Patent Grant
8645222
In the present fast paced environment, people make a variety of purchases using traditional payment methods. To support such payment methods, an extensive financial infrastructure is utilized. For example, the credit card, and financial system associated therewith, is widely used. However, the current financial infrastructure is insufficient in some respects to provide desired convenience for people. For example, the ease and efficiency of performing routine transactions is lacking using various of today's commonplace technologies. Also, the tracking and recording of travel records, cost records, and similar records may be difficult and inefficient, especially for corporate travelers, who often maintain separate records for personal purchases and business purchases. Therefore, improvements to the current financial infrastructure is needed to accommodate the evolving needs of people in their busy and complex lives.
Computer implemented methods and systems for fulfilling a customer request for a requested item purchased from a merchant is provided. The method may be performed by a tangibly embodied processing machine disposed in a customer device. The method may include (1) observing, through the input of information, an observed event that is associated with a customer; (2) associating the observed event with a corresponding order record; (3) retrieving order information from the corresponding order record, the order information including at least customer financial entity account information; (4) generating a merchant request based at least in part on the order information in the corresponding order record, the merchant request including at least customer identification information and customer financial entity account information; and (5) outputting the merchant request to the designated merchant, so as to provide the designated merchant with information to fulfill the customer request.
A wide variety of other features and embodiments are disclosed.
The present invention can be more fully understood by reading the following detailed description together with the accompanying drawings, in which like reference indicators are used to designate like elements, and in which:
b) is a block diagram showing a mobile-payment system 100′ in accordance with an embodiment of the invention;
a)-33(f) are figures showing a user scenario in which a mobile-payment device is configured and used to perform mobile-payment (mPay) processing, in accordance with one embodiment of the invention.
a)-34(g) are figures showing a further user scenario in which a mobile-payment device is configured and used, in accordance with one embodiment of the invention;
a)-35(k) are figures showing a further user scenario in which a mobile-payment device is used in location based ordering and payment, in accordance with one embodiment of the invention;
a)-36(k) are figures showing a further user scenario in which a mobile-payment device is used in web based ordering and payment, in accordance with one embodiment of the invention;
a)-37(k) are figures showing a further user scenario in which a mobile-payment device is used in restaurant ordering and payment, in accordance with one embodiment of the invention;
a)-38(f) are figures showing a further user scenario in which a mobile-payment device is used in setting rules and fraud alerts, in accordance with one embodiment of the invention;
a)-39(k) are figures showing a further user scenario in which a mobile-payment device is used in open bar tab ordering and payment, in accordance with one embodiment of the invention;
a)-40(l) are figures showing a further user scenario in which a mobile-payment device is used in bill sharing, in accordance with one embodiment of the invention.
a)-41(i) are figures showing a further user scenario in which a mobile-payment device is used in performing person to person payment, in accordance with one embodiment of the invention; and
a)-42(g) are figures showing a further user scenario in which a mobile-payment device is used to perform payment at a point of purchase, in accordance with one embodiment of the invention;
Hereinafter, aspects of the inventive mobile-payment system in accordance with various embodiments of the invention will be described. As used herein, any term in the singular may be interpreted to be in the plural, and alternatively, any term in the plural may be interpreted to be in the singular.
The invention provides for a mobile-payment system and related processing of transactions, with enhanced convenience and record keeping capabilities, as well as various other features. For example, in accordance with some embodiments of the invention, a customer, i.e., a user, is enabled to identify an item to purchase, effect an event to trigger a transaction to purchase the item from a merchant, settle the transaction with the merchant and a financial entity over a payment network using a customer device without having to deal with any physical handling of a funds transfer, and secure the item. Various other processing is described.
The “customer device” or similar term as used herein may include any mobile device, cell phone, land phone, smart phone, car phone, computer terminal, texting device, RFID (Radio-frequency identification) device, GPS (Global positioning Satellite) enabled device, PDA (personal digital assistant), satellite radio device, voice over IP device, and/or any other device that is adapted to perform processing as described herein.
A customer may interface with a customer device using any of a wide variety of ways depending in particular on the capabilities of the customer device and/or what applications are utilized by the customer device to interface with the customer. Accordingly, for any of the features described herein the customer device might interface with the customer using any of key sequence, key strokes, presentation and selection of icons or other graphical representation, touch screen, voice recognition, a device utilizing textile features, LED (light-emitting diode) enabled device, push notification enabled features, media message enabled features, and/or any other type of interface that allows the customer to communicate information to and from the customer device.
Further, any communication channel or communication protocol that is associated with such a customer device may be utilized. Such customer device may effect the communications, as described herein, using any suitable data, such as numbers, characters, transmission and/or signal, for example. Any “number” as described herein may include any characters including in particular alphanumerics.
The “payment network” or similar term as used herein may include a telecommunication payment network, a telecommunication network, a payment network, Internet, extranet, intranet and/or some other network or part of a network that provides for communications to effect a transaction, for example. Relatedly, the use of a VISA or MASTERCARD network is described herein, for example. However, it is appreciated that other payment networks may well be used that have none or only some relationship to VISA or MASTERCARD, or with AMERICAN EXPRESS or DISCOVER, for example. For example, a particular bank or other financial entity may well utilize a network maintained by such particular bank or other financial entity.
A transaction as described herein may be funded by an available “payment mechanism.” A “payment mechanism” (i.e., a payment method) or similar term as used herein may include any of a credit card, debit card, gift card, stored value card, rewards card, stored benefit card, store card, club card, prepaid card, points card, some other type of card, some other account (e.g., checking or saving), PAYPAL account, food stamps, tab, and/or any other arrangement which results in a debit being accorded to an account associated with such arrangement, i.e., such debit being in the form of monetary funds, points, or some other accounting mechanism, for example.
A transaction might be initiated by any methodology as desired such as the customer running a card through a magnetic reader, some other type of card swipe, physical entry of a sequence (e.g. a PIN (personal identification number) at the POS), the customer tapping his customer device against a contactless card reader, interfacing with a reader in some other manner either wirelessly (e.g. BLUETOOTH) or by physical contact, an observed position or orientation of the customer device, any other manner as described herein, and/or in any other manner such that an event may be observed so as to initiate a desired transaction.
A “financial entity” or similar term as used herein means any financial institution that maintains or is associated with a payment mechanism of a customer from which funds or points are drawn to fund the activity as described herein. Accordingly, a financial entity may include a traditional bank such as JPMorgan Chase and/or a payment entity such as PAYPAL, for example.
As described herein, it is appreciated that the mobile-payment system may be used with a wide variety of merchants. A “merchant” or similar term as used herein means any entity that offers an item for purchase. The merchant might include any restaurant, coffee shop, or quick service related merchant, for example. The item for purchase may be any product, service, widget, or any other output that is available for purchase, for example. The particular processing described herein in connection with the purchase of one item of course may be used with any other item. For example, while various processing is described herein in connection with the purchase of coffee related items, such described processing may be used for the purchase of any other item.
As used herein, data, information, and similar terms have been used interchangeably.
As used herein, “communicates”, “interfaces”, “transmits”, inputs/outputs and similar terms have been used interchangeably.
As used herein, mobile-payment, mobile-pay, mPay and similar terms have been used interchangeably.
It is appreciated that any feature described herein may be used in conjunction with any other feature described herein.
As described in detail below, a merchant, such as a restaurant, may be provided with processing capability to perform the processing described herein so as to be a “mobile eligible restaurant”, i.e., a mobile-payment eligible or mobile-payment restaurant, for example. In accordance with one illustrative embodiment of the invention, a customer might first confirm that the restaurant (at which they are planning to dine) is such a “mobile eligible restaurant”. This might be performed, for example, by sending an “alert” to the customer as they walk into the particular restaurant.
In this example, in conjunction with placing an order with a waitress, the customer indicates that they participate in mobile-payments, i.e. a “mobile-payment” program, and agreement is reached between the customer and the waitress that the mobile-payment program will be used to effect the transaction, i.e., to pay for lunch. The customer proceeds with ordering, i.e., they order their lunch by verbally conveying the requested lunch items to the waitress.
The waitress then goes back to interface with the restaurant's collection/order system (e.g. a physical kiosk or other tangibly embodied system) and enters in the requested order. In addition, the waitress enters information that conveys that the order is in the mobile-payment program, as well as information to convey the identity of the customer. For example, such information might include a “mobile-payment program number” of the customer or some other number or identification of the customer.
At a point (or in an ongoing manner) the purchase information (i.e., the data regarding the items purchased at lunch) is transmitted from the restaurant's system to the payment network. Thereafter, data is transmitted from the payment network, and a financial entity such as a card issuer bank, to the customer device, such that the customer can review/confirm the purchase information. That is, the customer can review and verify that the merchant has entered the correct products or services into their collection/order system. Upon completion of ordering items at the restaurant, the customer can close out the purchase—completing the transaction. With the transaction thus being completed using the “mobile-payment” program, no further action is needed by the customer, i.e., prior to the customer leaving the restaurant.
In an exemplary embodiment, the customer may have one or more payment mechanisms, i.e., payment methods, associated with the “mobile-payment” program from which the customer may provide funds needed for a purchase. Other allocations/selections may be presented to the customer, i.e., such as whether to allocate a particular purchase to their personal recordkeeping log or business recordkeeping log, for example.
In order for merchants and customers to participate in the “mobile-payment” program, the merchant/customer may be required to initially register with the mobile-payment program, i.e., at some time prior to performing a transaction. In conjunction with the registration, or at some time after registration, the customer may download (or in some way activate) an application programming interface (API) of the payment network on the customer device. Merchants may also secure a suitable API. The API may thus provide the various features and customer experiences as described herein.
The customer device may transmit one or more authorization messages to the payment network to authorize the payment network to pay the merchant. Also, the customer device may directly provide the authorization messages to the collection/order system of the merchant and allow the merchant to provide the authorization messages to the payment network to collect the payment. Various other features are provided. For example, variations of the data transmitted between the customer device, restaurant, payment network, and financial entities i.e., the customer's card issuer/financial entity for example, are provided.
Accordingly, the systems and methods of the invention relate to a variety of processing, in particular in conjunction with a customer device. In accordance with one aspect of the invention such processing generally deals with the initiation of a payment event at a point of sale, identifying that the payment event is happening, and being able to intercept and hold the payment event at particular stage(s), at which point desired processing is performed. In summary, the invention might be characterized as a type of “enhanced transaction processing layer,” which supports the various offered functionality.
Such functionally may relate to customer ordering and related processing, customer payment related processing, use of rules in payment scenarios, the use of coupons (including URL and decay processing), the sharing of information (e.g. tell your friends you're at the local coffee house), GPS and other location related processing, use of photo/imaging technology, various authentication processing (including two key authentication), offer matching, integration of multiple customer devices, and various other experiences/processing, for example.
In short, aspects of the invention relate to an extensive set of integrated customer experiences that the financial entity, for example, can drive, i.e., when able to accurately initiate an experience using a payment event, inclusive of the various steps involved in such payment event.
b) is a block diagram showing a mobile-payment system 100′ in accordance with an embodiment of the invention. As shown, the mobile-payment system 100′ includes an MP processing portion 200′. The MP processing portion 200′ includes an mPay system and services portion 202 and an mPay device interface portion 204.
The mPay system and services portion 202 and the mPay device interface portion 204 may be characterized to constitute a front-end system and a back-end system, respectively. The processing performed by the MP processing portion 200′ may be allocated to the mPay system and services portion 202 (front-end system) and the mPay device interface portion 204 (back-end system) in a variety of ways—to provide efficient and effective processing. For example, the mPay system and services portion 202 may be disposed in the authorization transaction flow to input a requested transaction, perform initial processing, and interface with an issuer of a card used in the transaction. On the other hand, the mPay device interface portion 204 may be provided to, based on the transaction information it receives from the mPay system and services portion 202, interface with a variety of back-end systems to secure information to satisfy the controlling instructions of the customer. That is, a set of instructions, to use in processing the requested transaction, may be provided by the mPay system and services portion 202 and/or the mPay device interface portion 204, i.e., by the front-end system and/or at the back-end system. In general, the mPay system and services portion 202 and the mPay device interface portion 204 may interface to exchange a variety of information, in conjunction with processing a transaction.
In the embodiments described below, various architectures are set forth to provide mobile-payment processing. Some embodiments include the architecture of a front-end system and a back-end system, i.e., akin to
However, many embodiments provide one core architecture pattern of the invention. That is, a basic architecture pattern of the invention includes inputting a purchase event with an amount of money associated with it, referencing a set of instructions that the customer wants to perform in conjunction with that purchase event, and going ahead and performing those instructions for the purchase event, through interfacing with a series of back-end systems.
Within this basic architecture pattern, differences in the processing of various types of transactions relate to the manner in how the particular transaction comes in to the mobile-payment processing portion. That is, sometimes a transaction may come in though a traditional point of sale cash register type device at a merchant, for example. Alternatively, sometimes a transaction may come in from two different areas, i.e., information for the transaction comes in from two or more sources (one of which might be the merchant). This information from multiple sources then is matched up in processing the transaction. Different embodiments also relate to the manner in which the processing is allocated between respective processing portions, e.g. allocated between a front-end system 202 and/or a back-end system 204 as depicted in
In accordance with one embodiment of the invention,
In accordance with one embodiment of the invention, as shown at (1), the processing is initiated when the customer, i.e., the user, uses existing POS (Point of Sale) technology to initiate the transaction, such as by tapping his customer device against the contactless card reader to initiate the transaction.
At (2), the mPay transaction (i.e., the mobile-payment system 100′) uses a Visa/MasterCard Bin to route across the particular association network (i.e., the payment network) to the mPay system 200. As delineated at (3), the mPay system and services portion 202 is positioned within the authorization transaction flow to input the transaction.
At (4), the mPay system and services portion 202 evaluates the transaction against the customer's configuration. Such customer's configuration may be stored in a “record table” in a “customer record,” in accordance with one embodiment of the invention, as described in detail below. In turn, the “customer record” includes “order records,” as also described below with reference to
At (5) The mPay system and services portion 202 sends a communication to the mPay device interface portion 204 requesting such card information.
At (6) The mPay device interface portion 204 communicates with Chase servicing to secure the needed information. The information indicates that the card to use in the particular time window (i.e., the time of day that the transaction was effected) is the customer's CHASE FREEDOM CARD.
At (7) The mPay device interface portion 204 communicates the needed information back to the mPay system and services portion 202.
At (8), based on the customer's configuration information, the mPay system and services portion 202 converts the mPay account number to the customer's identified Chase Freedom Card and (9) routes the authorization to the issuer, or other designated entity, for approval.
At (10) the transaction is processed by the issuer of the customer's CHASE FREEDOM CARD and results are transmitted back across the payment network (such as a Visa/MasterCard network) via the mPay system and services portion 202 to the merchant.
At (11) the mPay system and services portion 202 creates a content rich digital receipt for the transaction, including merchant specific content such as a Merchant logo's, for example.
At (12), the mPay system and services portion 202 forwards the receipt to the mPay device interface portion 204 to append further information
At (13) The mPay device interface portion 204 appends further information to the receipt, including at (14) pulling contact information from a “location information” external source. Such location information relates to the location particulars of the merchant, for example
At (15) in
As described in detail herein, there are numerous variations to the above processing. In accordance with one embodiment of the invention, the mPay system and services portion 202 and/or the mPay device interface portion 204 may be used so as to provide a desired processing speed in responding to transaction requests. To explain, a response time may be desired that approaches real-time response. As used herein, “real-time” means a range from fractions of a second to a few seconds after a prior event has occurred. In order to provide such real-time capability, it may not be workable for the mPay system and services portion 202 to input the transaction request; then communicate with the mPay device interface portion 204 to retrieve information to process the transaction request. Also, there may not be processing time to provide for the mPay device interface portion 204 to communicate with external systems to secure further needed information. In order to provide such real-time processing, the mPay system and services portion 202 may handle the transaction request on its own, without interfacing with the mPay device interface portion 204 or external systems. Relatedly, certain tradeoffs may be imposed. For example, in order to provide real-time processing, the functionality provided by the MP processing portion 200′ may be limited in some manner.
In accordance with other embodiments of the invention, either the mPay system and services portion 202, the mPay device interface portion 204, and/or other processing portions in the MP processing portion 200′ may hold transaction information (relating to a requested transaction) until such processing portion receives further information from another processing portion. In other words, a first processing portion may sit waiting for information from a second processing portion. Illustratively, in
In the embodiment of
A wide variety of embodiments of the invention are described below.
With further reference to the processing of the embodiment of
In accordance with one embodiment of the invention, after being seated, the customer first verbally orders lunch by talking with a waitress, and the customer conveys to the waitress that they would like to use the “mobile-payment” program, as shown in step 12 of
Then, in step 16, in accordance with one embodiment of the invention, the merchant system 130 transmits the information regarding the order to the MP processing portion 200 (which in this embodiment is in the customer's cell phone (customer device 120), for example). As reflected in step 18 of
Thereafter, in step 22, the merchant system 130 interfaces with the financial entity processing portion 140 to secure approval of the debit (of the user's account) associated with the transaction, i.e., based on the billing information that was input from the MP processing portion 200.
Also in step 22, the merchant system 130 presents confirmation to the waitress that the transaction has been approved. Also, as shown in step 24, a communication may be sent to the MP processing portion 200 (for presentment to the customer via the customer device 120) that the merchant system has received approval for lunch, and that the transaction is complete.
Such described processing, including presenting the customer with the details of the order and securing authorization from the financial entity processing portion 140 may be done once at the conclusion of a lunch, for example, or might be done in an ongoing or periodic manner, e.g. as further items are ordered.
In step 26 of
In accordance with a further embodiment of the invention, it is appreciated that processing similar to that shown in
At the termination of the customer experience at the particular merchant, the customer would take some action to indicate such. Such action might include interfacing with their customer device 120 to indicate that the experience was to terminate and that the amount due should be settled. Thereafter, processing would be performed to complete the transaction, including communications between the customer device 120, the merchant system 130, the MP processing portion 200 and the financial entity processing portion 140.
It is appreciated that the described or similar functionality might be utilized in a variety of environments. In accordance with one embodiment of the invention, a movie theater may be provided with a MP processing portion 200 at a particular entrance to the theater, labeled as such. Upon the customer's approach to the entrance, the MP processing portion 200 would sense the customer device 120, and communications would be initiated between the customer device 120 and the MP processing portion 200. Once adjacent the MP processing portion 200, the customer might be prompted to take some action with the customer device 120 vis-à-vis the MP processing portion 200 so as to pass into the theater. For example, such action might be a flick of the customer device 120 or a tap on an icon displayed by the customer device 120. Such processing could be performed on a number of persons basis, i.e., by indicating how many persons should be admitted and the corresponding amount charged. Alternatively, the customer might perform the designated action for each person, i.e., to allow payment (by the customer) of persons amongst persons who the customer is not paying. In other words, the processing would allow: the customer to pass with flick/payment, friend 1 to pass with flick/payment, stranger to pass without payment, and friend 2 to pass with flick/payment. Such processing might be used in a wide variety of environments such as in a transit authority/metro environment in passing through a turnstile, in an entertainment venue such as an art gallery or theme park, and/or in conjunction with interface with a vending machine (such as to purchase a ticket, candy, drink, rent a movie and/or any other item), for example.
As reflected in
Thereafter, as shown in
However, the processing as shown in
In accordance with other embodiments of the invention, and different user experiences, other sequences of communications may be utilized.
That is,
As shown in
Thereafter, as shown in
That is, in the process of
In accordance with one embodiment of the invention, the customer device 120 may be provided with functionality to interface the customer with particular administrative persons or systems. For example, if the customer device 120 receives a communication indicating that a transaction has been denied, then functionality may be provided to generate a button to contact a customer service person, i.e., the customer might tap the button on their mobile device and a call is put through to customer service. In general, such processing may utilize a rule set that is responsive to particular observed criteria. When such particular criteria is observed, the customer device 120 responds by initiating a communication to a particular person or system. Such initiating might be performed by generating a tap button, a prepared text message or in some other manner. For example, a message displayed with the button might read: “You have been declined—tap here to find out why.” In response to tapping such button, the customer might be connected with a live representative, a chat room, or be sent an automated message, for example. In such manner, the customer may be connected to a financial entity involved in the transaction, the particular merchant and/or some other third party entity. Assuming the financial entity processing portion 140 approved the transaction, after receiving the approval, the MP processing portion 200 generates a communication (4) that is sent to the merchant system 130. The communication (4) might be characterized as a merchant request. The merchant request (4) conveys information to the merchant system 130 including that the requested transaction has been funded, i.e., that an account of the customer has been debited for the requested item, as well as the particulars of the requested item. For example, the particulars may be the particular coffee drink that the customer has requested.
In accordance with one embodiment of the invention, as shown in
As described further below, in accordance with embodiments of the invention, information may be captured, sorted and/or allocated in a variety of manners. In particular, transaction/receipt information may be captured, sorted and/or allocated.
In further illustration of the invention, and as described below with reference to
For example, in accordance with one embodiment of the invention, the customer is in route to the particular merchant. Once the customer has passed a particular estimated time of arrival (ETA) such as ten minutes, for example, the customer enters the predetermined keystroke (into their cell phone) so as to request their desired favorite. In response, a communication is sent to the particular merchant to proceed with preparing the customer's desired item, e.g. the customer's desired coffee drink, for example. A communication is also sent to the appropriate financial entity processing system, i.e., so as to effect the transaction that is to fund the purchase of the desired item.
Once the communication is received by the financial entity processing portion, the financial entity processing portion (in response) effects the transaction to fund the purchase. For example, the financial entity processing portion debits a predetermined credit card account of the user or in some other way effects the funds transfer (to fund the desired transaction) using any of a wide variety of payment mechanisms.
On the other hand, once the communication (including requested item information and financial entity account authorization) is received by the particular merchant, the merchant knows that the customer will be arriving shortly (e.g. in the ten minutes), and prepares the desired item accordingly. Thereafter, the customer arrives, and the coffee drink is “ready and waiting” for pick-up, having been already paid for.
In accordance with one embodiment of the invention, the initial communication from the customer device is forwarded to a “mobile-payment” processing portion. Once received, based on the customer information in store (i.e., stored in a suitable database from the data input at customer registration, for example), the “mobile-payment” processing portion then forwards the appropriate communication to the financial entity, as well as the appropriate communication to the merchant processing system, as described.
Accordingly, in accordance with one embodiment of the invention, the mobile-payment processing portion 200 may secure authorization for the transaction from the financial entity processing portion prior to forwarding the communication to the merchant, i.e., as shown in
Note that any of a wide variety of authentication techniques may be used in the systems and methods as described herein. In particular, various techniques may be used to either authenticate the user to the merchant and/or to authenticate the user to the financial entity, i.e., to process a requested transaction.
It is further appreciated that any of a variety of communication processing may be used in conjunction with the features described herein. Various such communication processing is described throughout the present disclosure. For example, the features described herein may be used in conjunction with the features described in U.S. Pat. No. 6,535,855 to Cahill issued Mar. 18, 2003 entitled “Push Banking System and Method”, which is incorporated by reference herein in its entirety. In summary, in accordance with one embodiment of the invention, the mobile-payment system allows a customer, with a few simple keystrokes to a cell phone, to arrange the purchase of a desired item with minimal effort, and without having to deal with any physical handling of a funds transfer. Additionally, the systems and methods of embodiments provide for various other features.
In the example described above, the customer enters a keystroke into their cell phone to initiate the order of a desired item. However, various other arrangements may be utilized. For example, the mobile-payment system 100 might utilize Global Positioning System (GPS) technology. For example, the customer's position in their car may be monitored such then when the customer comes to within a predetermined proximity of the merchant, the customer's order is automatically initiated and processed. Relatedly, an order might be triggered when the customer enters into, or passes through, a particular geographical area, i.e., when the customer drives down a particular road. In this example, as well as in the other processing as described herein, the mobile-payment system 200 may utilize a variety of rules. For example, a rule might dictate that only when the customer is within proximity of the merchant during a certain time window (e.g. 6:30 am to 7:30 am on a weekday), will the order be put through. Alternatively, a rule might dictate a first item order (i.e., to be ordered) when the customer approaches the merchant on the weekday, and dictate a second item order when the customer approaches the merchant on the weekend. A wide variety of rules might be utilized as desired, and such rules may be dependent on various parameters as desired, such as geographical position, direction of travel, time of day, day of the week, attributes of the customer device 120, and/or other parameters. Such processing may utilize a customer record table 252 (as described further below) to map observed events into a trigger—to order a particular item. Alternatively, certain observed events might trigger an order in some other manner. In accordance with one embodiment of the invention, customer confirmation of the placement of a particular order might be required, based on customer preference.
In accordance with one embodiment of the invention, the merchant might receive the above described communication (as shown in
In further explanation, in accordance with one embodiment of the invention, the merchant system 130, upon receipt of a “mobile-payment” request may print a “tab” that is used by the merchant worker in preparing the requested item. The tab might be in any of a variety of forms such that information associated with the tab (by the merchant system 130) may be associated with the physical requested item. In one form, the tab might be a small sheet of paper with the needed information printed thereon. The sheet of paper might be provided with an adhesive surface so as to be affixable to the customer's purchased item, e.g. a “sticky tab” affixed to the customer's coffee drink. It is appreciated that any information regarding the customer's purchase that is contained on a printed tab may alternatively be simply provided on the merchant's system (e.g. on a computer display) and vice-a-versa. Further, there may be multiple tabs printed for a particular purchase. One tab may contain the order information with the customer's name, picture, and requested item, while a second tab (to be affixed to the same requested item) contains a targeted ad or some other promotional content. Other tabs containing other content may also be provided. Further, a single tab might contain multiple orders.
The tab that is affixed to the requested item may contain information such as time to begin to prepare the requested item, time that the requested item should be ready for pick-up, a nickname (i.e., an alias such as “RoadWarrior”) to call the customer's order out, a picture of the customer, some other manifestation of the customer such as a caricature, and/or any other information to identify the customer. Further, the information on the tab might contain other information, such as targeted add information, a “saying of the day,” information regarding the customer's account (from the financial entity processing portion 140), information regarding the customer's buying experience or history at the merchant (from the merchant system 130), and/or any other information that might be associated with the user (e.g. based on a user's profile) and/or useful/enjoyable by the user or the merchant.
It is also appreciated that any of such information that might be printed on the tab, might also be presented in some other manner, such as via a merchant terminal, for example.
Relatedly, in accordance with one embodiment of the invention, the MP processing portion 200 provides for a user to upload information, i.e., any of the herein described information that might be affixed to a tab, such that the uploaded information may be presented to the merchant as described herein. For example, the customer might upload their picture so as to be displayed to the merchant worker, or so as to be printed on the tab, as described above.
In accordance with one embodiment of the invention, the placement of an order (such that the mobile-payment system 100, i.e., the MP processing portion 200, forwards a respective communication to the merchant system 130 and financial entity processing portion 140), might be triggered by interface of the customer device 120 with a device at the merchant. For example, the customer device 120 might interface with the merchant via RFID (Radio-frequency identification) technology, such that the customer does not need to wait in line, for example. It is appreciated that known RFID technology may be used in conjunction with the features described herein. For example, the features described herein may be used in conjunction with the features described in U.S. patent application Ser. No. 09/630,595 filed Aug. 1, 2000 entitled “System and Method for Transponder-enabled Account Transactions”, which is incorporated by reference herein in its entirety. As described above, to fund the desired transaction, the financial entity processing portion debits a predetermined account of the user to effect the funds transfer. It is appreciated that any of a wide variety of payment mechanisms may be used as described herein.
In conjunction with a mobile-payment transaction, it is appreciated that there may be a wide variety of communications utilized in the mobile-payment system, such as between the customer device, MP processing portion, financial entity, and the merchant, for example. As described herein, such communications may provide various information between the customer and the merchant, for example, such as that the desired item is ready for pick-up, the name or alias of the customer to call out once the item is ready for pick-up, a time that the item will be ready for pick-up, the merchant is unable to provide the item at the current time (e.g. the coffee house is out of muffins), the customer has arrived outside the merchant's business, and/or any other desired communication/information. Such communications may be utilized to resolve the disposition of an order. For example, if a customer has not picked up a prepared requested item, a communication may be sent to the customer requesting confirmation that the customer is coming, or in some other manner resolve the disposition of the order, e.g. using a set of rules/protocols. Further, such rules/protocols may vary based on particular parameters such as the customer location, device that the customer is using, nature of the product (e.g. shelf life of the product), time of day/week, and/or customer preference, for example. Once a given number of reminders are sent, a final communication may be sent to cancel a pending order. In general, in the various embodiments described herein, rules may be implemented to enhance the customer experience and avoid disconnects and/or shortcomings between a placed order, a paid for item that is not picked up, a customer's anticipation of an order that is not ready and/or other expectations of the customer or merchant.
The systems and methods of embodiments may be provided with functionality to prevent fraud. If fraud is suspected, suitable communications may be sent to the customer or other entity for investigation.
Further,
As shown in
The communication portion 210 performs various processing to provide communications between the MP processing portion 110 and other processing portions, such as the customer device 120, the merchant system 130, the financial entity processing portion 140, and any other system and/or resource, such as a data resource disposed on the Internet. In accordance with embodiments of the invention, the transaction request generation portion 220 generates a “transaction request” to be sent to the financial entity processing portion 140, in conjunction with a mobile-payment request. The merchant request generation portion 230 prepares a “merchant request” to be sent to a merchant, in conjunction with a mobile-payment request.
As described herein, the MP processing portion 200 might first send a transaction request to the financial entity processing portion 140 (and secure an approval for the requested transaction) and thereafter forward the merchant request to the merchant (with both information regarding the requested item AND information indicating the financial entity approval for the transaction), i.e., see
As described above, the MP processing portion 200 includes the mobile-payment database 240. The mobile-payment database 240 includes various data used and/or generated in the mobile-payment processing. In particular, the mobile-payment database 240 includes the customer information database 250, the financial entity information database 260 and the merchant information database 270, each of which are described below. In particular, the customer information database 250 includes various information about the customer including the customer profile information, i.e., customer personal information and the various customer ordering information including customer preferences. For example, customer information might include a physical description of the customer, address, phone numbers and other contact information, that they should only be contacted between 8 am and 5 pm and by e-mail, for example. The financial entity information database 260 includes various information regarding the financial entity from which the funds will be drawn to fund the mobile-payment activity of the customer. Thus, the financial entity (FE) information database 260 might contain the information needed to contact a particular financial entity in conjunction with processing a mobile-payment request.
The mobile-payment database 240 may also include various other data and/or database, as desired or needed, to contain further data used by and/or generated by the MP processing portion 200. For example, the mobile-payment database 240 may contain various data relating to: payment systems, payment associations, payment technology services, coupon related processing, receipt data, VISA, MASTERCARD, AMERICAN EXPRESS, DISCOVER, particular point of sales, and particular point of sale devices including attributes/capabilities of a particular type of phone for example. Such data may be in the form of tables, a relational database or some other arrangement such that the MP processing portion 200 can retrieve and use such data as needed.
As described above, it is appreciated that the mobile-payment system 100 may be used with a wide variety of merchants. For example, the mobile-payment system 100 might be used with any merchant including any restaurant, coffee shop related merchants, and any other quick service related merchants, for example. However, various other merchants may support the mobile-payment system 100 as is desired.
It is appreciated that the mobile-payment database 240 may use a wide variety of database structures and arrangements, such as relational database arrangements. Such database structures and arrangements may be used by the MP processing portion 200 to associate various information and to selectively parse out and use information, as needed, for example. Relatedly, in accordance with one embodiment of the invention, the customer information database 250 utilizes what is herein characterized as a “customer record table” 252 and an “order record table” 254. Various further details of the tables 252, 254 are described below.
The database 240 further includes the merchant information database 270. The merchant information database 270 includes various information regarding the merchants that participate in the mobile-payment program, such as contact information, menu information (i.e., what items are available through the mobile-payment program), settlement information (e.g. such as particulars relating to ACH and wire transfers), merchant blackouts, and promotion information, for example.
As described above,
In step 34, the MP processing portion 200 processes the customer request. Such processing includes various features as described below. In particular, such processing includes the generation and output of a transaction request to the customer's financial entity, i.e., for approval of the requested transaction. Further, assuming approval of the requested transaction, the MP processing portion 200 then generates and outputs a merchant request, which is sent to the particular merchant from which the requested item is to be purchased. Then, the process passes to step 36. In step 36, the designated merchant receives the merchant request, and effects fulfillment of the customer request for the “requested item.” In accordance with one embodiment of the invention, the requested item is prepared and held for pickup at the counter of the particular merchant. In other embodiments, various other arrangements may be made for delivery of the requested item to the customer, i.e., such delivery inclusive of delivery to the customer's home, to the customer's business, and/or delivery to the customer at the merchant's physical place of business, the latter inclusive of the common in-store purchase, for example.
In accordance with an alternative embodiment of the invention vis-à-vis step 34 of
After step 36 of
As noted above, in accordance with one embodiment of the invention, the customer information database 250 utilizes what is herein characterized as a customer record table 252 and an order record table 254.
That is, in accordance with one embodiment of the invention, the customer record table 252 of
The customer record table 252 also includes a listing of order records 255. In accordance with one embodiment of the invention, a particular combination of customer number, device number, and/or observed event, results (upon the MP processing portion 200 inputting such data) in a particular order record 255 being retrieved for processing. In other words, a particular combination of customer number, device number, and/or observed event (hereinafter characterized as “dictating parameters”) is input (by the MP processing portion 200) and the MP processing portion 200 uses such input information (dictating parameters) to map to a particular order record 255. Thereafter, the particular order record 255 is retrieved, and processed so as to fulfill the customer request.
Illustratively, assume that the MP processing portion 200 is physically disposed in a financial entity facility. A customer generates a mobile-payment “customer request” by calling into the mobile-payment portion and entering in a key sequence. In such communication between the customer device 120 and the MP processing portion 200, the MP processing portion 200 also inputs the primary customer identification (C11111), the secondary identification (i.e., the device number—D111), as well as the observed event (key sequence 1234). Using the input information, the MP processing portion 200 maps such information into a particular order record 252, i.e., the order record MP111.
Once the mapping is done, the MP processing portion 200 retrieves the particular order record 255. Thereafter, the transaction request generation portion 220 (in the MP processing portion 200) generates a transaction request 222 based on the information in the order record. The generation of the transaction request 222 includes the transaction request generation portion 220 determining the requested item from the particular retrieved order record 255 and pulling further information (e.g. from stored data) to determine the cost of such item.
As a further example, in accordance with one embodiment of the invention, the MP processing portion 200 receives a communication from a merchant, participating in the mobile-payment program, that includes a customer ID (C22222). The MP processing portion 200 identifies that the communication was indeed received from a merchant. Based on such data and the customer record table 252 for the customer C22222, the MP processing portion 200 maps to Record MP223. Thereafter, the MP processing portion 200 retrieves such record from the order record table 254. Based on such record, the MP processing portion 200 retrieves the appropriate account number to bill, and forwards such back to the merchant system 130 (assuming that the customer approves the requested transaction, i.e., by interfacing with their customer device 120 to indicate such approval).
Assuming approval of the requested transaction, the merchant request generation portion 230 then generates a merchant request 232. The merchant request 232 is prepared to convey the needed details of the customer request to the designated merchant, i.e., the merchant that will satisfy the customer request and prepare the requested item for pick-up by the customer.
Once the merchant request 232 is generated, the merchant request generation portion 230 sends the merchant request 232 to the particular merchant. For example, the merchant request generation portion 230 might pull contact information for the merchant from a database (containing such information) based on the merchant ID.
The merchant, upon receiving the merchant request 232, works to satisfy the customer request.
It is appreciated that
Further, it is appreciated that different data may be used and/or needed, to map to a particular order record in the order record table 254. For example, in accordance with one embodiment of the invention, the MP processing portion 200 is physically disposed in the customer's device, e.g. in the customer's cell phone. In such embodiment, the customer might enter an initial key sequence to reflect that the customer is initiating a mobile-payment request. Thereafter, the MP processing portion 200 would be activated and looking for input of a key sequence from the customer. Once the MP processing portion 200 receives such key sequence (i.e., out of a plurality of possible key sequences), the MP processing portion 200 proceeds in processing the mobile-payment request. That is, the customer device need not transmit customer ID information or device Id information to the MP processing portion 200, since the MP processing portion 200 indeed only receives mobile-payment requests from such device, i.e., the MP processing portion 200 is dedicated to and physically resides in the customer device 120. Accordingly, the information needed to be sent between and stored within either the customer device 120 and the MP processing portion 200 may vary depending on the particular arrangement.
In accordance with one embodiment of the invention, using a suitable user interface, the parameters (or at least some of the parameters) in the order record table 254 may be changed by the customer, an administrator, a merchant, some other person/entity or changed in some automated manner, for example. For example, it is envisioned that promotion parameters might be changed in some global manner, i.e., so as to globally change all order record tables 254 affected by the change to a merchant's promotion, for example. Alternatively, promotion information, as well as pricing information, might be pulled from an associated table based on the merchant ID and the requested item, for example. The customer also would be able to change their favorites and/or the particular key sequence or other observed event that such favorite is associated with. Such change might be performed by varying mapping, pointers, or some other association in a relational database, for example.
In accordance with one embodiment of the invention, the parameters associated with a customer's profile (such as preferences) may be dynamically changed. Such profile information may be stored using the order record table 254, for example.
For example, the MP processing portion 200 may observe trends of a customer and dynamically vary the customer's profile based on such trends. Accordingly, the parameters associated with a customer's profile may be changed based on preferences of the customer and/or prior behavior of the customer. In one scenario, a customer may have designated their favorites for MCDONALDS. Based on attributes associated with the customer's chosen favorites, the MP processing portion 200 tracks those attributes into products at other restaurants. The attributes might be based on similarity between two compared products, and in particular similar values or designations of parameters representative of the properties of such compared products. Thus, for example, a low calorie salad at MCDONALDS may be tracked to a low calorie salad at BURGER KING. Accordingly, upon being prompted by the user going to BURGER KING, the MP processing portion 200 is provided with the capability to generate a list of the customer's favorites at BURGER KING. In this manner, the MP processing portion 200 essentially extrapolates preferences and/or trends observed at one merchant over to another merchant, and in particular the menu of another merchant. Such processing may include the use of corresponding dynamic icons to interface with the customer via their customer device 120. Such icons might be used to alert the customer that the favorites were generated based on their purchase at other merchants and in general guide the customer through a purchase experience using the extrapolated information.
In accordance with a further scenario, it may be the case that the customer generally super-sizes their order at MCDONALDS. Accordingly, in favorites posed to the customer when the customer goes to BURGER KING, the MP processing portion 200 may propose larger-sizing the customer's selection. In accordance with one embodiment of the invention, and as alluded to above, such analysis may be performed by assigning values to item attributes, and then comparing those values to assess similarity, such as between products from different stores. With reference to
As described above, in accordance with one embodiment of the invention, a user interfaces with the customer device 120 using a “key sequence” entered into the customer device by the user. However, it should be appreciated that the user may interface with their customer device 120 in any of a wide variety of ways, depending in particular on the capabilities of the device and/or what software applications are utilized by the customer device 120 to interface with the user. Accordingly, for any of the functionalities described herein (including those described in the context of using a key sequence), the customer device 120 might interface with the user using any of key sequence, presentation of icons or other graphical representation, touch screen, voice recognition, a device utilizing textile features, LED (light-emitting diode) enabled device, push notification enabled device, media message enabled device and/or any other type of user interface that allows the user to communicate information to and from the customer device 120. For example, in accordance with one embodiment of the invention, the customer device 120 might present a first icon (reflecting an option to purchase their favorite coffee at their favorite store), a second icon (reflecting an option to purchase their second favorite coffee at their favorite store), and a third icon (reflecting an option to purchase their favorite coffee at their second favorite store). The icons might be associated with the letters A, B, and C, respectively, such that the customer makes their selection by entering either A, B or C into their key pad on the customer device 120. Accordingly, “A” might designate selecting the coffee of the day at STARBUCKS, and “B” indicate selecting a latte with blueberry muffin at DUNKIN DOUGHNUTS.
It is appreciated that in general the information as shown in
In particular,
In accordance with one embodiment of the invention, the mobile-payment system 100, e.g. the MP processing portion 200 may include data to present the user with template schedules. Such template schedules might include any of a wide variety of common regimes for customers, such as 8 am coffee every weekday, and 9 am coffee on Saturdays, for example. The templates might be presented to the user so as to be variable, i.e., the user could adjust the templates proposed 8 am time to 7 am, for example. The template schedules might be selected (out of a plurality of presented template schedules) via the user's selection of a radio-button, for example. The template schedules might be customized in any of a variety of ways, such as customized for open times of a particular store, customized for a particular time, for example. Further, the mobile-payment system 100 may provide for a first customer's schedule to be linked to another customer's calendar, i.e., the two customers' schedules might synch with each other or in some other manner talk with each other. Such processing might utilize GOOGLE CALENDAR technology, for example. Alternatively, a user might manually enter in their schedule using an appropriate interface. In general, it is appreciated that a customer's ordering regime may be integrated into their calendar, the merchant's calendar, or any other electronic calendar, as desired.
Further,
Further, as described above, the content shown in
As shown in
Various further aspects of
Hereinafter, further details of the mobile-payment processing are described with reference to the flowcharts of
Illustratively, the process starts in step 300 of
In step 400 of
In step 600, the process returns to step 400 of
Then in step 316, the system interfaces with the customer to secure such further needed information including any further personal information, customer location information, merchant information, and financial account information, as well as a wide variety of other information used in the processing of the mobile-payment processing portion. Then, the process passes to step 317, in which the mobile-payment processing portion, based on the information secured from the financial entity's database and from the customer, finalizes the customer mobile-payment record for the customer.
After step 317 of
Step 328 of
After step 430, the process passes to step 438 of
After step 438 of
On the other hand, if NO in step 442, i.e., the mobile-payment processing is not based on a customer device initiated event, then the process passes to step 446.
In step 446, the MP processing portion 200 determines if the mobile-payment request is based on a merchant initiated event. If yes, then the process passes to step 448. In step 448, the MP processing portion 200 performs further mobile-payment processing to satisfy the merchant initiated request. Further details of step 448 are described below with reference to
On the other hand, if NO in step 446, i.e., the mobile-payment processing is not based on a merchant initiated event, then the process passes to step 449.
Step 449 of
After any of steps 444, 448, or 449, the processing of
After step 426 of
After step 427 of
Alternatively, step 434 reflects that further information is needed, and the MP processing portion 200 interfaces with the customer to secure such further information. For example, the processing to secure the further information might be constituted by any of (a) presenting the customer with the customer's two (or more) favorites, and input the customer's selection; (b) presenting available menu options and input customer's selection; (c) presenting a list of requested items (received from merchant) to the customer for approval; and/or (d) any other information as needed. Such scenario (c) may relate to the situation in which the customer is physically seated in the restaurant and is using the mobile-payment system to pay for lunch, for example.
In accordance with one embodiment of the invention, the mobile-payment processing as described herein might be used in a bar environment, i.e., where a tab is initially opened and requested items are attributed to the tab in an ongoing manner. As reflected in
After step 434 of
In step 450, processing of the transaction request is performed to secure approval so as to debit the customer's account for the cost of the item that the customer has requested. Further details of step 450 are described below with reference to
After step 460 of
As shown in
After step 452, the process passes to step 453. In step 453, based on the merchant information, the associated product information, as well as any promotion information, and any additional information that was retrieved, the cost of the particular desired item is determined. Then, in step 454, the financial account information is retrieved from the identified record row. Then, in step 456, based on the retrieved financial account information and the cost of the desired item, a transaction request is generated.
Then, in step 457, processing is performed to secure approval of the transaction. That is, for example, the mobile-payment processing portion 200 communicates with an authorization entity to determine if the transaction is approved. After step 457 of
In step 461, data to generate the merchant request is pulled from the retrieved order record 255 of the retrieved customer mobile-payment account. The retrieved data may include the merchant ID from which the purchase is desired, any time parameters associated with the request, the particular product that is desired, delivery instructions, as well as any other information. After step 461, the process passes to step 462. In step 462, the merchant request is generated based on the retrieved data from the order record 255 and any addendum information i.e. any information the customer entered in manually, for example. Then, in step 463, time parameters set forth in the order record are processed. That is, these time parameters reflect the timing in which the merchant request is to be sent out. Then, in step 464, based on the retrieved time parameters, the merchant request is placed into queue with an output time. For example, the output time may be 0 minutes, i.e. immediately, or 15 minutes, for example. It is appreciated that various other timing mechanisms may be utilized. For example, if the time parameters are such that the merchant request should be immediately forwarded to the designated merchant, then no placement into queue is desired. After step 464, the process passes to step 465.
In step 465, once the output time is attained for the merchant request that is in queue, the merchant request is output i.e. transmitted to the merchant. Then, in step 466, a communication is sent from the mobile-payment portion to the customer device. This communication may include various information and in particular advises the customer that their mobile-payment request has been processed. Then, in step 467, the process passes to step 469 of
After starting in step 448, the process of
In step 480, based on the order record 255 that was retrieved (in
Regarding step 482, promotions and/or coupons may come from a variety of sources including the merchant, financial entities that are involved in the transaction, and/or some other third party. Promotions and coupons may be made available based on a wide variety of criteria as desired.
In step 484, the MP processing portion 200 prepares a communication based on information retrieved in steps 480 and 482. The MP processing portion 200 then transmits such communication to the merchant system 130.
After step 484 of
After step 500 of
As reflected in step 520, if the particular request being processed is a merchant initiated, i.e., merchant driven, request, then the availability of the requested item may have been previously determined, and thus the processing of
After step 520 of
After step 526 of
In step 530, the parameters of the customer's purchase are presented to the merchant worker. Then, in step 540, the merchant worker prepares the requested purchase and coordinates the pickup of the purchase (by the customer) based on the instructions that the worker sees in the merchant request. After step 540, the process passes to step 550. In step 550, the merchant worker interfaces with the merchant system to input that the requested purchase is satisfied. Accordingly, step 550, reflects that the requested purchase is satisfied, i.e., once the requested item is ready for pickup and/or once the customer picks up the requested item.
Then, the process of
Then, the process passes to step 559. In step 559, the process passes to step 600 of
As noted above, in accordance with embodiments of the invention, information may be captured, sorted and/or allocated in a variety of manners. In particular, transaction/receipt information may be captured, sorted and/or allocated. For example, in conjunction with dining at a mobile eligible restaurant, as described above, the MP processing portion 200 might associate the particular transaction with an expense number, which is in turn associated with a particular expense account. In some periodic manner, the customer may download all the transactions associated with each of his expense numbers, or use such aggregated information in some other manner, as desired. In general, there may be provided allocation, i.e., bucket allocation, of various information by either the customer MP processing portion, a participating merchant and/or a financial entity.
Such allocation may be performed utilizing the order record table 254 as shown in
As described above, the systems and methods of embodiments of the invention provide for a variety of functionality. Such functionally may relate to customer ordering and related processing, customer payment related processing, use of rules in payment scenarios, GPS and other location related processing.
Further, the invention may include, for example, the use of coupons (including URL and decay processing associated with the location/securement and life of coupons respectively), the sharing of information (e.g. tell your friends you're at the local coffee house), use of photo/imaging technology, various authentication processing (including two key authentication and biometric authentication such as fingerprinting and eye scan), offer matching, and integration of multiple customer devices. The order record 255, associated with a particular requested transaction (of a customer), may be utilized to provide such features.
For example, a coupon may be associated with a particular customer using the mapping capability of the order record table 254. A particular coupon may be presented to the customer for use by that customer. Alternatively, the customer might transfer the coupon to another customer for their use, i.e., via the two customer devices talking with each other, for example. Further, a customer may be a member of what might be characterized as a “coupon consortium.” As a member, the customer might be presented with coupons based on criteria, e.g. using a rule set, as desired. Members of the consortium may contribute coupons and/or coupon value to the pool. The customers may use coupons as they are available and/or as they are earned by the particular customer, for example.
In accordance with a further embodiment of the invention, the mobile-payment system 100 implements a coupon system, in conjunction with a particular merchant, in which if a given number of people are participating in an event, e.g. at a bar, then a price reduction will be granted. For example, a price reduction of 10% might be provided if 10 or more people participate in a transaction using the mobile-payment system 100. In general, the mobile-payment system 100 may utilize a wide variety of coupon related functionality such as any of the features described in U.S. application Ser. No. 12/559,756 filed Sep. 15, 2009 titled “SYSTEMS AND METHODS FOR COUPON SEARCHING CARDS” which is incorporated by reference herein in its entirety.
For example, in accordance with one embodiment of the invention, the order record 255 (that the MP processing portion 200 maps to for a particular transaction) may include indicia indicating that certain entities should be alerted to such requested transaction. Illustratively, the e-mail addresses of two friends of the customer may be associated with a retrieved order record 255—such that when that order record 255 is retrieved, the two friends are e-mailed. Various other information may be associated with respective order records 255, and used to enhance the customer experience.
In general, the mobile-payment system 100, and in particular the MP processing portion 200, may be integrated with other systems including what might be characterized as “social network sites (SNSs)” such as TWITTER, LINKEDIN and FACEBOOK, for example. More specifically, processing performed by the mobile-payment system 100, including the events associated with such processing, may be communicated to such SNSs as desired. For example, in accordance with one embodiment of the invention, upon the MP processing portion 200 observing a certain event, the MP processing portion 200 will communicate attributes of the observed event to an SNS in some predetermined manner. Such may be performed using the customer record table 252- and mapping an “observed event” to communications that are to be performed in conjunction with such observed event. Such processing may utilize the customer record table 252, trigger events, and/or a rule set, for example. In one illustrative scenario, as a customer approaches her local STARBUCKS—an order of a venti vanilla latte is generated and sent to such merchant, as described herein. In conjunction with sending such order, an e-mail goes out to the customer's designated friends. At such time, the friends might join the customer, if the friends are available. Various related processing may be provided.
In summary, the protocol may be characterized as “go somewhere; do something; come back.” The various systems and processing, and associated communications, as described herein may be provided with and/or utilize such protocol so as to provide a richer and more automated platform.
After the protocol is initiated in step 211 of
Application A, as described, may be constituted by the mobile-payment (MP) processing portion 200, with application B constituted by the merchant system 130. For example, the communication portion 210 and/or merchant request generation portion 230 in the MP processing portion 200 may effect the protocol related processing as described herein.
The calling application (application A) also includes a returnURL parameter so that application B knows how to come back when the processing is done. The returnURL contains all the information the calling application (application A) needs to continue the progression of processing between application A and application B. In one case the URL sent by application A may include a simple beverage_id parameter, i.e., so as to associate the communications to a comment id. However, the URL sent from the application A (to application B) may also include complex “continuation” information encoded in the URL, i.e., so as to dictate further action effected upon receipt of the URL by application B, i.e., such as delivery instructions. A URL from application A to application B might be constituted by, for example, the URL:
As shown in
Accordingly, when the customer taps “Return to CoffeePlace” as presented by application A on the customer's device, application A invokes the returnURL of the request, which includes the additional return parameters that indicate whether the order was completed as well as any other information generated by application B. In accordance with one embodiment of the invention, the return parameters are prefixed with an appropriate prefix, i.e., to avoid collisions.
The return URL might be constituted by, for example, the URL:
Accordingly, in step 216 of
The above protocol provides one approach that may be used in the communications between the MP processing portion 200 and the merchant system 130. In general, the above protocol may be used in conjunction with any of the communications or processing described herein, as desired.
In accordance with the various embodiments described herein, it is appreciated that payment accounts may be debited in combination. That is, multiple payment accounts may be debited for a particular transaction. For example, a gift card account might be debited, with the balance due being debited from a credit card account.
In accordance with some embodiments of the invention, and related to the “bar” environment processing as described above, the MP processing portion 200 may perform a variety of aggregation and allocation (i.e., divvying out) processing in conjunction with the various other features described herein. That is, in embodiments of the invention, functionality is provided to allocate and/or aggregate any of customer orders, payment of items, and delivery of items (including over the counter delivery), for example.
As shown in
Thereafter, the MP processing portion 200, via the customer 1 device 120, transmits the aggregated order to the merchant system 130, i.e., upon customer 1 walking down the street and entering the local coffee house, for example. As to the transmission between the customer 1 device 120 and the merchant system 130, such may be effected in different manners. In accordance with one embodiment of the invention, the MP processing portion 200 in the customer 1 device 120 actually allocates out the respective orders prior to sending to the merchant system 130. However, in accordance with a different embodiment of the invention, the MP processing portion 200 in the customer 1 device 120 transmits all the orders to the merchant system 130 together. The later scenario may be desired if the customer 1, for example, is paying for everyone's ordered item.
Once the order is received by the merchant system 130, the merchant system 130 debits the designated account based on the processing as described above, for example. Further, the merchant system 130 outputs the orders to the merchant's workers for preparation of the requested items. In conjunction, the merchant system 130 might generate/print tabs to be affixed to the ordered items.
The processing shown in
In accordance with embodiments of the invention, it is appreciated that orders may be aggregated in a wide variety of ways. As described herein, orders may be aggregated to pay funds and/or to receive funds in some allocated manner. In accordance with one embodiment of the invention, funds may be aggregated for purposes of administering a charitable contribution. The MP processing portion 200 may utilize the various features described herein to assist in such administering of a charitable contribution
In accordance with further embodiments of the invention, various variations of the above processing may be performed. For example, the MP processing portion 200 may provide for the customer 1 device 120 to provide an order for two or more people, debit the customer 1 designated account, and print out tabs (to be affixed to the ordered items) that designate the recipient. Accordingly, a customer 1 may arrange, using the MP processing portion 200, for payment of a colleague's coffee in conjunction with the colleague picking up the paid-for coffee from the barista, i.e., since the tab that is attached to the colleague's coffee has the colleague's name and caricature in one illustrative example.
As described above, order information may be transferred from a first customer's device to a second customer's device. In accordance with one embodiment of the invention, such data may have a decay function attached thereto, i.e., the data will be erased by the MP processing portion 200 (on the customer 1 device) in a certain period of time, e.g. an hour. Relatedly, it is appreciated that such transferred data may well set forth the particulars of the order, i.e., such that it is the customer 1 device's job to simply transfer the order to the merchant system 130 in the particular aggregated or allocated manner designated.
In accordance with a further embodiment of the invention, the MP processing portion 200 may be provided with functionality to allocate out aggregated costs in various manners. For example, in a group setting (such as the bar scenario described above) such functionality might allow the customer to which the purchases are being aggregated to allocate costs based on items purchased by participates, based on the number of participates (i.e., split the tab evenly), based on who is still present, and/or based on seniority of persons present, for example.
In accordance with one embodiment of the invention, the systems and methods of embodiments may also provide a ghost customer. For example, a person dining in a group setting may not be provided with the technology to participate as described herein. In such scenario, the MP processing portion 200 may provide for a ghost customer. An allocation of amount owed or amount due may be allocated to this customer by the processing portion 200, and then verbally communicated to the customer, for example.
It is appreciated that the processing as described herein may include, or be used with, processing to effect a transfer of funds between two or more persons. For example, a first customer may purchase an item for a second customer. Thereafter, the second customer may transfer funds from the second customer's account to the first customer's account. Any known processing may be used to effect such person to person processing. For example, the features described herein may be used in conjunction with the features described in U.S. patent application Ser. No. 11/833,709 (US 2008/0177659) filed Aug. 3, 2007 entitled “Systems and methods for providing financial processing in conjunction with instant messaging and other communications”, which is incorporated by reference herein in its entirety.
It is appreciated that the features described herein may be used in conjunction with a wide variety of other technologies, including but not limited to technology as set forth in U.S. Pat. No. 7,392,222, issued Jun. 24, 2008 entitled “SYSTEM AND METHOD FOR PROVIDING PROMOTIONAL PRICING;” U.S. Utility application Ser. No. 10/909,407 filed Aug. 3, 2004; U.S. Utility application Ser. No. 12/561,876 filed Sep. 17, 2009 entitled “SYSTEM AND METHOD FOR PROVIDING BORROWING SCHEMES”; U.S. Utility application Ser. No. 12/372,510 filed Feb. 17, 2009 entitled “SYSTEM AND METHOD FOR PROVIDING BORROWING SCHEMES”; U.S. Utility application Ser. No. 12/372,554 filed Feb. 17, 2009 entitled “SYSTEM AND METHOD FOR PROVIDING BORROWING SCHEMES”; U.S. Utility application Ser. No. 12/372,617 filed Feb. 17, 2009 entitled “SYSTEM AND METHOD FOR PROVIDING BORROWING SCHEMES”; U.S. Utility application Ser. No. 12/372,710 filed Feb. 17, 2009 entitled “SYSTEM AND METHOD FOR PROVIDING BORROWING SCHEMES”; U.S. Utility application Ser. No. 12/372,716 filed Feb. 17, 2009 entitled “SYSTEM AND METHOD FOR PROVIDING BORROWING SCHEMES”, as well as that described in U.S. Utility application Ser. No. 12/559,756 filed Sep. 15, 2009 titled “SYSTEMS AND METHODS FOR COUPON SEARCHING CARDS”; and U.S. Pat. No. 7,702,538, issuing Apr. 20, 2010 entitled “SYSTEM AND METHOD FOR TRANSPONDER-ENABLED ACCOUNT TRANSACTIONS”, all of such which are incorporated by reference herein in their entirety.
The content of all references cited herein are incorporated by reference herein in their entirety.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (3) of
d) is an illustrative user interface displayed in conjunction with the processing of step (4) of
e) is a flowchart showing aspects of the processing performed in the user scenario of
f) is a diagram describing details of the respective steps of
a)-34(g) are figures showing a further user scenario in which a mobile-payment device is configured and used, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) is an illustrative user interface displayed in conjunction with the processing of step (3) of
e) is an illustrative user interface displayed in conjunction with the processing of step (4) of
f) is a flowchart showing aspects of the processing performed in the user scenario of
g) is a diagram describing details of the respective steps of
a)-35(k) are figures showing a further user scenario in which a mobile-payment device is used in location based ordering and payment, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) shows steps of a “transaction” phase of a user scenario, showing aspects of location based ordering and payment, in accordance with one embodiment of the invention.
e) is an illustrative user interface displayed in conjunction with the processing of step (3) of
f) is an illustrative user interface displayed in conjunction with the processing of step (4) of
g) is an illustrative user interface displayed in conjunction with the processing of step (5) of
h) shows steps of a “post-transaction” phase of a user scenario, showing aspects of location based ordering and payment, in accordance with one embodiment of the invention.
i) is an illustrative user interface displayed in conjunction with the processing of step (6) of
j) is a flowchart showing aspects of the processing performed in the user scenario of
k) is a diagram describing details of the respective steps of
a)-36(k) are figures showing a further user scenario in which a mobile-payment device is used in web based ordering and payment, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) shows steps of a “transaction” phase of a user scenario, showing aspects of web based ordering and payment, in accordance with one embodiment of the invention.
e) is an illustrative user interface displayed in conjunction with the processing of step (3) of
f) is an illustrative user interface displayed in conjunction with the processing of step (4) of
g) is an illustrative user interface displayed in conjunction with the processing of step (6) of
h) shows steps of a “post-transaction” phase of a user scenario, showing aspects of web based ordering and payment, in accordance with one embodiment of the invention.
i) is an illustrative user interface displayed in conjunction with the processing of step (7) of
j) is a flowchart showing aspects of the processing performed in the user scenario of
k) is a diagram describing details of the respective steps of
a)-37(k) are figures showing a further user scenario in which a mobile-payment device is used in restaurant ordering and payment, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) shows steps of a “transaction” phase of a user scenario, showing aspects of restaurant ordering and payment, in accordance with one embodiment of the invention.
e) is an illustrative user interface displayed in conjunction with the processing of step (4) of
f) is an illustrative user interface displayed in conjunction with the processing of step (5) of
g) is an illustrative user interface displayed in conjunction with the processing of step (6) of
h) shows steps of a “post-transaction” phase of a user scenario, showing aspects of restaurant ordering and payment, in accordance with one embodiment of the invention.
i) is an illustrative user interface displayed in conjunction with the processing of step (7) of
j) is a flowchart showing aspects of the processing performed in the user scenario of
k) is a diagram describing details of the respective steps of
a)-38(f) are figures showing a further user scenario in which a mobile-payment device is used in setting rules and fraud alerts, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (3) of
d) is an illustrative user interface displayed in conjunction with the processing of step (4) of
e) is a flowchart showing aspects of the processing performed in the user scenario of
f) is a diagram describing details of the respective steps of
a)-39(k) are figures showing a further user scenario in which a mobile-payment device is used in open bar tab ordering and payment, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) shows steps of a “transaction” phase of a user scenario, showing aspects of open bar tab ordering and payment, in accordance with one embodiment of the invention.
e) is an illustrative user interface displayed in conjunction with the processing of step (3) of
f) is an illustrative user interface displayed in conjunction with the processing of step (4) of
g) is an illustrative user interface displayed in conjunction with the processing of step (5) of
h) is an illustrative user interface displayed in conjunction with the processing of step (6) of
i) shows steps of a “post-transaction” phase of a user scenario, showing aspects of open bar tab ordering and payment, in accordance with one embodiment of the invention.
j) is a flowchart showing aspects of the processing performed in the user scenario of
k) is a diagram describing details of the respective steps of
a)-40(l) are figures showing a further user scenario in which a mobile-payment device is used in bill sharing, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) shows steps of a “transaction” phase of a user scenario, showing aspects of bill sharing, in accordance with one embodiment of the invention.
e) is an illustrative user interface displayed in conjunction with the processing of step (4) of
f) is an illustrative user interface displayed in conjunction with the processing of step (5) of
g) is an illustrative user interface displayed in conjunction with the processing of step (6) of
h) shows steps of a “post-transaction” phase of a user scenario, showing aspects of bill sharing, in accordance with one embodiment of the invention.
i) is an illustrative user interface displayed in conjunction with the processing of step (7) of
j) is an illustrative user interface displayed in conjunction with the processing of step (8) of
k) is a flowchart showing aspects of the processing performed in the user scenario of
l) is a diagram describing details of the respective steps of
a)-41(i) are figures showing a further user scenario in which a mobile-payment device is used in performing person to person payment, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) shows steps of a “transaction” phase of a user scenario, showing aspects of performing person to person payment, in accordance with one embodiment of the invention.
d) is an illustrative user interface displayed in conjunction with the processing of step (3) of
e) is an illustrative user interface displayed in conjunction with the processing of step (4) of
f) shows steps of a “post-transaction” phase of a user scenario, showing aspects of performing person to person payment, in accordance with one embodiment of the invention.
g) is an illustrative user interface displayed in conjunction with the processing of step (6) of
h) is a flowchart showing aspects of the processing performed in the user scenario of
i) is a diagram describing details of the respective steps of
a)-42(g) are figures showing a further user scenario in which a mobile-payment device is used to perform payment at a point of purchase, in accordance with one embodiment of the invention.
In particular,
b) is an illustrative user interface displayed in conjunction with the processing of step (1) of
c) is an illustrative user interface displayed in conjunction with the processing of step (2) of
d) is an illustrative user interface displayed in conjunction with the processing of step (1) of
e) is an illustrative user interface displayed in conjunction with the processing of step (2) of
f) is a flowchart showing aspects of the processing performed in the user scenario of
g) is a diagram describing details of the respective steps of
Hereinafter, general aspects of implementation of the systems and methods of the invention will be described.
As described herein, embodiments of the system of the invention and various processes of embodiments of the method of the invention are described. The system of the invention or portions of the system of the invention may be in the form of a “processing machine,” such as a general purpose computer, for example. As used herein, the term “processing machine” is to be understood to include at least one processor that uses at least one memory. The at least one memory stores a set of instructions. The instructions may be either permanently or temporarily stored in the memory or memories of the processing machine. The processor executes the instructions that are stored in the memory or memories in order to process data. The set of instructions may include various instructions that perform a particular task or tasks, including any of the tasks described herein. Such a set of instructions for performing a particular task may be characterized as a program, software program, or simply software.
As noted herein, the processing machine executes the instructions that are stored in the memory or memories to process data. This processing of data may be in response to commands by a user or users of the processing machine, in response to previous processing, in response to a request by another processing machine and/or any other input, for example.
As noted herein, the processing machine used to implement the invention may be a general purpose computer. However, the processing machine described herein may also utilize any of a wide variety of other technologies including a special purpose computer, a computer system including a microcomputer, mini-computer or mainframe for example, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, a CSIC (Customer Specific Integrated Circuit) or ASIC (Application Specific Integrated Circuit) or other integrated circuit, a logic circuit, a digital signal processor, a programmable logic device such as a FPGA, PLD, PLA or PAL, or any other device or arrangement of devices that is capable of implementing the steps of the processes of the invention.
The processing machine used to implement the invention may utilize a suitable operating system. Thus, embodiments of the invention may include a processing machine running the Microsoft Windows™ Vista™ operating system, the Microsoft Windows™ XP™ operating system, the Microsoft Windows™ NT™ operating system, the Windows™ 2000 operating system, the Unix operating system, the Linux operating system, the Xenix operating system, the IBM AIX™ operating system, the Hewlett-Packard UX™ operating system, the Novell Netware™ operating system, the Sun Microsystems Solaris™ operating system, the OS/2™ operating system, the BeOS™ operating system, the Macintosh operating system, the Apache operating system, an OpenStep™ operating system or another operating system or platform.
It is appreciated that in order to practice the method of the invention as described herein, it is not necessary that the processors and/or the memories of the processing machine be physically located in the same geographical place. That is, each of the processors and the memories used by the processing machine may be located in geographically distinct locations and connected so as to communicate in any suitable manner. Additionally, it is appreciated that each of the processor and/or the memory may be composed of different physical pieces of equipment. Accordingly, it is not necessary that the processor be one single piece of equipment in one location and that the memory be another single piece of equipment in another location. That is, it is contemplated that the processor may be two pieces of equipment in two different physical locations. The two distinct pieces of equipment may be connected in any suitable manner. Additionally, the memory may include two or more portions of memory in two or more physical locations.
To explain further, processing as described herein is performed by various components and various memories. However, it is appreciated that the processing performed by two or more distinct components as described herein may, in accordance with a further embodiment of the invention, be performed by a single component. Further, the processing performed by one distinct component as described herein may be performed by two or more distinct components. In a similar manner, the memory storage performed by two or more distinct memory portions as described herein may, in accordance with a further embodiment of the invention, be performed by a single memory portion. Further, the memory storage performed by one distinct memory portion as described herein may be performed by two or more memory portions.
Further, various technologies may be used to provide communication between the various processors and/or memories, as well as to allow the processors and/or the memories of the invention to communicate with any other entity; i.e., so as to obtain further instructions or to access and use remote memory stores, for example. Such technologies used to provide such communication might include a network, the Internet, Intranet, Extranet, LAN, an Ethernet, or any client server system that provides communication, for example. Such communications technologies may use any suitable protocol such as TCP/IP, UDP, or OSI, for example. As used herein, the term “talking” in reference to devices means that the devices are communicating with each other.
As described herein, a set of instructions is used in the processing of the invention. The set of instructions may be in the form of a program or software. The software may be in the form of system software or application software, for example. The software might also be in the form of a collection of separate programs, a program module within a larger program, or a portion of a program module, for example The software used might also include modular programming in the form of object oriented programming. The software tells the processing machine what to do with the data being processed.
Further, it is appreciated that the instructions or set of instructions used in the implementation and operation of the invention may be in a suitable form such that the processing machine may read the instructions. For example, the instructions that form a program may be in the form of a suitable programming language, which is converted to machine language or object code to allow the processor or processors to read the instructions. That is, written lines of programming code or source code, in a particular programming language, are converted to machine language using a compiler, assembler or interpreter. The machine language is binary coded machine instructions that are specific to a particular type of processing machine, i.e., to a particular type of computer, for example. The computer understands the machine language.
Any suitable programming language may be used in accordance with the various embodiments of the invention. Illustratively, the programming language used may include assembly language, Ada, APL, Basic, C, C++, COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, REXX, Visual Basic, and/or JavaScript, for example. Further, it is not necessary that a single type of instructions or single programming language be utilized in conjunction with the operation of the system and method of the invention. Rather, any number of different programming languages may be utilized as is necessary or desirable.
Also, the instructions and/or data used in the practice of the invention may utilize any compression or encryption technique or algorithm, as may be desired. An encryption module might be used to encrypt data. Further, files or other data may be decrypted using a suitable decryption module, for example.
As described herein, the invention may illustratively be embodied in the form of a processing machine, including a computer or computer system, for example, that includes at least one memory. It is to be appreciated that the set of instructions, i.e., the software for example, that enables the computer operating system to perform the operations described herein may be contained on any of a wide variety of media or medium, as desired. Further, the data that is processed by the set of instructions might also be contained on any of a wide variety of media or medium. That is, the particular medium, i.e., the memory in the processing machine, utilized to hold the set of instructions and/or the data used in the invention may take on any of a variety of physical forms or transmissions, for example. Illustratively, the medium may be in the form of paper, paper transparencies, a compact disk, a DVD, an integrated circuit, a hard disk, a floppy disk, an optical disk, a magnetic tape, a RAM, a ROM, a PROM, a EPROM, a wire, a cable, a fiber, communications channel, a satellite transmissions or other remote transmission, as well as any other medium or source of data that may be read by the processors of the invention.
Further, the memory or memories used in the processing machine that implements the invention may be in any of a wide variety of forms to allow the memory to hold instructions, data, or other information, as is desired. Thus, the memory might be in the form of a database to hold data. The database might use any desired arrangement of files such as a flat file arrangement or a relational database arrangement, for example.
In the system and method of the invention, a variety of “user interfaces” may be utilized to allow a user to interface with the processing machine or machines that are used to implement the invention. As used herein, a user interface includes any hardware, software, or combination of hardware and software used by the processing machine that allows a user to interact with the processing machine. A user interface may be in the form of a dialogue screen for example. A user interface may also include any of a mouse, touch screen, keyboard, voice reader, voice recognizer, dialogue screen, menu box, list, checkbox, toggle switch, a pushbutton or any other device that allows a user to receive information regarding the operation of the processing machine as it processes a set of instructions and/or provide the processing machine with information. Accordingly, the user interface is any device that provides communication between a user and a processing machine. The information provided by the user to the processing machine through the user interface may be in the form of a command, a selection of data, or some other input, for example.
As discussed herein, a user interface is utilized by the processing machine that performs a set of instructions such that the processing machine processes data for a user. The user interface is typically used by the processing machine for interacting with a user either to convey information or receive information from the user. However, it should be appreciated that in accordance with some embodiments of the system and method of the invention, it is not necessary that a human user actually interact with a user interface used by the processing machine of the invention. Rather, it is also contemplated that the user interface of the invention might interact, i.e., convey and receive information, with another processing machine, rather than a human user. Accordingly, the other processing machine might be characterized as a user. Further, it is contemplated that a user interface utilized in the system and method of the invention may interact partially with another processing machine or processing machines, while also interacting partially with a human user.
It will be readily understood by those persons skilled in the art that the present invention is susceptible to broad utility and application. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and foregoing description thereof, without departing from the substance or scope of the invention.
Accordingly, while the present invention has been described here in detail in relation to its exemplary embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present invention and is made to provide an enabling disclosure of the invention. Accordingly, the foregoing disclosure is not intended to be construed or to limit the present invention or otherwise to exclude any other such embodiments, adaptations, variations, modifications or equivalent arrangements.
This application is a continuation of U.S. application Ser. No. 12/776,961 filed May 10, 2010, which claims priority to U.S. Provisional Patent Application 61/288,029 filed Dec. 18, 2009, the content of which is incorporated herein by reference in its entirety, and also claims priority to U.S. Provisional Patent Application 61/180,218 filed May 21, 2009, the content of which is incorporated herein by reference in its entirety. U.S. application Ser. No. 12/776,961 is incorporated herein by reference in its entirety. U.S. application Ser. No. 12/776,961 is a continuation-in-part of U.S. application Ser. No. 12/489,066 filed Jun. 22, 2009, which claims priority to U.S. Provisional Patent Application 61/162,169 filed Mar. 20, 2009. The content of both incorporated herein by reference in their entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3999050 | Pitroda | Dec 1976 | A |
| 4012720 | Call et al. | Mar 1977 | A |
| 4338587 | Chiappetti | Jul 1982 | A |
| 4554418 | Toy | Nov 1985 | A |
| 4868376 | Lessin et al. | Sep 1989 | A |
| 5220501 | Lawlor et al. | Jun 1993 | A |
| 5258855 | Lech et al. | Nov 1993 | A |
| 5266925 | Vercellotti et al. | Nov 1993 | A |
| 5336870 | Hughes et al. | Aug 1994 | A |
| 5351296 | Sullivan | Sep 1994 | A |
| 5369508 | Lech et al. | Nov 1994 | A |
| 5412730 | Jones | May 1995 | A |
| 5446740 | Yien et al. | Aug 1995 | A |
| 5467269 | Flaten | Nov 1995 | A |
| 5482139 | Rivalto | Jan 1996 | A |
| 5500650 | Snodgrass et al. | Mar 1996 | A |
| 5506981 | Madter | Apr 1996 | A |
| 5550358 | Tait et al. | Aug 1996 | A |
| 5560008 | Johnson et al. | Sep 1996 | A |
| 5583850 | Snodgrass et al. | Dec 1996 | A |
| 5590038 | Pitroda | Dec 1996 | A |
| 5602919 | Hurta et al. | Feb 1997 | A |
| 5615159 | Roohparvar | Mar 1997 | A |
| 5617474 | Ditzig et al. | Apr 1997 | A |
| 5625465 | Lech et al. | Apr 1997 | A |
| 5627544 | Snodgrass et al. | May 1997 | A |
| 5640002 | Ruppert et al. | Jun 1997 | A |
| 5682345 | Roohparvar et al. | Oct 1997 | A |
| 5708422 | Blonder et al. | Jan 1998 | A |
| 5715431 | Everett et al. | Feb 1998 | A |
| 5742845 | Wagner | Apr 1998 | A |
| 5748737 | Daggar | May 1998 | A |
| 5754938 | Herz et al. | May 1998 | A |
| 5761648 | Golden et al. | Jun 1998 | A |
| 5767896 | Nemirofsky | Jun 1998 | A |
| 5768416 | Lech et al. | Jun 1998 | A |
| 5778067 | Jones et al. | Jul 1998 | A |
| 5787174 | Tuttle | Jul 1998 | A |
| 5796827 | Coppersmith et al. | Aug 1998 | A |
| 5796832 | Kawan | Aug 1998 | A |
| 5801985 | Roohparvar et al. | Sep 1998 | A |
| 5802502 | Gell et al. | Sep 1998 | A |
| 5805702 | Curry et al. | Sep 1998 | A |
| 5819234 | Slavin et al. | Oct 1998 | A |
| 5857152 | Everett | Jan 1999 | A |
| 5878337 | Joao et al. | Mar 1999 | A |
| 5880769 | Nemirofsky et al. | Mar 1999 | A |
| 5880996 | Roohparvar | Mar 1999 | A |
| 5884271 | Pitroda | Mar 1999 | A |
| 5889863 | Weber | Mar 1999 | A |
| 5895454 | Harrington | Apr 1999 | A |
| 5897625 | Gustin et al. | Apr 1999 | A |
| 5903830 | Joao et al. | May 1999 | A |
| 5938764 | Klein | Aug 1999 | A |
| 5940510 | Curry et al. | Aug 1999 | A |
| 5943423 | Muftic | Aug 1999 | A |
| 5949880 | Curry et al. | Sep 1999 | A |
| 5960411 | Hartman et al. | Sep 1999 | A |
| 5974078 | Tuttle et al. | Oct 1999 | A |
| 5982293 | Everett et al. | Nov 1999 | A |
| 5986570 | Black et al. | Nov 1999 | A |
| 5987500 | Arunachalam | Nov 1999 | A |
| 5991749 | Morrill, Jr. | Nov 1999 | A |
| 5991843 | Porterfield et al. | Nov 1999 | A |
| 5999624 | Hopkins | Dec 1999 | A |
| 6000608 | Dorf | Dec 1999 | A |
| 6002613 | Cloud et al. | Dec 1999 | A |
| 6003770 | Schilling | Dec 1999 | A |
| 6010067 | Elbaum | Jan 2000 | A |
| 6016484 | Williams et al. | Jan 2000 | A |
| 6016963 | Ezawa et al. | Jan 2000 | A |
| 6018761 | Uomini | Jan 2000 | A |
| 6047269 | Biffar | Apr 2000 | A |
| 6047270 | Joao et al. | Apr 2000 | A |
| 6055513 | Katz et al. | Apr 2000 | A |
| 6061344 | Wood, Jr. | May 2000 | A |
| 6065053 | Nouri et al. | May 2000 | A |
| 6070067 | Nguyen et al. | May 2000 | A |
| 6072801 | Wood, Jr. et al. | Jun 2000 | A |
| 6088683 | Jalili | Jul 2000 | A |
| 6088816 | Nouri et al. | Jul 2000 | A |
| 6091956 | Hollenberg | Jul 2000 | A |
| 6105006 | Davis et al. | Aug 2000 | A |
| 6105013 | Curry et al. | Aug 2000 | A |
| 6112984 | Snavely | Sep 2000 | A |
| 6118789 | Wood, Jr. | Sep 2000 | A |
| 6119106 | Mersky et al. | Sep 2000 | A |
| 6134563 | Clancey et al. | Oct 2000 | A |
| 6144848 | Walsh et al. | Nov 2000 | A |
| 6145098 | Nouri et al. | Nov 2000 | A |
| 6151584 | Papierniak et al. | Nov 2000 | A |
| 6164549 | Richards | Dec 2000 | A |
| 6170067 | Liu et al. | Jan 2001 | B1 |
| 6170745 | Schilling | Jan 2001 | B1 |
| 6189787 | Dorf | Feb 2001 | B1 |
| 6199173 | Johnson et al. | Mar 2001 | B1 |
| 6202054 | Lawlor et al. | Mar 2001 | B1 |
| 6220510 | Everett et al. | Apr 2001 | B1 |
| 6226300 | Hush et al. | May 2001 | B1 |
| 6230267 | Richards et al. | May 2001 | B1 |
| 6237095 | Curry et al. | May 2001 | B1 |
| 6237848 | Everett | May 2001 | B1 |
| 6243838 | Liu et al. | Jun 2001 | B1 |
| 6266721 | Sheikh et al. | Jul 2001 | B1 |
| 6272586 | Roohparvar et al. | Aug 2001 | B1 |
| 6301567 | Leong et al. | Oct 2001 | B1 |
| 6304849 | Uecker et al. | Oct 2001 | B1 |
| 6317832 | Everett et al. | Nov 2001 | B1 |
| 6328217 | Everett et al. | Dec 2001 | B1 |
| 6330543 | Kepecs | Dec 2001 | B1 |
| 6330544 | Walker et al. | Dec 2001 | B1 |
| 6349971 | McCarthy | Feb 2002 | B2 |
| 6357665 | Peachman et al. | Mar 2002 | B1 |
| 6366893 | Hannula et al. | Apr 2002 | B2 |
| 6366894 | Everett et al. | Apr 2002 | B1 |
| 6385723 | Richards | May 2002 | B1 |
| 6425006 | Chari et al. | Jul 2002 | B1 |
| 6439455 | Everett et al. | Aug 2002 | B1 |
| 6446111 | Lowery | Sep 2002 | B1 |
| 6459726 | Ovard et al. | Oct 2002 | B1 |
| 6466862 | DeKock et al. | Oct 2002 | B1 |
| 6488211 | Everett et al. | Dec 2002 | B1 |
| 6529725 | Joao et al. | Mar 2003 | B1 |
| 6535855 | Cahill et al. | Mar 2003 | B1 |
| 6553416 | Chari et al. | Apr 2003 | B1 |
| 6575372 | Everett et al. | Jun 2003 | B1 |
| 6601040 | Kolls | Jul 2003 | B1 |
| 6601169 | Wallace, Jr. et al. | Jul 2003 | B2 |
| 6625444 | Fleming, III et al. | Sep 2003 | B1 |
| 6631849 | Blossom | Oct 2003 | B2 |
| 6659354 | Everett et al. | Dec 2003 | B2 |
| 6681328 | Harris et al. | Jan 2004 | B1 |
| 6681342 | Johnson et al. | Jan 2004 | B2 |
| 6704714 | O'Leary et al. | Mar 2004 | B1 |
| 6705520 | Pitroda et al. | Mar 2004 | B1 |
| 6736322 | Gobburu et al. | May 2004 | B2 |
| 6736325 | Peacham | May 2004 | B1 |
| 6742120 | Markakis et al. | May 2004 | B1 |
| 6742715 | Everett et al. | Jun 2004 | B2 |
| 6754833 | Black et al. | Jun 2004 | B1 |
| 6761319 | Peachman et al. | Jul 2004 | B2 |
| 6769607 | Pitroda et al. | Aug 2004 | B1 |
| 6819219 | Bolle et al. | Nov 2004 | B1 |
| 6857566 | Wankmueller | Feb 2005 | B2 |
| 6868391 | Hultgren | Mar 2005 | B1 |
| 6873974 | Schutzer | Mar 2005 | B1 |
| 6891811 | Smith et al. | May 2005 | B1 |
| 6892052 | Kotola et al. | May 2005 | B2 |
| 6925439 | Pitroda | Aug 2005 | B1 |
| 6950881 | Ndili | Sep 2005 | B1 |
| 6963850 | Bezos et al. | Nov 2005 | B1 |
| 6996579 | Leung et al. | Feb 2006 | B2 |
| 7005985 | Steeves | Feb 2006 | B1 |
| 7039809 | Wankmueller | May 2006 | B1 |
| 7058611 | Kranzley et al. | Jun 2006 | B2 |
| 7068832 | Price et al. | Jun 2006 | B1 |
| 7093767 | Faenza, Jr. et al. | Aug 2006 | B2 |
| 7096003 | Joao et al. | Aug 2006 | B2 |
| 7119659 | Bonalle et al. | Oct 2006 | B2 |
| 7139729 | Nault | Nov 2006 | B2 |
| 7146344 | Wankmueller | Dec 2006 | B2 |
| 7155411 | Blinn et al. | Dec 2006 | B1 |
| 7156301 | Bonalle et al. | Jan 2007 | B1 |
| 7200566 | Moore et al. | Apr 2007 | B1 |
| 7210620 | Jones | May 2007 | B2 |
| 7228155 | Saunders | Jun 2007 | B2 |
| 7239226 | Berardi et al. | Jul 2007 | B2 |
| 7249112 | Berardi et al. | Jul 2007 | B2 |
| 7259887 | Lech et al. | Aug 2007 | B2 |
| 7268667 | Beenau et al. | Sep 2007 | B2 |
| 7287695 | Wankmueller | Oct 2007 | B2 |
| 7308426 | Pitroda | Dec 2007 | B1 |
| 7312707 | Bishop et al. | Dec 2007 | B1 |
| 7349866 | Schwarz, Jr. | Mar 2008 | B2 |
| 7349885 | Gangi | Mar 2008 | B2 |
| 7355990 | Smith et al. | Apr 2008 | B2 |
| 7357310 | Calabrese et al. | Apr 2008 | B2 |
| 7357331 | Blossom | Apr 2008 | B2 |
| 7360694 | Wankmueller | Apr 2008 | B2 |
| 7366990 | Pitroda | Apr 2008 | B2 |
| 7376431 | Niedermeyer | May 2008 | B2 |
| 7392222 | Hamilton et al. | Jun 2008 | B1 |
| 7401032 | Golden et al. | Jul 2008 | B1 |
| 7413113 | Zhu | Aug 2008 | B1 |
| 7421410 | Schechtman et al. | Sep 2008 | B1 |
| 7428507 | Villaret et al. | Sep 2008 | B2 |
| 7469151 | Khan et al. | Dec 2008 | B2 |
| 7471818 | Price et al. | Dec 2008 | B1 |
| 7474434 | Lech et al. | Jan 2009 | B2 |
| 7483334 | Ha | Jan 2009 | B2 |
| 7493288 | Biship et al. | Feb 2009 | B2 |
| 7496527 | Silverstein et al. | Feb 2009 | B2 |
| RE40686 | Wood, Jr. | Mar 2009 | E |
| 7526449 | Blossom | Apr 2009 | B1 |
| 7527208 | Hammad et al. | May 2009 | B2 |
| 7529563 | Pitroda | May 2009 | B1 |
| 7533047 | Hagale et al. | May 2009 | B2 |
| 7546254 | Bednarek | Jun 2009 | B2 |
| 7555444 | Wilson et al. | Jun 2009 | B1 |
| 7562818 | Bierbaum et al. | Jul 2009 | B1 |
| 7587363 | Cataline et al. | Sep 2009 | B2 |
| 7591416 | Blossom | Sep 2009 | B2 |
| 7603311 | Yadav-Ranjan | Oct 2009 | B1 |
| 7606741 | King et al. | Oct 2009 | B2 |
| 7627310 | Starr et al. | Dec 2009 | B2 |
| 7631810 | Liu et al. | Dec 2009 | B2 |
| 7636694 | Wankmueller et al. | Dec 2009 | B1 |
| 7637425 | Mock et al. | Dec 2009 | B2 |
| 7644859 | Zhu | Jan 2010 | B1 |
| 7653600 | Gustin et al. | Jan 2010 | B2 |
| 7657489 | Stambaugh | Feb 2010 | B2 |
| 7668363 | Price et al. | Feb 2010 | B2 |
| 7669759 | Zettner | Mar 2010 | B1 |
| 7689504 | Warren et al. | Mar 2010 | B2 |
| 7693752 | Jaramillo | Apr 2010 | B2 |
| 7702538 | Rau et al. | Apr 2010 | B2 |
| 7706838 | Atsmon et al. | Apr 2010 | B2 |
| 7708191 | Vega | May 2010 | B2 |
| 7708194 | Vawter | May 2010 | B2 |
| 7708202 | Hawkins | May 2010 | B2 |
| 7716194 | Williams et al. | May 2010 | B2 |
| 7720707 | Mowry | May 2010 | B1 |
| 7734621 | Weitzman et al. | Jun 2010 | B2 |
| 7747522 | Walker et al. | Jun 2010 | B1 |
| RE41531 | Wood, Jr. | Aug 2010 | E |
| RE41562 | Dando et al. | Aug 2010 | E |
| 7768395 | Gold | Aug 2010 | B2 |
| 7774231 | Pond et al. | Aug 2010 | B2 |
| 7806321 | Segura | Oct 2010 | B1 |
| 7813955 | Ariff et al. | Oct 2010 | B2 |
| 7814005 | Imrey et al. | Oct 2010 | B2 |
| 7818229 | Imrey et al. | Oct 2010 | B2 |
| 7818246 | Cushing et al. | Oct 2010 | B2 |
| 7822688 | Labrou et al. | Oct 2010 | B2 |
| 7822816 | Payne | Oct 2010 | B2 |
| 7835960 | Breck et al. | Nov 2010 | B2 |
| 7848978 | Imrey et al. | Dec 2010 | B2 |
| 7850855 | Pomerleau et al. | Dec 2010 | B2 |
| 7853600 | Herz et al. | Dec 2010 | B2 |
| 7856377 | Cohagan et al. | Dec 2010 | B2 |
| 7860450 | Rissanen | Dec 2010 | B2 |
| 7870021 | Mankoff | Jan 2011 | B2 |
| 7886964 | Steinecker et al. | Feb 2011 | B2 |
| RE42254 | Wood, Jr. | Mar 2011 | E |
| 7899234 | Abed | Mar 2011 | B1 |
| 7899706 | Stone et al. | Mar 2011 | B1 |
| 7906896 | Seo et al. | Mar 2011 | B2 |
| 7908170 | Asmar et al. | Mar 2011 | B2 |
| 7922077 | Humphrey et al. | Apr 2011 | B2 |
| 7926714 | Zhu | Apr 2011 | B1 |
| 7933800 | Main et al. | Apr 2011 | B2 |
| 7941197 | Jain et al. | May 2011 | B2 |
| 7942337 | Jain | May 2011 | B2 |
| 7945479 | Asher et al. | May 2011 | B2 |
| 7954717 | Narendra et al. | Jun 2011 | B2 |
| 7967215 | Kumar et al. | Jun 2011 | B2 |
| 7974889 | Raimbeault | Jul 2011 | B2 |
| 7983616 | Wang et al. | Jul 2011 | B2 |
| RE42599 | Wood, Jr. | Aug 2011 | E |
| 7988058 | Englebardt et al. | Aug 2011 | B2 |
| 7991694 | Takayama | Aug 2011 | B2 |
| 7991696 | Gustin et al. | Aug 2011 | B2 |
| 7992779 | Phillips et al. | Aug 2011 | B2 |
| 7992781 | Hammad | Aug 2011 | B2 |
| 7996252 | Shahrabi et al. | Aug 2011 | B2 |
| 7996324 | Bishop et al. | Aug 2011 | B2 |
| 8000749 | McConnell et al. | Aug 2011 | B1 |
| 8014720 | Lortz | Sep 2011 | B2 |
| 8014755 | Sun et al. | Sep 2011 | B2 |
| 8019365 | Fisher | Sep 2011 | B2 |
| 8020766 | Hammad | Sep 2011 | B2 |
| 8024220 | Ariff et al. | Sep 2011 | B2 |
| 8027891 | Preston et al. | Sep 2011 | B2 |
| 8032410 | Main et al. | Oct 2011 | B2 |
| 8037158 | Arunachalam | Oct 2011 | B2 |
| 8041099 | Abed | Oct 2011 | B2 |
| 8041338 | Chen et al. | Oct 2011 | B2 |
| 8045784 | Price et al. | Oct 2011 | B2 |
| 8046257 | Wane et al. | Oct 2011 | B2 |
| RE42900 | Wood, Jr. | Nov 2011 | E |
| 8078528 | Vicente et al. | Dec 2011 | B1 |
| 8086488 | Liu | Dec 2011 | B2 |
| 8106766 | Gold | Jan 2012 | B2 |
| 8108492 | Arunachalam | Jan 2012 | B2 |
| 8121948 | Gustin et al. | Feb 2012 | B2 |
| 8150767 | Wankmueller | Apr 2012 | B2 |
| 8151335 | Wankmueller et al. | Apr 2012 | B2 |
| 8190522 | Vicente et al. | May 2012 | B1 |
| 8190893 | Benson et al. | May 2012 | B2 |
| 20010016835 | Hansmann et al. | Aug 2001 | A1 |
| 20010044762 | Nault | Nov 2001 | A1 |
| 20010050875 | Kahn et al. | Dec 2001 | A1 |
| 20010051920 | Joao et al. | Dec 2001 | A1 |
| 20010056402 | Ahuja et al. | Dec 2001 | A1 |
| 20020025797 | Joao et al. | Feb 2002 | A1 |
| 20020038424 | Joao et al. | Mar 2002 | A1 |
| 20020050528 | Everett et al. | May 2002 | A1 |
| 20020052842 | Schuba et al. | May 2002 | A1 |
| 20020054111 | Knight | May 2002 | A1 |
| 20020099826 | Summers et al. | Jul 2002 | A1 |
| 20020116331 | Cataline et al. | Aug 2002 | A1 |
| 20020152123 | Giordano et al. | Oct 2002 | A1 |
| 20020152179 | Racov | Oct 2002 | A1 |
| 20030009374 | Moodie et al. | Jan 2003 | A1 |
| 20030024980 | Everett et al. | Feb 2003 | A1 |
| 20030055675 | Twennaar et al. | Mar 2003 | A1 |
| 20030055983 | Callegari | Mar 2003 | A1 |
| 20030115126 | Pitroda | Jun 2003 | A1 |
| 20030169881 | Niedermeyer | Sep 2003 | A1 |
| 20030177072 | Bared | Sep 2003 | A1 |
| 20030233306 | Madhavan et al. | Dec 2003 | A1 |
| 20040002902 | Muehlhaeuser | Jan 2004 | A1 |
| 20040093281 | Silverstein et al. | May 2004 | A1 |
| 20040128197 | Bam et al. | Jul 2004 | A1 |
| 20040185830 | Joao et al. | Sep 2004 | A1 |
| 20040200898 | Kepecs | Oct 2004 | A1 |
| 20040230483 | Kepecs | Nov 2004 | A1 |
| 20040254848 | Golan et al. | Dec 2004 | A1 |
| 20050060233 | Bonalle et al. | Mar 2005 | A1 |
| 20050071231 | Beenau et al. | Mar 2005 | A1 |
| 20050097046 | Singfield | May 2005 | A1 |
| 20050102212 | Roy | May 2005 | A1 |
| 20050102220 | Stackpole | May 2005 | A1 |
| 20050116810 | Beenau et al. | Jun 2005 | A1 |
| 20050131761 | Trika et al. | Jun 2005 | A1 |
| 20050160003 | Berardi et al. | Jul 2005 | A1 |
| 20050165695 | Berardi et al. | Jul 2005 | A1 |
| 20050170814 | Joao et al. | Aug 2005 | A1 |
| 20050187851 | Sant | Aug 2005 | A1 |
| 20050199709 | Linlor | Sep 2005 | A1 |
| 20050256802 | Ammermann et al. | Nov 2005 | A1 |
| 20060012473 | Bishop et al. | Jan 2006 | A1 |
| 20060022048 | Johnson | Feb 2006 | A1 |
| 20060074698 | Bishop et al. | Apr 2006 | A1 |
| 20060074813 | Saunders | Apr 2006 | A1 |
| 20060085330 | Imrey et al. | Apr 2006 | A1 |
| 20060085331 | Imrey et al. | Apr 2006 | A1 |
| 20060085332 | Imrey | Apr 2006 | A1 |
| 20060155569 | Lord et al. | Jul 2006 | A1 |
| 20060165060 | Dua | Jul 2006 | A1 |
| 20060219776 | Finn | Oct 2006 | A1 |
| 20060224470 | Garcia et al. | Oct 2006 | A1 |
| 20060282389 | Gupte | Dec 2006 | A1 |
| 20070005498 | Cataline et al. | Jan 2007 | A1 |
| 20070124673 | Trotto et al. | May 2007 | A1 |
| 20070125840 | Law et al. | Jun 2007 | A1 |
| 20070175978 | Stambaugh | Aug 2007 | A1 |
| 20070192245 | Fisher et al. | Aug 2007 | A1 |
| 20070198432 | Pitroda | Aug 2007 | A1 |
| 20070295803 | Levine et al. | Dec 2007 | A1 |
| 20080029607 | Mullen | Feb 2008 | A1 |
| 20080035738 | Mullen | Feb 2008 | A1 |
| 20080042423 | Roberts et al. | Feb 2008 | A1 |
| 20080054068 | Mullen | Mar 2008 | A1 |
| 20080054079 | Mullen | Mar 2008 | A1 |
| 20080054081 | Mullen | Mar 2008 | A1 |
| 20080065555 | Mullen | Mar 2008 | A1 |
| 20080120190 | Joao et al. | May 2008 | A1 |
| 20080121696 | Mock et al. | May 2008 | A1 |
| 20080140577 | Rahman et al. | Jun 2008 | A1 |
| 20080162338 | Samuels et al. | Jul 2008 | A1 |
| 20080177659 | Lacey et al. | Jul 2008 | A1 |
| 20080262969 | Samid | Oct 2008 | A1 |
| 20080275779 | Lakshminarayanan | Nov 2008 | A1 |
| 20080275820 | Joao et al. | Nov 2008 | A1 |
| 20080302869 | Mullen | Dec 2008 | A1 |
| 20080302876 | Mullen | Dec 2008 | A1 |
| 20080304431 | Karaoguz | Dec 2008 | A1 |
| 20090043623 | Blades et al. | Feb 2009 | A1 |
| 20090065571 | Jain | Mar 2009 | A1 |
| 20090065572 | Jain | Mar 2009 | A1 |
| 20090069049 | Jain | Mar 2009 | A1 |
| 20090069050 | Jain et al. | Mar 2009 | A1 |
| 20090069051 | Jain et al. | Mar 2009 | A1 |
| 20090069052 | Jain et al. | Mar 2009 | A1 |
| 20090070272 | Jain | Mar 2009 | A1 |
| 20090070691 | Jain | Mar 2009 | A1 |
| 20090070861 | Jain | Mar 2009 | A1 |
| 20090108064 | Fernandes et al. | Apr 2009 | A1 |
| 20090119226 | Kurczek et al. | May 2009 | A1 |
| 20090132813 | Schibuk | May 2009 | A1 |
| 20090132941 | Pilskalns et al. | May 2009 | A1 |
| 20090164322 | Khan et al. | Jun 2009 | A1 |
| 20090192906 | Rau et al. | Jul 2009 | A1 |
| 20090199283 | Jain | Aug 2009 | A1 |
| 20090265245 | Wright | Oct 2009 | A1 |
| 20090287603 | Lamar, III et al. | Nov 2009 | A1 |
| 20090307142 | Mardikar | Dec 2009 | A1 |
| 20100012721 | Jain et al. | Jan 2010 | A1 |
| 20100044444 | Jain et al. | Feb 2010 | A1 |
| 20100078471 | Lin et al. | Apr 2010 | A1 |
| 20100078472 | Lin et al. | Apr 2010 | A1 |
| 20100082481 | Lin et al. | Apr 2010 | A1 |
| 20100088148 | Presswala et al. | Apr 2010 | A1 |
| 20100142447 | Schlicht et al. | Jun 2010 | A1 |
| 20100264211 | Jain et al. | Oct 2010 | A1 |
| 20100293065 | Brody et al. | Nov 2010 | A1 |
| 20100299212 | Graylin et al. | Nov 2010 | A1 |
| 20100323681 | Corda et al. | Dec 2010 | A1 |
| 20100332650 | Aisen et al. | Dec 2010 | A1 |
| 20110004551 | Armes et al. | Jan 2011 | A1 |
| 20110082772 | Hirson | Apr 2011 | A1 |
| 20110087595 | Sabella | Apr 2011 | A1 |
| 20110098023 | Hammad | Apr 2011 | A1 |
| 20110106635 | Khan et al. | May 2011 | A1 |
| 20110112866 | Gerrans | May 2011 | A1 |
| 20110112898 | White | May 2011 | A1 |
| 20110112968 | Florek et al. | May 2011 | A1 |
| 20110119155 | Hammad et al. | May 2011 | A1 |
| 20110153403 | Postrel | Jun 2011 | A1 |
| 20110191252 | Dai | Aug 2011 | A1 |
| 20110208589 | Garg | Aug 2011 | A1 |
| 20110208656 | Alba et al. | Aug 2011 | A1 |
| 20110218911 | Spodak | Sep 2011 | A1 |
| 20110238471 | Trzcinski | Sep 2011 | A1 |
| 20120042080 | Aisen et al. | Feb 2012 | A1 |
| 20120239417 | Pourfallah et al. | Sep 2012 | A1 |
| 20120259781 | Fote et al. | Oct 2012 | A1 |
| Number | Date | Country |
|---|---|---|
| 0917119 | May 1999 | EP |
| WO 9806214 | Feb 1998 | WO |
| WO 2006045060 | Apr 2006 | WO |
| WO 2007103574 | Sep 2007 | WO |
| WO 2007103575 | Sep 2007 | WO |
| WO 2007103576 | Sep 2007 | WO |
| Entry |
|---|
| U.S. Appl. No. 12/372,554, filed Feb. 17, 2009. |
| U.S. Appl. No. 12/372,617, filed Feb. 17, 2009. |
| U.S. Appl. No. 12/372,710, filed Feb. 17, 2009. |
| U.S. Appl. No. 12/372,716, filed Feb. 17, 2009. |
| U.S. Appl. No. 09/630,595, filed Aug. 1, 2000. |
| U.S. Appl. No. 12/559,756, filed Sep. 15, 2009. |
| “U.S. Bank Tests Mastercard Mobile-Phone Payments in Spokane,”Cardline, Jan. 28, 2009. |
| “Fiserv Markets Mobile-Deposit Capability,” Cardline, Jul. 29, 2009. |
| “Amazon Launches Mobile Payments Service,” Cardline, Oct. 6, 2009. |
| Malykhina, “Cell Phone Software Formats Checks for Online Banking,” Informaton Week, Jan.3 24, 2008. |
| Kilian-Kehr, R. “Mobile Security with Smartcards,” Dissertation, Mar. 6, 2002. |
| “Electronic purse can free you from ATM drag,” Business Times, Feb. 23, 2001. |
| “Photo Deposits,” Cardflash, Jul. 28, 2009. |
| “Vivotech® Quicker than cash, Safer than checks™: RF-Based Contactless Payment: A More Convenient Way to Pay,” White Paper—Version 2.0, Apr. 2004. |
| “Aliaswire,” Cardflash, Mar. 30, 2010. |
| “Chase Said to be Reviewing Contactless-Stickers,” CardLine, Jun. 16, 2009. |
| Kahn, G., “'Charge It; Says Your Cellphone,” Wall Street Journal Online, Aug. 13, 2003. |
| “Citi Sees Weak Demand for Mobile P2P Transfers—for Now,” American Banker, Mar. 18, 2010. |
| “Bankcorp Issue Obopay Card That Links to Mobile Account,” Cardline, Sep. 11, 2008. |
| “Mobile Operators Announce Global Payment Initiative,” CardLine, Feb. 14, 2007. |
| “Cell Phone Software Formats Checks for Online Banking,” Information Week, Jan. 24, 2008. |
| Number | Date | Country | |
|---|---|---|---|
| 61288029 | Dec 2009 | US | |
| 61180218 | May 2009 | US | |
| 61162169 | Mar 2009 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12776961 | May 2010 | US |
| Child | 13163153 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12489066 | Jun 2009 | US |
| Child | 12776961 | US |
