CA2344749A1 - A mobile telecommunications network-based sales transaction system - Google Patents
A mobile telecommunications network-based sales transaction system Download PDFInfo
- Publication number
- CA2344749A1 CA2344749A1 CA002344749A CA2344749A CA2344749A1 CA 2344749 A1 CA2344749 A1 CA 2344749A1 CA 002344749 A CA002344749 A CA 002344749A CA 2344749 A CA2344749 A CA 2344749A CA 2344749 A1 CA2344749 A1 CA 2344749A1
- Authority
- CA
- Canada
- Prior art keywords
- mobile
- customer
- merchant
- server
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Abstract
The objective of the present invention is to devise an m-commerce system which, without need for transferring credit card numbers or other confidential information relat-ing to a customer, offers providers of services and goods a centralized site that performs customer's validation, checks solvency, makes an invoice, carries out clearing of accounts, and collects and processes statistical informa-tion. The m-commerce system stores virtual bank ac-counts for each customer joined to the system. The ac-count indicates the customer's solvency. The system also stores information about the customers and merchants joined to the system. The system receives a solvency in-quiry sent by a merchant through the mobile telecommu-nications network. In response to the inquiry the m-commerce system checks whether the customer has sol-vency for the purchase. If so, the merchant server sends a sale message that includes all the details of the transac-tion concerned. In response to the sale message the m-commerce system starts data processing, during which the merchant's account is credited, the customer's ac-count is debited, and statistics and necessary databases are updated.
Description
A MOBILE TELECOMMUNICATIONS NETWORK-BASED SALES
TRANSACTION SYSTEM
FIELD OF THE INVENTION
The present invention relates generally to a system for providing information and performing financial transactions. More particularly, the in-vention relates to a financial system utilizing wireless portable terminals for performing financial transactions and especially small payment transactions.
BACKGROUND OF THE INVENTION
Various automated payment systems particularly suited for pur-chases over a distributed computer network, such as the Internet, are being developed. A reason for using a public communication system as the Inter-net is its ability to make it possible for a single merchant economically reach a vast number of potential customers at substantially low costs. In addition, the customers are able to review a great number of vendors and their prod-ucts with the ease of a few keystrokes and clicks of the mouse. Therefore, it is evident that a significant amount of commerce will be conducted using dis-tributed networks of computers such as the Internet.
Numerous purchasing and payment methods are both proposed and in use. Usually a merchant computer contains certain promotional infor-mation, which is communicated to a customer's computer. Based upon the information, the operator of the customer's computer decides whether or not to purchase the services or goods offered by the merchant. The customer's computer is linked to a payment processing computer and the customer's credit card number and the amount of the goods or services is transmitted to the payment-processing computer. The payment-processing computer automatically contacts a bank or a credit card company for verification of the credit card and amount; then the bank transmits an authorization to the pay-ment-processing computer. The payment processing computer communi-cates a self generated transactions and, in some embodiments, a password, to the customer's computer. For example, the payment-processing computer might be a gateway which is authorized, by a bank or other financial institu-tion that has the responsibility of providing payment on behalf of the cus-tourer, to authorize a commercial transaction on behalf of such a financial institution, without the risk of exposing that information to interception by
TRANSACTION SYSTEM
FIELD OF THE INVENTION
The present invention relates generally to a system for providing information and performing financial transactions. More particularly, the in-vention relates to a financial system utilizing wireless portable terminals for performing financial transactions and especially small payment transactions.
BACKGROUND OF THE INVENTION
Various automated payment systems particularly suited for pur-chases over a distributed computer network, such as the Internet, are being developed. A reason for using a public communication system as the Inter-net is its ability to make it possible for a single merchant economically reach a vast number of potential customers at substantially low costs. In addition, the customers are able to review a great number of vendors and their prod-ucts with the ease of a few keystrokes and clicks of the mouse. Therefore, it is evident that a significant amount of commerce will be conducted using dis-tributed networks of computers such as the Internet.
Numerous purchasing and payment methods are both proposed and in use. Usually a merchant computer contains certain promotional infor-mation, which is communicated to a customer's computer. Based upon the information, the operator of the customer's computer decides whether or not to purchase the services or goods offered by the merchant. The customer's computer is linked to a payment processing computer and the customer's credit card number and the amount of the goods or services is transmitted to the payment-processing computer. The payment-processing computer automatically contacts a bank or a credit card company for verification of the credit card and amount; then the bank transmits an authorization to the pay-ment-processing computer. The payment processing computer communi-cates a self generated transactions and, in some embodiments, a password, to the customer's computer. For example, the payment-processing computer might be a gateway which is authorized, by a bank or other financial institu-tion that has the responsibility of providing payment on behalf of the cus-tourer, to authorize a commercial transaction on behalf of such a financial institution, without the risk of exposing that information to interception by
2 third parties. Such institutions include, for example, financial institutions offer-ing credit or debit card services.
Sending a credit card number through an open network is a risk.
For that reason several cryptographic methods are used. One such method of securing transmission channel is Secure Electronic Transaction (SET), developed by the Visa and MasterCard card associations. Other known se-cure payment methods are Secure Transaction Technology (STT) and Se-cure Electronic Payments Protocol (SEPP), for example.
A drawback to secure payment technology is that it requires de ployment of special-purpose software to the customer compliant with the par ticular secure payment technology. Customers are generally reluctant to in stall specialized software in the absence of a general acceptance of mer chant software and payment gateway software that incorporate the corre sponding secure payment technology with which to interact. Similarly, mer chants and payment gateways are reluctant to implement a secure payment technology in the absence of an installed customer base.
The difficulties customers have faced in paying for their purchases has depressed commerce. A variety of techniques have been developed to cure this problem, ranging from accepting phone orders to the establishment of another currency called "E-Cash". Although E-Cash is a feasible alterna-tive, it is faced with some problems, which will be difficult or impossible to address. These include: counterfeiting problems; government reluctance to accept the concept; difficulties in getting access for handling E-Cash; and, the low number of users and merchants which can use E-Cash.
A drawback when using fixed networks for commercial transac-tions is that a customer is tied to a computer that is physically connected to the network. Therefore, a possibility to use wireless networks for commerce opens promising prospects. A need to bring Internet based services and con-tents available to end users independent of time and place has led the wire-less industry to develop a new standard useful in developing applications and services that operate over wireless communications networks. The stan-dard, wireless application protocol (WAP), specifies an application framework and network protocols for wireless terminals, such as mobile telephones, pagers, and personal digital assistants (PDAs). The WAP makes it possible to offer a wide range of wireless services, which are independent of the un-derlying digital wireless network technology.
Sending a credit card number through an open network is a risk.
For that reason several cryptographic methods are used. One such method of securing transmission channel is Secure Electronic Transaction (SET), developed by the Visa and MasterCard card associations. Other known se-cure payment methods are Secure Transaction Technology (STT) and Se-cure Electronic Payments Protocol (SEPP), for example.
A drawback to secure payment technology is that it requires de ployment of special-purpose software to the customer compliant with the par ticular secure payment technology. Customers are generally reluctant to in stall specialized software in the absence of a general acceptance of mer chant software and payment gateway software that incorporate the corre sponding secure payment technology with which to interact. Similarly, mer chants and payment gateways are reluctant to implement a secure payment technology in the absence of an installed customer base.
The difficulties customers have faced in paying for their purchases has depressed commerce. A variety of techniques have been developed to cure this problem, ranging from accepting phone orders to the establishment of another currency called "E-Cash". Although E-Cash is a feasible alterna-tive, it is faced with some problems, which will be difficult or impossible to address. These include: counterfeiting problems; government reluctance to accept the concept; difficulties in getting access for handling E-Cash; and, the low number of users and merchants which can use E-Cash.
A drawback when using fixed networks for commercial transac-tions is that a customer is tied to a computer that is physically connected to the network. Therefore, a possibility to use wireless networks for commerce opens promising prospects. A need to bring Internet based services and con-tents available to end users independent of time and place has led the wire-less industry to develop a new standard useful in developing applications and services that operate over wireless communications networks. The stan-dard, wireless application protocol (WAP), specifies an application framework and network protocols for wireless terminals, such as mobile telephones, pagers, and personal digital assistants (PDAs). The WAP makes it possible to offer a wide range of wireless services, which are independent of the un-derlying digital wireless network technology.
3 WAP enables mobile phones supporting the protocol to have ac-cess to information and transactional services, such as restaurant and hotel information, stock trading, banking services, directory services, exchange rates, flight schedules and train, bus timetables etc. Using browser software installed in the mobile phone, the user can contact a merchant's computer for certain promotional information which is communicated to the mobile phone and shown on the display. Based upon the information, the user can decide whether or not to purchase the services or goods offered by the mer-chant.
Payment methods do not differ essentially from the previously de-scribed methods used in the Internet. However, because the user is a sub-scriber of a mobile communications network, so having a certain directory number, it is possible to charge the user for the purchase by adding the pur-chase price to the telephone bill. In this case the regional operator of the mobile communications network and the merchant clear their accounts of terwards. Usually the user does not keep records of the purchases made during the billing period so that the amount of the telephone bill might be surprisingly high.
It is also possible to use a credit card wherein the user sends the card number to the merchant's server which then links the number to the server of a credit card company, for example. Sending a credit card number through a radio channel is a great risk, because interception of the number by a third party is possible. In order to reduce the risk it is known to make use of a mobile phone's smart card. Encryption algorithms may be stored and processed with the smart card to allow the smart card to be validated from a remote merchant server or by a host computer operated by a financial institution, for example. In this way, information can be securely exchanged between the card and the remote location using one or more encryption keys that are in place in both locations. The encryption keys are used to encode information to be transmitted and to decode information that is received.
Using encryption techniques, it is possible not only to encode fi-nancial information stored remotely by a host computer or locally on the smart card, but also to encode identification information, such as personal identification numbers (PINs). In this way a user's PIN may be encrypted by the smart card and communicated to a remote host, which has the same en-cryption key to decode the encrypted PIN and to validate it. This provides
Payment methods do not differ essentially from the previously de-scribed methods used in the Internet. However, because the user is a sub-scriber of a mobile communications network, so having a certain directory number, it is possible to charge the user for the purchase by adding the pur-chase price to the telephone bill. In this case the regional operator of the mobile communications network and the merchant clear their accounts of terwards. Usually the user does not keep records of the purchases made during the billing period so that the amount of the telephone bill might be surprisingly high.
It is also possible to use a credit card wherein the user sends the card number to the merchant's server which then links the number to the server of a credit card company, for example. Sending a credit card number through a radio channel is a great risk, because interception of the number by a third party is possible. In order to reduce the risk it is known to make use of a mobile phone's smart card. Encryption algorithms may be stored and processed with the smart card to allow the smart card to be validated from a remote merchant server or by a host computer operated by a financial institution, for example. In this way, information can be securely exchanged between the card and the remote location using one or more encryption keys that are in place in both locations. The encryption keys are used to encode information to be transmitted and to decode information that is received.
Using encryption techniques, it is possible not only to encode fi-nancial information stored remotely by a host computer or locally on the smart card, but also to encode identification information, such as personal identification numbers (PINs). In this way a user's PIN may be encrypted by the smart card and communicated to a remote host, which has the same en-cryption key to decode the encrypted PIN and to validate it. This provides
4 authorization to access information stored by the host and/or to request vari-ous financial transactions.
In order to highlight the difference between networks through which commercial transactions are performed, commerce in fixed networks are called e-commerce whereas commerce in wireless networks are called m-commerce (mobile commerce).
The payment methods, which are used in m-commerce, have cer-tain drawbacks. From the user's point of view, sending a credit card number through the radio channel is, despite encryption, always a risk. From the merchant's point of view, extra resources are needed for handling collection of customers' payments, invoicing of services, and monitoring of credit.
Every merchant should be provided with said resources, which restrains their willingness to start offering goods and services through a public wireless network. In the case a user is billed in connection with the telephone bill, a telephone company or telecommunication operator has to establish special arrangements for billing and clearing purposes.
In addition, in the prior art systems records of transactions are dis-tributed among the merchants' servers so that it is not possible to acquire statistical information about overall commerce in the network. This informa-tion would enable service providers to react quickly to changes in the busi-ness environment.
SUMMARY OF THE INVENTION
An objective is to devise an m-commerce system in which real money and bills are not transferred at all, but nevertheless the system has real-time knowledge of customers' solvency.
Another objective of the present invention is to devise an m-commerce system which, without need for transferring credit card numbers or otlier confidential information relating to a customer, offers providers of services and goods a centralized site that performs customer's validation, checks solvency, carries out clearing of virtual accounts, and collects and processes statistical information.
The core of the m-commerce system comprises customer informa tion management, transaction processing, credit and information forwarding, and account services.
The m-commerce system includes a database consisting of virtual accounts for each customer joined to the system. The account states the customer's solvency. Solvency can be comprised of prepaid virtual money wherein a customer transfers beforehand to the virtual account a certain
In order to highlight the difference between networks through which commercial transactions are performed, commerce in fixed networks are called e-commerce whereas commerce in wireless networks are called m-commerce (mobile commerce).
The payment methods, which are used in m-commerce, have cer-tain drawbacks. From the user's point of view, sending a credit card number through the radio channel is, despite encryption, always a risk. From the merchant's point of view, extra resources are needed for handling collection of customers' payments, invoicing of services, and monitoring of credit.
Every merchant should be provided with said resources, which restrains their willingness to start offering goods and services through a public wireless network. In the case a user is billed in connection with the telephone bill, a telephone company or telecommunication operator has to establish special arrangements for billing and clearing purposes.
In addition, in the prior art systems records of transactions are dis-tributed among the merchants' servers so that it is not possible to acquire statistical information about overall commerce in the network. This informa-tion would enable service providers to react quickly to changes in the busi-ness environment.
SUMMARY OF THE INVENTION
An objective is to devise an m-commerce system in which real money and bills are not transferred at all, but nevertheless the system has real-time knowledge of customers' solvency.
Another objective of the present invention is to devise an m-commerce system which, without need for transferring credit card numbers or otlier confidential information relating to a customer, offers providers of services and goods a centralized site that performs customer's validation, checks solvency, carries out clearing of virtual accounts, and collects and processes statistical information.
The core of the m-commerce system comprises customer informa tion management, transaction processing, credit and information forwarding, and account services.
The m-commerce system includes a database consisting of virtual accounts for each customer joined to the system. The account states the customer's solvency. Solvency can be comprised of prepaid virtual money wherein a customer transfers beforehand to the virtual account a certain
5 amount of virtual money. This money can be debited at the same time from a real bank account or the money can be frozen in the real bank account. This way corresponds to the pre-pay method. Solvency can also be comprised comprise of a virtual credit card account having a certain limit. Further, sol-vency can also be comprised of the knowledge that the customer's real bank account can be debited for a purchase. This way corresponds to the direct debiting method. Generally, solvency can be comprised of any kind of infor-mation that ensures a customer's solvency.
The m-commerce system also includes at least one database that consists of information about the customers and merchants joined to the sys tem. Merchant data include identifications of the merchants, list of items or services being offered to customers, and their prices, possible discounts etc., in other words, all necessary information which is needed for invoicing a cus-tourer.
The m-commerce system also includes an input/output interface to a public access network. The system receives at the input an inquiry sent by a merchant through the network. In this inquiry the merchant sends an identification of a customer and the value of the purchase which the cus-tomer has chosen. In response to the inquiry the m-commerce system re-trieves customer information from the database and then checks form the database whether the customer has solvency for the purchase. If so, then an amount of the solvency corresponding the value of the purchase will be fro-zen. Thereafter the m-commerce system, through the output, sends the mer-chant a reply message, which confirms or rejects the purchase. The reply message will also be transferred to the customer.
After receiving the reply message, including confirmation, the merchant's server will prepare a transaction message that includes all the details of the transaction concerned. The message is sent, immediately or later among other transaction messages, to the m-commerce system, which stores the message for processing. The processing can be started immedi-ately but preferably the mobile transaction server collects a large number of transaction messages and processes them in batch processing. During data ~ 02344749 2001-04-24
The m-commerce system also includes at least one database that consists of information about the customers and merchants joined to the sys tem. Merchant data include identifications of the merchants, list of items or services being offered to customers, and their prices, possible discounts etc., in other words, all necessary information which is needed for invoicing a cus-tourer.
The m-commerce system also includes an input/output interface to a public access network. The system receives at the input an inquiry sent by a merchant through the network. In this inquiry the merchant sends an identification of a customer and the value of the purchase which the cus-tomer has chosen. In response to the inquiry the m-commerce system re-trieves customer information from the database and then checks form the database whether the customer has solvency for the purchase. If so, then an amount of the solvency corresponding the value of the purchase will be fro-zen. Thereafter the m-commerce system, through the output, sends the mer-chant a reply message, which confirms or rejects the purchase. The reply message will also be transferred to the customer.
After receiving the reply message, including confirmation, the merchant's server will prepare a transaction message that includes all the details of the transaction concerned. The message is sent, immediately or later among other transaction messages, to the m-commerce system, which stores the message for processing. The processing can be started immedi-ately but preferably the mobile transaction server collects a large number of transaction messages and processes them in batch processing. During data ~ 02344749 2001-04-24
6 processing the merchant's account is credited, the customer's account is debited, and statistics and necessary databases are updated.
The proposed m-commerce system has several advantages. The customer can buy services fast and safely using a mobile phone or a wire s less terminal. The customer can trust that purchases can be made without any risk. The merchant can leave all financial and billing routines to the m-commerce system that takes care of billing customers and credit control. Sta-tistics produced by the m-commerce system include quantitative and qualita-tive information about buying habits and use of services. It can be effectively utilized for marketing purposes. Various customer profiles can easily be cre-ated based on statistics.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention is described more closely with reference to the ac-companying drawings, in which FIG. 1 depicts the invented system in connection with a mobile com-munications network;
FIG. 2 illustrates the exchange of messages during purchasing;
FIG. 3 is a practical example of a purchasing event;
FIG. 4A, 4B shows contents of messages;
FIG. 5 shows processing steps performed by the system;
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Networks to which the invented e-commerce system can be adapted can be any kind of public access network. However, a wireless communication network, especially mobile telecommunications networks of-fering WAP services are preferred. Henceforward it is assumed that the net-work is a mobile telecommunications network having the WAP service.
The upper half of FIG. 1 represents a mobile telecommunications network offering WAP services. The network will first be shortly described.
Only the important elements are shown i.e. wireless WAP terminal 10 gateway 11 residing in mobile telecommunications network 13, and server 12. Subscriber terminal 10, which is a WAP mobile phone, initiates a request for connection with a service that is located in server 12 somewhere in the network. Communication between WAP phone 12 and the fixed network
The proposed m-commerce system has several advantages. The customer can buy services fast and safely using a mobile phone or a wire s less terminal. The customer can trust that purchases can be made without any risk. The merchant can leave all financial and billing routines to the m-commerce system that takes care of billing customers and credit control. Sta-tistics produced by the m-commerce system include quantitative and qualita-tive information about buying habits and use of services. It can be effectively utilized for marketing purposes. Various customer profiles can easily be cre-ated based on statistics.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention is described more closely with reference to the ac-companying drawings, in which FIG. 1 depicts the invented system in connection with a mobile com-munications network;
FIG. 2 illustrates the exchange of messages during purchasing;
FIG. 3 is a practical example of a purchasing event;
FIG. 4A, 4B shows contents of messages;
FIG. 5 shows processing steps performed by the system;
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Networks to which the invented e-commerce system can be adapted can be any kind of public access network. However, a wireless communication network, especially mobile telecommunications networks of-fering WAP services are preferred. Henceforward it is assumed that the net-work is a mobile telecommunications network having the WAP service.
The upper half of FIG. 1 represents a mobile telecommunications network offering WAP services. The network will first be shortly described.
Only the important elements are shown i.e. wireless WAP terminal 10 gateway 11 residing in mobile telecommunications network 13, and server 12. Subscriber terminal 10, which is a WAP mobile phone, initiates a request for connection with a service that is located in server 12 somewhere in the network. Communication between WAP phone 12 and the fixed network
7 takes place via a radio channel and base transceiver station 14, which is a network element of the mobile telecommunications network.
Merchant server 12 often uses the HTTP format but it can also use the WAP format. The server includes contents that are WML pages in-s tended for sending to mobile phones. Between the subscriber terminal and the server there is gateway 11 including encoders/decoders which encode WAP content of a file received from the server into a suitable compact format for radio transmission and decode the encoded data received from a radio channel prior to further transmission to the server 12.
WAP phone 10 is provided with a textual browser, a search en-gine, etc., for displaying and interpreting a service received from server 12.
When using WAP services, a user selects one of the services displayed on the screen of the mobile phone. The browser sends a request to the mer-chant's server, which returns a content fetched from the content database.
After a plurality of request-content messages have been exchanged, the user finally selects one of the services or one of the goods being offered.
The price of the selected item of the service and the payment method are known by this stage at the latest. Then the server 12 inquires about the pay-ment method that the user will use. In response to the inquiry, the user sends an answer message to server 12. Said message 1 is labeled with "PAYMENT INFO" in FIG. 1.
After receiving message 1 "PAYMENT INFO", merchant server 12 forms solvency inquiry message 2 and sends it to the m-commerce system 100 according to the invention. The system checks user's solvency from the virtual account database and sends a reply message 3 both to WAP phone 10 and merchant server 12. If the user has solvency for the purchase, the merchant server forms a message 4 that includes the details of the transac-tion. Said message can be sent immediately to the nn-commerce system or several transaction details messages can be put together and send now and then to the m-commerce system.
The m-commerce system will be described now in detail. The core of the e-commerce system consists of a mobile transaction server 101. Per-manent data that service software of the system needs is stored in a plurality of databases.
A database 102 for virtual accounts consists of solvency informa-tion of the customers joined to the m-commerce system. For example, by joining the system each customer may insert into this database a certain amount of virtual money. At the same moment the real bank account may be debited with the same amount of real money. This virtual account can be called a pre-paid account. This account will debited by each purchase, wherein the method can also be called a direct debiting. Alternatively, the customer may have a credit account with a certain upper limit in the data-base. This alternative is practical if the user prefers a credit card.
Further, a customer may belong to an on-line paying system of an financial instance. For example, the customer has made a contract with a merchant in which the purchase will automatically and immediately be deb ited from the customer's bank account. This proceeding can be called a di-rect debiting method. In that case the customer's virtual account consists of information about paying proceeding in said on-line paying system.
A customer database 103 includes customer information that is stored in the database when a customer joins the m-commerce system. The customer's name and address are needed. Importantly, customer information contains an identification token (ID) of the customer. This is a token which arrives from the mobile telecommunications network within the inquiry mes sage sent by the merchant, and by the help of the token the m-commerce system is able to retrieve the customer information concerned from the cus-tomer database 103. Usually the token is the telephone number of the cus-tomer. Customer information also contains a reference to the virtual money accounts database 102 wherein the reference binds information about a cus-tomer and information about the customer's virtual account.
A merchant database 104 includes information about the mer-chants who are joined into the m-commerce system. Information about a merchant consists not only the merchant's name and address but also a list of the products and/or services that the merchant offers to the subscribers of the mobile communications network. To each of the products or services re-lates a price, a possible discount, a possible bonus, and other information that is needed for billing purposes. Preferably, an identifying code (ID) is at-tached to each merchant. When the merchant contacts the m-commerce system, the code may be used for identification purposes besides the IP ad-dress of the merchant's server.
Service software installed in the mobile transaction server in-cludes programs for managing customer data and merchant data, process-ing transactions, handling credit and solvency information, creating bills, per-forming account operations, and for processing transaction events for statis-tical purposes.
The m-commerce system also has interface B to external systems such as banks and other external systems. In addition, reports generated by the system are transmitted through this interface. The banks and other ex ternal systems can access the m-commerce system via this interface.
FIG. 2 shows the basic steps during purchasing. The protocol used in the session is the wireless application protocol (WAP). Messages, which are exchanged between the mobile terminal and the merchant server, go through a gateway (see FIG. 1). First a mobile terminal contacts a mer-chant server and sends a request. In response to the request the merchant server sends a content, which may be a menu, for example. The user selects an item from the menu whereupon the mobile terminal sends the second re-quest. The merchant server responds by sending the second content, which includes more detailed information of the selected menu item. After request-content message pairs have been sent N times, the user has got enough in-formation and makes a decision to order a service. The service might be an order for tickets to a movie, for example. In response to the order message the merchant server sends a payment inquiry message in which the mer-chant inquires how the user wishes to pay. The content of the menu in the message can include various alternatives like "credit card", "pre-pay", "on-line pay". Using the browser the user selects one method, in this example the selection is "credit card", and sends an answer message. It is important to note that no credit card number is transmitted.
In response to the payment method message the merchant server sends an solvency inquiry message to the mobile transaction server to the m-commerce system. The message contains only the user's identification, the value of the intended purchase, and the payment method selected by the user. Preferably, the user identification comprises the user's telephone num-ber, which the transmission network of the operator concerned transmits to the merchant server. The payment method in the payment inquiry message is a code only. Again, it is worth noting that no credit card number is transmit-ted in the message.
In response to the account inquiry message, the mobile transac-tion server first checks information about the user from the customer data-base and then the corresponding virtual account linked to that particular user. If the virtual account verifies that the liquidity of the credit card account is enough for covering the purchase, the mobile transaction server sends an acceptance message to the merchant server. But if the virtual account shows 5 that the user fails to have liquidity enough, the mobile transaction server sends a rejection message to the merchant server. In addition, the user of the mobile terminal is informed about the acceptance or rejection of the pur-chase. This information will end the session between the merchant and the user.
10 Now the merchant server prepares a second message to the mo-bile transaction server. The message, "Details of Transaction", includes all details of the purchase previously made. Consequently, the message in-cludes generally the merchant's identification code, which is also stored in the merchant data base 104, a product code, amount of the products, the price of the product, discount code and bonus code if such codes are used, and the payment method.
In addition, the operator of the network can deliver details of the call the user previously made to the mobile transaction server. Preferably, the operator sends the call data record (CDR) of the call. It is known that an exchange generates CDRs for each call. The CDR includes the caller's tele-phone number, starting and ending time of the call (time stamps), duration of the call, and the telephone number of the called party, the number being the uniform resource locator if the call has been a WAP call. The mobile transac-tion server can use the CDRs for authentication purposes, i.e. to be able to present, whenever needed, legally valid evidence that the call has really been made.
After the mobile transaction server has received the "details of transaction" message from the merchant, and possibly the CDR from the op-erator, it will start processing of the accounts using particulars given in the "details of transaction" message. Relevant databases will be updated, i.e. the user's virtual account will be debited, the merchant's account will be credited, and statistics will be created.
FIG. 3 depicts a practical example based on the steps of fig. 2.
Here the boxes on the left show contents of the display in the user's mobile phone. After the user has contacted a merchant server, which means that the browser has called the URL of the merchant server, the server transmits a menu content that is shown in box 31. The user selects "movies" and the selection will transmit through the transmission network to the merchant server. The server returns content 32 that is a list of movies. The user's se-lection "movie 3" is transmitted to the merchant server that returns content 33. It tells both the theater at which the selected movie is on and also times when the movie is shown. In this manner the user selects the delivery date (it is possible to buy a ticket no more than seven days beforehand), content 34, and the price of the ticket, content 35. Thereafter the merchant server asks to confirm the selection, content 36. The user confirms by clicking "yes"
whereupon the merchant server inquires the payment method, content 37.
Here two alternatives are shown, namely the user can pay with a credit card or with the pre-pay option. In the latter case the user has inserted solvency beforehand to the virtual account in the m-commerce system.
The user selects "credit card", whereupon the payment method message is transmitted to the merchant server. In response to this message the merchant server sends through the transmission network a solvency in-quiry message to the mobile transaction server, stage 38. The message in-cludes the mobile phone number of the user, a code of the payment method, here credit card, and the value of the intended purchase. In addition, the message includes the address of the merchant server so that the mobile transaction server is able to send a reply to the right address.
After receiving the payment info message, the mobile transaction server makes a query in the customer database for obtaining customer data that relates to the mobile phone number of the user. The customer data in-cludes a pointer to the customer's credit card account in the virtual money database so that the mobile transaction server is able to find out whether or not there is solvency enough for the purchase. If the answer is "yes" the mo-bile transaction server replies to the credit card message by sending an ap-proval message to the merchant server, stage 310. In response to the ap-proval message, the merchant server forwards the acceptance to the user, stage 311. The user's share in commercial transactions ends by receiving the acceptance message from the merchant.
The essential part of the steps of the present invention will start now. The merchant server sends all appropriate details about the above described purchase to the mobile transaction server, stage 311. The mobile transaction server will start processing the received data the result of which will be debiting the virtual account of the customer and crediting the virtual account of the merchant.
FIG. 4A and 4B show contents of the messages transmitted from the mobile telecommunications network to the mobile transaction server. An exchange in a mobile telecommunications network, like in a PSTN network, produces a call data record for each call. As shown in FIG. 4A, the record contains basic information about the call. For example, the CDR of a WAP
call includes identification of the user that made the call. This is most com-monly the mobile telephone number of the user. Then the CDR includes the start time and end time of the call, duration of the call, the amount of data transferred during the call, and the address of the called party. In the WAP
call the address is the URL (Uniform Resource Locator) of a merchant's server. A message of this type is sent to the mobile transaction server after the call. Said server stores the CDR for safety reasons. Moreover, if a ser-vice offered by a merchant contains downloadable files or the service is tied to the duration of the call, the duration field of the CDR can directly be used for billing.
FIG. 4B shows the contents of the "details of transaction" mes-sage of fig. 4 that the merchant server sends to the mobile transaction server. The message is comprised of the ID of the calling party, that is the user's mobile telephone number, and a product code. Each product the mer-chant offers to users has its own unique code. The real description of the code is stored in the merchant database. Further, the message contains the number of sold products; here the numbers of the tickets, a currency code if different currencies are in use, unit price of the product, and value added tax percentage. If discounts or bonuses are in use, their codes follow in the message. The merchant code identifies the merchant and the rest of the fields tell the order date and time and the delivery date and time.
Information in some of the fields is coded in order to shorten the message. Each piece of coded information has its clear text counterpart in the merchant database.
Based on this type of a message the mobile transaction server is able to per-form all necessary actions.
The actions described with reference to FIG. 5 depict some basic functions of the mobile transaction server. The main functions of the mobile transaction server consist of management of customer data, management and forwarding of credit status and liquidity information, and carrying out in-voicing and accounting. The mobile transaction server is a centralized sys-tem and both a merchant and a customer i.e. a subscriber of a mobile tele-communications network, have to join the system by making a contract with the system operator.
The server includes a plurality of databases and service pro-grams. Database 102 contains virtual account information of every customer joined to the m-commerce system. The account information can be the amount of virtual money that the customer has put into the e-commerce sys-tem. This can be called a pre-pay method. It can also be a credit limit of a credit card. Other possible ways to open a virtual account are possible.
Database 103 contains relevant data of every customer joined to the m-commerce system. Such data are at least the name, the address, and payment methods. By joining the m-commerce system the customer has to make a contract with the operator of the system whereupon the customer designates the payment methods. The customer can designate one or all payment methods that the system offers. The operator opens a virtual ac-count for each payment method. Thus, the customer database also includes references to virtual accounts that the customer has. The references can be links, indexes, pointers etc. depending on the programming language.
In addition, database 103 may include information about particular characters of the customer. Such characters tell that the customer belongs to a certain bonus or discount system, the customer is a member of a commer-cial group so enjoying so benefits, for example.
Database 104 contains relevant data of every merchant joined to the m-commerce system. By joining the m-commerce system the merchant has to make a contract with the operator of the system, whereupon all rele vant data about the merchant, services, and products are input to the m commerce system. The merchant also designates the payment methods.
Further, it is agreed in the contract, which services of the mobile transaction server the merchant will to buy. Said relevant data are at least the name, the address, a merchant's code, and information abut banking accounts of the merchant. In addition, each merchant has in database 104 data relating to every product and/or service being offered by the merchant. Such data in-clude codes and corresponding plain text. Such data are needed to decode information of a "details of transaction" message (see Fig. 4) and for billing, accounting, and statistical purposes.
Transactions database 503 is intended for storage details of the transactions. Thus, it contains historical knowledge about transactions. Data in this database can be processed for making different kind of statistical analyses which are needed in order to make sales curves, sales forecasts, marketing, sales campaigns, customer profiles etc.
Invoice database 515 includes information about what has been billed. Data in this database can be used for producing statements of ac-counts which are send to the customers.
When the mobile transaction server receives an account inquiry message from a merchant server, it retrieves from customer database 103 customer data relating to the customer's identification in the message. Most often the id is the telephone number of the customer. Based on customer data the mobile transaction server runs a query in database 102 in order to obtain information about the customer's solvency.
After receiving the "details of transaction" message from the mer-chant server the mobile transaction server starts processing: First, account-ing rules relating this case of a merchant's service and the customer are checked, stage 500. The rules determine how to handle this financial trans-action and the rules are stored in databases 103 and 104. Thereafter pay-ment transactions and sales transactions are processed.
Processing the payment transaction at stage 511 starts by calcu-lating the total amount of the purchase. All details needed for calculation are included into the "details of transaction" message. The meanings of the coded fields of the message are obtained from merchant database 104. In-formation about payment methods used by the customer is obtained from the customer database 103.
Processing the sale transaction 510 contains those parts of the transactions concerning products or services. Which product or service has been paid for, what the amount of products or services is, what the delivery dates are, this kind of processing is made at this stage. The results of proc-essing are stored in transaction database 503. Information stored in this da-tabase can be utilized for producing different kind of statistics.
Processing of accounts based on accounting rules is performed on stage 512. The rules tell when the accounts of the merchants and the customers are handled. After processing the accounts has been finished, the databases will be updated at stage 513. The virtual money account of the customer in database 102 is debited. Accordingly, the virtual money account of the merchant is credited with the same amount of money. Entries to a ledger are provided with appropriate information.
Finally, virtual invoices are created at stage 514. Invoices are 5 stored in invoice database 515 from which statements of accounts can be sent periodically.
The m-commerce system described above is applicable to any public access network. However, adapting to the Internet is not advisable because of problems in validation of the user. In contrast, adapting to a wire-10 less network is recommendable because validation of the user is easy, due to the fixed telephone number.
It is assumed in the previous description that the customer and the user are the same. However, a customer can be formed of several users.
For example, a family is a customer to which a certain solvency is recorded 15 in the m-commerce system. Each member of the family who has an own mobile phone is the user. Then, the purchases made by each family member are allocated to one single customer code and one single virtual account.
The invention is described in connection with a network provided with WAP services. However, the invented system can also be used in GSM
networks or in other digital mobile telecommunication networks. In these networks user call given services numbers and receives voice instructions.
Solvency of the user and billing are performed in the invented system.
Merchant server 12 often uses the HTTP format but it can also use the WAP format. The server includes contents that are WML pages in-s tended for sending to mobile phones. Between the subscriber terminal and the server there is gateway 11 including encoders/decoders which encode WAP content of a file received from the server into a suitable compact format for radio transmission and decode the encoded data received from a radio channel prior to further transmission to the server 12.
WAP phone 10 is provided with a textual browser, a search en-gine, etc., for displaying and interpreting a service received from server 12.
When using WAP services, a user selects one of the services displayed on the screen of the mobile phone. The browser sends a request to the mer-chant's server, which returns a content fetched from the content database.
After a plurality of request-content messages have been exchanged, the user finally selects one of the services or one of the goods being offered.
The price of the selected item of the service and the payment method are known by this stage at the latest. Then the server 12 inquires about the pay-ment method that the user will use. In response to the inquiry, the user sends an answer message to server 12. Said message 1 is labeled with "PAYMENT INFO" in FIG. 1.
After receiving message 1 "PAYMENT INFO", merchant server 12 forms solvency inquiry message 2 and sends it to the m-commerce system 100 according to the invention. The system checks user's solvency from the virtual account database and sends a reply message 3 both to WAP phone 10 and merchant server 12. If the user has solvency for the purchase, the merchant server forms a message 4 that includes the details of the transac-tion. Said message can be sent immediately to the nn-commerce system or several transaction details messages can be put together and send now and then to the m-commerce system.
The m-commerce system will be described now in detail. The core of the e-commerce system consists of a mobile transaction server 101. Per-manent data that service software of the system needs is stored in a plurality of databases.
A database 102 for virtual accounts consists of solvency informa-tion of the customers joined to the m-commerce system. For example, by joining the system each customer may insert into this database a certain amount of virtual money. At the same moment the real bank account may be debited with the same amount of real money. This virtual account can be called a pre-paid account. This account will debited by each purchase, wherein the method can also be called a direct debiting. Alternatively, the customer may have a credit account with a certain upper limit in the data-base. This alternative is practical if the user prefers a credit card.
Further, a customer may belong to an on-line paying system of an financial instance. For example, the customer has made a contract with a merchant in which the purchase will automatically and immediately be deb ited from the customer's bank account. This proceeding can be called a di-rect debiting method. In that case the customer's virtual account consists of information about paying proceeding in said on-line paying system.
A customer database 103 includes customer information that is stored in the database when a customer joins the m-commerce system. The customer's name and address are needed. Importantly, customer information contains an identification token (ID) of the customer. This is a token which arrives from the mobile telecommunications network within the inquiry mes sage sent by the merchant, and by the help of the token the m-commerce system is able to retrieve the customer information concerned from the cus-tomer database 103. Usually the token is the telephone number of the cus-tomer. Customer information also contains a reference to the virtual money accounts database 102 wherein the reference binds information about a cus-tomer and information about the customer's virtual account.
A merchant database 104 includes information about the mer-chants who are joined into the m-commerce system. Information about a merchant consists not only the merchant's name and address but also a list of the products and/or services that the merchant offers to the subscribers of the mobile communications network. To each of the products or services re-lates a price, a possible discount, a possible bonus, and other information that is needed for billing purposes. Preferably, an identifying code (ID) is at-tached to each merchant. When the merchant contacts the m-commerce system, the code may be used for identification purposes besides the IP ad-dress of the merchant's server.
Service software installed in the mobile transaction server in-cludes programs for managing customer data and merchant data, process-ing transactions, handling credit and solvency information, creating bills, per-forming account operations, and for processing transaction events for statis-tical purposes.
The m-commerce system also has interface B to external systems such as banks and other external systems. In addition, reports generated by the system are transmitted through this interface. The banks and other ex ternal systems can access the m-commerce system via this interface.
FIG. 2 shows the basic steps during purchasing. The protocol used in the session is the wireless application protocol (WAP). Messages, which are exchanged between the mobile terminal and the merchant server, go through a gateway (see FIG. 1). First a mobile terminal contacts a mer-chant server and sends a request. In response to the request the merchant server sends a content, which may be a menu, for example. The user selects an item from the menu whereupon the mobile terminal sends the second re-quest. The merchant server responds by sending the second content, which includes more detailed information of the selected menu item. After request-content message pairs have been sent N times, the user has got enough in-formation and makes a decision to order a service. The service might be an order for tickets to a movie, for example. In response to the order message the merchant server sends a payment inquiry message in which the mer-chant inquires how the user wishes to pay. The content of the menu in the message can include various alternatives like "credit card", "pre-pay", "on-line pay". Using the browser the user selects one method, in this example the selection is "credit card", and sends an answer message. It is important to note that no credit card number is transmitted.
In response to the payment method message the merchant server sends an solvency inquiry message to the mobile transaction server to the m-commerce system. The message contains only the user's identification, the value of the intended purchase, and the payment method selected by the user. Preferably, the user identification comprises the user's telephone num-ber, which the transmission network of the operator concerned transmits to the merchant server. The payment method in the payment inquiry message is a code only. Again, it is worth noting that no credit card number is transmit-ted in the message.
In response to the account inquiry message, the mobile transac-tion server first checks information about the user from the customer data-base and then the corresponding virtual account linked to that particular user. If the virtual account verifies that the liquidity of the credit card account is enough for covering the purchase, the mobile transaction server sends an acceptance message to the merchant server. But if the virtual account shows 5 that the user fails to have liquidity enough, the mobile transaction server sends a rejection message to the merchant server. In addition, the user of the mobile terminal is informed about the acceptance or rejection of the pur-chase. This information will end the session between the merchant and the user.
10 Now the merchant server prepares a second message to the mo-bile transaction server. The message, "Details of Transaction", includes all details of the purchase previously made. Consequently, the message in-cludes generally the merchant's identification code, which is also stored in the merchant data base 104, a product code, amount of the products, the price of the product, discount code and bonus code if such codes are used, and the payment method.
In addition, the operator of the network can deliver details of the call the user previously made to the mobile transaction server. Preferably, the operator sends the call data record (CDR) of the call. It is known that an exchange generates CDRs for each call. The CDR includes the caller's tele-phone number, starting and ending time of the call (time stamps), duration of the call, and the telephone number of the called party, the number being the uniform resource locator if the call has been a WAP call. The mobile transac-tion server can use the CDRs for authentication purposes, i.e. to be able to present, whenever needed, legally valid evidence that the call has really been made.
After the mobile transaction server has received the "details of transaction" message from the merchant, and possibly the CDR from the op-erator, it will start processing of the accounts using particulars given in the "details of transaction" message. Relevant databases will be updated, i.e. the user's virtual account will be debited, the merchant's account will be credited, and statistics will be created.
FIG. 3 depicts a practical example based on the steps of fig. 2.
Here the boxes on the left show contents of the display in the user's mobile phone. After the user has contacted a merchant server, which means that the browser has called the URL of the merchant server, the server transmits a menu content that is shown in box 31. The user selects "movies" and the selection will transmit through the transmission network to the merchant server. The server returns content 32 that is a list of movies. The user's se-lection "movie 3" is transmitted to the merchant server that returns content 33. It tells both the theater at which the selected movie is on and also times when the movie is shown. In this manner the user selects the delivery date (it is possible to buy a ticket no more than seven days beforehand), content 34, and the price of the ticket, content 35. Thereafter the merchant server asks to confirm the selection, content 36. The user confirms by clicking "yes"
whereupon the merchant server inquires the payment method, content 37.
Here two alternatives are shown, namely the user can pay with a credit card or with the pre-pay option. In the latter case the user has inserted solvency beforehand to the virtual account in the m-commerce system.
The user selects "credit card", whereupon the payment method message is transmitted to the merchant server. In response to this message the merchant server sends through the transmission network a solvency in-quiry message to the mobile transaction server, stage 38. The message in-cludes the mobile phone number of the user, a code of the payment method, here credit card, and the value of the intended purchase. In addition, the message includes the address of the merchant server so that the mobile transaction server is able to send a reply to the right address.
After receiving the payment info message, the mobile transaction server makes a query in the customer database for obtaining customer data that relates to the mobile phone number of the user. The customer data in-cludes a pointer to the customer's credit card account in the virtual money database so that the mobile transaction server is able to find out whether or not there is solvency enough for the purchase. If the answer is "yes" the mo-bile transaction server replies to the credit card message by sending an ap-proval message to the merchant server, stage 310. In response to the ap-proval message, the merchant server forwards the acceptance to the user, stage 311. The user's share in commercial transactions ends by receiving the acceptance message from the merchant.
The essential part of the steps of the present invention will start now. The merchant server sends all appropriate details about the above described purchase to the mobile transaction server, stage 311. The mobile transaction server will start processing the received data the result of which will be debiting the virtual account of the customer and crediting the virtual account of the merchant.
FIG. 4A and 4B show contents of the messages transmitted from the mobile telecommunications network to the mobile transaction server. An exchange in a mobile telecommunications network, like in a PSTN network, produces a call data record for each call. As shown in FIG. 4A, the record contains basic information about the call. For example, the CDR of a WAP
call includes identification of the user that made the call. This is most com-monly the mobile telephone number of the user. Then the CDR includes the start time and end time of the call, duration of the call, the amount of data transferred during the call, and the address of the called party. In the WAP
call the address is the URL (Uniform Resource Locator) of a merchant's server. A message of this type is sent to the mobile transaction server after the call. Said server stores the CDR for safety reasons. Moreover, if a ser-vice offered by a merchant contains downloadable files or the service is tied to the duration of the call, the duration field of the CDR can directly be used for billing.
FIG. 4B shows the contents of the "details of transaction" mes-sage of fig. 4 that the merchant server sends to the mobile transaction server. The message is comprised of the ID of the calling party, that is the user's mobile telephone number, and a product code. Each product the mer-chant offers to users has its own unique code. The real description of the code is stored in the merchant database. Further, the message contains the number of sold products; here the numbers of the tickets, a currency code if different currencies are in use, unit price of the product, and value added tax percentage. If discounts or bonuses are in use, their codes follow in the message. The merchant code identifies the merchant and the rest of the fields tell the order date and time and the delivery date and time.
Information in some of the fields is coded in order to shorten the message. Each piece of coded information has its clear text counterpart in the merchant database.
Based on this type of a message the mobile transaction server is able to per-form all necessary actions.
The actions described with reference to FIG. 5 depict some basic functions of the mobile transaction server. The main functions of the mobile transaction server consist of management of customer data, management and forwarding of credit status and liquidity information, and carrying out in-voicing and accounting. The mobile transaction server is a centralized sys-tem and both a merchant and a customer i.e. a subscriber of a mobile tele-communications network, have to join the system by making a contract with the system operator.
The server includes a plurality of databases and service pro-grams. Database 102 contains virtual account information of every customer joined to the m-commerce system. The account information can be the amount of virtual money that the customer has put into the e-commerce sys-tem. This can be called a pre-pay method. It can also be a credit limit of a credit card. Other possible ways to open a virtual account are possible.
Database 103 contains relevant data of every customer joined to the m-commerce system. Such data are at least the name, the address, and payment methods. By joining the m-commerce system the customer has to make a contract with the operator of the system whereupon the customer designates the payment methods. The customer can designate one or all payment methods that the system offers. The operator opens a virtual ac-count for each payment method. Thus, the customer database also includes references to virtual accounts that the customer has. The references can be links, indexes, pointers etc. depending on the programming language.
In addition, database 103 may include information about particular characters of the customer. Such characters tell that the customer belongs to a certain bonus or discount system, the customer is a member of a commer-cial group so enjoying so benefits, for example.
Database 104 contains relevant data of every merchant joined to the m-commerce system. By joining the m-commerce system the merchant has to make a contract with the operator of the system, whereupon all rele vant data about the merchant, services, and products are input to the m commerce system. The merchant also designates the payment methods.
Further, it is agreed in the contract, which services of the mobile transaction server the merchant will to buy. Said relevant data are at least the name, the address, a merchant's code, and information abut banking accounts of the merchant. In addition, each merchant has in database 104 data relating to every product and/or service being offered by the merchant. Such data in-clude codes and corresponding plain text. Such data are needed to decode information of a "details of transaction" message (see Fig. 4) and for billing, accounting, and statistical purposes.
Transactions database 503 is intended for storage details of the transactions. Thus, it contains historical knowledge about transactions. Data in this database can be processed for making different kind of statistical analyses which are needed in order to make sales curves, sales forecasts, marketing, sales campaigns, customer profiles etc.
Invoice database 515 includes information about what has been billed. Data in this database can be used for producing statements of ac-counts which are send to the customers.
When the mobile transaction server receives an account inquiry message from a merchant server, it retrieves from customer database 103 customer data relating to the customer's identification in the message. Most often the id is the telephone number of the customer. Based on customer data the mobile transaction server runs a query in database 102 in order to obtain information about the customer's solvency.
After receiving the "details of transaction" message from the mer-chant server the mobile transaction server starts processing: First, account-ing rules relating this case of a merchant's service and the customer are checked, stage 500. The rules determine how to handle this financial trans-action and the rules are stored in databases 103 and 104. Thereafter pay-ment transactions and sales transactions are processed.
Processing the payment transaction at stage 511 starts by calcu-lating the total amount of the purchase. All details needed for calculation are included into the "details of transaction" message. The meanings of the coded fields of the message are obtained from merchant database 104. In-formation about payment methods used by the customer is obtained from the customer database 103.
Processing the sale transaction 510 contains those parts of the transactions concerning products or services. Which product or service has been paid for, what the amount of products or services is, what the delivery dates are, this kind of processing is made at this stage. The results of proc-essing are stored in transaction database 503. Information stored in this da-tabase can be utilized for producing different kind of statistics.
Processing of accounts based on accounting rules is performed on stage 512. The rules tell when the accounts of the merchants and the customers are handled. After processing the accounts has been finished, the databases will be updated at stage 513. The virtual money account of the customer in database 102 is debited. Accordingly, the virtual money account of the merchant is credited with the same amount of money. Entries to a ledger are provided with appropriate information.
Finally, virtual invoices are created at stage 514. Invoices are 5 stored in invoice database 515 from which statements of accounts can be sent periodically.
The m-commerce system described above is applicable to any public access network. However, adapting to the Internet is not advisable because of problems in validation of the user. In contrast, adapting to a wire-10 less network is recommendable because validation of the user is easy, due to the fixed telephone number.
It is assumed in the previous description that the customer and the user are the same. However, a customer can be formed of several users.
For example, a family is a customer to which a certain solvency is recorded 15 in the m-commerce system. Each member of the family who has an own mobile phone is the user. Then, the purchases made by each family member are allocated to one single customer code and one single virtual account.
The invention is described in connection with a network provided with WAP services. However, the invented system can also be used in GSM
networks or in other digital mobile telecommunication networks. In these networks user call given services numbers and receives voice instructions.
Solvency of the user and billing are performed in the invented system.
Claims
What is claimed is:
1.A mobile telecommunications network-based sales transaction system comprising:
at least one mobile transaction server;
at least one mobile terminal for operation by a customer desiring to purchase a product or service;
at least one merchant server containing promotional information for communication to the mobile terminal, the information being intended to give the customer sufficient information to make a decision to purchase a product or service;
the mobile terminal being adapted to send a payment message containing information about payment method to the merchant server;
the merchant server being adapted in response to said payment message to send, via the network, an inquiry message to the mobile transac-tion server, the inquiry message containing a network identification of the customer, the price of the purchase and a notification about the payment method, and in response to an answer message received from the mobile transaction server to send a message containing details of the sale to the mobile transaction server;
the mobile transaction server containing financial data therein, said financial data including solvency data relating to payment methods of the customers joined the system and virtual accounts of the merchants joined the system;
the mobile transaction server further containing information about the merchants, product data and service data, and information about cus-tomers;
the mobile transaction server being programmed, in response to the inquiry message, to check solvency data relating to the notified payment method and to cause the answer message to be sent to the merchant server;
the mobile transaction server further being programmed, in re-sponse to the message containing details of the sale, to cause solvency of the customer to be diminished and the virtual account of the merchant to be credited.
2. A mobile telecommunications network-based sales transaction system as in claim 1, wherein said solvency data correspond to a deposit that the customer has transferred to said sales transaction system, wherein the payment method is a prepay option.
3. A mobile telecommunications network-based sales transaction system as in claim 1, wherein said solvency data correspond to a limit of a credit card account that the customer has transferred to said sales transac-tion system.
4. A mobile telecommunications network-based sales transaction system as in claim 1, wherein said solvency data inform of the use of direct debiting, wherein a real bank account of the customer will be debited.
5. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the virtual account of a merchant correspond to income from sales.
6. A mobile telecommunications network-based sales transaction system as in claim 1, wherein information about each of the merchants com-prises identity data, real bank account numbers, and an individual merchant code.
7. A mobile telecommunications network-based sales transaction system as in claim 1, wherein information about each of the merchants fur-ther comprises accounting rules.
8. Mobile telecommunications network-based sales transaction systems as in claim 1, wherein information about each of the customers con-tain identity data and network identification.
9. Mobile telecommunications network-based sales transaction systems as in claim 8, wherein the network identification of the customer is the mobile subscriber identification number.
10. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed, in response to the message containing details of the sale, to produce an invoice.
11. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed to yield statistics of the sales.
12. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed to perform clearing of the accounts.
13. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed to establish connections to external financial institutions for ex-changing data.
14. A mobile telecommunications network-based sales transaction system as in claim 1, wherein details in the message containing details of the sale are coded and the meanings of the codes are stored in the mobile transaction server.
15. Mobile telecommunications network-based sales transaction systems as in claim 1, wherein financial data, information about the custom-ers, information about the merchants, and information about sales are stored in databases.
16. Mobile telecommunications network-based sales transaction systems as in claim 15, wherein said databases are updated after each transaction.
17. A mobile telecommunications network-based sales transaction system as in claim 15, wherein said databases are updated by external con-trol connections.
18. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile telecommunications network send a call data record CDR to the mobile transaction server after the customer has finished the call.
19. A method of performing sales transactions in a mobile tele-communications network comprising at least one mobile transaction server;
at least one mobile terminal for operation by a customer desiring to purchase a product or service, and at least one merchant server containing promo-tional information for communication to the mobile terminal, the information being intended to give the customer sufficient information to make a decision to purchase a product or service; the method comprising the steps of:
storing solvency data of customers beforehand in the mobile transaction server;
sending from the mobile terminal to the merchant server a pay-ment message containing information about payment method and a network identification of the customer;
forming, in response to said payment message, an inquiry mes-sage containing a network identification of the customer, a merchant code, the price of the purchase and a notification about the payment method;
sending the inquiry message from the merchant server to the mo-bile transaction server;
checking in the mobile transaction server solvency data relating to the notified payment method and sending an answer message to the mer-chant server;
sending in response to the answer message a sale message con-taining details of the sale to the mobile transaction server;
processing in response to the sale message the sales transaction;
changing the solvency of the customer, and;
crediting a virtual account of the merchant.
20. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
retrieving from a database customer data relating to the network identification;
retrieving from another database solvency information corre-sponding to the customer data.
21. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
retrieving from the database merchant data relating to the mer-chant code.
23. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
decoding the sale message by using merchant data;
checking accounting rules from the database;
creating an invoice by using information of the decoded sale mes-sage.
25. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
using the mobile subscriber number as the network identification of the customer.
26. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
storing in a sales database sale information to be used in creating statistics.
27. A method of performing sales transactions in a mobile tele-communications network as in claim 20 or 27, further comprising the step of:
updating the databases after processing the sales transaction.
29. A method of performing sales transactions in a mobile tele-communications network as in claim 20 or 27, further comprising the step of:
updating the databases via external control connections.
30. A method of performing sales transactions in a mobile tele-communications network as in claim29, wherein the external control connec-tions are established to financial institutions.
31. A sales transaction server comprising:
a database for storing financial data therein, said financial data in-cluding solvency data relating to payment methods of customers and virtual accounts of merchants offering, through a public access network, products or services to the customers;
another database containing information about the merchants, product data and service data, and information about the customers;
the sales transaction server being programmed, in response to a solvency inquiry message which was sent by a merchant server via the pub-lic access network and which contains a network identification of the cus-tomer, the price of the purchase and a notification about the payment method, to check solvency data relating to the notified payment method and to cause the answer message to be sent to the merchant server;
the mobile transaction server further being programmed, in re-sponse to the message which contains details of the sale sent and which was sent by the merchant server, to cause solvency of the customer to be diminished and the virtual account of the merchant to be credited.
32. A sales transaction server as in claim 31, wherein said sol-vency data correspond to a deposit that the customer has transferred to the database.
33. A sales transaction server as in claim 31, wherein said sol-vency data correspond to a limit of a credit card account that the customer has transferred to the database.
34. A sales transaction server as in claim 31, wherein the virtual account of the merchant correspond to income from sales.
35. A sales transaction server as in claim 31, wherein information about each of the merchants, stored in another database, comprises identity data, real bank account numbers, and an individual merchant code.
36. A sales transaction server as in claim 31, wherein information about each of the customers; stored in another database, contain identity data and network identification.
37. A sales transaction server as in claim 36, wherein the network identification of the customer is the telephone number.
38. A sales transaction server as in claim 31, further being pro-grammed to yield statistics of the sales.
39. A sales transaction server as in claim 31, further being pro-grammed to perform clearing of the accounts.
40. A sales transaction server as in claim 31, wherein further be-ing programmed to establish connections to external financial institutions for exchanging data.
41. A sales transaction server as in claim 31, wherein said data-bases are updated periodically
1.A mobile telecommunications network-based sales transaction system comprising:
at least one mobile transaction server;
at least one mobile terminal for operation by a customer desiring to purchase a product or service;
at least one merchant server containing promotional information for communication to the mobile terminal, the information being intended to give the customer sufficient information to make a decision to purchase a product or service;
the mobile terminal being adapted to send a payment message containing information about payment method to the merchant server;
the merchant server being adapted in response to said payment message to send, via the network, an inquiry message to the mobile transac-tion server, the inquiry message containing a network identification of the customer, the price of the purchase and a notification about the payment method, and in response to an answer message received from the mobile transaction server to send a message containing details of the sale to the mobile transaction server;
the mobile transaction server containing financial data therein, said financial data including solvency data relating to payment methods of the customers joined the system and virtual accounts of the merchants joined the system;
the mobile transaction server further containing information about the merchants, product data and service data, and information about cus-tomers;
the mobile transaction server being programmed, in response to the inquiry message, to check solvency data relating to the notified payment method and to cause the answer message to be sent to the merchant server;
the mobile transaction server further being programmed, in re-sponse to the message containing details of the sale, to cause solvency of the customer to be diminished and the virtual account of the merchant to be credited.
2. A mobile telecommunications network-based sales transaction system as in claim 1, wherein said solvency data correspond to a deposit that the customer has transferred to said sales transaction system, wherein the payment method is a prepay option.
3. A mobile telecommunications network-based sales transaction system as in claim 1, wherein said solvency data correspond to a limit of a credit card account that the customer has transferred to said sales transac-tion system.
4. A mobile telecommunications network-based sales transaction system as in claim 1, wherein said solvency data inform of the use of direct debiting, wherein a real bank account of the customer will be debited.
5. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the virtual account of a merchant correspond to income from sales.
6. A mobile telecommunications network-based sales transaction system as in claim 1, wherein information about each of the merchants com-prises identity data, real bank account numbers, and an individual merchant code.
7. A mobile telecommunications network-based sales transaction system as in claim 1, wherein information about each of the merchants fur-ther comprises accounting rules.
8. Mobile telecommunications network-based sales transaction systems as in claim 1, wherein information about each of the customers con-tain identity data and network identification.
9. Mobile telecommunications network-based sales transaction systems as in claim 8, wherein the network identification of the customer is the mobile subscriber identification number.
10. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed, in response to the message containing details of the sale, to produce an invoice.
11. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed to yield statistics of the sales.
12. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed to perform clearing of the accounts.
13. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile transaction server further being programmed to establish connections to external financial institutions for ex-changing data.
14. A mobile telecommunications network-based sales transaction system as in claim 1, wherein details in the message containing details of the sale are coded and the meanings of the codes are stored in the mobile transaction server.
15. Mobile telecommunications network-based sales transaction systems as in claim 1, wherein financial data, information about the custom-ers, information about the merchants, and information about sales are stored in databases.
16. Mobile telecommunications network-based sales transaction systems as in claim 15, wherein said databases are updated after each transaction.
17. A mobile telecommunications network-based sales transaction system as in claim 15, wherein said databases are updated by external con-trol connections.
18. A mobile telecommunications network-based sales transaction system as in claim 1, wherein the mobile telecommunications network send a call data record CDR to the mobile transaction server after the customer has finished the call.
19. A method of performing sales transactions in a mobile tele-communications network comprising at least one mobile transaction server;
at least one mobile terminal for operation by a customer desiring to purchase a product or service, and at least one merchant server containing promo-tional information for communication to the mobile terminal, the information being intended to give the customer sufficient information to make a decision to purchase a product or service; the method comprising the steps of:
storing solvency data of customers beforehand in the mobile transaction server;
sending from the mobile terminal to the merchant server a pay-ment message containing information about payment method and a network identification of the customer;
forming, in response to said payment message, an inquiry mes-sage containing a network identification of the customer, a merchant code, the price of the purchase and a notification about the payment method;
sending the inquiry message from the merchant server to the mo-bile transaction server;
checking in the mobile transaction server solvency data relating to the notified payment method and sending an answer message to the mer-chant server;
sending in response to the answer message a sale message con-taining details of the sale to the mobile transaction server;
processing in response to the sale message the sales transaction;
changing the solvency of the customer, and;
crediting a virtual account of the merchant.
20. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
retrieving from a database customer data relating to the network identification;
retrieving from another database solvency information corre-sponding to the customer data.
21. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
retrieving from the database merchant data relating to the mer-chant code.
23. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
decoding the sale message by using merchant data;
checking accounting rules from the database;
creating an invoice by using information of the decoded sale mes-sage.
25. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
using the mobile subscriber number as the network identification of the customer.
26. A method of performing sales transactions in a mobile tele-communications network as in claim 19, further comprising the step of:
storing in a sales database sale information to be used in creating statistics.
27. A method of performing sales transactions in a mobile tele-communications network as in claim 20 or 27, further comprising the step of:
updating the databases after processing the sales transaction.
29. A method of performing sales transactions in a mobile tele-communications network as in claim 20 or 27, further comprising the step of:
updating the databases via external control connections.
30. A method of performing sales transactions in a mobile tele-communications network as in claim29, wherein the external control connec-tions are established to financial institutions.
31. A sales transaction server comprising:
a database for storing financial data therein, said financial data in-cluding solvency data relating to payment methods of customers and virtual accounts of merchants offering, through a public access network, products or services to the customers;
another database containing information about the merchants, product data and service data, and information about the customers;
the sales transaction server being programmed, in response to a solvency inquiry message which was sent by a merchant server via the pub-lic access network and which contains a network identification of the cus-tomer, the price of the purchase and a notification about the payment method, to check solvency data relating to the notified payment method and to cause the answer message to be sent to the merchant server;
the mobile transaction server further being programmed, in re-sponse to the message which contains details of the sale sent and which was sent by the merchant server, to cause solvency of the customer to be diminished and the virtual account of the merchant to be credited.
32. A sales transaction server as in claim 31, wherein said sol-vency data correspond to a deposit that the customer has transferred to the database.
33. A sales transaction server as in claim 31, wherein said sol-vency data correspond to a limit of a credit card account that the customer has transferred to the database.
34. A sales transaction server as in claim 31, wherein the virtual account of the merchant correspond to income from sales.
35. A sales transaction server as in claim 31, wherein information about each of the merchants, stored in another database, comprises identity data, real bank account numbers, and an individual merchant code.
36. A sales transaction server as in claim 31, wherein information about each of the customers; stored in another database, contain identity data and network identification.
37. A sales transaction server as in claim 36, wherein the network identification of the customer is the telephone number.
38. A sales transaction server as in claim 31, further being pro-grammed to yield statistics of the sales.
39. A sales transaction server as in claim 31, further being pro-grammed to perform clearing of the accounts.
40. A sales transaction server as in claim 31, wherein further be-ing programmed to establish connections to external financial institutions for exchanging data.
41. A sales transaction server as in claim 31, wherein said data-bases are updated periodically
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US56859100A | 2000-05-11 | 2000-05-11 | |
| US09/568,591 | 2000-05-11 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2344749A1 true CA2344749A1 (en) | 2001-11-11 |
Family
ID=24271900
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002344749A Abandoned CA2344749A1 (en) | 2000-05-11 | 2001-04-24 | A mobile telecommunications network-based sales transaction system |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP2002007935A (en) |
| CA (1) | CA2344749A1 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8660948B2 (en) * | 2010-07-02 | 2014-02-25 | Qualcomm Incorporated | System and method for managing transactions with a portable computing device |
-
2001
- 2001-04-24 CA CA002344749A patent/CA2344749A1/en not_active Abandoned
- 2001-05-07 JP JP2001136260A patent/JP2002007935A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002007935A (en) | 2002-01-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7487126B2 (en) | Computer network method for conducting payment over a network by debiting and crediting utilities accounts | |
| US7248855B2 (en) | Convergent communications system and method with a rule set for authorizing, debiting, settling and recharging a mobile commerce account | |
| US7461010B2 (en) | Computer network method for conducting payment over a network by debiting and crediting telecommunication accounts | |
| US7437328B2 (en) | Value insertion using bill pay card preassociated with biller | |
| US8244612B2 (en) | Inserting value into customer account at point of sale using a customer account identifier | |
| US20070266130A1 (en) | A System and Method for Presenting Offers for Purchase to a Mobile Wireless Device | |
| US20080162348A1 (en) | Electronic-Purse Transaction Method and System | |
| KR20070057668A (en) | Inserting value into customer account at point of sale using a customer account indetifier | |
| MXPA04011153A (en) | System and method for adding value to a stored-value account. | |
| EP2153390A1 (en) | Application server and/or method for supporting mobile electronic commerce | |
| AU2001247953B2 (en) | System and method for purchasing goods and services through financial data network access points | |
| AU2001247953A1 (en) | System and method for purchasing goods and services through financial data network access points | |
| KR20090110387A (en) | Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment | |
| JP5695685B2 (en) | Centralized communications platform and method for mobile and electronic commerce in heterogeneous network environments | |
| JP2004164598A (en) | Methods for maintaining prepaid account information and for supporting transactions in an e-commerce system | |
| CA2546911A1 (en) | A system and method for presenting offers for purchase to a mobile wireless device | |
| FI105860B (en) | Procedure for the execution of a trading service | |
| CA2344749A1 (en) | A mobile telecommunications network-based sales transaction system | |
| EP4016426A1 (en) | Method and system for exchanging sms, mms and/or call into cash or funds in a bank account | |
| KR20030051572A (en) | Transit method of van system within wire and wireless integration for credit settlement and settlement agency | |
| KR20090004831A (en) | System for sharing communication service profits | |
| WO2007038936A1 (en) | Method for real-time distributing of benefits in an electronic system | |
| KR20080103617A (en) | System and method for sharing communication service profits and program recording medium | |
| ZA200303044B (en) | Remote payment method and system. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |