CN1989520A - Transaction processing method, device and system - Google Patents

Abstract

The invention provides a transaction processing method, equipment and a system. The present invention relates to transaction processing for processing payments between payers (typically individual payers) and payees (typically merchants). Payment transactions typically involve providing account details of a user to a merchant device, for example, by swiping a card in the merchant's card swipe device. The merchant device then prepares a transaction message including information such as the user's account ID, merchant ID, and payment information, and forwards the message to a transaction processing system that may include an acquirer and an issuing bank. The transaction processing system approves the payment and returns a confirmation to the merchant. In the present invention, the device associated with the payee, which in the preferred embodiment is a suitably adapted mobile phone, is involved in the payment transaction processing. In one aspect, the transaction processing system requests confirmation from the payer electronic device that the transaction should be conducted, and the payer enters the correct PIN to authorize the transaction. On the other hand, all transaction processing information is provided from the payer electronic device to the transaction processing system, and then the transaction processing system or the payer electronic device confirms that the transaction is authorized to the merchant device. This relieves the merchant of the burden of transaction processing and also enhances the security of the transaction as the payer is in control. In another embodiment, the payer electronic device may also upload a list of products and select a product while paying for the product, the selected product being notified to the payee (merchant).

Description

Transaction processing method, device and system

technical field

The present invention relates generally to transaction processing methods and systems, and more particularly but not exclusively to methods and systems for facilitating transactions between a payer (who may be a member of the general public) and a payee (who is typically a merchant) at the point of sale or online Payment transaction processing system.

Background technique

Payments for products or services are usually made electronically. For example, payment may be made using a credit or debit card, and a financial institution such as a bank may initiate a payment transfer to the payee's account either directly or through one or more intermediaries after the payer has authorized the transfer. Authorization to transfer funds may include, for example, presenting the payee with a credit or charge card and signing an invoice. The payee then compares the payer's signature on the invoice with the signature on the card and, if he is satisfied, authorizes payment.

Many other methods have been proposed for the payer to "sign" the transaction for verification of the payment, including for example the use of a secure pin code.

However, there are still a number of security risks that need to be considered. For example, payments using credit or charge cards typically require the card to be released to the payee for a short period until the invoice is issued and signed. Magnetic stripe cards are easily duplicated on relatively inexpensive equipment, and duplicated cards can be used to carry out fraudulent transactions. There are security issues in electronic payment systems involving the Internet. There is a general need for a payment system that provides improved security and convenience.

Additionally, the general paradigm conventionally associated with processing payment transactions is the handling of transaction processing communications (messages including payment information) between a payee or merchant device and a transaction processing system (typically an acquirer and one or more issuing banks). , such as the payer's account ID, merchant ID, transaction amount, etc.). Payers pay little attention to transaction processing beyond providing their account details (which, as mentioned above, are then made public and thus used for fraudulent purposes). No one has proposed a system that can replace conventional merchant device/transaction processing system configurations.

Contents of the invention

According to a first aspect, the present invention provides a method of making a payment, the method comprising the following steps:

provide information associated with the payer, presenting the information in a manner that the payee can access the information,

receive payment-related information through a Payer electronic device associated with the Payer, and

Instructions to make payment are given using the electronic device associated with the payer.

Today, members of the public typically possess one or more electronic devices. For example, mobile phones are ubiquitous. In one embodiment, the method includes utilizing such ubiquitous electronic device associated with the payer to give instructions to make the payment. The electronic device may be a dedicated payer electronic device or may be a modified mobile phone.

Thus, each payer may have an electronic device associated with them that they can use to provide instructions to make a payment. In one embodiment, the instruction to make a payment may simply be an acknowledgment to the transaction processing system that the payment should proceed. However, this adds an extra layer of security (requiring information from an electronic device associated with the payer) that current exchanges lack.

The payment may be a card-present payment, eg, the payer goes to a point-of-sale ("POS"). The transaction may be a non-card present payment, such as an internet payment. Where the payment is online (such as Internet payments), the electronic device is not the computer that the payer uses to access the merchant's website, but a separate electronic device.

In one embodiment, the payer electronic device is configured (eg, by including an appropriate software application) to recognize payment information. In one embodiment, software that implements payment information recognition in a manner similar to the present transaction processing software can be used so that the payer electronic device can express messages including payment information and send these messages to the transaction system (e.g. , used by acquirers and issuing banks).

In one embodiment, the payer electronic device may include security measures to increase the security of the process. These security measures may include sending a digital signature as said confirmation, and in one embodiment, the payer electronic device may require the user to enter a message such as a PIN on a keypad. In one embodiment, firmware may require a PIN to be entered in response to payment information appearing on the device's display to prevent hackers from exploiting the payment application without the payer's knowledge.

In one embodiment, the payment related information may include product information in the form of a list comprising at least one product identifier. In this case, the method further comprises the step of selecting at least one product identifier by the payer electronic device, and the information associated with the payer includes the selected product identifier. In one embodiment, the payer electronic device may be provided with a list of multiple product identifiers, from which the payer may then select. This choice is provided to the payee electronic device so that the payee can provide the product to the payer.

It is advantageous for the payee to receive an "order" for the product, which may have been paid for at the same time. This allows users to buy and pay at the same time.

In one embodiment, the payer's electronic device can obtain all payment information required for transaction processing from the payee's electronic device, and can then use the processing system to directly process the transaction. This reduces the burden on the merchant for transaction processing and enables individual payers to exercise sufficient control over the processing without requiring them to hand over their credit card details to the merchant, for example. Instead, the payer electronic device provides account details to the transaction processing system.

According to a second aspect, the present invention provides a method of processing a payment transaction, the method comprising the steps of: a transaction processing system receiving an instruction to make a payment from a payer electronic device associated with a payer; the transaction processing system authorizing the payment; and The transaction processing system provides confirmation that the payment transfer has been authorized.

According to a third aspect, the present invention provides an apparatus for facilitating a payment transaction from a payer to a payee, said apparatus comprising a payer electronic device associated with a payer, said payer electronic device comprising: payment information receiving means for receiving information related to payment; and payment instruction issuing means for giving an instruction to make payment.

According to a fourth aspect, the present invention provides a transaction processing system for processing payment transactions, the system comprising: a payment instruction receiving device configured to receive a payment instruction from a payer electronic device associated with the payer an instruction to make a payment to the payee; and a payment processor for authorizing the transfer of funds from the payer's account to the payee's account.

According to a fifth aspect, the present invention provides apparatus for facilitating processing a transaction, the apparatus comprising payee electronic equipment configured to communicate with a transaction processing system according to the fourth aspect.

According to a sixth aspect, the present invention provides a database comprising a plurality of product listings available to a payer electronic device, whereby the payer electronic device may select one or more products from these product listings to Send to payees to fulfill their product needs.

According to a seventh aspect, the present invention provides a passive device configured to be read by a payer electronic device to facilitate a payment transaction.

According to an eighth aspect, the present invention provides a passive device comprising information identifying an application such that an electronic device can use the information to process information associated with said passive device.

According to a ninth aspect, the present invention provides a method of launching a software application, the method comprising the steps of: utilizing a passive device comprising information identifying the location of said software application; uploading the information to a user device; and obtaining said application from a remote location using the user device.

According to a tenth aspect, the present invention provides a method of organizing a queue, said method comprising the steps of: providing information to a user's mobile phone indicating the user's position in said queue; The information is updated according to the movement of the position in the queue.

Description of drawings

With reference to the accompanying drawings, the features and advantages of the present invention will become clear according to the following description of the embodiments of the present invention by way of example only, in the accompanying drawings:

Figure 1 is a schematic block diagram of a general payment method and system according to an embodiment of the present invention;

Fig. 2 is a schematic block diagram illustrating a payment system according to an embodiment of the present invention in more detail;

Figure 3 is a flowchart illustrating one possible operation of the payment system of Figure 2;

Figure 4 is a block diagram illustrating a payment system utilizing an embodiment of the present invention;

FIG. 5 is a flowchart illustrating an operational process utilizing the system of FIG. 4;

Figure 6 is a block diagram illustrating the operation of a system according to another embodiment of the present invention;

FIG. 7 is a flowchart illustrating one possible operation of the system of FIG. 6;

8 is a block diagram illustrating the operation of a payment system according to another embodiment of the present invention;

FIG. 9 is a flowchart illustrating one possible operation of the system of FIG. 8;

10 is a block diagram illustrating the operation of a payment system according to another embodiment of the present invention;

Figure 11 is a flowchart illustrating one possible operation of the system of Figure 10;

Figure 12 is a block diagram illustrating the operation of a system according to another embodiment of the present invention;

Figure 13 is a flowchart illustrating one possible operation of the system of Figure 12;

Figure 14 is a block diagram illustrating the operation of a system according to another embodiment of the present invention;

Figure 15 is a flowchart illustrating one possible process of operation of the system of Figure 14;

Figure 16 is an example view of the "menu" that appears on the payer's electronic device in the system of Figure 14;

Figure 17 is a flowchart illustrating processing according to another embodiment of the present invention;

Figure 18 is a block diagram illustrating the application of a system according to another embodiment of the present invention;

Figure 19 is a more detailed block diagram illustrating components that may be included in a transaction processing system according to an embodiment of the invention; and

Figure 20 is a block diagram of a payer electronic device according to an embodiment of the present invention.

Detailed ways

Figure 1 is a "schematic" view of an apparatus that may be used to implement various embodiments of the invention. Unlike conventional payment transactions, which typically require only an electronic device associated with the payee ("merchant device") and a transaction processing system (which may typically include an acquirer/gateway and a financial institution) to process the payment, embodiments of the present invention There is also another entity (the electronic device associated with the payer) that needs to be included in the transaction processing.

