HK1066289B - Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment - Google Patents

Description

Converged communication platform and method for mobile and e-commerce in a multimodal network environment

Cross Reference to Related Applications

This application claims benefit of U.S. patent application No. 10/096,912 filed on 3/14/2002, which is a continuation-in-part (connection-in-part) of U.S. application No. 09/894,890 filed on 29/6/2001, the contents of which are incorporated herein by reference.

Background

Technical Field

The present invention relates to a convergent communications system for providing services to individual and corporate customers worldwide. More particularly, the present invention relates to a convergent communications system that provides mobile commerce, e-commerce and communications services through existing communications switches and without the need for specific hardware located at those switches. The system supports the use of prepaid and postpaid accounts between heterogeneous networks to provide a wide range of advanced communication services regardless of the location of the customer.

Description of the prior art

It is known that payment for services (prepaid) and setting up a credit account for services (postpaid) can be made in advance. The post-paid account is established based on the customer's credit and then the company institution establishing the post-paid account guarantees the customer's extended credit. Post paid accounts are well known and widely used.

For example, a postpaid telephone access account may be established. The customer is then able to make long distance telephone calls or access the telephone network using the postpaid account when the customer roams in a visited network different from the home network. The telephone company then guarantees payment to any other company providing roaming services based on the customer's credit. In addition, mobile operators have provided roaming services to their customers for several years. Typically, mobile operators enter into roaming agreements with partner operators located in different regions (e.g., other countries), allowing their customers to use their mobile phones within these partner countries or different networks. The home network guarantees payment for calls made by their customers within the visited network. The visited network provides the home network user with the facilities to place and receive calls and collects, processes and forwards usage data to the caller's home network for payment. The home network then pays for the visited network.

At periodic intervals, the home network telephone company bills its customers and charges the customers for money. Such transactions typically involve long time delays, e.g., from days to months. Thus, for a visited network, the home network must act as a payment guarantee for calls made by its customers. For this reason, currently the home network can only provide roaming to postpaid customers (whose reputation is established). With the increase in prepaid subscriber groups, telecommunication operators worldwide wish to also provide roaming services to their prepaid customers. Today, operators are not able to provide true prepaid roaming to their customers due to the inherent nature of non-real-time processing of call usage to roaming customers.

Further, it is known to establish a postpaid credit account with a bank or other lending institution and then use the postpaid account to purchase goods and services. Occasionally, a postpaid credit account can be combined with roaming telephone services, e.g., credit card numbers exchanged over a wireless telephone link to order services. A limitation of such systems is that. For example, a customer may wish to limit the financial exposure of their account, or may not wish to establish credit with a telephone company. These customers may establish prepaid accounts. However, existing prepaid account schemes have several disadvantages.

For example, a prepaid mobile or wireless telephone user may want to use his/her wireless telephone when in an area covered by another telephone company. As described below, this is referred to as a visited or roaming area or network. While a prepaid customer may have sufficient credit to complete a telephone call using another account, such as a credit card, as a prepaid customer, the customer has not yet established "credit" with the telephone company of the roaming region, or even with its originating telephone company ("home network" or "home region"). Thus, while roaming, a prepaid customer in the roaming area ("prepaid roamer") cannot debit his/her prepaid home telephone company account unless the roaming network telephone company has an agreement with his home network telephone company and has specific hardware on each switch to monitor the call and debit the customer's prepaid account. Since these establishment agreements are generally not practical, there is no effective prepaid roaming.

Prepaid telephones already exist within the telecommunications industry. The customer or user needs to pay a certain amount of money in advance to the communication service provider, and the service provider allows the customer to use a communication service equal to the prepaid amount. When the user account balance is zero, the service provider stops the service. The customer then has to top up his/her account by paying the additional credit to the communication service provider. Thus, prepaid accounts need to remain negotiable.

To enable prepaid communication services, the service provider needs to control in real time the actual use of the credit in the customer's prepaid account (i.e., as the service is delivered) and the service provider needs to have a system that can calculate in real time the use of the account credit as the customer calls. There are several systems available on the market for service providers that allow real-time usage control. Today's commercially available technology enables service providers to use several methods to control calls in real time or near real time.

The first approach is a prepaid platform as a service node to a telephone switching network. Calls may flow through the prepaid platform or the service node prepaid platform may control calls in a semi-intelligent network (i.e., where the platform instructs the switching network to connect/disconnect when virtually no calls are routed through the system). Thus, the prepaid platform functions as an intelligent network node on an IN (intelligent network) enabled telephone switching network.

Prepaid service may also be provided in a manner that calls data records ("CDRs") are processed periodically at very short intervals. The switching system allows usage information to be transferred to the service provider's billing system, for example, through a hot CDR port where the telephone company switch is set to provide usage information to the billing system at frequent intervals. Prepaid service may also be provided by programming a card with an advice of charge ("AoC") parameter, which limits call usage. However, mobile operators worldwide are stopping their use because of the fraud that is prone to using call data records. Also, AoC cannot provide flexibility in setting usage rates.

Traditional prepaid systems require call control equipment, i.e. software and hardware, to be co-located with the switch at the same time. The prepaid system is connected to the telecommunication exchange via a signalling link (e.g. SS7, MF2RC or ISDN-PRI, etc.). When a caller places a telephone call, the switch routes the signaling information to the prepaid system over the signaling link. The prepaid system then authorizes the call and asks the switch to connect the call. The prepaid system also initiates a billing process for the call. The billing process tracks the usage of the caller's prepaid account and when the balance runs out, the system asks the switch to disconnect the call.

The deployment of this type of system for prepaid roaming is not sufficient. For prepaid roaming, all networks participating therein, and usually heterogeneous, need to have the same prepaid system. This means that multiple prepaid call control devices need to be deployed for each participating network. This can have a dire impact on logistics for several reasons. First, the initial deployment of devices on all participating networks is time consuming and costly. Second, normal operation and maintenance (e.g., tariff plan updates, management information system information, etc.) is a difficult logistics on a daily basis.

In addition, roaming services require data clearing and settlement of financial transactions. Multi-party settlement between various network systems is very complicated. Customer account establishment and management across networks is very complex and any delay can cause significant inconsistencies and confusion for customers. Customers may exhaust their prepaid account balance while in the visited network. The customer must be able to add money or "top up" his/her account from the access network. Recharging from a customer accessing a network presents several problems, including: how to allow a customer account to be recharged when the customer is not a customer of the visited network service provider, how to manage financial transactions related to payment management and settlement of the recharge amount (e.g., issues related to dealer commissions, recharge service simplification processes, and money transfers between the home network and the visited network).

If the customer needs help about his/her account, such as billing information or additional services, etc., then the question arises as to who he/she will contact for customer service. The visited network may not have all the information related to the client and the information in the home network is not necessarily current. The visited network may want to provide value added services such as simple messaging service ("SMS"), data services, and call related services (e.g., call conferencing, call waiting, etc.) to the roaming client (which are available to the same client within the home network when he/she is not roaming). Another problem arises when information between the home network and the visited network needs to be synchronized to the prepaid roaming client.

Most telephone companies today have in-house information technology ("IT") systems for operation and service management. Their current prepaid systems are integrated with these internal operations and service management systems. Telephone companies desire the same level of integration between their prepaid roaming systems and enterprise-wide IT systems so that they can efficiently manage their services. The deployment of several prepaid roaming systems may imply several integrations. This in itself can be time consuming and costly.

For post-paid customers, the telephone company is willing to undertake customer payment or financial risk, since the home network has already assessed the customer's credit and the home network is willing to undertake the payment risk. However, in the case of a prepaid customer, the home network may not even know who the customer is, e.g. it may be an anonymous customer. This means that both the visited network and the home network need to enter into a fixed agreement for various types of transactions (e.g. communication services as well as commercial transactions).

The telephone company also provides customer care to its customers. However, telephone companies provide customer care to their users only when they are within their home network. If the user is roaming, he can dial a customer care center of the home network and use the facility. However, providing customer care outside the home network service area is difficult because customer information is not available within the visited network. Some telephone company operators are able to provide limited customer care within the access network. However, until now, such systems have only accepted post-paid customers.

Customer care becomes very important for prepaid customers as the population of prepaid customers increases and mobile commerce opportunities grow. Generally, from a customer care perspective, customers require several needs: information related to services available at a visited network or regional location (e.g., whether a customer can send a fax using his/her mobile phone), information related to a local region (e.g., who is located nearest a doctor), information related to how to use access to network services (e.g., how a customer places a call to an XYZ destination; how a fax is sent using his/her mobile phone provided by a visiting network vendor), account consulting services (e.g., what is the current balance within the customer's prepaid account; what are the five transactions the customer has recently performed and how much these transactions are spent), account/service status information modifying services (e.g., the customer may want to change his/her address; the customer may want to sign up for a new service so that he/she can send a fax), disputes/complaints (e.g., the customer has tried ten calls but dropped each call, the customer therefore does not want to pay for the call; the customer never places a call to the XYZ destination), the customer's prepaid account is recharged from various sources (e.g., the customer has exhausted the amount in his/her account and he/she wants to top up his/her account by using a recharge ticket, his/her bank account, cash, or some other method).

Telephone company traffic is complex. Any telecommunication service delivery requires various systems to operate together to manage customer expectations, for example, to make services available and to provide complete and accurate information at the appropriate time and in the appropriate location to effectively service the customer. The telephone company system must also ensure that the internal operation of the telephone company is optimized. This means that complete and accurate information is required to be available to employees within the telephone company at the right place and at the right time so that it can be used to effectively manage the business. The telephone company system must also ensure that they are able to coexist or be compatible with other third party telephone companies and service providers so that they can collaborate to provide services to customers together and manage their business, share revenue, etc. To meet these large and complex requirements of telephone companies/service providers, no single system is capable of providing this entire functionality. Often, suppliers, integrators, and telephone companies cooperate in a hand-held fashion to customize and integrate several different systems to meet the needs of a particular telephone company.

Since prepaid communication service was originally intended as a separate service, telephone companies have generally adopted a single company-specific system that is capable of controlling calls in real time (or near real time, depending on the different definition of the phrase "real time"). As prepaid communication services begin to grow rapidly throughout the world, service providers feel the need to integrate their prepaid systems with other systems in order to effectively provide services to their customers and manage services.

However, prepaid roaming presents several challenges to the telephone company industry. All participating networks need to have a common understanding of how to manage call flow, how to provide services, and how to manage traffic. However, with several systems integrated in several ways between various networks, there are many challenges for prepaid roaming. One fundamental problem is how to achieve "seamless" service delivery to customers and efficient traffic management between several participating networks (usually heterogeneous or heterogeneous networks). For example, one service provider operator may have a good customer care center while another operator may not have such a high quality customer care center, or one operator may have a high quality top-up generation/management system while another operator manually manages most of these processes. Due to the different permutations and combinations of telephone companies, the integration of several different systems, either simple or complex, does not provide a business solution. Also, regardless of how good the new system is, it is impractical to expect one or more telephone companies to abandon their existing systems and adopt entirely new systems.

Known prepaid systems are single box solutions that allow limited integration with external systems. Even in cases where integration is feasible, it is not possible for other systems to go to the various levels of the prepaid system. That is, it is not possible to replace some functions of the prepaid system by integration. It is the integration that is needed to add additional functionality. This is a major limitation for telephone companies to manage their traffic efficiently. For example, if a telephone company already has a Personal Identification Number (PIN) generation system, if it wants to deploy a prepaid system for roaming, it needs to use the PIN generation capability of the new prepaid roaming system instead of the old system. This means that telephone companies now need to have two types of PIN generation systems-one for non-roaming users and one for roaming users. This can be very confusing in the market place and integration with third party systems alone does not solve the problem. Other problems of this type exist, such as allocation management, customer management, etc.

In addition to the above, when a mobile operator enables mobile commerce for prepaid roamers in a convergent communications and commerce environment, the parties involved in the commercial transactions made by prepaid roaming customers are required to perform financial settlement. Settlement of a business transaction may also involve: payments associated with a business transaction may need to be distributed among one or more of the following entities: merchants (provider or manufacturer, distributor or distributor of goods/services or a combination of several of these entities), portals (mobile portals or other types of portals including voice portal ("virtual"), electronic commerce portal, etc.), internet service providers (standalone agents, or mobile operators themselves, or portals themselves), mobile phone companies (home networks, access networks, or a combination of both), virtual service providers (or content service providers, or infrastructure service providers, or brand agents, or any combination thereof), bank/credit card agents or any other financial institution(s) involved in the transaction), third party payment agents (e.g., business groups, payment processing agents, electronic purses, or any such payment processing agent), goods/services delivery agents (e.g., courier company, express company, etc.) Bandwidth providers and insurance agents). There may be instances where the mobile service provider may offer some bundled services (e.g., if the customer purchases a product worth $ 50 while roaming, the additional cost of roaming on the phone may be cancelled, etc.). This means that any accounting system should be able to derive various accounting amounts based on tariff plans and roaming agreements between the parties involved in the business transaction.

Mobile processing devices (phones, PDAs, etc.) are expected to be used for processing all types of payments, in particular micro-value payments. Typically, the customer will use his mobile phone to pay for low value items, such as soft drinks, cigarettes, newspapers, books, parking fees on vending machines and other such low value payments, which are commonly referred to in the industry as micro-value payments.

The current state of the art today allows such payments to be made in the following manner: the customer can use his/her mobile phone and at the time of payment he/she can use his/her credit card or bank debit card to make the payment. This means that payment will be made through the customer's bank/credit account rather than the customer's telephone account. This method has the limitation of assuming that all customers have bank debit or credit cards. The current growth of prepaid mobile phones worldwide means that there is a large market share in the market that does not have any bank/credit relationship or simply does not want to use their bank/credit relationship for the phone. This is especially true in some developing countries with weaker bank configurations. The debit/credit card assumption also limits the overall number of mobile commerce capable customers, and thus, telephone companies may only play a very limited role in mobile commerce. Telephone company revenue is typically limited to the telephone connections and services they have provided. However, the customer may use his/her mobile phone account for payment of the business transaction. That is, the cost of goods/services will be charged to the customer's telephone account. At the end of the month, the customer receives a telephone bill which includes the cost of the goods/services purchased. This approach is limited in that it assumes that the customer is a post-paid account customer. This means that the system does not accept pre-paid customers and therefore mobile commerce transactions cannot be conducted. Instead, the system assumes that the payment risk is borne by the telephone company or merchant. At the end of the charging period, the telephone company/merchant must bear this financial risk if the customer does not pay his/her bill.

The customer may have an electronic wallet account, which is an account with a personal identification number. Each time a customer purchases an item, he or she may type in a PIN and an electronic wallet company (e.g., IPIN) may issue a payment guarantee. In this method, the e-wallet functions as a pre-paid account, and the purchase transaction can only be authorized if a balance is held in the account. This approach is limited in that each time a purchase is requested, the user must prove his/her own identity (e.g., using a PIN, which is typically a 12 digit number or more). This identification process itself has a deterrent effect, and customers may not be interested in passing this process for small value purchases. Again, telephone companies will play a very limited role in mobile commerce, since their revenue or charges are limited to the telephone connections they have provided.

In order to simplify the mobile commerce purchasing process, the industry is seeking innovative technologies, such as bluetooth technology, which allow direct communication between the vending machine and the customer's mobile phone. However, these technologies are also limited in that merchants and customers must be equipped with equipment that can use these technologies. This means higher equipment costs. Cost economics may not justify such investment at least in the early years, and these techniques do not address issues related to payment risk. These systems assume that all customers are trusted and will redeem their payments. In real life, this is not the case. Furthermore, these techniques do not address the problems involved with prepaid customers. The prepaid customer may be anonymous, meaning that neither the telephone company nor the merchant knows who the purchaser is.

Read/write memory devices are becoming increasingly common in today's e-commerce industry. The read/write memory device has the capability to store account balances and other customer-related information. The read/write storage device does not require any network connection to the backend system. The reader of the read/write memory device may be deployed at the merchant's location and an approaching customer may use his card to make payments. This mechanism has been found to be useful because it is simple to use for both merchants and customers and allows advance payment.

Each time a service is used, payment associated with the service is deducted from the customer's prepaid account. It is clear that money on a prepaid account will reach a zero balance at some point. Thus, the customer needs to recharge his/her prepaid account. There are several commercially available systems on the market that offer prepaid facilities and account top-up for the most part. Currently available systems allow for recharging accounts: it can be used by the customer by issuing a voucher (with a unique number, called a PIN, having a certain preset value, e.g., $ 20). The customer dials into the service provider's interactive voice response ("IVR") system and through a guide menu, the customer is able to recharge his/her prepaid account by typing in a unique PIN number.

A limitation of such a top-up system is that the service provider must print top-up coupons and issue them. This is a significant logistical and cost issue. Again, there is a potential fraud risk with several types of possible fraud, for example, PIN leakage to unauthorized users, random attempts by unauthorized users to dial several numbers and match the correct number, and unauthorized parties printing counterfeit recharge tickets, such as counterfeit coins. Further, the service provider may only provide a preset number of money items for each ticket. While they may offer several types of coupons, each coupon has a preset number. This means that the customer cannot choose the exact number he/she wishes to recharge. Further, the service provider cannot offer credit overdraft for prepaid customers. The increasing use of prepaid accounts in highly developed and credit-driven countries shows that customers are increasingly using prepaid accounts due to their convenience and simplicity of use without facing any credit-related problems. Such customers do not want to pay in advance for services they have not used yet. This approach will increase the number of customers who select prepaid accounts due to credit limits (with assurance that payment is guaranteed by a third party such as a bank).

In the case where the prepaid number is programmed into a card (for example a SIM card, a smart card, a magnetic card or any other type of card) usable by the customer, the customer can bring his card to the nearest socket which possesses a special programming machine usable for replenishing this card. These types of prepayments have been used in the past. However, as mobile commerce becomes more prevalent, it is expected that customers will want to use these solutions for micro-value payments. The scheme of programming prepaid numbers into the card provides convenience to the customer because he/she does not need to type a long (typically 12 digits or more) code for a transaction of very low value. However, the limitation of this account recharging method is that the customer can only find a limited recharging socket each time recharging is required. These cards cannot be recharged elsewhere. Service providers also do not want to update or charge large numbers into these cards because of issues related to fraud (e.g., unauthorized parties accessing devices that can write large amounts of money on the cards) and the inability of service providers to provide credit overdraft to prepaid customers.

In normal commercial transactions (e.g., using credit/debit cards in physical department stores or shops), transaction verification is typically accomplished by swiping a card and physical signature verification. Sometimes, to protect against fraud, credit/debit card agents require the merchant/customer to call the bank. The bank will then use additional security measures such as asking the mother for the mother's maiden character, date of birth, etc. to ensure that the customer is not an unauthorized user. In today's internet and mobile internet, various existing unmodified prepaid account systems do not present these additional security measures and are subject to the fraud described above. Fraud is assessed to be high for internet/mobile internet related transactions due to limited security.

When a phone call charge occurs, the customer's prepaid account may be debited. These debits may come from many sources that vary from account to account. For example, a prepaid telephone access account may be established. The customer may then make a long distance telephone call or access the telephone network.

Further, a post-paid credit account may now be established with a bank or other lending institution and then utilized to purchase goods and services. Occasionally, a postpaid credit account can be combined with roaming telephone services, e.g., credit card numbers exchanged over a wireless telephone link to order services. There are limitations to such systems. For example, a customer may wish to limit the financial exposure of their account, or may not wish or for other reasons be able to establish credit with a telephone company. These customers may establish prepaid accounts. However, existing prepaid account schemes have at least several disadvantages.

For example, a prepaid mobile or wireless telephone user may want to use his/her wireless telephone when in an area covered by another telephone company. As described below, this is referred to as a visited or roaming area or network. While a prepaid customer may have sufficient credit to complete a telephone call using another account, such as a credit card, as a prepaid customer, the customer has not yet established "credit" with the telephone company of the roaming region, or even with its originating telephone company ("home network" or "home region"). Thus, while roaming, a prepaid customer in the roaming area ("prepaid roamer") cannot debit his/her prepaid home telephone company account unless the roaming network telephone company has an agreement with his home network telephone company and has specific hardware on each switch to monitor the call and debit the customer's prepaid account. Since the subscription of these agreements is often impractical, there is no effective prepaid roaming.

Prepaid telephones already exist within the telecommunications industry. The customer or user needs to pay a certain amount of money in advance to the communication service provider, and the service provider allows the customer to use a communication service equal to the prepaid amount. When the user account balance is zero, the service provider stops the service. The customer then has to top up his/her account by paying the additional credit to the communication service provider. Thus, prepaid accounts need to remain negotiable. Any transaction for which an account does not have sufficient credit is processed as a restricted transaction.

