KR20120069673A - Peer-to-peer financial transaction devices and methods - Google Patents

Abstract

Various techniques are provided for conducting peer to peer financial transactions using one or more electronic devices 10, 92. In one embodiment, the payment request is sent from the first device 10 to the second device 92 using the near field communication (NFC) interface 46. In response to the request, the second device 92 sends the payment information to the first device. The first device selects the crediting account and uses one of the external communication servers 100 configured to process and determine the payment information and the selected crediting account using the appropriate communication protocol, whether the payment can be authorized. Can transmit If payment is authorized, the payment may be credited to the selected crediting account. In a further embodiment, the device 10 may comprise a camera 48 configured to acquire an image of the payment means. The device 10 may further include an application for extracting payment information from the acquired image.

Description

Peer-to-peer FINANCIAL TRANSACTION DEVICES AND METHODS

FIELD OF THE INVENTION The present invention relates generally to peer to peer transactions, and more particularly to various systems, methods and electronic devices configured to initiate and process such transactions.

This section is intended to introduce the reader to various technical aspects that may relate to various aspects of the present techniques described and / or claimed below. This description is believed to be helpful in providing the reader with background information to aid in a better understanding of the various aspects of the present invention. Accordingly, the descriptions should be read with this in mind, and should be understood to be non-approval of the prior art.

Many means of payment currently exist and can be used to conduct financial transactions between two or more parties. For example, payment may be made using a credit card, debit card, check, electronic check and cash. In recent years, the growth of e-commerce is at least partly due to the popularization of credit cards, debit cards and other non-monetary based payment means. Moreover, it may sometimes be more convenient to impose a payment on the consumer's credit card because the consumer may not always have the correct amount of cash in hand to pay the outstanding bill or bill to the seller or retailer.

As we move into a more liquid and fast-paced society, the use of cash or money is increasingly being replaced by electronic transactions using credit cards, debit cards and the like. Thus, it is not uncommon for consumers to simultaneously have multiple non-monetary accounts (multiple credit cards or debit cards corresponding to each banking provider), each of which is dedicated to a particular type of purchase or financial transaction. Can be converted. For example, consumers may only use credit card accounts that can be dedicated for gas or car purchases, especially credit card accounts for travel-related purchases, general-purpose credit card accounts for various purchases, as well as certain retailers or sellers. One or more loyalty credit card accounts can be owned at the same time. In addition, a consumer may simultaneously own one or more debit card accounts associated with each banking provider.

As can be seen, the consumer can make payments and participate in financial transactions using any of the accounts described above through a payment means that represents an account, such as a credit card. However, as the number of payment accounts owned by the consumer increases, carrying such a large number of credit / debit cards can become increasingly inconvenient. Moreover, payments made using the aforementioned accounts can be easily compatible with retailer and seller businesses, including those established online on the Internet, while payments made from such accounts are always made by other consumers or "peers". It may not be easily accepted.

Certain aspects of the embodiments disclosed herein by way of example are summarized below. It is to be understood that these aspects are merely described to provide the reader with a summary of the various techniques disclosed and / or claimed herein, and are not intended to limit the scope of any technology disclosed and / or claimed herein. . Indeed, any technique disclosed and / or claimed herein may include various aspects that may not be described below.

The present invention generally relates to various techniques for performing peer to peer transactions using a portable device. According to one embodiment disclosed, a portable electronic device may be configured to store information representing one or more accounts owned by a user. For example, the information stored may represent one or more credit card accounts owned by the user. As used herein, the term "credit card" should be understood to include any type of card, including those according to the ISO 7810 standard, such as credit cards, debit cards, charge cards, gift cards, and the like. In one embodiment, the credit card may store the user's account information using a magnetic stripe encoded on the card (eg, the ISO 7813 standard). In other embodiments, as described below, the credit card may include a storage device configured to store user account information (eg, in addition to the magnetic strip described above). The portable device may be configured to store information about one or more bank accounts owned by the user.

The portable device may have one or more communication interfaces configured to transmit or transfer information stored on the device. For example, based on inputs or instructions received from the user, the portable device sends payment information corresponding to the credit account stored on the device (eg as payer) to an external device (eg as payee). It may be configured to initiate a payment by sending. In one embodiment, the receiving device may be a similar portable electronic device. In addition, the device may be configured to receive payment information from an external device and initiate a transaction request to process the received payment information, such that the corresponding payment is on behalf of an appropriate account (eg, a bank account) stored on the device. Is written. For example, a transaction request may include communication with one or more external servers that are configured to provide authorization for the requested transaction.

The electronic device may further include a plurality of communication interfaces that may include a near field communication (NFC) interface as well as one or more input devices such as a camera device. According to an embodiment, the device may initiate transmission and reception of payment information with an external device using the NFC interface through an NFC handshake operation. In addition, the electronic device may send and receive payment information by establishing a communication link with an external device using a device identification networking protocol.

In a further embodiment, the electronic device may include an image processing application for processing the image to extract information. For example, using the camera input device described above, an image of a payer's payment means, which may include a credit card, a check, or the like, may be acquired. The acquired image can be processed to extract and determine information about the payment account represented by the payment means. Accordingly, the electronic device may transmit a request including the extracted payment account information to one or more financial services for permission of payment using the extracted information. Thus, the presently described techniques, which may include methods, systems, and apparatus, provide a convenient method and system for conducting peer to peer financial transactions, as well as providing a single transaction point for sending and receiving payments, allowing a user to The need to carry each physical payment means (eg, multiple credit / debit cards) can be reduced or eliminated.

The presently described techniques may provide one or more systems for performing a group transaction comprising a plurality of group transaction members. In one embodiment, group transaction members may include an initiator that manipulates an electronic device. The initiator can initiate a major transaction to pay the full amount of the group invoice including the amounts that each of the group transaction members must pay. The initiator can then perform one or more secondary transactions with each of the remaining group transaction members to collect each amount to be paid. As can be appreciated, the collection of outstanding payments may simply be performed using one or more of the communication or image processing techniques described above. Further, in further embodiments, the initiator may be the issuer of the invoice or directly collect payments corresponding to the amounts to be paid by the group transaction members (eg, without the main transaction described above).

The electronic device may further comprise an application, such as a computer program stored on one or more machine readable media, adapted to provide the functions described above. In one embodiment, the device may include a display, and the application may provide a graphical user interface that can be viewed on the display. Through the graphical interface, a user can operate the device to perform one or more of the above-described functions, which are described in more detail below.

Various embodiments of the foregoing features may exist in connection with various aspects of the present invention. Additional features may also be included in these various aspects. These improvements and additional features may be present individually or in any combination. For example, various features described below in connection with one or more of the described embodiments can be included alone or in any combination within any of the foregoing aspects of the invention. It is also to be understood that the foregoing summary is not intended to limit the claimed invention, but to make certain aspects and situations of embodiments of the present invention familiar to the reader.

Various techniques are provided for conducting peer to peer financial transactions using one or more electronic devices 10, 92. In one embodiment, the payment request is sent from the first device 10 to the second device 92 using the near field communication (NFC) interface 46. In response to the request, the second device 92 sends the payment information to the first device. The first device selects the crediting account and uses one of the external communication servers 100 configured to process and determine the payment information and the selected crediting account using the appropriate communication protocol, whether the payment can be authorized. Can transmit If payment is authorized, the payment may be credited to the selected crediting account. In a further embodiment, the device 10 may comprise a camera 48 configured to acquire an image of the payment means. The device 10 may further include an application for extracting payment information from the acquired image.

These and other features, aspects, and advantages of the present invention will be better understood when the following detailed description of certain exemplary implementations is read in connection with the accompanying drawings, in which like characters indicate like elements throughout. . In the drawing:
1 is a front view of an electronic device according to an embodiment.
FIG. 2 is a rear view of the electronic device shown in FIG. 1.
3 is a simple block diagram illustrating components that may be used in the electronic device shown in FIG. 1.
4 is a block diagram illustrating processing of a peer-to-peer transaction between the device of FIG. 1 and an external device in communication with the device of FIG. 1, in accordance with an embodiment, wherein the device of FIG. 1 serves as a recipient device, and the external device; Serves as a payer device.
5A is a diagram illustrating a plurality of screens that may be displayed on the device of FIG. 1 illustrating a method for storing credit card information in the device of FIG. 1.
FIG. 5B is a diagram illustrating a plurality of screens that can be displayed on the apparatus of FIG. 1 showing a method for verifying credit card information inputted in FIG. 5A.
FIG. 6A is a diagram illustrating a plurality of screens that may be displayed on the device of FIG. 1 illustrating a method for storing banking information within the device of FIG. 1.
FIG. 6B is a diagram illustrating a plurality of screens that may be displayed on the apparatus of FIG. 1 illustrating a method for verifying banking information stored in FIG. 6A.
FIG. 7 is a diagram illustrating a plurality of screens that may be displayed on the device of FIG. 1 illustrating a method for configuring a default payment account on the device of FIG. 1.
8 is a diagram illustrating a plurality of screens that may be displayed on the device of FIG. 1 illustrating a method for configuring a default crediting account on the device of FIG. 1.
9 is a diagram illustrating a plurality of screens that may be displayed on the apparatus of FIG. 1 illustrating a method for configuring an authorization PIN code, according to one embodiment.
10A and 10B are diagrams illustrating a plurality of screens that may be displayed on the device of FIG. 1 illustrating a method for locking and unlocking a transactional application stored on the device of FIG. 1, according to one embodiment.
11A is a flow diagram illustrating a method of operating the recipient device of FIG. 4 to initiate a transaction, according to one embodiment.
FIG. 11B is a flow diagram illustrating a method of manipulating the device of payment of FIG. 4 to respond to a transaction initiated by the method of FIG. 11A, according to one embodiment.
12A-12C are schematic diagrams of systems that are adapted to perform various types of transactions that may be performed between the payee and payer devices of FIG. 4 in accordance with aspects of the present technology.
13 is a schematic diagram illustrating a communication process that may be performed between the payee and payer devices of FIG. 4 during the transactions shown in FIGS. 12A-12C.
14A is a diagram illustrating a plurality of screens that may be displayed on the device of FIG. 1 illustrating a method for initiating a payment request to be sent to a payer device, according to one embodiment.
14B is a diagram illustrating a plurality of screens illustrating the transfer of the payment request of FIG. 14A from the payee device to the payer device using the established communication channel.
14C and 14D are diagrams showing the setting of the communication channel of FIG. 14B.
14E-14G are diagrams illustrating a plurality of screens that may be displayed on the payer device showing various methods for selecting a payment account in response to the payment request of FIG. 14A.
FIG. 14H is a diagram illustrating a plurality of screens that may be displayed on the payer device to initiate transfer of the payment account information selected in FIG. 14E to the payee device.
14I is a diagram illustrating a plurality of screens illustrating the transfer of payment account information selected in FIG. 14E from the payer device using the established communication channel of FIG. 14B to the payee device.
FIG. 14J is a diagram illustrating a plurality of screens that may be displayed on the recipient device indicating a method for selecting a crediting account and completing the transaction originally initiated in FIG. 14A.
15A is a diagram illustrating in more detail one or more steps of the method shown in FIG. 11A in accordance with the transactions shown in FIGS. 12A-12C.
15B is a diagram illustrating certain steps of the method shown in FIG. 11B in accordance with the transactions shown in FIGS. 12A-12C.
FIG. 16A is a flow diagram illustrating a method in which the payer device of FIG. 4 is manipulated to initiate a transaction, according to one embodiment. FIG.
FIG. 16B is a flow diagram illustrating a method in which the recipient device of FIG. 4 is manipulated to respond to a transaction initiated in FIG. 16A, according to one embodiment.
17A is a diagram illustrating a plurality of screens that may be displayed on a device that is a payment representing a method for initiating a transaction in accordance with the methods described in FIGS. 16A-16B according to one embodiment.
FIG. 17B is a diagram illustrating a plurality of screens that may be displayed on the recipient device indicating a method for selecting a crediting account and completing the transaction initiated by FIG. 17A.
18 is a schematic diagram of a system in which a selected payment account is adapted to perform a transaction that includes a non-cash account.
19A and 19B are diagrams illustrating a plurality of screens that may be displayed on a payer device illustrating a method for selecting the non-cash account of FIG. 18 as a payment account and initiating a transaction, according to one embodiment.
19C is a diagram illustrating a plurality of screens that may be displayed on a payee device that illustrates a method for selecting a non-cash crediting account according to one embodiment.
FIG. 19D is a diagram illustrating a plurality of screens that may be displayed on the recipient device indicating a method for selecting a crediting account and completing the transaction disclosed in FIG. 19A.
20 is a schematic diagram of a system in which a selected payment account is adapted to perform a transaction provided by a smart card.
21A is a diagram illustrating in more detail one or more steps of the method shown in FIG. 11A in accordance with the transaction shown in FIG. 20.
FIG. 21B is a diagram illustrating certain steps of the method shown in FIG. 11B in accordance with the transaction shown in FIG. 20.
22A illustrates a plurality of screens that may be displayed on the payee device of FIG. 18 illustrating a method for receiving payment information stored on the smart card of FIG. 18, according to one embodiment.
22B is a diagram illustrating the establishment of a communication channel between the recipient device and smart card of FIG. 18 for the transmission of payment information in FIG. 22A.
FIG. 22C is a diagram illustrating a plurality of screens that may be displayed on the recipient device indicating a method for selecting a crediting account and completing the transaction disclosed in FIG. 22A.
23 is a schematic diagram of a system in which a selected payment account is adapted to perform a transaction provided using a magnetic credit card provided by a payer.
24 is a schematic diagram of a system in which a selected payment account is adapted to perform a transaction provided using a check provided by a payer.
25A is a diagram illustrating one or more steps of the method shown in FIG. 11A in more detail in accordance with the transactions shown in FIGS. 23 and 24.
FIG. 25B is a diagram illustrating in more detail one or more steps of the method shown in FIG. 11B in accordance with the transactions shown in FIGS. 23 and 24.
FIG. 26A is a diagram illustrating a plurality of screens that may be displayed on a recipient device, illustrating a method for obtaining an image of the credit card of FIG. 23, according to one embodiment. FIG.
FIG. 26B is a diagram illustrating a technique for processing the image acquired in FIG. 26A for extraction of payment information. FIG.
FIG. 26C is a diagram showing a plurality of screens that can be displayed on the recipient device, which shows a method for editing the information acquired by the image processing step in FIG. 26B.
FIG. 26D is a diagram illustrating a plurality of screens that may be displayed on the recipient device indicating a method for selecting a crediting account and completing the transaction disclosed in FIG. 22A.
27A and 27B are diagrams illustrating a plurality of screens that may be displayed on a payee device that illustrates a method for obtaining an image of a check in FIG. 24, according to one embodiment.
FIG. 27C is a diagram illustrating a technique for processing the image acquired in FIG. 27B for extraction of payment information. FIG.
FIG. 27D is a diagram illustrating a plurality of screens that may be displayed on the recipient device indicating a method for selecting a crediting account and completing the transaction disclosed in FIG. 27A.
FIG. 27E is a diagram illustrating a plurality of screens that may be displayed on the payee device, which illustrates a method for obtaining an image of a check in FIG. 24, according to a further embodiment. FIG.
FIG. 27F is a diagram illustrating a technique for processing the image acquired in FIG. 27E for extraction of payment information. FIG.
FIG. 27G is a diagram illustrating a plurality of screens that may be displayed on the recipient device showing a method for selecting a crediting account and completing the transaction disclosed in FIG. 27A based on the image acquired in FIG. 27E.
28 is a schematic diagram of a system adapted to perform a group transaction comprising a plurality of payers, according to one embodiment.
FIG. 29 is a flow diagram illustrating a method for performing a group transaction of FIG. 28.
30A is a diagram illustrating a plurality of screens that may be displayed on the initiator device showing a method for initiating a major portion of the group transaction of FIG. 28.
30B and 30C are diagrams illustrating a plurality of screens that may be displayed on the initiator device showing a method for completing a main transaction disclosed in FIG. 30A and further initiating an auxiliary portion of a group transaction.
FIG. 30D is a diagram illustrating a plurality of screens that may be displayed on a device that is a payment representing a method for joining the group transaction of FIG. 28.
FIG. 30E is a diagram illustrating a plurality of screens that may be displayed on the initiator device showing a technique for adding additional transaction members to the group transaction shown in FIG. 28.
30F is a diagram illustrating a plurality of screens that may be displayed on the initiator device showing a technique for assigning invoice items to a group transaction member.
30G is a diagram illustrating a plurality of screens that may be displayed on an initiator device that represents a technique for assigning invoice items to two or more group transaction members.
30H is a diagram illustrating a plurality of screens that may be displayed on an initiator device that illustrates a method for viewing a partial invoice, according to one embodiment.
30I-30L are diagrams illustrating a plurality of screens that may be displayed on an initiator device showing methods for collecting payments from each of group transaction members according to one embodiment.
31 is a schematic diagram of a system adapted to perform a transaction including multiple payers according to one embodiment.
32A and 32B illustrate a plurality of screens that may be displayed on a merchant device showing methods for initiating the group transaction of FIG. 31.
32C is a diagram illustrating a plurality of screens that may be displayed on a merchant device showing a technique for assigning invoice items to a group transaction member.
32D is a diagram illustrating a plurality of screens that may be displayed on a merchant device showing methods for collecting payments from each of the group transaction members and completing the group transaction of FIG. 31.

One or more specific embodiments of the present invention are described below. These described embodiments merely illustrate the presently disclosed techniques. In addition, not all features of an actual implementation may be described herein in order to provide a concise description of these example implementations. In the development of any such actual implementation, such as in any engineering or design project, various implementation specific decisions must be made to achieve the specific goals of the developer, such as following system-specific and business-specific restrictions that may vary from implementation to implementation. You should know that Moreover, such development efforts can be complex and time consuming, but will be routine tasks of design, manufacture and fabrication for those skilled in the art having the benefit of this disclosure.

The present invention relates to various techniques for conducting peer to peer financial transactions using a handheld portable electronic device. A handheld electronic device, in accordance with aspects of the present invention, performs peer-to-peer transactions that include storing information representing payment accounts and crediting accounts of a user, obtaining and sending payment information, and obtaining a payment authorization. You can integrate multiple functions. One or more input devices may be provided, such as a camera or near field communication (NFC) device, for obtaining payment information. For example, an NFC device may be used to initiate an NFC connection with an external device to obtain or transmit payment information data. In addition, the camera apparatus may be used in conjunction with an image processing application to extract payment information data from an image of the payment means provided by the payer. The electronic device may be configured to communicate with one or more external servers to obtain permission for payment via a selected communication channel, such as a wide area network (WAN), a local area network (LAN), a personal area network (PAN), or a local area communication channel. . Accordingly, various functions provided by an electronic device according to embodiments of the present invention provide a convenient technique for performing peer-to-peer financial transactions, including group transactions, including three or more members, as described in more detail below. Can provide. Indeed, as described in more detail below, certain aspects of the techniques described below may be particularly useful for person-to-person transactions performed between individuals.

Referring first to FIG. 1 of the drawings, there is shown an electronic device that may include one or more transactional applications for providing the transaction related techniques and capabilities described briefly above, and generally referred to by reference numeral 10. According to the illustrated embodiment, the electronic device 10 may be a handheld device that includes the functions of one or more portable devices such as a media player, a cellular phone, a personal data organizer, and the like. Thus, according to the functions provided by the electronic device 10, the user can move freely with the device 10, listening to music, playing games, recording videos, taking pictures, and making phone calls. have. In addition, the electronic device 10 may allow a user to connect and communicate over the Internet or through other networks, such as a local or wide area network. For example, the electronic device 10 may allow a user to communicate using email, text messaging, instant messaging, or other forms of electronic communication. The electronic device 10 may also communicate with other devices using short range access protocols such as Bluetooth and near field communication (NFC). By way of example only, the electronic device 10 may be a model of an iPhone® available from Apple Inc. of Cupertino, California.

As shown in the illustrated embodiment, the device 10 may be enclosed in an enclosure or housing 12. Enclosure 12 may be used to protect internal components of device 10 from physical damage. In addition, the enclosure 12 may allow the device 10 and its internal components to be shielded from electromagnetic interference. As will be appreciated by those skilled in the art, the enclosure 12 may be formed and / or constructed from any suitable material, such as plastic, metal or synthetic material, and electromagnetic radiation of a predetermined frequency may be applied to facilitate wireless communication. 10) may be passed through a wireless communication circuit.

Enclosure 12 may further provide access to various user input structures shown in FIG. 1 with reference numerals 14, 16, 18, 20, and 22. Through such user input structures, a user may interface with device 10, and each user input structure 14, 16, 18, 20, 22 may be configured to control one or more device functions when pressed or actuated. Can be. For example, the input structure 14 may include a button that causes the home screen or menu to be displayed on the device when pressed or actuated. Input structure 16 may include a button for toggling device 10 between one or more modes of operation, such as a sleep mode, wake mode, or power on / off mode. The input structure 18 may include a dual position sliding structure capable of muting or silencing the ringer in embodiments where the device 10 includes a cell phone application. In addition, the input structures 20, 22 may include buttons for increasing or decreasing the volume output of the device 10. The illustrated input structures 14, 16, 18, 20, 22 are exemplary only, and the electronic device 10 may include buttons, switches, control pads, keys, knobs, scroll wheels, and the like according to specific implementation requirements. It should be understood that it can include any number of user input structures that exist in various forms.

The electronic device 10 may further include a display 24 configured to display various images generated by the device 10. For example, display 24 may be configured to display photos, movies, album art, and / or data, particularly text documents, spreadsheets, text messages, and emails. Display 24 may also display various system indicators 26 that provide the user with feedback such as power status, signal strength, call status, external device connectivity, and the like. Display 24 may be any type of display, such as a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, or other suitable display. In certain embodiments, the device 10 may be disposed adjacent to the display 24, which may serve as an additional user input structure (eg, in addition to the structures 14, 16, 18, 20, 22) ( Touch sensing elements, such as a touch screen interface (not shown in FIG. 1). Through this touch screen interface, the user can select the elements displayed on the display 24 by touching certain elements, for example using the user's finger or stylus.

As further shown in this embodiment, display 24 may be configured to display a graphical user interface (GUI) 28 that allows a user to interact with device 10. GUI 28 may include various graphics layers, windows, screens, templates, elements, or other components that may be displayed on all or part of display 24. For example, the GUI 28 may display a plurality of graphical elements that are generally represented as icons 30. By default, for example, when the device 10 is first powered on, the GUI 28 may be configured to display the illustrated icons 30 as a “home screen”, indicated by reference numeral 29. In certain embodiments, user input structures 14, 16, 18, 20, 22 may be used to navigate through GUI 28 and thus may be remote from home screen 29. For example, one or more of the user input structures may include a wheel structure that may allow a user to select various icons 30 displayed by the GUI 28. In addition, the icons 30 may be selected via a touch screen interface.

As will be appreciated, the icons 30 may represent various layers, windows, screens, templates, elements or other components that may be displayed in some or all of the areas of the display 24 upon selection by the user. Moreover, selection of icon 30 may lead to or initiate a hierarchical screen navigation process. For example, the selection of icon 30 may cause display 24 to display another screen that includes one or more additional icons 30 or other GUI elements. Also, as shown in this embodiment, each graphic element 30 may be displayed on or near its respective graphic element 30 to facilitate user interpretation of each graphic element 30. It may have one or more text indicators 32 associated therewith. For example, icon 34 may be associated with a text indicator “transaction”. It should be appreciated that the GUI 28 may include various components arranged in a hierarchical and / or non-hierarchical structure.

When icon 30 is selected, device 10 may be configured to launch, open, or run an application associated with the selected icon 30 and display a corresponding screen. For example, when transaction icon 34 is selected, device 10 may open a transaction program and display a transaction menu displaying various tools that are features available in the transaction program. Thus, for each application provided on device 10, one or more respective screens or screens may be displayed on display 24, which may include various user interface elements corresponding to each application.

The electronic device 10 may include various input / output (I / O) ports such as the illustrated I / O ports 36, 38, and 40. These I / O ports may allow a user to connect or interface the device 10 with one or more external devices. For example, input / output port 36 may include a proprietary connection port for transmitting and receiving data files, such as media files. The input / output port 38 may include a connection slot for receiving a subscriber identity module (SIM) card, for example when the device 10 includes a cell phone function. Input / output port 40 may be an audio jack that provides a connection of audio headphones or speakers. As will be appreciated, the device 10 may include any number of input and output ports configured to connect to various external devices, such as power supplies, printers and computers or external storage devices, as a few examples. As will be appreciated, the I / O ports can include any suitable interface type, such as a universal serial bus (USB) port, a serial connection port, a FireWire port (IEEE-1394), or an AC / DC power connection port. have.

In addition, in some embodiments certain I / O ports may be configured to provide more than one function. For example, in one embodiment, I / O port 36 may be configured to send and receive data files as described above, as well as a power adapter designed to provide power from an electrical outlet, or other such as a desktop computer. The device may be further configured to couple the device to a power charging interface, such as an interface cable configured to draw power from the electrical device. Thus, I / O port 36 is configured to function as both a data transfer port and an AC / DC power connection port, depending on, for example, an external component coupled to device 10 via I / O port 36. Can be.

The electronic device 10 may also include various audio input and output elements. For example, audio input / output elements, generally indicated at 42, may include an input receiver that may have one or more microphones. For example, when the electronic device 10 includes a cell phone function, the input receivers may be configured to receive a user audio input such as a user's voice. In addition, the audio input and output elements 42 may include one or more output transmitters. Thus, if the device 10 includes a media player application, the output transmitters of the audio input and output elements 42 may include one or more speakers for transmitting audio signals to the user, such as for example, playing music files. .

In addition, when the electronic device 10 includes a cell phone application, as illustrated in FIG. 1, an additional audio output transmitter 44 may be provided. Like the output transmitter of the audio input and output elements 42, the output transmitter 44 may include one or more speakers configured to transmit audio signals, such as voice data received during a telephone call, to the user. Thus, the input receivers and output transmitters of the audio input and output elements 42 and the output transmitter 44 can operate in conjunction to function as audio reception and transmission elements of the telephone.

In the illustrated embodiment, the electronic device 10 further includes a near field communication (NFC) device 46. NFC device 46 may be disposed within enclosure 12, and a mark or symbol outside of enclosure 12 may identify its location within enclosure 12. NFC device 46 may generally include an antenna that may be disposed along the periphery of housing 12, and may provide a near range of communication at relatively low data rates (eg, 424 kb / s) Standards such as ISO 18092 or ISO 21481 may be followed. In some embodiments, NFC device 46 may provide near range communication at relatively high data rates (eg, 560 Mbps) and may follow the TransferJet® protocol. As used herein, it should be understood that the term " NFC device " refers to both the NFC communication device 46 as well as the aforementioned antennas.

In certain embodiments, communication using NFC device 46 may occur within a range of about 2-4 cm. As will be appreciated by those skilled in the art, near range communication using NFC device 46 may occur through magnetic field induction, such that NFC device 46 may communicate with other NFC enabled devices, Information may be retrieved from tags having an RFID) circuit. Magnetic field induction may also cause NFC device 46 to "wake up" or induce other NFC enabled devices in active mode, either in passive or sleep mode. As described in more detail below, NFC device 46 may interact with one or more external servers for the acquisition and transmission of payment and crediting information, as well as for the processing and authorization of transactions, as well as for verification of payment and crediting accounts. It may be used in conjunction with the transaction application described above (eg, represented by graphical element 34) to provide communication.

Referring now to FIG. 2, a rear view of the electronic device 10 shown in FIG. 1 is shown. As shown in FIG. 2, device 10 may include a camera 48. Camera 48 may be used to acquire digital still or moving images, such as digital photos or movies. As described in more detail below, camera 48 may be used in conjunction with the aforementioned transactional application indicated by graphical element 34 to obtain images of various types of payment means, such as checks or credit cards. have. As is known to those skilled in the art, various image processing techniques, such as optical character recognition (OCR), are applied to the processing of photographic images of acquired payment means, so as to correspond to account holder identification and account information associated with a particular payment means. Can be extracted.

Further details of the exemplary apparatus 10 may be better understood with reference to FIG. 3, which is a block diagram illustrating various components and features of the apparatus 10 according to an embodiment of the present invention. As shown in FIG. 3, the device 10 includes the CPU 50, the control circuit 52, the storage device 54, as well as the display 24, the NFC device 46, and the camera 48 described above. It may include a plurality of communication interfaces 56, a video controller 76, a touch screen interface 78, an I / O controller 80, and a power source 80.