In conventional systems, a merchant device obtains account identification data from a payer, typically by swiping a magnetic card (or obtaining information from a smart card). The merchant device then prepares a message containing all payment information (eg, merchant ID, payment account, merchant account, payer's account ID, etc.) and sends the message to the transaction processing system. The transaction processing system can then check the payer's account to ensure that sufficient funds are available for the transaction (depending on whether there is an authorization-free transaction amount (floor limit) associated with the account), and will approve the transaction or deny the transaction Return to Merchant Devices. If transaction authorization (approval) is received, the merchant (payee) can be assured that the transaction will proceed.

This conventional processing presents all of the security issues described above and also requires each payee to utilize the infrastructure associated with the payment processing system.

According to an embodiment of the present invention, the payment transaction from the payer to the payee requires the payer electronic device 1 associated with the payer by the transaction processing system 2 . In the embodiment according to FIG. 1 , the information 3 associated with the payer will be provided to the payee electronic device 4 . As will be seen later in the description, the information 3 may comprise different elements. For example, it could include the account details of the payer or just a confirmation that the transaction between the payer and payee is authorized.

However, without the Payer Electronic Device 1 being involved, the transaction will not be authorized. This adds an extra layer of security and, in some embodiments (to be described), greatly facilitates the payer and payee involved in the transaction. In some embodiments, the need for a payee to be involved in payment transaction processing may be eliminated. Instead, the payer becomes the primary conduit for initiating and processing payment transactions. This is a shift from the usual practice where merchants are responsible for transactions. Embodiments enable payers to retain all their account details so that they do not need to go through the merchant and do not compromise security.

Embodiments of the present invention enable a mix of many levels involving the payer electronic device 1 . At one level, the payer electronic device only provides confirmation that the payment should proceed, otherwise, the transaction is processed substantially in a conventional manner through the payee electronic device and the transaction processing system.

At another level, the payer electronic device initiates payment processing and processes the transaction by sending a message with the transaction processing system. In this embodiment, the payee's electronic device may only receive confirmation that the payment has occurred, and all processing is performed through the payer's electronic device.

At another level of hybridization, an arrangement can be provided wherein the payer electronic device can select a product through the transaction processing system and pay for the product.

In one embodiment (first level), the information associated with the payer may be account information provided by the device 3 for providing information such as a pass card, credit card, account card or smart card. A payee electronic device 4 (eg a card reading device) associated with the payee reads information from the card 3 and sends payment related information to the transaction processing system 2 . The transaction processing system 2 will be described in more detail later, but typically includes a transaction gateway or acquiring bank, and may also include an issuing financial institution such as an issuing bank. This is a standard configuration where the transaction gateway receives the transaction information and checks with the issuing bank that the payer is able to pay. In this embodiment, the transaction processing system 2 then communicates with the payer electronic device 1 to obtain confirmation from the payer electronic device 1 that the payment should proceed.

The payer electronic device 1 in this embodiment is a modified mobile phone, which will be described in more detail later in the specification. The payer electronic device 1 sends an acknowledgment to the transaction processing system 2 , which then sends a payment authorization to the payee electronic device 4 .

Figure 2 shows a representation of an embodiment at different levels comprising a payer electronic device 1 in the form of a modified mobile phone, a payee electronic device 4 in the form of a conventional card reader with a card swipe 10, a display 11 and a keypad 12 . The transaction processing system is still represented by block 2. The payer holds a card 3 (which may be a credit card). Transaction processing according to the embodiment of FIG. 2 will now be described with reference to the flowchart of FIG. 3 .

In step 13, the payer's card 3 is swiped in the card reader 10 of the payee's device. In the following description, it should be noted that "Payee Device" will be referred to as "Merchant Device" or "MD".

At step 14, a transaction message is sent from the MD 4 to the transaction processing system "TPS" 2. The transaction message may include all information conventionally involved in conducting transaction processing, eg credit card details, payment account.

At step 15, the TPS 2 sends a request to the Payer Device ("PD") 1 for confirmation that the payment should proceed ("Confirmation Request").

In step 16, the payer utilizes the keyboard 20 of PD 1 to press the confirmation key. Then, PD 1 sends an acknowledgment to TPS 2.

In step 17, TPS 2 sends transaction authorization to MD 4.

An advantage of including the payer electronic device 1 in the process is that it provides additional security to the transaction. The payer needs not only his credit card, but also access to his modified mobile phone in order for the transaction to proceed. The payer may be required to key in a security code such as a PIN, which the transaction processing system can compare to the PIN stored in the database.

It is highly unlikely that a fraudster would have access to a user's credit card, their mobile phone, and also know the PIN in order for the fraudulent transaction to proceed.

Additional security measures may be implemented. In one embodiment, a digital signature security construct may be used between the transaction processing system and PD 1.

In another embodiment, in order to ensure that the payment transaction proceeds, firmware may be used in the PD 1 to ensure that the payer must activate the input device (keypad 20). This prevents a hacker from being able to remotely operate the phone to approve payment transactions without the owner of the PD 1 knowing. For this firmware, the hacker cannot change the firmware, and requires the payer 1 to enter confirmation through the keyboard 20 . The firmware 1 can also be configured to require payment information to appear on the display 21 of the PD 1, so for example the payer can review the payment information such as the payment amount before typing in a confirmation.

In a variant of the process shown in Figure 3, instead or in addition to the TPS 2 sending the transaction authorization to the MD 4 (step 17), in step 17A the TPS 2 sends the transaction authorization to the PD 1. Then, for example, the payer presents the authorization to the payee (the authorization appears on the screen of PD 1). In one embodiment, the authorization details may be provided on the screen 21 of the PD 1 in coded form (recognizable by a suitable reader which may be provided with the MD 4). The reader is not shown in Fig. 2, but the reader can be provided on the MD 4. For example, the code may be a barcode appearing on the screen 21 to be read by an appropriate barcode reader on the MD 4.

Receipts for payments can also be sent to PD 1, which can have an application for storing transaction receipts and billing them accordingly.

The ability to use an electronic device associated with a payer to confirm that a payment transaction should proceed also applies to online transactions (as well as point-of-sale (POS) type transactions described above).

Referring to FIG. 4 , a typical online transaction includes a payer accessing a merchant website 27 provided by a merchant server 28 via the Internet 25 and utilizing a computer such as a PC 26 . After selecting a product, the payer enters their credit card details. The merchant server 28 then proceeds to process the payment transaction. This process is notoriously vulnerable to spoofing.

According to an embodiment of the invention, the PD 1 associated with the payer can be used to enhance security. Transaction processing performed according to this embodiment will now be described with reference to FIG. 5 .

At step 29, the payer selects merchandise from the merchant website 27 and enters his account details (usually a credit card number) on the merchant website 27 .

At step 30, a usual transaction message is sent from the merchant server 28 to the TPS 2.

According to this embodiment, TPS 2 then sends a request to PD 1 confirming that payment should proceed. The payer types an acknowledgment on his PD 1 (step 32), which sends the acknowledgment to TPS2.

Then, TPS 2 sends transaction authorization to merchant server 28 (step 33).

The TPS may have a database storing information (eg, mobile phone number) that enables communication with the payer electronic device.

The embodiments described above generally relate to a payer electronic device for providing an additional layer of security by requiring confirmation from the payer electronic device that a payment transaction should proceed. The payer electronic device can also be used to receive transaction authorizations and receipts, but in practice transaction processing is routine and most messaging occurs between the payee electronic device and the transaction processing system. In the following embodiments, the payer's electronic device can undertake more transaction processing, which generally leads to an improvement in the operational convenience of transaction processing.

Referring to Fig. 2, PD 1 is provided with some devices 35 capable of realizing local communication. The means 35 for enabling local communication comprise an "access device" and may comprise a contactless smart card provided within (perhaps attached to) the mobile phone. The payee electronic device 4 is provided with a suitable reader 36 . The access device 35, when contacted or in close proximity to the reader 36, is arranged to provide the MD 4 with information enabling the MD 4 to subsequently communicate with the PD 1 . For example, the identification information may be a telephone number so that the MD 4 can contact the PD 1 using the mobile telephone network. Alternatively, a local wireless network (eg, Bluetooth ^™ ) can be used to communicate between PD 1 and MD 4 . Therefore, MD 4 can send payment-related information to PD 1 . This would allow PD 1 to take a more active role in the transaction process.

In one embodiment, MD 4 may send payment amount to PD 1. Payer 1 can then change the payment amount (appearing on screen 21) and send the changed payment amount back to MD 4 for subsequent transaction processing. Such an embodiment would be very useful in "tipping" situations, for example. For example, in a restaurant, payers can utilize PD 1 to enter their tips, which will prevent any fraudulent practices that may occur when manually entering tips on cash payment vouchers. The remaining transaction processing can be carried out according to the confirmation required by PD 1 as described in the above embodiments.

FIG. 7 is a flowchart illustrating payment processing that may be implemented using the embodiment of FIG. 6 .

In step 38, swipe payer's card 3 in the card reader 10 of MD 4.

In step 39, send transaction message and transaction information from MD 4 to TPS 2. Then, PD1 sends wireless communication information to MD 4 via access device 35 and reader 36, so as to realize wireless communication between MD4 and PD 1 (step 40).

In step 41, MD 4 wirelessly sends a "Payment Request" to PD 1. A payment request may include payment information, such as a payment amount. It should be noted that if the payer is given the option to change the payment information (which will change the payment amount), then MD 4 can wait for a reply from PD 1 before sending the transaction message to TPS (i.e., step 39 will go further along the flow chart to proceed below).

In step 42, in response to the payment request from MD 4 (and after any further information has been entered, such as a change in payment amount), PD 1 sends an acknowledgment to TPS 2 that the transaction should proceed.

In step 43, TPS 2 then sends transaction authorization to MD 4, letting the payee know that the transaction can proceed. Alternatively, TPS 2 sends transaction authorization to PD 1 at step 43A, (and at 43B), PD 1 wirelessly sends authorization to MD 4.

It should be noted that a separate access device (e.g. smart card 35) may not be required, but instead the access device, for example, may be incorporated into suitably configured PD 1 and MD 4 to allow direct wireless communication.

In the embodiment of Figures 6 and 7, the payer still swipes the card in the payee device, and the merchant device still handles the vast majority of the transaction processing. Figure 8 illustrates an embodiment in which the payer does not need any card or device other than the payer device 1 to carry out the transaction.

Access device 35 and reader 36 may still be provided (or, as noted above, devices 1 and 4 may be suitably configured to initiate short range communication in some other way). In this embodiment, the PD 1 also includes an application (which may be implemented as software) enabling it to express transaction messages used in transaction processing.

Referring to Figure 9, in order to undertake payment transactions, PD 1 and MD 4 establish communication with each other. Then, at step 45, MD 4 wirelessly sends payment information to PD 1, the payment information including the information required to process the payment, such as merchant ID and payment amount.

In step 46, a transaction message is sent from PD 1 to TPS 2 so that the payer account can be identified, the transaction message includes common information required for transaction processing, such as merchant ID, payment amount, and identity of the payer. At the same time, the transaction message may include confirmation that the transaction should proceed.

In step 47, TPS 1 may send transaction authorization to MD 4. Alternatively, at step 47A, PD 1 may receive the transaction authorization transmitted from TPS 2, and at step 47B, PD 1 wirelessly sends the authorization to MD 4.

It should be understood that if paths 47A and 47B are selected, merchant equipment that is capable of communicating with TPS 2 is not required. Thus, it is possible to provide a payee electronic device with only a local communication device for communicating (eg, wirelessly) with the payee electronic device, which then conducts bulk transaction processing communications. The main advantage of this configuration is that the payer's account details (eg credit card details) may not need to go through the merchant equipment. In addition, the payer has complete control over the transaction from a convenience and security standpoint. As described in connection with the above embodiments, the payment information can appear on the screen 21 so that the payer can view the information, enter 20 through the keyboard to change the information (eg change the tip), etc. The payer has full control.

It should be noted that in a variant of this embodiment, all communications may go through MD 4. That is, payment messages may be prepared by PD 1 and then wirelessly sent locally to MD 4 for subsequent delivery to the transaction processing system. This is a less secure option as all payer information will pass through the merchant device. However, this may be convenient in certain circumstances (for example, when there are communication difficulties between the PD and the transaction processing system 2).

The payer's account ID can be sent in encrypted form along with the digital signature. Any security measures may apply. In one embodiment, transaction processing system 2 maintains a database of "split" account numbers. That is, a part of the account number is saved by the TPS 2 database, and the other part of the account number is saved by the payer device 1. Therefore, hackers cannot obtain all account IDs by hacking into PD1.

In an alternative, merchant device 4 may comprise two parts 4A and 4B (FIG. 8). Part 4A may be a mobile device, for example carried by an operator such as a waiter in a restaurant. Part 4B can be Payee Electronic Devices. The waiter may bring device 4A close to PD 1 to obtain communication details (e.g. initiate communication) so that PD 1 can then communicate with part 4B, e.g. enabling PD 1 to upload transaction details and then continue transaction processing.

Device 4A may provide contact details to other parts of device 4B. Device 4A may actually be a passive device, which may be powered by power from PD 1. In the case of a restaurant, for example, part 4A can provide information such as the table number in the restaurant so that in a subsequent communication with part 4B (which may be an electronic cash drawer), the payer can be identified as sitting at a particular table in the restaurant Person in position, therefore, can be calculated by Part 4B and generate a payer's bill, which is then sent to the PD 1 associated with that payer.

The two-part merchant device 4 may take any convenient configuration. In order to obtain payment information, part 4A only needs to provide information enabling the payer device 1 to access the (usually more complex) part 4B.

FIG. 10 illustrates a system in which PD 1 is capable of handling transaction processing for online payments. The same reference numerals as used in FIG. 4 are used in FIG. 10 to denote similar components.

In this embodiment, PD 1 includes an application for preparing transaction messages for transaction processing.

With reference to Fig. 11, in step 50, the payer selects product from merchant's website 27 via PC 26 and Internet 25.

In step 51, PD 1 uploads payment information, including merchant ID and payment amount (and any other information that may be needed to proceed with transaction processing). Uploading can be done by wired or wireless communication with PC 26. Alternatively, when the product 27 is selected, the payer may provide the contact details of PD 1 to the merchant server 28, and the merchant server 28 may then send the payment information to PD 1 (e.g. via a mobile phone communication network) . In yet another option, the PC 26 may be omitted, and the PD 1 (which may be a modified Internet-capable mobile phone) directly accesses the website 27 and uploads the payment information.

At step 52, a transaction message is prepared by PD 1 and sent to the TPS together with the transaction confirmation and account ID.

In step 53, TPS 2 sends transaction authorization to the merchant server. Subsequently, a receipt can be generated for PD 1 (and it can be sent from the merchant server to PD 1).

The encryption and other security measures described above can be applied in this embodiment. The main advantage of this embodiment is that there is no need to place account details (such as credit card details) on a network (such as the Internet).

Figure 12 illustrates another embodiment of the present invention. In this exemplary embodiment, the payer electronic device 1 comprises a reading device 55 designed to read payment information from a passive device 56 . In the illustrated embodiment, the reading device 55 is a camera 55 (cameras are commonly provided with mobile phones these days). However, the reading device may be any other convenient reading device, such as a barcode scanner. In this embodiment, the camera 55 is used with application software that enables the mobile phone to detect the passive device image from the camera and process the information provided by the passive device.

Furthermore, the passive device 56 need not be a barcode, but can be any passive device that can be read to provide payment information (eg, RF).

In one embodiment, the payment information provided by the passive device may be a merchant ID, enabling the PD1 to subsequently communicate with the merchant device 4 as in the embodiment of FIG. 8 . Processing may then continue along the processing line of Figure 9, except that payment information from MD 4 is obtained via the passive device and reader 55 in PD 1. For example, a passive device could be a barcode on a table in a restaurant.

At a more complex level, passive devices may provide payment information that enables PD 1 to proceed and initiate payment transactions. For example, passive device 56 may include sufficient information to enable PD 1 with appropriate software applications to prepare transaction information for transaction processing system 2.

Operation of the system of FIG. 12 will now be described in relation to FIG. 13 .

In step 58, PD 1 obtains payment information from passive device 56. In the embodiment of Fig. 12, the payer uses his camera 55 to take a picture of the barcode 56, and the application on the PD 1 recognizes the barcode and obtains the payment information.

In addition, in the embodiment of FIG. 12, the barcode 56 is provided with a bill 57, which may be a restaurant bill, for example. The information on the barcode 56 includes all the information needed to process the transaction to pay the merchant (eg, the owner of the restaurant). That is, the information will include the merchant ID, payment amount, and any other information needed to prepare the transaction message.

At step 59, the transaction message is prepared by PD 1 and sent to TPS 2 together with the transaction confirmation and the account ID of the payer.

In step 60, TPS 2 communicates with MD 70 and provides transaction authorization to MD 70. Alternatively, as in the above embodiment, the TPS 60A may notify the PD 1 of the transaction authorization, and then the PD at 60B sends the transaction authorization to the MD 70. The MD 70 can generate a receipt 71 and/or send an electronic receipt to the PD 1. Alternatively, transaction processing system 2 may receive electronic receipts from MD 17 and send them to PD 1.

It should be appreciated that this configuration has great advantages. For example, a bill received through the post (e.g., a utility bill) may include a passive device that includes a code readable by a reader of the payer's electronic device to enable the payer's electronic device to process the payment of the bill. Payment Information.

In a further embodiment, the passive device may provide a transaction ID number and require the PD 1 to communicate with a remote database (e.g., operated by a merchant system) containing the transaction information. For example, the database may be associated with an electronic cash register. PD 1 then collects the required payment information from the database and executes the transaction by communicating with TPS 2. In this embodiment, the payer can even manually key in the transaction ID number.

Note also that in the above embodiments where the Payer Device processes the transaction, the Merchant Device must be configured to recognize a Transaction Approval Code (or similar) sent over the phone or via TPS 2 in response to transaction processing initiated by PD 1. identifier).

