WO2006023745A2

WO2006023745A2 - Conducting secure financial transactions independent of physical location

Info

Publication number: WO2006023745A2
Application number: PCT/US2005/029586
Authority: WO
Inventors: Mounir Shita; Timothy M. Wyatt; Darin Lacount; Aaron B. Sternberg; Richard Warnick
Original assignee: Paywi Corporation
Priority date: 2004-08-19
Filing date: 2005-08-19
Publication date: 2006-03-02
Also published as: WO2006023745A3

Abstract

A method of and system for operating a network (10) within which wired and wireless devices (22, 24) interconnect enable performance of secure financial transactions between a recipient and a provider of services or goods, independent of the physical locations of the recipient and the provider.

Description

CONDUCTING SECURE FINANCIAL TRANSACTIONS INDEPENDENT

OF PHYSICAL LOCATION

Related Applications

[0001] This application claims benefit of U.S. Provisional Patent Application Nos. 60/705,626 and 60/603,231 , filed August 3, 2005 and August 19, 2004, respectively.

Copyright Notice

[0002] © 2005 PayWi Corporation. A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 37 CFR § 1.71 (d).

Technical Field

[0003] The present invention relates to performing financial transactions through communication links between a provider and a recipient of goods or services and, in particular, to a method of and system for using a globally accessible communication network to perform secure financial transactions between the recipient and provider, independent of their physical locations.

Background Information

[0004] There are several business organizations that provide credit card payment processing.

[0005] Pay By Touch, San Francisco, California, allows consumers to store their fingerprint data and their financial accounts in a database operated by Pay By Touch. To pay for his goods, a consumer places his finger on a fingerprint reader at participating stores. The Pay By Touch approach does not require consumers to carry their credit cards or checks, thereby reducing the risk of identity theft. Because the Pay by I ouch technology requires the consumer to touch a piece of equipment owned by the merchant, the possibility of skimming exists. This technology enables only point-of-sale transactions and does not allow bill payments, eCommerce, wire transfers, and other financial transactions. Moreover, this technology requires merchants to purchase new credit card terminals or plug-in modules to their parent credit card terminals.

[0006] BioPay, Herndon, Virginia, uses biometrics for merchants and retailers to identify and verify their customers and thereby enhance their payment transactions. As in the case of Pay By Touch, the BioPay technology does not require consumers to carry their credit cards or checks, thereby reducing the risk of identity theft. Because the BioPay technology requires the consumer to touch a piece of equipment owned by the merchant, the possibility of skimming exists. This technology is only for point-of-sale transactions and does not allow bill payments, eCommerce, wire transfers, and other financial transactions. This technology requires merchants to purchase new credit card terminals or plug-in modules to their current credit card terminals. Moreover, the BioPay approach supports only ACH transactions and, therefore, does not accommodate credit card transactions. [0007] Mobile Lime, Boston, Massachusetts, uses a customer's mobile telephone as a payment device and loyalty card at Mobile Lime-participating merchants. At the point-of-sale, the customer tells the cashier that he wants to pay using Mobile Lime. The cashier enters the information on a credit card terminal, which information is then sent to a Mobile Lime server. The customer then dials the Mobile Lime telephone number and, when asked, enters his PIN and the merchant's unique location ID number to complete the transaction. The Mobile Lime system does not use GPRS/EDGE or any other form of wireless data transfer and is, therefore, guaranteed to work on all cellular telephones. Because the Mobile Lime system does not use GPRS/EDGE or any other form of wireless data transfer, this technology can rely only on the existing security protocols implemented by wireless service providers. These security protocols are required to have a back door to enable law enforcement and government agencies to listen to live conversation. Criminals also have the ability to access this back door and potentially steal a customer's PIN. Because each payment request sent to the Mobile Lime server is linked to a merchant and not to a customer, a merchant can bill only one customer at a time. This is acceptable for point-of-sale transactions, but it is not possible to perform bill payments. Moreover, this technology cannot support any other form of financial transaction, such as a wire transfer.