The operation of the apparatus 10 may generally be controlled by the central processing unit (CPU) 50 and the control circuit 52. These elements can work together to provide the processing power needed to execute an operating system, application programs, GUI 28, and any other functions provided on device 10. The CPU 50 may include a single processor or, in other embodiments, may include a plurality of processors. For example, the CPU 50 may include “universal” microprocessors, combinations of general purpose and custom microprocessors, instruction set processors, graphics processors, video processors, as well as associated chip sets and / or special purpose processors. Control circuit 52 may include one or more data buses for transferring data and instructions between components of apparatus 10. The control circuit 52 may further include an on board memory (RAM) for caching purposes. In addition, although not shown in FIG. 3, the apparatus 10 may include a standalone random access memory (RAM) in communication with the CPU 50 through one or more memory controllers that may be integrated into the control circuit 52.

The information used by the CPU 50 can be stored in the long term storage device indicated by reference numeral 54. The storage device 54 of the electronic device 10 includes data necessary for the operation of the CPU 50, data processed or executed by the CPU 50, as well as other data that the device 10 needs, such as application and program data. Can be used to store data. For example, the storage device 54 can be configured to store firmware for the electronic device 10 used by the CPU 50. The firmware may include not only an operating system but also other programs or drivers that enable various functions, GUI functions, and / or processor functions of the electronic device 10. Storage device 54 may also store components for GUI 28 such as graphical elements, screens, and templates. In addition, storage 54 may include media (eg, music and video files), image data, application software, preference information (eg, media preferences, general user preferences), wireless connection information (eg, device 10 Or information that allows establishing a wireless connection, such as an Internet connection), subscription information (e.g., information that maintains a record of a podcast, television show, or other media the user subscribes to), telephone information (e.g., a phone number), and Data files such as any other suitable data needed by device 10 may be stored.

Long term storage device 54 may be a non-volatile memory such as read-only memory, flash or semiconductor memory, hard disk drive, or any other suitable optical, magnetic or semiconductor computer readable medium, as well as combinations thereof. Thus, while long term storage device 54 is shown as a single device for clarity, it should be understood that long term storage device 54 may include one or more combinations of the foregoing storage devices that operate in conjunction with CPU 50. .

In addition, in certain embodiments, storage device 54 may include an image processing application configured to perform extraction of text or encoded information from image data, such as an image acquired using camera device 48. . The image processing application may simply use one or more OCR techniques as described above. For example, an image processing application may be used to extract banking information from credit card information or an image of a acquired check from an image of the acquired credit card. These features and applications are described in more detail below.

Apparatus 10 may further include one or more communication interfaces shown in FIG. 3 at 56 to provide additional access channels for transmitting and receiving information. For example, communication interface 56 may represent one or more network interface cards (NICs) and / or network controllers, as well as various related communication protocols. The communication interface 56 includes a wireless local area network (WLAN) interface 58, an NFC interface 60, an unstructured auxiliary service data (USSD) interface 62, a personal area network (PAN) interface 64, a local area network. Various types of communication interfaces, including but not limited to (LAN) interface 66, wide area network (WAN) interface 68, and short message service (SMS) interface 70.

PAN interface 64 may provide capabilities for networking with, for example, a Bluetooth® network, an IEEE 802.15.4 (eg, ZigBee) network, or an ultra-wideband network (UWB). As will be appreciated, networks that can be accessed by the PAN interface 64 may represent low power, low bandwidth or near range wireless connections, but need not be so. The PAN interface 64 may permit one electronic device 10 to connect to another local electronic device, such as a computer or a portable media player, via an ad hoc or peer to peer connection. However, if the physical distance between the two electronic devices exceeds the effective range of the PAN interface 64, the connection may be interrupted.

LAN interface 66 and WLAN interface 58 may generally provide a longer range of communication channels over the effective range via PAN interface 64. LAN interface 66 may represent an interface to a wired Ethernet based network that provides, for example, access to an intranet or the Internet, and WLAN interface 58 may represent an interface for connecting to a wireless LAN, such as an IEEE 802.11x wireless network. Can be. Also, in many cases, a connection between two electronic devices via LAN interface 66 may include communication through one or more network routers, switches, gateways, or some other intermediate device.

Connection to the wide area network (WAN) may be provided through the WAN interface 68. WAN interface 68 may grant a secret and / or secure connection to a cellular data network, such as an Enhanced Data rates for GSM Evolution (EDGE) network or a 3G network (eg, based on the IMT-2000 standard). When connected via the WAN interface 68, the electronic device 10 is connected to the Internet despite location changes that may disrupt the connection via the PAN interface 64, the LAN interface 66, or the WLAN interface 58. In some embodiments, the electronic device may remain connected to one or more additional electronic devices.

In certain embodiments, the electronic device 10 may also include a service discovery networking protocol for establishing a connection with an external device via a network interface. For example, both device 10 and an external device can broadcast identification information using Internet Protocol Standards (IP). In some embodiments, the external device can further broadcast information related to the available services that the external device can provide (eg, printing services for a networked printer). The devices may then use the identification information to establish a network connection, such as a PAN connection or a WLAN connection between the devices. For example, a device identification protocol may be provided by Bonjour® developed by Apple.

Small sized communications can be transmitted using the USSD interface 62 and the SMS interface 70. The SMS interface 70 may permit the transmission of text messages of 140 bytes or less. In certain embodiments, larger size messages may be sent using connected SMS. USSD interface 62 may facilitate the transmission of real-time text messages over GSM signaling channels. For example, USSD interface 62 may be used to query location and address, movie watch time, stock price, and the like.

The device 10 may further have a near range communication capability through the NFC interface 60. NFC interface 60 may operate in conjunction with NFC device 46 described above to provide near range communication between device 10 and an external device. NFC interface 60 may exist as a separate component, may be integrated into another chipset, or may be integrated within NFC device 46 itself, for example as part of a system on chip (SoC) circuit. NFC interface 60 may include one or more protocols, such as near field communication interface and protocol (NFCIP-1), to communicate with other NFC enabled devices. The protocols can be used to adapt the communication speed and designate one of the connected devices as the initiating device to control and / or initiate the NFC connection. In certain embodiments, NFC interface 60 may be required to authorize connection via another communication interface, such as WLAN interface 58, PAN interface 64, LAN interface 66, or WAN interface 68. It may be used to receive information such as a service set identifier (SSID), channel and / or encryption key.

In certain embodiments, NFC interface 60 may be connected to other NFC-enabled devices and payment and crediting information in the context of electronic device 10 performing or initiating the processing of a financial transaction, as described in more detail below. Allows communication in peer-to-peer mode for exchanging the same data. NFC interface 60 may be used to transmit or receive data in the "host" or active mode where NFC device 46 generates its own RF field, and when the NFC device 46 detects an RF field generated by another device. It may be configured to switch the NFC device 46 between a passive mode or a " wake-on-NFC " mode that can be induced into an active state to perform reception. As will be appreciated, operation of NFC device 46 and interface 60 in passive mode can extend battery life of device 10. In further embodiments, NFC device 46 may be preset by the manufacturer or seller, or based on user or manufacturer preferences indicated by reference numeral 72, which may be subsequently configured by the user based on the user's preferences. Can be controlled. These preferences may be stored in storage 54 regardless of whether they are preconfigured or subsequently configured.

In embodiments where electronic device 10 is configured to provide for the initiation of peer-to-peer transactions including financial transactions with an external device as described in more detail below, preferences 72 may be a user specified preference. Or a default payment account or source, as well as a user specified preference or default crediting account. As used herein, terms such as "payment account" and the like should be understood to refer to the account to which the payment is debited or billed. In addition, terms such as "crediting account" and the like should be understood to refer to an account in which payment is deposited or credited. Thus, the default payment account may be an account that is automatically selected to provide payment when a transaction is initiated on the device 10. Similarly, the default crediting account may be an account that is automatically selected for crediting or depositing received payments. The preferences 72 may also include a preferred email address that a user prefers to receive electronic receipt records or confirmation messages related to payments made or received through manipulation of the electronic device 10.

In certain embodiments, preferences 72 may further determine characteristics of the aforementioned communication interfaces 56 (including, for example, 58, 60, 62, 64, 66, 68, 70). For example, the preferences 72 can include a list of networks to which the device 10 can connect, and can further manage the order or priority between the communication interfaces 56. For example, device 10 may be configured to communicate via NFC interface 60 when the communication involves receiving payment information from or transmitting payment information to an external device. Similarly, the device 10 may be configured to communicate via a WLAN 58 or LAN 66 interface if the communication involves, for example, verifying received payment information with external and / or remote financial servers. Can be. Moreover, device 10 may be configured to initiate or participate in a group transaction in which communication with a plurality of external devices is achieved through a combination of provided communication interfaces 56. For example, in one embodiment, the device 10 may receive payment information from one or more of a plurality of external devices via the NFC interface 60, while at the same time a WLAN 58, a PAN 64, or a LAN 66. The updated invoice or bill may be transmitted to each of the external devices through the ad hoc network established through one of the interfaces.

As can be appreciated, the communication preferences associated with the preferences 72 may further depend on the security features 74 available for each communication interface 58, 60, 62, 64, 66, 68, 70. . The security features 74 may be stored in the storage device 54, such as a secure socket layer (SSL) protocol or a transport layer security (TLS) protocol to establish secure communication between the device 10 and an external device. It may include one or more encryption protocols. Security features 74 may also include one or more cryptographic applications for encrypting information sent from device 10. Such features may be particularly useful when transferring sensitive nature information such as payment and / or crediting account information, which may generally include credit card and bank account information, for example.

Security features 74 are used to restrict access to data that may be required by certain aspects of security features 74, such as encryption keys, passcodes and passwords, digital certificates, and the like (eg, storage 54). May include) secure access restricted storage areas. The secure storage area may also be adapted to store sensitive data, such as information about the user's financial accounts, including credit card accounts and bank accounts. The secure storage area may also store information about accounts of non-financial nature. As used herein, terms such as "non-cash account", "non-financial account", and the like, however, include non-monetary assets that may be used as a medium of transactions with at least one party, such as an organization that owns or maintains a non-cash account. It should be understood to refer to accounts that can. To provide an example, a non-financial or non-cash account may be a user's online music / media subscription or purchase account, such as an iTunes account available through the iTunes® online digital media store developed and operated by Apple. The iTunes account may include a number of "credits" that allow a user to obtain or exchange media files such as music files, movie files, audio books, podcasts, and the like from the iTunes online media store. Thus, such non-cash accounts may be stored alongside financial accounts (eg, banking and credit card accounts) in a secure storage area provided by security features 74. In certain embodiments, the secure storage area may include a microcontroller embedded within the electronic device 10. In addition, in some embodiments, the secure storage area may, in addition to the storage of sensitive data described above, have its own respective password or authorization "personal identification number" (e.g., to prevent unauthorized access to the information stored therein). PIN) can be further protected.

According to further embodiments, the security features 74 may include all (e.g. For example, lock on power up) or just certain functions may be locked or temporarily disabled. For example, when locked, the aforementioned peer to peer transaction features may simply be disabled or not accessed by users until a user specified PIN or password is provided. In addition, security features 74 may further include requiring a PIN to be provided prior to the transmission or transfer of payment account information to external devices. As can be seen, the security features 74 described herein can help prevent the device 10 from being used to make payments by unauthorized persons.

As noted above, the device 10 is video operatively coupled to the display 24 and may be configured to receive image data and transmit voltage signals corresponding to the pixel values of the image data to the display 24. The controller 76 may further include. The displayed image may represent information received through the communication interface 56 as well as information included in the storage device 54. As will be appreciated by those skilled in the art, pixel values may be numerical assignments corresponding to respective pixel intensities. Thus, display 24 may receive voltage signals from video controller 76 as input and generate an image corresponding to the voltage signals. For example, the image generated by the signals provided by video controller 76 may represent the screen of GUI 28 described above with respect to FIG. 1.

In addition, as described above, a user operating the device 10 may select various graphical elements that may represent applications or information that may be displayed via the GUI 28. As shown in FIG. 3, the touch screen interface 78 may be disposed in front of or behind the display 24, and graphical elements such as icons 30 displayed by the GUI 28 described above in FIG. 1. May provide the user with the ability to select them. The touch screen interface 78 receives input based on physical contact (eg, touch of the display 24) by the user or an object (eg, a stylus) controlled or manipulated by the user, and receives “touch event” information. It may be configured to transmit to the CPU (50). Subsequently, the CPU 50 may process the detected touch event information and perform a corresponding action. For example, referring briefly to FIG. 1 again, “touching” of icon 34 may be processed by CPU 50 as an instruction to launch or launch a corresponding transactional application. The touch screen interface 78 may use any suitable type of touch screen technology such as resistance, capacitive, infrared, surface acoustic waves, electromagnetic or near field imaging. Moreover, the touch screen interface 78 may use single point or multi point sensing.

The I / O controller 80 shown in FIG. 3 uses the CPU through various input structures provided by the user on the device 10, such as the input structures indicated by reference numerals 14, 16, 18, 20 and 22 in FIG. An infrastructure may be provided for authorizing to communicate with 50. User input structures 14, 16, 18, 20, 22 may be used in conjunction with or independently of touch screen interface 76 to provide input information to device 10.

Power source 82 of device 10 may include the ability to power device 10 in both non-portable and portable settings. For example, in a portable setting, to facilitate transportation and movement, device 10 may include an integrated power source 82 for powering device 10. The power source 82 may include one or more batteries, such as lithium ion batteries, which may be removed by the user or secured to the enclosure 12. In certain embodiments, a proprietary connection I / O port 36 may be used to connect the device 10 to a power source to recharge the battery. In other embodiments, one or more batteries may not be integrated and may include one or more rechargeable or replaceable batteries. In addition, in a non-portable setting, power source 82 may include an AC power source as provided by an electrical outlet.

As noted above, device 10 may include a transactional application (eg, indicated by icon 34) that provides device 10 with the ability to initiate and receive transactions (eg, payments and credits) from an external device. Can be. Referring now to FIG. 4, generally reference numerals for performing peer to peer transactions between the first device 10 operated by the "recipient" and the second device 92 operated by the "payee". A system, shown at 90, is shown. The second device 92 may be a portable device substantially the same as the first device 10, or in other embodiments may be a non-portable device such as a desktop computer or payment terminal. As used herein, the term "recipient" should be understood to refer to one party of a transaction receiving a payment, and the term "payer" should be understood to refer to another party of a transaction making a payment. Thus, the terms “recipient device” and “payer device” should be understood to refer to devices (eg, devices 10, 92) operated by the payee and payer respectively.

As shown in FIG. 4, the device 10 acts as the recipient of the transaction and the second device 92 acts as the payment recipient. First, the recipient device 10 may send a payment request, indicated by reference numeral 94, to the payer device 92. The payment request information 94 may include information regarding a payment amount requested by the payee device 10. The payment request information 94 may indicate the payee's identifier, which may include the payee's name, an email address belonging to the payee and / or identifying the payee, or text data corresponding to any other type of appropriate identification information. Information may also be included. In addition, the payment request 94 may further include information indicating the purpose of the payment request. For example, the payment request 94 may correspond to a particular outstanding debt or difference that the payer has to pay to the payee.

In one embodiment, the payee device 10 and the payer device 92 may be both NFC enabled devices each having a respective NFC device 46 and an NFC interface 60 as described above. Initially, both the payee 10 and payer 92 devices may be in a passive mode of operation. Just before sending the payment request 94 to the payer device 92, the NFC device 46 of the payee device 10 may be powered on, so the payee device 10 may be the NFC device of the payee device 10. 46 may be switched to the active mode in which the RF field is generated. Thus, when the payee device 10 and the payer device 92 are located within close proximity or distance (eg, typically 2-4 cm) sufficient to facilitate the establishment of an NFC connection, the payee device 10 The RF field generated by) may induce the NFC device 46 of the payer device 92 to switch to an active mode of operation, thus establishing an NFC connection between the two devices as described above. Thus, over the established NFC connection, payment request information 94 may be transmitted and received by the payer device 92.

Upon receipt of the payment request information 94 from the payee device 10, the payer device 92 may display the received payment request information 94 on a display such as the display 24 described above. Thus, the payer can review the payment request information 94 accurately and select a payment method to use to provide the requested payment to the payee. The payment method can be, for example, a credit card account or bank account belonging to the payee. As described above, account information associated with the selected payment account may be stored in the payer device 92, such as in a secure storage area of the storage device 54 described above in FIG. 3. Thus, information associated with the selected payment method (eg, credit card or bank account) may be stored and retrieved from the secure storage area for transfer to the recipient device 10 upon selection of a particular account by the payer.

Thus, once the desired payment account is selected, payment account information indicated by reference numeral 96 may be sent to the recipient device 10. For example, like the transmission of payment request information 94, payment account information 96 is likewise over a previously established NFC connection over each NFC interface 60 of each device or if the previous NFC connection has already been terminated. In some cases (eg, if the distance between the devices exceeds the 2-4 cm range) it may be sent from the payer device 92 to the payee device 10 by initiating a new separate NFC connection session. In certain embodiments, the recipient device 10 may include the security features 74 described above, and only transmit payment information 96 if a password, PIN, or some other suitable form of authentication is first provided. Can be granted. Before continuing the description, it should be noted that the NFC-based exchange of payment information between the payee device 10 and the payer device 92 is provided by way of example only. Indeed, in other embodiments, any type of suitable communication interface may be used, such as those described above with respect to communication interface components 56 in FIG. 3.

Upon receiving payment information 96 from payer device 92, the payee can see payment information 96 on display 24 of payee device 10. The payee can then select the desired crediting account that can be stored in the payee device 10, where the payment indicated by the pay account information 96 is credited or deposited. When a crediting account is selected on the payee device 10, the requested payment amount, payment account information 96, and the selected crediting account, collectively referred to as "transaction information" and indicated by reference numeral 98, are selected from the account information. It may be sent by the payee device 10 to one or more financial servers 100 for subsequent authorization and processing of the verified and requested payment. As will be appreciated, communication with financial servers 100 may be accomplished through one or more of the communication interfaces described above. For example, if the recipient device 10 is a portable device having WLAN or WAN capabilities, the recipient device 10 may communicate with the financial servers 100 via a wireless connection. If the device 10 is not a portable device, a LAN connection may be provided for communication with the financial servers 100. Regardless of the type of connection established between the device 10 and the financial servers 100, the data encryption techniques and security protocols described above with respect to the security features 74 of FIG. 3 (eg, SSL or TSL protocols). One or more of the) may be further utilized to assist in secure transmission of transactional data 98 to financial servers 100.

As will be appreciated by those skilled in the art, the type or types of financial servers 100 to which transaction data 98 is transmitted may depend on the type of payment account selected by the payer and / or the type of crediting account selected by the payee. Can depend For example, if the payment account selected by the payer is a credit card account and the credit account specified on the payee device 10 is a bank account, the financial servers 100 may include a bank card as well as a credit card verification server. Can be. For example, transaction information 98 may first be sent to a bank server associated with a banking institution that maintains a designated crediting account to verify that the designated crediting account is a valid account and can accept credit card payments. As will be appreciated, receipt of credit card payments into a bank account may constitute a special service that may require registration, subscription or additional payment of fees by the recipient. Thus, if the crediting account is not authorized to receive payments made using the credit card account, the payee may be notified to select a different crediting account.

If it is determined that the selected crediting account is authorized to receive payments from the credit card account, transaction data 98 may be further sent to the credit card verification server in the form of an authorization request. The credit card verification server may be associated with a credit card company that maintains a payer's selected credit card account, such as American Express® or MasterCard®. The credit card verification server may process the transaction information 98 to determine whether a claim for the credit card account of the payer of the amount specified in the payment request may be authorized. For example, the credit card verification server may first verify that the credit card account information provided in the transaction information 98 corresponds to a valid credit card account belonging to the designated payer. The credit card verification server may further determine whether the credit line associated with the credit card account is sufficient to meet the requested payment amount. If the credit card verification server determines that the specified credit card account is valid and authorized to make the requested payment, the credit card verification server places a payment to the crediting account selected by the payee by charging the payer's credit card. I can grant it. The credit card verification server then generates an authorization message indicating that the requested payment was authorized, the requested payment was charged to the payer's credit card account, and credited or deposited in the recipient's credit account (e.g., a bank account). Can be sent to the bank server.

The interactions between the credit card verification server and the bank server described above are merely to illustrate one possible scenario related to the processing of a transaction initiated by the payee device 10 or the payer device 92. Thus, it should be understood that there may be various other types of scenarios in which one or more types of financial servers are used for processing peer to peer transactions in accordance with embodiments of the present invention. For example, in a scenario where the designated crediting account and payment account are bank accounts maintained at different respective banking institutions, the transaction may be processed by multiple bank servers instead of the credit card verification server. Communication between the various financial servers 100 described above is available on payee device 92 and payer device 92, such as WAN 68, LAN 66, or WLAN interface 58, with only a few examples. It should be further understood that it may be provided by any suitable communication interface and may include one or more security protocols, such as SSL or TSL, as well as one or more data encryption techniques to protect the security and integrity of transaction information 98. do.

As further shown in FIG. 4, once the transaction is processed, a completion message 102 may be sent to the recipient device 10. The completion message 102 may be received by WAN, WLAN, LAN interfaces as described above, or in some embodiments sent via email or via an SMS text message (eg, via SMS interface 70). Can be. Completion message 102 may indicate whether the requested transaction was processed successfully. If the transaction is successful, the completion message 102 may include a confirmation indicating to the payee that the requested payment 94 has been credited to the designated crediting account. Alternatively, if the transaction is unsuccessful for one or more reasons (eg, lack of sufficient funds or credits in the provided credit card account), the completion message 102 may indicate that the transaction was unsuccessful and / or to follow an alternative payment method. You can inform.

In one embodiment, the payee device 10 may store multiple crediting accounts therein, and the payee may designate priorities associated with the crediting accounts via user preferences 72 and the like. For example, the selected crediting account may be automatically selected as the crediting account with the highest priority. Thus, if the transaction was unsuccessful because of a currently selected crediting account (eg, the account may not be configured to receive credit card payments), the transaction application may use the next highest priority crediting account to It can be configured to automatically initiate subsequent transaction requests to the financial servers 100. In addition, the financial servers 100 or the payee device 10 may transmit a confirmation message in the form of an electronic receipt indicated by reference numeral 104 to the payer device 92 when the transaction is successfully processed. The electronic receipt 104 can be used as a confirmation that the requested payment was met by the payer and received by the payee.

In the examples provided above one or more financial servers 100 refers to multiple servers (eg, bank servers and credit card verification servers), but in certain scenarios one or more financial servers 100 may be designated payment accounts and credits. The accounting account may include a single financial server, such as in situations where the account is maintained by the same financial institution (eg, the same bank). In such a scenario, the transaction authorization process described above may be performed by a single server associated with a common financial institution. Thus, while the expression “single server” may refer to two or more computing devices at different locations, it should be understood that each of the computing devices is owned, manipulated, or related by the same financial institution. Further, one or more financial servers 100 need not be limited to financial servers configured to manage monetary assets. For example, if a transaction requires non-cash assets, such as credits stored in an iTunes® account as described above, the financial servers 100 may include a server managed by an iTunes online server. Indeed, these additional embodiments related to the interactions of the various financial servers 100 are also envisioned within the scope of the present invention and will be described in more detail below.

Continuing with the present description, FIGS. 5A-10B illustrate various methods and techniques for configuring electronic device 10 for use in transaction application 34 described above via a plurality of screen images. The screen images shown are generated by the GUI 28 and can be displayed on the display 24. For example, such screen images may be generated when the user interacts with device 10 via input structures 14, 16, 18, 20, 22, and / or touch screen interface 78, and the like. Specifically, these figures store payment account and crediting account information on device 10 in accordance with embodiments of the present invention, as well as the user preferences 72 and security features described above with respect to FIG. 74 illustrates techniques and methods for constructing one or more of the following.

As noted above, GUI 28 may display various screens including icons (eg, 30) and graphical elements in accordance with inputs and selections made by the user. Such elements may represent graphical and virtual elements or “buttons” that may be selected by the user, for example, by physically touching their respective location on the display 24 using the touch screen interface 76. . Thus, when used in the description of the screen images below, terms such as "button", "virtual button", "graphic button", "graphic elements", etc., are represented by graphical elements provided on the display 24. It should be understood that it is intended to refer to graphical representations of buttons or icons. It should also be understood that the functions provided and described in the subsequent figures may be accomplished using various graphical elements and visual schemes. Accordingly, the invention is not intended to be limited to the very user interface conventions described herein. Rather, embodiments of the present invention may include various user interface styles.

First, referring to FIGS. 5A and 5B, these figures collectively represent screen images that can be displayed on device 10 when information representing a credit card account is entered and stored by device 10 by the user. . The stored credit card information can then be used as a payment account in conjunction with the transaction application described above. As shown in FIG. 5A, a user can launch a transactional application by selecting an icon 34 displayed on the home screen 29 of the device 10. Upon selection of icon 34, the transactional application may be launched via CPU 50 or the like, and the user may proceed to screen 110, which may present a "home" or "main" screen for the transactional application.

Screen 110 may include a plurality of graphical elements, indicated by reference numerals 112, 114, and 116. Each of the graphical elements 112, 114, 116 may be displayed in the form of a button or key, and may include a brief description of the corresponding function or action associated therewith. For example, graphical button 112 may represent a function to view and change account information stored in device 10. Graphic button 114 may represent the ability for a user to initiate a peer to peer transaction, such as the transaction described above in FIG. 4. In addition, graphical button 116 may represent a function that allows a user to view and change various user preferences, such as user preferences 72 described above with respect to FIG. 3. The functions provided by the graphical button 116 may allow a user to change or access one or more of the security features 74 described above.

This description will first begin with a description of the functions provided by the graphical button 112. However, it should be remembered that additional functions provided by the graphical buttons 114, 116 are described in more detail below. In addition, as shown in FIG. 5A, screen 110 may include a graphical button 118. Graphic button 118 may represent an action to return the user to the previous screen. For example, if the user selects the button 118 displayed on the screen 110 of FIG. 5A, the user will return to the home screen 29.

In order to enter and store a new credit card account into the device 10, the user selects the graphical button 112 to access a screen 120 that can display a list of all accounts currently stored on the device 10. can do. As shown by screen 120, currently stored accounts can be organized and displayed according to certain categories. For example, the account information screen 120 may include a first list 122 of currently stored credit card accounts, a second list 124 of currently stored banking accounts, a third list 126 of currently stored non-cash accounts, as well as specifics. An additional list 128 of other accounts that may include charge cards or loyalty cards associated with the seller or retailer may be displayed. In addition, the account information screen 120 shows additional graphical elements representing the functions of adding additional accounts to the device 10 or removing existing accounts from the device 10 as indicated by the graphical buttons 130, 132, respectively. Can include them. Thus, in order to add a new account to the device 10, the user can select the graphical button 130. Also, if the user wants to remove a previously stored account displayed on one or more lists 122, 124, 126, 128, the user can do so by selecting graphical button 132.

As shown in FIG. 5A, upon selection of graphical button 130, the user may proceed to screen 134. Screen 134 may include a plurality of graphical buttons 136, 138, 140, 142, 144, each of which may represent categories of accounts of various types that may be stored on device 10. For example, the user may initiate the process of entering and storing a new credit card account by selecting graphical button 136. This selection may advance the user to screen 146. However, if the user can decide to select any other graphical button 138, 140, 142 or 144 for input of different account types, the selection of any other graphical button directs the user to each appropriate screen. Understand that you will proceed.

Referring now to screen 146, several dropdown style selection fields indicated by reference numerals 148, 150, 152, and 154 may be displayed. For example, drop-down selection field 148 may provide a list of credit card brands corresponding to various credit card providers that may make appropriate selections based on the particular credit card the user wishes to store on device 10. have. In addition, the dropdown fields 150 and 152 may provide the user with a selection of month and year corresponding to the expiration associated with the new credit card account, respectively. As will be appreciated, the dropdown fields can display a list of available options that can be selected to populate each dropdown field when driven or selected by the user. For example, referring to a dropdown field 154 that may indicate a selection of a category corresponding to the type of credit card account being input, the user may select a category from a list of available categories that generally describe the various credit card account types. Can be. For example, credit cards may generally be used in connection with gas purchases, online or travel purchases, or may be general purpose cards for various purchases.