Some example situations where this embodiment would be useful are as follows:

• A bill is generated by the merchant cash register with a barcode including payment information. PD 1 scans the barcode (photographs), and the payer authorizes the transaction via TPS 2. TPS approves the transaction and notifies the payer via PD 1. PD 1 displays on its screen 21 the authorization code read by a barcode reader (not shown in FIG. 12 ) at the merchant's store.

- A variation of the above example is for responses from the transaction processing system 2 to be transmitted directly to the merchant device 70 via the Internet or other electronic system.

• Generate a docket incorporating a barcode at the merchant cash register. The barcode is read by the payer at the bistro table via PD 1. The payment is processed and a response is sent to the cash register, or even to the phone of the waiter serving that table. Then, the consumer can go away.

In further embodiments, product information may be provided in addition to payment information to the payer device. The product information may be provided in the form of a list comprising at least one product identifier, and the payer device comprises means (which will typically be a software application) enabling selection of the product. Information pertaining to product selections can be sent to the payee (via the payee electronic device), enabling the payer electronic device to order the product in addition to paying the payee. This enables the payer electronic device to become a "personal cash register". Payers can simultaneously order and pay for products using their own devices.

Product information can be provided by a number of means, including transmission via passive devices (eg, barcodes) from payee electronic devices, uploading from the Internet, and the like.

Figure 14 illustrates various options for obtaining and utilizing product information according to this embodiment. It should be understood that the invention is not limited to the options illustrated in FIG. 14 .

One option is to provide product information via a passive device such as a barcode 71 that can be associated with the product. In Figure 14, an example is shown in the form of a restaurant menu 72, which includes a general list of items 73, and a barcode 71 that can be photographed by the payer's PD 1 to upload the menu to the PD 1.

Referring to Figure 15, an example process is as follows.

In step 80, PD 1 uploads a menu including the product list. A software application on PD 1 enables a list of products to appear on display 21, and the payer can select from the list using input 20 (step 81).

In step 82, PD 1 prepares a transaction message including Merchant ID, Product ID, Account ID or any other information needed to process the transaction and also orders the product. Transaction messages are sent to TPS2.

TPS 2 sends product selection to MD 70 and also sends payment authorization after TPS 2 has authorized payment.

If the product information relates to a menu in a restaurant, the payer selections are received by the MD 70 and will include the payer's ID (e.g., table number) and a list of products (e.g., food) that the payer has selected. Thus, the merchant can fill the order and deliver the food and beverages to the payer with the confidence of knowing that they have been paid for.

In this embodiment, the payee electronic device may provide a means for displaying the order, which in the embodiment illustrated in FIG. processing to enable them to fill orders.

The transaction processing system 2 incorporates an order system which is designed to process orders (product selection) and forward them to the payee.

Product information can be provided in many ways and used in many ways of shopping. Other examples of menus in restaurants include:

• Products in a store/supermarket may be provided with a barcode 71 identifying the product and providing payment information, enabling the PD 1 to process payment transactions for the product 85. In this case, PD 1 may select more than one product, pay in aggregate and take one transaction. The TPS 2 then notifies the merchant device (in this case, an electronic cash register) that these products have been purchased. Thus, login to the cash register is facilitated automatically and may not require any operations associated with the store cash register. An appropriate system can be used to remove any security measures from the product 85 so that the payer can leave the store with the product. A receipt (described above) can be generated for PD 1.

• Product listings can be downloaded from database 86 (which is actually a "shopping" database). The database may include multiple merchants and multiple product listings associated with those merchants. The Payer may request a particular merchant's menu or browsable listing via PD 1 (perhaps by transmitting the merchant ID) and upload one or more menus. They can then shop and obtain and pay for the merchandise remotely, or order and pay for the product and visit a merchant outlet to receive the merchandise in person. PD 1 can be provided with an appropriate receipt (eg, a barcode that appears on the screen), which can be referenced within the merchant's storefront to ensure that the item is given to the correct person.

• For example, the database could provide takeout menus for restaurants and diners. An example of such a menu uploaded to PD 1 is shown in Figure 16. For example, a payer can upload a diner's menu to their PD 1 on the way to work. They can enter an order for coffee, burgers and cakes and send the order to the diner via TPS 2 while paying for the order. By the time they arrive at the diner, their order may already be ready. It should be noted that menus may be provided from a "common shopping database", from a system associated with the merchant (e.g., a merchant's website), and uploaded to the phone via a network (e.g., the Internet), or from a passive device ( such as barcodes).

As noted above, the payee electronic device 70 may simply include a printer configured to receive transaction authorization from the TPS 2 and print out the order (and print out the receipt 74). The main burden of payment processing is borne by TPS 2 and PD 1.

Security measures described in previous embodiments may be implemented, such as digitally signed confirmation of payment from PD 1.

It should be noted that in one embodiment, transaction processing system 2 may manage database 86 . In such an embodiment, PD 1 may send a merchant ID, optional product code, or product family code to TPS 2, which may access database 86 and send back to PD 1 a menu of available items, including prices and descriptions . The payer selects the item via PD 1, and then sends the item list, store ID (optionally the location within the store) to TPS 2. The TPS then obtains payment authorization and sends the paid order to the store along with the customer identification. As mentioned above, the customer identification may include a code that needs to be matched with a code provided by the PD 1 in some form (eg, a barcode).