[0008] PayPal, San Jose, California, offers a service that enables any individual or business with an e-mail address to securely send and receive payments on line. The PayPal service builds on the existing financial infrastructure of bank accounts and credit cards and uses proprietary fraud prevention systems to create a safe, global, real-time payment technique. In most cases, the consumer does not need to reveal his credit card number; only an e-mail address is required. PayPal is restricted to online payments and money transfers and cannot be used at point-of- sale. Making payments using PayPal service takes the consumer away from the merchant's website to the PayPal website. This not only may create a bad image for the merchant, but also removes the consumer's focus on the eCommerce site he originally visited, thereby increasing the chance of abandonment of the purchase. [0009] C-Sam, Inc., Oakbrook Terrace, Illinois, offers technology that allows issuing banks to issue cards directly to a user's mobile telephone display. The issuer's logo will appear on the mobile telephone. All credit card information is stored on the mobile telephone. A lost telephone would require the user to cancel the credit card account. This technology works only on high-end telephones that have IR or Bluetooth features and requires the customer to be at the point-of-sale location. Wireless web can also be used to pay using only a high-end telephone. For low-end telephones, payment can be accomplished by typing and sending an unsecured text message.

Summary of the Invention

[0010] A method of and system for operating a network with which wired and wireless devices interconnect enable performance of secure financial transactions between a recipient and a provider of services or goods, independent of the physical locations of the recipient and the provider. (A glossary of terms used in this patent application appears at the end of the document.) The financial transactions system and method enable, by way of illustration, a person, while sitting on a bus on his way to work, to transfer funds across the nation to another person; a consumer to pay her monthly bills while vacationing at an overseas beach resort; a customer to approve a charge made at a local store; or a customer to order refreshments without leaving his seat during a sports entertainment event. [uuπj A preferred method of effecting a secure transaction between a recipient and a provider of goods or services is implemented by establishing communication links between the provider and the recipient through a server gateway. The server gateway receives, in response to action initiated by a recipient, a transmission of a first set of transaction information that includes recipient identification information and a request for a transaction. The server application operating on the server gateway operates to confirm the recipient identification information and processes a payment operation corresponding to the request for a transaction. In response to action by a provider, the server gateway transmits to a communication device associated with the recipient a second set of transaction information to which the recipient can respond. The server gateway receives, by secure transmission from the recipient in response to the second set of transaction information, an instruction as to whether to proceed with the transaction requested. The server application on the server gateway operates to initiate a payment process in response to the recipient's instruction to proceed with the transaction. The gateway server communicates transaction status information to communication equipment associated with the provider to inform the provider about the state of the transaction. [0012] A preferred system for carrying out the method is designed to allow full mobility for the recipient while still accomplishing a secure transaction from any location where wired or wireless network access exists. The preferred system is configured in a way that allows current providers and recipients to link their existing communications devices to a system financial transactions server associated with the server gateway. Such a system allows a recipient to pay for goods or services, transfer funds, or conduct any other financial transaction from the recipient's mobile device, irrespective of where the recipient is located, or from any wired device that is connected to a network. The utility and versatility of the preferred system is established by absence of a requirement that a recipient be at a particular location at the time of the transaction. To preserve this mobility, a recipient is provided an ability to perform financial transactions from any place that has wired access, GPRS/EDGE coverage, or any other type of wireless data coverage (e.g., CDMA, GSM, UMTS, 3G, or WLAN).

[0013] It is also vital that all of these transactions be done in a way that cannot be compromised, thereby making security a main issue addressed by the financial transactions method and system for carrying it out. [0014] Additional aspects and advantages will be apparent from the following detailed description of preferred embodiments, which proceeds with reference to the accompanying drawings.

Brief Description of the Drawings

[0015] Fig 1 is a simplified block diagram showing wireless communication links established among provider and recipient communication devices and a financial transactions server to perform secure financial transactions. [0016] Fig. 2 is a block diagram of a system server suitably configured to implement preferred methods of performing secure financial transactions in accordance with the invention.

[0017] Figs. 3-1 - 3-6 are illustrations of display images presented on a mobile communication device to a customer during a payment process. [0018] Figs. 3-7 and 3-8 are illustrations of display images presented on a mobile communication device to a customer using a pay at table solution payment process feature.

[0019] Figs. 4A and 4B are, respectively, a mobile payment process diagram and a mobile payment process flowchart summarizing in general the process steps performed in an exemplary commercial transaction.

[0020] Figs. 5A and 5B are, respectively, a mobile commerce process diagram and a mobile commerce flowchart summarizing in general the process steps performed in an exemplary mobile commerce transaction.

Detailed Description of Preferred Embodiments

[0021] Fig. 1 is a simplified block diagram illustrating generally a preferred system 10 in which wireless communication links form instruction and data information communication paths 12 and 14 between a financial transactions server 20 and respective communication devices 22 and 24. Communication device 22 is a communication device of a provider or merchant, and communication device 24 is preferably a mobile communication device of a recipient or customer (sometimes referred to as consumer). A communication path 26 between merchant communication device 22 and customer communication device 24 may be established by a wireless communication link or spoken words communicated between the customer and the merchant.

[0022] Fig. 2 is a block diagram of a preferred embodiment of financial transactions server 20 configured to establish through a server or an access gateway 30 communication links between a provider and a recipient of goods or services. (An access gateway 30 can be of several types, including, for example, a web browser, point of sale terminal, mobile device, or point of sale application.) This embodiment constitutes a passive system in that server 20 does not perform an open gateway operation on its own. A passive system allows a recipient to register more than one device to his account. For example, a married couple might want separate access from different devices to the same, shared account. Another example is computer software operating to act like a recipient device that allows a recipient to perform authorizations directly from his computer when he is at home and from a mobile device when he is in transit. To make this system useful, from a recipient's point of view, system 10 does not require the recipient to initiate a payment transaction except during an mCommerce process (e.g., on a money transfer transaction, system 10 recognizes the initiating user as a merchant). [0023] With reference to Fig. 2, server 20 includes a data management layer 40, which provides management and persistent storage of data. Data management layer 40 provides two primary data storage services, which include persistence services (cache memory stores) 42 for management of persistent data objects and a data storage system 44 for concrete storage of data.

[0024] A business services layer 50 provides core application program interfaces for logical business transactions. Business services layer 50 includes a business domain model 52, which provides an object-oriented view of entities in the financial transactions system data model, and an event distribution service 54. Business domain model 52 records information relating to client contacts, participating merchants, credit accounts, billing matters, and similar financial transaction related categories. Event distribution service 54 notifies business services layer entities of import activities within server 20 that are originated by other business layer entities. These event notifications enable coordination of information or instruction distribution to participating application programs operating to effect a financial transaction. Business services layer 50 also includes application program interfaces that execute logical sequences of operations against business domain model 52 to realize system functionality.

[0025] Business services layer 50 includes a number of application programs. An account holder registration program 58 enables providers and recipients of services or goods to participate in the financial transaction service by either the World Wide Web or a customer service representative at a physical registration kiosk location. An account management program 60 performs account configuration management functions (e.g., add and update security credentials, payment processing information, and contact information) transactions relating to specific customer accounts. A billing business service 62 and a payment processing program 64 operate to process, respectively, billing and payment transactions associated with individual customer accounts. An accounting program 66 carries out internal service provider bookkeeping functions relating to overall system operations. [0026] A security services layer 70 provides security-oriented services to other subsystems. Security services include authentication service 72 of system users and system processes performing actions autonomously within the system, access control service 74 for security-sensitive actions based on a current authenticated context, confidentiality service 76 for encrypting sensitive data, auditing service 78 for tracking sensitive operations and policy violations, and alerting service 80 for notifying system operators of policy violations.

[0027] A service applications layer 90 encapsulates high-level functional workflows within server 20. Service applications layer 90 includes application programs directed at specific classes of system users and include consumer applications 92, merchant applications 94, and provider applications 96. [0028] Consumer applications 92 include verification of registration 98 for customer activity enablement, account management functions 100 and bill payment application 102 in response to customer transactions, and customer service functions 104. Merchant applications 94 include merchant registration 110, merchant account management 112, merchant billing application 114, and customer service 116 functions analogous to those of their consumer application counterparts. Provider applications 96 include payment processing application 120, customer service functions 122, accounting and billing interface 124, system management 126, and other operational support applications for the service provider. [0029] Access gateway 30 provides a pathway to access service applications layer 90 from client applications, which reside outside server 20. Examples of client applications include those residing on a mobile device (e.g., customer communication device 24) or a device (e.g., merchant communication device 22) at a merchant's premises. The web gateway services accomplish access from a thin client 130 (typically a web browser) using the HTTP protocol over Internet transport protocols to form mobile application communication link 14 or merchant application communication link 12. A point of sale (e.g., credit card) terminal gateway 132 provides an interface tailored toward interaction with point of sale devices. A mobile device gateway 134 provides secure transport for low-power portable devices (e.g., cellular telephones) to access server 20. A point of sale application 136 provides an application program interface for access to payment services of business services layer 50 from nonterminal-based point of sale and billing systems. [0030] The following general example of a transaction processed through server 20 demonstrates the operation of its multiple functional layers. A transaction is initiated by a merchant who uses merchant communication device 22 to send over merchant application communication link 12 a payment request to an access gateway 30. A merchant can be a retail outlet, a billing company, or an eCommerce business. The particular application of the access gateway invoked depends on the equipment used by the merchant. Access gateway 30 consults authentication service 72 to validate the identity of the merchant submitting the request. If authentication service 72 confirms the identity of the merchant, access control service 74 establishes an authorization context encapsulating the set of activities permitted to the merchant within the system. Merchant billing application 114 is invoked and forms a request to billing business service 62. Billing business service 62 consults access control service 74 to verify that the current authorized context is permitted to generate a request for billing with the parameters requested. If the current authorized context is not permitted to carry out the requested actions,, a record of the denied request is created with auditing service 78, and an alert is generated to service provider operators by alerting service 80. If the billing action is permitted, business domain model 52 objects are created to represent the request for billing and handed off to persistence service 42 to manage backing storage with data storage system 44. Merchant billing application 114 instructs event distribution service 54 to notify it of changes in the payment status effected by the billed recipient.

[0031] A recipient starts the approval process by starting an application on mobile handset device 24, which prompts the consumer for a personal identification number (PIN). This PIN is combined with a secret value stored on mobile handset device 24 and random nonce values exchanged with mobile device gateway 134 to derive two cryptographic session keys, one for symmetric cryptography and another for message authentication. Additional exchanges with mobile device gateway 134 are scrambled with the symmetric session key and digitally signed with the message authentication session key. In response to the first secured transmission, mobile device gateway 134 invokes authentication service 72 to verify the signature and establish an authenticated context with access control service 74 as above. Further exchanges are placed in the same authenticated context if the message signature is successfully verified. Server 20 invokes bill payment application 102 to obtain a list of business domain model 52 entities representing open requests for payment from providers by payment processing program 64 of business services layer 50 operating in conjunction with persistence service 42 and data storage system 44. The list of open bills is returned to the recipient on mobile handset device 24 by way of mobile device gateway 134 along with a set of information on active payment accounts and those payment accounts that are acceptable for paying each outstanding bill. The recipient chooses the appropriate bill entity representing the request from merchant above, and chooses to pay the bill on the mobile handset device 24. The recipient chooses a payment account with which to settle the billing request from the provider. A new request to mobile device gateway 134 is created in the manner above using existing session security parameters. [0032] Bill payment application 102 generates a request to payment processing program 64 of business services layer 50 to execute payment of the bill. Payment processing program 64 verifies by way of access control service 74 that the requesting user is authorized to execute payment for the outstanding bill with the supplied account identifier. Payment processing program 64 contacts preferably over an Internet protocol communication link 140 an appropriate payment processor or financial institution 142 (Fig. 1 ) to execute the financial transaction and records in business domain model 52 the transaction information, which is stored in data storage system 44 by way of persistence service 42. Payment processing program 64 notifies event distribution service 54 of the payment of the bill. Bill payment application 102 returns electronic receipt information to mobile handset device 24 by way of mobile device gateway 134. Event distribution service 54 notifies billing business service 62 of the bill payment. Billing business service 64 returns an affirmative response to merchant billing application 114, which presents an electronic payment receipt to the merchant by way of the specific gateway type of access gateway 30 that serviced the request. The merchant equipment presents an electronic indication of a successful payment to the merchant, along with any required physical copy of the receipt according to merchant's business practices. [0033] Storage of receipts in data storage system 44 offers an available feature that can be of great security value to the merchant. Currently, if a thief enters a store, picks up merchandise, and thereafter represents to the store clerk that the merchandise in the thief's possession is merchandise the thief had bought at an earlier time, the store clerk can be forced to issue to the thief a store-credit even though the thief presented no receipt. With provision of the receipt storage feature, all transactions processed by server 20 can have attached to them receipts setting forth an amount of detail specified by the merchant. A merchant can quickly obtain access to a receipt through merchant account management function 112. An authorization request is placed in domain model 52 and stored in data storage system 44 so that the next time a customer communication device 24 checks in with access gateway 30, an authorization request is sent to the communication device 24. As soon as the customer authorizes access to the receipt, the merchant will be allowed to view it.

[0034] The recipient may also choose by way of mobile handset device 24 to reject the request for payment from the merchant. In that case, mobile handset device 24 generates a notice of rejection of the bill, which is recorded and transmitted to the merchant in a similar manner. Should payment processor 142 reject the payment requested by the recipient for merchant's services, the recipient is notified by mobile handset device 24 and allowed to choose another payment account to process. Merchant equipment is notified of a declined transaction only when the recipient chooses to reject the request or after a merchant-specified timeout elapses for the transaction.

[0035] The following detailed examples demonstrate the actions of a recipient and provider in two different commercial transactions and a fund transfer operation.

EXAMPLE 1

[0036] Example 1 represents a customer purchasing food and beverage items from a restaurant. Although the customer may use any one of a number of customer communication devices 24, examples of the display information presented to the customer are illustrated in Figs. 3-1 - 3-6 as cellular telephone display images. The service provider identified in the illustrations is PayWi Corporation, the assignee of this patent application. Upon selecting items or services for purchase, the customer undertakes a process of payment for the selected items or services. [0037] The process typically starts with one of the four following scenarios. In a first scenario, a merchant (e.g., cashier) asks a customer for his 10-digit mobile telephone number or for his proprietary service ID number. This number is then keyed in to a merchant communication device 22, which is, for example, a credit card terminal or any other point-of-sale equipment. In a second scenario, the merchant has a Bluetooth-enabled communication device 22, and the customer has a Bluetooth-enabled mobile communication device 24. As soon as it detects Bluetooth terminal 22, mobile communication device 24 automatically transmits the customer's mobile service ID number. In a third scenario, a billing company has the customer information on file, including the customer's mobile service ID number. In a fourth scenario, on an eCommerce site, the customer enters his mobile telephone number or mobile service ID number at the checkout page. [0038] Upon completion of one of the four scenarios of initiating a payment process, the service ID number (or mobile phone number) is transmitted from merchant communication device 22 to access gateway 30 with the amount due, the service ID number of the merchant, due date, and detailed list of services rendered or goods sold. (The due date is optional. If it is not included, the due date is set to, for example, three minutes into the future.)

[0039] Merchant billing application 114 receives the request from the relevant access gateway 30. Merchant billing application 114 queries account management program 60 to locate the target customer account in domain model 52 in conjunction with data management layer 40. Merchant billing application 114 invokes billing business service 62, which verifies through access control service 74 that the billing parameters are acceptable for the current authenticated context. If target accounts are not acceptable, access control service 74 signals a security violation, which is recorded by auditing service 78 and signaled to service provider operations by alerting service 80. If the security services layer 70 authorization check succeeds, billing business service 62 constructs domain model 52 entities representing an open billing request, and persists them by data management layer 40. [0040] The customer starts an application on a mobile handset, computer terminal, or functionally similar communication device 24 (either before or after he provides his customer mobile service ID number) and enters his PIN. Fig. 3-1 shows a prompt for entry of PIN. The customer's application running on customer communication device 24 establishes a secure session with access gateway 30 and continually connects to check for account updates by bill payment application 102. Once an update (in this case, a request for bill payment) is found in domain model 52, bill payment application 102 assembles details of the billing request, including the requesting provider, amount due, date due, and an identifier for the request. Bill payment application 102 returns these details by way of the relevant access gateway 30 for display on customer communication device 24. The customer sees a payment request message similar to that shown in Fig. 3-2; and, upon actuating an "open" function key, the customer sees details of the transaction, as shown in Fig. 3-3.

[0041] If the customer elects to "Pay," he is given an opportunity to choose what payment method he would like to use, as shown in Fig. 3-4. All payment alternatives given to the customer will have been pre-approved by the merchant. For example, if the customer has registered his American Express® charge card information through account management or during initial registration but the merchant does not accept American Express® charge cards, this card will not appear as a payment alternative. If no payment alternative is chosen, a default payment alternative is automatically selected. Fig. 3-5 shows a prompt for customer to acknowledge the selected payment method.

[0042] The billing request identifier, payment method, and payment type (point-of- sale payment or remote billing) are sent to access gateway 30 and processed by bill payment application 102. Bill payment application 102 retrieves the billing request from domain model 52. Bill payment application 102 verifies that the payment instruction is authorized by security services layer 70 and, if valid, instructs payment processing program 64 to execute the transaction with an appropriate financial transaction processor. If the payment information is obtained from an account of an external payment processor or financial institution 142, such as a VISA® card, payment processing program 64 sends the payment information securely to an external Internet gateway of the merchant's choice. If the payment information is for an internally controlled account, the payment is processed internally by payment processing program 64.

[0043] The response to the customer communication device 24 includes a receipt, as shown in Fig. 3-6. Approval or denial code is received from the payment processor (internal or external) and is represented in domain model 52. Event distribution service 54 notifies merchant billing application 114 that the status of the billing request has changed status (to a resolved state) and a response is returned to merchant communication device 22.

[0044] Figs. 4A and 4B are, respectively, a mobile payment process diagram and a mobile payment process flowchart summarizing in general the process steps performed in the commercial transaction of Example 1.

[0045] A pay at table solution offers a modification of the payment process of Example 1 to enable a customer to approve creation of a dynamic tab and thereby postpone an election to pay at the payment request processing stage of the transaction represented by Fig. 3-3. The pay at table solution allows the merchant to propose to the customer a dynamic tab, which, if accepted, the customer approves on customer communication device 24. Once approved, the balance amount of the tab may be extended (added to) or credited (subtracted from) in response to an instruction by the merchant as the customer orders additional goods or services from the merchant. The customer may continually monitor the balance amount of the tab and elect to close the tab at any time on customer communication device 24. The merchant can also close the tab on merchant communication device 22. [0046] Figs. 3-7 and 3-8 are examples of the display information presented to the customer using the pay at table solution. Fig. 3-7 shows a tab open request message indicating an initial balance, and Fig. 3-8 shows a close tab prompt indicating a final balance. Upon closing the tab, the application operating on communication device 24 allows the customer to transition to payment request processing to complete payment of the tab.

[0047] A stored value accounts solution can be made available for use by cash- only merchants, who typically cannot afford transaction fees associated with charge or credit cards or the equipment needed to accept them. Stored value accounts enable a merchant with a merchant communication device 22, such as a conventional mobile telephone, to accept wireless cash. This is accomplished by providing a customer with a cash service account into which the customer can deposit cash obtained by withdrawal from a debit card (automated teller machine (ATM)), checking account (ACH), or credit card (credit transaction). Instead of providing cash to the customer, the cash withdrawal provides for storage in the cash service account funds that can be used to pay for goods or services or transfer to other service account holders of the service provider. Stored value accounts are useful for smaller dollar amounts below which regular credit card transactions are cost effective.

[0048] The opportunity to select a payment method by cash service account would appear as a "WiCash" option in a display image similar to that shown in Fig. 3-4 of Example 1. (The WiCash option refers to the cash service account offered by service provider PayWi Corporation.) Merchant billing application 114 initiates a check to determine whether there is a sufficient balance in the cash service account to cover the transaction. If the balance is sufficient, the amount of transaction is added to the cash service account. If the balance is insufficient, merchant billing application 114 initiates execution of a decline message for transmission to merchant communication device 22 and terminates the process.

EXAMPLE 2

[0049] Example 2 represents the process of performing a fund transfer operation. The process starts with a consumer selecting funds transfer option from the main menu of an application operating on customer communication device 24. The consumer enters the customer service account ID number or mobile telephone number of the intended recipient of funds. The consumer enters the amount he wants to send and the source from which he wants to fund the transfer. The consumer enters his PIN.

[0050] The application operating on customer communication device 24 establishes a secure session with access gateway 30 and generates a request to bill payment application 102. The recipient account is located by way of account management program 60. Bill payment application 102 generates a request for funds transfer to payment processing program 64, which executes the transfer operation after checking account parameter authorization by access control service 74. A transfer receipt is constructed in domain model 52 and stored in data storage system 44. A response is delivered to customer communication device 24 for the transfer request. An optional SMS (text message) is sent to the intended recipient of the funds to inform him that the funds have been transferred. [0051] System 10, in addition to enabling the payment and funds transfer options described above, provides a new way for local merchants to interact with their local consumers. In a restaurant, for example, the ordering system can be more efficient and more pleasant for consumers. For example, food service workers do not have to periodically check with customers and ask them whether they want to order something. Instead, a customer can choose an mCommerce option from the application operating on mobile communication device 24 and enter the merchant's telephone number. A menu from which the customer can order food and drinks then appears on the display screen of the customer's mobile communication device 24.

EXAMPLE 3

[0052] Example 3 represents an mCommerce transaction. An mCommerce transaction begins with a consumer entering the merchant telephone number (or other merchant ID number) onto consumer communication device 24, which, in this example, is a cellular telephone. Communication device 24 establishes a secure session with access gateway 30. The merchant ID number is delivered by mobile device gateway 134 to an mCommerce component of merchant applications 94. The mCommerce site (also called merchant specific script), which is encoded in a special format, is sent back from access gateway 30 as a response to the request. [0053] The file is parsed and displayed on customer communication device 24. The consumer browses through the mCommerce site, selects the goods and services he wishes to purchase, and then actuates an "Order" button. [0054] The order is delivered to merchant application 94 component, which generates an order entity in domain model 52. A merchant computer terminal 22 can check access gateway 30 for order updates and fetch the order. When the merchant has created the order, a message is sent to access gateway 30. [0055] When the merchant has fulfilled the order, a billing request is generated by merchant billing application 114. The customer interacts with bill payment application 102 as in other scenarios to settle the bill. Bill settlement is communicated to merchant communication device 22.

[0056] Figs. 5A and 5B are, respectively, a mobile commerce process diagram and a mobile commerce flowchart summarizing in general the process steps performed in the mCommerce transaction of Example 3. [0057] To preserve the highest level of security, the following rules and procedures are implemented in preferred embodiments. Communication between a customer communication device 24 and access gateway 30 does not take place through a medium that does not allow customized encryption. Communication sessions with access gateway 30 are secured by cryptographic ciphers of 128 bits or greater. Recipient payment account numbers stored in domain model 52 and data storage system 44 are encrypted with 256-bit or greater ciphers. No sensitive data, with the exception of service ID numbers and session security material, are allowed to be stored on customer communication device 24. No payment authorization is allowed through Bluetooth protocol or by any "relay" device. It is preferred that TCP/IP protocol be used as communication protocol between customer communication device 24 and access gateway 30. Server 20 does not hold information about account balance or credit limits for financial accounts managed by a third party. Server 20 auto-declines a payment request after three minutes, if no approval or decline has been received from the consumer. [0058] There are several features associated with and options available on system 10. For example, server 20 can be configured to perform recurring billing, which entails automatic periodic billing for fixed amounts, such as automobile loan and rent payments. Recurring billing is established by storage of billing information that includes customer ID and merchant ID numbers, a schedule of successive automatic billing requests, and a reminder schedule coordinated with the billing request schedule. In a preferred implementation, the billing request and reminder schedules include first date of billing request to customer, time interval between successive billing requests to customer, and number of days after a number of the automatic periodic billing requests (e.g., each billing request) for transmitting a billing reminder to the customer. Server 20 sends to the customer a billing request on the specified first billing date and thereafter successively on dates separated by the specified time interval.

[0059] Server 20 is a passive system in that it does not perform an open gateway operation on its own. Preferred embodiments of server 20 do not initiate a communication link. Any request to access gateway 30 produces a response from the gateway. The communication medium can be of a wireless or wired type, except for a medium operating only at very short range, such as Bluetooth. A consumer is not required to be physically present at a place to perform a transaction. Merchants should not be required to batch their systems.

[0060] A merchant's mCommerce site is preferably unavailable at times when the merchant is not open for business. For example, a restaurant would make its mCommerce site unavailable when it closes for the day. Glossary of Terms

3G - Next generation wireless technology with data speeds reaching over 1 Mbit.

Currently being deployed in Europe and Japan.

Bluetooth - Cable replacement technology for up to 10 feet.

CDMA - Code Division Multiple Access. An American wireless technology with approximately 100 million users worldwide.

Financial Transactions Server - A server through which all transactions are processed.

GSM - Global System for Mobile phones. The wireless technology most used worldwide, with over 1 billion users. mCommerce - mobile Commerce. A process that allows consumers to interact with local or remote merchants.

Nonce - Number used once.

PIN - Personal Identification Number or any other way of personal recognition, e.g., fingerprint recognition or retinal scan. PINs are not stored on any consumer/merchant device.

Service Account - An account a consumer or a merchant has registered with the service provider.

Service ID - A number that identifies a consumer's account with the service provider.

Service Provider - Operator of the financial transactions server.

UMTS - Universal Mobile Telephone System. Another word for 3G, mostly used in

Europe.

WAP — Wireless Application Protocol. A communication protocol used on wireless devices. WAP data always passes through a WAP gateway before the information is sent to the receiving server.

WLAN - Wireless Local Area Network. Wireless network access in a local area.

[0061] It will be obvious to those having skill in the art that many changes may be made to the details of the above-described embodiments without departing from the underlying principles of the invention. The scope of the present invention should, therefore, be determined only by the following claims.

Claims

1. A method of effecting between a recipient and a provider of services or goods a secure transaction implemented by establishing communication links between the provider and the recipient through a server, comprising: receiving a transmission of a first set of transaction information for processing by a server application operating on a server, the first set of transaction information including recipient or provider identification information and a request for a transaction; operating the server application on the server gateway to confirm the recipient or provider identification information and initiate a payment approval operation corresponding to the request for a transaction; transmitting, in response to action by the recipient, from the server to a communication device associated with the recipient a second set of transaction information to which the recipient can respond; receiving a transmission to the server from the recipient providing in response to the second set of transaction information an instruction as to whether to proceed with the transaction requested; operating the server application to initiate a payment process in response to the instruction by the recipient; and communicating transaction status information from the server to communication equipment associated with the provider to inform the provider about the state of the transaction.

2. The method of claim 1 , further comprising communicating transaction status information from the server to the communication device associated with the recipient to inform the recipient about the state of the transaction.

3. The method of claim 1 , in which the payment process initiated in response to the instruction by the recipient includes at least a temporary payment denial and thereby causes an interruption of the transaction.

4. The method of claim 3, in which the instruction by the recipient includes a payment mode option, and in which the interruption of the transaction causes the server to transmit to the communication device associated with the recipient a prompt for selection of an alternative payment mode option.

5. The method of claim 4, further comprising receiving by the server in a secure manner a transmission from the recipient providing in response to the prompt an alternative payment instruction for execution by the server application.

6. The method of claim 5, in which the receipt of the alternative payment instruction causes the server application to proceed with the transaction and communicate transaction status information indicative of an approved state of transaction.

7. The method of claim 5, in which the receipt of the alternative payment instruction causes the server application to initiate in the payment process at least a repeat temporary payment denial and thereby cause an additional interruption of the transaction.

8. The method of claim 7, in which the additional interruption of the transaction causes the server to transmit to the communication device associated with the recipient a prompt for selection of a further alternative payment mode option.

9. The method of claim 3, in which the interruption of the transaction initiates operating the server application to verify the existence of no alternative payment mode option and communicate transaction status information indicative of a denied state of transaction.

10. The method of claim 1 , in which the instruction as to whether to proceed causes creation of a dynamic tab and thereby postpones the payment process; and further comprising receiving a transmission to the server from the provider or the recipient providing a close tab instruction to initiate the payment process to complete payment of the tab.

11. The method of claim 10, in which the tab has a balance amount and, before receiving the transmission providing a close tab instruction, further comprising receiving a transmission to the server from the provider an instruction to extend or to credit the balance amount of the tab.

12. The method of claim 1 , in which: the request for a transaction includes a request for automatic periodic billing; the first set of transaction information further includes a schedule of successive automatic periodic billing requests to the recipient; and the instruction as to whether to proceed with the requested automatic periodic billing is configured within the server. W

13. The method of claim 12, in which the schedule represents a time interval between successive automatic periodic billing requests to the recipient.

14. The method of claim 12, in which the first set of transaction information further includes a reminder schedule coordinated with the schedule of successive automatic periodic billing requests for transmitting a billing reminder to the recipient.

15. The method of claim 14, in which the reminder schedule represents a number of days after a number of the automatic periodic billing requests for transmitting a billing reminder to the recipient.

16. The method of claim 1 , further comprising establishing within the server a stored value account into which the recipient can deposit cash for subsequent withdrawal, and in which instruction as to whether to proceed initiates the payment process by withdrawal of funds from the stored value account.