According to one aspect of the present invention, the manufacturer of the device 10 may reach agreement with one or more credit card providers who may preconfigure the device 10 such that a particular credit card brand may be initially selected as the default selection. One or more business methods may be provided. For example, as shown in FIG. 5A, drop-down field 148 may initially indicate a default credit card brand associated with a particular credit card provider (eg, American Express®). Thus, if the user continues with the process shown in Figures 5A and 5B, completing the steps of adding a credit card type of default selection to the device 10, the manufacturer of the device 10 and the credit card provider are credit card providers. Each time a credit card account maintained by is stored on a device sold and / or manufactured by the manufacturer, the manufacturer of the device 10 may enter into an agreement to receive a fee or fee. In addition, the manufacturer of the device 10 allows the manufacturer of the device 10 to receive a portion of the credit card transaction fee that is paid to the credit card provider when the credit card transaction is performed using the device 10. You can also go into consultation with them.

Continuing with the description of FIG. 5A, screen 146 may further include several text fields as indicated by reference numbers 156 and 158. Field 156 may allow the user to enter an account number corresponding to the new credit card account. Form field 158 may also be provided to allow a user to enter a card verification value (CVV) code corresponding to the selected credit card. As will be appreciated, CVV codes are generally printed on the front or back of the credit card, may be encoded in a magnetic strip on the credit card, and may be used as an additional security feature in credit card transactions, thus improving on credit card fraud. Can provide protection. In an alternative embodiment, the CVV code may not be needed when entering a new account, but instead may be required by the device 10 whenever a newly added credit card account is used in a transaction.

To enter data in fields 156 and 158, screen 146 may include graphical text input keyboard interface 160. Text input keyboard interface 160 may include, for example, a plurality of graphical buttons representing alphabetic characters, as well as buttons representing standard “spacebar” and “backspace” functions on the keyboard. Thus, the user can enter text data into any text fields that can be displayed on the display 24 of the device 10 using the text keyboard interface 160. Text input keyboard 160 may also include graphical buttons 162 that allow a user to toggle between text input keyboard 160 and numeric keyboard 164. As shown in FIG. 5A, numeric keyboard 164 may include a plurality of commonly used punctuation marks as well as a plurality of buttons representing numbers 0-9. Numeric keyboard 164 may also include graphical buttons 166 that the user can select to return to text keyboard 160. For example, a user may switch from text keyboard 160 to numeric keyboard 164 to enter credit card account number and CVV code into form fields 156, 158. In addition, if there is a need to return to text keyboard 160, the user can do so by selecting graphical button 166 on numeric keyboard 164. In further embodiments, numeric and text input features may be integrated into a single graphical keyboard interface.

Once all the credit card information required by the dropdown fields 148, 150, 152, 154 and text fields 156, 158 is provided by the user, the user selects the graphic button 168 to select a credit card. You can begin the verification process. This verification process may generally serve the purpose of verifying that the user performing the steps of entering the credit card account into the device 10 is a credit card account holder or an authorized user. For example, during the verification process, credit card information entered on screen 146 may be sent to the corresponding credit card provider. As noted above, the transmission of credit card information may be accomplished through one or more of the communication interfaces described above and may be protected by one or more of the encryption and security methods described above.

Referring now to FIG. 5B, when the credit card provider verifies that the credit card information provided by the device 10 is valid, the credit card provider verifies the identifier of the user by sending one or more verification codes to the device 10. Can be. For example, referring to screen 170, a notification message 172 may be displayed informing the user that a verification code for driving a credit card to be used on device 10 has been provided, for example, by email or the like. As will be appreciated, the email address to which the verification code is sent may be an email address associated with a credit card account and included in records maintained by the credit card provider. Thus, this ensures that only authorized users or users receive the verification code. Thus, the credit card verification screen 170 may include a graphical button 144 that allows a user to run an email program that can retrieve email messages to obtain a verification code.

In addition, by selecting the graphical button 178, the user may return to the screen 120, which may be updated to include a new credit card account 180 entered by the user through the screen 146 as described above. have. At this point in the process, screen 120 does not allow the newly entered credit card account 180 to make a payment from the device 10 until an authorization or activation action such as the provision of the verification code described above is performed. It may indicate that it may not. If the user has obtained the email verification code described above with respect to screen 170, the user can proceed to screen 184 and enter the verification code, thus allowing for credit card account (for use on device 10). 180) can be activated. For example, as shown in FIG. 5B, a user may select a location of a new credit card account 180 on screen 120 and proceed to screen 184.

As shown on screen 184, the user may be provided with a text field 186 for entering the email verification code described above. The verification code can be entered using text input keyboard 160 and / or numeric keyboard 164 which can be accessed by selecting graphical button 162. Once the email verification code is entered, the user can select the graphical button 188, thus completing the verification process and returning to the screen 120. If the verification code provided by the user in the text field 186 matches the verification code provided by the credit card provider, then the newly entered credit card account 180 is shown in the last updated screen 120 of FIG. 5B. Likewise, it will be authorized and ready for use in conjunction with transactional application 34.

If the email verification code is not received for some reason, the user may alternatively activate the credit card account 180 by providing a phone verification number in the text field 190. For example, referring back to screen 170, phone confirmation code 176 is also provided in notification message 172. In one embodiment, in order to obtain a phone verification code, the user may be different from the email verification code, but the corresponding entry permitting the use of the newly entered credit card 180 by the transaction application 34 when correctly entered. In order to receive the phone verification code, a phone verification code 176 must be provided to the credit card provider, such as by phone call. Thus, the user can enter the phone verification code into the text field 190 and select the graphical button 192 as an alternative way to authorize the newly entered credit card account 180 for use in the transactional application 34. have.

Referring now to FIGS. 6A and 6B, these diagrams illustrate a method for entering and storing a bank account in the electronic device 10 via screen images. As will be appreciated, the various aspects of the process shown in FIGS. 6A and 6B may be similar but not identical to the steps described above with respect to FIGS. 5A and 5B. Starting from FIG. 6A, a user can select graphical button 112 on screen 110 to access screen 120, which can display a list of all accounts currently stored on the device as described above. As shown in FIG. 6A, the credit card accounts 180 entered by the user in FIGS. 5A and 5B are included in the list 122 of stored credit card accounts.

The user may then select graphical button 130 on screen 120 to proceed to screen 134. As described above, screen 134 may display graphical buttons 136, 138, 140, 142, 144, each of which represents various types of accounts that may be stored in device 10. Can be. Thus, in order to enter and save a new bank account, the user may select graphical button 140 and proceed to screen 198. As shown in FIG. 6A, screen 198 is similar to screen 146 described above in that it may provide a plurality of dropdown fields (eg, 200, 202) and text fields (eg, 204, 206). can do. Through these fields, the user can enter the required bank account information into the device 10. For example, dropdown fields 200 allow a user to select an identifier of a banking provider associated with a new bank account. The dropdown field 202 may provide a selection of the types of banking accounts that may be stored, for example, check accounts, savings accounts, cash market accounts, and the like. In addition, the text fields 204 and 206 may allow the user to enter the routing number of the banking provider and the account number associated with the bank account, respectively. Text keyboard 160 may be provided on screen 198 for entry of data in fields 204 and 206. In addition, as noted above, the numeric keyboard 164 may be accessed through the selection of a graphical button 162 when input of numeric data such as routing and bank account numbers described above is required.

Once the required bank account information is entered in the dropdown fields 200 and 202 and the text fields 204 and 206, the user selects the graphical button 208 to display the transactional application 34 on the device 10. The process of verifying and authorizing a bank account entered for use can be initiated. As can be seen, certain aspects of the verification process associated with the entered bank account may be similar to the credit card verification process described above with respect to FIG. 5B. For example, during the verification process, the bank account information entered in the screen 198 may be sent to the banking provider selected in the dropdown field 200. As mentioned above, the transfer of bank account information may be accomplished through one or more of the aforementioned communication interfaces (eg, interfaces 58, 60, 62, 64, 66, 68, 70), and the encryption and security described above. Protected by one or more of the methods.

Referring now to FIG. 6B, when the banking provider verifies that the bank account information sent by the device 10 represents a valid bank account, the banking provider may use any suitable type of authentication technique to identify the user's identifier. You can check it. For example, in the illustrated embodiment, a banking provider may initiate one or more verification deposits in a bank account. As those skilled in the art will understand, the verification deposit is generally a relatively small amount (eg, less than US $ 1) and can be used to verify the account holder's identifier. For example, the banking provider may require the account holder to provide the correct value of the verification deposit before the newly entered bank account can be authorized for use in the transactional application 34. For example, referring now to screen 210 of FIG. 6B, a notification message 212 may be displayed if the banking provider has validated the bank account entered on screen 198. In the illustrated embodiment, notification message 212 may inform the user that two verification deposits have been credited to a newly entered bank account, but it should be understood that any number of verification deposits may be used in the verification process.

The user may select graphical button 214 to return to screen 120, where list 124 may be updated to include the newly entered bank account as indicated by reference numeral 216. Like the screen 120 shown in FIG. 5B, the screen 120 of FIG. 6B shows that a new bank account 216 makes a payment using the device 10 until the verification deposit described above is verified by the banking provider. May indicate that it may not be used. Thus, the user may need to determine the amount of the verification deposit, for example, by reviewing a banking statement issued after the deposit of the verification amount.

After determining the verification deposit, the user can access screen 218 by selecting the location of a new bank account 216 on screen 120. As shown in FIG. 6B, screen 218 may display text fields 220, 222 through which a user may enter the amount of two verification deposits. The screen 218 can also include a numeric keyboard 164 through which the user can enter verification deposit amounts in the fields 220, 222. Once the verification deposit amount is entered, the user may select graphical button 224 to return to screen 120 to complete the verification process. As shown in FIG. 6B, if the deposit amount entered by the user in screen 218 matches the verification amount deposited by the banking provider, the newly entered bank account 216 is the last updated screen of FIG. 6B. It will be authorized and prepared for use in conjunction with transactional application 34 as shown at 120. As described in more detail below, a bank account stored on device 10 (or device 92) may be used as both a crediting account and a payment account depending on whether device 10 acts as a payee device or a payer device. have.

Referring now to FIGS. 7-10B, as described above, the apparatus 10 may be one or more preferred settings, such as those indicated by reference numeral 72 in FIG. 3, which may be preconfigured by the manufacturer or later configured by the user. It may include. For example, preference settings 72 may include additional settings such as the selection of a default payment account, a default crediting account, as well as the selection and storage of an authorization PIN number for security purposes. Thus, the screen images shown in FIGS. 7-10B are intended to illustrate by way of example the techniques by which a user can manipulate the device 10 to configure the aforementioned preference settings.

First, referring to FIG. 7, selection of a default payment account may begin first from screen 110. Here, the user can select the graphical button 116 to access a screen 230 that can display the current configuration of one or more user preferences on the device 10. In the illustrated embodiment, user preference settings displayed on screen 230 may include a currently selected default payment account 232 and a currently selected default crediting account 234. Screen 230 may be displayed next to default accounts 232 and 234, respectively, and may also include graphical buttons 236 and 238 that allow the user to modify or change the selected default account settings.

As will be explained in more detail, screen 230 may identify a user of device 10, e.g., a user entered email address 240 that may be used by transaction application 34 to receive a payment receipt, for example. You can also display various other preferences, such as As shown in FIG. 7, the user may update the email address setting 240 through the selection of the graphical button 242. Screen 230 may further include a graphical button 244 that the user can select to enter and store an authorization PIN code as well as indicate an authorization status associated with transaction application 34. For example, as indicated by reference numeral 246, transaction application 34 may be in "unlocking" mode and may therefore be used by a user to perform the transactions generally described above. For security purposes, the user may toggle this permission setting 246 between unlocking and locking mode, such as by selecting a graphical button 248 that can disable transaction application 34 when in locking mode. Can be. As will be appreciated, when the transactional application 34 is locked, the user may not be able to send and receive payments using the device 10. In certain embodiments, transaction application 34 may only be unlocked when providing an authorization PIN as described in more detail below.

Referring back to the default payment account 232 setting, the user may update the preference setting by selecting a graphical button 236 that may advance the user to the screen 258. Screen 258 may display a list of all accounts currently stored on the device that may be selected as a payment account. In the embodiment shown, the list of accounts can be organized into categories indicated by reference numbers 260, 262, 264. As can be seen, this may be similar to the list of accounts shown on screen 120 with respect to FIG. 5A. The list 260 may correspond to a list of credit card accounts currently stored in the device 10. As shown in list 260, the credit card account 232 displayed on the previous screen 230 may be indicated to be the currently selected default payment account. Here, the user may have the option of selecting one of the other listed accounts as the default payment account. In addition, the user may select graphical button 266 if he or she does not want to configure default payment account settings. For example, by selecting graphical button 266, transaction application 34 may prompt the user to select a payment account each time a payment is made using device 10.

In this embodiment, the user can select the credit card account 180 entered in FIGS. 5A and 5B. For example, a user can select a credit card account 180 by selecting his general location on screen 258. The previously selected default payment account (eg, credit card account 232) may then be deselected and credit card account 180 may be directed on screen 258 as the currently selected default payment account. The user may then select graphical button 118 to return to screen 230, which may be updated to display credit card account 180 as the newly selected default payment account.

Referring now to FIG. 8, this figure shows additional screen images from which the user can select a default crediting account. As shown, the user can select graphical button 238 on screen 230 to access screen 270. Screen 270 may display a list of all accounts currently stored on the device that may be selected as a crediting account. For example, screen 270 may display a list 262 of bank accounts and a list 264 of non-cash accounts. However, screen 270 may omit the list 260 of credit card accounts described above with respect to screen 258 of FIG. 7, because credit card accounts generally accept payment credits or deposits. It is not used as an intermediary.

As shown in list 262, the bank account 234 displayed on the previous screen 230 may be indicated to be the currently selected default crediting account. Thus, the user may have the option of selecting one of the other accounts listed on the screen 230 as the default crediting account. For example, the user may select the bank account 216 entered in FIGS. 6A and 6B. For example, a user may select a bank account 216 by selecting its general location on screen 270. The previously selected default crediting account 234 may then be deselected and the bank account 216 may be indicated on the screen 270 as being the currently selected default crediting account. The user can then select the graphical button 118 to restore the screen 230, which can be updated to display the bank account 216 as the newly selected default payment account. In addition, as noted above, the user does not want to configure default crediting account settings, but instead prefers to be prompted to select a crediting account each time a payment is received through the device 10. ) Can be selected.

If the default payment account (eg, credit card account 180) and default crediting account (eg, bank account 216) are configured by the user in the manner described above with respect to FIGS. 7 and 8, the user may receive additional preferences from screen 230. You can continue to configure the settings. For example, referring now to FIG. 9, a plurality of screen images are shown illustrating a method for selecting an authorization PIN. Beginning with screen 230, a user may select graphical button 244 to access screen 280. Screen 280 may include an indication message 282 that generally instructs the user to select a desired authorization PIN having a predetermined number of characters. For example, in the illustrated embodiment, the device 10 may be configured to store a four digit PIN. However, it should be appreciated that other implementations may use authorization PINs of any desired length.

As shown on screen 280, a user may enter a desired PIN 286 into text field 284 via numeric keyboard 164. Further, in embodiments in which the device 10 may support PIN codes with text and numbers, the user may select the text button 160 (not shown in FIG. 9) by selecting the graphical button 166 as described above. Can be accessed. Once the desired PIN 286 is entered, the user can update the screen 280 to display a confirmation message 290 instructing the user to re-enter the selected PIN 286 in the confirmation text field 292. By selecting 288, the input PIN 286 can be confirmed. Accordingly, the user can re-enter the selected PIN 286 into the text field 292 via the numeric keyboard 164.

Once the PIN 286 is entered in the text field 292, the user can complete the permission PIN selection process by selecting the graphical button 294. As will be appreciated by those skilled in the art, upon selection of graphical button 294, device 10 may determine whether the authorization PIN codes entered in text fields 284 and 292 are the same. If the PINs entered in the text fields 284, 292 do not match due to incorrect user input or for any other reason, the user may be notified of the inconsistency (not shown in FIG. 9), and the PIN 286 may be texted. It may be required to re-enter each of the fields 284 and 292 once again. If the entered PINs are determined to be the same, the PIN 286 may be used for use as an authorization PIN code to provide additional security features in connection with various aspects of the transactional application 34 as described in more detail below. ) Can be stored. Subsequently, once the authorization PIN 286 is confirmed and stored in the device 10, the user may have a graphical button 298 corresponding to the function that the user can edit or change the currently stored authorization PIN code 286. ) Can be returned to the updated screen 230 which is replaced with.

In addition to providing the user with the ability to select and store the authorization PIN code 286, user preference settings for the device 10 may further provide the ability to lock or disable the transactional application 34. It is possible to prevent the device from receiving, sending or processing transaction requests while the transaction application 34 is locked. For example, in one embodiment transaction application 34 may remain locked or disabled when locked by the user until the authorization PIN 286 stored by the user in FIG. 9 is entered. Such techniques related to locking and subsequent unlocking of a transactional application can be better understood with reference to FIGS. 10A and 10B.

First, referring to FIG. 10A, as described above, screen 230 displays the current state of permission settings 246 for transaction application 34 that may indicate that current transaction application 34 is in an unlocked state. Can be displayed. To lock the transactional application 34, the user can select the graphical button 248 to access the screen 304. As shown on screen 304, a notification message 306 may be displayed that generally informs the user that the device 10 cannot send and receive transaction requests when the transaction application 34 is locked. If the user chooses to lock the transaction application 34, the user can do so by selecting the graphical button 308 on the screen 304. As shown in FIG. 10A, selection of graphical button 308 locks transaction application 34 and returns the user to screen 230, which indicates that permission settings 246 are currently locked. Can be updated to indicate. Graphic button 248 may be replaced with graphic button 312 on updated screen 230, which may represent a function that allows the user to unlock transaction application 34 upon subsequent selection. In addition, if the user decides not to lock the transactional application 34 on the screen 304, the user selects the graphical button 310 to indicate that permission settings 246 for the transactional application are directed to be unlocked. It may return to screen 230.

Referring now to FIG. 10B, if the user decides to lock transaction application 34 in FIG. 10A, the user may select graphical button 312 on screen 230. Upon selection of graphical button 312, the user may proceed to screen 318, which may display notification message 320, field 322, and graphical button 324. The notification message 320 can instruct the user to enter the permission PIN 268 selected in FIG. 9. As shown, a numeric keyboard 164 may be provided for input in the text field 322 of the authorization PIN 268. Once the authorization PIN 268 is entered, the user can confirm the unlocking request by selecting a graphical button 324 that can return the user to the screen 230, where the transaction application 34 is once again displayed. The permission setting 246 is updated to reflect an unlocking state and thus enabling the ability to send and receive transaction requests using the device 10 again. It should also be noted that the graphical button 312 can be replaced with the graphical button 248 as described above.

While various aspects of the configuration of the transactional application 34 that can be executed on the device 10 have been described, FIG. 11A illustrates a method for processing after initiating a transaction from the perspective of the payee, generally indicated at 328. . Similarly, FIG. 11B illustrates a method 360 that illustrates the receipt of a transaction request from a payer's point of view and the subsequent action of making a payment in response to the transaction request. It should be understood that in some situations the methods 328, 360 may occur at least partially concurrently.

Starting from FIG. 11A, method 328 may begin with the determination of the invoice in step 332. As understood, the term "invoice" may refer to the general terms of a payment request, which may include the amount of the requested payment, the identifier of the requested payee, as well as additional information describing the nature or reasons for which the payment is being requested. have. If the conditions of the invoice are determined in step 332, the invoice information may be sent to the payer, as indicated in step 334. For example, the transmission of invoice information described in method 328 may correspond to the communication of payment request information 94 from the payee device 10 to the payer device 92 as described above with reference to FIG. 4. .

Then, as indicated at step 336, the payee may wait for the transfer of information indicative of the payment account from the payer. As noted above, the receipt of payment information from the payer may direct the confirmation and acceptance of the requested payment from step 334. Upon receiving payment information from the payer, the payee may select, on step 338, the crediting account on the device 10 that the payment requested by the payee will be credited or deposited. For example, as described above, the crediting account may be automatically selected as the user-specified default crediting account 216 and / or manually selected by the user as described above with respect to FIGS. 6A and 6B.

Subsequently, the payment request information determined in step 332, which is referred to together as "transaction information", the payment information received from the payer in step 336, and the crediting account selected from step 338 are used for verification and processing of the requested transaction. The above may be transmitted to the appropriate financial server 100. For example, as described above, the types of financial servers 100 to which transaction information may be transmitted may depend on the types of payment and crediting accounts selected by the payer and the payee, respectively.

In decision step 340, the transaction information can be processed to determine whether the requested transaction can be authorized. If it is determined in step 340 that the financial servers 100 cannot authorize one or more of the payment account or the crediting account to perform the requested transaction, the method 328 proceeds to decision step 342 where the payee is currently present. It may be urged to renegotiate the conditions of the transaction. For example, if the payee wants to renegotiate the terms of the transaction, the payee may return to step 336 to receive an alternate payment account from the payer, or return to step 338 to select an alternate crediting account. As will be appreciated, the determination of whether to return to step 336 or 338 may depend on the reason or reasons why the transaction information cannot be verified or authorized in decision step 340. For example, if the authorization process fails due to insufficient funds or credits associated with the payment account received in step 336, the payee provides an alternative payment account with sufficient funds, credits, etc. for the payer to meet the requested payment amount. You can ask to be done. In such a scenario, the method 328 may proceed from decision step 342 to step 336 again.

As an alternative, a situation may arise where the authorization failure at decision step 340 is due to an incompatibility between the payment account and the crediting account. For example, this type of transaction failure may occur if the selected payment account is a credit card account and the selected credit account is a bank account that is not authorized or configured to receive payments from the credit card account. Thus, the method may return from decision step 342 to step 338 to prompt the recipient to select an alternate crediting account that is authorized to receive payment from the selected payment account, or return to step 336 to the payer to the payer. A request may be made to select an alternative payment account, such as a bank account, that is compatible with the recipient's selected crediting account. Alternatively, the recipient may decide not to renegotiate the condition of the transaction at step 342, and thus cancel the current transaction at step 344.

Now, returning to decision step 340, if it is determined that the requested transaction can be authorized in connection with payment and crediting accounts, in step 346, corresponding to the requested payment amount, as indicated by reference numeral; The payment to make may be credited or deposited into the crediting account selected in step 338. If payment is received by the payee in step 346, the transaction may be completed in step 348. Then, in step 350, the payment receipt may be sent by the payee to the payer either directly through the payer device 10 or indirectly through one of the financial servers 100 under the recipient's permission. For example, the payee may authorize an electronic receipt, such as receipt 104 of FIG. 4, to be sent from one or more financial servers 100 to the payer's device 92 upon successful completion of the transaction.

Referring now to FIG. 11B, the transaction described generally in FIG. 11A from the recipient's point of view is described from the payer's point of view through method 360. Beginning at step 364, the payer may receive a payment request from the payee. For example, receipt of a payment request at step 364 may correspond to transmission of invoice information at step 334 of method 328. Upon receipt of a payment request, the method 360 proceeds to step 366 where the payer can select a payment account from one or more of the available payment accounts stored in the payer device 92. As in the description of the selection of the default payment account 180 on the device 10 in FIGS. 5A and 5B, the payer device may include similar features. If a payment account is selected, the method continues to step 366 where the payment account to be selected is sent to the payee. As noted above, in one embodiment, the transfer of payment request and payment account information may be accomplished via an NFC connection between the payee device 10 and the payer device 92. When the payee receives information indicating the payer's selected payment account, the payee may select a crediting account (eg, step 338 of method 328) and send transaction information to one or more financial servers 100 for processing. Can provide.

At decision step 368, a determination is made as to whether the transaction completed successfully. If the transaction is not completed for one or more of the reasons described above, as indicated in step 370, the payer's account will not be charged. Alternatively, if it is determined at decision 368 that the transaction is authorized and successfully completed by the financial servers, then the requested payment amount will be debited or billed to the crediting account designated by the payer at step 372. Then, as indicated by step 374, the payer may receive a receipt from the crediting account indicating that the payment was made. For example, the receipt received at step 374 of method 360 may correspond to the receipt sent at step 350 of method 328 described above.

12A-12C show schematic diagrams illustrating various transactions that may be performed between the payee device 10 and the payer device 92 in accordance with the presently described techniques. In general, the embodiments shown in FIGS. 12A-C represent various scenarios in which a transaction may be initiated between two NFC enabled devices via an NFC tap operation as described in more detail below. For example, FIG. 12A illustrates an embodiment where payment is made through a credit card account stored on payer device 92 in response to a payment request provided by payee device 10. 12B and 12C show additional embodiments in which a bank account is selected as the payment account by the payer. Specifically, FIG. 12B illustrates a scenario where selected payment and crediting accounts are maintained by different banking providers, and FIG. 12C illustrates a scenario where selected payment and crediting accounts are maintained by the same banking provider.

Starting from FIG. 12A, the transaction 375 may include a payee device 10, a payer device 92, as well as a bank server 380 and a credit card verification server 382 in this embodiment. It may include a financial server 100. To initiate a transaction 375, the payee device 10 may first send a payment request 384 to the payer device 92. As noted above, the payment request 384 may include additional information related to the nature or reason for the payment request, as well as the amount of the requested payment, the recipient's identifier. As described above, the payee device 10 and the payer device 92 may both be NFC enabled devices. Thus, the payment request information 384 may be transferred from the payee device 10 via the establishment of the NFC connection 388 by " tap " or " tap operation " the devices as indicated by reference numeral 386. 92).

As used herein, terms such as "tap" and "tap action" may refer to placing one NFC enabled device in the vicinity of one or more additional NFC enabled devices to establish an NFC based connection between the devices. It should be understood to mean the action that makes it possible. As mentioned above, one technique for establishing an NFC-based connection may be through magnetic field induction, whereby a first NFC enabled device acting as a host device generates an RF field, which is then The NFC connection is established by inducing an NFC device located within the second device to transition from a passive state to an active state. Once the NFC connection is established, information can be exchanged between the devices.

Referring briefly to FIG. 13, a schematic diagram of NFC tap operation 386 is shown. For example, prior to initiating NFC connection 388, payer device 92 may be in manual or “wake on NFC” mode as indicated by reference numeral 390. While in the passive state, NFC device 46 and NFC interface 60, which may be included in device 92, are inactive until NFC interface 60 detects NFC transmissions from an external device, such as recipient device 10. Can be maintained. For example, when the payee device 10 operates to send a payment request 384, the NFC interface 60 and the corresponding NFC device 46 located within the payee device 10 are indicated by reference numeral 392. You can switch to active or host mode. While in host mode 392, the NFC device 46 of the recipient device 10 has another NFC with its own respective NFC interface 60 and NFC device 46 that are within the appropriate range to assist the NFC connection. NFC communications signals may be periodically emitted to find enabled devices.

For example, when the payee device 10 and the payer device 92 are placed within a range suitable for establishing an NFC connection (eg, tap operation 386), the establishment of the connection is initiated from the initiating handshake referred to by reference number 396. Can be. When tapping the devices, it should be understood that the NFC devices 46 in each device are positioned so that the distance between each NFC devices 46 is suitable for establishing an NFC based connection. For example, if the payer device 92 is a relatively large non-portable device, the payee may have any correspondence in the payer device 92 that the NFC device 46 in the payee device 10 establishes an NFC connection 388. It will be necessary to place the recipient device 10 to be in a proper transaction of the NFC circuit.

While NFC interface 60 and NFC device 46 of recipient device 10 are operating in host mode, recipient device 10 may periodically emit ping messages 400. The corresponding NFC interface 60 of the payer device 92 may receive ping messages 400 so that the NFC device 46 located within the payer device 92 wakes up upon detection of the NFC transmission. (Eg, wake on NFC), as indicated by reference number 398, may allow the transition from passive mode to active mode. Thus, if the NFC device 46 of the payer device 92 is powered on and powered on, the ping message 400 may be transmitted by sending a confirmation message 402 that may be received via the NFC interface 60 of the payee device 10. ), Thus completing the initiation handshake 396.