The merchant then provides the item (eg, food at a diner, food delivered to home, item delivered to home, item available at a store's pick-up point) to the customer. As also described above, deactivation of the secure ID tag allows the shopper to conveniently leave the store with the merchandise.

As noted above, there are a number of ways for the payer's electronic device to obtain information for billing and ordering purposes. For example, optical reading (e.g., camera software), smart card readers/RFID tag readers, etc. can be utilized to obtain store details and in some cases locations within the store, such as table numbers or points of payment. Items may be selected by scanning the item with an RFID reader/optical reader, scrolling and clicking a product/service menu within software downloaded to the phone, or manually entering a product code.

Below are five examples demonstrating the application of the system for ordering and payment in restaurants, diners, etc. according to embodiments of the present invention.

Example 1 - Standard full service restaurant

1. Generate a bill and send it along with an optical/electrical readable diner/table/amount;

2. The customer chooses/photographs the bill/wallet;

2(a). When the amount is not on the bill/wallet, send a request for the amount to the kitchen, then send the amount to the phone;

3. The customer adds any tips and presses the "OK" button, all done.

Example 2 - Diner with full service

1. The customer selects/photographs the table number (it is a small restaurant/table number);

2. Send a request for the amount (via the system) to the kitchen, then send the amount back to the phone;

3. The customer adds any tips and presses the "OK" button, all done.

Example 3 - Ordering and payment at a counter cafe

1. The customer selects the table number from the cashier or sits at a table that is not yet ready;

2. The customer selects/photographs the restaurant/table number (this number also indicates the phone number to enter the order mode);

3. Send the menu to the phone;

4. The customer enters the item number (2 digits maximum for most) via the menu/blackboard and presses the "OK" key. Alternatively, the customer scrolls through the items and clicks "OK" on the item to order;

5. The phone displays the completed order in text with the amount. Phone order sent with a salt, then text back to the phone - order and pay in one step! ! ;

4. Print the order slip in the kitchen;

5. The staff sends the prepared order.

Example 4 - Juice/Sandwich Bar/McDonald's etc

1. The customer takes a photo/selects the "small restaurant" number;

2. Send the menu to the customer phone;

3. The customer enters the item number (2 digits maximum for most) via the menu/blackboard and presses the "OK" key. Alternatively, the customer scrolls through the items and clicks "OK" on the item to order;

4. Send the customer name and send the order to be printed on the kitchen bar;

5. If the customer's name is called when the order is ready and there is no answer, the phone can buzz to remind.

Example 5 - Modern Full Service Restaurant

1. Customers can choose to order at the table, and there is a choice to signal the need for menu assistance. The staff can routinely inform the details, etc. After the menu is electronically "delivered", it can display "waiting for the staff to inform the details".

2. Even though the order has been sent, the phone returns to "more order mode", allowing further orders for dessert, coffee, wine, etc. End meal option Prompt tip - send payment and notify restaurant so staff can say "goodbye" etc.

3. Ability to order ahead by using the above system from the takeaway menu or stored list, sending the name instead of the table number - pick up the order, call in, pay, and be able to notify the buyer when it's ready.

As mentioned above, contactless smart cards can be used to provide or obtain payment-related information. Good touch type devices can also be used where a contact is touched by another contact to obtain payment information. These devices are well known.

Another example of a transaction flow where the payer is equipped with an electronic device capable of both initiating the transaction and making the payment is as follows:

The payee is provided with an identification code that identifies the payee with respect to the TPS. Provide a unique identification code for each point of service provided by the payee, which includes the table number, take-out food or other food service counter where the payee provides table service. Each payment station at the payee is also assigned a unique identification code.

The payee's identification code is set at:

1. Form for payee business card in print or electronic form

2. On the payee's printed menu or brochure

3. The table number identifier in the business premises of the payee

4. At any other convenient location

The payer initiates the transaction by specifying the unique identification code of the payee in one of the following ways:

1. Select the payee identification code from the stored list of "common payees" by the software on the phone or stored on the remote server used by the payee;

2. Manually input the payee identification code;

3. Automatically input the payee identification code;

3(a). Optical scanning of the identification code via a camera and decoding of software linked or incorporated in the device;

3(b). Via a "barcode" scanner or similar optical reader linked to or incorporated in the device;

3(c). Via an RFID reader or contactless smart card reader linked to or incorporated in the device;

3(d). Via an RFID or contactless smart card for activating the payee's device to provide the identification code to the device via Bluetooth or other wireless means.

If the payee identification number detected or entered into the payer device identifies the payment station, then proceed with the required transaction as described for payment.

If the identification number identifies any other point of service of the payee, it is assumed that the payer wishes to now identify the goods and services that the payer wishes to obtain and pay for from the payee.

The payee's device may then present a menu of options available from the payee.

The payer selects the individual items required by the item identification code. These codes can:

1. Use the device keyboard to manually input, such as 5<ok>, where "5" is the code of the desired item;

2. Select from a menu provided to the device by the payee using the known "scroll" method on a small device such as a mobile phone;

3(a). Optical scanning of the identification code via a camera and decoding of software linked or incorporated in the device;

3(b). Via a "barcode" scanner or similar optical reader linked to or incorporated in the device;

3(c). Via an RFID reader or contactless smart card reader linked to or incorporated in the device;

3(d). Via an RFID or contactless smart card for activating the payee's device to provide the identification code to the device via Bluetooth or other wireless means.

Upon completion of the list, the payee indicates completion of the list without entering any code, for example, by pressing the <ok> key. The payee's device may then display a list of items selected for viewing by the payee and the prices for those items.

Here the payee has the option to change the account from the default account to the account used for payment, to simply indicate to proceed (eg by pressing the <ok> key) or to cancel.

The payee's device may request a PIN or other biometric to confirm the transaction.

The list of items is then sent directly to the facility provided to the payee for receiving the list, and in a preferred embodiment printed, or indirectly via the TPS. Depending on the payee's commercial arrangements, payment may be completed before the list is sent to the payee, or it may be sent at a later time (such as when the customer receives the goods or services, or when the customer chooses to complete the transaction with the payee). In all cases, the system provides security for payments by identifying the payer from the outset.

The payer's payer device may be configured to allow continued ordering of additional items until specified by the payer. In this case, payment can be initiated at this time and the payer can be given the option to change the amount to be paid or to "split the bill".

Splitting the bill allows additional payers to join the transaction at the payee identification code, each payer indicating a share of the total amount (eg, 1 person, 2 people).

Figure 17 illustrates transaction processing using pre-approval processing according to an embodiment of the present invention. In this embodiment, by utilizing the payer electronic device, the payer can pre-approve payment for transactions that they have not committed. This is particularly useful for many transaction types or situations, for example in transactions where the card is not presented, such as payments over the Internet. According to this embodiment, the payer sends a pre-approval message including a pre-approval instruction to TPS 2. The pre-approval instructions may include details identifying transactions to occur subsequently. For example, the details may include the amount of the payment to be made. The payer then, for example, executes an Internet transaction, but before making payment for the transaction, the TPS 2 checks the pre-approval details with the transaction details. TPS 2 can then confirm or deny the payment depending on the match of the details.

In more detail, referring to Figure 17, at step 100 the payer determines the transaction they wish to perform. For example, a transaction may be an Internet transaction. A payer may request to purchase an item from a merchant Internet site. Thus, the payer is able to determine details of the transaction, such as the payment amount required by the merchant to provide the good/service sold.

In step 101, the payer sends a pre-approval instruction to the TPS. Pre-approval instructions include transaction details that TPS uses to confirm or reject subsequent transactions. The details may include any details that enable identification and authorization of the transaction. For example, they can include payment amounts for transactions.

At step 102, the TPS stores the pre-approval in a database. The database may include "Payment" information identifying the payer, "Amount" information including details for the pre-authorized payment amount, a "Transaction Number" and a "Time" (which may include the time the transaction will take place). Once the "time" has expired, the TPS may then not approve the transaction.

At step 103, the payer undertakes the transaction in the usual manner. For example, when the transaction is an Internet transaction, the payer may enter credit card details on a web page of a merchant website provided for receiving such details. Details also include payments that can be entered by the payer or automatically by the merchant. These transaction details are then provided to the TPS. They can be provided in a variety of ways. For example, they may be provided to the TPS via the usual transmission via the merchant system.

In step 104, the TPS checks the received transaction details against the pre-approved details in the database, and then authorizes (or not authorizes) the transaction depending on whether the details match. A confirmation may then be sent to the payer and payee (step 105). For example, confirmation of the payer can be done by SMS message.

If, in the approval process, the TPS requires further confirmation, they may use the method as described above in connection with the previous figures. Alternatively or in addition, they could exchange SMS messages, or even make phone calls using the payer electronic device.

As noted above, this embodiment is particularly useful for providing an additional authorization step for card-not-present transactions.

This embodiment can also be used as an extra layer of security for card presented transactions. Furthermore, the previous several embodiments of the present invention described above rely on the existence of an open communication channel between the payer's electronic device and the TPS for the transaction to occur. If these communication channels are not open when the card is presented for the transaction (eg, the payer electronic device is a mobile phone that is out of range of the appropriate transmitter), the transaction will not be authorized. This embodiment of the invention makes it possible to choose to pre-approve after a failed transaction. If a failure occurs, the Payer finds where there is an open communication channel between their Payer Device and the TPS, and provides pre-approval details. They then return to transact at a location where no communication channel exists. The transaction then proceeds as described above, even if the payer's electronic device falls out of communication range, the TPS compares the pre-approval details with those of the transaction in order to effectuate the transaction.

In the case of such a failed transaction, the system may have obtained transaction-related information from the merchant. That is, certain transaction information has been provided to the TPS due to an attempt to conduct a transaction but failed due to the inability to contact the persons phone. In this embodiment, the TPS may continue to try and contact the Payer's device until the Payer is within range. When the payer is within range and a connection is established, the authorizer entity can provide transaction information to the payer device, and the payer only needs to confirm that the transaction information is correct. Then, the payer then returns to the merchant and conducts the transaction again, at which point the transaction goes through due to the stored pre-authorization entered by the payer by confirming the details of the transaction with the authorizer entity.

For card-not-present transactions, as is often the case, the merchant provides the financial institution with details of the transaction and asks them to confirm that the payer has sufficient funds to pay and to hold those funds before placing an order to supply the payer with goods. Only after that the transaction will go through. In one embodiment, the TPS may use the merchant pre-approval information to contact the electronic device associated with the payer and ask the payer to confirm that the transaction is authorized. A transaction may be identified by some transaction details such as payment amount. Once the payer authorizes the payment, the transaction can then be processed. The details of the transaction can be kept in the database until the transaction actually occurs.

A similar pre-approval system could be used for online payments that people make with each other.

Another situation where this embodiment is useful is periodic payments, ie, payments made monthly to the payer. The pre-approval can be stored in the database along with the transaction time (eg, the time of month the payment should have occurred), the TPS checking the pre-approval details each time a payment request is received from the payee. This provides an extra level of security for recurring payments. It can also prevent payments from being made more frequently than agreed.

In another embodiment, a passive device for providing information to PD 1 may include information related to an application used by the passive device. For example, when the passive device is a barcode, it may include information related to an application that needs to run on the PD device 1 so that the barcode information can be processed.

Referring to Figure 18, a number of different payment processing applications configured to run on PD 1 may be provided. For example, payment processing application 150 may be configured specifically for payment processing for parking meters. Another payment processing application 151 may be configured to process payment of bills, and another payment processing application 152 may be configured to process payment to restaurants. In another embodiment, the application may not involve payment processing at all, but have other functions. For example, one application may be a business card application that enables PD 1 to upload and process business card information.

The advantage of this system is that having information in the barcode related to the barcode itself enables the PD 1 to get the correct application or identify the application if the application is already on the phone. When it is necessary for PD 1 to obtain an application, the barcode can provide location information from which the application can be obtained, such as the location of an Internet node.

The passive device is not limited to the barcode 153, although a camera 55 is readily available using conventional telephone technology, it could be any other type of passive device. Applications may be stored in a database accessible over a network such as the Internet.

FIG. 19 illustrates possible components of a transaction processing system 2 . In one embodiment, the transaction processing system may include a gateway 160, which may include systems for communicating with payer devices and payee devices, as well as systems for communicating with "back-end" processors. A routine transaction would typically require the merchant device to communicate with a payment gateway managed by the acquirer 161, which in turn communicates with the financial institution 162 (which may be the issuing bank) to determine whether to authorize the payment. The acquirer 161 will then typically provide authorization or denial to the payee device. The TPS of an embodiment of the present invention may indeed simply be the acquirer 161 with appropriate systems, or may be a separate entity that operates the gateway 160 and provides information to the acquirer from either the merchant device or the payer device. The Gateway may also run a "Universal Shopping Database" 163 that enables Payer devices to upload menus, and a Transaction Pre-Approval Database 164 that enables Payers to download pre-approved via the Gateway, as described in connection with the above embodiments.

A TPS may include an organization that performs all of these functions individually, or all of these functions together, or a combination of different parts that perform these functions.

A transaction processing system may be implemented by suitable software and hardware, typically a server computer.

20 is a block diagram of components of a retrofitted mobile phone that may be used to implement a payer device according to an embodiment of the invention. Most of the functions discussed in the previous sections of this text can be implemented by software loaded into the mobile phone in the form of applications 121 . These applications include payment applications that enable the preparation of appropriate messages. With these applications, mobile phones can be configured to recognize payment information. This is generally not possible with standard computing equipment.

Consider the World Wide Web for comparison. The World Wide Web constitutes a universal browsing database. The network includes a system in which information can be retrieved using a "request" that combines a description of the "site" and additional location information within the site (known as a URL), which allows information in a common format that is structured to handle the A computer capable of displaying and processing text, graphics, and links in this format.

Currently people can shop online, but there is no system that allows computers to shop online. The web language (html) specifies tags so that a computer can recognize and display headings, recognize and display links, etc., but cannot recognize item codes or prices. A user of the computer must read the information on the screen and determine whether an item description or price exists.

Applications 121 may include applications that enable a payer device to recognize and process payment information. One proposed embodiment includes a "universal shopping database" as described in the following examples. For such a database, the request may specifically contain a code identifying the store offering the product for sale, and instead of getting a display page, the following two types of requests are required:

1. A request to obtain descriptions and prices of items for sale in a format convenient for automatic processing and in a common format enabling a computer to automatically create a table of prices and descriptions from individual responses. This request is referred to as a "menu" request; and

2. General request to purchase items or to collect items obtained from the previous "menu request".

An example of online shopping using conventional web language (html) is as follows:

Request＝www.sampleshop.com/buypage.html

Response＝

<! DOCTYPE HTML PUBLIC″-//W3C//DTD HTML 4.01 Transitional//EN″

"http://www.w3.org/TR/htm14/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<title>Untitled Document</title>

</head>

<body>

<h2>Welcome to the shop! </h2>

<p>Click<a href=″buywidget.html″>here</a> to buy a widget for $50! </p>

<p>&nbsp;</p>

</body>

</html>

Website browsing programs use tags to process information related to website browsing, for example, the text between the tags <h2> and </h2> is a heading.

The fact that the price of a "widget" is $50 has nothing to do with the web browser.

For comparison, using the proposed "world store format", the request would look like:

"store=1234, menu=a"

And the response is as follows:

<itemID>1567<itemDesc>Widget<price>5000

The response needs to be read by a "shopping program", not a "web browsing program". In this case, how the information is displayed depends on the "shopping program". However, the program knows that items are sold for a certain price. If the user chooses to buy the item, the program knows that the item is being purchased.

This has the advantage that the security measures required to make a purchase can be automatically applied by the program, and a history of purchases can be automatically saved.

Other applications 121 that enable the phone to read barcodes (or other passive devices) may also be loaded.

Furthermore, to further add security measures as described above (further exemplified later in the specification), firmware 122 may be employed.

The adapted phone includes transmitter/receiver 119, processor 118, SIM card 116, clock 123, RAM 117a, flash ROM 117b, LCD display 133 and driver 130, keyboard 112, navigation keys 110, camera 124 , speaker 115 , microphone 116 and A-D converter 114 . It also includes an antenna 120, a wireless module 125 (such as Bluetooth or General Packet Radio Service (GEPRS)).

The hardware may also include a security module capable of identifying the user using key encryption. The security module was set to the well-known cyrtosis, a systematic or electrical curve encryption method defined by Rivest, Shamir, and Adleman (RSA). When the device is a mobile phone, it includes a SIM, which in any variant of this embodiment is arranged to act as a security module.

The payer device may not include all the above-mentioned components for implementing the embodiments of the present invention. For example, for some embodiments, such as pre-approval, it is not necessary to have an access device or firmware. In other embodiments, to provide an additional layer of security, only the firmware may be provided without the access device. The access device and firmware provide four layers of security.

To sum up, the system can be implemented by an electronic device (such as a mobile phone) associated with the payer, basically implemented in three levels:

1. A standard mobile phone, with or without JAVA or another application to make it more user friendly. The basis of the system at that level is that in the absence of a secure mobile phone, security measures must be added to existing security measures. At this layer, pre-approved approvals for transactions can be implemented, for example, by simple SMS messages.

2. The system "protects" the mobile phone. Virus-resistant firmware is used to provide the signature system, and software is used to process incoming messages from the system. Signature and PIN pads can be replaced by approving all transactions using the mobile phone.

3. The use of contact and contactless IDs (access devices) and mobile phones to initiate payments are the primary communication devices for transactions.

It should be noted that payer electronic devices may not include modified mobile phones. It may include any other computing device (preferably portable), such as a PDA. It may even include specialized devices specially constructed as payer electronic devices.

The term "electronic equipment" should not be considered limited to equipment operated solely or entirely by electronic means. The present invention may use any type of processing device (eg, a device that may execute using optical transmission) as the payer device and/or the payee device.

Another embodiment of the present invention can be utilized to avoid having to prompt the payer. The payer device, when prompted, registers a person (payer) via the system, which sends a signal to the phone either directly or through a server. Alternatively, when the phone is in alert, the phone may periodically pole the alert state to inform the user of the current state. This can be used in any alert to notify the payer when the order is ready. Either give a reminder of the prompt code, or read it electronically through a contact list or other electronic device or use a camera (barcode) to read it optically. The system then provides continuous status updates of what number is at the top of the prompt, enabling the phone to display the last few numbers served before you. The system includes an alert database, and means for notifying phones of their position in the alert. Thus, the payer device can be ordered in advance and the payer is notified when the order is ready to be picked up.

Several other examples of embodiments of the present invention will be described below.

The improved payment system of the present invention takes advantage of the fact that most consumers in many markets bring their own computing device (usually a mobile phone) to the point of sale. A low-cost retrofit to this device could enable a new payment system not only to handle the security issues of current systems, but also to bring in many new additional novel features.

With this new system, merchants will advantageously have new and improved ways of accepting transactions. Banks can reduce or eliminate costly charge backs and increase consumer confidence. Cell phone companies have a new "killer:" apps for cell phones.

The system of an embodiment of the present invention utilizes a modified consumer electronic computer in the form of a mobile phone or pocket computer that has been "upgraded" to operate anywhere in the wireless coverage area. The system proposes that all transactions include verification from the consumer (payer) using the upgraded device. In this way, all transactions are verified by consumers. Real-time transactions such as purchases at the point of sale, over the phone, or over the Internet can be verified at the time.

Any background recurring payments such as bill payments will be approved in its entirety at the time the payment is set up, in this example making any follow up on a 24 hour cycle if required to cover the consumer sleeping or being unavailable at the time of the transaction additional approval.

The payment system allows for the changes required to be made to the mobile phone or pocket computer so that verification of payment transactions can be performed securely and simply.

Also consider the changes to the rest of the payment system required for optimal operation, and take advantage of opportunities that arise when such devices are part of the system.

In this example, in most cases, a mobile phone or pocket computer can be wirelessly accessed while the consumer is making a purchase.

Upgrading the unit for optional operation requires the unit to be equipped with:

●Wireless data communication systems such as GPRS or Bluetooth

● Software and/or firmware to facilitate payment verification

● A security module capable of “signing” transactions using public key cryptography

●Contactless smart card. The device is also capable of being programmed for payment functions before being provided to the consumer or in the field.

Note: Although the device is called a PINpad, it is not necessary to use a PIN.

Contactless smart cards are provided to consumers on the principle of payment systems. Contactless smart cards are well known devices that are commonly used in transportation systems. A typical feature of a contactless smart card is that it is powered and "read" (actually communicates with) a device called a contactless smart card reader at a distance of 0 to 10 cm.

In the preferred embodiment of the system, the consumer places his contactless smart card on the back of his mobile phone so that it does not interfere with any camera, battery cover or other functions of the phone (or pocket computer). Any electrical connection between the card and the consumer device is unnecessary. Physically connecting the card is for convenience and to combine the card with the device.

Initiating a payment in a system according to an embodiment

Upgraded payment points

To initiate a payment at a payment point equipped for the new system, the consumer touches a pocket PINpad to a specially marked reader at the payment point to indicate that he/she wishes to make a payment with the system.

A contactless smart card (attached to a phone or pocket computer) relays the details to the point of payment for further communication between the two devices at a distance. Now that the point of payment has the details of how to access the pocket PINpad, the consumer now only needs to stay within range of the wireless communication built into his pocket PINpad.

traditional payment point

An optional feature of the system is the ability to offer the new payment system even at payment points that have not yet been upgraded to accept the new system.

To provide the system at these existing payment points - the customer's bank activates the system in the background.

In this case, the consumer's regular credit card can be presented at the point of sale, and the transaction proceeds like a traditional transaction. When the payment request reaches the consumer's bank, the bank sends the payment approval request directly to the consumer's mobile phone. Once the consumer approves the transaction, an approval message is returned to the bank, and the transaction is authorized all the way back to the merchant terminal.

Improved payment transactions

Details about what wireless system (e.g. Bluetooth or GPRS) can be used to contact the pocket PINpad and any information needed to send the information to the correct pocket PINpad has been obtained from the card (e.g. Bluetooth ID or GPRS case phone number). The payment device sends the transaction amount to the Pocket PINpad and stores the details for payment.

Some transactions will allow consumers to change the amount. After the amount change has occurred, the consumer optionally enters his PIN or simply says "ok" and the pocket PINpad electronically "signs" the transaction to signify the consumer's consent to the transaction.

Then, the transaction is sent to the bank. The bank processes the transaction and sends a record of the transaction back to the consumer and merchant devices.

When the merchant device receives a record of the completed transaction, the device signals the store salesperson or vending machine that the payment is complete.

Retail, point of sale, card-based systems

Most of us are familiar with credit and debit cards. Two types of cards that are widely used are:

● magnetic stripe based cards; and

● A "smart card" with a computer chip.

From an operational point of view, payments with both cards are similar. The payment steps are usually as follows:

1. Payment steps - hand over the card to the merchant

• The consumer presents the card to the merchant.

• The merchant uses the card in the payment terminal.

● Merchant enters payment details.

• If a PIN is required, enter it on the PIN entry device.

● Send the transaction to the bank through the merchant's payment device.

• Display the bank reply on the merchant's payment device.

● For no PIN transactions, the merchant obtains the consumer's signature and retains it.

In a variation of payment processing where instead of the consumer handing over the card to the merchant, the consumer enters his own card into a reader designed to be operated by the consumer. This variation attempts to reduce some of the security concerns in the process by reducing the risk of the merchant guarding the card and thus being able to duplicate the consumer's card.

In general, there are several problems with processing.

Issue 1 - Equipment Change

With a payment device installed at a point of payment, the merchant has ample opportunity to learn how to operate the device and, should any tampering with the device occur, the merchant has ample opportunity to detect such tampering. However, consumers may be confronted with entirely different devices at each point of sale. This caused the following problems:

• Self-service payment points are slow and confusing to operate as consumers familiarize themselves with the equipment.

• Any transaction step that should be performed by the consumer for security reasons will face the barrier of the consumer operating unfamiliar equipment. This results in merchants performing steps such as card swiping and account selection, rather than explaining the operation to consumers.

● Alternative devices are readily used by unscrupulous merchants to collect PIN and card details.

Question 2 - Transaction Signing

Various methods have been proposed to enable consumers to "sign" a transaction to signify voluntary participation.

●written signature

Reliably detecting problems in written signatures at the time of transaction requires an unreasonable amount of skill on the part of the merchant. Filing and storing these written signatures also places an unreasonable burden on merchants. Presenting the card for signature verification also forces the consumer to surrender control of their card.

●Electronic PIN verified by the bank (or financial institution)

The PIN entered into the merchant's device can be easily obtained by the merchant's replacement device. This can cause serious attacks on personal funds.

●Electronic PIN verified by smart card

By utilizing the consumer's card to verify the PIN, the risk of PIN theft is greatly reduced. Unfortunately, this system has not been properly adopted widely enough.

Question 3 - Duplication of Cards

The ability of cards to be duplicated is a major drawback in current card payment systems. Magnetic stripe cards are easily duplicated on relatively inexpensive equipment.

While smart cards do in theory virtually eliminate the problem of card duplication, smart cards also contain magnetic details and many merchants worldwide accept magnetic details alone. At any time the card is presented, the magnetic details can still be copied and used for fraudulent transactions worldwide.

Issue 4 - Duplicate Transactions and Amount Spoofing

There are many ways in which merchants charge cards multiple times or charge an amount beyond the consumer's approval. Small sums may go unnoticed by the consumer, but the consumer suffers losses. However, large sums of money can be detected. By the time the statement arrives, the merchant may have disappeared. Although these are not the most serious problems in the current system, plugging other vulnerabilities to keep these problems will see a significant increase in the severity of these problems.

Question 5 - Tipping

Many transactions allow for an optional gratuity component. The only practical solution to tipping with the card used in the merchant's terminal is to add the tip after the bank has approved the transaction.

It is impractical for a consumer to enter his tip into a merchant's machine.

Letting merchants add tips to completed transactions creates shortcomings in the system. What recourse does the consumer have if the merchant is to incorrectly add a larger tip? First, the consumer must detect the problem. Then looking up that transaction and forcing the merchant to produce an original signed receipt is the problem. Costly and painful for both parties. Although merchants will eventually be found to be systematically underreporting fees (skimming), many consumers will still be charged additional fees after the problem is discovered (problem employees may be long-term!).

internet payment system

There are currently two types of Internet-based payments that are practical.

1. Really secure internet payment

Truly secure Internet payments are often mentioned, but rarely implemented. First, secure Internet payments require smart cards, and consumers don't have smart cards. The SET of MasterCard, Visa, etc. is one of the systems using smart cards that were first widely spread. Second, to be truly secure, an accessory to the PC is required that not only reads a smart card, but also displays the amount to be spent and accepts a PIN to sign transactions. For example, such systems are well known (see FINREAD).

Smart cards are used to provide secure non-reusable digital signatures for transactions. Since worms and viruses leave information on the main computer display open to alteration and access by remote parties, a separate security console is required to pay for it. Use the PIN pad on the console to instruct the smart card to create a digital signature for the amount securely displayed on the console.

Nowadays such transactions are as safe as possible. In order to create a transaction, one needs both the original smart card and the PIN. Obtaining a duplicate card is practically impossible.

The problem is that most people's PCs don't have FINREAD-type accessories, nor digital certificates that use smart cards. Systems are currently difficult to justify in terms of cost just to secure people's Internet transactions.

To avoid this problem, card associations such as American Express and Visa offer different alternatives.

The American Express personal payment program requires American Express cardholders to first log in to an American Express site, "pre-allocate" a payment amount and receive an ID for that allocation. The cardholder can then use the ID to purchase merchandise on Internet merchant sites linked to American Express Personal Pay. This method has the advantage that the purchase transaction can be carried out without using the card number, but it is quite cumbersome for the cardholder to use, and it has not been widely implemented in merchants so far.

In Visa International's 3D-Secure solution, cardholders still enter their card number, but only when the issuer, not the merchant, asks for it. The scheme relies on well-established SSL/TLS technology to secure the link between all parties involved in the transaction. Due to the complexities involved, this scheme is only attractive to larger merchants.

2. Mainstream “safe” internet payments

Mainstream "secure" internet payments simply mean that payment details are transmitted securely over the internet. While intermediaries cannot intercept card numbers being used, Internet merchants themselves must be trusted to keep the card numbers they receive confidential, charge the correct amount, and only bill under specified circumstances. Merchants who receive these payment details cannot determine with certainty who sent them.

Basically, the consumer has to take it on faith in the merchant, and this is expensive for the merchant when they add protections like checking where the item was delivered and signing when delivery was received. When goods are delivered electronically, it becomes even more difficult for merchants to add any protections, and as a result, fraud in such transactions is costly.

Advantages of the system of the above embodiments

If a new infrastructure for the system of this embodiment is adopted in the future, security costs and transaction costs can be reduced. The benefits of the new payment system for consumers, merchants and banks justify the rollout of the new system.

Safety

The solution according to this example of the invention provides the highest level of fraud protection available today. Purchases receive the same protections as FINREAD-type Internet transactions. It's as if consumers brought Internet terminals and smart card readers to the point of sale.

While it is true that many of today's security problems could be greatly reduced by the ubiquitous introduction of smart cards, this example goes beyond that and advantageously even eradicates problems still lingering due to the move to smart cards.

Further protection is provided by:

●Ability to verify the safety of the purchase amount;

●Prevent changes in tips and amounts;

●Prevent doubling charges;

● Eliminates the risk of copying even at the magnetic card level;

● the ability to protect even "traditional" transactions by allowing consumers to verify transactions at points of sale not equipped with the new system;

• In all transactions except traditional, provide the merchant with proof of payment but not the consumer's card details.

cost

The infrastructure cost of the improved system is low by utilizing devices (eg mobile phones) that consumers are already prepared to pay for.

The payment terminal can be thought of as "split in two" - one part of the terminal is the mobile phone carried by the consumer, and the remaining merchant components are greatly simplified and reduced in cost.

This enables more payment points such as parking meters, vending machines and self-service points of sale in malls.

speed

Increase transaction speed in all cases by enabling consumers to offload transaction loads across familiar devices. Self-service point-of-sale payments enabled by the system will also allow consumers to pay instantly, rather than waiting in line for service in most cases.

Not only can checkout be made faster, but customers in restaurants can be spared the entire extra step of removing their cards for processing.

flexibility

The new system brings a whole new level of possibility to electronic payments.

New conveniences include:

entrusted payment

When paying, consumers can designate a parent or friend to pay on their behalf, as long as the designated person is an absent "only phone call." This allows other loved ones of the child to have access to emergency funds - but ensures that other emergency fund providers' parents monitor the use of such funds.

When paying, consumers can designate a parent or friend to pay on their behalf, as long as the designated person is an absent "only phone call." This allows other loved ones of the child to have access to emergency funds - but ensures that other emergency fund providers' parents monitor the use of such funds.

split payment

Been to the restaurant? Ever had a situation where an account should be split into two, three, or even more? Adopting cash seems to be the only solution for now. While most restaurants will split the account in two ways for payment by card, even this is a messy solution. Every additional card or other complication makes it harder to pass on the wishes of different cardholders.

Equipped with their own personal PIN pad, each diner is able to make their own payments without having to communicate with the restaurant at all for explanation.

Amount change

Not only can the amount presented to the consumer be securely verified by the consumer - but it can also be changed with specified parameters. This works especially well for tipping. Current systems for tipping are generally only valid for credit card transactions. Transactions without tip are approved by the bank. After reading the tip amount written by the customer on the receipt, the merchant then processes the changes to the original transaction.

This is problematic for both consumers and businesses. For the merchant, it is necessary to retrieve the original transaction (in a busy restaurant, there may be several receipts on the table at any one time) and enter the new amount.

For consumers, there is no way to verify the actual final amount entered by the merchant, and it is difficult to detect errors due to merchant misreading, overcharging, or any other factor.

With this embodiment, the consumer can add the amount to be paid directly onto his own device - the correct amount being processed first. Merchants are not required to re-enter. Sources of error and doubt are completely eliminated.

account selection

Multiple bank accounts can be linked to the payer device and alternatively can be selected as the default account. These accounts do not need to be from the same bank.

The system of this embodiment also advantageously provides additional convenience.

Self Service Payment

Self-service payment points can avoid lines and make it possible to deliver goods and services in locations where this would not be possible otherwise. Historically, payment at these self-service payment points may have been by coin (and sometimes paper money). Where credit/debit cards are accepted, the customer or service provider must pay for expensive equipment and phone calls.

Paying through the system advantageously reduces these problems. Acceptance equipment is low cost and does not require a phone call. Preferably, the consumer utilizes the same payment device (in his own phone) without having to learn how to use a new payment device for each payment point. Reading instructions and difficult card readers are a thing of the past.

Select account at all payment points

The current system often limits account types for logistical reasons. For example, entering a PIN may be problematic in a restaurant. Utilizing the payer device system eliminates this problem because the request to enter the PIN is transmitted to the customer at the table. No instructions to the cashier are required, and there are no restrictions on PIN entry.

The scenario where a merchant asks for an account and then compares it to save consumers from choosing an account on an unfamiliar device is a thing of the past.

bill verification

When the bank statement arrives, the mobile phone can immediately reconcile the account balance of all electronic transactions verified by the system. This removes the worry of "am I being overcharged" or the hassle of coordinating for the consumer.

receipt filing

For all transactions signed electronically, paper receipts are not required. This simplifies costly claims, tax records and other accounting for consumers.

Eliminating the need to keep paper signatures as proof of transactions is a huge benefit for merchants.

general application

The same verification system can be used for all payments (telephone order, internet, existing traditional payment systems at point of sale as well as new improved low cost payment points).

Card issuers and mobile operators need upgraded systems. Once it's in place, every participating cardholder sees immediate benefits. There is no need to wait for an upgraded device to reach a merchant before the system has value.

equipment

consumer device

A form of wireless communication is required (in some embodiments not required) for the system to convert a consumer device to a payer device. Currently, three wireless communication systems are widely used - 802.11, Bluetooth and GSM+GPRS/CDMA.

In this example, each device is considered to be suitably equipped with a form of wireless communication capable of communicating between the consumer and the network at most points of purchase. Examples today are GSM and GPRS or CDMA mobile phone data communications. As the prevailing wireless protocols used change over time, the wireless systems to be used also change.

This paper discusses a system based on GSM+GPRS mobile phones which are additionally optionally equipped with Bluetooth communication.

New software and firmware

The software on the device in this example should include specific features not currently found in phones.

in particular:

• Ability to receive a payment request command through any wireless system enabling payment in the device and pass the request to the SIM module.

• Ability to display payment request messages from the SIM module and pass data entries back to the SIM module.

• The ability to display the PIN entry message in a manner that cannot be replicated by any application loaded into the phone.

• Present the answer to the payment approval message directly to the SIM.

• Answers to payment approval messages cannot be sent to the SIM by any application software.

It should be noted that another processing module could be used instead of the SIM, but the SIM is preferred for mobile phone embodiments.

Based on these requirements, it was concluded that payment approval message display and response should be implemented by firmware. Preventing applications from generating responses to payment approval messages ensures that no software worms or viruses can be used to cause the phone (or other consumer device) to approve payments that the consumer does not yet know about.

Reloadable software may be used to implement this functionality in the Payment Approval screen, provided that, when completing any function of the secondary function, it is ensured that the payment approval screen displays the amount that will be sent to the SIM in the message as the amount that the consumer approves to pay. on the screen.

contactless smart card

Contactless smart cards are well known. A preferred embodiment of the system equips each device with a contactless smart card for easy payment at new types of payment points. Contactless smart cards also facilitate enrollment of consumer devices with financial institutions.

It is desirable to use a contactless smart card that is as small as possible while still allowing any necessary antennas to be present within the card. It is also desirable to manufacture the card using flexible rather than rigid materials so that the card can adhere to the contours of the housing of the consumer device.

It is desirable that the card be able to securely and uniquely record the card's presence at the point of sale. This requires the card to contain the encryption key used to sign messages from the contactless payment reader.

The contactless smart card should also be able to transmit the information needed to communicate with the payer device associated with the card. Such information includes the Bluetooth ID and phone number of any Bluetooth modules incorporated in the consumer device to enable communication with the device's wireless module.

The contactless card is also capable of transmitting the capabilities of the matching consumer device (eg, Bluetooth-non-Bluetooth, GSM-GPRS or CDMA, etc.) to the reader.

The contactless card is also capable of sending the matching security module's public key (see below) to the reader as used by the financial institution, in this case the public "initialization" key.

SIM or security module

To ensure that the transaction has reached the correct device, it is desirable to be able to encrypt data with a key that the financial institution can verify belongs to the cardholder. Such systems are well known and have been proposed in almost all payment systems based on smart cards. In the case of GSM mobile phones, a security module is also already present. All that is required is that the SIM in the phone can meet the requirements specified here or be replaced by a SIM that can meet these requirements.

In a preferred embodiment, the SIM in the GSM phone is equipped with secure memory for the keys used for financial transactions and the encryption algorithms for matching. Well-known encryption standards such as RSA or elliptic curves are suitable. This system utilizes a pair of keys, a "private" key (secretly and securely stored on the consumer's card) and a public key. Data encrypted with one key can be decrypted with the other key. Simple drop-in and data can be sent to the card by encrypting it with a private key, and trusting that only the card with the matching private key can be used to decrypt the data. Instead, any data correctly decrypted with the public key originates from the card with the private key.

To enable financial institutions to install keys on issued SIM cards for their cardholders, a public/private "initialization" key pair is used, the private key held in the SIM card and the matching contactless smart card public key.

Bank Authorization System

Every bank that issues debit or credit cards is required to ensure that the system maintains records of each cardholder's balance and the approved minimum balance. The system is upgraded to send a payment approval message to the cardholder's payer device when the system is enabled.

The balance verification system formats the message and sends it, along with the details, through the system when the payer device is recognized.

The cardholder may need a way to enable and disable the system to allow movement outside of the area in which his payer device can communicate.

Mobile Phone Communication Gateway

The new communication system receives the payment request from the card issuer and sends the request to the payer device. The system can consist of one integrated gateway system for all transaction types or separate gateway systems for one or two transactions, or can be added as a new function to an existing gateway. The gateway should be able to be used for three transaction types:

●Start the payment authorization request and send it to the payer’s device;

● Responding to payment received from the payer device;

• Pass the transaction signed by the payer device at the point of sale to the appropriate financial institution.

In the first two of these cases, the gateway will act as an interface between the financial system and the payer's device. The issuing bank still needs to approve the transaction. In the third case, the financial institution that receives the approved transaction is usually the acquiring bank.

It should be noted that the traditional roles of card issuers, acquirers, and card associations (eg, Visa) can be evaluated when implementing a preferred solution.

Card

For a long time, traditional payment points have required existing types of magnetic cards to initiate transactions. Lower transaction costs for new types of point of sale will encourage their addition to point of sale over time, but the system still gives current card based point of sale adequate protection without requiring any upgrades.

New cards can be issued that are not linked to a specific bank account.

payment device

Existing electronic payment acceptance equipment worked with the unchanged system - but did not take advantage of the new equipment being provided.

Some devices already get instructions from the bank on a card-by-card basis whether to request a PIN or signature. It is proposed that the system be linked to existing signature cards - or new payment cards issued for this purpose - rather than PIN-based cards.

Even small changes to configuration or programming will improve the efficiency of transactions with payer devices. Additional benefits are obtained with systems having reprogramming devices, and still further benefits are obtained with systems having new generation payment devices.

Payer devices in one embodiment may have three types of wireless communications for flexible operation:

• Very short range (approximately max 10cm) wireless communication for initiating transactions.

• Local area wireless communication for communicating with payment points (or payment terminals) throughout the transaction.

• Worldwide wireless communication, enabling communication between the payer device and the bank where the customer holds the account, no matter where the customer is globally, or at least in as many locations as possible.

The payment system is able to function in a version that does not need to implement all of the above systems. This proposal would allow the easy and low-cost conversion of current mobile phones or pocket computers with radiotelephone modems into working payer devices.

Only a single type of wireless communication

An exemplary payer device includes only one type of wireless communication. Local communication enabling communication with the point of payment or remote communication enabling direct communication with the financial institution with which the account is held is technically sufficient.

Such a device may be operative to communicate with a financial institution through a payment point, or operatively to communicate with a payment point through a financial institution.

Since no facility is incorporated to initiate transactions, these devices would effectively be suitable for securing traditional transactions.

Short range + local area wireless PIN keyboard

Devices with short-range and local area wireless communication capabilities can both initiate and execute transactions at payment points equipped with all three types of wireless communication.

Short-range + long-range wireless payer equipment

Long-range wireless devices utilizing private data networks or mobile phone networks are widely used and short-range wireless communications can easily be added.

Full System Payer Device

Take any mobile phone that is also equipped with Bluetooth (or has the ability to be equipped with Bluetooth), add the necessary firmware and a packet containing the appropriate SIM and contactless smart card, and you have a multi-purpose payment man equipment. Adoption of these devices requires only ambitious mobile phone system operators, as they have the ability to request phone manufacturers to add firmware and access SIM and contactless smart cards.

Integrated full system payer device

As with upgrades to "full system" payer devices, near-range wireless can be integrated into payer devices at the time of manufacture. This would allow the payer device to not only send data but also receive data short-range. This capability will make direct person-to-person payments more flexible.

payment transaction type

Traditional transactions utilizing payer devices

Traditional transactions using the Payer's device proceed like normal credit card transactions until the transaction is received by the traditional card issuer's transaction approval center. At this point, a payment approval request is sent to the payer device.

Once the payer device receives the transaction, the consumer can choose where to pay his account and approve or decline the transaction.

The consumer's response is sent through the gateway back to the approval center - which then processes the transaction and sends the result back through the traditional system. The result of the transaction is also sent through the gateway to the payer device for filing by the consumer and as an electronic consumer receipt.

Near + Long Distance Wireless Payer Device Transactions

In the case of payment points specially equipped with payer device transactions, the consumer indicates his willingness to make a payment by touching his smart card to the payment point, rather than using a conventional credit or debit card. The merchant should have entered the amount to pay (or, for variable amount transactions, the range to pay) into the point of payment device.

Approval requests for transactions collected by the point of payment device should be sent directly to the payer device gateway. The consumer again uses the payer device to modify and/or approve the transaction, and then sends the result from the payer device back to the gateway, which sends the information from the payment point along with the reply from the payer device to the financial transaction approval network. The transaction result is sent back to both the point of payment and the payer device to provide an electronic receipt for both devices.

Local Area Wireless Transactions for Complete Payer Devices

Payment points that currently accept traditional cards will continue to do so for the foreseeable future. When additionally equipped for payer device transactions, these payment points can deliver transactions faster for payer device transactions than traditional transactions without much effort from the salesperson. The ability to process traditional transactions requires payment points to be equipped with communication links to financial transaction approval centers.

When the payment point configured for the payer's device detects a device with local area wireless capability, the payment point can directly send a payment approval request to the payer's device through the local area network.

When the payer device receives a payment approval request over the local area network, it first allows the consumer to change and/or approve the payment approval request. The payer device then examines the request to determine whether to send the transaction directly to the payer device gateway, or back to the payer device via a local wireless connection to the payer's point. In this case, the transaction is sent back to the payment point.

The payment point then sends the transaction by approving the same network that traditional exchanges use. After receiving a response to the transaction, the payment point communicates the transaction result to the payer device to provide the consumer with an electronic receipt.

Remote wireless transactions for complete payer devices

In locations that have not previously offered electronic transactions, or in some cases even where traditional transactions are accepted, it may be desirable to provide low-cost payment acceptance points that do not themselves have remote communication capabilities (eg, no modems or telephones).

In this case, the payer device may be used to send the transaction for processing and receive the result.

Local area wireless transactions for the complete payer device (except that the payer device is responsible for sending the transaction for approval through the payer device gateway) and the payer device sending the electronic record or transaction to the payment point, both of which provide A record of the transaction and allows the merchant to identify the consumer's payment.

system security

Where does the security of the system come from? The SIM module (or other designated system processor) securely stores the keys used to encrypt data and create digital signatures using well-known techniques (eg, RSA). Thus, it is guaranteed that every payment approval sent from the phone is generated using this SIM module.

This leaves only two possibilities for fraudulently generating a transaction that the consumer does not approve: 1) someone other than the consumer uses the phone or SIM, or 2) the payer device has been The authorization for the transaction is generated in the case.