When a restricted transaction is encountered, there are two options for processing the transaction. The transaction may be denied. The transaction may be approved, depending on later verification. When the transaction is approved by subsequent verification, the account provider accepts the risk of being exposed to fraudulent transactions. Thus, if a large debit occurs in the credit account and the credit account provider approves the transaction after further telephone calls to the account holder, the credit account provider is typically charged with liability when the transaction is detected as fraudulent.

Various credit account providers will attempt to distribute these losses based on their position in the marketplace. For example, a credit provider may force a vendor who accepts their credit card to accept a portion of the losses incurred by fraudulent transactions, for example. Alternatively, losses can be reduced by using insurance.

Similarly, there is now a credit transaction to the account. Pre-authorized credit, sometimes referred to as overdraft protection, is also occasionally used. Again, the restrictions on the accounts are also simplistic. For example, payment that would reduce the checking account balance below zero is approved as long as there is still an account in the savings account, and transfers from one account to another are not subsequently made.

There are also various discounts for services associated with a particular account. For example, if the customer is a member of a savings club, groceries may be purchased at a discounted price. Thus, even if there is no account on the account, the record of the transaction is sufficient to decide a discount for holding a certain membership. The additional discounts may depend on a certain number of accounts or account records. In addition, advertisements and discounts may be specifically offered to various customers. It is now possible to pay for services (prepaid) and to set up a credit account for services (postpaid) in advance. The post-paid account is established based on the customer's credit and then the company institution establishing the post-paid account guarantees the customer's extended credit. Post paid accounts are well known and widely used.

To support prepaid communication services, the service provider needs to control in real time the actual use of the account in the customer's prepaid account (i.e., the service is being delivered) and the service provider needs to have a system that can calculate in real time the use of the account's account as the customer's call progresses. Several systems have been offered in the market place for service providers to simulate such real-time usage control.

In addition, roaming services require data clearing and settlement of financial transactions. Multi-party settlement between various network systems can be very complex. Customer account establishment and management across networks can be very complex and any delay can introduce significant inconsistencies and confusion to customers. Customers may exhaust their prepaid account balance while in the visited network. The customer must be able to add money or "top up" his/her account from the access network. Recharging from a customer accessing a network presents several problems, including: how to allow a customer account to be recharged when the customer is not a customer of the visited network service provider, how to manage financial transactions related to payment management and settlement of the recharge amount (e.g., issues related to dealer commissions, recharge service simplification processes, and money transfers between the home network and the visited network).

Various exemplary embodiments of the present invention enable mobile processing devices (phones, PDAs, etc.) to be used for all types of payments, particularly micro-value payments. Typically, the customer will use his mobile phone to pay for small value items, such as soft drinks, cigarettes, newspapers, books, parking fees on vending machines and other such low value payments, which are commonly referred to in the industry as micro value payments.

The inability of the service provider to provide credit overdraft for the prepaid customer can result in limitations on the use of the prepaid account. The increasing use of prepaid accounts in highly developed and credit-driven countries shows that customers are increasingly using prepaid accounts due to their convenience and simplicity of use without facing any credit-related problems. For reputable customers, these accounts are referred to as real-time authorized accounts. Such customers do not want to pay in advance for services they have not used yet. This approach will increase the number of customers who select prepaid accounts and real-time authorized accounts due to credit limits (with the assurance that payment is guaranteed by a third party, such as a bank).

In the case where the prepaid number is programmed into a card (for example a SIM card, a smart card, a magnetic card or any other type of card) usable by the customer, the customer can bring his card to the nearest socket which possesses a special programming machine usable for replenishing this card. These types of prepayments have been used in the past. However, as mobile commerce becomes more prevalent, it is expected that customers will want to use these solutions for micro-value payments. The scheme of programming prepaid numbers into the card provides convenience to the customer because he or she does not need to type a long (typically 12 digits or more) code for a transaction of very low value.

However, the limitation of this account recharging method is that the customer can only find a limited recharging socket each time recharging is required. These cards cannot be recharged elsewhere. Service providers also do not want to update or charge large numbers into these cards because of issues related to fraud (e.g., unauthorized parties accessing devices that can write large amounts of money on the cards) and the inability of service providers to provide credit overdraft to prepaid customers. Furthermore, such a top-up system becomes logistically less feasible the further away the user is from his "home base". For example, a service provider located in london may not provide a top-up center in paris, let alone hong kong, even if his customers frequently visit these locations. Because in the case where the service provider relies on the assets of another party, such as a store floor or distribution infrastructure, he is likely to lose a significant portion of the potential revenue in order to pay a commission on the use of these assets.

Disclosure of Invention

One exemplary embodiment of the present invention disclosed in U.S. parent patent application No. 09/395,868 relates to prepaid calling and other communication services using a simple telephone switch. The simple telephone switch has a plug-in computer telephony interface ("CTI") card that routes advanced functions to a second secure channel. The second secure channel is connected to the communications platform through a telephone network, the internet, or any other internet protocol network. The communications platform can then send authorization, connection instructions, and other commands for the call to a simple telephone switch so that the customer can access advanced functions.

The use of a second secure channel for authorizing payment and handling call control enables several exemplary embodiments (with modifications to the communication system) described in detail below to result in improvements to prepaid roaming services. For example, in addition to the above-described prepaid roaming, the invention in this document provides an improved convergent communications device for mobile commerce, e-commerce, account replenishment, multi-party settlement transactions, integrated customer care, or any other commercial transaction.

Thus, the first exemplary embodiment of the present invention is a converged communication system residing at a centralized location, accessible from any location through the internet, the public switched telephone network, SS7 signaling lines, telephone numbers, or any other now known or later devised means. The prepaid roaming call is then handled by signaling from the local telephone exchange to the centralized convergent communications platform that the customer is attempting to access his/her account.

The convergent communications platform can then authorize the telephone call after completing several steps. The first step is to check that the client is indeed an authorized client. The second step is to check that the customer has authorized the use of this particular service. The third step is to check the account balance within the customer centralized convergent communications system. If the request is from a customer who has authorized the service and has a sufficient account balance, the centralized convergent communications platform may issue an authorization number to the local telephone exchange.

Then, when the customer completes the telephone call, the local telephone exchange can send a notification of the completion of the service and the duration of the call to the centralized convergent communications platform. If the customer runs out of money in his account during the telephone call, the centralized, convergent communications platform can send a message to the switch over the second line to end the telephone call. In either case, the prepaid roaming customer is able to access his/her account and use prepaid services.

Within the telecommunications industry, different network technologies exist in different geographical locations. Customers expect to be able to connect to phones in roaming areas while going from one place to another (e.g., from europe to the united states) using the same phone number. Today roaming can be performed between two networks of the same type (e.g., roaming from one GSM network to another GSM network or one AMPS network to another AMPS network, etc.). However, due to technology differences, customers cannot roam between one type of network and another (e.g., customers with GSM phones cannot roam in CDMA networks; customers with AMPS phones cannot roam in GSM networks). The inability to roam is because each technology operates on a different frequency. Thus, mobile handsets are incompatible, call flow management in each telephone company network technology is different, and subscriber identification procedures in each network type are also different. For example, in a GSM network, a subscriber or customer is identified by IMSI, SIM serial number and MSISDN; within a CDMA network, a user or customer is identified by MIN and ESN; whereas within AMPS networks, users are identified by ESN.

The problem of roaming between heterogeneous networks can be solved by either of the following two solutions: a customer may purchase a multi-band mobile handset that allows paging signals from the handset to be identified by multiple networks (e.g., a tri-band handset allows a user to use the same phone in europe as well as the united states), or a roaming customer may go to a roaming service provider and temporarily rent handsets of different roaming network standards. The telephone company may also ensure that the customer is reached with the same telephone number by means of call forwarding.

However, these roaming solutions are only feasible for post-paid users. They cannot provide prepaid roaming for prepaid subscribers because all participating networks need to authenticate, charge and charge the customer's home network prepaid account together. There are no commercial technologies in the market today that can support prepaid roaming across heterogeneous networks.

With the growth of prepaid subscriber groups, telephone companies worldwide wish to provide prepaid roaming across multiple types of networks. Therefore, there is a need for a solution that is capable of: the method includes the steps of satisfying different requirements of heterogeneous network types, acquiring related call control information and user information from a calling or roaming network, establishing and transmitting the related call control information and user information to a home network of a user, not only acquiring user authentication according to user validity, but also authenticating the user according to service conditions allowed to be provided to the user, returning approval/rejection to the calling or roaming network in the form of a call or roaming network requirement, billing call usage in real time, providing usage information if the call is established by the calling network or the network in which the user is located, and performing multi-party settlement on services provided between heterogeneous networks.

Customer care solutions for roaming users (especially prepaid roamers) should also have at least the following capabilities: the ability to identify a roaming user when the user calls into a customer care center ("CCC"); the ability to communicate with the home network and obtain information related to the customer's account (balance, previous transaction records, etc.) and customer service status (what services are allowed to be provided to that particular customer); the ability to process a client's request for information delivery/query responses; the ability to respond to customer accounts or service conditions (e.g., credit/drop the number of calls used for dropped calls; activate new services for the customer, etc.); the ability to enable users to connect to customer care systems within an access network such that customer care can be provided (e.g., integrated with local interactive voice systems, customer care applications, etc.); and the ability to update the customer's home database to maintain the integrity of the customer's account information and to allow the customer to be able to top up his/her prepaid account while roaming.

Prepaid roaming also presents several challenges for multi-party billing for convergent communication services. In post-paid roaming money is collected from the customer by the home network. Thus, all visited networks send roaming client usage data (either directly or via a data clearing/settlement center) to the home network for settlement. In prepaid roaming, customer a may initially order from network X but recharge its account in network Z using a prepaid amount on network Y. In this case, network Z does not have a business obligation to pay network Y, although network Z is holding a top-up amount paid by customer A. In addition, network X is vouching for customer payment and does not actually hold the money paid by customer A. Likewise, for providing payment collection or top-up services, network Z may wish to collect a service fee from network X.

Currently existing roaming settlement solutions are only concerned with the telephony services of the postpaid service. They do not address the need for prepaid telephone service (single or convergent service) nor do they address the need for settlement of business transactions made by prepaid roaming users within a visited network. Therefore, there is a need for a solution for a method and system that: allowing multi-party settlement of convergent services and communication transactions; and allows settlement rules to be set for each service and business transaction. These rules should allow settlement between: merchants (providers of goods/services, such as manufacturers, distributors or a combination of several of these entities), portals (mobile portals or other types of portals including e-commerce portals and the like), internet service providers (independent agents, or mobile operators, or portals), mobile phone companies (home networks, or access networks, or a combination of both), virtual service providers (content service providers, or infrastructure service providers, or brand agents, or any combination thereof), bank/credit card agents or any other financial institution(s) involved in a business transaction), third party payment agents (such as business groups, payment processing agents, e-wallets, or any such payment processing agents), goods/services delivery agents (such as courier companies, express delivery companies, etc.), Bandwidth provider) and insurance agents.

The settlement rules should also allow settings for various conditions, such as: (1) real-time settlement, (2) settlement with time delay (e.g., after 2 or 30 days, etc.), (3) settlement based on confirmation of certain conditions (e.g., paying the courier only at the time of delivery of the goods and paying the insurance agent before shipment of the goods), (4) settlement based on business relationships between the parties (e.g., courier provides a volume-based discount-meaning that the settlement process will process several deliveries rather than just one delivery), and (5) settlement based on performance (e.g., portal gets a small value payment each time an advertisement is delivered to the roaming user and a larger value payment if the roaming user actually purchases the goods/services). The settlement should also take into account roaming contracts (e.g., roaming surcharges) between the participating networks. Settlement should also take into account any regulatory requirements (e.g., tax withdrawals and settlement with government agencies).

For prepaid services and commercial transactions to be successful, particularly in mobile commerce, there is a need for a method and system that allows for recharging from any of the following ways: a load ticket, directly linked to a secured account (credit/debit/any other type of account), loaded by the customer from a mobile or landline phone, directly debited to a secured account (credit/debit/any other type of account), loaded by the customer from a bank ATM, or loaded by cash payment at a cash desk. Each prepaid customer should also be able to set its own criteria for top-up in the following way: recharge from only a telephone (mobile or fixed), from only a network (internet, mobile internet or any other type of public or private network), only when the customer specifically requires recharge (through IVR, network, or walk-in, or any other means), automatically recharging from another specific account (bank debit or credit or any other type of account) when the balance drops below a certain value, without recharging the account, but rather uses another account as a payment guarantee for the prepaid account, charges several sub-accounts on a preset limit basis from the primary account, charges periodically (e.g., daily, monthly, weekly, etc.), and determines the number of charges according to usage criteria set by the user (e.g., view the last seven days of usage and charge their average number; or the number of charges should equal the value of the highest priced transactions conducted during the last "x" days, etc.).

In a prepaid convergent communications environment, transaction validation/authentication (a communications service, or a business transaction, or a combination of both) may have several steps or checks to validate the availability of the user and the credit limit or prepaid money associated with the account. Solutions for communication access, internet or mobile/internet access, business transactions (done in physical stores or on a network/mobile network) should allow: verification of the room based on a PIN, password, phone-related security features, or a combination of all or part of the above, verification of whether the requested service/transaction is authorized for a particular customer prepaid account (service status verification), verification of whether there is a sufficient balance in the customer prepaid account for availability of the service/transaction (the balance may be in a precautionary account balance, or a credit account balance or any other type of real or virtual account associated with the customer prepaid account).