Following this initiation handshake 396, the payee device 10 and the payer device 92 may exchange device profiles as indicated by reference numeral 404. Device profiles 404 may include various information regarding the functions available on payee device 10 and payer device 92. For example, device profiles 404 may be any suitable form of data, including extended markup language (XML), which may represent device name, serial number, owner name, device type, as well as any other type of identification information. Can be represented by messages. For example, the additional identification information may include the name of a service provider, such as a network or cellular telephone service provider, which may be associated with each of the devices 10, 92, for example. The device profiles 404 may further include information related to the capabilities of the payee device 10 or payer device 92 by indicating what applications, drivers or services can be installed on each device. have.

Recipient device 10 and payer device 92 may also exchange information related to the encryption capabilities available on each device, as indicated by reference numeral 406. As noted above, the various transactions described herein may involve the transmission of sensitive information, such as information about credit card accounts and bank accounts, and therefore, between the payee device 10 and the payer device 92. Of course, the use of one or more encryption means to protect transaction information that is also sent to one or more financial servers 100 may be implemented. Thus, once the NFC connection 388 is established and the device profiles 404 and encryption capabilities 406 are exchanged, information may be exchanged between the devices 10, 92, as indicated at 408. Can be.

Referring now again to FIG. 12A, data transmission 408 may include transmitting payment request information 384 from payee device 10 to payer device 92 over an established NFC connection 388. . Subsequently, upon receipt of payment request information 384, the payer may, in response, continue the transaction process by selecting a payment account stored in payer device 92. In the embodiment shown, the selected payment account may be a credit card account. The payer device 92 may transmit the credit card information 410 corresponding to the selected credit card account to the payee device 10 via the NFC connection 388 via the second tap operation 412. As can be seen, the tap operation 412 is similar to the tap operation described above with reference to FIG. 13 except that the payer device 92 operates as a host device and the payee device can operate in a " wake on NFC " mode. 386). In some embodiments, the exchange of payment request information 384 and payment account information 410 may occur via a single tap operation (eg, 386) if the distance between the devices 10, 92 is maintained. Therefore, it should also be noted that the NFC connection 388 may remain active during the data transfer period.

After receiving the credit card information 410 on the payee device 10, the payee may select a crediting account on which the requested payment will be credited, as described above with respect to method 328 (eg, step 338). . When the crediting account is selected, the payer's credit card account information 410, the payee's credit account information, and the payment request information 384, collectively represented by transaction information 414, are indicated by reference numeral 416. It may be transmitted to the financial server 380 through a network connection. For example, if the selected crediting account is a bank account, the financial server 380 may correspond to a banking provider that maintains the crediting account. In addition, the network 416 to which the transaction information 414 is transmitted may be any suitable network that may be provided by one or more communication interfaces 56 (eg, WAN, LAN, WLAN, etc.) available on the recipient device 10. It may include. For example, network 416 may be a wireless Internet connection established via WLAN interface 58, a local area network connection established via LAN interface 66, or a General Packet Radio Service (GPRS) connection, Enhanced Data rates for GSM. Evolution) connection or wide area network connection established via WAN interface 68, which may include one of a variety of WAN mobile communication protocols, such as a 3G connection in accordance with the aforementioned IMT-2000 standard.

Upon receipt of transaction information 414, financial server 380 may perform various actions for authorization of the requested transaction 375. For example, financial server 380 may first access the accounts provided by transaction information 414 to determine whether the specified payment account and the crediting account are compatible. As mentioned above, the financial server 380 may not be able to process the requested transaction 375 if the designated crediting account is not authorized to receive payment from the credit card account. Then, if the crediting account and payment account are determined to be compatible by the financial server 380, the financial server 380 credits the payer's credit card account information, indicated by reference numeral 418, via the network 420. The card verification server 382 may further transmit. Network 420 may be any type of suitable network to assist in the transmission of data, including one or more of the network types described above in connection with network 416 where transaction information 414 is initially transmitted to financial server 380. Can be.

Once the payer's credit card account information 418 is received by the credit card verification server 382, additional verification and authorization steps indicated by reference numeral 422 are performed to ensure that the credit card account provided is valid and that the requested payment has been made. You can verify that you have enough credit lines to implement. Thus, if the credit card verification server 382 determines that the provided credit card information 418 corresponds to a valid credit card account having enough credits to fulfill the requested payment 384, the credit card verification server 382. May authorize the requested payment by sending an authorization message via the network 420 to the financial server 380. The financial server 380 may then complete the processing of the requested transaction 375 as indicated by reference number 424, in which case the amount corresponding to the requested payment is charged to the payer's credit card account. In this case, the amount charged is deposited in the recipient's selected crediting account.

Subsequently, if the transaction is successfully processed and completed in step 424, a transaction confirmation message 426 may be sent via the network 416 to the recipient device 10. Transaction confirmation message 426 may generally indicate to the payee that the requested payment 384 has been completed. In addition, a payment receipt 428 may be sent to the payer device 92. The payment receipt 428 may be sent to the payer device 92 by any of the connection types described above. For example, the transmission of the payment receipt 428 may be the payee device 10 and the payer device 92, such as a LAN connection (eg, interface 66), WLAN connection (eg, interface 58), or WAN connection (eg, interface 68). It can be through the network 430, which can be any type of network connection established through a common networking interface available on the network. In addition, the payment receipt 428 may be sent by tapping the payee device 10 on the payer device 92. This tap operation, indicated at 432, may establish an additional NFC connection 434, thus providing a channel through which the payment receipt 428 may be sent to the payer device 92.

The payment receipt 428 may include information such as the total payment amount of the transaction 375, the payment method (eg, credit card account 410) and the time the transaction 375 was processed. In addition, in certain embodiments, payment receipt 428 may include financial servers 100 and devices (eg, including bank server 380 and credit card server 382) when performing transaction 375. It may indicate an additional charge of fees associated with transaction processing services collectively provided by (10, 92). Thus, it should be noted that in accordance with a further aspect of the present invention, various business methods may be provided in which transaction fees are charged for one or both of the payee and payer. The fee may be charged each time a transaction request is processed, or may be a flat fee based, for example, on a monthly subscription service. Also, a banking provider (eg, associated with the financial server 380), a credit card provider (eg, associated with a credit card server 382) or manufacturers of device manufacturer (s) (eg, devices 10, 92). An agreement may be made in which a transaction fee may be assigned between one or more of the entities that provide transaction services, including a). According to one embodiment, a transaction fee may first be collected by a single entity (eg, a banking provider) and then allocated in a negotiated manner between the remaining entities (eg, credit card provider and device manufacturer (s)). .

Referring now to FIG. 12B, a schematic diagram illustrating an alternative embodiment of a transaction in accordance with the presently described techniques is shown, generally referred to by reference numeral 376. As noted above, transaction 376 may be similar to transaction 375 shown in FIG. 12A except that the payment account selected by the payer may be a bank account rather than a credit card account. As noted above, the payee device 10 may first send a payment request 384 to the payer device 92 via an NFC connection 388, which may be established as a result of the tap operation 386. Upon receipt of the payment request 384, the payer selects the bank account stored on the payer device 92 as the payment account and uses the NFC connection 388 to obtain the bank account information 440 from the payee device 10. Can be sent to.

After receiving the bank account information 440 on the payee device 10, the payee selects the crediting account as described above, and then selects the selected payment account (eg, 440), the crediting account, and the payment request information 384. Transaction information 442, which may be included, may be transmitted to the financial server 380 via the network 416. As noted above, the financial server 380, which may correspond to a banking provider that maintains the recipient's selected crediting account, may initiate one or more authorization steps, such as determining whether the designated payment account and the crediting account are compatible. . The financial server 380 may then send the payer's bank account information, indicated at 444, to the second financial server 418 associated with the payer's banking provider. That is, this transaction 376 illustrates a scenario in which bank accounts selected by the payee and payer are maintained by two different banking providers (eg, different financial institutions).

The transfer of bank account information 444 to financial server 418 may be via network 420. When bank account information 444 is received, financial server 418 may determine whether the account is a valid account and whether the account has sufficient funds to satisfy the requested payment 384. If the financial server 418 determines that the payment request 384 can be authorized with respect to the bank account 444, an authorization message may be sent via the network 420 to the financial server 380. Subsequently, as described above, the financial server 380 may complete the processing of the requested transaction 376, as indicated by reference number 448, in which case the amount corresponding to the requested payment is the payer's bank. The account is debited and then deposited into the recipient's crediting account.

Subsequently, if the transaction is successfully processed, a transaction confirmation message 450 may be sent via the network 416 to the recipient device 10. Transaction confirmation message 450 may generally indicate to the payee that the requested payment 384 has been deposited in the crediting account, and thus transaction 376 may be completed. In addition, as noted above, a payment receipt 428 may be sent to the payer device 92 using one or more of a variety of available networking connections.

Referring now to FIG. 12C, another schematic diagram of a transaction according to a further embodiment is shown, generally referred to by reference numeral 378. Specifically, FIG. 12C illustrates a transaction process that may be similar to transaction 376 described with respect to FIG. 12B, but here the bank accounts where the payment account and the crediting account are maintained by the same banking provider. As will be explained in more detail below, in this embodiment, one or more financial servers, indicated at 100 in FIG. 4, may only require a single financial server 380.

To initiate the transaction process 378, the payee device 10 may send the payment request 384 to the payer device 92 in a manner similar to that described above with respect to FIGS. 12A and 12B. For example, the transmission of the payment request 384 may be accomplished by tapping 386 the payee device 10 to the payer device 92 to establish an NFC connection 388 for the transfer of data. When payment request 384 is received, the payer may select a bank account as the payment account. The payer device 92 may then send banking information 458 associated with the selected bank account to the payee device 10 via the NFC connection 388.

Upon receiving banking information 458 from the payer device 92, the payee may select a crediting account for which the requested payment 384 will be credited. As mentioned above, in the presently described scenario, the selected crediting account and the payment account 458 provided collectively referred to as transaction information 460 may both be accounts maintained by the same banking provider. Thus, transaction information 460 may be sent over network 416 to financial server 380, which may be associated with a common banking provider for both payment and crediting accounts.

The financial server 380 may then perform the steps of validating the provided accounts as well as determining whether the payment account has sufficient funds to fulfill the payment request 384. Unlike the embodiments described in FIGS. 12A and 12B, the financial server 380 stores the account information as the credit card verification server 382 in FIG. 12A or the second financial server 418 in FIG. 12B since the common banking provider maintains the accounts. Note that there is no need to send to a second external server such as). Thus, information about the crediting account and the selected payment account 458 can be stored and accessed by the financial server 380. Thus, if the financial server 380 verifies that both the crediting and payment accounts are valid and that the payment account has sufficient funds to fulfill the requested payment 384, the financial server 380 is referred to at 464. The transaction can be processed as indicated, so that the requested payment is debited to the payer's bank account, as described above, and then deposited into the recipient's crediting account. Upon completion of transaction 378, a transaction confirmation message 466 may be sent from the financial server 380 to the payee device 10 via the network 416. In addition, a payment receipt 428 may be sent to the payer device 92 using the available networking connections described above.

Various embodiments illustrating peer-to-peer transactions (eg, between the payer device 92 and the payee device 10) with respect to each of the transactions 375, 376, 378 shown in FIGS. 12A, 12B, and 12C. Although described, various techniques for manipulating the payee device 10 and the payer device 92 to perform the transactions 375, 376, 378 described above on the payee device 10 or the payer device 92. It is further shown in FIGS. 14A-14J through schematic views as well as through various screen images that may be displayed. It should also be noted that in the presently described embodiment, the payee device 10 and the payer device 92 are both NFC enabled devices.

First, referring to FIG. 14A, a process is shown in which a recipient can manipulate a device 10 to send a payment request. The actions illustrated by these screen images will generally correspond to the step 332 of the method 328 shown in FIG. 11A as well as the transmission of the payment request information 384 to the device 92 which is the payment. Can be. Also, the illustrated actions may be performed from the recipient's point of view, and thus the actions shown on these screens are described as being performed by the recipient.

As shown in this figure, the process may begin with a screen 110 that may represent a “home screen” for the transactional application 34 as described above. From screen 110, the recipient can select graphical button 114, which can advance the recipient to screen 476. Screen 476 may display a plurality of graphical buttons 478, 480, 482. Each of these graphical buttons may represent a particular function that may be performed when selected by the recipient. For example, in the illustrated embodiment, graphical button 478 may represent a function by which a user can initiate a payment request. Graphic button 480 may represent a function that allows a user to send a payment to another device. In addition, graphical button 482 may allow a user to initiate a transaction between two or more other parties. The functions represented by the two later graphical buttons 480 and 482 are described in more detail below.

To initiate a payment request, the payee may select graphical button 478, which may advance the payee to screen 484. Like screen 476, screen 484 can also display a plurality of graphical buttons 486, 488, 490, each of which can represent specific functions. As shown, graphical button 486 may represent a function by which a payee may initiate a payment request using NFC device 46. This functionality may generally correspond to the techniques described above with respect to transactions 375, 376, 378. In addition, graphical buttons 488 and 490 can represent additional functions available on device 10 that can initiate transactions and are described in more detail below.

By selecting the graphical button 486, the payee can proceed to the screen 492. As shown in FIG. 14A, screen 492 may include text fields 496, 498, 500 that allow the recipient to enter information regarding the payment request. For example, text field 496 may be used to enter an identifier of the payee, text field 498 may be used to specify the amount of payment requested, and text field 500 may be used for the payment requested by the payee. Allows you to include an explanatory message of nature or reason. As indicated on screen 492, the required information is sent to text fields 496, 498, 500 via text keyboard 160 or numeric keyboard 164 (eg, via selection of graphical button 162). Can be entered. Once the requested information is entered in the text fields 496, 498, 500, the payee can send the entered information in the form of a payment request (eg 384) to the payer device 92 by selecting the graphical button 504. have.

The function represented by the graphical button 504 powers on the NFC device 46 of the recipient device 10 as described above, causing the device 10 to enter NFC active mode and enabling the NFC interface 60. May correspond to executing a command. For example, referring now to FIG. 14B, upon selection of graphical button 504, screen 508 may be displayed on recipient device 10. The screen 508 notifies that the NFC interface 60 of the recipient device 10 is currently active and can establish an NFC connection with an external device for the transmission of payment request information entered at the screen 492. May include a message 510. Accordingly, the notification message 510 may further instruct the recipient to tap (eg, 386) the recipient device 10 to a second device, such as the payer device 92, to establish an NFC connection.

Referring briefly to FIG. 14C, the establishment of an NFC connection 388 between two devices, namely the payee device 10 and the payer device 92, via a tap operation 386 is shown. As mentioned above, the NFC device 46 of the recipient device 10 is powered on upon selection of the graphic button 504 shown in FIG. 14A, hosting the device 10, as indicated by reference numeral 392. Mode or active mode, in which active device 10 may periodically emit NFC transmit ping messages 400 as described above with respect to FIG. 13. When the active device 10 is placed within an acceptable distance 514 (eg, 2-4 cm) from the payer device 92, which may be currently in passive or wake on NFC mode as indicated by reference numeral 390, The payer device 92 switches from passive mode to an active mode in which the NFC device 46 in the payer device 92 is powered on, enabling the corresponding NFC interface 60 of the payer device 92 and It may provide for setting up an NFC connection 388 between the payee device 10 and the payer device 92, from which a payment request may be sent.

The payer device 92 shown in FIG. 14C is shown to be a portable device similar to the payee device 10, although in alternative embodiments the payee device 10 is a non-portable device such as a personal computer, computing workstation, payment terminal, or the like. It should be understood that the devices may be included. For example, referring now to FIG. 14D, a setup of an NFC connection is shown in which the recipient device 10 is tapped on a non-portable desktop computer shown at 515. Accordingly, it should be understood that embodiments of the present invention are intended to provide for the initiation and processing of transactions between any suitable type of electronic device, whether portable or non-portable.

Referring again to FIG. 14B, if the payee device 92 taps 386 to the payer device 92, the payer device 92 may be configured to send NFC transmissions (eg, ping messages) from the payee device 10. 400, and may switch from passive to active mode, such that the corresponding NFC device 46 of the payer device 92 is powered on. As shown in FIG. 14B, if devices 10, 92 are tapped and NFC transmissions emitted from recipient device 10 are detected, screen 516 may be displayed on device 92 that is the payment. . Screen 516 displays a notification message 518 informing the payer that the NFC transmission has been detected and, in response, the corresponding NFC device 46 of the payer device 92 is powered on and the corresponding NFC interface 60 is enabled. ) May be included. Notification screen 516 may further provide a graphical button 520 that allows the payer to cancel the NFC connection process upon selection.

If the establishment of the NFC connection 388 on the payer device 92 is permitted, the screen 508 displayed on the payee device 10 may be updated to display the notification message 522. The notification message 522 is that an NFC connection (e.g., 388) is established between the payee device 10 and the payer device 92, and the payment request information specified by the payee on the screen 492 of FIG. 388 may be directed to the payer device 92. Screen 508 may also include a graphical button 512 with the option of the payee canceling the payment request before or during the transmission of the payment request information.

On the other hand, the notification screen 516 displayed on the payer device 92 may be similarly updated to display the notification message 524. The notification message 524 is that an NFC connection 388 has been established between the payer device 92 and the payee device 10, payment request information is sent from the current payee device 10, and within the payer device 92. The payer may be instructed that it is being received via the corresponding NFC interface 60.

As can be seen, the interactions between the payee device 10 and the payer device 92 described in FIG. 14B are generally one of the steps described in the methods 328 and 360 shown in FIGS. 11A and 11B, respectively. The above can be responded to. For example, the actions displayed on screen 508 may indicate step 334 of sending an invoice to the payer. Referring briefly to FIG. 15A, which illustrates in more detail various steps of the method 328 according to the present embodiment, the step of transmitting payment request information to the payer (eg, step 334) may be performed as indicated by step 530. Establishing an NFC connection through operation 386 or the like. Further, performing 334 may include transmitting payment request information entered at screen 492 to the payer device 92 using the established NFC connection as indicated by step 532. In addition, screen 516, which may be displayed on payer device 92 upon detection of NFC transmission from payee device 10, may indicate step 364 of receiving a payment request in method 360. . For example, referring now to FIG. 15B, step 364 may be described in more detail in accordance with the presently described embodiment. For example, according to this embodiment, receiving 364 the payment request may include joining the NFC connection via a tap operation as indicated by step 534. Also, once the NFC connection is established, the payer device 92 can receive payment request information sent from the payee device 10 using the NFC connection as indicated in step 536.

As described above with particular reference to FIGS. 12A-C, the payer may select an appropriate payment method on the payer device 92 in response to the payment request 384 received from the payee device 10. For example, the selected payment account may be a credit card account (e.g. 410), a bank account (e.g. 440) provided by a different banking provider with respect to a banking provider associated with the recipient's crediting account (e.g. 440), or a banking provider. May include a bank account (eg, 458) that also manages the recipient's crediting account. The selection of these various types of payment accounts may be illustrated by various screen images that may be displayed on the payer device 92 as shown in FIGS. 14E-14G.

First, referring to FIG. 14E, once payment request information is received by the payer device, screen 516 is generally entered by the payee in fields 496, 498, 500 on screen 492 of FIG. 14A. It can be updated to display details 540 of the payment request that can reflect the information. In addition, screen 516 may include graphical buttons 542 and 544 that allow the user to accept or decline the payment request, respectively. As shown in FIG. 14E, when the payer selects graphical button 542, the payer may proceed to screen 546. Screen 546 may list a portion or portion of the received payment request information. For example, screen 546 displays the payee's identifier 550 and the requested payment amount 552. Screen 546 may also display information regarding the payer's identifier, as indicated by reference numeral 548. In the illustrated figure, payer identifier information 548 may include the payer's name as well as an associated email address identifying the payer. Thus, the displayed email address is sent to the recipient device 10 and can be used by the transaction process for the transfer of the payment receipt 428 described above.

Screen 546 may further display the currently selected payment account 554. As shown, the currently selected payment method 554 may be a default or preferred payment method that may have been selected by the payer, such as by using one or more of the techniques described above with respect to FIG. 7. The screen 546 can also include graphical buttons 558, 560, 562. Graphic button 558 may represent a function by which a payer may initiate the transfer of payment information using default payment account 554. Graphic button 560 may represent additional functionality that allows the user to select an alternative payment method. Thus, if the payer prefers to use an account other than the account 554 in this transaction as the paying account, the payer may do so by selecting the graphical button 560. The payer may also have the option to cancel the transaction through the selection of graphical button 562.

If the payer decides to select a payment account that is different from the currently selected default payment account 554, the payer may select graphical button 560 to access screen 566. Screen 566 may display a plurality of graphical buttons 570, 572, 574, 576, 578 representing account categories. In certain embodiments, such as the presently described embodiment, each of the categories represented by buttons 570, 572, 574, 576 or 578 may be further subdivided into additional subcategories. For example, selection of a credit card account category represented by graphical button 570 may advance the payer to screen 580, which screen may be a variety of credit card account types that may be selected by the payer. Graphic buttons 584, 586, 588, 590, and 592 representing sub categories may be displayed. Referring back to screen 146 of FIG. 5A, credit card account subcategories for credit card accounts represented by graphical buttons 584, 586, 588, 590, 592 are provided in drop-down field 154. May correspond to one or more of the credit card categories. In addition, the payer may also have the option to view all available credit card accounts currently stored in payer device 92 by selecting graphical button 594.

The payer may decide to view all available payment accounts (eg, but not limited to credit card accounts) before making payment account selection. For example, by selecting graphical button 118 on screen 580, the payer can return to previous screen 566. Here, the payer may select graphical button 578 to access a list of all selectable payment accounts stored on payer device 92 that may be provided by screen 598. In the illustrated embodiment, screen 598 may display a list of all payment accounts currently stored and available by category. For example, the available payment accounts are generally grouped according to additional accounts 604, including credit card accounts 600, bank accounts 602, as well as non-cash iTunes® accounts, as described above. Can be.

As shown in the list of stored credit card accounts 600 on the screen 598, the available credit card accounts may include the currently selected default payment account 554 as well as a replacement credit card account 602. Thus, as shown on screen 598, if the payer does not want to use the default payment account 554 to provide the requested payment 384, the payer may open an alternate credit card account 602. You can choose as a payment account. Upon selection of alternate credit card account 602, the payer may return to screen 546, which may be updated to indicate the selection of credit card account 602 to be the payment account for the current transaction. . In addition, the updated screen 546 can display a graphical button 606 that can replace the previously displayed graphical button 558. Graphic button 606 may represent a function by which a payer may initiate the transfer of credit card account information 602 to payee device 10.

Alternatively, the payer may select other accounts other than the listed credit card accounts 600 as the selected payment account. For example, a user may select a bank account from list 603 or a non-cash account from list 604. Referring now to the screen images shown in FIGS. 14F and 14G, these images illustrate how a payer can select a bank account as a payment account. Specifically, FIG. 14F illustrates the selection of a bank account, wherein the selected bank account and the recipient's crediting account are maintained by different banking providers as described in transaction 376 of FIG. 12B. 14G illustrates the selection of the payer's bank account, which may correspond to transaction 378 shown in FIG. 12C, wherein the selected payment account and the recipient's crediting account are maintained by the same banking provider.

As shown in FIG. 14F, the payer may navigate to screen 566 by first selecting graphical button 542 on screen 516 and then selecting graphical button 560 on screen 546 as described above. Can be. On screen 546, as described above, rather than selecting graphical button 570 or 578, the payer selects graphical button 572, on payment device 92, which can be used as a payment account. Access screen 610, which may display a list 603 of stored bank accounts. As described in this embodiment, the payer may select a bank account 612. The payer can then return to an updated screen 546 that can reflect the selection of the bank account 612 as the payment account for the current transaction. As described above with respect to screen 270 in FIG. 8, bank account 612 may be different from banking providers associated with default crediting account 216 selected by the payee (eg, Wachovia®). Note that it relates to the provider (eg, Wells Fargo®). Thus, as discussed above in connection with FIG. 12B, the authorization and processing of a transaction in accordance with the actions indicated by the screens of FIG. 14F may be achieved by separate financial servers (eg, financial servers 380) associated with each banking provider. 418) may require communication to take place.

FIG. 14G similarly illustrates the selection of a bank account by a payer who may share a common banking provider with the recipient's crediting account as indicated by transaction 378 in FIG. 12C. Starting from screen 516, the payer is in the following order: graphical button 542 for navigating to screen 546, graphical button 560 for navigating to screen 566, and screen 610. May select a graphical button 572 to access a list 603 of bank accounts. Here, the payer may select a bank account 614 rather than a bank account 612. It should be noted that the bank account 614 and the payee's default crediting account 216 are associated with the same banking provider (eg, Wachovia®). Thus, upon selection of bank account 614, the payer may return to screen 546, which may be updated to reflect the selection of bank account 614 as the payment account for the current transaction. In addition, as described above with respect to FIG. 12C, a transaction according to the actions indicated by the screens of FIG. 14G may be authorized and processed by a single financial server (eg, 380).

As noted above, devices such as payee device 10 or payer device 92 may include one or more security features, such as the use of an authorization PIN code, such as PIN 286 described above in FIG. 9. As will be appreciated, the use of an authorization PIN code can prevent unauthorized payments from being made from the payer device 92 or the payee device 10. For example, the payer may configure the device such that an authorization PIN code must be provided (eg, via one or more user preference settings) to authorize the transfer and transfer of payment information from payer device 92.

Referring now to FIG. 14H, as indicated on screen 546, if a payment method, such as alternate credit card account 602, is selected, the payer may proceed with payment by selecting graphical button 606. Screen 620 may then be displayed on the payer device 92 and may include an indication message 622 instructing the user that an authorization PIN code must be entered to complete the transaction. Thus, the payer can enter the appropriate authorization PIN code 624 into the text field 626 via the numeric keyboard 164. As noted above, it should be appreciated that the device may support the use of alphanumeric authorization PIN codes. In such embodiments, the user may toggle between the numeric keyboard 164 and the text input keyboard 160 (not shown in FIG. 14H) by selecting the graphical button 166. Further, although the use of the authorization PIN code 624 is shown in FIG. 14H in connection with the selection of the credit card account 602 in FIG. 14E, the authorization PIN code 624 is shown in FIG. 14F when the selected payment method is a bank account. It should be appreciated that with respect to the embodiments shown in FIG. 14G, and of course, in the context of any other type of payment method that may be selected on the payer device 92.

Once the appropriate authorization PIN code 624 is entered, the user can authorize and send payment information to the recipient device 10 by selecting the graphical button 628. Upon selection of graphical button 628, screen 630 may be displayed on payer device 92, and as indicated by reference numeral 632, NFC device 46 of payer device 92 may power up. It can be turned on to enable the corresponding NFC interface 60 and instruct the payer device 92 to enter active or host mode as described above. The notification message 632 may further instruct the payer to perform a tap operation on the receiving device, in this example, the recipient device 10. In addition, screen 630 may include a graphical button 634 that the payer may select to cancel the transmission of payment information if needed.

Referring now to FIG. 14I, this figure generally illustrates the tapping operation and subsequent NFC connection setup between the payer device 92 and the payee device 10. As described above in FIG. 14H, screen 630, which may be displayed on payer device 92, includes an indication message 632 indicating to payer that payer device 92 is currently in active mode. And may further instruct the payer to perform a tap operation, such as tap operation 412 shown in FIG. 12A, with respect to the recipient device 10. Thus, if the payer device 92 and the payee device 10 are placed in close proximity to each other so that the distance between the two devices is sufficient to establish the NFC connection, the payer device 10 will ping messages 400 as described above. May detect NFC transmissions emitted from the payer device 92, such as).

Upon detection of NFC transmissions from the payer device 92, the payee device may activate its own corresponding NFC device 46. In addition, a screen 638 including a notification message 640 indicating to the recipient that the NFC transmission has been detected and the NFC device 46 of the recipient device 10 is powered on is displayed on the recipient device 10. Can be. Notification screen 638 may further include a graphical button 642 that provides the recipient with the option to cancel the establishment of the NFC connection, if desired. Thus, when the payee authorizes the establishment of the NFC connection, the screen 630 displayed on the payer device 92 and the screen 638 displayed on the payee device 10 respectively receive notification messages 644 and 646. Can be updated to display. The notification message 644 displayed on the payment information transmission screen 630 indicates that the NFC connection has been established and the payment information 410 is the payee device 10, which may include, for example, the credit card account 602 selected in FIG. 14E. Can be sent to the payer. At the same time, a notification message 646 displayed on the screen 638 of the recipient device 10 indicates that an NFC connection has been established and that payment information 410 is being received on the NFC interface 60 of the recipient device 10. The recipient can be instructed.