PIN and Other Biometrics - Payment Device Theft Prevention

A PIN is only one form of biometric. It exists in the user's memory, and by retrieving that memory, the user identifies himself as the person who owns it. The system can use any form of biometric such as PIN, fingerprint, eye scan, facial recognition.

In a preferred embodiment, whichever biometric (PIN, fingerprint, eye scan, etc.) is being used will be required each time a preset amount is reached or for any transaction exceeding that preset amount. For example, consider a preset amount of $100. Transactions of less than $100 can occur until all of these consecutive transactions total more than $100. The first transaction to reach the aggregate of consecutive non-biometric transactions will require biometric authentication.

Amount of the transaction Biometrics required? reason $300 yes The transaction is greater than the preset limit $10 no Only $10 spent since last biometric $50 no Only $60 spent since last biometric $60 yes With this transaction, $120 has been spent since the last biometric $30 no Only $30 spent since last biometric $150 yes The transaction is greater than the preset limit $80 no Only $80 spent since last biometric (including this transaction)

It is important to note that biometrics should only be used by the SIM. The SIM internally authenticates the biometrics before subsequently signing the transaction as consumer-approved. Whatever biometric is used should not be sent outside of the payer's device. If a PIN is used, it should not match any PIN currently used in ATMs etc. Whatever biometric is used is of no value to anyone who does not have access to the payer's device.