Additional validation may be performed according to rules set by the service provider (bank, telephone company, merchant, or any other type of service provider). For example, a service provider may: asking for additional information from the user (e.g., mother's maiden name, date of birth, or value of a previous transaction made, or value of a previous bill, previous charges, or a match of personal questions and answers preset by the customer), asking for special passwords for high priced transactions (e.g., above $ 20) or large numbers of transactions (e.g., more than 15 transactions a day or more than 50 transactions a month, etc.). Additional validation may be performed by the service provider based on rules set by the end user or customer.

For example, a client/user may request: additional passwords for some types of transactions (e.g., purchase of airline tickets), additional information (e.g., date of birth, friend's name, special password) that would be required by the system if the value of the transaction was higher than in the case of the previous transaction group (e.g., ask for a special password if the value of the current transaction was higher than 50% of the total price of the transaction within the last five days). The system should be able to block some types of transactions (e.g., allow all e-commerce and m-commerce transactions in addition to pornography or money transfers between countries where there is currency regulation) according to rules set by the customer/user.

According to the rules set forth above, the customer care agent should be able to speak to the customer by telephone (i.e., the system should allow voice communication for transaction authorization while the authorized transaction is in progress). The customer should not be charged for such voice communication/additional security information usage (e.g., toll-free access) according to rules set by the service provider.

Accordingly, an aspect of the present invention is to provide a method for providing mobile commerce, electronic commerce, customer care and communication services via a plurality of networks, the method comprising: receiving an identification number and a request for service from a user equipment within a roaming network; forwarding the identification number and the request for the service from the roaming network to the home network and adding a charge or charge related to the service provider's service provider identification number and the service if the service is charged; verifying, by the convergent communications platform located on the home network, that the identification number relates to a valid user account, that the user device is authorized to receive the service, and that the valid user account has sufficient value to pay for the service; if the identification number relates to a valid user account, the user device is authorized to receive the service, and the valid user account has sufficient value, providing authorization to the service provider if the service is charged; and charging the valid user account in real time (if necessary) to provide the service if the service is charged.

Another aspect of the present invention is to provide an apparatus for providing mobile commerce services via a plurality of networks, the apparatus having: a receiver for receiving a request for a service, the request comprising an identification number from a user equipment located within a roaming network and the requested service, a service provider identification number from the roaming network relating to the service provider and a cost of the requested service; a validator that validates that the identification number relates to a valid user account, that the user device is authorized to receive the service, and that the valid user account has sufficient value to pay for the service; a transmitter providing authorization to a service provider if the identification number relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value; and a charger to charge the valid user account for providing the service.

Another aspect of the present invention is to provide a method for providing prepaid roaming communication services via a plurality of networks, the method comprising: receiving an identification number and a destination device number from a user device within a roaming network; forwarding the identification number and the destination device number from the roaming network to the home network and adding the service provider identification number and the cost of the roaming communication service; verifying, by the convergent communications platform located on the home network, that the identification number relates to a valid user account, that the user device is authorized to receive the service, and that the user account has sufficient value to pay for initial use of the service; providing authorization to the roaming network if the identification number relates to a valid user account, the user device is authorized to receive the service, and the valid user account has sufficient value to pay for initial use of the service; charging the valid user account for providing the service; and sending a signal when the balance of the user account reaches a preset level.

Another aspect of the present invention is to provide an apparatus for providing prepaid roaming communication services via a plurality of networks, the apparatus comprising: a receiver for receiving a request for a communication service, the request comprising an identification number and a destination device number from a user device located within a roaming network, and a service provider identification number and a service charge from the roaming network relating to a service provider; a validator that validates that the identification number relates to a valid user account, that the user device is authorized to receive communication services over the roaming network, and that the valid user account has sufficient value to pay for the services; a transmitter providing authorization to a service provider if the identification number relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value, and signaling if the valid user account balance reaches a preset level; and a charger to charge the valid user account for providing the service.

Another aspect of the present invention is to provide a method of providing customer care services via a plurality of networks, the method comprising: receiving, within a roaming network, an identification number from a user equipment and a request for customer care services; forwarding the identification number and the request for customer care services from the roaming network to the home network and adding a service provider identification number; verifying that the identification number relates to a valid user account through a convergent communication platform located on a home network; and connecting the user device to the customer care service if the identification number relates to a valid user account.

Another aspect of the present invention is to provide an apparatus for providing customer care services via a plurality of networks, the apparatus comprising: a receiver for receiving a request for customer care services, the request comprising an identification number from a user equipment located within a roaming network and a service provider identification number relating to a service provider from the roaming network; an authenticator that verifies that the identification number is associated with a valid user account, that the user device is authorized to receive customer care services, and a connector that connects the user device to a customer care provider capable of providing customer care services if the identification number is associated with a valid user account.

Another aspect of the present invention is to provide a method of recharging a prepaid account for services provided via a convergent communications platform, the method comprising: receiving a request for authorization to use a customer account located on a convergent communications platform; determining that the customer account does not have a sufficient balance for the service to be provided; determining that a customer account has authorized a recharge mechanism; using the recharge mechanism to recharge the customer account; and authorizing use of the customer account for the service via the convergent communications platform.

Another aspect of the present invention is to provide an apparatus for recharging a prepaid account for services provided via a convergent communications platform, the apparatus comprising: a receiver that receives a request for authorization to use a customer account located on a convergent communications platform; a determiner that determines that the customer account does not have a sufficient balance for the service to be provided and that the customer account authorizes a recharge mechanism; a charger that charges the customer account using the charging mechanism; and a transmitter that transmits, via the convergent communications platform, authorization for use of the customer account for the service.

Another aspect of the invention provides a method for settling a prepaid transaction to a plurality of providers in a convergent communications environment, the method comprising: charging a fee in real time for a user account for a transaction provided via a plurality of networks; determining a plurality of portions of fees that should be allocated to a plurality of providers involved in providing prepaid transactions via a plurality of networks; and settling with the provider via the plurality of networks according to the determined plurality of portions.

Another aspect of the invention provides an apparatus for settling a prepaid transaction to a plurality of providers in a convergent communications environment, the apparatus comprising: a charger that charges a fee in real time for a user account for a transaction provided via a plurality of networks; a determiner that determines portions of fees that should be allocated to a plurality of providers involved in providing prepaid transactions via a plurality of networks; and a transmitter which settles with the provider via a plurality of networks according to the determined plurality of parts.

Another aspect of the present invention is to provide a method of providing mobile commerce, electronic commerce, customer care and communication services via a plurality of networks, the method comprising: receiving an identification number and a request for service from a user equipment within a roaming network; forwarding the identification number and the request for the service from the roaming network to the home network and adding a charge or charge related to the service provider's service provider identification number and the service if the service is charged; verifying, by the convergent communications platform located on the home network, that the identification number relates to a valid user account, that the user device is authorized to receive services, and that the valid user account has sufficient value to pay for services; if the identification number relates to a valid user account, the user device is authorized to receive the service, and the valid user account has sufficient value, providing authorization to the service provider if the service is charged; and charging the valid user account in real time (if necessary) to provide the service if the service is charged.

Further, an aspect of the present invention is to provide an apparatus for providing mobile commerce, electronic commerce, customer care and communication services via a plurality of networks, the apparatus comprising: a receiver which receives the identification number from the user equipment and a request for the service, a service provider identification number related to the service provider and a charge or charge for the service if the service is charged from the roaming network; a determiner, via a convergent communications platform located on the home network, that determines whether the identification number relates to a valid user account, whether the user device is authorized to receive services, and whether the valid user account has sufficient value to pay for services; a transmitter providing authorization to a service provider if the identification number relates to a valid user account, the user device is authorized to receive the service, and the valid user account has sufficient value, if the service is charged; and a charger that charges the valid user account in real time (if necessary) if the service is charged to provide the service.

It is, therefore, one aspect of the present invention to provide a convergent communications system and method that enables a single user account with flexibility and complexity to handle communications services and transactions originating from multiple sources. A single account capable of processing transactions from multiple service providers and transaction providers allows transactions that were previously unavailable to be made and reduces the cost of other transactions so that they become more frequent. Various exemplary embodiments of the present invention enable Micro-transactions in a multi-vendor, multi-system environment. Various exemplary embodiments establish a convenient way to authorize, debit, and settle very small transactions. Various exemplary embodiments of the present invention provide a convergent communications system and method that meets today's mobile, connected user needs.

It is another aspect of the present invention to provide a convergent communications system and method applicable to increasingly specialized societies where many participants need to carry out some transactions. Additional parties may add value to the transaction and wish to receive compensation based on that value. The real-time rule set described in this document allows multiple parties involved in a transaction to receive payment according to the debit and payment plan agreed upon by the parties. In a complex transaction, each service provider needs to be guaranteed to receive payment. For these complex collaborative service deliveries, parties in the delivery chain can only be assured if the complex transaction is authorized in real time against the account, where there are established rules for authorization that are assured to be available at that time (i.e., in real time). Various exemplary embodiments of the present invention enable multi-party debiting and settlement using real-time rule settings, making complex transactions between multiple service providers feasible.

Another aspect of the invention described in this document is to provide a communication system and method that extends the adaptability and functionality provided by accounts, allowing complex rules related to account top-up, authorization of transactions, real-time debiting and complex settlement, and methods of determining these rules.

A single account that provides flexibility and security to the customer may allow transactions that were previously impractical. Various exemplary embodiments of the present invention provide complex rule sets to be implemented that provide flexibility and convenience to customers while providing security to the service providers involved. For example, complex rules for crediting accounts, authorizing transactions, debiting accounts, and settling transactions to multiple recipients will provide the flexibility and convenience needed in today's and future mobile commerce transactions. Thus, it may be determined at any point in time whether the requested transaction is permissible, and if not, which additional actions are to be taken to make it permissible. Sometimes this involves making a selection to the customer, but usually not.

Determining the exact number of payments to specific parties can be complicated and requires a determination at the time of the transaction to ensure that all parties are treated fairly. Various exemplary embodiments of the present invention utilize real-time authorization and debiting of accounts to provide a transaction that is conducted in real-time. The real-time rule settings may be determined based on various considerations. For example, the time and date of the transaction, the customer's and merchant's history, and other factors that can be determined appropriately or in stages based on previous events can be used to support whether the transaction is authorized.

A first category of rules used in converged communication systems and methods is account replenishment, in which a user requests and is required to pay in advance for mobile commerce, communication or other e-commerce transactions from various service providers through converged communication systems and methods in a multimodal network environment. Account recharge may include various types of credits into an account. Various examples include: money, stocks, frequent flyer miles, membership additions, credit rewards, transfer of ownership, or any other now known or later devised method for transferring value into an account. Account recharge may be automatic, semi-automatic, manual, or automatic and manual within certain parameters. Various exemplary embodiments of the present invention provide for top-up from any of the following ways: a load ticket, directly linked to a secured account (credit/debit/any other type of account), loaded by the customer from a mobile or landline phone, directly debited to a secured account (credit/debit/any other type of account), loaded by the customer from a bank ATM, or loaded by cash payment at a cash desk. Thus, a user may create a complex but functional scenario to top up his or her customer account.

A second category of rules used in the convergent communications systems and methods are authentication and authorization rules in which a user requests and is required to pay in advance for mobile commerce, communications or other e-commerce transactions from various service providers through the convergent communications systems and methods in a multimodal network environment. Since exemplary embodiments of the present invention provide links to credit services, telephony, and the internet, rules outlining under what conditions money may be withdrawn from an account are included. Various examples include: per-charge limits, second system notifications, account charge limits, membership limits, or any other now-known or later-devised method for limiting single transactions, monthly transactions, account balances, transaction originators, and transaction recipients. Thus, the user may establish a complex but functional scenario to control who is authorized to use the account and its reasons.

A third category of rules used in the convergent communications systems and methods are debit rules, where a user requests and is required to pay in advance for mobile commerce, communications or other e-commerce transactions from various service providers through the convergent communications systems and methods in a multimodal network environment. Various exemplary embodiments of the present invention provide various methods for a service provider to establish a debit account with the service provider or customer. For example, a telephone service provider may provide a payment to its own account, one to the roaming network provider's account and a third to the long distance provider's account.

Various aspects of the present invention as described above may be implemented by a convergent communications approach that employs rule sets, which possess several functions, including: for an authorized user, determining at least one rule available at the time for authorizing a transaction and debiting an account of the authorized user; applying at least one rule for authorizing a transaction; debiting the account in real time according to at least one rule for debiting the account if the transaction is authorized; and settling the real-time debit with the plurality of transaction providers based on at least one settlement rule.

For the above systems and methods, various aspects may include: determining that the authorized user does not have sufficient value within the authorized user account to debit the transaction; and recharging the authorized user account after completing a recharge program having several functions, wherein the program comprises: determining a top-up user account from which funds are to be transferred, and authorizing the transfer by reference to at least one of a pre-authorized transfer and an authorization requested from an authorized user. Other aspects may include the use of multiple top-up user accounts for top-up. Other aspects may include: the requested authorization from the authorized user is at least one of a request for a PIN, a request for manual entry, a request for a user password, and a confirmation of the user's identity through biometric means.

For the above systems and methods, various aspects may include: the application is performed by using a plurality of rules for authorizing the transaction, the debiting is performed by using a plurality of rules for debiting the account, and the settlement is performed by using a plurality of settlement rules, or the debiting is performed by using a plurality of rules for debiting the account, and the settlement is performed by using a plurality of settlement rules. Other aspects may include: settlement occurs at least one of immediately, after 3 days, at the end of the natural month, at regular intervals, and in a series of partial payments, and applying at least one rule for authorizing transactions includes: the transaction is authorized using at least one of a user PIN, manual entry, a user password, and confirmation of the user's identity through biometric means.

For the above systems and methods, various aspects may include: at least one rule to be applied in real time at the time of the transaction authorization request is determined based on an algorithm using data related to historical events that are deemed relevant to the transaction authorization request. Other aspects may include: historical events are the actual results of previous purchase records or historical risk assessments by the authorized user, or the historical data available is constantly changing. Other aspects may include that the transaction is requested and connections to multiple transaction providers are over a multimodal network.

Aspects of the invention as described above may also be implemented by a user input device for accessing accounts within a convergent communications system, with: a transmitter to transmit to a convergent communications system to access an authorized user account for a requested transaction to an account manager, wherein the account manager has: a determiner that determines, for an authorized user, at least one rule that is available at the time for authorizing transactions and debiting accounts; a processor that applies at least one rule for authorizing the transaction; a debiter which debits the account in real time according to at least one rule for debiting the account if the transaction is authorized; and a settlement that settles real-time debits to a plurality of transaction providers according to at least one settlement rule; and a receiver that receives at least one of a confirmation to access the authorized user account, a confirmation from the account manager to debit the authorized user account, and a settlement notification.

The various aspects of the invention as described above may further be implemented by a convergent communications system employing rule sets with: a determiner, for an authorized user, that determines at least one rule available at the time for authorizing a transaction and debiting an account of the authorized user; a processor that applies at least one rule for authorizing transactions; a debiter that debits the account in real time according to at least one rule for debiting the account if the transaction is authorized; and a settlement engine that settles the real-time debit to the plurality of transaction providers according to at least one settlement rule.

The various aspects of the invention as described above may further be implemented by a convergent communications system employing rule sets with: a determiner that determines a plurality of rules for authorization in real time, debiting and settling the transaction at the current time; an authorizer that authorizes a transaction if a current state of an authorized user account or an authorized user satisfies a plurality of rules for authorizing the transaction at a current time; a debiter that debits the authorized user account and credits the at least one transaction provider account in real time; and a settlement unit for settling the transaction according to at least one settlement rule for settling the transaction.

Brief description of the drawings

These and other aspects and advantages of the present invention will become more apparent and more readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawings of which:

FIG. 1 is an exemplary embodiment of a system using a converged communication platform;

FIG. 2 is an exemplary embodiment of using a converged communication platform for mobile commerce;

FIG. 3 is an exemplary embodiment of using a convergent communications platform for prepaid roaming;

FIG. 4 uses an exemplary embodiment of a convergent communications platform for customer care;

FIG. 5 is an exemplary embodiment of an international system using a convergent communications platform;

FIG. 6 is an exemplary embodiment of a system using a converged communication platform;

FIG. 7 is an exemplary embodiment of an architecture for enhanced data services enabled with a converged communication platform;

FIG. 8 is an exemplary embodiment of a toll balance for a convergent communications platform;

FIG. 9 is an exemplary method of recharging a prepaid communication account;

FIG. 10 is an example of information forwarding between several participants for a converged communication platform;

FIG. 11 is a block diagram of mobile commerce while roaming;

FIG. 12 is an example of a user requesting roaming services with a converged communication platform;

FIG. 13 is an exemplary user and transaction record for a convergent communications platform;

FIG. 14 is an exemplary user account in a convergent communications platform;

FIG. 15 is an exemplary embodiment of an interactive voice response system for use in a convergent communications platform;

FIG. 16 is a flow chart illustrating the use of prepaid accounts for multi-party settlement in a convergent communications platform;

FIG. 17 is an exemplary embodiment of a semi-automated method for recharging prepaid accounts and establishing rules for multi-party settlement in a convergent communications platform;

FIG. 18 is an exemplary method of generating a reconciliation report in a convergent communications platform;

FIG. 19 is an example of data transfer within a converged communication platform;

FIGS. 20A and 20B are exemplary methods of multi-party real-time settlement in a convergent communications platform;

FIG. 21 is a block diagram of an exemplary account management device for a convergent communications platform;

FIG. 22 is a block diagram of an exemplary switching manager device for a converged communication platform;

FIG. 23 is an example of a business-to-business transaction using a convergent communications system;

FIG. 24 is a block diagram of a convergent communications system for conducting business-to-business transactions;

FIG. 25 is a block diagram of an exemplary system for account replenishment in a convergent communications platform;

FIG. 26 is a block diagram of an exemplary system for recharging prepaid accounts using an interactive voice response system within a convergent communications platform;

FIG. 27 is a block diagram of an exemplary security system used by a convergent communications platform;

FIG. 28 is an example of multi-party settlement with a convergent communications platform as the settlement center;

FIG. 29 is an exemplary screen shot of vendor information for settlement within a convergent communications platform;

FIG. 30 is an exemplary screen shot of adding vendor information into a convergent communications platform;

FIG. 31 is an exemplary screen shot of adding detailed information about a merchant to a convergent communications platform;

FIG. 32 is an example table of a rules repository for a converged communication system;

FIG. 33 is an exemplary apparatus capable of implementing settlement for a convergent communications system;

FIG. 34 is an exemplary method of complex account top-up using a convergent communications system;

FIG. 35 is an exemplary method of complex transaction authorization using a convergent communications system;

FIG. 36 is an exemplary method of complex real-time account debiting using a convergent communications system; and

fig. 37 is an exemplary method of a complex settlement process using a convergent communications system.

Detailed description of the embodiments

As described in this document, exemplary embodiments of the present invention can be applied to systems, methods, and platforms for use with multimodal (or aggregated) networks and for aggregated communication, aggregated commerce, and aggregated services. When various industry terms and acronyms are used, several terms have the additional meanings described below.

An example of a multimodal network is a network of dissimilar or multiple technology components or combined components. For example, a diverse network may possess: different telecommunication standards, such as GSM and CDMA; different versions of the same telecommunications standard, such as GSM 900 and 1900; different exchange environments, such as nokia and ericsson; intelligent Network (IN) or non-IN; different signaling, such as ISDN and SS 7; different operating systems, such as UNIX and microsoft windows NT; different styles of the same operating system, such as SOLARIS (SUN) and AIX (IBM); different versions of the same operating system, e.g., 2.0 and 2.1; different server hardware, such as IBM and Conbo; the same operator but different network types, such as KDDI CMDA and PDC in japan; the same operator but different networks, e.g. VODAFONEs in different countries.

Examples of aggregation combine various technologies and media together to provide richer services. For example, the convergent communications may combine: different media, such as voice, data, messaging; mobile, fixed or satellite voice, data, messaging provided by different service providers; mobile, fixed or satellite voice, data, messaging media provided by different service providers; mobile, fixed or satellite voice, data, messaging media provided by the same service provider; mobile, fixed or satellite voice, data, messaging provided by different service providers. The convergent business includes: combination telephone, internet, e-commerce or mobile commerce. The convergent services include: combining communication and business services. Aggregated billing may include such features as providing a unitary, integrated bill for all communication services and the fees charged for the content or goods delivered. Convergent commerce may also refer to the integration of all the fees for a transaction into one transaction and the cost of items such as surcharges, taxes, telecommunication fees, etc. A convergent service may also refer to providing a single helper operator that can access, view, and modify a customer account even if the account is not on the local network.

The convergent interface may consist of a number of required and optional parameters that can be set to integrate with third party systems by analyzing the input/output parameters required by the third party components, mapping the third party components to the exemplary convergent communications platform components parameters, and setting the components to resolve any conflicts. If the third party system is unable to provide some option parameters, the exemplary convergent communications platform can create virtual parameters to ensure proper mapping.

Examples of platforms include systems that provide a basis for additional uses (additional endpoints). For example, a communication platform such as a telephone system allows data to flow through the platform in a variety of ways to communicate. Similarly, the convergent communications platform can allow a mix of technologies to enable enhanced mobile commerce (enhanced mobile commerce), e-commerce, and customer care.

Examples of enhanced services include features such as reformatting. For example, an enhanced service can reformat a data request from one system so that it can be accepted by a second system; the information is reformatted with reference to the stored information so that the reformatted information may contain information that is unavailable to the originating device.

FIG. 1 is a block diagram of an exemplary system that utilizes a converged communication platform. As shown in fig. 1, the customer connects via his/her input 10 to a vendor (i.e., service provider) service device 50 through device IP 21, wireless device 23 or telephone system access device 25, and internet 22, wireless network 24 or public switched telephone network 26. The vendor service device 50 then connects to the convergent communications platform 100 via a payment request 52. The convergent communications platform 100 then returns the payment authorization 102 to the vendor service device 50. The vendor service device 50 can then deliver or confirm delivery of the service/good 11 back to the customer input 10.

In such an exemplary system, a customer wishing to conduct mobile commerce can quickly and efficiently receive the services/goods he desires. For example, if a customer wishes to purchase an MP3 file from an electronic music vendor, the transaction may proceed in the following manner.

A customer operating customer input 10 attempts to connect to a music vendor via vendor service device 50. The client input 10 may be connected to any of the IP device 21, the wireless device 23, or the telephone system access device 25. The IP device 21 may be a network card, WAP connectivity device, SMS messaging device, or any other now known or later devised device for connecting to an internet protocol network.

The wireless device 23 may be a mobile phone, a cellular phone, or any other device that uses radio waves or electromagnetic energy to communicate with the wireless network 24. The telephone system access device 25 may be a modem, router, cable modem, or any other device capable of connecting to the public switched telephone network 26.

The internet 22 may be any combination of switches, routers, hubs, microwave devices, or other communication devices capable of transmitting internet protocol messages from one point to another. The wireless network 24 may be any system of radio towers and switches and other devices that enable the wireless device 23 to connect to the vendor service device 50.

The public switched telephone network 26 may be any combination of circuit switched, packet switched or other suitable device for accessing the telephone system to the vendor service device 50.

If the customer input 10 is a wireless device 23 and connects to the vendor service device 50 via the wireless network 24, the vendor service device 50 may be a Morse or digital identification system so that the customer input 10 adequately describes a request to purchase the MP3 file from the vendor service device 50.

Vendor service device 50 may be any combination of a Web server, voice server, SMS messaging server, or Wireless Access Protocol (WAP) server capable of mobile commerce and delivery or confirmation of delivery of services or goods to customer input 10. The vendor service device 50 receives the customer request for the MP3 file and generates a payment request 52. Payment request 52 is sent to convergent communications platform 100.

The convergent communications platform 100 then determines whether the user or customer is an authorized user, whether the user's account is authorized to conduct this type of mobile commerce, and whether the customer's account has sufficient money or accounts to conduct the service. If the user account has the correct authorization and account, the convergent communications platform 100 generates a payment authorization 102 and sends it back to the vendor service device 50.

The vendor service device 50 then generates a service or good, in this example an MP3 file, and sends the MP3 file to the customer network or customer input 10 via any of the Internet 22, the wireless network 24, the public switched telephone network 26, or any other delivery network.

In various exemplary embodiments, the above steps may be performed automatically by the system to a greater or lesser extent. In a fully automated environment, the customer input 10 may be an MP3 player connected to the wireless network 24 via the wireless device 23, which may automatically send authorization or routing data to the vendor service device 50. All the user needs to do is therefore open the device and select the new PM3 file he wishes to purchase. The device then automatically connects to the MP3 vendor and displays the song list for purchase by the user. The user may then simply select the song he wishes to purchase and then start downloading the song, in which case all other independent tasks are in progress.

In another exemplary embodiment, additional security for authorization and payment of service/merchandise requests may be utilized through the use of personal identification numbers (pins), smart cards, magnetic read/write devices, bar codes, magnetic strips, raised alphanumeric characters, or any other anti-fraud method now known or later developed or described with reference to FIG. 27.

Fig. 2 is a block diagram illustrating an exemplary system for utilizing converged services devices in mobile (m) or electronic (e) commerce. As shown in fig. 2, customer input 100 sends a service request 105 to vendor service device 110. The vendor service device 110 then sends an authorization request 115 to the convergent services device 200. The convergent services device 200 then sends an authorization grant 125 to the vendor service device 110 and a payment notification 135 to the customer input device 100. The convergent services device 200 then sends the payment 150 to the vendor's bank or financial institution 140 and sends the payment 155 to the carrier 150.

In the present exemplary embodiment, the customer requests a purchase of a movie ticket via his input device 100. The customer may turn on or activate his/her customer device 100 such that the service request 105 is sent to the vendor service device 110. The vendor service device 110 can be any now existing or future invented device for voice recognition or digital translation that enables a user to select a particular movie ticket for a particular movie theater he/she wishes to go to. Further, the vendor service device 110 can work for any known business, not just movie tickets. For example, concert tickets or other items may also be purchased.

After the user enters the service request 105 into the vendor service device 110, the vendor service device 110 can generate an authorization request 115. The authorization request 115 may include information such as a customer ID, service cost, and vendor Identification (ID).

When the convergent services device 200 receives the authorization request 115, it may prepay the account for the user in association with the user ID, check if the account is authorized to purchase movie tickets, and check if the customer account has a sufficient balance. If the account has a sufficient balance, the account is authorized to conduct the transaction, and the account is a valid account, the convergent services device may send an authorization grant 125 to the vendor service device 110 and a payment notification 135 to the customer input device 100.

The customer can then take a movie ticket from the movie theater by any method now known or invented in the future. For example, the user may enter a dispenser identification number and simply cause the dispenser to dispense a movie ticket. Other methods known in the art may also be used, for example: federal express delivery, entry of authorization codes into pre-existing machines, and in person pickup to vendor representatives are common methods in the art.

In various exemplary embodiments, the convergent services device 200 may not send payment to the vendor service device 110. The convergent services device 200 may send payment to a bank or financial institution associated with the vendor 140. Alternatively, the convergent services device 200 may simply authorize transfers from a bank or financial institution associated with the customer or user to a bank or financial institution of the vendor 140. In addition, the convergent services device 200 may authorize payment to a carrier 160 that can later perform the delivery.

Fig. 3 is a block diagram illustrating an exemplary system that enables prepaid roaming with a convergent communications platform. In fig. 3, the area 310 contains therein a customer 1, a customer 2, a telephone exchange a, a service manager a, and an account manager a. The account manager a includes customer accounts for customer 1, customer 2, and customer 3. The area 320 has therein a customer 3, a customer 4, a telephone exchange B, a service manager B, and an account manager B. The account manager B includes customer accounts for customer 4, customer 5, and customer 6. The area 330 contains therein a customer 5, a customer 6, a telephone exchange C, a service manager C, and an account manager C. The area 310, the area 320, and the area 330 are connected through a public switched telephone network 300 and a Wide Area Network (WAN) 350.

The use of wide area network 350 has a secure channel for account information to enable prepaid roaming. Thus, if all customers 1-6 are prepaid customers with their accounts in either zone 310 or 320, then the present exemplary embodiment enables them to use their prepaid accounts regardless of the zone. Various examples will be described below.

Prepaid roaming can work in the manner shown in the following steps. Customer 1 in area 310 who wants to call customer 2 in area 310 activates his/her device. When the device of client 1 is activated, telephone exchange a takes the signal and forwards the service request to service manager a. Service manager a then checks with account manager a that customer 1 is a valid customer and that there is an account balance or credit remaining in his/her account. Service manager a also checks that customer 2 is a valid customer with an account balance or credit remaining in his/her account to receive the telephone call. Service manager a completes the call after determining that all account information is correct.

However, a problem arises if customer 1 in area 310 wants to call customer 3 in area 320 under existing systems. Customer 1 activates his/her device and enters the identification number of customer 3. The telephone exchange a then receives the service request and forwards it to the service manager a. Service manager a then checks that client 1 and client 3 are valid clients and attempts to complete the communication. Then, the service manager a attempts to reach the client 3 through the telephone exchange a and the public switched telephone network 300. However, on telephone switch B, since customer 3 does not have an account on account manager B, telephone switch B does not have authorization to complete the telephone call.

However, in various exemplary embodiments of the present invention, telephony switch B forwards the service request to service manager B (which will be aware that customer 3 does not have an account with account manager B) and thus forwards the request to service manager a over wide area network 350. Then, the service manager a verifies that the customer 3 is a valid user, and that there is an account left on his/her account. Service manager a then authorizes the call to service manager B through wide area network 350, which tells telephony switch B to complete the call. If customer 1 or customer 3 runs out of money or account balance during the telephone conversation, service manager A sends a signal to telephone switch A or to service manager B via wide area network 350 to disconnect the telephone conversation.

In existing systems for prepaid telephone service, if customer 1 wishes to contact customer 4, customer 1 activates his/her device to contact customer 4. The service request is received by telephone exchange a, which then sends a signal to service manager a authorizing the service if customer 1 prepaid account in service manager a is alive. The service manager a will then authorize the service, since the receiving customer 4 is not part of its account or its network. Telephone exchange a then forwards the service request to telephone exchange B via public switched telephone network 300. The telephone exchange B then checks that the customer 4 is in its area and checks with the service manager B that the customer 4 has an account. The service manager B checking with account manager B will verify that the customer 4 is a current account holder with a remaining balance. Service manager B then authorizes telephone switch B to complete the telephone call, and can then contact customer 4.

However, if customer 1 in area 310 wishes to reach customer 5 in area 330, the existing system cannot do so for reasons detailed below. However, in various exemplary embodiments of the present invention, client 1 activates its access device in an attempt to call client 5. The telephone exchange a receives the service request and sends an acknowledgement request to the service manager a. Service manager a then checks with account manager a that customer 1 is a valid customer with the remaining balance and that customer 5 is not a customer within his network. The telephone exchange a then forwards the service request via the public switched telephone network to the telephone exchange C, which owns the customer 5 registered in its area. The telephone exchange C then connects to the service manager C, which will verify that the customer 5 does not have an account in the account manager C. Service manager C then requests account manager B to authorize the communication over wide area network 350. When service manager B authorizes the communication after checking that client 5 is a valid client with a remaining balance within account manager B, telephony switch C authorizes and completes the telephone call between the clients.

Several scenarios can be summarized as follows.

Case 1: both client 1 and client 4 are within the home network. Customer 1 dials to customer 4.

1. Customer 1 dials customer 4.

2. Since customer 1 is a prepaid subscriber, telephone exchange a routes the signal to service manager a.

3. Service manager a routes the signal to account manager a.

4. The account manager a recognizes that the personal identity of customer 1 belongs to the home network, the DNIS (MSISDN of customer 4) does not belong to network 310, and the call is originated from network 310.

5. The service manager a authenticates the customer 1 and responds to the telephone exchange a.

6. Telephone switch a sends the call to telephone switch B via the Public Switched Telephone Network (PSTN).

7. The telephone exchange B receives the call via the PSTN network and routes a signal to the service manager B indicating that the customer 4 is prepaid.

8. Service manager B receives the signal and authenticates customer 4 through account manager B.

9. Service manager B sends a MAP query and locates serving telephone switch B for customer B.

10. The service manager B sends a paging signal to the telephone exchange B.

11. The telephone exchange B starts paging the client 4.

12. When client 4 responds to the call service, service manager B starts billing client 4 and service manager A starts billing client 1.

Case 2: client 4 is in its home network and client 3 roams in the home network of client 4 and client 3 dials to client 4.

1. Customer 3 dials customer 4.

2. Since the customer 3 is a prepaid subscriber, the telephone exchange B routes the signal to the service manager B.

3. Service manager B routes it to service manager a.

4. Service manager a identifies that client 3 belongs to network 310 and client 4 does not belong to network 310.

5. Service manager a authenticates customer 3 and routes the signal to telephone exchange B.

6. The telephone exchange B routes a signal to the service manager B indicating that the customer 4 is a prepaid subscriber.

7. Service manager B authenticates customer 4 as belonging to network 320 through account manager B and sends a MAP query to locate the serving MSC for customer 4.

8. The telephone exchange B replies and is instructed to make a call.

9. The telephone exchange B starts paging the client 4.

10. When client 4 responds to the call, service manager B starts charging for client 4 and service manager a starts charging for client 3.

Case 3: both client 5 and client 3 are roaming and client 5 dials to client 3.

1. Customer 5 dials customer 3.

2. After verifying the IMSI (or other such unique identification code) of the customer 5, the telephone exchange C determines that the customer 5 is a prepaid subscriber and routes the signal to the service manager C, which in turn routes the signal to the service manager B.

3. Service manager B recognizes customer 5 as a roaming user and authenticates it by querying account manager B.

4. Service manager B replies to service manager C that client 5 is active and further routing is possible.

5. The service manager C routes the authentication to the telephone exchange C.

6. The telephone exchange C routes a signal indicating that the customer 3 is a prepaid subscriber to the telephone exchange a via the PSTN.

7. Service manager a authenticates customer 3 and sends a MAP query to locate the serving MSC for customer 3.

8. Service manager B replies to service manager a, which forwards the routing information to telephony switch C.

9. Telephone switch C routes the call to the serving MSC, telephone switch B.

10. The telephone exchange B starts paging the client 3.

11. When client 3 responds to the call, service manager A begins to bill client 3 and service manager C begins to bill client 6.

12. When either party disconnects the call, service manager C updates account manager B via the WAN.

FIG. 4 is a block diagram illustrating an exemplary embodiment of a generic or network-independent customer service system. In fig. 4, a customer 400 accesses the public switched telephone network or SS7 network 410 via path 414 to contact a service manager ("SM") 420. Service manager 420 may be connected to an account manager ("AM") 442, an account manager 444, or an account manager 446 over a wide area network ("WAN") 430. Service manager 420 can then reroute customer 400 using path 412 to connect customer 400 to any of carrier/vendor 1 at 462, carrier/vendor 2 at 464, or carrier/vendor 3 at 466, which may then access the appropriate account manager 442, 444, or 446 to provide the customer with his/her customer care service. The account manager 442 may be connected to customer information in database 452 or database 454 via the wide area network 430 or to customer information in database 456 through the wide area network 430. Thus, a customer can request customer care services with a telephone number, regardless of where the customer is actually located.

Fig. 5 is a block diagram showing each operator operating multiple switches within its home country (home geographic region). Each operator joins international roaming services based on a centralized roaming data center model. The data center may be managed by one of one or more telephone companies or a third party. As shown in fig. 5, operator 1532, operator 2534 and operator 3536 are within country a 530 and are connected to both WAN or TCP/IP network 520 and PSTN & SS7 network 510. In turn, operator 4546, operator 5544 and operator 6542 are within country B540 and are connected to WAN or TCP/IP network 520 and PSTN & SS7 network 510 simultaneously. Both WAN or TCP/IP network 520 and PSTN & SS7 network 510 are connected to international roaming data center 500. The international roaming data center 500 may include a server 502, a server 506, and a server 506.

Each of the servers 502,506, and 506 described above may be used to authenticate clients and route service requests. Thus, fig. 5 illustrates that the service manager and account manager described above may be located anywhere, not necessarily within the call area of the home network. The network may be GSM, CDMA, TDMA, AMPS, DAMPS, or any other network standard, including 2.5G and 3G. Several SM/AMs can (but need not) be run on one switch for routing messages to a particular convergent communications platform. The switch to the exemplary convergent communications platform system is optional, and the address may be local to the international roaming data center if the switch is installed. Otherwise, the address must be an international address.

Customer care for roaming customers may be handled entirely in the manner described above. However, for large-scale implementation by many operators across many countries, it is impractical for each participating telephone company to have call control equipment (switch manager servers) set up at the site of all its switches. All participating telephone companies utilize the customer account management and service support system (account manager) to manage their respective subscribers, create/manage their billing schemes, and provide the switching manager with the IMSI/MSISDN (unique subscriber identification number) used to identify and bill each customer call. Depending on the business situation, the account manager may or may not be distributed.

Fig. 6 is a block diagram illustrating a centralized account manager 672. In one example, one account manager can be provided in a centralized fashion to several telephone companies. In another example, multiple account managers may also be deployed in a highly distributed fashion, each account manager being provided to a particular telephone company, and any combination thereof. As shown in fig. 6, user 615 may be connected to a cellular telephone switch 678 via radio or a cellular tower 690. Cellular telephone switch 678 is connected to PSTN 650 and switch manager 674. The switching manager 674 is connected via a network to an Interactive Voice Response (IVR) server 686, a Simple Message Server (SMS)684, a voicemail server (VMS)682, a Network Account Service (NAS) unit 680, a firewall 676, an Account Manager (AM)672, and a Catalyst hub 640. The IVR server 686 is connected to a consultation station 688. The AM 672 is connected to a database 670. The Catalyst hub 640 is connected to an access server 628, an IVR server 632, an e-mobile portal commerce server 630, a proxy server 626 and a security server 624. Home/office users 610 are connected to the internet 600, which is connected to the PSTN 650 and site router 620. Site router 620 connects to proxy server 626 through firewall 622.

Thus, the convergent communications system shown in fig. 6 enables an international roaming data center to be used and accommodate various specific servers to provide services. For example, NAS unit 680 may be designated as a fee calculation server. Other modifications and arrangements for accommodating various business practices are also included without departing from the spirit and scope of the invention.

Thus, the switching manager may be centralized within an International Roaming Data Center (IRDC). Each participating network may be connected to the central switching manager via a signaling link (SS7, etc.). Assuming this is possible, each participating network operator only requires one instance (instance) of a service manager running within the IRDC to manage the operator's roaming traffic. Several service managers may be deployed on one server, or each instance may run on its own dedicated server, or a combination of the cases where one service manager server acts as a backup/backup to the other service manager servers.

The SM assigned to each operator can combine the activities of each SM described in the roaming section above. Individual MSCs within each carrier region will identify callers, verify that their home networks are partners participating in roaming, assign MSRNNs to them, and so on. However, when the MSC switches the signal to SM, the control traffic is not only switched to the switch room, but also switched from the international SS7 network to the IRDC. The SM identifies the call origination point and it can determine the caller's home location. The SM then handles authentication, charging according to the originating switching network code (and originating cell ID, etc.), and the appropriate charging tables for the MOC and MTC portions of the call.

Inter-operator settlement is handled in the IRDC as described above. Real-time, daily, weekly or monthly settlement of net revenue is managed and effected based on rules for revenue allocation. The exemplary convergent communications platform handles calls over a multimodal network in the following manner:

SM & AM can be set up for multiple network types; network-specific information for GSM, CDMA, TDMA, AMPS, etc.; signaling parameter control information; information specific to user authentication; and communication protocol information.

2. Roaming agreements and rules for relationships between operators are made to conduct service and business transactions: cost per unit, surcharges, tax, etc., settlement format, period, account information, etc.

3. User establishment: service profile information including available network types for roaming and user identification information for each network type.

4. The call may be handled in the following manner:

SM receiving incoming call signals

b. The network type is identified.

c. The information (i.e., the unique identification code) required to check the network type.

d. It is checked whether the call is a home or visited network call.

e. The appropriate parameters required for that network type are used to generate a signal to the home network.

f. The user/subscriber returned to the visited network is authenticated and service validation from the user service conditions is confirmed.

g. The call is rated (checked for balance, confirmed availability) from the visited network type to the user account.

h. If the balance runs out or the call terminates: and the SM confirms termination, and sends the post-transaction information to the home network database for settlement.

As services may become more competitive, mobile operators worldwide are seeking ways to provide various value-added services to customers on their home networks, such as data, fax, simple message servers, and mobile commerce. Also, these value added services are increasingly being offered to postpaid roamers. Mobile operators also would like to offer these services to their prepaid roaming subscribers, but limited by their operator-specific equipment and systems.

Fig. 7 is a block diagram illustrating a mobile network 710 with a phone management system 720, an SMS service management system 722, a fax service management system 724, a data service management system 726, and other "XYZ" management systems 728.

Some of these services that are charged to the customer may be time-based, while other portions may be event-based. In a practical deployment, it may or may not be possible to control the authentication/usage of all value added services over the signalling link. Telephony services may be controlled through signaling links; however, for services such as fax, SMS, mobile commerce, it is not feasible to control the authentication/use over the signalling link.

For telephone companies or other communications carriers that offer such value-added services to prepaid roaming users, some interface must be established where usage records are collected and processed at frequent intervals (e.g., every minute or every five minutes). However, given that high value transactions may occur, the business services need to be processed in real time as the transactions are conducted.

Fig. 7 illustrates how an exemplary embodiment of a convergent communications platform system manages the use of such value-added services for prepaid roamers. Mobile network 710 has access to phone management system 720, SMS service management system 722, and fax service management system 724, data service management system 726, or XYZ service management system 728. Phone management system 720 can access phone charges 740, and phone charges 740 can then connect to a convergent communications platform prepaid account and balance 750. An SMS service management system 722, a fax service management system 724, a data service management system 726, and an XYZ service management system 728 can be connected to the gateway 730 to access enhanced data services billing 742 for SMS, enhanced data services billing 744 for fax, enhanced data services billing 746 for data, and enhanced data services billing 748. Enhanced data services billing for SMS 742, enhanced data services billing for fax 744, enhanced data services billing for data 746, and enhanced data services billing 748 can connect to the convergent communications platform prepaid account and balance 750.

Before the value added service is authorized, an external system (i.e., the system that is providing the value added service) issues a request to the exemplary convergent communications platform system through the gateway 730. Details of an exemplary convergent communications platform system are not shown in fig. 7, but are described and/or illustrated herein. The exemplary convergent communications platform system either authorizes the transaction or denies the transaction to external systems via network 730, depending on the billing tables, available account balances for the prepaid accounts, and permitted service profiles. For each authorized transaction, the external system provides value-added services to the prepaid roaming customer. At the end of use (or at the end of a preset amount of time), the external system generates an Enhanced Data Rate (EDR) that is sent to the exemplary convergent communications platform system over network 730. The exemplary convergent communications platform system initiates an EDR billing process for each such record and processes the EDR and updates the customer account balance information in the exemplary convergent communications platform database.

It may be the case that a prepaid roamer may use one or more value added services while phone use is ongoing. In that case, the exemplary convergent communications platform system (to be further explained herein) will initiate a phone billing process for the phone usage. The exemplary converged communication platform also processes EDR using EDR billing tables, EDR rules, and processes simultaneously. To avoid any deadlock situations or significant balance overbooking, the exemplary convergent communications platform system establishes a preferential allocation of money for telephony services within the prepaid customer account (e.g., a number reserved for a certain preset period of use). In this architecture, the account balance of a prepaid roaming subscriber may go below zero due to the delayed registration of EDR records. This situation can be avoided by pre-allocating money for the value added service when the service authorization request arrives.

For example, a client makes a call from a visited network area. The exemplary convergent communications platform handles call billing according to the following:

1. the user calls in via IVR, walk-in, internet/mobile internet and any other means.

2. The exemplary convergent communications platform authenticates the user through a telephone number, a PIN or other information given by the user, or through a verification means that may be automatic or manual.

IVR locates customer home account.

The IVR sends a query to the customer home account to obtain account information and service profiles.

IVR analysis/processing of queries: the information service is processed by the CCC, service queries related to the account generate further queries to the home network through the exemplary convergent communications platform, and the top-up service is processed in the manner described below.

6. The customer then connects to the internet through the WAP services provided by the visited network and makes a purchase through the merchant's website.

7. For payment authorization, the merchant website (or any other service provider requesting authorization) is connected via an IP network (public or private network) to an exemplary convergent communications platform on the home network.

8. The convergent communications platform then verifies to the home network authorization database that the customer is authorized to conduct business transactions (service profile validation) and obtains the customer's location.

9. The convergent communications platform then issues a request to the convergent communications platform component that is handling the call on the visited network (these components may be located at the visited location in a distributed architecture).

10. The convergent communications platform issues requests via a public or private WAN link. In a centralized architecture, these components may be available locally.

11. The convergent communications platform issues an authorization request via the network.

12. When authorization passes, the exemplary convergent communications platform component (either in the home network or in the visited network depending on its type) submits the entire transaction to the home network database to ensure information consistency.

13. The exemplary convergent communications platform settles according to settlement rules.

Authorization requests can be of two types: type 1: saying what the current balance of the customer is; and preventing 'X' amounts of money from flowing to the commerce transaction ('X' value equals the number of merchant requests authorized by the request plus any service charges incurred by the home/visited network according to the roaming agreement). In this case the final authorisation is handled by the home network itself. Type 2: if authorized, process the business transaction and deduct the number of X ('X' is equal to the number requested by the merchant requesting authorization plus any service charges incurred by the home/visited network under the roaming agreement). In this case, it is the commercial billing process on the access network that processes the entire transaction and generates settlement records for further processing.

In another example, a local client a of network X has roamed into network Z. He needs to fill/recharge his prepaid account. An exemplary convergent communications platform may allow this to proceed in the following manner:

1. he can purchase the voucher from operator Z on the market.

2. He dials the IVR number of network Z.

3. The IVR system reading his MSISDN number determines from the network code that he is not a local subscriber.

4. Using the network ID, the IVR issues a query over the TCP/IP network to the LAUT database of network X, where it determines the airtime of customer a at the home network corresponding to the value of the purchased top-up voucher.

5. The LAUT database is then updated on the home network.

This process ensures that any money associated with a recharge is always forwarded to the home network even if it is recharged within any one of the visited networks. After a successful roaming call, the revenue charged by the exemplary convergent communications platform switching manager must be distributed among the cooperating networks according to their roaming tariff agreements.

The roaming tariff agreement may be stored in any one of several locations. The agreement may be stored on the convergent communications platform, on a separate billing server, or any other place where account settlement is supported. In addition, the settlement rules may be located on the convergent communications platform, on a separate billing server, or any other location determined by the parties to the agreement. Further, agreements may be made between operators of the convergent communications platform, companies trading with operators, customers, and governments.

After the end of any time period, typically once per day, all Call Description Records (CDRs) for the roaming Call are forwarded to the settlement process. Alternatively, a record of usage in an industry standard format (e.g., TAP/Cyber) may be established to forward information for settlement purposes. This may be part of each operator's back office or handled by a clearing house running in the Application Service Provider (ASP) model. The exemplary convergent communications platform is able to compare the revenues of each operator with respect to its partners and organize the resulting net transfers.

Although the preferred embodiment is for using a multidimensional database provided on a convergent communications platform, these transactions may be stored on or off the convergent communications platform. If the preferred embodiment is used, the multidimensional database may store all aspects of transactions as one dimension, with transactions settled at different times according to agreements between partner networks or vendors being in different dimensions. Also, the customer may select his long distance telecommunications carrier when access is available. In this case, the exemplary convergent communications platform will settle PSTN mobile terminated calls within the visited network with the long distance telecommunications carrier, rather than with a planned home long distance mobile network (home long distance mobile network). Also, planning a home long distance mobile network and planning a visited long distance mobile network can be planning a home mobile network and planning a visited mobile network (i.e. a roaming system or 3G network covering a global planning). The home network and the visited network may also be based not on GSM technology but on other mobile technologies.

The exemplary convergent communications platform system is capable of interfacing with a telephone company network to act as a prepaid roaming service management system. In addition, the exemplary convergent communications platform may also interconnect with merchant systems for managing commerce transactions. Settlement rules for each merchant and network partner are set on the exemplary convergent communications platform settlement system. An exemplary convergent communications platform controls payment transactions related to services provided or business transactions. According to the settlement rules, the exemplary convergent communications platform settles payments for all parties involved in the service and/or transaction according to the settlement rules.

For items such as volume discounts and bundled services, the exemplary convergent communications platform can register the appropriate information into a data table. The exemplary convergent communications platform analyzes this information on a regular basis (e.g., every minute, every day, etc.) and performs accounting for these services.

An exemplary convergent communications platform can be deployed at a central location and connected to a telephone company network, a merchant network, and a customer account system of a guarantor. The exemplary convergent communications platform allows dynamic interaction between a billing engine or meter for voice, data and/or events and a customer's prepaid account. Money may be transferred from the guarantor's customer account (any type of account) to the exemplary convergent communications platform customer prepaid account upon the user's selection (either every time a selection is made, or the system itself automatically selects according to user-defined criteria).

An exemplary convergent communications platform customer prepaid account is used for commerce and communications transaction payment processing. In the event that the customer balance runs out on the exemplary convergent communications platform account, the exemplary convergent communications platform account may be recharged according to the needs of the user, such as through a guarantor customer account within a bank mutual fund or the like. The exemplary convergent communications platform also allows for the simultaneous processing of business, communication and data transactions on one customer's prepaid account of the platform. The exemplary convergent communications platform also enables settlement of payments between parties involved in providing services and/or transactions to customers for each transaction.

For example, if john smith owns a bank account (BA001) and a convergent communications platform account (UP987), then john smith can link his bank account BA001 and his prepaid platform account UP 987. Of course, BA001 may be savings, check, debit, credit, or any other type of account. Further, the bank may be some other type of institution that is capable of funding a customer. According to bank-defined criteria, the bank agrees to act as a guarantor on behalf of john smith on a certain number of convergent communications platform account limits. For example, BA001 has $ 1500 on the customer account and the bank allows the convergent communications platform customer account limit to $ 100. The actual number on an exemplary convergent communications platform account may vary depending on several factors, such as: the crediting record of john smith, the number that john smith is willing to deposit on the exemplary convergent communications platform account, any terms and conditions specified by the telephone company, merchant group, local regulatory agency, etc. John smith may pay for any mobile commerce using the exemplary convergent communications platform prepaid account or for communications services using the exemplary convergent communications platform account, top up using an associated customer bank or guarantor account.

For example, in the event that the user runs out of his money within the convergent communications platform account, he may recharge his platform account from BA 001. He may also establish sub-accounts for convergent communication accounts (e.g., UP001, UP657, etc.) and use them for specific purposes (e.g., give his family with or without restrictions on the types of services they are allowed to perform, or use one account for online transactions and another for offline transactions, etc.). He may also set limits for each sub-account (budget control) or take the main account limit (convergent communications account) as the total free-flowing limit for all sub-accounts. In any case, the bank guarantee for customer payments is limited to the number of accounts assigned to the exemplary convergent communications platform.

Likewise, BA001 is not necessarily a single account and the quota of UP987 is not necessarily a fraction of BA 001. For example, BA001 may be a virtual account that combines all of the financial content of john smith (e.g., savings account, credit account, checking account, balance of current market value of all stock/mutual funds owned by john smith) and which may be considered the number of currencies arriving at BA 001. Likewise, the limit on the convergent communications account may be higher or lower than or equal to the number within the BA001 account.

An exemplary convergent communications platform may implement the following scenarios: authorization based only on the balance in the convergent communications platform account; authorization based on a balance within a convergent communications platform account, wherein the platform account is integrated with a customer account of an authorized guarantor to conduct real-time or near real-time transactions (checking balances and debits); and authorization based on a balance within the convergent communications platform account, wherein another mechanism guarantees a fixed number that is the basis for real-time authorization and real-time balance.

It may also occur in some situations/markets where there is no participation from the bank. In this case, the digital debit account may be issued by the merchant, or a group of merchants, or by the telephone company, or by a third party, or a combination of all and a portion of these entities. Digital debit accounts operate in a very similar manner except for accounts issued by parties other than the bank. In this case, the digital debit account issuing agent may or may not be a partner of the bank or financial institution.

The digital debit account is different from the electronic wallet being used on the market. Electronic purses only address issues related to payment. The purse is primarily focused on the number of money authorized. While the digital debit account allows for other aspects related to the customer (e.g., whether the customer is authorized to receive or purchase the service). Electronic wallets also do not address issues related to continuous time-based billing (e.g., telephone calls, billing for the downloading of music based on the number of minutes downloaded, etc.). A digital debit account takes these issues into account and allows for the correct calculation of the fee. That is, the e-wallet makes no decision on how much money to deduct from the e-wallet account (they are made from a third party). A digital debit account used within the convergent communications platform can make a decision on how much money to deduct.

An exemplary convergent communications platform can be deployed at a central location and connected to a telephone company network as a service node or intelligent network node. The exemplary convergent communications platform may also be connected to a bank's customer account system, or the customer's credit card system, or any third party system that allows online/offline convergent communications platform customer account recharge.

For a customer, an exemplary convergent communications platform account may be created with two sub-accounts. For example, one sub-account is used for online/real-time transactions, which may be used for communication services and/or for business services or both. Another sub-account is used for offline transactions. For example, if john smith's exemplary convergent communications platform account owns $ 50, he may own $ 40 account a, which is used for online/real-time transactions. John smith owns another sub-account B of $ 10. The $ 10 may be transferred to the user's read/write storage device (either a stand-alone read/write storage device or a telephone appliance functioning as a read/write storage device or any combination).

When john smith makes a phone call or downloads music on the internet or any such transaction that requires real-time billing, the exemplary convergent communications platform will use account a for payment, either automatically or upon user selection (pre-selection or selection upon user request). When john smith goes to the store and wants to purchase some coffee, or cola or newspaper or other such item that does not warrant an online/real-time transaction, the exemplary convergent communications platform will use account B automatically or upon user selection (pre-selection or selection upon user request). If the device allows online connectivity to the exemplary convergent communications platform at the merchant site, the exemplary convergent communications platform can update (in both directions) information related to the status of the transaction/customer.

If the balance in sub-account B is exhausted, the exemplary convergent communications platform allows the customer to transfer money from account A to account B (either according to user selection or by preset parameters). If john smith runs out of money in account B, he may also go to the merchant location (which has a device for updating the balance information on the read/write memory device) and top up his account. For example, if john smith goes to the store and pays $ 100, his read/write storage device is updated for the additional $ 100, and the next time he uses a merchant device that is online connected to the exemplary convergent communications platform system, the exemplary convergent communications platform will automatically update the information and allocate the new $ 100 to his prepaid sub-accounts a and B as required by john smith.

The exemplary convergent communications platform can be connected to customer account systems of telephone companies, merchant networks, and banks. The exemplary convergent communications platform allows customers to define various recharge standards according to a configurable rules engine for recharging. Such a rules engine allows a customer to define: various recharge modes (IVR, ATM, direct transfer, etc.) that the customer is allowed to use, various criteria that cooperate to specify whether it is time to recharge the account, and various criteria that cooperate to determine how much money will be charged to the customer's account. Thus, the convergent communications platform system can provide many services to its customer prepaid accounts through a gateway or other means.

Fig. 8 illustrates an exemplary categorized list of cost resolution for communication services using the convergent communications platform, system and method. Fig. 8 includes columns containing the type of charges, charge establishment, charge deduction, the number of home and visited networks due, and the basis for determining the charges. For example, a business transaction may require payment of a Mobile Originated Call (MOC) within the home network by a service tax rent and a top-up fee.

Fig. 9 is an exemplary method of recharging a prepaid customer account for a convergent communications platform, system and method. The method shown in fig. 9 is automatic top-up. However, other types of recharge are within the scope of the invention, the method comprising: an additional step of confirming the customer with the load, an additional step of confirming the load with the bank or a third party, and an additional step related to time or other variables. The method begins at start 900 and proceeds to 910 to determine if there are sufficient accounts in the customer's prepaid account.

In the step of determining whether there is sufficient credit in the account at 910, it is determined whether there is a monetary value in the account of the prepaid user. If there are not enough accounts in the account, the method continues to 920 to determine if a recharge rule has been established? . If there are sufficient credits in the account, the method proceeds to step 912 to authorize the service. If the method proceeds to authorize services step 912, then the method proceeds to end 950.

If the method proceeds to "charging rule established? Step 920, it is determined if the customer has authorized prepaid recharge of his account. If the customer has authorized automatic recharge of their account, the method proceeds to the step "recharge from? "930. If the customer has not authorized automatic replenishment of their account, the method proceeds to a denial of service step 922. If the method proceeds to denial of service 922, the method proceeds to end 950.

If the method proceeds to "top up from? "930," it is determined to recharge the account with any of a bank, credit, investment account, or pre-authorized loan. If the "top up from" action is from the bank, the method proceeds to e-commerce 932 with the bank. If the recharge is by credit, the method proceeds to e-commerce with the credit company 934. If the recharge is from an investment account, the method proceeds to e-commerce 936 with the investment company. If the form of the charge is by way of a pre-authorized loan, the method proceeds to electronic commerce 938 with the loan company. Regardless of the form of the recharge, the method proceeds to step 940. At step 940, the convergent communications platform charges the prepaid customer account and returns to step 910 where it is determined whether there are sufficient accounts in the customer's prepaid account.

As described above, a user may recharge their account from any of several sources. Recharge may be controlled by user selection or rules. For example, the user may pre-set a top-up with the first $ 5000 from the investment account and a subsequent top-up with the credit account. In addition, the user may authorize recharging based on various other variables, such as time, account balance, total recharge amount, and other factors. For each recharge account, an agreement is made between the convergent communications platform and the recharge institution, and between the recharge institution and customers of both the platform and the recharge institution. The agreement may be detailed to such things as refill speed, settlement time frames, notification of insufficient money from the refill mechanism, account balance notification, and other factors known in the art. Preferably, data related to the top-up account agreement, rules and procedures are stored within the account and/or service manager of the convergent communications platform.

FIG. 10 illustrates exemplary relationships between a franchisee 1010, a sales agent 1020, a user 1030, an external telecommunications carrier 1050, corporate and home accounts 1040, VMS users 1060, and a convergent services manager 1000. User 1030 may place an order or cancel an order and enter a personal identification number into convergent services manager 1000. User 1030 may then receive the service in return. In exchange for services received by the user 1030, the convergent services manager 1000 may issue payments from corporate and home accounts 1040. If the user 1030 wishes to recharge their account, he may go to the sales agent 1020. The sales agent 1020 can then recharge the account within the convergent services manager 1000 and receive a commission in return. The convergent services manager can then forward the account top-up to the corporate and home accounts 1040. The user may then authorize payment to the dealer 1010 in return for providing the service received by the user, using the recharged account. In addition, the external telecommunication operator 1050 can receive payment or authorization for services, such as forwarding services, and virtual phone number reconciliation (reconciliaion), and billing information updates to the convergent services manager 1000. Alternatively, VMS user 1060 can receive queries or payments, bills and letters, query responses, greeting letters, and payment reminders for maintaining voicemail information.

Fig. 11 is an exemplary embodiment of a convergent system for implementing mobile commerce in a roaming network. The user equipment 1130 connects to the roaming network 1120. The roaming network 1120 is connected to a convergent service provider 1150. Convergent service provider 1150 may be connected to internet 1100 and convergent service provider 1140. Merchants 1160 and 1170 may be connected to the internet 1100. Then home network 1110 may also be connected to convergent service provider 1140. Convergent service providers 1150 and 1140 are both structures that maintain a convergent communications system that has different service areas.

In operation, the user device 1130 may connect to the convergent service provider 1150 while within the roaming network 1120 to initiate a mobile commerce transaction. The convergent service provider 1150 then forwards the request for the mobile commerce transaction to the convergent service provider 1140 within the home network 1110. The convergent service provider 1150 may also be connected to the internet 1100 to contact merchants 1160 and 1170 to provide delivery of services to user devices 1130 or to confirm delivery of goods to user devices 1130.

FIG. 12 illustrates an example of prepaid roaming service activity according to an exemplary embodiment of the invention. A mobile phone prepaid subscriber, timm, located at location 1200 in italy 1210, whose home network 1212 travels to spain 1220 that owns the roaming network 1222. When in spain 1201, tim wants to recharge his prepaid customer account. Then tim at location 1201 contacts roaming network 1222 which establishes link 1224 to SS71240 and SS71240 establishes link 1242 to converged service manager 1250. The convergent services manager 1250 then sends tim's current account information to the roaming network 1222 via link 1244, SS71240, and link 1226. The roaming network 1222 can then contact bank 1232 in france 1230 to recharge timm's prepaid customer account within the convergent services manager 1250.

FIG. 13 illustrates an exemplary embodiment of information data and structure for a user account of a convergent communications platform. Customer accounts may include (but are not limited to): a home table 1300, a request information table 1310, and an authorization information table 1320. The family table 1300 may include (but is not limited to): home major number, title, first name, middle name, last name, address, telephone number, fax, email, remark, profession, recent billing date, number of deposits, credit limit, remaining credit limit, current balance, recent payment date, valid card, identity, and identity change date. The authorization information table 1320 may include: value, quarantine, active description, counter used, approved identity, most recently approved serial number, topology code and transferred to the ROC. Request information table 1310 may include (but is not limited to): an external code, a start string, a coverage area, a personal identification number, an initial activation code, and an identity.

FIG. 14 illustrates an exemplary embodiment of a customer account linked to a voicemail system for a convergent communications platform. Customer accounts may include (but are not limited to): client table 1400, voice mailbox 1410. Client table 1400 may include (but is not limited to): password, title, first name, middle name, last name, address, telephone number, fax, email, identity and identity change date, status ID, occupation, language ID, activation date, last billing date, current balance, last payment date, remark, and greeting message. Voice mailbox 1410 may include (but is not limited to): carrier name status and accepted import mailbox number. Voicemail system configurations may be added and include description, message group link (total message link), single message link, message age, cost, outdated surcharge, interest type, proportion (rate), expiration date, expiration start date, credit, and message group.

FIG. 15 illustrates an exemplary example of an interactive voice response system that may be used in a convergent communications platform. The method of fig. 15 begins at start 1500. The method then proceeds to 1510 where the prompt number 1 is played to the user. After the prompt number 1 is played to the user at 1510, the method transitions to wait number 1512. If a number is entered, the method proceeds to check number 1520 based on the number. In the check number 1520, if the number is a valid number, the method proceeds to 1530. If the number is an invalid number, the method returns to 1514.

At 1514, a determination is made as to whether the maximum number of retries has been reached. If the maximum number of retries has not been reached, the method proceeds to play a prompt 11510 to the user. If the maximum number of retries has been reached, the method proceeds to play prompt 41560.

In playing prompt 2 to the user 1530, it is determined whether it has received a number or reached the end of play. If the play prompt 1530 reaches the end of the play to the user, the method proceeds to a wait number 1532. If play prompt 1530 gets a number to the user, the method proceeds to 1540 where prompt 3 is played to the user. There is a wait time in wait number 1532 until it obtains a number. When the number is received, the method proceeds to 1540 where prompt 3 is played to the user.

Prompt 3 is then played to the user 1540 to determine if it has reached the end of the play or received the number. If the end of play is reached with play prompt 3 1540 to the user, the method proceeds to wait number 1542. If 1540, which plays prompt 3 to the user, receives the number, the method proceeds to check number 1550. In the check number 1550, if the number is a valid number, the method proceeds to register the short code and the actual number in the database 1570. Otherwise, the method goes to 1560 where prompt 4 is played to the user.

Fig. 16 is a flow diagram illustrating the use of prepaid accounts in a convergent communications platform for multi-party settlement. Prompt 1 can prompt the convergent communications platform to select the type of participant according to previously established rules. The participant type is then entered into select participant type 1610. The select participants type 1610 may be any of a company, family, distributor, or sales agent type. If the participant type is company, the method transitions to select company department 1612. If the participant type is a family, the method transitions to selecting a family 1614. If the participant type is dealer, the method transfers to select dealer 1616. If the party type is a sales agent, the method transitions to selecting a sales agent 1618.

Depending on the selected participant type, the appropriate type of ID is sent to view the payment 1600 for the outstanding and payable number of the participant code. Thus, the user may recharge or set up the prepaid account. Related information is stored on the convergent communications platform to view payments 1600 for outstanding and payable numbers of participant codes.

Prompt 2 payment method prompt the convergent communications platform to select a payment method according to previously established rules. In the selective payment method 1620, the type of payment method is selected from credit card, bank, and cash. If a credit card is selected, the method moves to enter credit card information 1640. If a bank is selected, the method moves to entering bank information 1622. The method then transfers to view the payment 1600 for the outstanding and payable numbers of the participant code.

Then, a check for payment 1600 of the outstanding number and the paid number for the participant code may proceed to any of am _ di _ info 1630, am _ home _ info 1632, dms _ dealer 1634, dms _ sales _ agent 1636, pp _ instr 1638, pp _ credit _ card 1640, pp _ pad _ trans _ main 1642, pp _ output _ payment 1644. Thereby settling the multi-party transaction.

Fig. 17 is an exemplary embodiment of a semi-automatic method for recharging a prepaid account and establishing rules for multi-party settlement that may occur within a convergent communications device. The method begins at start 1700 and proceeds to select a participant type and code 1701 or view a list 1710 of O/S payments.

If the method proceeds to view a list 1710 of outstanding and settled (O/S) payments, the method will determine the first or current due payment. The method then proceeds to select payment method 1720. In selecting a payment method 1720, the method will determine the type of payment based on previously established rules. If the rule is expressed as cash, the method transfers to cash 1722. If the rule is expressed as a check, the method transfers to check 1724. If the rule is represented as a credit card, the method moves to credit card 1726.

If the rule is represented as a check 1724, the method proceeds to an inserting bank 1725. If the rule is represented as a credit card 1726, the method moves to inserting credit card information 1727. After entering the appropriate information that has been previously stored on the convergent communications platform, the method proceeds to insert transaction record 1730. The method then proceeds to end 1740.

If the rule is expressed as a participant type and code, the method proceeds to step 1712. Then, in selecting the participant type and code, the method determines the type of participant that needs an account update. If the rule is represented as a company, the method moves to update company 1702. If the rule is represented as a family, the method moves to update the family 1704. If the rule is represented as a distributor, the method moves to update distributor 1706. If the rule is indicated as a sales agent, the method moves to update sales agent 1708. The method then proceeds to end 1740.

FIG. 18 illustrates an exemplary method for generating reports using a convergent communications platform and system. The method may begin with any of batch information 1820, print order information 1810, batch information 1830, print vendor information 1860, or all card types 1850. The method then proceeds to generate report 1800 and to preview report 1840. If the method starts with batch information 1820, the batch number unit rate and batch number need to be entered from a storage device on the convergent communications platform. If the method starts with print order information 1810, the PO number, PO status, and PO date need to be entered. If the method starts with batch information 1830, then a batch number and batch size need to be entered. If the method starts with all card types 1850, a credit card type description needs to be entered. If the method starts by printing vendor information 1860, the name of the vendor needs to be entered.

Fig. 19 is an example of data transfer within a convergent communications platform. As shown in fig. 19, user device 1900 may contain a data storage structure such as 1905 that contains end-user information, end-user account-enabled information, telecommunications information, billing data capture information, and user data capture information. User data storage structure 1905 may also contain communication device call control and billing control and data capture functions that are capable of communicating with communication device 1940 for payment, settlement processing, and customer care. Internet ISP 1910 may contain data structures 1915 containing information about the end user, the end user's enabled account, the ISP, billing data capture, and user data capture relating to advertisements and commissions. Data structure 1915 also contains modules for communication device radius control (radius control), usage control, and data capture, which communicate with communication devices 1940 for payment, settlement processing, and customer care. Portal 1920 can contain data structure 1925. The data structure 1925 may contain end user information, account access information, portal information, and account management information. Data structure 1925 may also contain modules for communication, device payment, vouching and data capture, which communicate with communication devices 1940 for payment, settlement processing and customer care. Merchant 1930 may contain data structure 1935. Data structure 1935 may contain information about the end user, shopping cart inventory within the enabled account, merchant, billing data capture, and user data capture. Data structure 1935 may also contain modules for communication, device payment, vouching and data capture, which communicate with communication devices 1940 for payment, settlement processing and customer care. Communication devices 1940 for payment, settlement processing, and customer care can communicate with data mining/Customer Relationship Management (CRM) 1950.

Fig. 20A is an exemplary method and system for multi-party real-time settlement of services and/or transactions made by customers with prepaid, top-up accounts using a convergent communications platform. The exemplary method begins with end user 2000 initiating the method. The method then proceeds to prepaid recharge 2010.

In prepaid recharge 2010, the user determines in advance, automatically, or when requesting services and/or transactions which other non-platform accounts and how large a number associated with each of these accounts is to be recharged into his prepaid platform account. The method then proceeds to real-time financial settlement 2050.

Real-time financial settlement 2050 receives payment requests from telephone company 2060, ISP 2062, portal 2064, merchant 2066 and bank 2068. Merchant management 2070 is a means for implementing real-time and direct financial settlement 2050. Merchant administration 2070 indicates that settlement of the participating parties is simultaneous, delayed, involves additional authorization, or any other feature known in the art. Thus, there are exemplary embodiments of a convergent communications platform that enables settlement of transactions involving multiple parties through multiple time schemes.

Fig. 20B is another exemplary method and system for multi-party real-time settlement of services and/or transactions using a convergent communications platform by customers with prepaid, top-up accounts. The method begins with end user 2000 initiating the method. The method then proceeds to prepaid recharge 2010.

In prepaid recharge 2010, the user determines in advance, automatically, or when requesting services and/or transactions which other non-platform accounts and how large a number associated with each of these accounts is to be recharged into his prepaid platform account. The method then proceeds to bank 2020. In bank 2020, the account is transferred from the bank into real-time financial settlement 2050.

Real-time financial settlement 2050 receives payment requests from telephone company 2060, ISP 2062, portal 2064, merchant 2066. Merchant management 2070 is a means for implementing real-time and direct financial settlement 2050. Merchant administration 2070 indicates that settlement of the participating parties is simultaneous, delayed, involves additional authorization, or any other feature common in the art. Thus, there are exemplary embodiments of a convergent communications platform that is capable of settling transactions involving multiple parties through multiple time schemes.

Fig. 21 is an exemplary embodiment of an account management device 2100 for use within a convergent communications platform. The account management device 2100 may own a user account manager 2160, SIM supply 2170, SIM issuance 2180, SIM order 2190, settlement 2150, voucher supply 2140, voucher issuance 2130, voucher order 2120, and PIN generation 2110.

Fig. 22 is a block diagram of an exemplary switching manager 2200 for use within a converged communication platform. The switching manager 2200 may include billing 2230, call control 2220, and balance 2210. The charge 2230 may be a real-time (or through various accumulations) charge for the cost of the requested service. Billing may also determine the surcharges or risks involved in a business transaction. Call control 2220 can track all simultaneous debits to the user's account and send a signal to the user or various third parties authorizing an additional amount to top up the user's account, or authorizing a top up to be performed, or terminating the call. Balance control 2210 can track the instant balance in the user account or issue an alarm when the user account reaches a preset level.

Fig. 23 is a block diagram illustrating an example of a business-to-business (B2B) converged communication system. As shown in fig. 23, company 12330, company 22332 through company x 2339 are connected to the convergent communications system 2300 via the internet 2310. Further, company a 2340, government 2342, utility a 2344, utility B2346, merchant 2348 and supplier 2349 are connected to the convergent communications system 2300 via the internet 2320. Convergent communications system 2300 may be connected to or integrated with virtual account 2302, general account 2304, and banking system 2306. Thus, a company, such as company 12330, need only have one connection to the internet 2310 in order to conduct business-to-business transactions with any of company a 2340 through provider 2349.

Fig. 24 is a block diagram illustrating another example of a business-to-business aggregated communication system. In fig. 24, user 2400 connects to bank 2420 via phone 2410, ATM 2412, WEB 2414, WAP 2416, and proxy 2418. Bank 2420 is connected to B2B gateway 2434. The B2B gateway 2434 is part of a converged communication system 2430 that also includes a converged communication device 2432. The convergent communications device 2432 connects to a telephone company or other corporate billing system 2440. Thus, user 2400 can use phone 2410, ATM 2412, WEB 2414, or WAP 2416 or proxy 2418 to deposit or transfer accounts, to transfer accounts between accounts, and/or to designate business-to-business transactions to the telephone company or company billing system 2440 using bank 2420. Additionally, as shown in fig. 24, bank 2420 need only have one connection to a convergent communications system 2430 for conducting business-to-business transactions with many different institutions.

Fig. 25 is a block diagram of an exemplary system for recharging a customer prepaid account within a convergent communications platform. In fig. 25, various devices such as ATM2506, ATM 2504, ATM 2502, ATM 2508, investment company 2530, bank 22520, and bank 12510 are connected to x.25 network 2500. The x.25 network 2500 is connected to a router 2549 as part of a convergent communications platform 2540. Convergent communications platform 2540 may include firewall 2544, account manager 2546, customer care 2548, and bank 32542. The account manager 2546 may be connected to a database 2547. Thus, a customer user may access their account within the convergent communications platform 2540 from any remote device, such as ATM 2506.

Fig. 26 is a block diagram of an exemplary system for recharging a customer's prepaid account using an interactive voice response system within a convergent communications platform. As shown in fig. 26, bank 1 host 2610 may be connected to any one of ATMs 2602 through 2608, telephone company 22640, telephone company 12630, and bank 2 host 2620 via x.25 network 2600. The convergent communications platform 2650 may also be connected to the x.25 network 2600. Convergent communications platform 2650 may include a router 2660, a firewall 2658, an account manager 2656, a database 2657, an interactive voice response system 2654, and an operator 2652.

Thus, a customer user connected to the convergent communications platform 2650 through the telephone company 12630 may have his request routed to the router 2660 through the x.25 network 2600. The router 2660 may authenticate the user using the firewall 2658 and determine whether the request should use the interactive voice response system 2654. The interactive voice response system 2654 can handle account recharge or if the customer is experiencing difficulty, the interactive voice response system 2654 can forward the call to the operator 2652. If the interactive voice response system 2654 is capable of handling account refills, the user transfers funds from the user's bank 2 host 2620 to the platform account manager 2656 using the X.25 network 2600 by speaking commands or entering numbers, which are recorded in the platform database 2657.

Fig. 27 is a block diagram of an exemplary security system for use by a convergent communications platform. As shown in fig. 27, a Personal Identification Number (PIN)2701 may be entered into the user device 2700. User equipment 2700 can include a Subscriber Identity Module (SIM)2702, an International Mobile Subscriber Identity (IMSI)2704, and an International Mobile Station Equipment Identity (IMSEI) 2706. User device 2700 can then forward any of these security required numbers to telephony switch 2730. The telephone switch 2730 may contain a Mobile Switching Center Number (MSCN)2734 and a Mobile Station Number (MSN) 2732. The telephone switch can forward any of the numbers or the identification code to the switching manager 2750. The exchange manager 2750 may contain a user account 2752 and an authorization module 2754.

The exemplary convergent communications platform allows for secure financial transactions (according to ISO 8583 or any such secure financial transaction protocol) that affect the actual top-up of a customer's prepaid account. The example convergent communications platform provides various interfaces that allow withdrawal of money from a third party system (e.g., the example convergent communications platform initiates a transaction to withdraw money from a customer's bank account system) or deposit of money into the example convergent communications platform system by a third party (e.g., the customer's bank account system deposits money into a customer's pre-paid account of the example convergent communications platform).

Thus, the exemplary convergent communications platform is immune to fraud from unauthorized users of credit and debit cards and merchant establishments in conducting normal commerce transactions. Thus, the exemplary convergent communications system methods and platforms can use existing or future invented device security systems for authenticating users of prepaid convergent communications platforms.

Fig. 28 illustrates an exemplary embodiment of multi-party settlement with a convergent communications platform as the clearing house. As shown in fig. 28, the clearing house 2800 may be associated with a bank 2840, a merchant 2820, an internet service provider 2830, and a customer 2810. Thus, in addition to being the only conduit for multiple services and transactions via a multimodal network, the convergent communications platform can also be the single conduit for multi-party financial settlement.

Fig. 29 is an exemplary screen shot of vendor, merchant, and service provider information for settlement within a convergent communications platform. As shown in fig. 29, various rules for interacting with and arranging settlement with various vendors, service providers, and merchants may be stored. For example, the exemplary convergent communications platform may store and display merchants, settlement conditions, settlement value, units for settlement, timestamps, currency, contract plans, expiration dates of contracts, and any other supplemental rules related to contracts. For example, Satyam Online wishes to settle an e-commerce transaction after receipt, which has a value greater than 5, which is the percentage of the cash in total receipt. In addition, the contract is valid from 11/23/2000 to 11/23/2000.

Fig. 30 is an exemplary screen shot of adding vendor/service provider/merchant information to a convergent communications platform. Com may have information such as contract, effective start date, effective expiration date, terms, payment mode, value, timestamp, merchant related to the merchant, terms, payment mode, value, timestamp, and saved information, for example, as shown in fig. 30.

Fig. 31 is an exemplary screen shot of adding details about a vendor/service provider/merchant to an exemplary communication platform. As shown in fig. 31, details relating to the merchant such as name, address 1, address 2, city, state, zip code, country, account number, base currency, base unit, bank name, bank branch, city where the bank is located, and notes relating to the merchant may be stored within the convergent communications platform.

FIG. 32 illustrates an exemplary rule repository (repository) for implementing complex rule settings within a converged communication system. The exemplary rule repository contains several tables. These tables may be referred to as rule master 3200, user 3210, service provider 3220, and service 3230. Each table may contain several fields with data relating to implementing various rule settings.

For example, the rule master 3200 may have fields for rule identifiers, time-based, day-based, date-based, quantity-based, percentage-based, location-based, user-based, service provider-based, service-based, recent transaction-based, and mortgage-contract-based. The rule identifier field may be linked to a user 3210 table and a service provider 3220 table.

The user 3210 table may have user identifier, service provider identifier, balance credit, number of uses, and rule list fields. The service identifier field may be linked to a service 3230 table. The service provider identifier field may be linked to a service provider 3220 table. The rule list field may be linked to the rule master 3200 table.

The service provider 3220 table may have service provider identifier, service identifier, access service provider, accounts payable, accounts receivable, and rule list fields. The service provider field may be linked to the access provider field and the user 3210 table. The service identifier field may be linked to a service 3230 table. The rule list field may be linked to the rule master 3200 table.

The service 3230 table may have service identifier, service type and tariff fields. The service identifier field may be linked to the user 3210 and service provider 3220 fields.

The additional tables may be part of the overall convergent communications system and method. Further, while the various tables and fields used within the exemplary rules repository use descriptive names, any name related or unrelated to the role of the field or table may be used. Additional fields may be used within each table, for example, a tracking field for keeping the date of the modification may be used.

Fig. 33 is an exemplary instrument capable of implementing a settlement process using the convergent communications system and method according to the preferred embodiment of the present invention. The whole system comprises: a convergent communications system 3300, a service provider 3340, and a financial institution 3380. After the transaction has been authorized and debited, the exemplary instrument shows one way to enable settlement when the service provider 3340 remains in an account within the financial institution 3380 and does not directly receive money corresponding to the services provided. While this is most common, money is transferred from one account to another account in one financial institution, there are other situations that can affect settlement.

Settlement begins with an account within the convergent communications system 3300, which convergent communications system 3300 is held in debit agreement with the service provider 3340 that provides the service. The convergent communications system 3300 may include a settlement service provider 3301. The settlement service provider 3301 may secure a data import/export 3302 that transfers information between the convergent communications system 3300, the service provider 3340, the financial institution 3280, and the data format repository 3310.

Thus, for example, the service provider 3340 can provide settlement rules to the settlement process provider 3301 through the data import/export 3302. The settlement rules may then be used to generate data for the data format repository or to provide transfer instructions to the financial institution 3380. Financial institution 3380 can then transfer accounts between institutions or accounts. For example, if the convergent communications system 3300 owns a user account hosted by the credit association 3384 and the service provider 3340 provides a service to be credited in its account within the bank 3382, the settlement process provider 3301 can simply provide an indication of the transfer to the financial institution 3380.

The service provider may be any one of telcos 3342, internet service companies 3344, merchants 3346, content providers 3348, or any other existing or future invented device organization for providing goods or services. Financial institution 3380 may be any of banks 3382, credit unions 3384, credit companies 3386, brokerage companies 3388, or any organization now existing or invented in the future for holding and transferring value.

Fig. 34 illustrates an exemplary method for recharging a prepaid customer account of a convergent communications system and method, according to several exemplary embodiments of the invention. The method shown in fig. 34 is a method of linear progression of questions (linear progression of questions). However, other various exemplary embodiments may include: synchronization questions (simultaneousquestions), contingent questions (continent questions), and questions for which no answer is determined. The method begins at start 3400 and proceeds to determine if the transfer will come from a savings account 3410.

If it is determined in the determination of whether the transfer will come from a savings account 3410 that the transfer will not come from a savings account, the method proceeds to a determination of whether the transfer will come from a credit card 3430. If it is determined in the determination of whether the transfer will come from savings account 3410 that the transfer will come from a savings account, the method proceeds to determine whether there is sufficient credit in account 3420. If it is determined that there are sufficient credits in the out-account, the method proceeds to transfer credits 3490. If it is determined that there are not enough accounts in the account, the method proceeds to determine if the transfer will come from credit card 3430.

If it is determined in the determination of whether the transfer will come from the credit card 3430 that the transfer will not come from a credit card, the method proceeds to a determination of whether the transfer will come from a stock account 3450. If it is determined in the determination of whether the transfer will come from a credit card 3430 that the transfer will come from a credit card, the method proceeds to determine if there is sufficient credit in the account 3440. If it is determined that there are sufficient credits in the out-account, the method proceeds to transfer credit 3490. If it is determined that there are not enough credits in the account, the method proceeds to determine if the transfer will come from a stock account 3450.

If it is determined in the determination of whether the transfer will come from a stock account 3450 that the transfer is not from a stock account, the method proceeds to a determination of whether the customer is allowed overdraft 3470. If it is determined in determining whether the transfer will come from a stock account 3450, the method proceeds to query which stocks 3460 the customer will sell. When the customer determines the number of stocks to be sold, then the method proceeds to transfer credit 3490.

If it is determined in the determination of whether the customer is allowed overdraft 3470 that the customer is not allowed overdraft, the method proceeds to determine whether the customer authorizes the recharge 3480. If it is determined in determining whether the customer is allowed overdraft 3470, the method proceeds to transfer credits 3490.

If the customer is determined to have authorized recharging in determining whether the customer authorizes recharging 3480, the method proceeds to determining whether the transfer is viable 3485. If it is determined that the customer does not authorize a recharge or that the transfer is not viable, the method proceeds to deny the transaction 3495. If the transfer is determined to be viable in determining if the transfer is viable 3485, the method proceeds to transfer credit 3490.

Each prepaid customer may formulate its own criteria for recharging in at least the following ways: (1) recharging from only a telephone (mobile or fixed), (2) from only a network (internet, mobile internet or any other type of public or private network), (3) recharging only when the customer specifically requires recharging (by IVR, network or walk-in or any other means), (4) automatically recharging from another specific account (bank debit or credit or any other type of account) when the balance falls below a certain value, (5) without recharging the account, using another account as a payment guarantee for the prepaid account, recharging several sub-accounts based on a preset limit from the main account, (34) recharging by periods (e.g., daily, monthly, weekly, etc.), (7) determining the number of recharges according to the criteria of use set by the user (e.g., looking at the use of the last seven days and recharging their average number), or the number of recharges should equal the highest priced transactions made in the last "x" days Value of (1), (8), a recharge rule according to a service provider, (9) a recharge rule according to a customer's "owner" (which may be one or a combination or more of two of a plurality of different service providers who "own" the customer and are able to indicate the rule to the customer), (10) a recharge rule according to a primary "account holder" rather than a sub-account holder (e.g., parent/child or rate-dependent rules), and (11) a recharge rule indicated by the owner of the device providing the recharge (i.e., phone, agent, ATM, POS, etc.).

These recharging methods may also vary between different types of devices, between different networks, between different recharging modes (IVR, agents, etc.), and according to rules within different countries or jurisdictions. Further, the modes, devices, networks, etc. may be combined to formulate different rules or allow different combinations or permutations to occur. For example, someone with a business account uses an IVR to add money from their cell phone to their phone from a business account for mobile commerce. Rules indicating how this is to be done and how much money can be added to the phone account may be regulated by legal restrictions on business in that country. The rules may be different when the same person uses the same rules and patterns, devices, etc. to recharge elsewhere.

Fig. 35 illustrates an exemplary method of authorizing a prepaid customer account for use in a convergent communications system and method, according to several exemplary embodiments of the invention. The method shown in fig. 35 is a method of linear progression of the problem. However, other types of developments are within the scope of the invention, including: synchronous questions, contingent questions, and questions for which no answer is determined. The method begins at start 3500 and proceeds to 3510 to determine whether the transaction is below $ 1.

In determining whether the transaction is below $ 1 3510, it is determined whether the transaction is below a minimum number, $ 1. If the transaction is above $ 1, the method proceeds to determine if the transaction is below $ 10 3520. If the transaction is below $ 1, the method proceeds to authorize transaction 3580. If it is determined in the determination of whether the transaction is below $ 10, $ 3520, the method proceeds to determine whether the transaction is below $ 100, $ 3540. If it is determined in the determination of whether the transaction is below $ 10, $ 3520, the method proceeds to determine whether the transaction is from Kless 3530. If it is determined that the transaction is from Kless, the method proceeds to authorize the transaction 3580. If it is determined that the transaction is not from Kless, the method transfers to whether the transaction is below $ 100, $ 3540.

In determining whether the deal is below $ 100 3540, it is determined whether the deal is below a set number, $ 100. If the transaction is above $ 100, the method proceeds to determine whether the transaction is local (within the home region) 3560. If the transaction is below $ 100, the method proceeds to determine if the transaction is for clothing 3550. If it is determined in the determination of whether the transaction is for clothing 3550, the method proceeds to an authorization transaction 3580. If it is determined that the transaction is not for clothing, the method returns to 3560 where it is determined whether the transaction is local. If it is determined 3560 that the transaction is non-local, the method proceeds to determine 3570 if there was any authorization of the pin within the last hour. If it is determined that the transaction is local, the method proceeds to authorize the transaction 3580. Finally, if it is determined that there has not been any authorization for the PIN within the last hour, the method proceeds to validate the PIN 3585. If it is determined that the PIN was authorized within the last hour, the method proceeds to an authorization transaction 3580.

Thus, for example, a company administrator goes to an OFFICE department store near work to purchase OFFICE supplies. The administrative staff has selected supplies and moved to the checkout station. The administrative person represents an exemplary point of invention (execution inventories point) where he wishes to use the service system of the OFFICE desk store to transfer money from a commercial operations account at the red company to the OFFICE desk account to pay for the selected supplies (rules: whether the store provides an exemplary point of invention for the service system, whether the clerk has information available to use the system, whether the transaction is part of an exemplary point of invention for the service system, whether something else is required in addition to the account number/PIN number). The clerk records the purchase and allows the administrative staff to enter the commercial account code (rules: whether the account code matches the string, number, letter required by the system) at the point of the server. The exemplary invention of the service system checks if the company's commercial account is a valid account by accessing the national bank account register (register) via the exemplary invention and exemplary gateway of the service system (rules: what bank and account are part of the exemplary invention of the service system and what is allowed to pass through the system).

The registry indicates that the company's business account is a valid account on the company and requires the administrator to enter a PIN number (rules: whether the person is a valid user, whether the person is entitled to spend money through the system, whether the PIN number matches the number on the file and what the limit is allowed). An exemplary invention of the service system notifies the clerk of the validity of the company's business account and then checks the company's business account to see if the account is valid and the account is able to receive payment (rules: whether the account accepts such payment, what the limit is). The clerk receives an authentication that the company's commercial account is valid and able to receive payment (rules: the clerk receives several options she offers to the administrative staff, including whether to include a receipt, whether to refer to an account, whether to pay some by cash/balance on account). The clerk also receives a notification that the PIN of the administrative person is valid and that the administrative person has certain purchasing power. The clerk provides the administrative staff with the amount to be transferred/paid from the company's business account onto the OFFICE department account. The administrative staff agrees to make payment. The exemplary point of the service system notifies the company (via an exemplary gateway) of the commercial account and OFFICE department account of the outstanding transaction (rules: when money is actually transferred, what the allocation between the parties is, when the allocation is made, what the information provided to the parties is). The transaction is processed (rules: timing associated with the processing) by the exemplary invention point and exemplary gateway of the service system. The administrative staff is provided with a receipt with a confirmation (rules: what the information on the receipt is, what other options are available). Confirmation is provided to the OFFICE department clerk (rules: what is the internal operation required for the clerk, whether there is a printout for confirmation, whether there is a number added to cash, payment, credit payment, other categories, etc.).

Thus, in an exemplary convergent communications system and method, transaction validation/authentication (either a communications service or a business transaction or a combination of both) may have several operations or checks to validate the availability of the user and the credit limit or prepaid money associated with the account. For various exemplary embodiments using communication access, internet or mobile/internet access, the confirmation that a commercial transaction (done at a physical store or on a network/mobile network) may be allowed is: customer validation based on PIN entry, validation of login based on password entry, validation based on phone related security features, a combination of all or a portion of the above, validation of whether a requested service/transaction is authorized for a particular customer prepaid account (service profile validation), validation of whether there is a sufficient balance in the customer prepaid account for the service/transaction (the balance may be in a precautionary account balance, or a credit account balance or any other type of real or virtual account associated with the customer prepaid account), validation based on a matrix between different numbers, between different service providers. For example, for different numbers, a bank may require only a 4-digit PIN for authorization, a telephone company may require only an address for transactions below $ 20, and a zip code and social security number may be required for any transactions above $ 50, and a credit card issuer may require the address, zip code, social security number, mother's maiden name, and account recent payments.

Further, the rules may vary depending on the particular authorization process. For example, if one cannot answer a question such as "what are your current addresses? "the rules for authorization may immediately become adding two questions that have been determined by the service provider to be important to its authorization requirements. If the person requesting authorization can answer both of these added questions, authorization is granted. If not, another question is asked or the person is placed in a queue for the in-person authorization request according to rules set by the service provider (bank, telephone company, merchant, or any other type of service provider). For example, a service provider may: asking for additional information from the user (e.g., mother's maiden name, date of birth, or value of a previous transaction made, or value of a previous bill, previous charges, or a match of personal questions and answers preset by the customer), asking for special passwords for high priced transactions (e.g., above $ 20) or large numbers of transactions (e.g., more than 15 transactions a day or more than 50 transactions a month, etc.). Thus, instead of simply rejecting the transaction, additional confirmation may be used, depending on the rules set by the customer or service provider. As can be seen from the above description, these rules are part of an interactive process based on a set of rules established by the customer or service provider, and for some transactions fraud can be prevented through interactive communication between the customer and the service provider.

For example, a client/user may establish: additional passwords for some types of transactions (e.g., purchase of airline tickets), additional information that would be required by the system when the value of the transaction is higher than in the case of the previous transaction group (e.g., date of birth, friend's name, special password) (e.g., ask for special password if the value of the current transaction is higher than 50% of the total price of the transaction in the last five days). The system may block some types of transactions (e.g., allow all e-commerce and m-commerce transactions except pornography or money transfers between countries where there is currency regulation) according to rules set by the customer/user.

Thus, as long as the prepaid balance is not below zero (in other words $ 20 overdraft is allowed), where the age of the requester is 60 years or more and the request is made outside of the banking hours, the rules specify that a $ 20 transaction to purchase a train ticket can be authorized. Thus, several exemplary embodiments may use criteria defined by economics, transaction type, requester, and time. Thus, the exemplary system may use three-dimensional rules, rules determined by artificial intelligence, a matrix of rules applied based on transaction-transaction or account. The rule matrix may look different, even for the same transaction, when there is cooperative participation from different service providers.

Further, as embodied in this document, rules may be based on an adaptive or economic basis. For example, the rules may be based on account balances; a recharge capability; the currency used; marginal rules and interest rates. (these rules may be referred to as algorithmic rule changes). Other rules may be based on customer conditions-for example: age, occupation, nationality, gender, address, financial records, criminal records, membership, transaction records, transaction status-for example: type of service, type of content, quantity requested, purchase of some category of product. The rules may vary depending on history, logic, fraud and security factors or merchant conditions (e.g. location, type, business network cooperation etc.) of any person in the chain (including service providers, merchants and customers),

further, the rules as embodied in this document may be based on "fuzzy" or high-level logic, such as artificial intelligence. For example, analysis of the customer's voice may be divided into acoustic shocks, tones, and accents to determine the volume level of the customer, which may therefore affect the decision to authorize the transaction. Artificial intelligence systems may also have learning capabilities that allow for decisions based on various past events for a particular individual customer (even if a single event cannot have any particular effect on the decisions made). For example, the system can analyze debit transactions over a period of a specified number of months and derive the person's spending behavior. When a request for a new transaction is issued, the system may grant the transaction if it substantially matches the purchase form. If not, the system can mark it as potentially fraudulent and make additional verifications. If the verification is done properly, the system authorizes the transaction and includes the transaction in the knowledge base to derive the person's new spending behavior.

As embodied in this document, the system may also have a learning capability that allows for the determination of various past events based on a client group (e.g., all teachers, all teenagers, all women older than 55 years old living in dallas, etc.). When a request for a transaction is issued, the system can analyze the purchase pattern and authorize the transaction if it substantially matches the group behavior pattern. For example, it may be the case that: a female aged 62 who belongs to a town of texas requests permission to download pornographic merchandise from a website in brazil, while her actual location is in indonesia. Since the transaction may be a potential fraudulent situation, the system may provide additional authentication.

As embodied in this document, the system may also have a learning capability that supports decision-making based on various past events for a particular individual customer (even if a single event cannot have any particular impact on the decision made). For example, the system can analyze transactions over a period of a specified number of months and derive the spending behavior of the person. When a request for a new transaction is issued, the system authorizes the transaction if it substantially matches the purchase pattern. If not, the system identifies it as potentially fraudulent and makes additional verifications. If proper completion is confirmed, the system authorizes the transaction and includes the transaction in the knowledge base to derive the person's new spending behavior.

One special feature of several exemplary embodiments is that the debiting occurs in real time. Thus, the service provider is protected from excessive customer overdraft when both charges arrive at approximately the same time. Furthermore, real-time debiting allows dynamic calculation of all charges, rather than a pure one-access charge. For example, a roaming telephone call can pay a roaming network based on the length of the call, rather than just a single roaming charge. This enables fraud prevention from several distinctive approaches.

All types of service providers have common problems in managing and controlling fraud. Fraud is one of the biggest threats to their business for service providers who are offering pure communication services, or business or financial services, or any other type of service. Fraud is generally defined as "lost revenue" for any reason. Traditionally, vendors and service providers have recognized this problem and have proposed a number of solutions that attempt to minimize fraud. The proposed solutions to date analyze potential fraud by understanding some underlying problems. These fundamental problems are: motivation-what the underlying purpose of fraud is (e.g., fraud, crime tendency, spacious behavior, etc.), means-what the nature of fraud is (e.g., telemarketing/voice service, etc.), patterns-what fraud methods in general (e.g., registration fraud, web surfing, impersonation, etc.) and methods-what specific fraud methods are (e.g., registration, roaming, etc.).

The methods used in each of the above cases may be generically categorized. The first is registration fraud (subscription burst) -when the user is involved in high usage but does not want to pay. The second is call sales fraud-when the registration is for selling calls to others using subsidies, but the registrant does not want to pay. The third is voice over service (PRS) fraud-in this way, PRS content providers themselves abuse the network by generating calls to their own PRS numbers to charge a commission; but avoids paying the operator for the generated call. The fourth is roaming fraud-roaming subscribers heavily use the network/service but do not want to pay. The last type of fraud is internal fraud-the employees of the service provider use what they know to tamper with the system to help others commit fraud.

Service providers throughout the world are constantly learning and understanding about the problems with different kinds of fraud and how to make sufficiently effective measures to detect, analyze, respond to and prevent fraud. One particular advantage or exemplary system is the ability to continually measure valid exemplary embodiment behavior and feed the results back to the system as a measure of improvement.

Today there are many fraud management systems in the market with different levels of technology. Service providers typically manage fraud by implementing these systems and multiple business processes. For example: obtaining a credit assessment from a credit assessment agent, actual confirmation of the customer and his residence, obtaining confirmation from other service providers that the person/institution has honored his payment obligations in the past, establishing a very complex collection process, password protection, enhanced IT security and establishing a more robust encryption algorithm.

In the communications industry, today's service providers prefer prepaid customers over postpaid customers due to the risks associated with various types of fraud. However, converting a postpaid customer to a prepaid customer does not eliminate fraud, but simply transfers the anti-fraud responsibility from one party to the other. The potential fraudsters, and regardless of who assumes anti-fraud responsibility. This therefore does not have a significant effect on fraud problems.

In the financial services industry, today's service providers prefer debit cards and smart card-based prepaid cards over credit cards due to some of these same factors. Exemplary embodiments of the present invention improve upon all of these systems by integrating convergent communications systems and methods into the authentication process using cellular phones, access to email systems, and other connections described in this document.

For example, a customer may use his phone, an internet appliance, any point of sale device, a credit card, debit card, or bank ATM to issue an authorization request for any two or more services (two or more communication services, commerce services, or a combination of communication and commerce services). Such a request would go through the normal fraud validation procedure of each service provider and if the result is positive, it is further validated by the exemplary convergent communications system and method for service composition. If, during validation, the request is suspected of being potentially fraudulent, the service provider may initiate a session (voice or data session) with the customer and perform additional validation. These verifications may be based on parameters set by the customer. For example, additional validation may be performed whenever a customer attempts to purchase an item above $ 25. Additional parameters set by the service provider may also be used. For example: any request above $ 25 should be additionally validated and any request by the customer to purchase goods/services while roaming should be additionally validated based on the home service provider and the visited service provider. Setting parameters based on the situation/category/usage may be used. For example: burst but unexpected number of authorization requests, burst but unexpected authorization requests from a remote location, and types of services not normally used by such customers.

Thus, as the use of sophisticated technologies increases and business processes continue to become complex, service providers worldwide are able to reduce potential fraud. The biggest challenges facing service providers today are: although they have established many rules and business processes, fraud is still a reality.

For example, the industry has recognized that the best way to reduce/minimize fraud is to control fraud attempts at the moment they are about to occur. Any request that has business impact may be potentially fraudulent. Thus, currently available anti-fraud management solutions focus on granting or denying requests according to a set of rules. These solutions are based on the assumption that any request that satisfies a set of rules is a good request and any unsatisfied request is fraudulent. However, in real life, a customer who meets all criteria may still be a cheat, while on the other hand, a customer who appears to be a cheat may actually be a good customer without the intent of fraud.

With the convergence of communications and commerce, multiple participants must be portable together to meet the single needs of the customer. Each service provider has an associated risk in dealing with fraud in their service offerings. Any convergent service aggregates the risks of all participating service providers. In effect, the composite fraud management capabilities of the composite service are the least common denominator (i.e., weakest association case) of the fraud management capabilities of each service provider. Thus, potential fraud increases as the number of service providers participating in providing the service increases.

Currently existing anti-fraud management systems do not address the problem of involving multiple parties. They are single service fraud management solutions with different levels of complexity. They do not provide a solution based on the synthetic risks associated with convergent services brought on by various service providers. The various exemplary embodiments described in this document can be used to reduce and eliminate fraud.

For example, fig. 36 illustrates an exemplary method of debiting a prepaid customer account for a convergent communications system and method, according to several exemplary embodiments of the invention. The method shown in fig. 36 is a method in which the problem linearly progresses. However, other various exemplary embodiments may include synchronous questions, contingent questions, and questions for which no answer is determined. The method begins at start 3600 and proceeds to determine whether the transaction is tax free 3610.

If it is determined in determining whether the transaction is to be tax 3610, the method proceeds to determining whether the debit will be transferred to the credit account 3630. If it is determined in determining whether the transaction requires a tax 3610 that the transaction must be taxed, the method proceeds to debit to government account 3620. When debiting to government account 3620 is complete, the method proceeds to scheduled settlement time 3690.

If it is determined in the determination of whether a debit will be transferred to credit account 3630 that the debit transfer need not be transferred to the credit account, the method proceeds to determine whether the transaction should include a shipment 3650. If it is determined in the determination of whether a debit is being transferred to credit account 3630 that the debit transfer should be transferred to the credit account, the method proceeds to 3640 where it is determined whether the debit should be instant. If it is determined at 3640 that the debit should be immediate, the method proceeds to a scheduled settlement time 3690. If it is determined that the debit need not be immediate, the method proceeds to determine whether the transaction should include a delivery 3650.

If it is determined in determining whether the transaction includes a shipment 3650 that the transaction does not include a shipment, the method proceeds to determining whether the debit should be split (split)3670 according to the passage of time. If it is determined in the determination of whether the transaction includes a shipment 3650, the method proceeds to determine whether the shipment should be paid for immediately 3660. If it is determined that the shipment should be paid immediately, the method proceeds to a scheduled settlement time 3690. If it is determined that payment for the shipment need not be made immediately, the method proceeds to determine whether the debit should be split 3670 over time.

If it is determined in determining whether the debit should be divided 3670 over time that the transaction does not have to be divided 3680 over time, the method proceeds to determining whether the debit should be electronic. If it is determined in determining whether the debit should be split over time 3670, the method proceeds to schedule settlement time 3690. If it is determined that the debit does not have to be split over time, the method proceeds to 3680 where it is determined whether the settlement should be electronic. If it is determined in the determine whether the settlement should be electronic 3680 that the transaction need not be electronic, the method proceeds to print settlement information 3695. If it is determined in 3680 that the determination of whether the settlement should be electronic that the debit should be electronic, the method proceeds to the schedule transfer time 3697.

For example, a consumer comes to an ATM and selects her department store and enters the account number of her retail department store Renner. Exemplary embodiment of the system the check is whether the store is a member of the system, whether the store provides payment through the system, and whether the account number matches (character/number) the number of the department store. The exemplary system can then use the gateway to contact the Renner department store database to validate the account number. The exemplary system can then check if the account numbers match. The customer may also use the PIN number to verify her identity and account. The exemplary system can then use the gateway to contact the Renner department store database to validate the account number with the Renner. The system may perform additional validation operations, checking the PIN number against the system's characters and the exact account number associated with the consumer. The system can then access the database and return the account balance to the consumer. The system can then check: whether the PIN number matches a PIN number in the department store record, whether an account is returned with the balance, and whether the account can use the exemplary system for further payment or clearing.

The consumer may then decide to pay off the portion of the Renner she owed with her credit card as a means of payment. An exemplary system checks: what the consumer wants to do and what the consumer can do. The exemplary system is capable of checking credit card balances within a banking system, and may not use a gateway. The system can then check: what the balance on the credit card is, what the overall credit limit is, what the difference between the credit limit and the balance is, if the balance is a positive number, the system may provide options to the consumer. The exemplary system then further verifies whether there is credit on the consumer's credit card. The consumer may then agree to pay a portion of her balance via a transfer from a credit card. The exemplary system can then check: what the consumer wants to do, how many numbers should be processed, how many numbers should be transferred and when the transfer should be made. The banking system can then be used to indicate that a transfer is to be initiated to actually transfer the money and check that the money has been received. The exemplary system can then check: the Renner and credit card companies require what checks and confirmations, and what receipt options the consumer wants. The consumer may then receive a transaction/payment receipt via the ATM showing the payment. An exemplary system can check: what information is needed on the receipt, what information the consumer further wants to see, and what choices are available for the consumer to choose from. The receipt may include a confirmation of the transaction. The transaction is then completed. The exemplary system can then check: whether the consumer wishes to do something else, and what to choose.

Thus, these rules are specific to when money is removed from an account (as opposed to credit after debiting). Thus, the rules may be based on rules according to the service provider, rules according to customer needs (which are likely to be rarely used), rules according to multiple service providers, rules according to the customer's "owner", rules according to the "primary" provider of the service (i.e., if one merchant sells a 20 dollar CD to a customer and the overnight shipping fee is $ 22, the overnight carrier may indicate when/how to debit), rules that change according to the financial institution's conditions, processes, procedures, rules according to different legal provisions, rules according to the customer's history, overhead limits, monthly average account balances, and rules according to preset agreements between any service providers.

Further, the rules may be immediate or may be commitments to later debits/later transfers, and the rules may be in possession of the combination over time. For example, 50% of the number may be immediately performed, while the remainder may be divided into two equal weekly debits. Thus, the debit need not be just a single payment, or an instant debit, it can be multiple debits that add up to the purchase price, it can be a monthly debit (covering "everything you can afford"), and other known ways of making up payments.

Further, not all value transactions necessarily involve the transfer of money. While value may be exchanged, various transactions may be: free of charge, interest in previously purchased items (e.g., frequent flyer miles), value of a monthly subscription service, or an exchange of goods or services that does not include money (e.g., goods credits). For example, free items may be provided that offer an agreement to purchase additional items within a specified period of time. Other exchanges may include: the MP3 file is gifted to access another MP3 file. Or they may access the map program whenever the customer deposits at a bank. The present exemplary system allows these types of exchanges within the exemplary architecture shown in fig. 32.

Fig. 37 illustrates an exemplary transaction settlement method for convergent communications systems and methods according to several exemplary embodiments of the present invention. The method shown in fig. 37 is a method in which the problem linearly progresses. However, other various exemplary embodiments may include synchronous questions, contingent questions, and questions for which no answer is determined. The method begins at start 3700 and proceeds to determine if there is any real-time settlement 3710.

If a real-time settlement is determined in any real-time settlement 3710, the method proceeds to transfer account 3715. In transfer account 3715, an instruction to immediately transfer accounts between accounts is given. The method then returns to determine if there are any date-triggered settlements 3720. Alternatively, if it is determined that there are no real-time settlements in any real-time settlements 3710, the method proceeds to determine if there are any date-triggered settlements 3720.

If it is determined that there is a date triggered settlement in determining whether there are any date triggered settlements 3720, the method proceeds to set date trigger 3725. In set date trigger 3725, the trigger is set to activate the transfer of funds on the set date. The method then returns to determine if there are any event-triggered settlements 3730. Alternatively, if it is determined in the determination of whether there are any date-triggered settlements 3720, the method proceeds to determine whether there are any event-triggered settlements 3730.

If it is determined that there is an event-triggered settlement in determining whether there are any event-triggered settlements 3730, the method proceeds to set event trigger 3735. In set event trigger 3735, the trigger is set to activate the transfer of funds on the set event. The method then returns to determine if there are any batch settlements 3740. Alternatively, if it is determined in the determination of whether there are any date triggered settlements 3730, the method proceeds to determine whether there are any batch settlements 3740.

If it is determined that there is a batch settlement in determining if there are any batch triggered settlements 3740, the method proceeds to add the transaction to the batch 3745. In adding transactions to the batch 3745, the transaction results are added to the list of transactions that will run the next time the batch is called. The method then returns to end 3750. Alternatively, if it is determined that there are no batch settlements in determining if there are any batch settlements 3740, the method returns to end 3750.

For example, if the transaction is a pure communication transaction and there is more than one communication service provider involved (e.g., roaming), the exemplary settlement module reviews the transaction, identifies the parties involved (e.g., service providers) and applies rules to settlement (e.g., real-time or delayed settlement, partner settlement tariff plan, discount on large orders, whether a portion will be paid to an authority, etc.) whenever the transaction (e.g., telephone call) ends. In accordance with these rules, the convergent communications system and method is also able to identify whether settlement must be completed within the exemplary system itself, or whether settlement must be conducted using an external agent. The convergent communications system and method will then apply these rules and derive settlement net information and reports. For external agents, this information is passed in a pre-agreed format (e.g., TAP record, pre-agreed ASCII text file, MXP record, CIBER record, or IPDR record, etc.).

In another example, the transaction may be a business transaction. The exemplary convergent communications systems and methods will follow the same process described above, but the rules applied may be somewhat more complex, as they must take into account all or part of the external service provider (e.g., a merchant may require express delivery to deliver goods, and some rules relating to physical delivery may not be real-time and sometimes some processes may not even be automated). Settlement rules may also be more complex (e.g., settlement values may vary by number, weight, etc.).

If the transaction is an aggregated transaction (business and communication), the exemplary aggregated communication system and method is a combination of the two types described above. The exemplary convergent communications system and method may also add further complexity to the rules in the sense of business settlement-based rules, some of which may be affected. For example, if a customer purchases $ 50 of a good within the visited network, the visited network may not charge the home network any air-roaming time fees. The home network may or may not pass this benefit to the end client.

The above method is derived from the following application example. During vacation, customer Jim is roaming in Washington, Columbia with his CDMA prepaid mobile phone. His home network is North Carolina Mobile (North Carolina Mobile), and he pays a monthly service fee of $ 50 for the "weekend time plan you can use anywhere" an 11you can use weeweeweekend minutes plan and anywhere on the home network. His home network charges an additional cost of $ 1 per call for roaming.

In Washington, Columbia, Jim is listening to the best golden program of Santana via the OrangeMusicStreamer music service he receives over the GSM network. He receives a Simple Messaging System (SMS) advertisement, marketing sony's new miniature digital CD player. He listens to Carlos Santana while watching the advertisement. A short list of CD player features is followed by an offer of 33% of the price of the list if the CD player is purchased within the next 15 minutes. He decides to click on the offer at a moment and is taken to the orangemesicsStreamer mobile services shopping website.

The Orange MusicStreamer website was developed by the Aether System. And manages the web site according to a contract with Orange. Aether receives compensation for this management, development, and design relationship in a number of ways. These remunerations include: (1) direct fixed price is charged for website development; (2) monthly management fees are charged for maintaining the website, providing services and the like; (3) the same fee of 2 cents is charged for each click received by any advertisement of the website; (4) charging a percentage of the cost of the product or service for each item sold due to the advertising utility of the website; and (5) the same fee of $ 1 is charged per customer service call offered on behalf of the Orange MusicStreamer.

Jim continues to listen to Carlos Santana while clicking on a few more screens on the mobile web site on the Sony CD player. He clicks to see pricing and availability. The web site provides him with two Orange MusicStreamer partners who he can purchase the product. He selects Amazoom on Electronics-R-Us and immediately goes to Amazoom mobile shopping website.

At Amazoom, gimer chooses to offer an easy payment plan for the CD player of $ 100 (the listing price is $ 150), and he chooses to pay with two payments (now pay $ 50 and pay $ 50 when the CD player is delivered). He clicks the prepaid button and chooses to use his convergent communications system prepaid account.

Amzoom packs Jim's new CD player in a FedExtra box and arranges Insurus to provide insurance for the packaging. FedExtra shipping costs $ Amazoom 5.00 and Insurus costs $ 0.50 total to secure the CD player.

Jim continues to listen to Carlos Santana on his prepaid phone while waiting urgently for a train to return to North Carolina. When he returns home, FedExtra delivers his CD player and his signature on the bill triggers a transaction value chain involving many service providers.

The following settlement transactions are conducted using embodiments of the system and method of the present invention:

	partner business	Type of transaction	Payment person	Selection of time	Number of
							Telephone company (home network service provider): north Carolina mobile phone	All-you-can-use monthly payment type service	From Jim via a bank account	In advance of each month	$ 50 per month
	Telephone company (home network service provider): north Carolina mobile phone	Roaming	From Jim	Real time	Each one of which isCalling $ 1 $
							Telephone company (visited network service provider): orange MusicStreamer	Number of minutes roaming on a network	From the home network	Real time	$ 0.02 per minute
	Telephone company (visited network service provider): orange MusicStreamer	Music service fee	From the home network	Real time	$ 0.03 per minute $
							The merchant: amazoom	Fixed number of	From Jim	Now pay $ 50, pay $ 50 after delivery	$ 100 $
	Shipping/express companies: FexExtra	Fixed number of	From Jim	Collecting $ 5 during transportation	$ 5 $
							Insurance company: insurus	Percentage of	From Jim	While in transit	$ 0.50 (0.25% of the purchase price)
	Telephone company partner 1 (developer and manager of mobile web sites): aether system	Same fee for clicking on advertisement	From OrangeVoice Stream	Real time	$ 0.02 per click on an advertisement
							Telephone company partner 1 (developer and manager of mobile web sites): aether system	Percentage of the sale price of the product	From Orange	Batch, monthly payments	0.25% of the purchase price
	Telephone company partner 2 (music service-Virgin)	Percentage of	From Orange	Batch, monthly payments	$ 0.005 per minute
							Telephone company partner 2 service provider (music commission clearing center)	Percentage of	From Orange through music services	Batch, monthly payments	$ 0.001 per minute
	Advertiser on the telephone company partner website: sony of the design reside in the sony	Click-based identity fee	From Sony to telephone company partner	Monthly payment, batch processing	$ 0.05 per click

The settlement portion of the exemplary convergent communications system and method controls how payments are routed and which accounts can be credited by the payments. These transaction settlement rules include settlement between accounts and from different accounts to multiple accounts. Thus, the exemplary system: allowing multi-party settlement of convergent service and communication transactions, allowing settlement rules to be set for each service and business transaction, and allowing settlement between: merchants (providers of goods/services, such as manufacturers, distributors or a combination of several of these entities), portals (mobile portals or other types of portals including e-commerce portals and the like), internet service providers (independent agents, or mobile operators, or portals), mobile phone companies (home networks, access networks, or both), virtual service providers (content service providers, or infrastructure service providers, or brand agents, or any combination thereof), bank/credit card agents or any other financial institution(s) involved in a business transaction), third party payment agents (such as business entities, payment processing agents, or e-wallets or any such payment processing agents), goods/services delivery agents (such as courier companies, express delivery companies, etc.), Bandwidth provider) and insurance agents.

As embodied in this document, convergent communications systems and methods can provide for the setting of settlement rules under various conditions, such as: real-time settlement, settlement with time delay (e.g., after 2 or 30 days, etc.), settlement based on confirmation of certain conditions (e.g., payment to the courier only at the time of delivery of the goods and payment to the insurance agent before shipment of the goods), settlement based on business relationships between the parties (e.g., courier provides a volume-based discount meaning that the settlement process will handle several deliveries rather than just one delivery), and settlement based on performance (e.g., portal gets a small value of payment each time an advertisement is delivered to the roaming user and a larger value of payment if the roaming user actually purchases the goods/services). As embodied in this document, convergent communications systems and methods can provide for settlement of roaming contracts (e.g., roaming surcharges) between participating networks. Further, the convergent communications system and method can provide settlement required in view of any regulations (e.g., tax fund transfers and settlement with government agencies). Thus, the transaction need not be just a one-time transaction payment, or an instant credit, and the transaction may be divided into multiple debits that add up to the purchase price. The transaction may also be a monthly transaction (encompassing "plans you can use") apportioned into the year, and so forth.

As embodied in this document, convergent communications systems and methods can provide settlement that is divided into several categories: loan days, loan limits, financial quantity limits, discounts for large orders, regulatory standards, settlement percentages, type of service based, on demand (on a regular basis, based on the end of the relationship), online, real-time, and batch processing based on various time standards.

There are several embodiments of accessing the system. For example, one of the preferred embodiments of the present invention includes accessing the system through an ATM, a bank, an agent, a POS, an interactive voice response system, a cellular handset, a landline telephone, the internet, a WAP (via a cell), a simple messaging system (via a landline telephone and a cell), a Perto machine (i.e., a machine that accepts cash to pay bills) and a post office, among others.

There are several exemplary types of users who will use the system. For example, the system may be used by consumers, family members, children, business users, business managers, business subordinates, payment company users, and bank users.

There are several exemplary types of accounts between which the system may transfer accounts. For example, the system may involve bank accounts (of different types: checking, savings, growth, education, holidays, etc.), cash accounts, credit card accounts, debit card accounts, virtual accounts, investment accounts, brokerage accounts, and commercial accounts. Exemplary systems can use a variety of formats for communications involving transfers, which have been mentioned above and are known in the art.

There are several exemplary account recipients. For example, the general payment types fall into three different categories: peer-to-peer, business-to-consumer, and business-to-business. More specifically, payment types may include: telephone charges (tolls), utilities, taxes, other municipal uses (licenses, etc.), retail (brick and cement), retail (e-commerce/internet), mobile commerce, cellular, ISP, banks, insurance companies, charities, brokerage firms, gifts to family members, and fixed telephone bills.

There are several exemplary ways to communicate the exemplary system with other accounts, or determine how to communicate with them, to make a transfer of funds. For example, validation of a payment account may be via: national wireless telecommunications database (cellular); national fixed line telecommunications database (telephone); a national bank account database; the personal account of the company that accepts each payment-i.e., the retail store Renner, has a database of all customers who own Renner credit cards or payment types, as well as a multi-party database for taxes, licenses, etc.

The many features and advantages of the invention are apparent from the detailed specification, and thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.

Claims (61)

1. A method of providing mobile commerce services via a plurality of networks, the method comprising:

receiving an identification number and a request for service from a user equipment within a roaming network;

forwarding said identification number from the user equipment and said request for service from the roaming network to the home network and adding a fee related to the service provider's service provider identification number and service;

verifying, by a convergent communications platform located on a home network, that the identification number from a user device relates to a valid user account, that the user device is authorized to receive services, and that the valid user account has sufficient value to pay for services;

providing authorization to a service provider if the identification number from the user device relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value; and

charging the valid user account for providing the service.

2. An apparatus for providing mobile commerce services via a plurality of networks, the apparatus comprising:

a receiver for receiving a request for a service, the request comprising: an identification number from a user equipment located within the roaming network and a requested service, a service provider identification number from the roaming network relating to the service provider and a cost of the requested service;

A validator that validates that the identification number from the user device relates to a valid user account, that the user device is authorized to receive services, and that the valid user account has sufficient value to pay for services;

a transmitter providing authorization to a service provider if the identification number from the user device relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value; and

a charger to charge the valid user account for providing a service.

3. A method of providing prepaid roaming communication services via a plurality of networks, the method comprising:

receiving an identification number and a destination device number from a user device within a roaming network;

forwarding the identification number and the destination device number from the user equipment from the roaming network to the home network and adding a service provider identification number and cost of the roaming communication service;

verifying, by a convergent communications platform located on a home network, that the identification number from a user device relates to a valid user account, that the user device is authorized to receive services, and that the user account has sufficient value to pay for initial use of services;

Providing authorization to a roaming network if the identification number from the user device relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value to pay for initial use of the services;

charging the valid user account for providing a service; and

and sending a signal when the balance of the effective user account reaches a preset level.

4. The method of claim 3, wherein the signal is at least one of a service disconnect, a pause, a request for recharge, and a low balance alert.

5. An apparatus for providing prepaid roaming communication services via a plurality of networks, the apparatus comprising:

a receiver for receiving a request for a communication service, the request comprising: an identification number and a destination device number from a user device located within the roaming network, and a service provider identification number and a service charge from the roaming network relating to the service provider;

a validator that validates that the identification number from the user device relates to a valid user account, that the user device is authorized to receive communication services over the roaming network, and that the valid user account has sufficient value to pay for services;

A transmitter providing authorization to a service provider if the identification number from the user device relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value, and signaling if the valid user account balance reaches a preset level; and

a charger to charge the valid user account for providing a service.

6. The apparatus of claim 5, further comprising:

a decider for determining a charge for providing the service to the user,

wherein the charger charges the valid user account in real time according to a service provided at the calculated charge.

7. The apparatus of claim 5, wherein the signal is at least one of a service disconnect, a pause, a request for recharge, and a low balance alert.

8. A method of providing network-independent customer care services via a plurality of independent networks, the method comprising:

receiving, within a roaming network, an identification number from a user equipment and a request for customer care services;

forwarding the identification number from the user equipment and the request for customer care service from the roaming network to the home network and adding a service provider identification number;

Verifying, by a convergent communications platform located on a home network, that the identification number from a user device relates to a valid user account; and

connecting the user device to the customer care service if the identification number from the user device relates to a valid user account.

9. The method of claim 8, wherein the customer care service is at least one of: a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, and a recharge request.

10. The method of claim 8, further comprising:

determining that the valid user account authorizes a recharge mechanism; and

and recharging the effective user account by using the recharging mechanism.

11. The method of claim 8, further comprising: the service provider identification number is stored.

12. An apparatus for providing customer care services via a plurality of networks, the apparatus comprising:

a receiver for receiving a request for customer care services, the request comprising: an identification number from a user equipment located within the roaming network and a service provider identification number from the roaming network relating to the service provider;

A validator that validates that the identification number from the user device relates to a valid user account, the user device being authorized to receive customer care services; and

a connector for connecting the user device to a customer care provider capable of providing customer care services if the identification number from the user device relates to a valid user account.

13. The apparatus of claim 12, wherein the customer care service is at least one of a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, and a recharge request.

14. The apparatus of claim 12, further comprising:

a determiner that determines that the valid user account authorizes a recharge mechanism; and

a charger to charge the active user account using the charging mechanism.

15. A method for recharging a prepaid account for services provided via a convergent communications platform, comprising:

receiving a request from a user device containing a user identification number to authorize use of a customer account located on a convergent communications platform;

determining that a customer account associated with the subscriber identification number does not have a sufficient balance for a service to be provided;

Determining that the customer account has an authorized recharge mechanism;

recharging the customer account using at least one other account determined according to the authorized recharge mechanism; and

authorizing the customer account for use with a service via a convergent communications platform after the customer account is recharged.

16. The method of claim 15, wherein the service is at least one of a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, and a data download.

17. The method of claim 15, wherein the receiving is from a roaming network when the convergent communications platform is located in a home network.

18. An apparatus for prepaid account top-up for services provided via a convergent communications platform, comprising:

a receiver that receives a request from a user device containing a user identification number to authorize use of a customer account located on a convergent communications platform;

a determiner that determines that the customer account associated with the identification number from the user device does not have a sufficient balance for the service to be provided and that the customer account has authorized a recharge mechanism;

A charger to charge the customer account using at least one other account determined according to the charging mechanism; and

a transmitter to transmit, via a convergent communications platform, an authorization for the customer account to use for a service.

19. The apparatus of claim 18, wherein the service is at least one of: a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, and a data download.

20. The apparatus of claim 18, wherein the user equipment is located within a roaming network when the convergent communications platform is located within a home network.

21. A method of settling prepaid transactions to multiple providers in a convergent communications environment, comprising:

charging a fee in real time for an active user account for a transaction provided via a plurality of networks;

determining a plurality of portions of the fee that should be allocated to providing the plurality of providers involved in the prepaid transaction via a plurality of networks; and

the prepaid transaction is settled with the provider via a plurality of networks based on the determined plurality of portions.

22. The method of claim 21, wherein the transaction is at least one of a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, a data download, and a recharge request.

23. The method of claim 21, further comprising:

determining that the valid user account does not have a sufficient balance;

determining that the valid user account authorizes a recharge mechanism; and

and recharging the effective user account by using the recharging mechanism.

24. The method of claim 21, further comprising: a transaction and a provider identification number for each of a plurality of providers is stored.

25. An apparatus for settling prepaid transactions to a plurality of providers in a convergent communications environment, comprising:

a charger that charges a fee in real time for a user account for a transaction provided via a plurality of networks;

a determiner that determines a plurality of portions of the fee that should be allocated to providing the plurality of providers involved in the prepaid transaction via a plurality of networks; and

a transmitter that settles prepaid transactions with the provider via a plurality of networks based on the determined plurality of portions.

26. The device of claim 25, wherein the transaction is at least one of a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, a data download, and a recharge request.

27. The apparatus of claim 25, further comprising a storage device that stores transaction and provider identification numbers for each of a plurality of providers.

28. A method of providing mobile commerce via a plurality of networks, the method comprising:

receiving an identification number and a request for service from a user equipment within a roaming network;

forwarding said identification number from the user equipment and the request for said service from the roaming network to the home network and, if the service is charged, adding a charge or charge related to the service provider's service provider identification number and the service;

verifying, by a convergent communications platform located on a home network, that the identification number from a user device relates to a valid user account, that the user device is authorized to receive services, and that the valid user account has sufficient value to pay for services;

providing authorization to a service provider if the identification number from the user device relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value; and

if the service is charged, the valid user account is charged in real time to provide the service.

29. The method of claim 1, 3, 8, or 28, wherein the roaming network is at least one of a wireless network, a simple messaging service network, a public switched telephone network, a packet switched network, a circuit switched network, an asynchronous network, the internet, an intranet, a microwave network, a cable network, an ethernet network, a token ring network, and a wide area network.

30. A method as claimed in claim 8 or 28, wherein the roaming network is of at least one of operated by an entity other than the home network, using a different signalling protocol and being located in a different geographical region.

31. The method as recited in claim 1, 3, 8, 15 or 28, wherein the user equipment is at least one of a wireless telephone, a wired telephone, a modem, a computer, a personal digital assistant, a pager, a cellular telephone, and a radio transmitter.

32. The method as recited in claims 1, 3, 8, 15 or 28, wherein said identification number from the user equipment is at least one of a personal identification number, a subscriber identity module, an international mobile subscriber identity, an international mobile station equipment identity, a mixture of alphanumeric characters and a hexadecimal number.

33. The method as recited in claim 1, 3 or 28, wherein the service is at least one of a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, a data download and a recharge request.

34. A method as claimed in claim 1, 3 or 28, wherein the service provider comprises a plurality of services, each service receiving a portion of the service charge.

35. The method as recited in claim 1, 3 or 28, further comprising: the charged number is sent to the service provider.

36. The method of claim 1, 3 or 28, further comprising:

determining that the valid user account does not have a sufficient balance;

determining that the valid user account authorizes a recharge mechanism; and

and recharging the effective user account by using the recharging mechanism.

37. The method of claim 36, further comprising:

determining, after user intervention, that the valid user account authorizes a recharge mechanism;

contacting a user device requesting authorization for recharge in a roaming network; and

the recharge is authorized only if the user device correctly answers the request for an authorized recharge.

38. The method of claim 36, wherein said recharging is based on user-defined rules that specify at least one of account, number, and source of funds.

39. The method of claim 38, wherein the user-defined rules specify a plurality of accounts based on a recharge priority based on at least one of account, previous recharge, account balance, and time.

40. The method of claim 36, wherein said replenishing is from at least one of a bank account, an investment account, a credit account, and a pre-authorized loan account.

41. The method of claim 1, 3 or 28, further comprising: storing said charging and service provider identification numbers.

42. The method of claim 3, wherein the cost of the roaming communication service is at least one of a roaming cost, a cost of a delivered service, an air time cost, a tax, an additional cost of facility use, a discount, and an insurance cost.

43. The method of claim 3 or 28, further comprising:

determining a charge for providing a service to a user; and

charging the valid user account in real time based on the services provided pursuant to the calculated billing.

44. The method of claim 28, wherein the charging is at least one of roaming network charging, home network charging, air time charging, long distance charging, international charging, tax, additional charges for facility use, discounts, and insurance charges.

45. An apparatus for providing mobile commerce via a plurality of networks, the apparatus comprising:

a receiver which receives the identification number from the user equipment and a request for the service, a service provider identification number related to the service provider and a charge or charge for the service if the service is to be charged from the roaming network;

a determiner that determines, by a convergent communications platform located on a home network, whether the identification number from a user device relates to a valid user account, whether the user device is authorized to receive services, and whether the valid user account has sufficient value to pay for services;

a transmitter providing authorization to a service provider if the identification number from the user device relates to a valid user account, the user device is authorized to receive services, and the valid user account has sufficient value, if the services are charged; and

A charger to charge the valid user account in real time to provide the service if the service is charged.

46. The apparatus of claim 2, 5, 12, or 45, wherein the roaming network is at least one of a wireless network, a simple messaging service network, a public switched telephone network, a packet switched network, a circuit switched network, an asynchronous network, the Internet, an intranet, a microwave network, a cable network, an Ethernet network, a token ring network, and a wide area network.

47. An apparatus as claimed in claim 12 or 45, wherein the roaming network is of at least one of operated by an entity other than the home network, using a different signalling protocol and being located in a different geographical region.

48. The apparatus of claim 2, 5, 12, 18, or 45, wherein the user equipment is at least one of a wireless telephone, a wired telephone, a modem, a computer, a personal digital assistant, a pager, a cellular telephone, and a radio transmitter.

49. The apparatus as recited in claims 2, 5, 12, 18, or 45, wherein said identification number from the user equipment is at least one of a personal identification number, a subscriber identity module, an international mobile subscriber identity, an international mobile station equipment identity, a mixture of alphanumeric characters, and a hexadecimal number.

50. The apparatus of claim 2, 5 or 45, wherein the service is at least one of a telephone connection, a simple messaging service message, a facsimile transmission, a data transmission, a purchase request for goods/services, a data download and a recharge request.

51. An apparatus as claimed in claim 2, 5 or 45, wherein the service provider comprises a plurality of services, each service receiving a portion of the service charge.

52. An apparatus as claimed in claim 2, 5 or 45, wherein the transmitter also transmits the charged number to the service provider.

53. The apparatus as recited in claim 2, 5, 25 or 45, further comprising:

a charger to charge the active user account using the charging mechanism,

wherein the determiner determines that the valid user account does not have a sufficient balance and determines that the valid user account authorizes a recharge mechanism.

54. The apparatus as recited in claim 53, further comprising:

an authorizer authorizing recharge only if the user device correctly answers the request for authorized recharge,

wherein the determiner, after user intervention, also determines that the valid user account authorizes a recharge mechanism,

Wherein the transmitter also transmits a request for authorizing a recharge to a user equipment in the roaming network.

55. The apparatus of claim 53, wherein said recharge is based on user-defined rules that specify at least one of account, number, and source of credit.

56. The apparatus of claim 55, wherein the user-defined rules specify a plurality of accounts based on a recharge priority based on at least one of an account, a previous recharge, an account balance, and a time.

57. The apparatus of claim 53, wherein the charger charges from at least one of a bank account, an investment account, a credit account, and a pre-authorized loan account.

58. An apparatus as claimed in claim 2, 5 or 45, further comprising a storage device for storing the charged fee and the service provider identification number.

59. The apparatus of claim 5, wherein the cost of the roaming communication service is at least one of a roaming cost, an air time cost, a tax, an additional cost for facility use, a discount, and an insurance cost.

60. An apparatus as defined in claim 45, wherein the determiner is further to determine a fee for providing the service to the user, and the fee charger to charge the valid user account in real-time based on the service provided pursuant to the calculated fee.

61. The apparatus of claim 45, wherein the charging is at least one of a roaming network charging, a home network charging, a time-over-the-air charging, a long distance charging, an international charging, a tax, an additional fee for facility use, a discount, and an insurance fee.