The actions dictated by the screens shown in FIGS. 14E-14I may generally represent the step of providing payment information to the payee as shown in FIG. 11B and indicated by step 336 of the method 360 described above. have. Referring again to FIG. 15B, step 366 of providing payment information to the payee is shown in more detail. For example, upon receipt of invoice information (step 536), a determination as to whether to accept the received payment information, as indicated by step 650, is made on the device 92 as the payment. This step may correspond to the selection of graphical button 542 on screen 516 as described above.

If the payment request information is accepted, then at step 652 the payer may proceed to select the payment account to which the payment request is debited or billed. This step can generally be represented by the selection of an alternative credit card account 602 shown in FIG. 14E or by the selection of bank accounts 612 or 614 shown in FIGS. 14F and 14G respectively. Then, if an appropriate payment account is selected, the NFC connection can be established by tapping operation as indicated in step 654, and thus on the payer device 92 and the payee device 10 in step 654 as described above. NFC connection can be established. Then, in step 656, the payment account information selected in step 652 may be sent to the payer device 92 via the established NFC connection. Referring to FIG. 14I, the transmission of payment information at step 656 may correspond to the transmission of payment information 410 from the payer device 92 to the payee device 10.

Also, from the recipient's point of view, the steps of establishing the NFC connection via the tap operation 412 as well as receiving the payment information 410 indicate the acquisition of the payment information 410 from the payer device 92. May correspond to step 336 of 328. This step is further described in FIG. 15A, where step 336 is shown in more detail in accordance with the transaction that is currently described. Referring to FIG. 15A, step 336 may include initially participating in an NFC connection established through a tap operation, such as tap operation 412, indicated by reference numeral 660. Following the establishment of the NFC connection, the payee may receive payment account information (eg, 410) corresponding to the payment account (eg, step 652) selected in step 662. Once payment information is received by the payee device 10, selecting a crediting account may be performed on the payee device 10 as indicated by step 338 in FIG. 15A.

Referring now to FIG. 14J, in accordance with one embodiment of the present invention, the selection of a crediting account by the payee is illustrated by screens 638, 674. Referring first to screen 638, once payment information 410 is received by payee device 10, screen 638 may be updated to display notification message 668. The notification message 668 may include information regarding the identifier of the payer as well as the amount of the requested payment. In response to the notification message 668, the payee may select the graphical button 670 to accept the payment provided, or alternatively select the graphical button 672 to cancel the payment process. If the payee chooses button 670 to decide to accept the payment, the payee can navigate to screen 674.

As shown in FIG. 14J, screen 674 may display payee identifier information 676 and payer identifier information 678. Payer identifier information 678 may indicate all of one or more additional identifying attributes such as, for example, the payer's name and email address. As described in detail above, upon successful completion of a transaction, a payment receipt, such as payment receipt 428, may be sent to the payer's email address specified in payment identifier information 678.

Screen 674 may further include payment amount information 680, payment method information designated by the payer indicated at 682, as well as a crediting account for which the requested payment will be credited. As shown on screen 674, as described above with respect to FIG. 8, a crediting account may initially be selected as the default crediting account 216 specified by the payee during configuration of device preferences. Screen 674 also includes a graphical button 686 that allows the user to initiate the process of crediting the requested payment to the default crediting account 216, and a graphical button 688 that allows the user to select an alternate crediting account. ), Of course, may include a graphical button 690 that allows the user to cancel pending transactions.

If the payee decides to credit the payment to the default crediting account 216 as indicated by the selection of the graphic button 686, the authorization and verification steps indicated by decision block 340 in FIG. 11A are performed. Can be. The decision logic and decision steps that can be made at decision block 340 are shown in more detail in FIG. 15A. As shown in FIG. 15, if the payee initiates processing of the transaction information by selecting a crediting account at step 338, selecting a graphical button 686 on screen 674, or the like, the payment selected by the payer Both the account (e.g. 602) and the crediting account (e.g. 216) selected by the payee are one or more financial servers (e.g. 100) for verification of account information and authorization of the requested transaction as indicated by step 694. Can be sent to. For example, as described above in particular with respect to FIGS. 12A-12C, the one or more financial servers 100 include a bank server, a credit card server, or some combination thereof, depending on the types of accounts provided by the payee and payer. can do.

Referring now to step 696, a determination may be made by the financial servers as to whether the selected payment and crediting accounts are compatible. As noted above, it may occur that the crediting account designated by the payee may not be authorized or configured to accept payments from the payment account selected by the payer. In one example, if the credit account is a bank account that is not authorized to receive payments directly from the credit card account, the payment and credit account may be incompatible. For example, referring back to FIG. 14J, if the selected payment and crediting accounts are determined by the financial servers 100 to be incompatible, a screen 700 showing the notification message 702 may be displayed.

The method shown in FIG. 15A then proceeds to decision step 342, where the payee has the option to renegotiate the payment terms by selecting an alternate crediting account, so the method returns to step 338. For example, renegotiation of payment terms may be performed by selecting graphical button 704 on screen 700 of FIG. 14J. Alternatively, the payee may renegotiate the selection of another payment account by the payer, so the method returns to step 662. Also, in decision step 342, if the payee decides not to renegotiate the payment terms, the payee cancels the transaction as indicated by step 344, such as by selecting a graphical button 706 on the screen 700, or the like. can do.

Returning to decision step 696, if it is determined that the payment and crediting accounts specified by the payer and the recipient are compatible, the method proceeds to decision step 698, where the payment account is valid and sufficient funds to satisfy the requested payment. Determination as to whether or not may be made by one or more financial server 100). If it is determined that the specified payment account is not valid or does not have sufficient funds to meet the requested payment, the method may return to decision step 342, and the payee may cancel the transaction or have sufficient funds in step 344. Options to renegotiate the terms of the transaction, such as by asking the payer to provide another payment account. As will be appreciated, this action may return the method to step 662. Referring back to FIG. 14J, in step 698, if it is determined that the payment account selected by the payer does not have sufficient funds to meet the requested payment, a notification message 708 is displayed on the screen 700. Can be. Thus, screen 700 may include a graphical button 710 that the user may select to return to the payment request screen 484 described above in FIG. 14A. Also, as discussed above, the payee may cancel the transaction by selecting the graphical button 706.

In step 698, if the specified payment and crediting accounts are both valid and the payment account is determined to have sufficient funds, the transaction may be authorized and processed by the financial servers, and the amount specified in the payment request is debited from the payment account. Is filled in and credited to the credit account. For example, as described above in connection with FIG. 12A, if the selected payment credit card account (eg, 602) is verified, the credit card server 382 may authorize that the transaction has been approved for processing as indicated by block 424. The message may be sent to the financial server 380. Then, if the transaction is processed, the payee may receive the payment as indicated at step 346 of the method 328 of FIG. 11A. In addition, in terms of payment, a determination may be made as to whether the transaction was successfully processed and completed in step 368 of the method 360 of FIG. 11B. If the transaction is determined to have failed for any reason, such as those indicated by the notification messages 702 and 708 in FIG. 14J, then in step 370 no charge is made to the payer's account.

Similarly, if it is determined that the transaction has been successfully processed, the amount specified in the payment request in step 372 may be debited to the payer's account, as described above. For example, referring to FIG. 14J, upon successful completion of a transaction, screen 712 may be displayed on recipient device 10. Screen 712 may include a notification message 714 informing the payee that the requested payment amount 680 has been credited to the selected crediting account 216. The notification message 714 may further indicate to the recipient that a payment receipt (eg, 428) for this transaction has been sent or delivered to the payer. As noted above, an electronic form of payment receipt may be emailed to the payer using the email address provided in the payer identification information 678 on the screen 674. Transaction notification screen 712 may further include graphical buttons 716, 718. Graphic button 716 may be selected to initiate a subsequent transaction. For example, by selecting graphical button 716, the payee may return to transaction initiation screen 476 described above in FIG. 14A. In addition, the user may exit the transaction application 34 by selecting the graphical button 718, for example by returning to the home screen 29 of the recipient device 10.

The techniques and screen images associated with the transactions described above in connection with the embodiments shown in FIGS. 12A-C and 14A-J are a payee, such as by sending a payment request (eg, 384) from the device 10, and the like. Although it is particularly dependent on the initiation of the transaction by, in further embodiments it should be appreciated that the payer may also initiate the transaction. For example, referring now to FIGS. 16A and 16B, these figures collectively represent methods in terms of payer and payee, respectively, where a transaction is initiated by a payer and then generally employs the techniques described above. Can be processed by the addressee.

First, referring to FIG. 16A, a method 730 is shown for initiating a transaction from the payer's point of view. The method 730 begins with the selection of a payment method at step 732. As noted above, the selection of the payment method may include selecting a payment account from one or more payment accounts stored on the device, such as the payer device 92. Once the payment account is selected, payment information corresponding to the selected payment account may be delivered or transmitted to the recipient as indicated in step 734. As described above, the transmission of payment information may be via a communication channel established between the payer device 92 and a device belonging to the payee, such as the device 10. In the above-described embodiments, this communication channel may comprise an NFC connection, but may be available on the payee device 10 and the payer device 92 as shown in FIG. 3 by the communication interface 56. It may also include additional communication channels established over other communication interfaces (eg, WAN, LAN, WLAN, PAN, etc.). Subsequently, at decision step 736, a determination is made as to whether the transaction initiated by the payer was completed successfully. For example, as discussed above, successful completion of the transaction may cause payment from the payment account selected in step 732 to be credited to the recipient's selected crediting account. If it is determined that the transaction did not complete successfully, it will not be charged to the payer's payment account, as indicated in step 738.

Returning to step 736, if it is determined that the transaction initiated by the payer has been successfully completed, the method proceeds to step 740 in which the amount that can be specified in the payment information sent in step 734 as described above is selected by the payer. Is charged from the account. Finally, after being charged to the payer's account at step 740, the payer may receive a receipt from the payee as instructed at step 742, which receipt is used as confirmation that the payment sent by the payer has been received. Can be. As mentioned above, in some embodiments, the receipt may be in electronic form and may be received by the payer via an email address.

Referring now to FIG. 16B, a method for processing a transaction in response to a transaction initiated by a payer in method 730 of FIG. 16A is shown and generally referred to by reference numeral 746. The method 746 may begin at step 748 where payment information is received by the payee. For example, the payment information received by the payee at step 748 may correspond to the payment information sent by the payer at step 734 of method 730. The payment information may include, for example, information about the payment account selected by the payer, the payer's identifier, as well as the payment amount sent by the payer. The payment information may be received using a device such as the device 10 described above using, for example, an NFC connection.

Then, at step 750, the payee may select a crediting account to which the received payment will be credited. For example, the crediting account may be selected by the payee from one or more crediting accounts stored in the payee device 10. Once the appropriate crediting account is selected, the payee verifies these accounts and verifies the selected credits from the payment account, including account information that may include both the payment account information sent by the payer and the crediting account information selected in step 750. The account verification process can be initiated by sending to one or more financial servers configured to authorize payment to the account. This account verification and payment authorization process is indicated by decision step 752 in FIG. 16B, in which step both the payment account and the crediting account specified in this transaction are valid, and the payment account is authorized and performing the requested payment. A decision is made as to whether there is sufficient funds in the If at step 752 it is determined, for example, that the transaction cannot be processed for one or more of the reasons described above with respect to FIG. 14J, the method 746 may proceed to decision step 754.

At decision step 754, the payee may have the option to renegotiate the conditions of the transaction. As noted above, this may include the selection of an alternate crediting account or a request for a payer to provide an alternate payment account. Thus, if the payee decides to select an alternate crediting account, the method may return to step 750. Alternatively, if the payee decides to ask the payer to provide an alternate payment account, the method returns to step 748 where the payee can receive payment information, for example, regarding the newly selected alternative payment account. Further, if it is determined in decision step 754 not to renegotiate the condition of the transaction, the recipient may have the option to cancel the transaction, as indicated in step 756.

Returning to decision step 752, if it is determined that both the payment account and the crediting account are valid and payment from the payment account to the crediting account can be authorized, the payee receives the payment sent by the payer in step 758. can do. For example, receiving the payment at step 758 may debit the payment amount as specified in the payment information received at step 748 from the payer's selected payment account and then credit the same amount to the recipient's selected crediting account. And may thus complete the transaction at step 760. In addition, the method 746 may further include transmitting a receipt confirming that the payment sent by the payer has been received by the payee as indicated at step 762. The transmission of the receipt at step 762 may correspond to the receipt received by the payer at step 742 of the method 730 shown in FIG. 16A.

Referring now to FIG. 17A, a plurality of screen images are shown showing the initiation of a transaction on the payer device 92 in accordance with the transaction described by FIGS. 16A and 16B. Payer device 92 may be indicated by icon 34 and may include a transactional application similar to the transactional application described above with reference to payee device 10. Upon execution of a transactional application, the transaction screen 110 described above in FIG. 5A may be displayed on the device 92 as a payment. From transaction home screen 110, a transaction can be initiated via selection of graphical button 114.

Upon selection of graphical button 114, the payer may proceed to screen 476. Screen 476 may display graphical buttons 478, 480, 482 as described above. As shown, the payer can initiate the transfer of the payment by selecting the graphical button 480. The payer may then proceed to screen 770. Screen 770 may include a plurality of text fields, generally indicated at 772, from which the payer may enter information via text keyboard 160. For example, as indicated on screen 770, the payer may enter the payee's identifier 774, the amount of payment 776 sent to the payee, as well as a brief description 778 of the purpose or nature of the payment. Can be. Screen 770 may further include graphical buttons 780, 782. Once information 774, 776, 778 is entered in form fields 772, the user can proceed to screen 786 and select the appropriate payment method by selecting graphical button 780. Alternatively, the user has the option of selecting graphical button 782 to cancel the transaction and thus not sending the payment.

As indicated on screen 786, information regarding the recipient's identifier 774, payment amount 776 sent, as well as a description of payment 778 may be displayed. In addition, screen 786 may further display information regarding the payer's identifier as indicated by reference numeral 788. As noted above, the payer identification information may include both additional identifying attributes such as the payer's name and email address. Selection of the payment method may also be displayed on screen 786. As shown in FIG. 17A, the selected payment method may be initially selected as the default payment method 554 described above with reference to FIG. 14E.

Screen 786 may further include graphical buttons 790, 792, 794. As discussed above, these buttons may correspond to certain functions that may be performed on the payer device 92 upon selection of these buttons. For example, graphical button 790 may represent a function by which a payer can initiate a transaction using default payment account 554 as the selected payment account. Graphic button 792 may represent a function that a payer may direct to one or more screens for selection of an alternative payment method, such as those described above with respect to screen 566 of FIG. 14E. The payer may have the option to cancel the payment by selecting graphical button 794.

Recipient device 10 and payer device 92 may each have configured one or more security features. For example, as described above with respect to FIG. 14H, the payer device 92 may require input of a previously stored authorization PIN code before the transfer of payment can be authorized. For example, as shown in FIG. 17A, upon selection of graphical button 790, the payer may proceed to screen 620 described above in FIG. 14H. Screen 620 includes a prompt 622 that instructs the user to enter an authorization PIN code 624 in text field 626 using numeric keyboard interface 164. In addition, as described above, the user can select the graphical button 166 to toggle between the numeric keyboard interface 164 and the text input keyboard interface 162 (not shown in FIG. 17A). For example, this feature can be implemented in embodiments where the device 92 supports alphanumeric PIN codes including both text and numbers.

Once the authorization PIN code 624 is entered, the payer can proceed to send the payment information entered from the screen 786 to the payee. For example, as described above with respect to FIG. 14I, the transmission of payment information may be accomplished via an NFC connection established between the payer device 92 and the payee device 10 via a tap operation 412. Thus, when the payer device 92 and the payee device 10 are tapped and placed within a distance (eg, 2-4 cm) that can support an NFC connection between these devices, the payment information displayed on the screen 786 Can be transmitted to the recipient device 10 through the NFC connection is set.

Referring now to FIG. 17B, when payment information is received by the payee device 10, a screen 800 may be displayed on the payee device 10. Screen 800 may include a notification message 802 informing the payee that an offer has been received for payment of the amount specified by the payer on screen 770 of FIG. 17A. Screen 800 may further include graphical buttons 804, 806. By selecting the graphical button 804, the payee can proceed to the screen 674 as described above in FIG. 14J. The screen 674 is entered by the payer within the screen 770, such as the payee's identifier 774, the payment amount 776 sent and the payment method selected by the payer, in this example the default payment account 554. Information can be displayed. Screen 674 may include the payer's email and may further include the payer's identification information 788, which may be used to send a receipt to the payer if the transaction was successfully completed. Screen 674 may further display the currently selected crediting account for which payment is credited. As shown, the selected crediting account is initially the default account 216 configured in FIG. 8. To process a transaction based on these settings, the payee may select graphical button 686. As described above, the selection of the graphical button 686 is a process in which the amount 776 is debited into the payment account 554 selected by the payer, which is then credited to the selected crediting account 216. May be disclosed. This process may include verification and authorization of a transaction by one or more financial servers 100, such as those described above in FIGS. 12A-C.

Depending on whether the transaction is successful, the screens 700 or 712 described above in FIG. 14J may be displayed on the recipient device 10. For example, if the transaction fails for one or more reasons, screen 700 may be displayed. Screen 700 may include a notification message 708 informing the recipient of the reason or reasons for the failure of the transaction. In addition, the screen 700 may provide the recipient with the option to return to the screen 484 via the graphical button 710 or the like, as well as the option to cancel the transaction through the selection of the graphical button 706. If the transaction completed successfully, a screen displaying a notification message 714 notifying the payee that the transaction was successfully completed and that the payment amount 776 specified by the payer has been credited for the selected crediting account 216 ( 712 may be displayed on the recipient device 10. The notification message 714 can further inform the payee that the receipt has been sent to the payer.

While all of the foregoing embodiments describe transactions involving the use of monetary means such as credit cards and bank accounts, the techniques described herein describe non-monetary and non-cash accounts (e.g., 126, 604) described above. It should be understood that other types of accounts representing ownership of certain types of exchange media may be applied. For example, a non-cash account may be an account associated with an online music merchant service, such as an iTunes account, available through the iTunes Online Digital Media Store / Service operated and managed by Apple.

The iTunes account can be exchanged from an Internet-based online virtual store for the purchase of music files (eg mp3, m4a) as well as other related types of media such as podcasts, music videos, audio books, game applications, movies, etc. It can be operated based on the available credits. At the time of purchase, these media products may be stored on storage device 54 or the like on device 10 for later viewing or listening to a user. Credits associated with an iTunes account may not have monetary value in the real world, but these credits may be used as a non-cash vehicle of exchange associated with products and services offered through the iTunes service. In addition, according to aspects of the present invention, credits held by iTunes accounts may be exchanged between account holders through the transactional techniques described above.

Prior to continuing this description, the use of iTunes services provided by Apple is described by way of example only, and according to the present invention the techniques described herein may be applied to non-cash accounts provided by multiple online merchants, It should be understood that the non-cash mediator of the exchange (eg, "credits") may be stored in these accounts and exchanged for the products or services offered by each online seller.

Referring now to FIG. 18, the transaction techniques shown in FIGS. 17A and 17B are now described with respect to iTunes accounts owned by the payee and payer. Specifically, FIG. 18 is a transaction where payment is initially sent from the payer device 92 to the payee device 10, and the payment information 810 sent to the payee designates an iTunes account belonging to the payer as the selected paying account. A schematic diagram of 808 is shown. Payment information 810 may further indicate the amount or number of credits the payer wishes to deliver to the payee as payment. In order to transfer the iTunes account information to the payee device 10, a tap operation 814 is performed between the payee device 10 and the payer device 92 so that the payment information 810 can be transferred to an NFC connection ( 812 may be set.

After receiving payment information 810 on payee device 10, the payee may select the appropriate crediting account for which the payment indicated by payment information 810 is to be credited. For example, in the scenario shown, the selected crediting account may be each iTunes account belonging to the payee. Thus, the payment amount (eg, credits) specified in the payment information 810, as well as the payee and payer's iTunes account information, may be collectively represented by transaction information block 816. Transaction information 816 may then be sent by the payee device 10 to one or more financial servers 100 for further processing of transaction 808 as described above.

As shown in FIG. 18, one or more financial servers 100 in this embodiment may be represented by iTunes server 818 configured to maintain respective iTunes accounts belonging to the payer and the payee. As mentioned above, specifically referring to transaction 378 shown in FIG. 12C, for the authorization and processing of a transaction (eg, another entity) when both the payment account and the crediting account are maintained by the same entity or financial institution. Or there may be no need to communicate with additional external servers belonging to a financial institution.

The transfer of transaction information 816 to iTunes server 818 may be provided by any suitable networking interface available on recipient device 10, such as those specified by communication interface block 56 in FIG. 3. This may be through the network 820. Upon receipt of transaction information 816, iTunes server 818 performs one or more verification actions, as indicated by reference number 822, such that both iTunes accounts are valid and the payer's iTunes account is in payment information 810. It may be verified whether there are at least enough credits to meet the specified payment amount. If both iTunes accounts are valid and it is determined that the payer's iTunes account has enough credits, the transaction can be processed as indicated at 824. The iTunes server 818 may then send a confirmation message to the payee device 10 via the network 820 informing the payee that the payment has been credited to the payee's iTunes account. Further, as indicated by reference number 826, upon receipt of confirmation, the recipient device 10 (or iTunes server 818) debits or charges the payer's iTunes account the amount specified by the payment information 810. A receipt, such as an electronic receipt confirming that the payment has been made, may be further configured to send to the payer device 92 using the payer's email address and thus terminate the transaction 808. Transactions 808 described above may be better understood with reference to FIGS. 19A-19D, in which a plurality of images representing transactions 808 shown in FIG. 18A are shown.

First, starting from FIG. 19A, it should be noted that these screens are generally the same as those described above with respect to FIG. 17A. For example, starting from screen 110, the payer can initiate a transaction process by pressing graphical button 114. The screen 476 may then be displayed, where the payer further selects the graphical button 480 to allow the transaction to initiate a request from the payee directly via the transfer of the payment (eg, as described above in FIGS. 12A-12C). Without having to wait first). Upon selection of graphical button 480, the payer proceeds to screen 770 where form fields 772 can be completed using text keyboard interface 160. Then, by selection of graphical button 780, the user further proceeds to screen 786 to display payee identification information 774, payment amount 776, as well as a brief description 778 of the nature of the payment. can do. In addition, screen 786 may further include identification information 788 about the payer, as well as display the currently selected payment method. As shown, the payment method may initially be selected as the default payment account 554. Then, as described above in FIG. 17A, rather than selecting the graphical button 790 to initiate payment using the default payment account 554, the payer selects the graphical button 792, and in FIG. 18. The described iTunes account can be selected as the default payment method.

Note that the reason for the current payment specified 778 may represent the cash or monetary amount of the debt that the payer is required to pay to the payee, and may not need to be associated with one or more of the services offered through the iTunes service. Should be. However, the figures show how an agreement can be reached between the payer and the payee to satisfy the debt using non-cash assets, in this example iTunes credits.

Referring to FIG. 19B, upon selection of graphical button 792, the payer may proceed to screen 566 described above with respect to FIG. 14E. As mentioned above, screen 566 may display a plurality of graphical buttons 570, 572, 574, 576, 578, each corresponding to a payment category that may be selected by the payer. As shown in FIG. 19B, the payer may select graphical button 574 to proceed to screen 828. Screen 828 may display a list 604 of all iTunes accounts currently stored on payer device 92. Thus, the payer can select the desired iTunes account 830 for use as a payment account in the current transaction 808.

Upon selection of iTunes account 830, the payer may return to screen 786 of FIG. 19B, which may be updated to reflect the selected iTunes account 830 as a payment method. The payer can then select graphical button 832 to proceed to screen 620. As noted above, payer device 92 may include one or more security features that require an authorization PIN code to be provided prior to transmitting payment information from payer device 92. For example, as shown on screen 620, the payer may be required to enter authorization PIN 624 in text field 626. Once the authorization PIN code 624 is entered (eg, via the numeric keyboard interface 164), the payer may authorize the transfer of the iTunes account information 830 by selecting the graphical button 628.

Referring now to FIG. 19C, the screens shown represent screen images that may be displayed on the recipient device 10 upon receipt of iTunes payment account information 830. As described above, the receipt of payment information 830 may be performed by establishing an NFC connection via tap operation 814, as shown in FIG. 18. Upon receipt of payment information 830, a notification screen 800 may be displayed on payee device 10. Screen 800 may include a notification message 802 informing the payee that payment of the amount indicated by reference numeral 776 has been received from payer 788. Screen 800 may further display graphical button 804 where the user can proceed further steps to complete processing of the transaction and graphical button 806 that the user can select to cancel the current transaction.

For example, by selecting graphical button 804, the user can proceed to screen 674 as described above in FIG. 14J. Screen 674 may display the payee's identifier 774, the payer's identifier 788, the amount of payment requested 776 and the selected payment method, i.e., iTunes account 830. As will be appreciated, the requested payment amount may be translated into “credits” stored in the payer's iTunes account 830. As shown in screen 674 of FIG. 19C, the crediting account may initially be selected as the default crediting account 216. Here, the payee may select the graphical button 686 to select an alternate crediting account by selecting the graphical button 688 rather than crediting the payment to the default crediting account 216.

Upon selection of graphical button 688, the payee can navigate to screen 836, which screen except that the functions provided by screen 836 relate to the selection of a crediting account rather than a payment account. It may be similar to screen 566 described above at 19B. Screen 836 may include a prompt 838 instructing the recipient to select one of the following credit account categories represented by graphical buttons 840, 842, 844, 846, 848. In order to select a compatible account (iTunes account in this example) for receiving payments sent by the payer, the user may select graphical button 844 and proceed to screen 850. Screen 850 may include a list of all iTunes accounts stored on payee device 10. Thus, the payee may select iTunes account 852 as the crediting account of the current transaction 808.

Following selection of the iTunes account 852, the payee may return to screen 674. As shown in FIG. 19D, the updated screen 674 may display the iTunes account 852 as the selected crediting account. Also, graphical button 686 may be replaced with graphical button 854 on updated screen 674. Upon selection of graphical button 854, as described above, the process of transmitting transaction information 816, which may include information regarding the selected payment account 830 as well as the selected crediting account 852, is illustrated in FIG. 19A. And to the iTunes server 818 for processing of the payment initiated by the payer at 19B. If the transaction fails to complete for one or more reasons, the screen 700 may be displayed on the recipient device 10. Screen 700 may notify the recipient of the reason or reasons why the transaction failed. For example, in the illustrated embodiment, the notification message 708 can inform the payee that there are not enough credits in the payer's iTunes account 830 to satisfy the payment amount 776. Alternatively, once the transaction completes successfully, screen 712 may be displayed on recipient device 10. Screen 712 may include a notification message 714 that notifies the payee that the credits from the payer's iTunes account 830 have been credited to the payee's iTunes account 852. Notification message 714 may inform the payee that a receipt associated with the completed transaction has been provided to the payer.

In further implementations of the present technology, the payment amount may be credited directly to the iTunes gift card. For example, the account number associated with the gift card can be maintained by the iTunes server 818. Upon receipt and authorization of the transaction information 816, the iTunes server 818 may credit the recipient's iTunes gift card account, which may be in the form of an iTunes credit. Thus, the recipient can use the gift card to add additional gift credits to the recipient's iTunes account and / or purchase downloadable media content such as music files, movie files, audio books, podcasts, etc. as credits stored on the gift card. Can be.

Although the above embodiments have been described in connection with the processing of transactions between two electronic devices, such as the payee device 10 and the payer device 92, additional implementations of the presently described techniques provide that the payee device 10 is a payer. It may further include transactions for receiving payment information from sources other than a portable or non-portable electronic device of the type generally represented by device 92. For example, referring now to FIG. 20, there is shown a schematic diagram of a transaction 860 in which payment is made to the recipient device 10 via a smart card, indicated at 862. Smart card 862 may be similar to a conventional credit card, but may further include a storage device, such as secure storage chip 864. The storage chip 864 may be configured to store information regarding a credit card account or banking account (eg, when the smart card 862 is a debit card) represented by information printed on the smart card 862. . For example, storage chip 864 may include an account number corresponding to a smart card, the name of the account holder, an expiration associated with the smart card account, and any other relevant information associated with the payer's smart card account.

In the illustrated embodiment, the storage chip 864 may communicate with an external device, such as the recipient device 10, via an NFC connection established, for example, via magnetic field induction using an RF signal. As those skilled in the art will understand, smart cards can be distinguished from the electronic devices described above (eg, payee device 10, payer device 92), because smart card 862 is an electronic component. That is, the storage card 864, but the smart card 862 does not include a power supply or processing device that may generally be associated with electronic devices. Instead, the smart card 862 relies on a built-in inductor to obtain an RF signal that can be transmitted from the recipient device 10 via the NFC device 46 or the like, thus using the RF signal to the storage chip 864. Power may be temporarily supplied to the electronic components of, to transmit data stored therein to the receiving device. As will be appreciated by those skilled in the art, the transmission of information from a smart card may be in accordance with the NFC technology described above, as well as other known standards such as ISO / IEC 14443 and ISO 15693.

As shown in FIG. 20, transaction 860 may be initiated by a payment request 384. Upon initiation of the payment request 384, the NFC device 46 of the recipient device 10 may be powered on to drive the NFC interface 60 and provide an RF signal. Thus, NFC connection 388 may be established by tapping the activated recipient device 10 on the smart card 862. The smart card 862 utilizes a portion of this signal upon detection of the RF signal emitted from the recipient device 10 to establish information such as smart card information indicated by reference number 866 through tap operation 386. The storage chip 864 may be directed to transmit to the recipient device via the connection 388. In some embodiments, the RF signal can be rectified by the smart card 862.

Recipient device 10 provides an amount to be charged to smart card 862 to the payer who is the account holder upon receipt of smart card information 866, and in some embodiments additionally, such as to provide one or more security verification actions. It may further be required to provide verification information. For example, one such security verification action may require the payer to provide a card verification value CVV corresponding to the smart card 862. The CVV values may not be transmitted from the storage chip 864 or stored on the storage chip 864 itself, but may be printed on the smart card 862. Thus, as will be appreciated, these additional security verification procedures may prevent unauthorized payment initiation from the smart card 862.

In addition to smart card account information, payment amount, and security information described above (eg, CVV code), the payee may generally select the appropriate crediting account on the payee device 10 as described above. This information, then collectively referred to as transaction information and represented by block 868, may be sent to one or more financial servers 100. In detail, the transaction information 868 may be transmitted to the financial server 380 through the network 870. The financial server 380 may correspond to a financial institution that owns or maintains a crediting account selected by the payee. The network 870 over which the transaction information is transmitted may include any of the suitable networks described above, such as those provided by the communication interfaces 56 of the recipient device 10.

Upon receipt of the transaction information 868, the financial server 380 is the payer's smart card account information directed to block 872 via the network 876, which may be provided by any suitable network, such as a LAN, WAN, or WLAN. May be further sent to the smart card server 874. Smart card server 874 may be associated with a credit card provider that maintains an account corresponding to smart card 862. Smart card server 874 may perform one or more verification and / or authorization processes, as indicated by reference number 878, where the payer's smart card account 872 is verified, for example, of validity and sufficient funds. . Thus, if it is determined that the payer's smart card account 872 is valid and has sufficient funds to complete the requested payment 384, the smart card server 874 finances the authorization message via the network 876. Send to server 380.

Upon receipt of the authorization message, the financial server 380 may complete the transaction, such that the payer's smart card account 872 is charged an amount corresponding to the requested payment 384 and the recipient's selected crediting account. The credit shall be written in the credit. If the transaction 860 is successfully processed, a confirmation message 882 may be sent from the financial server 380 to the recipient device 10. Further, as indicated by reference number 882, one of the one or more financial servers 100, such as financial server 380 or smart card server 874, pays a receipt confirming that the smart card account 872 has been charged. Can be sent to. In one embodiment, one of the one or more financial servers 100 may send an electronic receipt by email associated with the smart card account 872.

When applied to the method 328 shown in FIG. 11A, the processing of the transaction 860 between the payee device 10 and the smart card 862 may be further understood with reference to FIG. 21A. Specifically, FIG. 21A shows in more detail certain steps of the method 328 as applied to this embodiment. For example, sending 334 an invoice to the payer may include providing a physical or verbal request for payment as indicated at 888 in this embodiment. For example, the payee and payer can negotiate with each other about the terms of the payment before the smart card information 866 is sent to the payee device. Once the terms of payment have been negotiated, the step of obtaining payment information from the payer may include the smart card account information 866 stored in the storage chip 864, which may be sent to the payee device 10 as indicated in step 890. Initiating an NFC connection between the device 10 and the smart card 862. For example, this step may correspond to the establishment of NFC connection 388 via tap operation 386 as described above in FIG. 20.

Once the smart card information 866 is sent from the storage chip 864 of the smart card 862, this information can be received by the recipient device 10 using the NFC connection 388 as indicated in step 892. have. Upon receipt of the smart card information 866, a crediting account may be selected on the recipient device 10 in step 338. Subsequently, at decision step 340, the selected crediting account information, as well as the smart card account information 866, may be sent to one or more financial servers 100 for verification and processing, as indicated by step 894. The process of verifying the smart card account 872 and the crediting account may include decision steps 896 and 898. For example, the determining step 896 may include determining whether the smart card account and the selected crediting account are compatible. As mentioned above, in this context, the term "compatible" indicates whether the crediting account is configured to receive credit card payments from the smart card account. If it is determined in step 896 that the smart card account and the selected crediting account are compatible, the method 328 may proceed to decision step 898 where the smart card account 872 provided by the payer is valid and requested. It is further determined whether they have enough funds (eg, credit lines) to meet the payment 384 made. If it is determined that the smart card account is valid and has sufficient funds, the transaction is processed so that the payee receives the payment at step 346 of method 328, and then transaction 860 is completed at step 348.

Returning to decision steps 896 and 898, if it is determined that the accounts are not compatible, the smart card account is not valid, or lacks sufficient funds to fulfill the requested payment, the method may proceed to decision step 342, where The payee may decide whether to renegotiate the terms of payment. If the payee does not want to renegotiate the terms of payment, the transaction may be canceled at step 344. Alternatively, if the payee decides to change the payment terms, the payee obtains information from another smart card belonging to the payer, and thus the method may return to step 892, or the payee may open an alternate crediting account at step 338. You can choose. As will be appreciated, the renegotiation of payment terms may depend on the results of the decisions made in steps 896 and 898. Also, although not shown in FIG. 21A, the renegotiation of payment terms in step 342 is a transaction in which payment information is stored in an electronic device, such as the payer device 92 described above in FIGS. 12A-C, and transmitted to the recipient device 10. It may also include performing.

Referring now to FIG. 21B, certain steps of method 360 are described in more detail from the payer's point of view in accordance with transaction 860 described above in FIG. 20. Specifically, FIG. 21B illustrates in more detail step 364 of receiving a payment request from the payee and providing payment information to the payee 366. Receiving a payment request 364 may include receiving a physical request for payment as indicated by step 900. As discussed above, the physical request may include mutual consultation between the payee and the payer regarding the terms of the payment to be made using the smart card 862. The payer may then accept this condition at step 902 if the payment conditions are met. In step 904, the payer may place the smart card 862 within range of the payee device, which may include the NFC device 46. Thus, when the recipient device powers on the NFC device 46 to enter active mode, the information stored in the storage chip 864, which may include smart card account information 866, is set via the wrap operation 386. It may be transmitted from the smart card 862 to the recipient device 10 via the NFC connection 388. The method 360 may then proceed to decision step 368, as well as the remaining steps of the method sufficiently shown in FIG. 11B.

Referring now to FIGS. 22A-C, a plurality of screen images are shown illustrating the operation of the recipient device 10 performing the transaction described in FIG. 20. First, referring to FIG. 22A, the process of initiating a transaction can begin by selecting the graphical button 114 displayed on the screen 110. As discussed above, screen 110 may represent a home screen for a transactional application (eg, represented by icon 34 on home screen 29 of payee device 10). By selecting the graphical button 114, the recipient can proceed to the screen 476 as described above in FIG. 14A, which can display the graphical buttons 478, 480, 482. To initiate a payment request, the user may select graphical button 478 and proceed to screen 484. As described above in FIG. 14A, screen 484 may display a plurality of graphical buttons 486, 488, 490, each of which differs from the different techniques of payee device 10 for initiating a request for payment and Indicates the functions. For example, as described above, graphical button 486 may represent a function for requesting payment in accordance with the transactions described above in FIGS. 12A-C. In this case, the payee may select the graphical button 488 to indicate that the payment request will be directed to a transaction involving at least one smart card 862.

Upon selection of graphical button 488, the recipient may proceed to screen 910. Screen 910 notifies the recipient that the owner (eg, payer) of smart card 862 must perform at least one security verification action, such as providing a CVV code, to complete the transaction. Message 912. Screen 910 may further display graphical buttons 914 and 916. Graphic button 914 initiates a payment request by powering on NFC device 46. FIG. The payee also has the option to cancel the payment request by selecting the graphic button 916. Upon selection of the graphic button 914, the NFC device 46 of the payee device 10 is powered up. Can be turned on, and thus the NFC interface 60 can be enabled, thus, the screen 910 can be updated to display a notification message 918, which notification message is generally presently active. That notifies the user status, and also instruct the user to tap the smart card 862 of the payer to the payee device (10).

Referring now to FIG. 22B, the establishment of an NFC connection between the recipient device 10 and the smart card 862 via the tap action 386 shown in FIG. 20 is shown. As discussed above, powering on the NFC device 46 may cause the recipient device to be in host or active mode 392. As the active device 10 is placed within an acceptable distance, indicated by the distance 514, from the smart card 862, which may be in passive mode 390, an NFC connection between the recipient device 10 and the smart card 862 may be established. 388) can be set. Thus, a storage chip 864 capable of storing smart card account information may be temporarily powered by magnetic field induction to transmit smart card information to the recipient device 10 over the established NFC connection 388. Referring now again to FIG. 22A, the transmission of smart card account information 866 from the storage chip 864 is an updated notification generally instructing the recipient that smart card information is being received by the recipient device 10. It may be displayed in screen 910 that includes message 920.