The use of biometrics (PIN or otherwise) is to limit the amount that can be spent by anyone who gains unauthorized access to the payer's device (although the use of biometrics can be applied in other ways).

firmware protection

The principle of the system according to this example is that the user of the payer device must be sure that the data displayed on the signing screen and accepted by the user is the only data that can be signed with the payer device.

This can be achieved through firmware in the device. The firmware is arranged such that a single firmware has the following functions:

1. Display information to the user,

2. Accept "OK" and a PIN or other biometric, and

3. Send the data displayed to the user to the security module (usually SIM).

Prevent the application from performing step 3 above without presenting the user with exactly the same information that was sent for encryption or digital signing.

Firmware protects the payer device itself from software attacks. Through various wireless interfaces, devices may be open to virus and worm attacks. The design is to ensure that any interface provided for the application software to send data to the SIM specifically prevents "payment approval" messages from being sent to the SIM. Only the Payment Approval Display routine can send this response. This ensures that the consumer sees and physically presses some minimal form of "OK" button to approve each transaction.

The filter prevents the application software from issuing a "generate signature" command directly to the security module or SIM.

set the standard

There are many possible configurations for this system. As with any deployment, it is necessary to determine which wireless and encryption standards are most applicable in the market where the system is to be deployed. The problem caused by multiple standards around the world is that when a consumer moves into an area where for example their own payer device cannot communicate due to different standards, they will be faced with the following options: 1) Get the 2) they may need to temporarily disable the system.

Currently, GSM is the preferred global system, however, for example in Japan an iMode system would be a logical choice.

system deployment

In order to initially deploy the system, at least one bank (or other card issuer) and one mobile phone system operator need to cooperate to deploy the system.

The role of mobile phone private system operators

• Mobile phone operators set standards and require at least one mobile phone provider to incorporate the firmware.

• The mobile phone operator then promotes the retrofitted phone, SIM and package matching the contactless smart card through retailers who sell the phone and the mobile phone operator's custom service.

• A manufacturer of a SIM for a mobile phone will have all the knowledge to manufacture a suitable SIM and contactless card through the instructions provided herein. The network operator sends these instructions to the

SIM provider and order SIM.

• Mobile phone operators must provide (directly or through gateway operators) computer systems to receive payment approval requests and send them to their subscribers.

The role of card issuers

●The card issuer promotes services to cardholders.

• The retail arm of the card issuer provides a service to initialize the payer device with the details of the card held by the customer.

Alternative Model for Telephone Carriers to Card Issuers

A mobile phone operator or a separate gateway used by a mobile phone operator can become a card issuer without the need to provide a debit or credit facility. The cards issued will simply be linked to a consumer's existing debit or credit account, but will have the ability to link to accounts from multiple card issuers.

The issued card will have the authorization request routed back to the gateway, saving the card issuer new infrastructure.

In many countries, mobile phone operators also provide services and infrastructure for card processing centres.

Payer Device Software

The following functions should be added to a standard mobile phone or other pocket computer device to obtain an embodiment of the present invention. For the sake of illustration, implementation-related details are limited to the preferred embodiment of a GSM mobile phone.

payment screen

The payment screen should have a unique identifying feature that cannot be imitated by any new application software loaded onto the device. For example, "Payline" has a solid red background, and the phone's firmware prevents any application from drawing a similar red-framed banner. This measure is to prevent virus programs from learning the card PIN.

software components

The following software components are required in the Payer Device embodiment.