Once the smart card account information 866 is sent to the payee device 10, the screen 924 may be displayed. Screen 924 may display, for example, the account holder's identifier 928, account number 930, as well as smart card account information 866 including expiration associated with account 932. Screen 924 may further display the currently selected crediting account that may initially display default crediting account 216 as described above with respect to FIG. 8. In addition, screen 924 may include graphical buttons 686, 688, 690 described above with reference to FIG. 14J. By selecting the graphical button 686, the payee can proceed to a screen 936 that can indicate one or more of the security verification actions required by the payer as described above.

As indicated on screen 936, text fields 938, 940, 942 are provided that may require the payer to enter the requested data. For example, the payer may be required to enter a payment amount in text field 938. As discussed above, payment amounts may be negotiated with one another between the payee and the payer at step 888 of FIG. 21A. The payer may be further required to enter the CVV code on the smart card into the text field 940. As mentioned above, this step may constitute additional security measures, and thus authorization from smart card 862, such as when smart card account information 866 stored in storage chip 864 is obtained without the consent of the payer. Prevent the initiation of unpaid payments. The payer may be further provided with an option to enter an email address in text field 942. For example, the email address may be used to provide an electronic receipt to the payer if the transaction 860 completes successfully after being sent to one or more financial servers 100. As indicated on screen 936, the payer may enter the aforementioned data into text fields 938, 940, 942 via text keyboard 160. In addition, for fields requiring numerical input, the payer may access the numeric keyboard 164 (not shown in FIG. 22C) by selecting the graphical button 162 as described above.

Once the information is entered in the text fields 938, 940, 942, the recipient can initiate the processing of the transaction by selecting the graphical button 944. Alternatively, the payee may have the option to cancel the transaction by selecting graphical button 946. Subsequently, if the transaction was not successfully processed for one or more reasons, the screen 700 may be displayed on the recipient device 10. Screen 700 may display a notification message 948 informing the recipient about the reason or reasons for the failure of the transaction. As shown in FIG. 22C, the notification message 948 may indicate that the CVV code provided in the text field 940 of the screen 936 is incorrect and therefore the requested payment cannot be authorized. If the transaction is processed successfully, the screen 712 may be displayed on the recipient device 10. As described above in FIG. 14J, the screen 712 may display a notification message 714 that generally informs the user that a payment of the amount specified in the text field 938 has been applied to the selected crediting account 216. The notification message 714 may further inform the payee that the receipt has been provided to the payer via an email address or the like specified in the text field 942 of the screen 936.

Referring now to FIGS. 23 and 24, transactions 952 and 970 according to further aspects of the present invention are shown, respectively. Specifically, transactions 952 and 970 may represent the functionality provided by graphical button 490 displayed on screen 484 as described above with respect to FIG. 14A. For example, as described in more detail below, the transactions shown in FIGS. 23 and 24 may be used by the camera 48 on the payee device 10 to obtain an image of a payment means, such as a payer's magnetic credit card or check. Can depend on

Referring now to FIG. 23, transaction 952 may be initiated through acquisition of an image of the payer's credit card 954. For example, a payment request may be generated by consultation between the payee and the payer, and the payer agrees to fulfill the requested payment using credit card 954. Thus, the payee can power on or drive the camera device 48 on the payee device 10 to acquire an image 956 of the payer's credit card 954. Upon receipt of the image 956, the recipient device 10 processes the image 956 using optical character recognition (OCR) technology or the like as described above, and the credit card 954 as indicated by reference numeral 958. Credit card account information corresponding to "

Once the credit card account information corresponding to the credit card 954 is determined by an imaging application or the like adapted to execute the OCR process, the recipient can select the appropriate credit account. Subsequently, additional data such as crediting account information, extracted credit card account information 958, as well as the total amount of the requested payment, are collectively referred to by reference numeral 960, is described above via the network 416. ) May be sent. As noted above, the financial server 380 may correspond to a banking provider that maintains the recipient's selected crediting account. The financial server 380 may include transmitting the payer's credit card account information, indicated by reference numeral 962, to the external credit card server 382 via the network 420, as described above with respect to FIG. 12A, for example. One or more of the permission actions may be initiated. The credit card server 382 may correspond to a credit card provider holding a payer's credit card account 962. The credit card server 382 may process the credit card account information 962 to determine if the provided credit card account is a valid account with sufficient credit lines to fulfill the requested payment as indicated by reference numeral 964. .

If the credit card server 382 determines that the charge of the amount corresponding to the requested payment can be granted for the specified credit card account 962, the credit card server 382 sends an authorization message via the network 420. May be sent to the financial server 380. Upon authorization from the credit card server 382, the financial server may process transaction 952 as generally indicated at 966. As noted above, the processing of transaction 952 may include billing the credit card account 962 the amount specified in the payment request and depositing or crediting the corresponding amount in the recipient's selected crediting account. Once transaction 952 is complete, a confirmation message may be sent to recipient device 10 via network 416. In addition, when the payer's email address is known or provided, an electronic receipt confirming receipt of the payment may be sent to the payer.

The transactional techniques described above in connection with the acquisition of an image 956 representing the payer's credit card 954 can also be applied to other types of payment means, such as a check corresponding to a check account owned by the payer. For example, referring to FIG. 24, a transaction 970 is shown in which payment information is obtained using a camera device 48 for acquiring an image 974 of a check 972 provided by a payer in response to a payment request. It is. When the image 974 is received by the payee device 10, the check image 974 is processed as described above to route from the check image 974 to the payer's name or identifier, the payer's banking provider. Predetermined information such as the number, the account number corresponding to the payer's bank account, as well as the identification number corresponding to the payer's check 972 may be extracted. Once the above information is extracted from the check image 974, the payee can select an appropriate crediting account for receiving the requested payment. Subsequently, the information extracted from the check image 974 collectively referred to by reference numeral 980, the selected crediting account, as well as the total amount of the requested payment, is sent to the financial server 380 via the network 416 as described above. Can be sent.

The financial server 380 may include transmitting check information of the payer, such as check information extracted during the image processing step 976, via the network 420 to the check verification service indicated at 984. One or more of the permission actions may be initiated. As will be appreciated, the check verification service may perform one or more of various functions related to the verification or verification of checks. For example, a check verification service may provide such services to banking providers, sellers, and retailers using a telephone or through a subscription based service that is generally accessible by one or more of the aforementioned networks. In some examples, check verification services described herein may be offered or provided by the banking provider itself. In general, check verification services, such as check verification service 984, may perform various functions that may include verifying the payer's identifier, as well as determining whether the payer has a history of providing a default check. Can be. Based on these records, the check verification service 984 can determine whether the provided check information 982 can be verified to be authorized to meet the payment to be requested. This verification process is indicated by reference numeral 986.

If the check verification service 984 determines that the requested payment can be made using the check information 982, the check verification service 984 sends an authorization message to the financial server 380 via the network 420. Can transmit Upon receipt of the authorization message, the financial server 380 may process the transaction as indicated by reference number 988, such that the bank account corresponding to the payer's check 972 is debited by the requested payment amount, The debited amount is also credited to the recipient's crediting account. Upon completion of the transaction, a confirmation message may be sent from the financial server 380 to the recipient's device 10 via the network 416, as indicated by reference numeral 990. In addition, if the payer provided an email address, an electronic receipt may be sent to the payer as described above.

The various steps of transactions 952 and 970 shown in FIGS. 23 and 24 may correspond to one or more of the steps described in each of methods 328 and 360 of FIGS. 11A and 11B. For example, acquisition of image 956 and image 974 may correspond to step 336 of obtaining payment information from the payer. In addition, accepting the payment request and providing the credit card 954 or check 972 may correspond to step 366 of providing payment information to the payee as shown in method 360. Referring now to FIGS. 25A and 25B, steps 336 and 366 highlighted above in accordance with the presently illustrated embodiment are shown in more detail.

Referring to FIG. 25A, step 334 of sending or providing an invoice to the payer that may indicate a payment request may include providing 888 a physical request for payment. For example, as described above in connection with FIG. 21A, step 888 includes mutual consultation between the payee and the payer on terms of payment before the credit card 954 or check 972 is provided by the payer for image acquisition. can do. Subsequently, step 336 of method 328 may include steps 994 and 996 when performed in accordance with the presently illustrated embodiment. As shown in the figure, step 994 may correspond to starting camera device 48 for acquisition of an image.

Subsequently, in step 996, an image may be acquired using the started camera device 48, and payment information may be obtained from the credit card 958 shown in FIG. 23, the check 972 shown in FIG. 24, or an image thereof. It can reflect an image of any other type of payment means that can be extracted. Once the image is acquired in step 996, payment information may be extracted from the acquired image as indicated in step 998. The payee can then select the appropriate crediting account at step 338 and proceed to decision step 340 for authorization of the requested transaction. As shown in this figure, the determining step 340 may include steps 694, 696, 698 as described above with respect to FIG. 21A when performed in accordance with the presently illustrated embodiment. Thus, it should be understood that the transaction permission steps that may be performed in connection with transactions 952 and 970 may generally be substantially the same as the permission steps described in the foregoing embodiments.

Referring now to FIG. 25B, steps 364 and 366 of the method 360 are shown in greater detail when performed in accordance with the presently shown embodiment from the point of view of the payer. For example, repairing a payment request from a payer as indicated by reference numeral 364 may include receiving a physical request for payment 900. As noted above, the physical request may include mutual agreement between the payee and payer regarding the terms of payment to be made from credit card 954 or check 972. Subsequently, providing payment information to the recipient as indicated by reference numeral 366 may include steps 902, 999, 1000. For example, as discussed above, if the terms of the requested payment are negotiated, the payer may accept the payment request at step 902. The payer may then select a payment method that may include a credit card 954, a check 972, or any other type of appropriate payment method. Once the desired payment method is selected, the payer can provide the selected payment method to the recipient device 10 for image acquisition by the camera 48.

23 and 24 may now be described in more detail with reference to FIGS. 26A-26D and 27A-27G, which are transactions 952 or as shown in FIGS. 23 and 24, respectively. Various screen images may be depicted that represent techniques for manipulating the recipient device 10 to perform 970. Specifically, the screen images shown in FIGS. 26A-26D may indicate acquisition of an image corresponding to credit card 954 of FIG. 23 and subsequent processing of a transaction using the acquired image. 27A-27G may represent acquisition of an image corresponding to check 972 of FIG. 24 and subsequent processing of transaction 970 generally in terms of payee device 10.

Referring now to FIG. 26A, initiation of the transaction 952 described in FIG. 23 may include navigating through the screens 110, 476, 484 described above. For example, starting from screen 110, the payee can navigate to screen 476 by selecting graphical button 114. The payee can then navigate further to screen 484 by selecting graphical button 478 from screen 476. Screen 484 may include graphical buttons 486, 488, 490 described above. As mentioned above, each of the graphical buttons may represent various functions provided by the device 10 to initiate a request for payment. For example, graphical button 486 may represent a function for initiating a payment request in accordance with the techniques described above with respect to FIGS. 12A-12C. Graphic button 488 may represent a function of initiating a payment request in accordance with the transaction techniques described above with respect to FIG. 20. Here, the payee may initiate a transaction in accordance with the techniques described above with respect to FIGS. 23 and 24 by selecting graphical button 490. Upon selection of graphical button 490, the payee can provide the payee with one or more options shown as graphical buttons 1004 and 1006 to obtain payment information using the image recognition techniques described above. You can proceed. As shown, graphical button 1004 may represent a function by which a payee can acquire an image of a credit or debit card as shown in transaction 952. Graphic button 1006 may also correspond to the function of acquiring an image of a check, such as check 972, as described in more detail below with respect to FIGS. 27A-27G.

Upon selection of graphics button 1004, camera device 48 of recipient device 10 may be powered on and started up for image acquisition. The recipient can also proceed to the screen 1008, which can serve as a viewfinder, indicated by reference numeral 1009, as shown in FIG. 26A, to display in real time the images detected by the camera 48. The viewfinder 1009 may include acquisition frames 1010 that may be used to provide the recipient with a means for centering the acquired image. As discussed above, once the terms of the payment request are negotiated, the payer may provide a credit card (eg, 954) to the recipient device 10 for acquisition of the image by the camera device 48. For example, as shown in this figure, the recipient may place the recipient device 10 such that the credit card 954 aligns with the image acquisition frame 1010 when viewed by the camera device 48. Once the credit card 954 is aligned, the recipient can acquire the image of the credit card 1018 by selecting the graphic button 1014. The payee may also have the option to cancel the image acquisition process by selecting graphic button 1016.

Once the image of the credit card 952 is acquired, the screen 1008 can be updated to display the acquired image referred to by reference number 1018. Thus, the recipient can review the acquired image 1018 to determine whether the quality of the acquired image generally meets the standards required for valid image processing. For example, the recipient can determine whether the acquired image 1018 is properly aligned with the acquisition frame 1010, whether the image 1018 is properly focused, or whether the image 1018 has been acquired under sufficient illumination. If the payee determines that the acquired image 1018 is suitable for image processing for extracting payment information from the card 954, the user can initiate the credit card information extraction process by selecting the graphic button 1020. If the recipient determines that the acquired image 1018 does not have sufficient quality for image processing, the recipient selects the graphics button 1022 to view the viewfinder 1009 for acquisition of subsequent images of the credit card 954. Can be returned.

Referring now to FIG. 26B, the processing of the credit card image 1018 can be briefly described. As mentioned above, the processing of images acquired by the camera device 48 of the recipient device 10 may utilize one or more optical character recognition techniques to extract text data from the acquired image. Further, in some embodiments, image recognition techniques may further provide for the recognition of certain images or graphics in the resulting acquired image. For example, such an image processing application may provide recognition of brand logos or symbols that may identify, for example, the corresponding credit card provider or banking provider.

As shown in FIG. 26B, according to the presently described embodiment, the image recognition application may analyze the image 1018 to determine one or more regions of interest. For example, based on the analysis of the image 1018, the image recognition application may identify areas 1030, 1032, 1034, 1036 that are areas of interest that may include account information regarding the credit card 954. . For example, area 1030 may correspond to an identifier of a credit card provider. Region 1032 may provide a credit card account number associated with the selected credit card 954. Also, area 1034 may correspond to expiration associated with credit card 954 provided, and area 1036 may correspond to an identifier of the payer and / or owner of credit card 954.

As will be appreciated, the accuracy of the image processing and recognition application may generally depend on the quality of the processed image, such as image 1018. As shown in FIG. 26B, reference numeral 1038 may represent a portion of image 1018 in region 1032 that may be distorted or incomplete. For example, this may be due to artifacts in the resulting image 1018 acquired using the camera device 48 as described in FIG. 26A, or due to physical damage or defects on the physical credit card 954 itself. For example, through natural wear and tear, one or more of the numbers or letters printed on the credit card 954 may be partially or completely obscured or distorted. For example, the character indicated by reference numeral 1038, which may initially have indicated the number "8", may appear distorted in the account number area 1032 of the acquired image 1018. Due to this distortion, the image recognition application may not be able to identify the character 1038 as the number "8". As described in detail below, the techniques may provide the recipient (or payer) with the ability to review and correct the extracted payment information prior to submitting the transaction information for authorization and processing.

Referring now to FIG. 26C, once the image processing steps described in FIG. 26B are completed, the screen 1042 may be displayed on the recipient device 10. As shown, the screen 1042 may display information extracted from the credit card image 1018. For example, screen 1042 may display the credit card provider's identifier 1030, the credit card account number 1032, the expiration 1034 associated with the payer's credit card and the payer's identifier 1036 as described above. Can be. In addition, screen 1042 may display graphical buttons 1044, 1046, 1048, each of which may correspond to specific functions that may be performed on device 10.

Referring specifically to the credit card account number 1032 extracted from the image 1018, the currently displayed extracted account number 1032 is the actual account number printed on the credit card 952 due to the distorted characters 1038. Note that this is not accurate compared to. Thus, the payee can edit the displayed credit card information by selecting the graphic button 1044. Upon selection of graphical button 1044, the user has access to screen 1043, which can display text fields 1052, 1054, 1056 as well as dropdown selection field 1050. These fields may be initially filled with corresponding extracted credit card information 1030, 1032, 1034, 1036 from the previous screen 1042, using the displayed text keyboard 160 or numeric keyboard 164 as needed. Can be individually selected and edited by the payee or payer.

For example, as shown in this embodiment, the payee edits the credit card account information displayed in the text field 1054 by using the numeric keyboard 164, thereby distorting the distorted characters in the acquired credit card image 1018. 1038) can correct for inaccuracies that may have resulted. Thus, if the payee confirms that the edited credit card information is now correct, the payee selects graphical button 1058 and returns to screen 1042, where the credit card account number 1032 is on screen 1043. It can be updated to reflect the calibration made by the recipient. The recipient can then proceed with the transaction process by selecting the graphical button 1046 to navigate to the screen 1060 of FIG. 26D.

As shown in screen 1060, the credit card information edited by the payee after extraction from image 1018 is displayed, generally indicated at 1062, as described in FIG. 26C. In addition, screen 1060 may display a crediting account, which may be the default crediting account 216 as described above in this embodiment. Screen 1060 may further display graphical buttons 686, 688, 690 that may represent the functions described above with respect to screen 674 shown in FIG. 14J. Accordingly, the payee may select graphical button 686 to navigate to screen 1066 to initiate the process of crediting the payment to the crediting account based on the extracted card information 1062.

As can be seen, screen 1066 may provide additional security measures that must be addressed before essentially transmitting transaction information to financial server 100 or the like. For example, in the illustrated embodiment, screen 1066 may include text fields 1068, 1070, 1072 as well as graphical buttons 1074, 1076. Thus, screen 1066 may require the payer to provide the requested information to fields 1068, 1070, 1072 prior to initiating the processing of this transaction. For example, field 1068 may be used to enter a payment amount corresponding to the requested payment. Field 1070 may require the payer to provide a CVV number corresponding to credit card 952. As mentioned above, the use of such additional authorization means may help to prevent the occurrence of unauthorized claims, such as those that may have been initiated based on unauthorized acquisition of credit card images.

In addition, an email address belonging to the payer may be provided in text field 1072. As noted above, the provided email can be used to send a receipt or receipt confirmation to the payer upon completion of the transaction. As noted above, the entry of data in text fields 1068, 1070, 1072 may be accomplished via text keyboard interface 160 (not shown in FIG. 26D) or numeric keyboard interface 164. Once the information required by the text fields 1068, 1070, 1072 is entered, the transaction authorization process can be initiated by selecting the graphical button 1074. In addition, the payer or payee may have the option to cancel this transaction by selecting graphical button 1076. Once the transaction is authorized and successfully processed, the screen 712 may be displayed on the recipient device 10. As described above, screen 712 has been requested that the requested payment amount has been deposited to the designated crediting account 216 and that a receipt has been provided to the payer via an email address or the like provided in text field 1072 of screen 1066. A notification message 714 may be displayed instructing the recipient.

Referring now to FIGS. 27A-27G, one or more techniques for manipulating the recipient device 10 in accordance with transaction 970 described above with respect to FIG. 24 are described through a plurality of screen images. As shown in FIG. 27A, the startup of the camera device 48 for acquisition of a check image, such as the image corresponding to the check 972, allows the recipient to navigate through the aforementioned screens 110, 476, 484. You can ask. For example, starting from screen 110, the user may select graphical button 114 to advance to screen 476. Here, the user can further navigate to the screen 484 by selecting the graphical button 478. From screen 484, the user can navigate to screen 1002 by selecting graphical button 490 as described above in FIG. 26A. Here, the user may not start the process for acquiring the credit card image by selecting the graphic button 1004, but may start the process for acquiring the check image by selecting the graphic button 1006.

As shown in FIG. 27A, selection of graphical button 1006 may navigate the recipient to screen 1080. Screen 1080 may display graphical buttons 1082 and 1084. Each of these graphical buttons corresponds to a respective technique for processing a check image acquired in accordance with the presently described techniques. Specifically, graphical button 1082 may represent a function for processing the entire check image. As will be appreciated, the image of the entire check must first be acquired to initiate processing of the entire check image. As described in more detail below, the use of the full check image processing function, represented by the graphical button 1082, means that the check provided by the payer has the payment amount indicated on the check, signed by the payer and for the payee. It can be selected in the situations that are created. Thus, it may be necessary to process the entire check image to extract information about the payment amount indicated by the payer on the check.

For example, referring now to FIG. 27B, upon selection of graphics button 1082, screen 1086 may be displayed on the recipient device, and camera device 48 may be started up for image acquisition as described above. . As shown on screen 1086, a viewfinder 1009 associated with camera device 48 may be displayed. The viewfinder may include an acquisition frame 1010. Thus, the payee may place the payee device 10 such that the entirety of the check 972 is aligned with the acquisition frame 1010. Once the check 972 is aligned with the image frame 1010, the recipient may select the graphics button 1090 to acquire an image using the camera 48. In addition, a section of graphical button 1092 on screen 1086 may cause the recipient to cancel the image acquisition process if necessary.

Once the image of the check 972 is acquired, the acquired image, indicated by reference numeral 1096, may be displayed on the screen 1086. As mentioned above, the recipient can evaluate the acquired image 1086 to determine whether the image is suitable for use by the image processing application as described above. If the recipient determines that the acquired image 1096 does not meet one or more quality standards required by the image processing application, as described above, the recipient selects the graphics button 1100 and returns to the viewfinder 1009. And a subsequent image can be obtained. If the payee determines that the acquired image 1096 is suitable for processing by the image recognition application, the user can initiate image processing steps by selecting the graphic button 1098.

Processing of the check image 1096 may be further described with reference to FIG. 27C. As shown, the image processing application may process the acquired image 1096 to determine various areas of interest, such as areas indicated by reference numbers 1104, 1106, 1108, and 1110. This processing may be similar to the process described above in connection with the processing of the credit card image 1018 in FIG. 26B. The image processing application may also designate a region 1112 as the region of interest that may correspond to the amount of payment written on the check 972 by the payer. As shown in FIG. 27C, area 1104 may correspond to an identifier of the payer, and area 1106 may be used to identify a banking provider associated with the payer's bank account number that may be displayed within area 1108. May correspond to a routing number that may be used. The image processing application may also direct area 1110 as corresponding to the check number associated with the provided check 972. Thus, as described above, once regions are recognized by the image processing application, information contained within regions 1104, 1106, 1108, 1110, 1112 is extracted and shown on screen 1116 as shown in FIG. 27D. Can be displayed.

In addition to the check information extracted from the image 1096, as shown on screen 1116, screen 1116 may also have graphical buttons 1118 as well as graphical buttons 1046 and 1048 described above with reference to FIG. 26C. I can display it. Then, in a manner similar to the editing process described above with respect to FIG. 26C, the user selects graphical button 1118 to edit the information extracted from check image 1096 if any portion of the information is determined to be inaccurate. can do. As indicated in FIG. 27D, if the extracted information is determined to be correct, the user may select graphical button 1046 to access screen 1124.

As indicated on screen 1124, information extracted from the check image, such as the information indicated by reference numerals 1104, 1106, 1108, 1110, 1112, is displayed, and generally indicated by reference numeral 1126. Screen 1124 may display a section of crediting account that may initially be selected as the recipient's default crediting account 216 as described above. In addition, screen 1124 may also display graphical buttons 686, 688, 690 as described above with respect to screen 674 in FIG. 14J. Thus, the payee may select graphical button 686 to initiate transaction authorization steps in which the payment amount indicated by check information 1126 is charged or debited to payment account 1112. In the presently described embodiment, the check 972 provided to the payee in this embodiment has been specifically written for the payee, thus indicating that the payer has previously condoned the request for payment, and therefore the screen 1066 of FIG. It should be noted that the security measures described above in connection with this may not be necessary. Subsequently, if the transaction is authorized and successfully processed by one or more financial servers 100 or the like, the screen 712 may be displayed on the recipient device 10. As described above, screen 712 may include a notification message 714 indicating that the requested payment amount has been credited to the selected crediting account 216.

Referring briefly to FIG. 27A and specifically referring to screen 1080, graphical button 1084 may represent additional functionality provided on recipient device 10, where transaction 970 described above in FIG. 24. May be initiated by obtaining only a partial image of the check (eg, not the entire image). As described in more detail below, the functions provided by the graphical button 1084 can be used in situations where the check provided by the payer is a blank check, so that the transaction 970 can, for example, It may only be initiated upon receipt of some type of additional authorization from the payer, such as providing.

Referring now to FIG. 27E, upon selection of graphical button 1084, screen 1080 may be updated to display notification message 1132 and graphical buttons 1134 and 1136. Notification message 1132 may generally inform the payee that this transaction further requires the provision of a bank account PIN number by the payer. In order to proceed with the acquisition of the partial check image, the payee may select a graphical button 1134. The payee may also have the option to cancel the check image acquisition process by selecting graphic button 1136. Upon selection of graphical button 1134, the user may be navigated to screen 1086 described above, which may include a viewfinder 1009 associated with camera device 48. As shown on screen 1086, viewfinder 1009 may include image acquisition frame 1010. Thus, the payee can place the device 10 such that the desired portion of the check 972 to be imaged is included in the area defined by the acquisition frame 1010. Once the desired portion of the check 972 is properly aligned, the payee can acquire an image of that portion of the check 972 by selecting the graphical button 1090 on the screen 1086. The recipient may also have the option to cancel the image acquisition step by selecting graphic button 1092.

Upon selection of graphical button 1090, an image of the aligned portion of check 972 may be acquired and displayed on screen 1086, as indicated by reference numeral 1140. In this case, in a manner similar to the screens 1086 described above with respect to FIG. 27B, the recipient may evaluate the image 1140 to determine if the quality of the acquired image is sufficient for processing by the image processing application. For example, if the image 1140 does not meet one or more of the quality standards described above, the payee may select the graphical button 1100 to reacquire a subsequent image of the check 972. Once the acquired image 1140 is determined to be suitable for processing by the image processing application, the payee may initiate the payment information extraction process by selecting the graphical button 1098. For example, referring now to FIG. 27F, the processing of the partial check image 1140 generally includes an area 1112 where the partial check image 1140 corresponds to the payment amount printed on the check 972 by the payer. It may be similar to the processing of the full check image 1096 as described above with respect to FIG. 27C except that it does not. Thus, in this embodiment, the image processing application processes the partial check image 1140 to identify the payer's identifier 1104, the routing number 1106 corresponding to the payer's banking provider, and the payer's bank account number 1108. ) And check number 1110 may be extracted.