• Payment request messages from the network.

• Payment request message to SIM.

● Payment request data entry screen.

• Payment Request Screen Data message to SIM.

• Payment Request Response from SIM.

• Payment request response passed from SIM to network.

● Payment received response from network.

● Payment screen options menu.

● Payment options menu.

payment request message

A simple method used by GSM mobile phones is to receive payment requests as specially tagged SMS messages.

The payment request message can simply be sent directly to the SIM module.

Phone Initiated Payment

A payer device can be used to initiate a payment to a specific person or business. An easy way to choose who will make the payment is by phone number.

This method of payment is prone to error - it is possible to pay the wrong person. Therefore, it is recommended (but not required) that the paid number is an existing entry stored in the phone's phonebook.

Enter the amount as one of the payment screens

Options from payment screen

● Select an account.

● pass on.

Payment menu from idle device

● Default account.

● View transactions.

● Initiate payment.

Payment Device Types and Technologies

Adaptive systems using "pair-wise" communication

An improved local area wireless communication is proposed for local area wireless communication. Local area wireless communication, such as Bluetooth, can occur between devices that are known to each other or between devices that are not programmed to talk to each other. Preferably, communication may be limited to devices that have previously identified each other as a "pair" in the process. Each device has a unique network ID that enables pairing.

Since payer devices are used at the point of payment on many occasions and are often on an ad hoc basis, pairwise communication initially appeared to be impossible.

This problem can be overcome using short range communication for initiating transactions. For each payer device, a "phantom" point may be issued with a unique identification of the paying bluetooth device. A payer device may be paired with the payment point. However, the network identifier is simply retained and recorded on the contactless smart card, rather than providing the actual point of payment as an actual paired device. When the actual point of payment detects the smart card for the payer device, the local area wireless communication of the point of payment reads the required network identifier from the contactless card and adopts this identity. In this way, the payment point becomes a paired device of the payer's device.

new payment point

hotel wallet

The electronic payment point may be configured in the form of a restaurant wallet for presenting the consumer with an amount payable, or in the form of a payment receptacle commonly used in restaurants. Currently, consumers make payments by inserting their credit card or paying the required cash. Where card payment is offered, additional steps must be performed by restaurant staff and the customer must wait. Both staff and consumers are inconvenienced. By using a payer device and having an electronic payment point built into the payment box, consumers can pay by themselves without waiting, and can split the payment between them without requiring restaurant staff to assist such complicated operations, consumers and restaurants The staff all benefit from it.

Further details of the system according to the exemplary embodiment:

sample screen

---------------

Pay: Meter

$2.20

for 20mins

------------

Pay: Food

$50:70

15% tip

****

------------

pay:

DJs books

$29.95

**** ←------PIN ENTRY

-----------

sample message

payment request

The message will be sent from the network to the phone.

field

field Use Amount The amount to be paid - or, for unit payments - the unit price Payto text A textual representation of the business or person to be paid Payto#   Phone number of the business or person to be paid   Unit Text Up to 4 characters specifying the unit used for unit payments Minimum unit The payment must match more than one such unit Flag: allow increase Flag: allow decrease

Amount: The amount (or its relative - unit price) to be paid by the request.

Payto: A textual representation of the person or organization to be paid.

Payto#: The phone number of the person or organization to be paid.

Unit Text: Up to 3 characters, showing the unit of the item to be purchased (empty if not relevant).

Minimum unit: 0 if don't care.

Flag-vary up amount? : Whether there is a corresponding tip and whether the amount can be increased.

Flag-vary down amount? : Whether the amount can be reduced.

Payment Transaction Process

Existing Magnetic Card Transactions

steps equipment Notes Swipe card Enter the amount   Send Txn to the bank The bank starts to confirm See "Payment Confirmation Steps" below

Payment Confirmation Steps

steps equipment Notes

Features of the system according to an exemplary embodiment:

1. Use the wireless device carried by the consumer to confirm the payment.

2. Utilize a secure wireless device carried by the consumer for payment confirmation.

3. Use the secure wireless device carried by the consumer to confirm the payment of the person himself.

4. Confirmation of payment through the secure wireless device carried by the consumer using the payment options available from the device.

Contactless card activation

● Confirmation of payment using a wireless device carried by the consumer.

●Utilizes a secure wireless device carried by the consumer for payment confirmation.

●Use the secure wireless device carried by the consumer to confirm the payment of the person himself.

• Confirmation of payment through the secure wireless device carried by the consumer using the payment options available from the device.

Wireless devices carried by consumers for secure confirmation of transactions are activated by the following cards:

●Contactless smart card.

●Magnetic credit and debit cards.

●Smart card credit debit card.

● Hybrid magnetic/smart card debit/credit card.

payment feature

● PIN entry mode on phone screen.

• Protected payment commands to SIM.

● Payment screen with % and unit options.

gateway

• A communications gateway that performs any of the three tasks described in Mobile Telephony Communications Gateway.

• Adaptive system for Bluetooth or other "pair-to-pair" communication systems.

• A payment point with an interface for the payer's device.

●Mobile phones that emit a touch tone when a specific phone number is entered.

• Payment is made by mobile phone using voice communication to identify the point of payment to be paid.

Modifications and variations apparent to those skilled in the art are deemed to fall within the scope of the present invention.

Claims (150)

1, a kind of method of paying, this method may further comprise the steps:

The information that is associated with the payer is provided, and described information so that be subjected to is paid the mode that the people can visit described information and is provided,

By receiving the information relevant with described payment with payer's electronic equipment that described payer is associated, and

Use the described electronic equipment that is associated with described payer to provide the instruction of paying.

2, method according to claim 1, the wherein said information relevant with payment comprises payment information, and described method also comprises the step of the payment information that described payer's electronic equipment identification is associated with described payment.

3, method according to claim 2, the described step that wherein provides instruction comprises that described payer's electronic equipment generates message that comprises payment information and the step that this message is sent to transaction processing system.

4, according to claim 2 or the described method of claim 3, wherein said payment information comprises the price of product.

5, according to claim 2,3 or 4 described methods, wherein said payment information comprises the sign of product.

6, according to any described method in the claim 2 to 5, wherein said payment information comprises that the described payment that is subjected to pay the people identifies, thereby described transaction processing system can be paid by the account who pays the people to described.

7, according to any described method in the claim 2 to 6, wherein said payer's electronic equipment comprises display, and described method comprises that also described payer's electronic equipment is set to show the step of payment information on described display.

8, according to any described method in the above claim, the wherein said information relevant with payment comprises payment, and wherein said method comprises that also described payer's electronic equipment changes the step of described payment.

9, method according to claim 8, wherein said payer's electronic equipment comprises user input apparatus, and the described step that changes described payment comprises the step of user by described input media input payment after changing.

10, according to any described method in the above claim, the wherein said information relevant with payment comprises the product information of tabular form, described tabulation comprises at least one product identifiers, and described method comprises that described payer's electronic equipment selects the step of at least one product identifiers, and the described information that is associated with the payer comprises selected product identifiers.

11, method according to claim 10, wherein said tabulation comprises a plurality of described product identifiers, these product identifiers comprise the described menu that is subjected to pay the product that the people provides, thereby described payer's electronic equipment can be selected in the described product one or more, makes describedly to be subjected to pay a people described product can be provided.

12, according to claim 10 or the described method of claim 11, wherein the payer can obtain described tabulation by network, it is uploaded to described payer's electronic equipment.

13, method according to claim 12, wherein said network are the wide area networks such as the internet.

14, according to any described method in the above claim, wherein the described step that receives the information relevant with described payment by described payer's electronic equipment comprises the step that receives the information relevant with described payment from inactive component.

15, method according to claim 14, but the equipment that wherein said inactive component is a light to be read.

16, method according to claim 15, but the equipment that wherein said light reads is bar code.

17, according to claim 14,15 or 16 described methods, wherein the part as invoice provides described inactive component.

18, according to claim 14,15 or 16 described methods, wherein said inactive component provides with the product of sale.

19, according to any described method in the claim 14 to 18, wherein saidly comprise following instruction with the relevant information of payment, described instruction is used to utilize and should be used for controlling described payer's electronic equipment so that the instruction of carrying out described payment to be provided.

20, method according to claim 19 wherein saidly comprises positional information with the relevant information of payment, and this positional information has identified the position that payer's electronic equipment can obtain to upload to the described application of described payer's electronic equipment.

21, according to any described method in the above claim, the step that wherein receives the information relevant with described payment comprises from receiving described information with the described pair people's electronic equipment that is subjected to that be associated by pair people.

22, method according to claim 21, the wherein said information that is associated with the payer comprise makes the described payer's electronic device information that people's electronic equipment can communicate with described payer's electronic equipment that is subjected to pay.

23, method according to claim 22, wherein said payer's electronic device information is provided by the access means that is associated with described payer's electronic equipment.

24, method according to claim 23, wherein said access means is a smart card.

25, according to claim 23 or the described method of claim 24, wherein said access means and described payer's electronic equipment are integrated.

26,, wherein saidly be subjected to pay communicating by letter between people's electronic equipment and the described payer's electronic equipment and undertaken by local area wireless network according to any described method in the claim 22 to 25.

27, according to any described method in the claim 22 to 26, wherein said payer's electronic equipment is undertaken by communicating by letter between pair people's electronic equipment by telephone network with described.

28, method according to claim 27, wherein said telephone network comprises mobile telephone network.

29, according to any described method in the above claim, the described step that wherein provides the instruction of paying comprises that described payer's electronic equipment provides and comprises payment and the described instruction that is subjected to pay people's payment sign, and described instruction is sent to transaction processing system.

30, method according to claim 29 wherein directly is sent to described transaction processing system with described instruction from described payer's electronic equipment.

31, method according to claim 29 wherein is sent to described transaction processing system via being subjected to pay people's electronic equipment with described instruction.

32, according to any described method in the above claim, the described instruction that wherein is used to pay comprises that the expression that is sent to transaction processing system should carry out the affirmation of described payment.

33, method according to claim 32, this method comprise the step that is generated described affirmation by described payer's electronic equipment.

34, method according to claim 33, wherein said payer's electronic equipment comprises input media, and the described step that generation is confirmed comprises that the requirement user makes it possible to generate the step of described affirmation by described input media input.

35, method according to claim 34, the wherein said step that requires is carried out by should being used for of being provided of described payer's electronic equipment.

36, method according to claim 35 realizes in the wherein said firmware that is applied in described payer's electronic equipment.

37, according to claim 34,35 or 36 described methods, wherein said payer's electronic equipment comprises display, and the described step that requires requires described user to approve the information relevant with described payment that appears on the described display by described input media.

38, according to any described method in the claim 32 to 37, wherein said affirmation comprises coded message.

39, according to the described method of claim 38, wherein said coded message is a digital signature.

40, according to any described method in the above claim, the wherein said information that is associated with the payer comprises described payer's account's account identifier.

41, according to the described method of claim 40, wherein said account identifier is by providing the described payer such as the card of credit card to provide.

42, according to the described method of claim 40, wherein said account identifier is a part of account 10, and wherein transaction processing system stores other parts of account 10.

43, according to the described method of claim 42, wherein said part account 10 is provided with encrypted form by described payer's electronic equipment.

44, according to any described method in the above claim, the wherein said information relevant with payment comprises one or more application, described one or more application comprises instruction, and described instruction is used to control described payer's electronic equipment provides the instruction of carrying out described payment.

45, according to the described method of claim 44, described method also comprises the step that described one or more application is uploaded to described payer's electronic equipment from network.

46, according to any described method in the above claim, the wherein said information that is associated with the payer is the affirmation that payment has been taken place.

47, according to any described method in the above claim, the wherein said information that is associated with the payer comprises described payer's sign.

48, according to any described method in the above claim, the described step that wherein provides the instruction of carrying out described payment comprises that described payer's electronic equipment carried out pre-approval to described payment by the pre-approval instruction is provided to transaction processing system before described payment transaction takes place.

49, according to any described method in the above claim, wherein said payer's electronic equipment is a portable set.

50, according to the described method of claim 49, wherein said portable set is a palmtop computer.

51, according to claim 49 or 50 described methods, wherein said portable set is a mobile phone.

52, a kind of method of handling payment transaction, this method may further comprise the steps: transaction processing system receives the instruction of paying from the payer's electronic equipment that is associated with the payer; Described transaction processing system authority to pay; And described transaction processing system provides the payment affirmation that account transfer has been authorized to.

53, according to the described method of claim 52, the described step that wherein receives instruction comprises the step that receives message from payer's electronic equipment, and described message comprises payment information.

54, according to the described method of claim 53, wherein said payment information comprises that payment and the described payment that is subjected to pay the people identify.

55,, wherein provide the described step of payment affirmation to comprise that described transaction processing system is sent to described payment affirmation the step that is subjected to pay people's electronic equipment according to claim 52,53 or 54 described methods.

56,, wherein provide the described step of payment affirmation to comprise that described transaction processing system is sent to described payment affirmation the step of payer's electronic equipment according to any described method in the claim 52 to 55.

57, according to the described method of claim 56, wherein said payer's electronic equipment comprises display, and provides the described step of payment affirmation to comprise described affirmation to be provided, to make it to appear on the described display of described payer's electronic equipment.

58, according to the described method of claim 57, the described payment affirmation that wherein appears on the described display is a machine-readable form, and can read by being subjected to pay people's electronic equipment.

59, according to the described method of claim 58, wherein said machine-readable form is a bar code.

60, according to any described method in the claim 52 to 59, this method also comprises the step that receives product information from described payer's electronic equipment, and described product information has identified at least one product that is subjected to pay the people that will be paid.

61,,, this method is subjected to pay that people's electronic equipment is described is subjected to pay the step that the people can offer described product described payer thereby comprising that described transaction processing system is sent to described product information according to the described method of claim 60.