Once the partial check image 1140 has been processed by the image processing application, the payee may proceed to the screen 1116 shown in FIG. 27G. As shown on screen 1116, the payer's identifier 1104, the banking provider's routing information 1106 associated with the selected payment account, bank account number 1108, and check identification number associated with the provided check 972 ( The extracted check information including 1110 may be displayed. In addition, the screen 1116 may provide graphical buttons 1046 and 1048 as well as graphical buttons 1118 that may exhibit the same functionality as described above with respect to FIG. 27D. Thus, if the check image information extracted from the image 1140 is determined to be correct by the payee, the payee may proceed to select a crediting account by selecting the graphical button 1046. For example, selection of graphical button 1046 may navigate the payee to screen 1124, which may initially be extracted as well as extracted check information provided on previous screen 116, generally indicated at 1144. May also indicate a section of the crediting account that may be selected as the default crediting account 216. In addition, screen 1124 may further include graphical buttons 686, 688, 690, each of which may correspond to the functions described above with respect to screen 674 in FIG. 14J. Thus, a graphical button 686 can be selected to advance the payee to screen 1148 to initiate authorization and processing of this transaction where payment is credited to the payee's default crediting account 216.

Screen 1148 can be similar to screen 1066 described above in FIG. 26D in that one or more additional authorization steps can be completed by the payer before the transaction can be processed. For example, the depicted screen 1148 can include text fields 1150, 1152, 1154. Using keyboard interface 160 or numeric keyboard interface 164 (not shown in FIG. 27G), the payer enters the amount of the requested payment in text field 1150, as well as in the provided check 972. A PIN number associated with the corresponding bank account may be entered in text field 1152. Optionally, if the payer wishes to receive an electronic receipt in the form of an email or the like upon completion of the transaction, the payer may provide a valid email address in text field 1154. Screen 1148 may further include graphical buttons 1156 and 1158. Thus, once the requested information is entered into the text fields 1150, 1152, 1154, the graphical button 1156 may be selected to initiate authorization and processing of the current transaction. Also, at this point, the graphic button 1158 can be selected to cancel the transaction.

As discussed above, once the transaction is successfully completed, screen 712 may be displayed on the recipient device 10. Screen 712 shows the recipient that the requested payment has been credited to the selected crediting account 216 and that a receipt regarding the current payment has been sent to the email address provided by the payer in text field 1154 of screen 1148. And a notification message 714 to notify the user. Alternatively, if the transaction failed for one or more reasons, screen 700 may instead be displayed on the recipient device. In this figure, screen 700 may indicate that the PIN number provided by the payer in text field 1152 of previous screen 1148 does not match the PIN number included in records maintained by the banking provider. May include a notification message 1160. Thus, the payee may be instructed to request the payer to re-enter or confirm the PIN number entered on screen 1148. It should be understood that the notification message 1160 is intended to indicate an example of why the current transaction may fail. Indeed, none of the above reasons (eg, lack of sufficient funds in the payment account, etc.) can contribute to the transaction not being processed successfully.

Referring now to the remaining figures, further aspects of the presently described techniques are shown. As noted above, the electronic device 10 may include one or more functions that are adapted to perform a group transaction that includes one or more payers. For example, as described above with respect to FIG. 14A, graphical button 482 may be selected from screen 476 to perform a group transaction. Referring now to FIG. 28, a schematic diagram of a system for performing a group transaction in accordance with an aspect of the present invention is shown and generally referenced 1170. As shown in this figure, group transaction 1170 may include a primary transaction indicated by reference numeral 1172, as well as one or more auxiliary transactions as indicated by reference numeral 1174.

In major transaction 1172, electronic device 10 may act as an initiating device for group transaction 1170 and may assume the role of a payer making a payment to merchant device 1176. The initiating device 10 may then act as a payee and receive additional payments from the owners of the payer device 92, the smart card 862 and the magnetic credit card 954. For purposes of this description and to more clearly distinguish between the owners of each of these payment means, the owner of the magnetic card 954 will be referred to herein as a credit card payer. Similarly, the owner of smart card 862 is referred to as a smart card payer, and the owner of a payer device, which may be an NFC enabled device in accordance with the embodiments described above, will be referred to as an NFC payer. As described in more detail below, the payments made to the initiator device 10 by the credit card payer, smart card payer, and NFC payer may correspond to a payment that must be paid back to the seller. For example, the presently described transaction 1170 may allow one party (e.g., initiator) to pay first for a group invoice that includes amounts owed by each of the parties shown, and the other parties later provide payment to the initiating party. This can happen in situations.

For example, the technique can be used in situations where the parties shown in FIG. 28 wish to share a bill or bill at a restaurant. In main process 1172, initiator device 10 may act as a payer in connection with seller device 1176, which may be a device operated by an employee associated with a restaurant. As noted above, the initiator device and the merchant device 1176 may establish an NFC connection 1178 where the group invoice 1180 may be sent from the merchant device 1176 to the initiator device 10. The initiator may then select the appropriate payment account on the initiator device, which may be the default payment account 180 as described above with respect to FIG. Upon selection, payment account information 1182 may be sent to merchant device 1176 via NFC connection 1178.

Upon receipt of payment information 1182, the merchant device 1176, which may act as the payee device in the main transaction 1172, selects the crediting account as described above and collectively referred to as reference number 1184. Information, payment account information 1182, as well as the requested payment amount corresponding to the group invoice 1180 may be sent to one or more financial servers 100. As shown in the figure, the transmission of transaction information 1184 may be via a network indicated by reference numeral 1186. Network 1186 may include any suitable network described above, such as, for example, a LAN or WLAN network connection.

Once transaction information 1184 is received, financial servers 100 may process and authorize the requested transaction, and if the transaction is authorized, payment 1188 may be provided to the seller. For example, if the primary transaction 1172 is authorized by the financial servers 100, the amount requested in the group invoice 1180 is billed from the payment account 1182 designated by the initiator device 10, and the seller device ( 1176) may be credited to the designated crediting account. Thus, main transaction 1172 may be completed at this point, and initiator device 10 may have the option to proceed with secondary transaction 1174. As noted above, secondary transactions 1174 may include transactions involving NFC device 92, smart card 862, and magnetic credit card 954. However, it should be appreciated that in other embodiments additional devices or payment means may also be included in the supplemental transaction 1174, and need not be limited to the examples provided herein.

As shown in FIG. 28, upon completion of the main transaction 1172, the initiator device 10 sends the current invoice 1192 to the NFC payer device 92 via the ad hoc network indicated by reference number 1194. Can be. Initially, the current invoice 1192 may be the same as the group invoice 1180. Before requesting payment from group transaction members (eg, credit card payer, smart card payer, and NFC payer), the initiator may allocate a group invoice 1180 according to the amount each transaction member is to pay. have. As described below, the allocation of invoice items can be updated in real time and can be viewed on the current invoice 1192, which can be displayed on the NFC payer device 92. The current invoice 1192 may also be updated in real time to reflect the payments received by the initiator device 10.

Once the group invoice 1180 is assigned by the initiator on the initiator device 10, the amounts that each of the credit card payer, smart card payer, and NFC payer should pay back may be delivered to these parties as a partial invoice. For example, the initiator device may begin the process of receiving payments by establishing an NFC connection 1196 with the NFC payer device 92 and sending the partial invoice 1148 to the NFC payer. As will be appreciated, the partial invoice 1118 may reflect a portion of the group invoice 1180 that the NFC payer should pay back to the initiator. Thus, according to the techniques generally described above in connection with the embodiments shown in FIGS. 12A-12C, a payment account may be selected on the NFC payer device 92, and then initiated as indicated by reference numeral 1200. May be transmitted to the child device 10.

Upon receipt of payment information 1200 from the NFC payer device 92, the initiator device 10 selects the crediting account and payment information 1200 collectively referred to as transaction request information 1202, In addition to the crediting account information, the amount reflected in the partial invoice 1198 may be transmitted to the financial servers 100 through the network 1204. As will be appreciated, network 1204 may be provided through one or more of the communication interfaces available on device 10 as described above. Subsequently, if the financial servers 100 determine that a transaction request, represented by transaction information 1202, may be granted, a payment 1206 may be written to the credit account selected by the initiator device 10. Can be. In addition, as discussed above, payments made by any payer in an auxiliary transaction may be updated in real time on the current invoice 1192 that the NFC payer is viewing. For example, each payment 1206 received by the initiating device may be reflected on the current invoice 1192 as indicated by arrow 1208.

Once the initiator device 10 receives the first payment from the device 92 which is an NFC payment, the initiator device 10 may continue to receive the remaining payments from the smart card payer and the credit card payer. For example, according to the techniques described above in connection with the transaction 860 shown in FIG. 20, the initiator device may correspond to the smart card information 1210 corresponding to the smart card 862 via an NFC connection 1196 through a tap operation. Can be received. Initiator device 10 may also acquire image 1212 of magnetic credit card 954 in accordance with the techniques described above in connection with transaction 952 shown in FIG. 23. Thus, the initiator device 10 may send the financial servers 100 via the network 1204 for authorization of these additional auxiliary transactions as well as smart card information 1210 and payment information that may be extracted from the image 1212. Can be sent to. Thus, if such transactions are authorized by the financial servers 100, the respective payments from the credit card payer and the smart card payer, also indicated by number 1206, are selected crediting account selected by the initiator device 10. It can be written on the stool. In addition, the current invoice 1192 that NFC payer 92 is viewing may be updated to reflect the processing of additional payments from the credit card payer and the smart card payer, as indicated by reference number 1208.

Referring now to FIG. 29, illustrated is a method 1220 that may describe a technique for manipulating the initiator device 10 to perform the group transaction 1170 described in FIG. 28. As indicated in step 1222, a group transaction may be initiated by the initiator device 10. Subsequently, in step 1224, the initiator may receive and pay a group invoice, such as group invoice 1180. As described above, according to one embodiment, receipt and payment of a group invoice by the initiator device 10 may be through an NFC connection 1178. If the group invoice is paid by the initiator device 10, the method 1220 proceeds to step 1226, where the initiator may include a credit card payer, a smart card payer and an NFC payer as described above. You can identify group interface members and interface with them. The initiator may then proceed to assign the items listed on the group invoice to the appropriate group transaction member. For example, the initiator may select the first invoice item in step 1228 and assign the item selected in step 1230 to the appropriate group transaction member. As indicated by subsequent decision block 1232, the initiator may continue the allocation process until all invoice items listed on the group invoice 1180 are properly assigned to the correct group transaction member.

The initiator can then initiate the process of collecting payments from each of the group transaction members. For example, the initiator may select the first group transaction member at step 1234. Subsequently, in step 1236, the partial invoice corresponding to the member selected from step 1234 may be communicated. For example, the partial invoice may be sent to the NFC payer device 92 via the NFC connection 1196 described above. Partial invoices may also be delivered, for example orally, to credit card payers and smart card payers. Upon receipt of the partial invoice, each payer can select a payment account and provide the payment account information to the initiator. For example, as indicated by step 1238, the initiator may process the transaction by collecting payment information from the selected group transaction member, then sending the transaction request to the financial servers 100, and the like. As mentioned above, when the requested transaction is authorized by the financial servers 100, a corresponding payment may be made for the crediting account designated by the initiator.

Then, as indicated by decision step 1240, the initiator device may continue to collect payments until a payment is received from each of the group transaction members. Thus, once all payments have been received, the group transaction can be completed in step 1242. It should be noted that the above described steps 1222 and 1224 may correspond to the primary transaction 1172, and the remaining steps 1126-1242 may correspond to the secondary transaction 1174 as described above in FIG. 28. .

The group transaction 1170 described above illustrates FIGS. 30A-30L, which may generally represent various screen images that may be displayed on the initiator device 10 or the NFC payer device 92 during the code of the group transaction 1170. Can be better understood by reference. For example, referring to FIG. 30A, main transaction 1172 may be initiated starting from screen 110 on initiator device 10. The initiator may then navigate to a screen 476 that can display the graphical button 482 by selecting the graphical button 114 as described above. Thus, the initiator can access the group transaction functions provided by the device 10 by selecting the graphical button 482 and proceeding to the screen 1270. Screen 1270 may display graphical buttons 1272, 1274, 1276. Each of these graphical buttons may represent specific functions as described above. For example, graphical button 1272 may represent the ability for an initiator to initiate a group transaction 1170. Similarly, graphical button 1274 may allow an initiator to join an existing group transaction, such as a group transaction that may have been previously initiated by another member. The initiator can also cancel the group transaction by selecting the graphical button 1276.

As shown in this figure, selection of graphical button 1272 may navigate the initiator to screen 1278. Screen 1278 may provide a selection of various options related to the group transaction. For example, after an initiator pays a group invoice, such as group invoice 1180, as a major transaction (e.g., 1172), allocate the invoice among additional transaction members as a series of auxiliary transactions (e.g., 1174), and these transactions A first option may be provided for collecting payments from each member. This may be the scenario generally described by group transaction 1170 in FIG. 28.

As indicated on screen 1278, additional group transaction options may be provided that allow the initiator to split the invoice directly between one or more other transaction members. This situation is further described below with respect to FIG. 32. The options shown on screen 1278 may be represented by graphical elements 1280 and 1282 that may represent check box graphical icons from which the initiator can select the appropriate option. For example, as shown in this figure, the initiator may select check box 1280 to indicate that this transaction should be performed in accordance with the techniques described above in FIG. Once option 1280 is selected, the initiator may select graphical button 1284 to initiate group transaction 1170.

Upon selection of graphical button 1284, the user proceeds to screen 1288, where the aforementioned main transaction, indicated by reference numeral 1172, can be initiated. For example, screen 1288 may represent the initiation of NFC connection 1178. The screen 1288 also shows a notification message 1290 that can instruct the initiator that the NFC device 46 of the initiator device 10 is powered on and thus the NFC interface 60 is driven, as described above. It may include. Screen 1288 may also include a graphical button 1292 that can be selected to cancel the establishment of NFC connection 1178 if the initiator is needed.

Upon establishing NFC connection 1178, initiator device 10 may receive group invoice 1180 from merchant device 1176 with NFC connection 1178 established. For example, if group invoice 1180 is received by initiator device 10, screen 1288 may be updated as shown in FIG. 30B to display notification message 1296. As shown, the notification message 1296 may inform the initiator that the group invoice 1180 has been received. Thus, via graphical buttons 1298 and 1300, the initiator can accept or reject the received group invoice 1180. To accept the group invoice, the initiator may select graphical button 1298 to navigate to screen 1304. Screen 1304 may display the identifier 1306 of the initiator, the identifier 1308 of the seller, as well as the amount requested by the group invoice indicated by reference number 1310. As described below, the amount 1310 may reflect the subtotal before adding the tip amount. For example, this embodiment may be reflected in the scenario where the seller is a restaurant and the invoice represents the restaurant bill. Accordingly, graphical buttons 1312 and 1314 are also provided on screen 1304 that the initiator can select to specify a tip amount or to view invoice details, respectively.

Screen 1308 may further display the currently selected payment account that may be initially selected as the default payment account 180 designated by the initiator as described above in FIG. 7. Thus, graphical buttons 1318, 1320, 1322 can be provided, which graphical button 1318 represents the ability for the initiator to pay the invoice using the currently selected default payment account 180, and the graphical button ( 1320 illustrates the ability for the initiator to select an alternate payment account, and graphical button 1322 allows the initiator to cancel the current transaction.

As shown in FIG. 30B, the initiator may view group invoice 180 by selecting graphical button 1314 and navigating to screen 1326. Screen 1326 may include a section that generally lists all group invoice items indicated with reference 1330. In addition, a scrollbar function 1332 may be provided on screen 1326, so that the initiator may navigate through the list if the entire list of invoice items 1330 is not visible in the display section provided. . In addition to the list of invoice items 1330, screen 1326 may also list any applicable tax amount 1328. As will be appreciated, the sum of the invoice items 1330 and the tax amount 1328 may be summed to obtain the subtotal 1310 described above. Screen 1326 may also display tip amount 1334, which may initially be zero before addition of the tip amount by the initiator. Accordingly, subtotals for group invoice 1310 and any tip amount 1334 may be summed to determine the total amount of group invoice 1336. In addition, graphical buttons 1338, 1340 may also be provided on screen 1326, which may provide the initiator with the ability to initiate payment of the displayed invoice based on its current status. . Also, graphical button 1340 may be selected if the initiator decides to specify tip amount 1334.

For example, if graphical button 1340 is selected, the initiator can navigate to screen 1350 for addition and selection of tip amounts. Screen 1350 may display the current subtotal of group invoice 1310 and may provide a text field 1352 for the initiator to enter a desired tip amount for the initiator. For example, the initiator may decide to enter a tip amount using the numeric keyboard 164 or select a pre-calculated tip amount as provided by graphical buttons indicated by reference numeral 1354. As shown, the precalculated tip amounts displayed by the graphical buttons 1354 may correspond to certain ratios of the current subtotal amount 1310. For example, in this figure, the initiator may select a graphical button that corresponds to a tip that is 20% of the current subtotal 1310. As shown, upon selection of the tip amount 1334 described above, the text field 1352 may be filled to reflect the selection. In addition, the total amount 1336 for the group invoice 1080 may be updated to reflect the addition of the tip amount 1334. For example, the total amount 1336 of the current group invoice can be calculated by summing the subtotal amount 1310 and the currently selected tip amount 1334. The initiator may then select graphical button 1356 to accept the selected tip amount and the corresponding updated group invoice total amount 1336 or cancel the current transaction by selecting graphical button 1358. As shown in this figure, selection of graphical button 1356 may return the user to screen 1326, which is updated to display the selected tip amount 1334 and updated group invoice totals 1336. Can be. If the initiator is satisfied with the current group invoice total amount 1336, the initiator may select graphical button 1338 to proceed with payment of the group invoice amount 1336.

Referring to FIG. 30C, the selection of graphical button 1338 may return the initiator to screen 1304, which allows the group invoice amount 1336 to add the specified tip amount 1334 from screen 1350. It may be updated to reflect that it has been updated to include. Thus, the initiator may initiate payment of the group invoice total amount 1336 using the default payment account 180 by selecting the graphical button 1318. As described above, the selection of the graphical button 1318 may send payment amount information 1182 to the merchant device 1176 via the NFC interface 1178. Thus, merchant device 1176 may send current transaction request 1184 to financial servers 100 to process and authorize the requested payment.

As shown in FIG. 30C, if primary transaction 1172 is authorized by financial servers 100, screen 1362 may be displayed on initiator device 10. Screen 1362 may display a notification message 1164 indicating to the initiator that the group invoice 180 was paid using the selected default payment account 180. The screen 1362 may also include graphical buttons 1366, 1368. Graphic button 1368 may represent the ability for a user to terminate or cancel a transaction. Graphic button 1366 may allow a user to assign group invoice 1180 and thus initiate secondary transactions 1174 described above with respect to FIG. 28. As shown in FIG. 30C, upon selection of graphical button 1366, screen 1370 may be displayed. Screen 1370 shows the configuration of an ad hoc network, such as network 1194. As noted above, capable devices, such as NFC payer device 92, connect to the established ad hoc network, present invoice 1192 as well as the current invoice 1192 as well as the current invoice 1192 during the various steps performed in the secondary transaction 1174. You can also see the updates that can be made for.

Screen 1370 may display the identifier 1306 of the initiator as indicated by reference numeral 1372, as well as apply the identifier name to the current group transaction. As shown, the transaction identifier 1372 may be the same as the recipient 1308 (“ABC restaurant”) of the payment in the major transaction shown in FIGS. 30A and 30B. In addition, screen 1370 may include graphical buttons 1376 and 1378. Graphic button 1378 may cause the initiator to cancel the setting of the ad hoc network if none of the other transaction members, such as a credit card payer and a smart card payer, are using devices capable of accessing the ad hoc network. have. If the group transaction 1170 includes at least one device capable of connecting to an ad hoc network, such as the device 92 described now, the initiator selects the graphical button 1374 to assign the process of assigning the group invoice 1180. It may wait for the device 92 to connect to the network before initiating.

The process of connecting to the ad hoc network 1194 in relation to the perspective of the NFC payer device 92 may be described with respect to FIG. 30D. For example, as described in FIG. 30, the NFC payer may select a graphical button 114 from the screen 110 to connect to the ad hoc network established by the initiator device 10. The screens shown in FIG. 30D may be similar to one or more of the screens described above in connection with the initiator device 10. Thus, it should be understood that a transactional application provided on the initiator device, such as application 34, may also be provided on the payer device 92 in this embodiment. Upon selection of graphical button 114, the payer may proceed to screen 476. In order to access the group transaction functionality provided on the NFC payer device 92, the payer may select graphical button 482 to navigate to screen 1270. Here, the payer can connect to the ad hoc network described above by manipulating the NFC payer device and selecting the graphical button 1274.

As shown in FIG. 30D, selection of graphic button 1274 may navigate the NFC payer to screen 1380. Screen 1380 may display the payer's identifier 1382, as well as a list of available ad hoc networks that may indicate ongoing group transactions. For example, the network set up by the initiator and described in FIG. 30C is listed here and is referenced 1384. Thus, the payer can connect to the selected network, for example, by selecting the listed network 1384 via the check box selection graphic 1385 and selecting the graphical button 1386. In addition, the NFC payer may have the option to refuse the connection to the ad hoc network by selecting the graphical button 1388. As will be appreciated, if the latter is selected, the NFC payer may continue to participate in the group transaction 1170, but may not see updates to the current invoice 1192 in any real time.

If all capable devices connect to the ad hoc network 1194 set up by the initiator device 10, the assignment of group invoice items may be initiated. For example, referring now to FIG. 30E, screen 1370 described in FIG. 30C may be updated to indicate that the NFC payer indicated at 1382 has connected to an established ad hoc network. Thus, since no other payer device is currently participating in the transaction, the initiator may select the graphical button 1336 and navigate to screen 1400 to initiate the assignment of group invoice items 1330.

As shown on screen 1400, a list of group transaction members may be displayed. As shown, the list 1402 may initially include only the initiator and the NFC payer currently connected to the initiator device 10 via the ad hoc network 1194. Screen 1400 may also display a list of group invoice items 1330. As described above, in the case where the list of group invoice items 1330 may not be displayed in its entirety due to screen size limitations, a scrollbar function may be provided on the screen 1400 that is indicated by the graphic 1404. have. The initiator can then select graphical button 1406 to add the remaining transaction members to the current group transaction. Upon selection of graphical button 1406, the initiator may navigate to screen 1410, which may display text field 1412 and graphical button 1414, as well as text keyboard 160. Thus, the initiator may enter an identifier of the credit card payer into text field 1412 via text keyboard 160. Once the identifier of the credit card payer is entered, the initiator can add the credit card payer to the current transaction by selecting the graphical button 1414. As shown in FIG. 30E, selection of graphic button 1414 may cause pop-up window 1420 to be displayed on screen 1410. Pop-up window 1420 may notify the initiator that the credit card payer has been added to the current transaction and may further provide the initiator with graphical buttons 1422 and 1424. For example, as shown, selection of graphical button 1422 may close popup window 1420 and allow the initiator to access screen 1410 again to add additional members, such as smart card payers. Thus, the initiator can repeat the above steps and enter the identifier of the smart card payer in the text field 1412. By reselecting the graphical button 1414, a popup window 1426 may be displayed on screen 1410 informing the initiator that the smart card payer has been added to the current transaction 1170. Thus, since all group transaction members described in the secondary transaction 1174 of FIG. 28 have now been added, the initiator can return to the screen 1400 by selecting the graphical button 1424.

Referring now to FIG. 30F, an allocation of one of the group invoice items 1330 by the initiator is shown. As shown in this figure, screen 1400 will display an updated list of transaction members 1402 that may include credit card payers and smart card payers added using the techniques described in FIG. 30E. Can be. The initiator may then assign the group invoice item 1430 by selecting the location of the item 1430 on the screen 1400 using a finger or other object such as a stylus, or the like, to display the display of the initiator device 10 ( While maintaining contact with 24, the selected invoice item 1430 can be moved to a location on the screen 1400 corresponding to the appropriate transaction member. As will be appreciated, this operation may be generally referred to as a “drag and drop” operation in connection with graphical user interfaces. In addition, as shown on screen 1400, the initiator may select graphical button 1428 if it decides to divide the entire group invoice 1080 evenly among the transaction members 1402. For example, the selection of graphical button 1428 can divide the group invoice total amount 1336 evenly among the initiator, NFC payer, credit card payer, and smart card payer. In addition, the drag and drop description shown in this figure represents one implementation that may be provided on an apparatus in accordance with the presently described techniques, although any type of suitable interfacing technique for assigning group invoice items 1330 may be employed. It should be understood that it can be used in the current transaction.

Referring to FIG. 30G, screen 1400 may be updated to indicate that invoice item 1430 has been assigned to the initiator. As shown in the figure, the allocation of group invoice items 1330 is indicated by reference numerals 1328 and 1334, respectively, based on a proportional amount of the cost of the allocated invoice item 1430 relative to the invoice total amount 1336. It can also include automatic allocation of tax and tip amounts. However, alternative techniques for allocating tax amount 1328 and tip amount 1334, including alternative schemes for automatically allocating such amounts, as well as techniques for manual allocation of such amounts by the initiator. It should be understood that it is within the scope of the present invention. The initiator may then continue to allocate remaining group invoice items 1330. For example, FIG. 30G further illustrates the assignment of invoice item 1432 to the initiator on list 1402 according to the techniques described above, as well as subsequent automatic allocation of any additional tax and tip amounts.

As will be appreciated by those skilled in the art, there may be a need to allocate specific invoice items between two or more transaction members 1402. For example, a particular invoice item may have been shared by each of the transaction members 1402. Thus, a shared invoice item may be assigned by selecting graphic button 1434. Selection of the graphical button 1434 can navigate the initiator to the screen 1438. Screen 1438 may generally display a list of group invoice items 1330 and may indicate which invoice items 1330 have already been assigned, such as invoice items 1430 and 1432. As will be appreciated, invoice items 1430 and 1432 that have already been assigned may not be selectable on screen 1438. As shown in the figure, the initiator may select a shared invoice item 1440 and assign this item among a plurality of group transaction members. For example, upon selection of invoice item 1440, popup window 1442 can be displayed on screen 1438.

Pop-up window 1442 can display a list of current group transaction members 1402. As shown, a check box graphic may be provided for each group transaction member. Thus, the initiator can specify how invoice item 1440 is allocated by selecting the appropriate group transaction members using the check box graphics associated with each member. In addition, as shown in this figure, the initiator may evenly allocate the shared invoice item 1440 among all group transaction members 1402 by selecting the check box graphic indicated by reference number 1444. Once the appropriate selections have been made, the initiator may select graphical button 1446 to assign the shared invoice item 1440 according to the selection reflected in popup window 1442. In addition, the initiator may cancel the assignment process by selecting graphical button 1484. Upon selection of graphical button 1446, invoice item 1440 may be allocated evenly among all group transaction members 1402, and the initiator may return to screen 1400. As shown in the list of group invoice items 1330 on the updated screen 1400, the list of invoice items 1440 may be updated to indicate that this item has already been allocated as described above.

Referring now to FIG. 30H, after allocating the shared invoice item 1440, the initiator may continue to allocate additional invoice items. For example, FIG. 30H shows the allocation of invoice items 1452, 1454 that may correspond to amounts that an NFC payer should pay. As shown in the figure, once invoice items 1452 and 1454 are properly allocated, their respective lists may be updated on screen 1400 as described above. As will be appreciated, during allocation of invoice items 1330, the initiator may select one or more of the group transaction members indicated in list 1402 to view the current state of the partial invoice. For example, by selecting an NFC payer, the initiator may see a screen 1456 that may display a partial invoice corresponding to the amount the NFC payer is to pay. As shown, screen 1456 may display additional invoice items 1452 and 1454 as well as part of the NFC payer of the shared invoice item 1440. Also, as noted above, based on the total cost of the assigned invoice items, any applicable tax and tip amount may be automatically calculated, as indicated by reference number 1458. Thus, by summing the items, tax and tip amounts, the total amount for the partial invoice indicated by reference number 1460 can be displayed. Screen 1456 may also provide a graphical button 1462 that can delete assigned items from the current group transaction member, such as items that the initiator may have been misassigned. In order to continue the assignment of the remaining group invoice items 1130, the initiator may return to the screen 1400 by selecting the graphical button 1464.

As shown in the updated screen 1400, if all group invoice items 1330 are properly assigned, the initiator selects the graphical button 1466 to determine steps 1234-1240 in the method 1220 of FIG. 29. As noted above, the process of collecting payments from each of the group transaction members may be initiated. As shown in this figure, selection of graphical button 1466 may display screen 1470 on the initiator device. Screen 1400 may display graphical buttons, such as graphical buttons 1472, 1474, 1476, each of which may correspond to each of group transaction members 1402. For example, as described above, graphic button 1472 may correspond to an NFC payer, graphic button 1474 may correspond to a credit card payer, and graphic button 1476 may correspond to a smart card payer. As will be appreciated, the screen 1470 may not include a graphical button corresponding to the initiator, because the initiator has already received the group invoice 1080 in payment of the group invoice 1180 in the main transaction 1172. Because it fulfilled the part of the initiator.

Collection of payments from each of the remaining group transaction members, indicated by graphical buttons 1472, 1474, 1476, may be performed in accordance with one or more of the transaction techniques described above. For example, by selecting the graphics button 1472, the initiator can proceed to the screen 1480, which can display a plurality of graphics buttons 1462, 1484, 1486, 1488. Each of these graphical buttons may represent different ways in which payment can be obtained from the corresponding group transaction member. For example, graphical button 1462 may represent the techniques indicated by transactions 375, 376, 378 of FIGS. 12A, 12B and 12C, respectively. In addition, graphical button 1484 may represent the transaction techniques described above in connection with transaction 860 described in FIG. 20. In addition, graphical button 1486 is described in transactions 952 and 970 and may represent the functionality shown in FIGS. 23 and 24, respectively. As shown, the initiator may also have the option of receiving cash payments from the corresponding group transaction member by selecting graphical button 1488. Although not described in detail herein, the selection of graphical button 1488 will simply display a confirmation screen where the initiator can confirm receipt of the payment if a cash payment corresponding to the partial invoice amount has been sent from the group transaction member to the initiator. Can be. Finally, graphical button 1490 may cancel the current transaction or return to screen 1470 when the initiator is needed.

As mentioned above, the NFC payer may own the NFC payer device 92. Thus, the initiator may have an NFC connection (eg, 1196) between the NFC interfaces 60 of each device 10, 92 to exchange information about the partial invoice and the corresponding payment amount that may be selected by the NFC payer. One may decide to obtain a payment from an NFC payer by selecting graphical button 1462 to initiate a payment by setting. For example, as shown in this figure, selection of graphical button 1462 can display screen 1494 on initiator device 10. Screen 1494 may display notification message 1496, which is generally known to the initiator that an NFC connection 1194 may be established and a tap action on the NFC payer device 92 may be required. Can be informed. The screen 1494 may also include a graphical button 1498, such that the initiator may cancel the setting of the NFC connection 1196 as needed.

As shown in FIG. 28, if partial invoice 1 198 and payment information 1200 are exchanged between initiator device 10 and payer device 92, screen 1500 may be displayed on the initiator device. have. Screen 1500 may display an identifier 1502 of the initiator, an identifier of NFC payer 1504, as well as a payment amount that may correspond to the partial invoice amount 1460 shown on screen 1456 in FIG. 30H. have. Screen 1500 may also display a payment account selected by the NFC payer in accordance with the techniques described above, which may be the NFC payer's default payment account 554, as shown in FIG. 14E. Screen 1500 may also display the currently selected crediting account, which may be the default crediting account 216. Thus, as described above, in order to receive the payment amount 1460 provided by the NFC payer, the initiator selects a graphical button 686 to write the requested amount in the credit of the default crediting account 216. can do. Subsequently, if the transaction completes successfully, screen 1510 may be displayed on the initiator device. Screen 1510 may include a notification message 1512 that may generally indicate to the initiator that the amount 1460 owned by the NFC payer has been credited to the initiator's crediting account 216. In addition, the notification message 1512 may also indicate that a confirmation or receipt has been provided to the NFC payer. The initiator then returns to screen 1400 by selecting graphical button 1514 to collect the remaining payments from the smart card payer or credit card payer, or to cancel or terminate the transaction by selecting graphical button 1516. Can be.

Referring now to FIG. 30J, upon receipt of a payment by an NFC payer, the list 1402 on screen 1400 is updated as indicated by reference numeral 1518 to complete the transaction between the initiator and the NFC payer. Can be indicated. The initiator may then continue to collect the remaining outstanding partial invoices from the credit card payer and the smart card payer by reselecting the graphic button 1466. Upon selecting graphical button 1466 in FIG. 30J, the initiator may navigate to screen 1470. As shown in this figure, screen 1470 may be updated to reflect that the amount paid by the NFC payer has been received by the initiator. For example, the currently shown screen 1470 is updated to remove the currently displayed graphic button 1472 and only the remaining graphic buttons 1474 and 1476 are displayed, each of which is assigned to a credit card payer and a smart card payer. Outstanding payments that must be paid by

Here, by selecting graphical button 1476, the initiator may return to screen 1480 where the initiator can select an appropriate method for receiving payment from the smart card payer, as described above in FIG. 30I. For example, in this figure, the initiator may select graphical button 1484 to initiate receipt of a payment using the techniques described above with respect to FIG. 20. For example, upon selection of graphical button 1484, screen 1520 may be displayed on device 10, NFC interface on device 10 is currently active, and NFC connection 1196 is shown in FIG. 28. As shown, a notification message 1522 can be displayed instructing the initiator that it can be initiated by tapping the smart card 862 and the initiator device 10. Subsequently, if the information stored in the storage chip 864 of the smart card 862 is received by the initiator device via the NFC connection 1196 or the like, the screen 1500 may be displayed. As noted above, screen 1500 may display the identifier of the initiator, as well as the identifier of the smart card payer referenced at 1526. The screen 1500 may also display a payment amount 1528 that may correspond to the partial invoice the credit card payer is to pay. Thus, the initiator selects graphical button 686 to initiate the transaction permission actions described above, such as sending current information to financial servers 100, so that payment amount 1528 is credited to crediting account 216. Can fill in As shown in screen 1510, a notification message 1512 may be displayed if the current transaction has been successfully processed and an amount 1528 has been charged for the smart card 862. In order to complete the group transaction, the initiator may then select graphical button 1514 to return to screen 1400 and collect the final outstanding payment from the credit card payer.

Referring now to FIG. 30K, upon selection of graphical button 1514, screen 1400 may be updated and displayed on initiator device 10. As shown in this figure, the list 1402 on the updated screen 1400 may indicate that the partial invoice paid by the smart card payer has been received by the initiator, as indicated by reference number 1532. Thus, in order to collect the remaining payments paid by the credit card payer, the initiator can select the graphical button 1466 to access the updated screen 1470. As shown, the updated screen 1470 can now display only a graphical button 1474 that reflects the remaining payment that should be paid to the initiator. By selecting graphical button 1474, the initiator proceeds to screen 1480, and selects graphical button 1486, referenced 1540, and transactions 952, as shown in FIGS. 23 and 24, respectively. 970 may generally be used to obtain payment from the credit card payer's magnetic credit card 954 using the image processing and information extraction techniques described above. For example, the initiator device 10 may acquire the image 1212 of the magnetic credit card 954 using the camera 48 described above. Once the image 1212 is acquired by the initiator device 10, the image corresponding to the credit card account represented by the credit card 954 is imaged using one or more image processing techniques, such as the OCR techniques described above. Extraction from 1212.

Referring to FIG. 30L, when necessary credit card information is extracted from the image 1212, the screen 1060 described above with respect to FIG. 26D may be displayed. Although not shown here, it should be understood that various techniques described above for editing extracted card information for any inaccuracies that may have occurred during image processing and extraction steps 1540 may also be provided. In order to credit the partial invoice paid by the credit card payer to the credit account 216, the initiator may select a graphical button 686. Selection of graphical button 686 may navigate the initiator to screen 1066, which may perform one or more additional authorization actions that must be performed by the credit card payer before the transaction can be processed as described above. I can display it. For example, screen 1066 may require the credit card payer to enter an invoice amount in text field 1068 as well as provide a CVV code corresponding to credit card 954 in text field 1070. The credit card payer may also have the option of providing an email address in the text field 1072 that can be used to send a payment receipt to the credit card payer when the transaction is completed.

If the information required by the field displayed on screen 1066 is provided by the credit card payer, the rest of the transaction can be processed by selecting graphical button 1074. If the transaction has been successfully processed, a screen 1510 that includes a notification message 1512 that indicates to the initiator that the final payment received by the credit card payer has been received and is credited to the crediting account 216. May be displayed on the initiator device 10. The initiator may then select graphical button 1516 to end the transaction. Alternatively, when determining to return to the initiator angle invoice screen 1400, a popup window 1542 may be displayed, as shown in the current figure. Pop-up window 1542 can indicate to the initiator that all outstanding payments have been received from the group transaction members. The pop-up window is a graphical button 1544 that the user can select to initiate a subsequent group transaction and a graphical button that the initiator can accept to exit from the completed group transaction, for example to return to the home screen 29 of the device 10. (1546) may also be included.

Determination of each partial invoice in the group transaction described above is provided through the assignment of specific group invoice items as shown in FIGS. 30F-30H, although this technique is intended to provide only one example of one possible implementation. You have to understand. In fact, in further implementations, the transactional application 34 running on the devices 10 or 92 may allow the initiator or group transaction members themselves to specify partial payment amounts to satisfy their respective portions of the group invoice. have.

Referring now to FIG. 31, an alternative implementation of a system configured to perform the group transaction described above with respect to FIG. 28 is shown and generally indicated at 1560. The depicted transaction 1560 may differ from the transaction 1170 described above in that the merchant device 1176 may operate as the initiator device of the transaction that is currently described. In addition, in this transaction 1560, the device 10 may operate as a payer who makes a payment to a seller associated with a partial invoice. As will be appreciated, the presently described transaction does not include the primary transaction step 1172 and the secondary transaction step 1174 described in FIG. 28, but the credit card payer, smart card payer, NFC payer device 92. The NFC payer associated with the device may be completed in a single group of transactions in which a payment is received from each of the NFC payers associated with the NFC payer device 10. For the purpose of distinguishing between users of device 10 and device 92, each user of these devices is a first NFC payer (corresponding to NFC payer device 10) and an NFC payer device. Reference will be made to the second NFC payer (corresponding to 92). As noted above, the merchant device 1176 may establish an ad hoc network that may connect all capable devices participating in this transaction 1560. For example, as shown, device 10 and device 92 may connect to ad hoc network 1562 to reflect group invoices collectively representing the total amount to be paid by each of the currently described transaction members. Current invoice 1564 may be received. Further, as described above, the first and second NFC payers may, for example, reflect the allocation of invoice items to corresponding transaction members, as well as to reflect receipt of payments by the seller from group transaction members. Current invoice 1564 can be viewed, which can be updated in real time during the course of transaction 1560.

If all invoice items are properly allocated on the merchant device, partial invoices may be sent to each of the payers participating in transaction 1560. For example, a partial invoice corresponding to the amount to be paid by the first NFC payer indicated by reference number 1568 may be sent from the merchant device 1176 to the NFC payer device 10 via the established NFC connection 1566. have. As discussed above, establishing an NFC connection 1566 may require a tap operation between each of the payer device 10 and the merchant device 1176. Upon receipt of the partial invoice 1568, the first NFC payer selects a payment account on device 10 and sends payment amount information, indicated by reference number 1570, to merchant device 1176 via NFC connection 1566. Can transmit Subsequently, as described above, the merchant device 1176 may provide financial information via the network 1574, which may be provided by any suitable network described above, with transaction information 1572 that may also include a selected crediting account. 100). If the requested transaction 1572 is authorized by the financial servers, the payment indicated by reference numeral 1576 may be credited to the seller's selected crediting account. In addition, any payments received by the merchant device during the code of this transaction 1560 may be displayed on the current invoice 1564 that the first and second NFC payers are viewing via the ad hoc network 1562. As will be appreciated, the current invoice 1562 can be updated to reflect any outstanding payments already received.

The merchant device may then further send the partial invoice 1582 corresponding to the second NFC payer. For example, as shown in this figure, the partial invoice 1582 may be sent to the payer device 92 over the NFC connection 166. Thus, as described above, the second NFC payer can select the payment account indicated by reference number 1584 and send the corresponding information about the selected payment account to the merchant device, which then the merchant device for authorization and processing. Information 1572 may further be sent to financial servers. In addition, the merchant device may also receive payment information from smart card 862 via NFC network 1566. For example, as described above, using the NFC tap operation, information stored on the storage chip included in the smart card 862 indicated by reference numeral 1588 may be transmitted to the merchant device 1176.

Merchant device 1176 may also include a camera, such as camera 48 described above, that may be used to acquire an image of magnetic credit card 954. Once the image indicated by reference number 1590 is acquired, the image may be processed using one or more of the techniques described above to extract account information corresponding to credit card 954. As will be appreciated, payment information received from each of the payers participating in the group transaction 1560 may be sent to the financial servers 100 for processing. Thus, if the requested payments are authorized by the financial servers, the corresponding payment, indicated by reference number 1576, will be applied to the seller's selected crediting account as described above.

Referring now to FIGS. 32A-32D, a series of screen images depicting the operation of the merchant device 1176 in performing a transaction 1560, in accordance with further implementations of the presently described techniques. It should be understood that the merchant device 1176 may include a transactional application similar to the transactional application 34 described above with respect to the electronic device 10. For example, as shown in FIG. 32A, screen 110 may be displayed on merchant device 1176. By selecting the graphical button 114, the merchant can navigate to the screen 476, and further select the graphical button 482 to access the graphical buttons 1272, 1274, 1276 on the screen 1270. Can be. Here, the merchant may initiate a group transaction 1560 by selecting graphical button 1272 and proceeding to screen 1278.

As discussed above, screen 1278 may display several options for performing a group transaction. Here, as described above in connection with transaction 1170 of FIG. 28, instead of selecting graphical button 1280, the option represented by check box 1282 may be selected. Upon selection, the seller may further select graphical button 1284 to proceed with current transaction 1560. For example, the selection of graphical button 1284 can navigate the seller to screen 1594 shown in FIG. 32B.

As mentioned above, this transaction may occur in connection with a restaurant bill in which a list of tables at a restaurant location referenced by reference number 1596 is displayed. Each of the displayed tables may include an indicator regarding the status of members seated in each table. For example, a table may be indicated as "ready", meaning that customers have finished eating and are ready to pay the bill. In addition, empty tables may be indicated as "vacant" and tables that customers are still eating may be indicated as "at meal". For example, the table 1598 in the list 1596 may indicate that customers are ready to pay the calculation. As shown, by selecting the table 1594, the seller can navigate to the screen 1600. Screen 1600 may be similar to screen 1370 described above with respect to FIG. 30C in that the presently described screen may set up an ad hoc network to which other capable devices such as devices 10 and 92 can connect. have. The screen 1600 may display the identifier 1604 of the current transaction as well as the identifier of the seller 1602. As indicated by reference numbers 1608 and 1610, when all capable devices such as devices 10, 92 connect to the ad hoc network 1194, the seller selects the graphical button 1606 and is shown in FIG. 32C. You may continue to screen 1614.

As shown on screen 1614, a list of transaction members 1616 may initially be displayed that may initially include the first and second NFC payers. Screen 1614 may also display a list of group invoice items 1330. By selecting the graphical button 1406, the seller performs the functions generally indicated by the screen images in FIG. 30E to add the credit card payer and smart card payer to the current transaction, thereby group transaction members 1616. ) List can be updated. Then, if all group transaction members have been added to the current transaction, the seller may proceed with the assignment of group invoice items to corresponding transaction members. For example, as described above, various invoice items, such as invoice item 1430, can be assigned to each group transaction member using a drag / drop operation.

Referring now to FIG. 32D, the seller may continue to allocate all remaining group invoice items 1330 as shown in the updated screen 1614 of this figure. It should also be noted that the amount to be paid by each of the group transaction members 1616 may be updated during the allocation process. As discussed above, once the amounts of each partial invoice are determined, the seller selects graphical button 1466 and proceeds to screen 1620 where the seller collects the corresponding payments from each of the group transaction members. May be initiated. For example, the depicted screen 1620 may display graphical buttons 1622, 1624, 1626, 1628. As mentioned above, each of these graphical buttons may correspond to an amount to be paid by each of the group transaction members 1616. Thus, in a manner similar to the steps indicated by the screens shown in FIGS. 30I-30K, the seller collects payment from each of the group transaction members by selecting one of the graphical buttons 1622, 1624, 1626, 1628. can do.

Upon selection of one of the displayed graphical buttons 1622, 1624, 1626, 1628, payment information may be received from the selected group transaction member. Then, corresponding techniques for processing each transaction may be performed as indicated at 1630, depending on how the payment information is obtained. For example, as will be appreciated, the selection of graphical button 1622 may initiate an NFC payment request for the first NFC payer on device 10 via the NFC connection 1566 shown in FIG. Accordingly, the first NFC payer may provide the payment information to the merchant device 1176 via the NFC connection 1566 as indicated by reference numeral 1570 in FIG. 31. As understood, the seller may proceed to collect payments from each of the group transaction members until all outstanding payments have been received. In addition, although not shown in the figure, it should be understood that each of the group transaction members may have the option of specifying tip amounts before sending payment information to the merchant device 1176 as needed.

Once all outstanding payments have been received by the seller, pop-up window 1632 may be displayed on screen 1614. As shown in FIG. 32D, the pop-up window may instruct the seller that all outstanding payments have been received from group transaction members 1616. In addition, pop-up window 1632 may display a graphical button 1634 that allows the seller to initiate a subsequent group transaction and a graphical button 1636 that the seller can select to terminate the group transaction application. Although the present group transaction techniques have been described in particular with respect to assigning a restaurant bill in the embodiments shown in FIGS. 28 and 31, it is understood that the techniques can be applied to any group transaction situations involving multiple payers. You have to understand.

As shown in the presently described figures, the various functions described herein may be provided through a transactional application (eg, indicated by icon 34) stored on a device that includes one or more aspects of the present invention. Indeed, a transactional application is stored in one or more machine readable media, such as storage 54, and encoded instructions configured to be executed by processor 50 to provide one or more of the functions of device 10 described above. Can include them. It should also be appreciated that a transactional application may also include encoded instructions that define various graphical screen images and user interface functions described throughout this specification. However, it should be understood that the functions shown and described in the figures can be accomplished using various graphical elements and visual schemes, and the invention is not intended to be limited to the very user interface conventions described above.

While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and have been described in detail herein. However, it should be understood that the techniques described herein are not intended to be limited to the particular forms disclosed. Rather, the invention covers all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims below.

Claims (6)

A method performed by a computer system of a handheld electronic device manufacturer,
Providing a handheld electronic device configured to store payment account information, provide a list of selectable financial service providers, and display one of the financial service providers from the list as a designated default selection; And
Charging a first fee to a default financial service provider in exchange for specifying a default selection
And performed by a computer system of a handheld electronic device manufacturer. The method of claim 1, wherein each of the other financial service providers not designated as the default financial service provider in exchange for configuring the handheld electronic device to provide other financial service providers in the list of selectable financial service providers. Claiming a second fee, the method being performed by a computer system of a handheld electronic device manufacturer. 2. The method of claim 1, further comprising the step of charging an additional fee to the default financial service provider when a user of the handheld electronic device stores a payment account associated with the default financial service provider on the handheld electronic device. And computer system of a handheld electronic device manufacturer. The financial service of claim 1, wherein a payment account stored on the handheld electronic device and associated with the financial service provider is selected by a user of the handheld electronic device to make a payment in a transaction. Charging a transaction fee to one of the providers. The method of claim 1, wherein the financial service providers comprise at least one of a credit card provider, a debit card provider, a banking provider, or a combination thereof. 10. The credit card of claim 1, wherein the financial service provider is associated with an online digital media provider, the financial service provider is associated with a non-cash payment account, and the non-cash payment account is credit exchangeable by a user of the handheld electronic device. Comprising units, performed by a computer system of a handheld electronic device manufacturer.

Images