62, according to claim 60 or the described method of claim 61, this method comprises the step that the product tabulation is uploaded to described payer's electronic equipment, and described product tabulation comprises can be by at least one product that is subjected to pay the people of described payer's electronic equipment selection.

63, according to the described method of claim 62, this method comprises the database that the product tabulation is provided so that upload to the step of payer's electronic equipment, and each product tabulation all comprises can be by corresponding at least one product that is subjected to pay the people of payer's electronic equipment selection.

64, according to any described method in the claim 52 to 63, this method comprises the step that application is uploaded to described payer's electronic equipment, described application comprises instruction, and described instruction is used to control described payer's electronic equipment provides the instruction of carrying out described payment.

65, according to the described method of claim 64, this method comprises provides the database that comprises application so that upload to the step of described payer's electronic equipment, described application has instruction, and described instruction is used to control payer's electronic equipment provides the instruction of paying.

66, according to any described method in the claim 52 to 65, the described instruction that wherein is used to pay comprises the affirmation that should carry out described payment from the expression of described payer's electronic equipment.

67, according to the described method of claim 66, the wherein said coded message that is confirmed to be.

68, according to the described method of claim 67, wherein said coded message is a digital signature.

69, according to claim 66,67 or 68 described methods, wherein said payer's electronic equipment generates described affirmation needs the user to start the input media of described payer's electronic equipment.

70, according to any described method in the claim 66 to 69, this method comprises that described transaction processing system sends the step of the request of confirming to described payer's electronic equipment.

71, according to any described method in the claim 52 to 70, the described instruction that wherein is used to pay comprises payer's account information.

72, according to the described method of claim 71, wherein said payer's account information comprises the part of account identifier, and wherein said transaction processing system stores the remainder of this account identifier, thereby can discern described payer account when described transaction processing system when described payer's electronic equipment receives described part.

73, according to any described method in the claim 52 to 72, the described instruction that wherein is used to pay comprises the pre-approval instruction that is used for the payment that will take place is subsequently carried out pre-approval, and described method comprises that described transaction processing system stores the step of described pre-approval instruction.

74, according to any described method in the claim 52 to 73, the described instruction that wherein is used to pay is from from the transmission of payer's electronic equipment and directly receive.

75, according to any described method in the claim 52 to 73, the described instruction that wherein is used to pay is via being subjected to pay people's electronic equipment from being subjected to pay the transmission of people's electronic equipment and receiving indirectly to described by described payer's electronic equipment.

76, according to any described method in the claim 52 to 74, wherein said payer's electronic equipment is a portable set.

77, according to the described method of claim 76, wherein said portable set is a palmtop computer.

78, according to claim 76 or 77 described methods, wherein said portable set is a mobile phone.

79, a kind of being convenient to from the payer to being subjected to pay the equipment that the people pays transaction, this equipment comprises the payer's electronic equipment that is associated with described payer, and described payer's electronic equipment comprises the payment instruction issue device that is used to receive the payment information receiving trap of the information relevant with described payment and is used to provide the instruction of carrying out described payment.

80, according to the described equipment of claim 79, wherein said payer's electronic equipment comprises the payment processes device that is used to discern payment information.

81,0 described equipment according to Claim 8, wherein said payer's electronic equipment comprise the message issue device that is used to generate the message that comprises payment information and are used for described message is sent to the dispensing device of transaction processing system.

82,1 described equipment according to Claim 8, wherein said payment information comprises payment.

83, according to Claim 81 or the described equipment of claim 82, wherein said payment information comprises the sign of product.

84,1,82 or 83 described equipment according to Claim 8, wherein said payment information comprise that the described payment that is subjected to pay the people identifies, and handles the payment that is subjected to pay people account for described thereby be convenient to described transaction processing system.

85, according to any described equipment in the claim 79 to 84, wherein said payer's electronic equipment comprises display, and is used to show payment information.

86, according to any described equipment in the claim 79 to 85, the wherein said information relevant with payment comprises payment, and wherein said payer's electronic equipment comprises the input media that makes described user can change described payment.

87, according to any described equipment in the claim 79 to 86, the wherein said information relevant with payment comprises product information, described product information comprises at least one product identifiers, and described payer's electronic equipment comprises and is used to select at least one product identifiers to be sent to the selecting arrangement that is subjected to pay the people.

88,7 described equipment according to Claim 8, wherein said product information is a tabular form, described tabulation comprises a plurality of product identifiers that described payer's electronic equipment can therefrom be selected.

89, according to Claim 87 or the described equipment of claim 88, wherein said payer's electronic equipment is used for uploading described product information from the database that can obtain described product information.

90, according to any described equipment in the claim 79 to 89, wherein said payer's electronic equipment comprises the reading device that is used for reading from inactive component the information relevant with described payment.

91, according to the described equipment of claim 90, but the equipment that wherein said inactive component is a light to be read, and described reading device comprises optical pickup.

92, according to the described equipment of claim 91, but the equipment that wherein said light reads is bar code.

93, according to claim 91 or the described equipment of claim 92, wherein said reading device comprises camera.

94, according to any described equipment in the claim 91 to 93, wherein said reading device is used to discern the inactive component of the information that provides relevant with described payment.

95, according to any described equipment in the claim 79 to 94, described payer's electronic equipment also comprises the communicator that is used for and communicated by pair people's electronic equipment.

96, according to the described equipment of claim 95, wherein said communicator comprises and makes it possible to the device that communicates by local area wireless network.

97, according to claim 95 or the described equipment of claim 96, described payer's electronic equipment comprises and is used for being subjected to pay to described that people's electronic equipment provides information so that can be subjected to pay the access means that communicates between people's electronic equipment and the described payer's electronic equipment described.

98, according to the described equipment of claim 97, wherein said access means is a smart card.

99, according to claim 97 or the described equipment of claim 98, wherein said access means and described payer's electronic equipment are integrated.

100, according to any described equipment in the claim 95 to 99, wherein said payer's electronic equipment comprises the dispensing device that is used for sending to transaction processing system the instruction of carrying out described payment, and described dispensing device is used for sending described instruction via the described pair people's electronic equipment that is subjected to.

101, according to any described equipment in the claim 79 to 100, described payer's electronic equipment comprises remote transmitting device, and the instruction that this remote transmitting device is used for carrying out described payment is sent to transaction processing system.

102, according to the described equipment of claim 101, wherein said remote transmitting device is the transmitter that is used for sending via mobile telephone network signal.

103, according to any described equipment in the claim 79 to 102, the instruction that wherein is used to carry out described payment comprises that the expression that sends to transaction processing system should carry out the affirmation of described payment, and described payment instruction issue device comprises and is used to generate described affirmation apparatus for converting shy with strangers really.

104, according to the described equipment of claim 103, wherein said payer's electronic equipment comprises input media, and will make described affirmation generating apparatus generate user's input that described affirmation need be passed through described input media.

105, according to the described equipment of claim 104, wherein said affirmation generating apparatus is partly or wholly realized by firmware.

106, according to claim 104 or the described equipment of claim 105, wherein said payer's electronic equipment comprises display, and described affirmation generating apparatus requires described user to approve the information relevant with described payment that appears on the described display by described input media, so that be that it generates affirmation.

107, according to claim 104,105 or 106 described equipment, wherein said affirmation generating apparatus is used to generate the affirmation of coded message form.

108, according to the described equipment of claim 107, wherein said coded message is a digital signature.

109, according to any described equipment in the claim 79 to 108, described payer's electronic equipment comprises the memory storage that is used to store at least one application, described application comprises instruction, and described instruction is used to control described payment instruction issue device and provides the instruction of carrying out described payment.

110, according to the described equipment of claim 109, described payer's electronic equipment is used for uploading described at least one application from database.

111, according to any described equipment in the claim 74 to 110, the instruction that wherein is used to carry out described payment comprises the account's who has identified described payer account identifier.

112, according to the described equipment of claim 111, wherein said account identifier comprises the part of account number, and wherein transaction processing system stores other parts of account.

113, according to any described equipment in the claim 79 to 112, the instruction that wherein is used to carry out described payment comprises pre-approval, and this pre-approval is used to authorize the payment for follow-up payment transaction.

114, a kind of transaction processing system that is used to handle payment transaction, this system comprises: the payment instruction receiving trap is used for being used for from described payer to being subjected to pay the instruction that the people pays from the payer's electronic equipment reception that is associated with the payer; And the payment processes device, be used to authorize from payer account to the funds transfer that is subjected to pay people account.

115, according to the described transaction processing system of claim 114, this transaction processing system also comprises and is used to confirm to pay the payment affirmation device that has taken place.

116, according to the described system of claim 115, wherein said payment affirmation device is used for payment affirmation is sent to described and is subjected to pay that the people is associated is subjected to pay people's electronic equipment.

117, according to claim 115 or the described system of claim 116, wherein said payment affirmation device is used for payment affirmation is sent to described payer's electronic equipment.

118, according to the described system of claim 117, wherein said payer's electronic equipment comprises display, and described payment affirmation device provides described payment affirmation, makes it to appear on the described display of described payer's electronic equipment.

119, according to the described system of claim 118, the described payment affirmation that wherein appears on the described display is a machine-readable form, and can read by being subjected to pay people's electronic equipment.

120, according to the described system of claim 119, wherein said machine-readable form is a bar code.

121, according to any described system in the claim 114 to 120, this system also comprises the product information receiving trap that is used for receiving from described payer's electronic equipment product information, and described product information has identified at least one product that is subjected to pay the people that will be paid.

122, according to the described system of claim 121, this system also comprises being used for described product information is sent to and is subjected to pay people's electronic equipment, thereby describedly is subjected to pay the product information dispensing device that the people can offer described product described payer.

123, according to claim 121 or 122 described systems, this system also comprises the database of product tabulation, and make it possible to the product tabulation is uploaded to payer's electronic equipment, each product tabulation all comprises can be by corresponding at least one product that is subjected to pay the people of payer's electronic equipment selection.

124, according to any described system in the claim 114 to 123, this system also comprises database, described database comprises the one or more application that are used to upload to described payer's electronic equipment, described one or more application comprises instruction, and described instruction is used to control described payer's electronic equipment provides the instruction of paying.

125, according to any described system in the claim 114 to 124, the instruction that wherein is used to carry out described payment comprises the affirmation that should carry out described payment from the expression of described payer's electronic equipment.

126, according to the described system of claim 125, the wherein said coding form of confirming as, and described system comprises and is used for device that described instruction is decoded.

127, according to the described system of claim 126, wherein said coding form is a digital signature.

128, according to any described system in the claim 114 to 127, the instruction that wherein is used to carry out described payment comprises payer's account information, this payer's account information comprises the part of account identifier, and described system also comprises the database of the remainder that stores described account identifier, thereby can discern described payer account.

129, according to any described system in the claim 114 to 128, this system also comprises the pre-approval database that stores the pre-approval instruction, and described pre-approval instruction is used for pre-approval is carried out in the payment that takes place subsequently.

130, a kind of equipment of being convenient to handle transaction, this equipment comprise and are used for and are subjected to pay people's electronic equipment according to what any described transaction processing system of claim 114 to 129 communicated.

131, according to the described equipment of claim 130, this equipment is used to receive the product information that has identified at least one product.

132, according to the described equipment of claim 131, this equipment comprises the device that is used to print described product tabulation.

133, a kind of system, this system comprises: according to any described equipment in the claim 79 to 99; According to any described system in the claim 115 to 129; And according to any described equipment in the claim 130 to 132.

134, a kind of database, this database comprise the available a plurality of product tabulations of payer's electronic equipment, thereby described payer's electronic equipment can be selected one or more product from described product tabulation, send to be subjected to pay the people, to satisfy product demand.

135, a kind of inactive component, this inactive component can be read by payer's electronic equipment, so that the transaction of paying.

136, according to the described equipment of claim 135, wherein said inactive component is a bar code.

137, according to claim 135 or the described equipment of claim 136, wherein said inactive component comprises makes described payer's electronic equipment can handle the payment information of payment.

138, according to any described equipment in the claim 135 to 137, wherein said inactive component comprises the product tabulation, and this product has been listed at least one product of selecting for described payer's electronic equipment.

139, according to claim 135 or 136 described equipment, wherein said inactive component is associated with product, and provides following information, this information to make payer's electronic equipment can make the transaction of the described product of payment convenient more.

140, according to the described equipment of claim 139, wherein said inactive component sticks on the described product or in the packing of product.

141, according to any described equipment in the claim 135 to 138, wherein said inactive component is the part of the menu in restaurant or the restaurant.

142, according to any described equipment in the claim 135 to 140, wherein said inactive component comprises the information of using that identified, and described payer's electronic equipment utilizes the described payment transaction facility more that should be used for making.

143, a kind of inactive component, this inactive component comprise the information that has identified application, and electronic equipment utilizes the described information that is associated with described inactive component that should be used for handling.

144, according to the described equipment of claim 143, wherein said inactive component is a bar code.

145, a kind of computer program, this computer program comprise and are used for controlling computing equipment to implement the instruction according to any described method of claim 1 to 51.

146, a kind of computer-readable medium that provides according to the described computer program of claim 145.

147, a kind of computer program, this computer program comprise and are used for controlling computing equipment to implement the instruction according to any described method of claim 52 to 78.

148, a kind of computer-readable medium that provides according to the described computer program of claim 147.

149, a kind of method that starts software application, this method may further comprise the steps: the inactive component that utilizes the information that comprises the position that has identified software application; Described information is uploaded to subscriber equipment; And utilize described subscriber equipment to obtain described application from remote location.

150, a kind of method of organizing formation, this method may further comprise the steps: provide information to user's mobile phone, this information representation the position of user in described formation; And along with described user moving of position and upgrade described information in described formation.

Images