Patent Grant
11295297
Embodiments of the present disclosure relate generally to the field of mobile wallets.
Payments for products and services are often completed using credit cards, debit cards, checks, and/or cash. At the same time, most people carry some type of mobile device. Electronic-based transactions may be carried out using a mobile device. For example, mobile device users may purchase goods and services through payment applications at point-of-sale terminals. Beneficially, using a mobile device to make payments at point-of-sale terminals may alleviate or reduce the need to carry cash or payment cards (e.g., credit cards), which some users may find appealing.
One embodiment relates to a computer-implemented method. The computer-implemented method includes receiving, by a mobile wallet computing system, information relating to a usable object from a party and provisioning, by the mobile wallet computing system, the usable object to a mobile wallet associated with a user. The computer-implemented method further includes receiving, by the mobile wallet computing system, one or more rules relating to the usable object from the party, wherein the one or more rules define an activation condition for the usable object such that when the activation condition is fulfilled the usable object is active in the mobile wallet of the user; determining, by the mobile wallet computing system, whether the activation condition is fulfilled; and in response to the activation condition for the usable object being fulfilled, activating, by the mobile wallet computing system, the usable object in the mobile wallet of the user.
Another embodiment relates to a mobile wallet computing system. The mobile wallet computing system includes a network interface structured to communicate data over a network, a processor, and a memory. The memory is coupled to the processor and includes non-transitory machine readable storage media having instructions stored thereon. When executed by the processor, the instructions cause the mobile wallet computing system to receive information relating to a usable object from a party and provision the usable object to a mobile wallet associated with a user. The instructions further cause the mobile wallet computing system to receive one or more rules relating to the usable object from the party, wherein the one or more rules define an activation condition for the usable object such that when the activation condition is fulfilled the usable object is active in the mobile wallet of the user, determine whether the activation condition for the usable object is fulfilled, and in response to the activation condition for the usable object being fulfilled, activate the usable object in the mobile wallet of the user.
Another embodiment relates to a mobile device associated with a user. The mobile device includes a display, a processor, and a memory. The memory includes non-transitory machine readable storage media having a mobile wallet application associated with a mobile wallet held by the user stored thereon. The memory is coupled to the processor, and the mobile wallet application includes instructions executable by the processor that are structured to cause the processor to receive a usable object for the mobile wallet of the user from a party, monitor a context of the mobile device with respect to one or more rules configured by the party, wherein the one or more rules define an activation condition for the usable object such that when the activation condition is fulfilled the usable object is active in the mobile wallet of the user, and in response to the activation condition for the usable object being fulfilled based on the context, activate the usable object in the mobile wallet of the user.
Referring to the Figures generally, various systems, methods, and apparatuses for third-party provisioning of a usable object to a mobile wallet and for pushing usable value objects from one mobile wallet to another mobile wallet are described herein. In various embodiments, a mobile device of a user includes a mobile wallet. As described in more detail below, a “mobile wallet” is a digital wallet provided on a user's mobile device that includes payment capabilities. In this regard, the mobile wallet may facilitate, enable, or otherwise transmit/provide a code, such as a barcode or a quick-response (“QR”) code, via a communication protocol (e.g., near-field communication (“NFC”)) to a point-of-sale terminal to transfer payment information and enable the purchase of a good or service. As such, the digital wallet may store usable value objects that can be used to make payments, such as a tokenized payment card (e.g., a credit card, a debit card), a non-tokenized payment card (e.g., a prepaid card such as a gift card), redeemable loyalty points, and so on. The digital wallet may further store non-payment usable objects that the user may wish to display or store using the user's mobile device, such as a ticket, a boarding pass, a coupon, an identification card, health care cards, insurance cards, library cards, transportation cards, and so on. The digital wallet may include many other capabilities, functions, and features that are described below in more detail.
In the embodiments described herein, while the user may cause provisioning of various usable objects to the user's mobile wallet, objects may also be provisioned to the user's mobile wallet by different “provisioning parties,” such as via third parties (e.g., individuals or organizations that do not have a mobile wallet account) or pushed to the user's mobile wallet by other mobile wallet users. Furthermore, the provisioning parties may be able to manually activate/deactivate the user's access to the pushed usable value object and/or set rules that automatically activate/deactivate the user's access to the pushed usable value object.
An example implementation may be described as follows. A user registers and activates a mobile wallet account with a mobile wallet computing system. A third party then causes a provisioning of a usable value object to the user's mobile wallet. Alternatively, a second user with a mobile wallet account causes a provisioning of a usable value object to the second user's mobile wallet. The second user then pushes the usable object to the first user's mobile wallet. Once the usable object is provisioned in the user's mobile wallet, the provisioning party (e.g., the third party or the second user) can manually activate or deactivate the usable object in the user's mobile wallet. Additionally, or alternatively, the provisioning party can set rules (e.g., rules that are dependent on the fulfillment of a condition or the occurrence of an event, such as the user being within a certain geographic area or that a certain amount of time has lapsed) that cause the usable object to be automatically activated or deactivated in the user's mobile wallet once the rules are fulfilled.
The systems and methods described herein for third-party provisioning and pushing of usable objects offer a number of technical advantages over current systems and methods for mobile wallets. Currently, mobile wallets predominantly require the user to register and provision all the usable objects that the user wishes to have access to in the user's mobile wallet. By contrast, the systems and methods described herein allow a third party without a mobile wallet to provision usable objects to a user's mobile wallet. Additionally, the systems and methods described herein allow other mobile wallet users to push usable objects provisioned in their own mobile wallets to the mobile wallets of other users. One technical advantage of the present systems and methods is that third parties and other users can use the present systems and methods to share usable objects with a mobile wallet user without the mobile wallet user having to personally register the usable object to the user's mobile wallet.
Furthermore, currently mobile wallets do not allow third parties or other users control over how another user uses objects provisioned to the user's mobile wallet. However, the present systems and methods allow third parties and other users to manually activate and deactivate usable objects that they have provisioned to a given user's mobile wallet. Alternatively, the present systems and methods allow third parties and other users to configure one or more rules for usable objects the third parties or other users have provisioned to a user's mobile wallet. When a condition or event associated with the rule or rules is fulfilled, the usable object is automatically activated or deactivated in the mobile wallet. Thus, another feature of the systems and methods described herein is that third parties and other users can provision or push usable objects to a user's mobile wallet and further exercise some level of control over how the usable objects are used. This feature provides the technical advantage of automating the process of applying third-party preferences for usable objects that have been provisioned to the user's mobile wallet. For example, without this feature, a mobile wallet user must manually remove, or remember not to use, a usable object from his or her mobile wallet for which the responsible third party has expressed a desire that the mobile wallet user no longer use or not use in certain circumstances. In turn, the user may be able to conduct mobile wallet transactions more quickly and more easily.
Referring now to
As used herein, a “usable object” or “usable value object” is any item that may be provisioned to a user's mobile wallet and later utilized by the user via the mobile wallet. Usable objects may include objects that can be used to make payments, such as payment cards. Payment usable objects may include tokenized objects (e.g., tokens for debit cards, credit cards, prepaid cards, gift cards, etc.) as well as objects that cannot or need not be tokenized (e.g., prepaid cards, gift cards, loyalty or rewards points, etc.). Usable value objects may also include non-payment objects, such as scans or other digital representations of various physical objects or e-items. For example, non-payment usable objects may include loyalty cards, identification cards (e.g., a driver's license, an employee identification card, a passport, etc.), membership cards, wholesale club cards, tickets, reservations, boarding passes, coupons, health care cards, insurance cards (e.g., automobile, health insurance, dental insurance, etc.), library cards, transportation cards (e.g., bus passes, transit fare passes, etc.), and so on.
In some arrangements, provisioning a usable object for in this arrangement making payments occurs by the third party submitting information about the usable object to the mobile wallet computing system 106, the mobile wallet computing system 106 tokenizing the object using the token service provider computing system 108, and either the mobile wallet computing system 106 or the token service provider computing system 108 provisioning the token to the user's mobile wallet on the user mobile device 102. In other arrangements, the usable object is not tokenized and instead directly provisioned to the user's mobile wallet on the user mobile device 102 once the third party submits information about the usable object to the mobile wallet computing system 106. Once the usable object is provisioned, the third party, via the third party computing system 104 communicating with the mobile wallet computing system 106, may further remotely activate and deactivate the usable object provisioned to the user's mobile wallet. Alternatively or additionally, the third party may configure rules for the usable object that cause the usable object to be automatically activated or deactivated within the mobile wallet on the user mobile device 102.
The user mobile device 102 includes any type of mobile device operated by a user in connection with services provided by a mobile wallet provider. As such, the user mobile device 102 includes, but is not limited to, a phone (e.g., a smartphone), a computing device (e.g., a tablet computer, a laptop computer, a personal digital assistant, etc.), a wearable device (e.g., a smart watch, smart glasses, a smart bracelet, etc.), and so on. As described in further detail below, the user mobile device 102 includes a mobile wallet associated with the user (e.g., implemented through a mobile wallet application 206). In the example shown, the user mobile device 102 is a smartphone.
Referring now to
The input/output circuit 202 is structured to receive communications from and provide communications to a user of the user mobile device 102. In this regard, the input/output circuit 202 is structured to exchange data, communications, instructions, etc. with an input/output component of the user mobile device 102. Accordingly, in one embodiment, the input/output circuit 202 may include an input/output device, such as a touchscreen, a keyboard, a microphone, or a speaker. In another embodiment, the input/output circuit 202 may include communication circuitry for facilitating the exchange of data, values, messages, and the like between an input/output device and the components of the user mobile device 102. In yet another embodiment, the input/output circuit 202 may include machine-readable media for facilitating the exchange of information between the input/output device and the components of the user mobile device 102. In still another embodiment, the input/output circuit 202 may include any combination of hardware components (e.g., a touchscreen), communication circuitry, and machine-readable media.
The display 204 may be a screen, a touchscreen, and the like. The user mobile device 102 may use the display 204 to communicate information to the user (e.g., by displaying the information to the user on the display 204) and/or to receive communications from the user (e.g., through a keyboard provided on a touchscreen of the display 204). In some embodiments, the display 204 may be a component of an input/output device, as described above.
In various embodiments, the user mobile device 102 includes a memory comprising non-transitory machine readable storage media having the mobile wallet application 206 stored fully or partly thereon. The memory is coupled to a processor, and the mobile wallet application 206 includes instructions that are executable by the processor. In this way, the mobile wallet application 206 is configured to interface with the mobile wallet computing system 106 to allow a user to manage the user's mobile wallet. For example, the mobile wallet application 206 may interface with the mobile wallet computing system 106 to facilitate the user in registering usable objects to the user's mobile wallet and in performing mobile wallet transactions with the usable objects (e.g., making a payment, displaying the usable object on the display 204, etc.). The mobile wallet application 206 is further configured to interface with the third party computing system 104 and/or the mobile wallet computing system 106 to receive usable objects from the third party computing system 104, as described in further detail below. Accordingly, in various arrangements, the mobile wallet application 206 is communicably coupled via the network interface 200 to the third party computing system 104, the mobile wallet computing system 106, and the token service provider computing system 108.
In some embodiments, the mobile wallet application 206 includes a circuit embodied within the user mobile device 102. For example, the mobile wallet application 206 may include program logic stored in a system memory of the user mobile device 102. In such arrangements, the program logic may configure a processor of the user mobile device 102 to perform at least some of the functions discussed below with respect to a mobile wallet system 404 of the mobile wallet computing system 106. In some embodiments, the mobile wallet application 206 is a web-based application, and many of the functionalities are provided by the mobile wallet system 404 of the mobile wallet computing system 106. Accordingly, as will be understood, the level of functionality that resides on the user mobile device 102 versus the mobile wallet computing system 106 will vary depending on the implementation.
It should also be understood that the role the mobile wallet application 206 takes in payment transactions will depend on the implementation of the mobile wallet. For example, in some arrangements, the mobile wallet may be configured in a secure element framework. In a secure element framework, the user mobile device 102 includes a secure element that is separate from the main system memory of the user mobile device 102 (e.g., any element having smart card functionalities, such as a universal subscriber identify circuit (a “SIM” card) or a secure digital card). Mobile wallet data, including tokens representing usable objects provisioned to the user's mobile wallet, for the user is stored in the secure element on the user mobile device 102. As another example, in other arrangements, the mobile wallet may be configured under a host card emulation (“HCE”) framework. In an HCE framework, mobile wallet data is maintained within a cloud-based environment. The cloud-based environment may enable provisioning of usable objects to the mobile wallet application 206 on the user mobile device 102. In this regard, the payment tokens are stored in the user mobile device 102 for a limited time (or a limited number of events) until they expire, and then new payment tokens are provisioned to the user mobile device 102. In yet other arrangements, the mobile wallet is implemented as a hybrid between a secure element framework and an HCE. All such variations are intended to fall within the scope of the present disclosure.
In various arrangements, the mobile wallet application 206 is structured to enable the user to manage the user's mobile wallet. In this regard, the mobile wallet application 206 is structured to present, control, and otherwise manage displays or graphic user interfaces on the user mobile device 102, for example, including information related to various usable objects provisioned to the user's mobile wallet. For example, the mobile wallet application 206 may present the user with displays enabling the user to input information relating to a usable object, such as a payment card, owned by the user (e.g., by entering a primary account number (“PAN”) for the payment card or by taking a picture of the payment card using a camera and the input/output circuit 202 of the user mobile device 102). The mobile wallet application 206 then processes the information input by the user and transmits the information to the mobile wallet computing system 106 for storage (e.g., in the mobile wallet database 410 in association with the user). As another example, the mobile wallet application 206 may interface with an application running on the user mobile device 102 (e.g., a text messaging application, an email application, a ticket application, a hotel application, etc.) and extract information about a usable object, such as a ticket, a pass, a reservation, or a coupon, from the application. The mobile wallet application 206 then transmits the information to the mobile wallet application 206 for storage. As a third example, the mobile wallet application 206 may monitor one or more online accounts associated with the user that the user has given the mobile wallet application 206 permission to access, such as an email account, ticketing account, or e-commerce account whereby the user may purchase vouchers (e.g., Groupon®, LivingSocial®). The mobile wallet application 206 extracts information relating to a usable object (e.g., a movie ticket, a concert ticket, a theatre ticket, a boarding pass, a train ticket, a voucher, a coupon, etc.) and transmits the extracted information to the mobile wallet computing system 106.
In some arrangements, after transmitting information about the usable payment object to the mobile wallet computing system 106, the mobile wallet application 206 then facilitates tokenization of the usable payment object. In this regard, the mobile wallet application 206 may receive a token associated with the usable object (e.g., a token representing a payment card) from the mobile wallet computing system 106 or the token service provider computing system 108. The mobile wallet application 206 may subsequently carry out mobile wallet transactions using the token. For non-tokenized usable value objects, the mobile wallet application 206 may receive a non-token representation of the usable object (e.g., a scan of the object, a digital representation of the object, etc.) from the mobile wallet computing system 106 or directly from the user, e.g., via the camera taking a picture of the object. For example, the mobile wallet application 206 may receive a scan of a driver's license. In still other arrangements, the mobile wallet application 206 may receive a token for a non-payment usable object that the user can use to temporarily download the usable object to the user's mobile wallet or to another computing device (e.g., the user mobile device 102 may receive a token representing the user's passport, and the user can submit the token to the mobile wallet computing system 106 and temporarily receive a scan of the user's passport on the user mobile device 102).
Alternatively, in other embodiments, the mobile wallet application 206 does not receive the usable object from the mobile wallet computing system 106. Instead, the mobile wallet application 206 gathers the information and generates a usable object for the user's mobile wallet independently. For example, the mobile wallet application 206 may extract information about a ticket that the user has purchased from an email application on the user mobile device 102. The mobile wallet application 206 then creates a digital ticket in the user's mobile wallet. The mobile wallet application 206 may simultaneously or subsequently transmit information about the usable object to the mobile wallet computing system 106 for storage.
Furthermore, in addition to receiving usable objects provisioned by the mobile wallet user, the mobile wallet application 206 may receive a usable object from a provisioning party, such as the third party. In some arrangements, the mobile wallet application 206 receives the usable object via the mobile wallet computing system 106 in the same manner the mobile wallet application 206 receives a usable object registered by the user to the user's mobile wallet (e.g., the mobile wallet computing system 106 provisions a token of the usable object registered by the third party to the mobile wallet application 206). In other arrangements, the mobile wallet application 206 at least partially receives the usable object via a device associated with the third party computing system 104. For example, the user mobile device 102 may include an NFC system including a chip and an associated controller that configures the chip to exchange information via NFC (e.g., an NFC reader). The mobile wallet application 206 may establish an NFC communication session with the third party device and receive the usable object from the third party computing system 104 via the third party device and the NFC communication session. As another example, the mobile wallet application 206 may perform an NFC tap with the device associated with the third party device to verify the user's location, after which the mobile wallet computing system 106 provisions the usable object to the user mobile device 102.
The mobile wallet application 206 may additionally present the user with displays enabling the user to engage in mobile wallet transactions using the usable objects provisioned to the user's mobile wallet. As used herein, the term “mobile wallet transaction” is meant to be broadly interpreted to refer to transactions accomplished via the mobile wallet on the user mobile device 102. As such, a mobile wallet transaction may include, but is not limited to, a person-to-person payment, a payment for a good or service at a point-of-sale terminal of a merchant, and the like. A mobile wallet transaction may also include a non-payment transaction, such as transmitting ticket information to a ticketing device or displaying a non-payment usable object on the display 204 of the user mobile device 102. In some arrangements, the mobile wallet application 206 engages in mobile wallet transactions through the initiation of communications with, for example, a merchant point-of-sale device. In this regard, the user mobile device 102 may include an NFC device configured to exchange information with a merchant point-of-sale device. The mobile wallet application 206 may thus transmit payment information to the merchant point-of-sale device using the NFC chip and associated controller. In other arrangements, the mobile wallet application 206 engages in mobile wallet transactions through the display 204. For example, the user mobile device 102 may display a QR code such that a third party can scan the QR code during a mobile wallet transaction.
The mobile wallet application 206 is also configured to present displays that enable the user to perform actions with usable objects. For example, the mobile wallet application 206 may present the user with displays enabling the user to make a payment with a usable object. As another example, the mobile wallet application 206 may present the user with displays enabling the user to show a usable object to an individual, a scanner, and so on. The mobile wallet application 206 may further present displays to the user directed to helping the user manage access to the usable objects in the user's mobile wallet. As an example, the mobile wallet application 206 may present the user with displays illustrating whether a usable object provisioned to the user's mobile wallet by a third party is active or not and, if the usable object has been deactivated, allow the user to send a message to the third party requesting that the usable object be reactivated.
Additionally, in some arrangements, the mobile wallet application 206 may be configured to present displays enabling the user to send messages to the third party computing system 104 or otherwise exchange information with the third party computing system 104. For example, the mobile wallet application 206 may allow the user to create a “thank you” message to the third party in response to receiving a usable object from the third party computing system 104. As another example, in response to a mobile wallet transaction being denied because the usable object has been deactivated (e.g., because the transaction violates rules for the usable object, as discussed in further detail below), the mobile wallet application 206 may allow the user to create a message asking the third party for one-time approval of the transaction or asking the third party to modify rules for the usable object such that the transaction may be allowed. As a third example, the mobile wallet application 206 may allow the user to create a message asking the third party to provision a specific usable object to the user's mobile wallet. The mobile wallet application 206 then transmits the message to the third party computing system 104 directly or indirectly via the mobile wallet computing system 106.
The third party computing system 104 is associated with a “third party,” which as used herein refers to a party that does not have a mobile wallet with the mobile wallet computing system 106 but is interested in provisioning usable objects to a mobile wallet user. For example, the third party may be an individual who does not have a mobile wallet or who has a mobile wallet with a mobile wallet provider different from the provider associated with the mobile wallet computing system 106. As another example, the third party may be a merchant (e.g., a retailer, wholesaler, marketplace operator, service provider, etc.).
Referring now to
The processing circuit includes a processor 308 and a memory 310. As shown in
The usable object provisioning circuit 304 is configured to generate information relating to usable objects and provision or facilitating provisioning of the usable objects to user mobile wallets, such as the mobile wallet on the user mobile device 102. In some arrangements, the usable object provisioning circuit 304 provisions a usable object to the user mobile device 102 via the mobile wallet computing system 106. For example, if the third party is a merchant, an individual may purchase a gift card associated with the third party for the user. In response, the usable object provisioning circuit 304 may gather information about the user from the individual and generate information relating to the purchased gift card (e.g., generate a gift card number to be used in transactions). The usable object provisioning circuit 304 may then transmit the information to the mobile wallet computing system 106, which provisions the gift card to the mobile wallet on the user mobile device 102 (e.g., by downloading the gift card number or a token of the gift card number to the user mobile device 102). The usable object provisioning circuit 304 may also store the information in the usable object database 312.
In other arrangements, the usable object provisioning circuit 304 directly provisions the usable object to the mobile wallet. As an example, if the third party is a merchant, the usable object provisioning circuit 304 may generate a coupon (e.g., a generic coupon, a coupon tailored for the user) and store the coupon in the usable object database 312. The usable object provisioning circuit 304 may then provide the usable object to the mobile wallet on the user mobile device 102 when the user mobile device 102 is at a merchant brick-and-mortar location. For instance, the third party computing system 104 may include a point-of-sale terminal with a radio-frequency identification (“RFID”) device or an NFC device in the brick-and-mortar location. When the user makes a purchase using the user's mobile wallet on the user mobile device 102 at the point-of-sale terminal, the usable object provisioning circuit 304 provisions the coupon to the mobile wallet on the user mobile device 102 via the point-of-sale terminal. Alternatively, the brick-and-mortar location of the merchant may have a Wi-Fi hotspot. Accordingly, the usable object provisioning circuit 304 may provision the coupon to the user mobile device 102 when the user mobile device 102 connects to the Wi-Fi hotspot. As another option, the usable object provisioning circuit 304 may include a handheld electronic device (e.g., a tablet run by an employee of the third party) with Bluetooth functionalities. As such, the usable object provisioning circuit 304 may provision the coupon to the user mobile device 102 through a Bluetooth session between the handheld electronic device and the user mobile device 102. Once the usable object provisioning circuit 304 provisions the usable object to the user mobile device 102, the usable object provisioning circuit 304 may also transmit a notification to the mobile wallet computing system 106 indicating that the usable object has been provisioned to the user mobile device 102.
In yet other arrangements, the usable object provisioning circuit 304 provisions the usable object through a combination of the mobile wallet computing system 106 and the third party computing system 104. For example, the mobile wallet computing system 106 may require the third party computing system 104 to take one or more actions to authenticate the user before provisioning the usable object. An example of an authentication process may be an NFC tap between the user mobile device 102 and a computing device (e.g., a point-of-sale device, a tablet, etc.) associated with the third party computing system 104, which indicates that the parties are proximate to each other at the time of the provisioning. Once the usable object provisioning circuit 304 submits proof of the authentication to the mobile wallet computing system 106, the mobile wallet computing system 106 provisions the usable object to the user mobile device 102.
The usable object management circuit 306 is configured to manage the user's access to a usable object provisioned to the user mobile device 102 by the usable object provisioning circuit 304. In some arrangements, the usable object management circuit 306 communicates with the mobile wallet computing system 106 (e.g., via the network interface 300) to activate and deactivate the usable object in the user's mobile wallet. For example, the usable object management circuit 306 may detect that the user is within a geographic distance of a brick-and-mortar location associated with the third party (e.g., based on the usable object management circuit 306 interfacing with the user mobile device 102 and using a global positioning system (“GPS”) functionality of the user mobile device 102 to determine the location of the user mobile device 102, based on the user mobile device 102 connecting to a Wi-Fi hotspot at the brick-and-mortar location, etc.). In response, the usable object management circuit 306 notifies the mobile wallet computing system 106 to activate a usable object provisioned to the user's mobile wallet. Subsequently, when the usable object management circuit 306 detects that the user is outside of the geographic distance from the brick-and-mortar location, the usable object management circuit 306 notifies the mobile wallet computing system 106 to deactivate the usable object.
In other arrangements, alternatively or additionally, the usable object management circuit 306 sets up one or more rules with the mobile wallet computing system 106. As described in further detail below, the mobile wallet computing system 106 automatically activates or deactivates the usable object within the user's mobile wallet based on whether activation or deactivation conditions defined by rule(s) are fulfilled. Activation or deactivation conditions may include a geofence (e.g., defined by certain latitude/longitude coordinates, defined as a radius around certain coordinates, etc.), a purchase amount limit, a time limitation (e.g., the usable object is only active for a certain number of hours or days, the usable object is only active between certain hours of a day, the usable object is only active for certain dates, etc.), a merchant limitation (e.g., as classified by the Merchant Category Code (“MCC”) or the North American Industry Classification System (“NAICS”)), a zip code, a product code (e.g., as classified by a Universal Product Code (“UPC”) of the item being purchased), the hardware the mobile wallet is running on, and so on. Additionally, a usable object may be activated or deactivated in response to an activation or deactivation condition of a rule being fulfilled. As an example, the usable object management circuit 306 may configure rules for a usable object such that the usable object is deactivated once a certain number of days have passed or if the user mobile device 102 leaves certain zip codes. As another example, the usable object management circuit 306 may configure rules such that a usable payment object is only activated only when the user is making a purchase with the usable object at merchants classified under certain MCCs. Furthermore, a usable object may only be activated or deactivated in response to two or more conditions defined by the rules being fulfilled. For example, the usable object management circuit 306 may configure rules for a usable payment object including a geofence and a purchase limit such that the usable object remains active if the user leaves the geofence or goes over the purchase limit but is deactivated if both occur.
It should be understood that, in other embodiments, the third party computing system 104 may be configured differently from the embodiment of the third party computing system 104 shown in
The mobile wallet computing system 106 is structured to permit, enable, facilitate, manage, process, and otherwise allow mobile wallet transactions. In this regard, the mobile wallet computing system 106 may store information relating to various usable objects. The mobile wallet computing system 106 is associated with, owned by, and/or otherwise operated by a mobile wallet provider. In some embodiments, the mobile wallet provider is a financial institution, such as the issuer associated with the issuer computing system 110. In other embodiments and as shown in
Referring now to
The processing circuit 402 includes a processor 406 and a memory 408. As shown in
In some arrangements, the mobile wallet database 410 also includes a token vault that is maintained by the mobile wallet computing system 106. The token vault may include a lookup table maintaining tokens associated with various tokenized usable objects. The token vault and the token generation process are described in further detail below with respect to the token service provider computing system 108.
The mobile wallet system 404 is structured to provide mobile wallet services for the user, including providing a mobile wallet in the user mobile device 102. In some embodiments, the mobile wallet system 404 is structured to provide a mobile wallet client application (e.g., the mobile wallet application 206 described above) on the user mobile device 102. In this regard, the mobile wallet system 404 enables activation and registration of a mobile wallet account for the user, presents the user with various user interfaces enabling the user to use and manage the mobile wallet (e.g., register usable objects to the user's mobile wallet), and enables the user to perform transactions using the mobile wallet. Additionally, the mobile wallet system 404 is further structured to interface with the third party computing system 104 such that the third party computing system 104 can register usable objects to the user's mobile wallet and manage the user's access to the registered usable objects in the user's mobile wallet.
As shown in
The application interface circuit 412 is structured to integrate payment-related functionalities and usable object registration into a user's mobile wallet, as well as enable usable object registration by the third party computing system 104 to the user's mobile wallet. In some arrangements, the application interface circuit 412 includes a series of software elements that provide accessibility to various functionalities discussed herein.
The user interface management circuit 414 is structured or configured to generate, update, control, or otherwise manage displays/graphical user interfaces of the mobile wallet. Moreover, in various arrangements, the user interface management circuit 414 updates the user interfaces responsive to user interactions with various portions of a mobile wallet interface presented to a user. In some arrangements, the user interface management circuit 414 may further be structured or configured to generate, update, control, or otherwise manage displays/graphical user interfaces displayed to the third party via the third party computing system 104. For example, if the third party is an individual, the user interface management circuit 414 may interface with the third party computing system 104 to display user interfaces that allow the third party to register usable objects to the user's mobile wallet (e.g., via a web-based application, via a banking application, etc.).
The mobile wallet account activation circuit 416 is structured to perform a activation process whereby a mobile wallet account for the user is created. In this regard, the mobile wallet account activation circuit 416 may present a first-time user with a plurality of activation interfaces (e.g., viewable by a web browser on the user mobile device 102) prompting the first-time user to input information such as user identifying information, login credentials, and the like. The activation interfaces may also ask the user permission to access, for example, user social media data, user accounts, and other data.
The usable object registration circuit 418 is structured to perform a registration process whereby usable objects are registered and provisioned to a user's mobile wallet. As discussed herein, usable objects may be registered and provisioned to the user's mobile wallet by the user or by a provisioning party (e.g., by a third party or by a secondary mobile wallet user, as described in further detail below). In this regard, the usable object registration circuit 418 may present the user or third party with a plurality of registration interfaces (e.g., shown to the user via the mobile wallet application 206) prompting the user or a third party to input information relating to a usable object to be registered (e.g., to manually input a PAN, a barcode, a driver's license number, and so on, to take a picture of the usable object, etc.). As an illustration, the registration interfaces may prompt the user or third party to register a payment card by manually inputting a PAN for the payment card or by taking a picture of the payment card using the camera on a smartphone. The usable object registration circuit 418 then receives the input information. Alternatively, or additionally, the usable object registration circuit 418 may simply receive information relating to a usable object from the user mobile device 102 and/or the third party computing system 104. For example, the usable object registration circuit 418 may receive information for a usable object generated by the usable object provisioning circuit 304 of the third party computing system 104. Furthermore, in some embodiments, the usable object registration circuit 418 may interface and extract information relating to an item to be registered from various user and/or third party accounts that the user and/or third party has given the usable object registration circuit 418 permission to access.
In various embodiments, once the usable object registration circuit 418 has received information for a usable object from the user or a provisioning party, the usable object registration circuit 418 is configured to store the information in the mobile wallet database 410. If the usable object is tokenizable (e.g., the usable object is a payment card), the usable object registration circuit 418 is configured to facilitate the tokenization of the usable object and the provisioning of the token to the user's mobile wallet on the user mobile device 102. For example, the usable object registration circuit 418 is configured to communicate with the token service provider computing system 108 to tokenize the usable object. Alternatively, if the usable object cannot be tokenized or does not need to be tokenized (e.g., the token is an e-ticket or a photo identification card), the usable object registration circuit 418 may instead provide a digital representation of the usable object (e.g., a scan of the usable object or a digital version of the usable object) to the mobile wallet on the user mobile device 102.
The rules configuration circuit 420 is structured to facilitate the third party in setting up rules for a usable object that the third party has provisioned to the user's mobile wallet. In some arrangements, the rules configuration circuit 420 may present the third party with a plurality of interfaces via the third party computing system 104 that facilitate the third party in setting up the one or more rules relating to the provisioned usable object. The rules configuration circuit 420 then collects the inputs from the third party in response to the user interfaces. Alternatively, the rules configuration circuit 420 may simply receive rules from the third party computing system 104 (e.g., the third party is a merchant, and the third party computing system 104 automatically submits standard rules for the usable object). Regardless, once the rules configuration circuit 420 receives the rules from the third party computing system 104, the rules configuration circuit 420 retrievably stores the rules in the mobile wallet database 410.
The access management circuit 422 is structured to manage the active status of a usable object provisioned to the user's mobile wallet by the third party computing system 104. In some embodiments, the access management circuit 422 interfaces with the third party computing system 104 and receives an indication from the third party computing system 104 as to whether the usable object should be active or inactive. For example, the access management circuit 422 may present the third party with a plurality of interfaces via the third party computing system 104 (e.g., through a web-based application running on the third party computing system 104) that facilitate the third party in activating and deactivating the usable object (e.g., by presenting the user with a button that the user can toggle to activate and deactivate the usable object, as shown in
In other embodiments, alternatively or additionally, the access management circuit 422 automatically activates or deactivates the usable objects based on activation or deactivation conditions associated with the rules received by the rules configuration circuit 420 and stored in the mobile wallet database 410. Accordingly, in such embodiments, the access management circuit 422 is configured to continuously monitor the context of the user (e.g., monitor the user mobile device 102, monitor the environment of the user, etc.) to determine whether the conditions of the rules for a given usable object are fulfilled. In one embodiment, the access management circuit 422 monitors the user mobile device 102 and uses one or more applications and/or one or more functionalities of the user mobile device 102 to determine whether conditions of the rules are fulfilled. For example, the access management circuit 422 may determine whether the user is within a geofence by using GPS functionalities of the user mobile device 102, using a Wi-Fi network the user mobile device 102 is connected to, and so on. In another embodiment, the access management circuit 422 determines whether conditions of the rules are fulfilled using internal functionalities of the mobile wallet computing system 106. For example, the mobile wallet computing system 106 may include an internal clock, and the access management circuit 422 may use the internal clock to determine whether a day/week/month access limit condition is fulfilled. In a third embodiment, the access management circuit 422 may determine whether conditions of the rules are fulfilled by interfacing with functionalities provided by outside parties, such as by interfacing with an online calendar of the user. In a fourth embodiment, the access management circuit 422 determines whether conditions of the rules are fulfilled based on purchase information transmitted to the mobile wallet computing system 106 (e.g., by a point-of-sale device or by the user mobile device 102) as part of a mobile wallet transaction. For example, the purchase information may include an MCC for the merchant the user is making the purchase from, and the access management circuit 422 may determine whether a merchant limitation is fulfilled based on the MCC.
If the access management circuit 422 receives an indication that the usable object should be made currently usable, or “active,” or should be made currently unusable, or “inactive,” from the third party computing system 104, or if the access management circuit 422 determines that the conditions defined by the rules for a usable object are fulfilled, the access management circuit 422 modifies the user's access to the usable object accordingly. For example, in embodiments of the mobile wallet including HCE, the access management circuit 422 may delete the token or other representation of the usable object from the user mobile device 102. Alternatively, the access management circuit 422 may delete the token for the usable object in the token vault or prevent a new token representing the usable object from being provisioned to the user mobile device 102 once an old token for the usable object expires. Conversely, the access management circuit 422 may provision the token or other representation of the usable object to the user mobile device 102. As another example, in some embodiments, the access management circuit 422 may take steps to prevent the usable object from being successfully used, such as denying a transaction request received from the user mobile device 102 using the token or alerting the issuer computing system 110 to deny any transaction payments requested by the user with the usable object. Otherwise, the access management circuit 422 may take steps to allow the usable object to be used, such as alerting the issuer computing system 110 to allow transaction payments requested by the user with the usable object.
In other embodiments, the access management circuit 422 may not directly activate or deactivate the usable object in the user's mobile wallet on the user mobile device 102. Rather, the access management circuit 422 may configure the mobile wallet application 206 to activate and deactivate the usable object in the user's mobile wallet. For example, the access management circuit 422 may provide the rules configured by the third party to the mobile wallet application 206. The mobile wallet application 206 may then determine whether the activation or deactivation conditions of the rules are fulfilled and activate or deactivate the usable object in the mobile wallet accordingly.
In certain embodiments, the access management circuit 422 may alternatively allow partial mobile wallet transactions to proceed if conditions of one or more rules for the usable object are fulfilled. As an example, the third party may configure a purchase limit condition for the usable object. Subsequently, if the access management circuit 422 receives a purchase request from the user mobile device 102 that violates the purchase limit condition, the access management circuit 422 may authorize the transaction amount up to the purchase limit (e.g., by transmitting the purchase request in the amount up to the purchase limit to the issuer or a card network associated with the usable object). The access management circuit 422 may then deny the remainder of the transaction request. As another example, the third party may configure a product limit for the usable object. As such, if the access management circuit 422 receives a purchase request from the user mobile device 102 including allowed products and prohibited products, the access management circuit 422 may authorize the transaction only for the allowed products.
In still other embodiments, the access management circuit 422 may transmit a notification (e.g., by the notification circuit 424) to the third party when the user requests a mobile wallet transaction for a deactivated usable object and/or a mobile wallet transaction that violates one or more rules (e.g., meets the deactivation condition(s) for the one or more rules) for the usable object. The third party can then respond to the notification within a certain amount of time to authorize the transaction (e.g., by transmitting a purchase request to the issuer or card network associated with the usable object, by provisioning a representation of the usable object to the user's mobile wallet on the user mobile device 102, etc.), after which the access management circuit 422 allows the transaction to proceed.
The notification circuit 424 is configured to transmit or to facilitate the transmission of notifications relating to a mobile wallet. In some arrangements, the notification circuit 424 is configured to transmit various notifications to the user mobile device 102 (e.g., via the mobile wallet application 206). For example, the notification circuit 424 may transmit a notification to the user mobile device 102 when the third party has provisioned a usable object to the user's mobile wallet (e.g., as an email, as a text message, to the mobile wallet application 126 which then displays the notification as a push notification on the user mobile device 102, etc.). As another example, the notification circuit 424 may transmit a notification to the user mobile device 102 when the third party, either manually or automatically via rules, has modified the user's access to the usable object. As a third example, the notification circuit 424 may transmit a notification to the user mobile device 102 informing the user of changes that the third party has made to rules for a usable object. In other arrangements, the notification circuit 424 is configured to transmit various notifications to the third party computing system 104. As an example, the notification circuit 424 may notify the third party computing system 104 when the user has performed a mobile wallet transaction with the usable object, when the rules have caused the usable object to be automatically activated or deactivated within the user's mobile wallet, and so on. Moreover, in various arrangements, the notification circuit 424 may transmit messages received from the user mobile device 102 to the third party computing system 104. For example, the notification circuit 424 may transmit a message from the user mobile device 102 to the third party computing system 104 asking the third party to confirm that the user is authorized to use the usable object or asking the third party to authorize a transaction carried out with the usable object.
The token service provider computing system 108 includes a computing system configured to provision payment credentials (e.g., payment tokens) on behalf of a mobile wallet user. The token service provider computing system 108 may be operated by a credit card network or other type of payment system, an acquiring or issuing financial institution (e.g., associated with the issuer computing system 110 or associated with the user), a merchant, a mobile wallet provider (e.g., mobile wallet computing system 106), and/or another provider. Accordingly, the token service provider computing system 108 may be a separate computing system, as shown in
Referring now to
The processing circuit 502 includes a processor 506 and a memory 508. As shown in
The token generator circuit 504 is configured to facilitate various services associated with payment tokens, including generating and provisioning new tokens, authorizing a token for use in a financial transaction, storing tokens for usable objects (e.g., in the token database 510), and managing the life cycles of the tokens. For example, the token generator circuit 504 may manage expiration times for various tokens, after which the tokens are no longer valid, and download new tokens to the user mobile device 102 to replace expired tokens. Additionally, the token generator circuit 504 may be configured to provision tokens to the user mobile device 102 in response to a request received from the mobile wallet computing system 106.
More specifically, the token generator circuit 504 is configured to generate and provision tokens for usable objects stored in the mobile wallet database 410 using tokenization processes. For example, the mobile wallet computing system 106 may request, from the token service provider computing system 108, a token for a usable object registered by the third party. In response, the token generator circuit 504 may create a token by generating a random number, by generating a random string of alphanumeric characters, by inputting a number associated with each item into a tokenization algorithm (e.g., computing a hash of a PAN of a usable payment object), and the like for each requested usable object. The token generator circuit 504 may then store each token, as well as the token's association with the corresponding usable object, in the token database 510. Alternatively, or additionally, the token generator circuit 504 may provide the token to the mobile wallet computing system 106, which may store the token in a token vault maintained internally within the mobile wallet computing system 106 (e.g., within the mobile wallet database 410).
As used herein, an “issuer” is a party with which the user, the third party, or, as discussed in further detail below, a secondary mobile wallet user holds one or more accounts (e.g., a demand deposit account, credit account, brokerage account, etc.) and that enables payments on behalf of the user. For example, an issuer may be a banking institution with which the user or the third party holds one or more accounts (i.e., the issuing entity of, for example, a payment card of the user, such as a credit card). As another example, an issuer may be a credit card company with which the user or the third party holds a credit card account. Additionally, an issuer may be responsible for the creation of a physical usable object, such as a credit card, that may be provisioned to the user's mobile wallet. Accordingly, in the context of the present disclosure, the issuer can include commercial or private banks, credit unions, investment brokerages, mobile wallet providers (e.g., the issuer computing system 110 may include the mobile wallet computing system 106), and so on. As such, the issuer computing system 110 is a computing system associated with one or more financial accounts held by the user or the third party.
Referring now to
The processing circuit 602 includes a processor 606 and a memory 608. As shown in
As described above, in some arrangements, the issuer computing system 110 is associated with the issuer of a usable object held by the user or third party. As an example, the issuer may be the issuer of a credit card held by the third party. As another example, the issuer may be the issuer of a credit card held by the user and affiliated with the third party, such as a rewards credit card affiliated with a merchant. In other arrangements, the third party holds one or more accounts with the issuer associated with the issuer computing system 110. In either of these arrangements, the payment processing circuit 604 of the issuer computing system 110 is configured to process a payment with the usable object, either from an account held by the user with the issuer or from an account held by the third party with the issuer.
As an example, the third party computing system 104 may provision a voucher for an item to the user's mobile wallet. The user may then purchase the item from a merchant using the voucher in the user's mobile wallet at a point-of-sale device. The point-of-sale device sends the payment request to the issuer computing system 110 (e.g., via the mobile wallet computing system 106), and the issuer computing system 110 makes a payment in the amount of the item from an account held by the third party to an account held by the merchant (e.g., at a separate acquirer associated with the merchant). In another example, the user opens a credit card account with the issuer, the credit card account being associated with the third party. The third party computing system 104 provides the information about the credit card to the mobile wallet computing system 106, which tokenizes the credit card (e.g., using the token service provider computing system 108) and provisions the token to the mobile wallet on the user mobile device 102. When the user subsequently makes a purchase using the credit card token in the user's mobile wallet, the issuer computing system 110 makes a payment from the credit card account held by the user to an account held by the merchant.
However, those of skill in the art will understand that in certain embodiments of the system 100, the system 100 may not include the issuer computing system 110 or may instead include a different computing system. For example, the third party computing system 104 may provision a loyalty card to the user's mobile wallet, in which case the issuer computing system 110 may be replaced by a loyalty card management system in the system 100.
Referring now to
In various embodiments, the user mobile device 702 is structured similarly to the user mobile device 102 described above with reference to
Additionally, instead of a third party computing system 104, the system 700 includes a secondary user mobile device 704. Similar to the user mobile device 702, the secondary user mobile device 704 includes any type of mobile device operated by a secondary user in connection with services provided by a mobile wallet provider. As such, the secondary user mobile device 704 includes, but is not limited to, a phone (e.g., a smartphone), a computing device (e.g., a tablet computer, a laptop computer, a personal digital assistant, etc.), a wearable device (e.g., a smart watch, smart glasses, a smart bracelet, etc.), and so on. As shown, the secondary user mobile device 704 is a smartphone.
Referring now to
In various embodiments, the secondary user mobile device 704 includes a memory comprising non-transitory machine readable storage media having the mobile wallet application 806 stored thereon. The memory is coupled to a processor, and the mobile wallet application 806 includes instructions that are executable by the processor. Furthermore, in various embodiments, the mobile wallet application 806 is configured similarly to the mobile wallet application 206 of the user mobile device 102 such that the secondary user can use the mobile wallet application 806 to register usable objects to the secondary user's mobile wallet and perform mobile wallet transactions with those usable objects. Additionally, the mobile wallet application 806 is configured to enable the secondary user to push usable objects to the user's mobile wallet. In some arrangements, the mobile wallet application 806 is configured to display user interfaces to the secondary user (e.g., via the display 804) whereby the secondary user can select a usable object and enter information regarding a user to whom the secondary user wishes to push the usable object. The mobile wallet application 806 then transmits that information to the mobile wallet computing system 106, which provisions the usable object (e.g., in the form of a token or other digital representation) to the mobile wallet on the user mobile device 102.
In other arrangements, the mobile wallet application 806 may display user interfaces to the secondary user enabling the secondary user to select a mobile wallet account for another user of the mobile wallet computing system 706 (e.g., by inputting a username of the other user, by inputting biographical information about the other user, etc.). Once the other user is identified, the secondary user can input a preference to link the secondary user's mobile wallet with the mobile wallet of the selected user, which the mobile wallet application 806 submits to the mobile wallet computing system 106. The linking process is described in further detail below with reference to
As still other arrangements, the mobile wallet application 806 may be configured to communicate with other mobile wallet applications running on other mobile devices, including the mobile wallet application on the user mobile device 702, through the input/output circuit 802 (e.g., through an NFC or RFID device included as part of the input/output circuit 802). When the secondary user provides an input to the mobile wallet application 806 indicating that the secondary user would like to provision a usable object to the user's mobile wallet, the mobile wallet application 806 is thus configured to display user interfaces instructing the secondary user to bring the secondary user mobile device 704 in proximity to the user mobile device 702. When the user mobile device 102 and the secondary user mobile device 704 are in sufficient proximity to each other (e.g., close enough for an NFC tap), the mobile wallet application 806 begins a communication session with the mobile wallet application on the user mobile device 702, and the mobile wallet application 806 provisions the usable object to the user's mobile wallet via the communication session. The mobile wallet application 806 may also transmit a notification to the mobile wallet computing system 706 indicating that the usable object has been provisioned to the user's mobile wallet.
Additionally, the mobile wallet application 806 is configured to facilitate the secondary user in managing the user's access to the provisioned usable object in the user's mobile wallet. In various arrangements, the mobile wallet application 806 is configured to display user interfaces to the secondary user that allow the secondary user to manually activate/deactivate the usable object and/or configure rules for the usable object, similar to the usable object management circuit 306 described above with respect to the third party computing system 104.
In various embodiments, the mobile wallet computing system 706 is structured similarly to the mobile wallet computing system 106. For example, the mobile wallet computing system 706 may include a network interface, a processing circuit including a mobile wallet database, and a mobile wallet system that are similar to the network interface 400, processing circuit 402 with mobile wallet database 410, and mobile wallet system 404 shown in
Additionally, in various embodiments, the mobile wallet computing system 706 is configured to link the mobile wallet accounts of various users, such as the user's mobile wallet and the secondary user's mobile wallet, in response to linking request from one or both users to link their mobile wallet accounts. In some arrangements, the mobile wallet computing system 706 may require the user or the secondary user to perform an authentication process (e.g., input a password or piece of biographical information) before linking their mobile wallet accounts. In other arrangements, the mobile wallet computing system 706 may require the non-requesting user to confirm that the non-requesting user would like to link accounts with the requesting user.
Furthermore, the mobile wallet computing system 706 is configured to facilitate the secondary user in pushing usable objects registered to the secondary user's mobile wallet to the user's mobile wallet. In various arrangements, the mobile wallet computing system 706 facilitates the secondary user in pushing the usable objects similarly to how the mobile wallet computing system 706 facilitates the third party in registering and provisioning usable objects to the user's mobile wallet as discussed above with respect to
In various embodiments, the token service provider computing system 708 is also configured similarly to the token service provider computing system 108 described above with reference to
The issuer computing system 710 is a computing system associated with one or more financial accounts (e.g., a demand deposit account, credit account, brokerage account, etc.) held by the user or the secondary user. In various embodiments, the issuer computing system 710 is structured similarly to the issuer computing system 110 described above with reference to
Referring now to
Referring first to
At process 904, information relating to a usable object is received from a third party that does not have a mobile wallet. In various arrangements, the mobile wallet computing system 106 receives information relating to a usable object from the third party via the third party computing system 104. Subsequently, at process 906, the usable object is provisioned to the user mobile wallet. In some arrangements, the usable object is a payment object. As such, the mobile wallet computing system 106 may store the information relating to the usable object in the mobile wallet database 410, tokenize the usable object (e.g., via the token service provider computing system 108), and provision the token to the user mobile device 102. In other arrangements, the usable object is not a payment object. Accordingly, the mobile wallet computing system 106 may provision another representation of the usable object to the user mobile device 102 (e.g., a scan of the usable object, a digital representation of the usable object, etc.). Alternatively, the mobile wallet computing system 106 may simply receive the information about the usable object, and the third party computing system 104 may communicate with the mobile wallet application 206 on the user mobile device 102 to provision the usable object to the user's mobile wallet.
At process 908, an instruction to activate or deactivate the usable object in the user mobile wallet is received from the third party. In various arrangements, the mobile wallet computing system 106 receives the activation/deactivation instruction from the third party computing system 104. Accordingly, at process 910, in response to the instruction, the usable object is activated or deactivated in the user mobile wallet, as described above. For example, the mobile wallet computing system 106 provisions a token or other representation of the usable object to the user mobile device 102, or deletes a token or other representation of the usable object on the user mobile device 102, in response to the instruction.
Referring now to
At process 1008, one or more rules relating to the usable object are received from the third party. In various embodiments, the mobile wallet computing system 106 receives one or more rules defining activation and/or deactivation conditions from the third party computing system 104 (e.g., a geofence, a purchase amount limit, a time limitation, a merchant limitation, a zip code use limitation, product code limits, limits on the hardware the mobile wallet can be used on, etc.). The mobile wallet computing system 106 then stores those rules in the mobile wallet database 410. It should be understood, however, that the order of processes 1004, 1006, and 1008 may differ in certain embodiments. For example the third party may submit the rules at the same time the third party provides the information relating to the usable object to the mobile wallet computing system 106.
At process 1010, whether the activation/deactivation condition(s) defined by the rule(s) for the usable object are fulfilled is determined. Accordingly, in various arrangements, the mobile wallet computing system 106 monitors the context of the user to determine whether the conditions defined by the rules for a given usable object are fulfilled (e.g., by interfacing with the user mobile device 102 and using functionalities of the user mobile device 102, by using internal functionalities of the mobile wallet computing system 106, by using functionalities provided by outside parties, etc.). At process 1012, in response to the condition(s) being fulfilled, the usable object is activated or deactivated in the user mobile wallet. In various arrangements, the mobile wallet computing system 106 activates or deactivates the usable object similarly to process 910 of
Referring now to
Referring first to
At process 1106, the user mobile wallet and the secondary user mobile wallet are linked. In some arrangements, the mobile wallet computing system 706 receives a preference from the user via the user mobile device 702 and/or the secondary user via the secondary user mobile device 704 to link their mobile wallet accounts. The mobile wallet computing system 706 may further perform an authentication of the user and/or the secondary user in response to the request. Subsequently, the mobile wallet computing system 706 links the mobile wallet accounts for the user and the secondary user such that additional functionalities are available to the user and secondary user, such as pushing a usable from one mobile wallet to the other. In other arrangements, the mobile wallet computing system 706 receives a request from the user or the secondary user to link their mobile wallet accounts. The mobile wallet computing system 706 submits the request to the other of the user or the secondary user for approval and, in response to receiving the approval, links the two mobile wallet accounts.
At process 1108, information relating to a usable object is received from the secondary user. In various arrangements, the mobile wallet computing system 706 receives information relating to a usable object from the secondary user via the secondary user mobile device 704. Subsequently, at process 1110, the usable object is provisioned to the secondary user's mobile wallet. In some arrangements, the usable object is a payment object, and the mobile wallet computing system 706 tokenizes the usable payment object (e.g., via the token service provider computing system) and provisions the token to the secondary user mobile device 704. In other arrangements, the usable object is not a payment usable object, and the mobile wallet computing system 706 provisions another representation of the usable object to the secondary user mobile device 704 (e.g., a scan of the usable object, a digital representation of the usable object, etc.).
At process 1112, an instruction to push the usable object to the user's mobile wallet is received from the secondary user. In various arrangements, the mobile wallet computing system 706 receives an indication from the secondary user mobile device 704 identifying the usable object and requesting that the usable object be provisioned to the linked mobile wallet for the user. At process 1114, in response to the instruction, the usable object is pushed to the user's mobile wallet. Process 1114 may, in various arrangements, occur similarly to process 906 discussed above with respect to
At process 1116, an instruction to activate or deactivate the usable object in the user's mobile wallet is received from the secondary user. In various arrangements, the mobile wallet computing system 706 receives the instruction from the secondary user mobile device 704. In response, at process 1118, the usable object is activated or deactivated in the user's mobile wallet. Process 1118 may, in various arrangements, occur similarly to process 910 discussed above with respect to
Referring now to
Additionally, at process 1216, one or more rules relating to the usable object are received from the secondary user. In various embodiments, the mobile wallet computing system 706 receives one or more rules defining activation and/or deactivation conditions from the secondary user mobile device 704 (e.g., a geofence, a purchase amount limit, a time limitation, a merchant limitation, a zip code use limitation, product code limits, limits that the mobile wallet can be used on, etc.). The mobile wallet computing system 706 then stores those rules in a mobile wallet database (e.g., similar to the mobile wallet database 410 of the mobile wallet computing system 106). It should be understood, however, that the order of processes 1208, 1210, 1212, 1214, and 1216 may differ in certain embodiments. For example, the secondary user may submit the rules at the same time the secondary party provides the information relating to the usable object to the mobile wallet computing system 106 or at the same time the secondary user provides the instruction to push the usable object to the user mobile wallet to the mobile wallet computing system 106.
At process 1218, whether the activation/deactivation condition(s) defined by the rule(s) for the usable object are fulfilled is determined. Moreover, at process 1220, in response to the rule(s) being fulfilled, the usable object is activated or deactivated in the user's mobile wallet. In various arrangements, processes 1218 and 1220 occur similarly to processes 1010 and 1012 described above with reference to
Referring now to
As illustrated in
The rules section 1504 also includes a button 1506 that the secondary user can press to view other rules options (e.g., in response to which the secondary user will be redirected to another screen with additional rules options that the secondary user can select from). Accordingly, those of skill in the art will understand that the rule options shown in the rules section 1504 are merely potential rules options. For example, while the rules options shown in
The rules configuration screen 1500 also includes a button 1506 that the secondary user can press to go back to the selection screen 1402 (e.g., as shown in
Referring now to
Referring now to
Further, the section 1802 includes a rules subsection 1806 that lists the rules that the secondary user has configured for the payment card in the user's wallet. In the example of
Additionally, as shown in
However, it should be understood that
It should further be understood that while
Referring now to
Referring now to
Those of skill in the art will understand, however, that
The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.
It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
As used herein, the term “circuit” may include machine or computer-readable media that are executable by one or more processors (e.g., multiple remote processors connected to each other through any type of network). The machine-readable media may include code, which may be written in any programming language, including, but not limited to, Java or the like and any conventional procedural programming languages, such as the “C” programming language or similar programming languages. Alternatively, the term “circuit” may include hardware structured to execute the functions described herein, and in some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, or XNOR), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on. Thus, a circuit may also include programmable hardware devices such as field programmable gate arrays, programmable array logic programmable logic devices, or the like.
In other embodiments, the “circuit” includes one or more processors communicably coupled to one or more memories or memory devices. In this regard, the one or more processors execute instructions stored in the memory or execute instructions otherwise accessible to the one or more processors. In various arrangements, the one or more processors are embodied in various ways and are constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors are shared by multiple circuits (e.g., circuit A and circuit B comprise or otherwise share the same processor which, in some example embodiments, executes instructions stored, or otherwise accessed, via different areas of memory). Additionally, in various arrangements, a given circuit or components thereof (e.g., the one or more processors) are disposed locally (e.g., as part of a local server or a local computing system) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, in certain arrangements, a “circuit” as described herein includes components that are distributed across one or more locations.
As used herein, a processor is implemented as a general-purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components. Additionally, in some arrangements, a “processor,” as used herein, is implemented as one or more processors. In certain embodiments, the one or more processors are structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors are coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. In some arrangements, the one or more processors take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, or quad core processor), microprocessor, and the like. In some embodiments, the one or more processors are external to the apparatus, for example, the one or more processors are a remote processor (e.g., a cloud based processor). Alternatively, or additionally, the one or more processors are internal and/or local to the apparatus. Accordingly, an exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit.
Additionally, as used herein, a memory includes one or more memory devices including non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), and the like. In some embodiments, the non-volatile media takes the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, or 3D NOR), EEPROM, MRAM, magnetic storage, hard discs, optical discs, and the like. In some embodiments, the volatile storage media takes the form of RAM, TRAM, ZRAM, and the like. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. In various arrangements, each respective memory device is operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, or script components), in accordance with the example embodiments described herein.
It should be understood that a “network interface,” as used herein, is structured to communicate data over a network (e.g., the network 112 or the network 712) includes any of a cellular transceiver (Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Long-Term Evolution (LTE), etc.), a wireless network transceiver (e.g., 802.11X, ZigBee, or Bluetooth), or a combination thereof (e.g., both a cellular transceiver and a Bluetooth transceiver). In some arrangements, a network interface includes hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, the network interface includes cryptography capabilities to establish a secure or relatively secure communication session between the device including the network interface and other devices of the system 100 via the network 112. In this regard, personal information about clients, financial data, and other types of data is encrypted and transmitted to prevent or substantially prevent the threat of hacking.
It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.
Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques, with rule-based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5412192 | Hoss | May 1995 | A |
| 5778067 | Jones et al. | Jul 1998 | A |
| 6016484 | Williams et al. | Jan 2000 | A |
| 6018724 | Arent | Jan 2000 | A |
| 6615194 | Deutsch et al. | Sep 2003 | B1 |
| 6865547 | Brake et al. | Mar 2005 | B1 |
| 6873974 | Schutzer | Mar 2005 | B1 |
| 7765481 | Dixon et al. | Jul 2010 | B2 |
| 7822206 | Birk et al. | Oct 2010 | B2 |
| 7827057 | Walker et al. | Nov 2010 | B1 |
| 7909243 | Merkow et al. | Mar 2011 | B2 |
| 7930225 | Wahlberg et al. | Apr 2011 | B2 |
| 7945776 | Atzmony et al. | May 2011 | B1 |
| 7970669 | Santos | Jun 2011 | B1 |
| 8019365 | Fisher | Sep 2011 | B2 |
| 8078140 | Baker et al. | Dec 2011 | B2 |
| 8126806 | Dimartino et al. | Feb 2012 | B1 |
| 8160959 | Rackley et al. | Apr 2012 | B2 |
| 8215560 | Granucci et al. | Jul 2012 | B2 |
| 8280788 | Perlman | Oct 2012 | B2 |
| 8332290 | Venturo et al. | Dec 2012 | B1 |
| 8401904 | Simakov et al. | Mar 2013 | B1 |
| 8433657 | Dinan | Apr 2013 | B2 |
| 8452257 | Granucci et al. | May 2013 | B2 |
| 8467766 | Rackley et al. | Jun 2013 | B2 |
| 8468587 | Blinn et al. | Jun 2013 | B2 |
| 8489067 | Rackley, III et al. | Jul 2013 | B2 |
| 8504699 | Vaughan et al. | Aug 2013 | B2 |
| 8533123 | Hart | Sep 2013 | B2 |
| 8538845 | Liberty | Sep 2013 | B2 |
| 8548908 | Friedman | Oct 2013 | B2 |
| 8548926 | Balistierri et al. | Oct 2013 | B2 |
| 8555361 | Nakhjiri et al. | Oct 2013 | B2 |
| 8566237 | Forzley | Oct 2013 | B2 |
| 8566239 | Arthur et al. | Oct 2013 | B2 |
| 8577803 | Chatterjee et al. | Nov 2013 | B2 |
| 8615468 | Varadarajan | Dec 2013 | B2 |
| 8627424 | O'Malley et al. | Jan 2014 | B1 |
| 8639621 | Ellis et al. | Jan 2014 | B1 |
| 8645971 | Carlson et al. | Feb 2014 | B2 |
| 8676704 | Ledbetter et al. | Mar 2014 | B2 |
| 8700729 | Dua | Apr 2014 | B2 |
| 8706628 | Phillips | Apr 2014 | B2 |
| 8725576 | Fisher | May 2014 | B2 |
| 8725577 | Fisher | May 2014 | B2 |
| 8732080 | Karim | May 2014 | B2 |
| 8744966 | Amacker et al. | Jun 2014 | B1 |
| 8750901 | Gupta et al. | Jun 2014 | B1 |
| 8768830 | Jorgensen et al. | Jul 2014 | B1 |
| 8768834 | Zacarias et al. | Jul 2014 | B2 |
| 8774781 | Speiser et al. | Jul 2014 | B1 |
| 8781955 | Schamer et al. | Jul 2014 | B2 |
| 8831677 | Villa-Real | Sep 2014 | B2 |
| 8838501 | Priebatsch | Sep 2014 | B1 |
| 8843125 | Kwon et al. | Sep 2014 | B2 |
| 8843417 | Hammad | Sep 2014 | B2 |
| 8880432 | Collins, Jr. | Nov 2014 | B2 |
| 8924246 | Chen et al. | Dec 2014 | B1 |
| 8925805 | Grigg et al. | Jan 2015 | B2 |
| 8972297 | Kay et al. | Mar 2015 | B2 |
| 8977251 | Grigg et al. | Mar 2015 | B2 |
| 8989712 | Wentker et al. | Mar 2015 | B2 |
| 9020836 | Fisher et al. | Apr 2015 | B2 |
| 9026460 | Grigg et al. | May 2015 | B2 |
| 9027109 | Wolberg-Stok et al. | May 2015 | B2 |
| 9037509 | Ellis et al. | May 2015 | B1 |
| 9043240 | Langus et al. | May 2015 | B2 |
| 9098190 | Zhou et al. | Aug 2015 | B2 |
| 9177307 | Ross et al. | Nov 2015 | B2 |
| 9208488 | Liberty | Dec 2015 | B2 |
| 9218624 | Moghadam | Dec 2015 | B2 |
| 9256876 | Vasant Akole et al. | Feb 2016 | B2 |
| 9286606 | Diamond | Mar 2016 | B2 |
| 9324068 | Soundararajan | Apr 2016 | B2 |
| 9361616 | Zhou et al. | Jun 2016 | B2 |
| 9691058 | Epler et al. | Jun 2017 | B2 |
| 9704157 | Ellis et al. | Jul 2017 | B1 |
| 9741051 | Carpenter et al. | Aug 2017 | B2 |
| 9805363 | Rudnick et al. | Oct 2017 | B1 |
| 10140615 | Carpenter et al. | Nov 2018 | B2 |
| 10169812 | Bajgier et al. | Jan 2019 | B1 |
| 10380596 | Butler et al. | Aug 2019 | B1 |
| 10445739 | Sahni et al. | Oct 2019 | B1 |
| 20020032602 | Lanzillo et al. | Mar 2002 | A1 |
| 20030028481 | Flitcroft et al. | Feb 2003 | A1 |
| 20030055785 | Lahiri | Mar 2003 | A1 |
| 20030056096 | Albert et al. | Mar 2003 | A1 |
| 20040230535 | Binder et al. | Nov 2004 | A1 |
| 20040236632 | Maritzen et al. | Nov 2004 | A1 |
| 20040254848 | Golan et al. | Dec 2004 | A1 |
| 20040260646 | Berardi et al. | Dec 2004 | A1 |
| 20050021401 | Postrel | Jan 2005 | A1 |
| 20050043997 | Sahota et al. | Feb 2005 | A1 |
| 20050077350 | Courtion et al. | Apr 2005 | A1 |
| 20050086492 | Nicodemus et al. | Apr 2005 | A1 |
| 20050125317 | Winkelman et al. | Jun 2005 | A1 |
| 20050138377 | First et al. | Jun 2005 | A1 |
| 20050184145 | Law et al. | Aug 2005 | A1 |
| 20050235363 | Hibbard et al. | Oct 2005 | A1 |
| 20060253335 | Keena et al. | Nov 2006 | A1 |
| 20070168354 | Ramer et al. | Jul 2007 | A1 |
| 20070174873 | Griggs | Jul 2007 | A1 |
| 20070199061 | Byres et al. | Aug 2007 | A1 |
| 20070244811 | Tumminaro | Oct 2007 | A1 |
| 20080005006 | Tritt et al. | Jan 2008 | A1 |
| 20080006685 | Rackley, III et al. | Jan 2008 | A1 |
| 20080033878 | Krikorian et al. | Feb 2008 | A1 |
| 20080040265 | Rackley, III et al. | Feb 2008 | A1 |
| 20080127317 | Nakhjiri | May 2008 | A1 |
| 20080208742 | Arthur et al. | Aug 2008 | A1 |
| 20080242274 | Swanburg et al. | Oct 2008 | A1 |
| 20080294556 | Anderson | Nov 2008 | A1 |
| 20080319887 | Pizzi et al. | Dec 2008 | A1 |
| 20090048971 | Hathaway et al. | Feb 2009 | A1 |
| 20090157531 | Bui | Jun 2009 | A1 |
| 20090177563 | Bernstein et al. | Jul 2009 | A1 |
| 20090228966 | Parfene et al. | Sep 2009 | A1 |
| 20090271287 | Halpern | Oct 2009 | A1 |
| 20090319427 | Gardner et al. | Dec 2009 | A1 |
| 20100114731 | Kingston et al. | May 2010 | A1 |
| 20100114733 | Collas et al. | May 2010 | A1 |
| 20100125495 | Smith et al. | May 2010 | A1 |
| 20100191602 | Mikkelsen et al. | Jul 2010 | A1 |
| 20100205077 | Hammad | Aug 2010 | A1 |
| 20110055080 | Ahlers et al. | Mar 2011 | A1 |
| 20110106674 | Perlman | May 2011 | A1 |
| 20110145149 | Valdes et al. | Jun 2011 | A1 |
| 20110153498 | Makhotin et al. | Jun 2011 | A1 |
| 20110191160 | Blackhurst et al. | Aug 2011 | A1 |
| 20110196782 | Allen et al. | Aug 2011 | A1 |
| 20110251892 | Laracey | Oct 2011 | A1 |
| 20110270748 | Graham et al. | Nov 2011 | A1 |
| 20110289004 | Prakash et al. | Nov 2011 | A1 |
| 20110295748 | Woodriffe | Dec 2011 | A1 |
| 20120011063 | Killian et al. | Jan 2012 | A1 |
| 20120018511 | Hammad | Jan 2012 | A1 |
| 20120022944 | Volpi | Jan 2012 | A1 |
| 20120078735 | Bauer et al. | Mar 2012 | A1 |
| 20120078751 | MacPhail et al. | Mar 2012 | A1 |
| 20120084210 | Farahmand | Apr 2012 | A1 |
| 20120110634 | Jakobsson | May 2012 | A1 |
| 20120130731 | Canetto | May 2012 | A1 |
| 20120143705 | Bhattacharya et al. | Jun 2012 | A1 |
| 20120150669 | Langley et al. | Jun 2012 | A1 |
| 20120150687 | Hart | Jun 2012 | A1 |
| 20120158589 | Katzin et al. | Jun 2012 | A1 |
| 20120185317 | Wong | Jul 2012 | A1 |
| 20120185387 | Doyle | Jul 2012 | A1 |
| 20120196586 | Grigg et al. | Aug 2012 | A1 |
| 20120197793 | Grigg et al. | Aug 2012 | A1 |
| 20120197794 | Grigg et al. | Aug 2012 | A1 |
| 20120209749 | Hammad et al. | Aug 2012 | A1 |
| 20120239417 | Pourfallah et al. | Sep 2012 | A1 |
| 20120253852 | Pourfallah et al. | Oct 2012 | A1 |
| 20120254021 | Wohied | Oct 2012 | A1 |
| 20120271705 | Postrel | Oct 2012 | A1 |
| 20120271712 | Katzin et al. | Oct 2012 | A1 |
| 20120284130 | Lewis et al. | Nov 2012 | A1 |
| 20120296720 | Pirillo | Nov 2012 | A1 |
| 20120303425 | Katzin et al. | Nov 2012 | A1 |
| 20120310774 | Chassin | Dec 2012 | A1 |
| 20120323762 | Kapur et al. | Dec 2012 | A1 |
| 20120330837 | Persaud et al. | Dec 2012 | A1 |
| 20130006848 | Kuttuva | Jan 2013 | A1 |
| 20130018777 | Klein | Jan 2013 | A1 |
| 20130018792 | Casey et al. | Jan 2013 | A1 |
| 20130030941 | Meredith et al. | Jan 2013 | A1 |
| 20130042261 | Tavormina et al. | Feb 2013 | A1 |
| 20130054454 | Purves et al. | Feb 2013 | A1 |
| 20130060679 | Oskolkov et al. | Mar 2013 | A1 |
| 20130060696 | Martin et al. | Mar 2013 | A1 |
| 20130060708 | Oskolkov et al. | Mar 2013 | A1 |
| 20130065555 | Baker et al. | Mar 2013 | A1 |
| 20130073365 | McCarthy | Mar 2013 | A1 |
| 20130073459 | Zacarias et al. | Mar 2013 | A1 |
| 20130080241 | Fisher | Mar 2013 | A1 |
| 20130110658 | Lyman et al. | May 2013 | A1 |
| 20130132854 | Raleigh et al. | May 2013 | A1 |
| 20130144663 | Qawami et al. | Jun 2013 | A1 |
| 20130144702 | Tabor et al. | Jun 2013 | A1 |
| 20130166332 | Hammad | Jun 2013 | A1 |
| 20130185167 | Mestre et al. | Jul 2013 | A1 |
| 20130191227 | Pasa et al. | Jul 2013 | A1 |
| 20130191277 | O'Leary et al. | Jul 2013 | A1 |
| 20130191278 | O'Leary et al. | Jul 2013 | A1 |
| 20130200999 | Spodak et al. | Aug 2013 | A1 |
| 20130204785 | Monk et al. | Aug 2013 | A1 |
| 20130226751 | Friedholm et al. | Aug 2013 | A1 |
| 20130226799 | Raj | Aug 2013 | A1 |
| 20130232032 | Chaturvedi et al. | Sep 2013 | A1 |
| 20130238455 | Laracey | Sep 2013 | A1 |
| 20130246260 | Barten | Sep 2013 | A1 |
| 20130246261 | Purves et al. | Sep 2013 | A1 |
| 20130246265 | Al-Sahli | Sep 2013 | A1 |
| 20130260734 | Jain et al. | Oct 2013 | A1 |
| 20130262309 | Gadotti | Oct 2013 | A1 |
| 20130262316 | Hruska | Oct 2013 | A1 |
| 20130290121 | Simakov et al. | Oct 2013 | A1 |
| 20130290169 | Bathula et al. | Oct 2013 | A1 |
| 20130304642 | Campos | Nov 2013 | A1 |
| 20130317928 | Laracey | Nov 2013 | A1 |
| 20140006129 | Heath | Jan 2014 | A1 |
| 20140006276 | Grigg et al. | Jan 2014 | A1 |
| 20140012750 | Kuhn et al. | Jan 2014 | A1 |
| 20140019352 | Shrivastava | Jan 2014 | A1 |
| 20140019360 | Yang | Jan 2014 | A1 |
| 20140038546 | Neal et al. | Feb 2014 | A1 |
| 20140058855 | Hussein et al. | Feb 2014 | A1 |
| 20140058936 | Ren | Feb 2014 | A1 |
| 20140074581 | Johnson et al. | Mar 2014 | A1 |
| 20140074655 | Lim et al. | Mar 2014 | A1 |
| 20140074724 | Gordon et al. | Mar 2014 | A1 |
| 20140081783 | Paranjape et al. | Mar 2014 | A1 |
| 20140081854 | Sanchez et al. | Mar 2014 | A1 |
| 20140089171 | Gandhi | Mar 2014 | A1 |
| 20140096215 | Hessler | Apr 2014 | A1 |
| 20140100975 | Van | Apr 2014 | A1 |
| 20140101048 | Gardiner et al. | Apr 2014 | A1 |
| 20140108254 | Lee | Apr 2014 | A1 |
| 20140108263 | Ortiz et al. | Apr 2014 | A1 |
| 20140114856 | Jung et al. | Apr 2014 | A1 |
| 20140122310 | Torrens et al. | May 2014 | A1 |
| 20140122563 | Singh | May 2014 | A1 |
| 20140129357 | Goodwin | May 2014 | A1 |
| 20140129442 | Hanson et al. | May 2014 | A1 |
| 20140136352 | Ramakrishna et al. | May 2014 | A1 |
| 20140143089 | Campos et al. | May 2014 | A1 |
| 20140180849 | Kimberg et al. | Jun 2014 | A1 |
| 20140188718 | Grossman et al. | Jul 2014 | A1 |
| 20140188719 | Poornachandran et al. | Jul 2014 | A1 |
| 20140207680 | Rephlo | Jul 2014 | A1 |
| 20140214640 | Mallikarjunan et al. | Jul 2014 | A1 |
| 20140222670 | Concannon | Aug 2014 | A1 |
| 20140244506 | Gramling | Aug 2014 | A1 |
| 20140249948 | Graylin et al. | Sep 2014 | A1 |
| 20140250003 | Levchin et al. | Sep 2014 | A1 |
| 20140279097 | Alshobaki et al. | Sep 2014 | A1 |
| 20140279469 | Mendes | Sep 2014 | A1 |
| 20140279489 | Russell et al. | Sep 2014 | A1 |
| 20140279566 | Verma et al. | Sep 2014 | A1 |
| 20140282068 | Levkovitz | Sep 2014 | A1 |
| 20140297435 | Wong | Oct 2014 | A1 |
| 20140297520 | Levchin et al. | Oct 2014 | A1 |
| 20140297524 | Ravindranath et al. | Oct 2014 | A1 |
| 20140304095 | Fisher | Oct 2014 | A1 |
| 20140310182 | Cummins | Oct 2014 | A1 |
| 20140337175 | Katzin et al. | Nov 2014 | A1 |
| 20140337621 | Nakhimov | Nov 2014 | A1 |
| 20140351072 | Wieler et al. | Nov 2014 | A1 |
| 20140351126 | Priebatsch | Nov 2014 | A1 |
| 20140351130 | Cheek et al. | Nov 2014 | A1 |
| 20140365363 | Knudsen et al. | Dec 2014 | A1 |
| 20140376576 | Jespersen et al. | Dec 2014 | A1 |
| 20140379576 | Marx et al. | Dec 2014 | A1 |
| 20150019944 | Kalgi | Jan 2015 | A1 |
| 20150026049 | Theurer et al. | Jan 2015 | A1 |
| 20150032627 | Dill et al. | Jan 2015 | A1 |
| 20150046241 | Salmon et al. | Feb 2015 | A1 |
| 20150046339 | Wong et al. | Feb 2015 | A1 |
| 20150074774 | Nema et al. | Mar 2015 | A1 |
| 20150088633 | Salmon et al. | Mar 2015 | A1 |
| 20150089568 | Sprague et al. | Mar 2015 | A1 |
| 20150095075 | Breuer et al. | Apr 2015 | A1 |
| 20150095219 | Hurley | Apr 2015 | A1 |
| 20150100442 | Van Heerden et al. | Apr 2015 | A1 |
| 20150112781 | Clark et al. | Apr 2015 | A1 |
| 20150140960 | Powell et al. | May 2015 | A1 |
| 20150154588 | Purves et al. | Jun 2015 | A1 |
| 20150178693 | Solis | Jun 2015 | A1 |
| 20150178725 | Poetsch | Jun 2015 | A1 |
| 20150186875 | Zhang et al. | Jul 2015 | A1 |
| 20150186886 | Schwalb et al. | Jul 2015 | A1 |
| 20150187021 | Moring et al. | Jul 2015 | A1 |
| 20150193869 | Del Vecchio et al. | Jul 2015 | A1 |
| 20150220914 | Purves et al. | Aug 2015 | A1 |
| 20150229622 | Grigg et al. | Aug 2015 | A1 |
| 20150254698 | Bondesen et al. | Sep 2015 | A1 |
| 20150254699 | Bondesen et al. | Sep 2015 | A1 |
| 20150287015 | Kaplinger et al. | Oct 2015 | A1 |
| 20150324768 | Filter et al. | Nov 2015 | A1 |
| 20150332252 | Shahrokhi et al. | Nov 2015 | A1 |
| 20150339662 | Huang et al. | Nov 2015 | A1 |
| 20150371326 | Montesano et al. | Dec 2015 | A1 |
| 20160004876 | Bye et al. | Jan 2016 | A1 |
| 20160012465 | Sharp | Jan 2016 | A1 |
| 20160026999 | Kurian | Jan 2016 | A1 |
| 20160042341 | Griffin et al. | Feb 2016 | A1 |
| 20160042344 | Thimmana et al. | Feb 2016 | A1 |
| 20160048828 | Lee | Feb 2016 | A1 |
| 20160063496 | Royyuru et al. | Mar 2016 | A1 |
| 20160065370 | Le Saint et al. | Mar 2016 | A1 |
| 20160086170 | Hurt et al. | Mar 2016 | A1 |
| 20160086179 | Barbier | Mar 2016 | A1 |
| 20160092696 | Guglani et al. | Mar 2016 | A1 |
| 20160092866 | Liberty et al. | Mar 2016 | A1 |
| 20160092868 | Salama et al. | Mar 2016 | A1 |
| 20160092874 | O'Regan et al. | Mar 2016 | A1 |
| 20160125396 | Brickell et al. | May 2016 | A1 |
| 20160125409 | Meredith et al. | May 2016 | A1 |
| 20160125417 | Huang et al. | May 2016 | A1 |
| 20160132875 | Blanco et al. | May 2016 | A1 |
| 20160140555 | Scipioni | May 2016 | A1 |
| 20160162889 | Badenhorst | Jun 2016 | A1 |
| 20160342962 | Brown et al. | Nov 2016 | A1 |
| 20160342992 | Lee | Nov 2016 | A1 |
| 20160379215 | Clerkin | Dec 2016 | A1 |
| 20170017958 | Scott et al. | Jan 2017 | A1 |
| 20170061402 | Mobin et al. | Mar 2017 | A1 |
| 20170061406 | Adams et al. | Mar 2017 | A1 |
| 20170164139 | Deselaers et al. | Jun 2017 | A1 |
| 20170193468 | Chougule et al. | Jul 2017 | A1 |
| 20170228715 | Gurunathan | Aug 2017 | A1 |
| 20180007052 | Quentin | Jan 2018 | A1 |
| 20180068308 | Gupta et al. | Mar 2018 | A1 |
| 20180082283 | Sharma | Mar 2018 | A1 |
| 20180157336 | Harris et al. | Jun 2018 | A1 |
| 20180322488 | Arana et al. | Nov 2018 | A1 |
| 20180365675 | Sivaraman | Dec 2018 | A1 |
| 20180374076 | Wheeler | Dec 2018 | A1 |
| 20190304029 | Murray et al. | Oct 2019 | A1 |
| 20210166260 | Ho et al. | Jun 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| WO-2011113121 | Sep 2011 | WO |
| WO-2012139003 | Oct 2012 | WO |
| WO-2013079793 | Jun 2013 | WO |
| WO-2014012138 | Jan 2014 | WO |
| WO-2014111888 | Jul 2014 | WO |
| WO-2014207615 | Dec 2014 | WO |
| WO-2015016780 | Feb 2015 | WO |
| WO2015023172 | Feb 2015 | WO |
| WO-2016009198 | Jan 2016 | WO |
| WO-2016053975 | Apr 2016 | WO |
| WO-2016097879 | Jun 2016 | WO |
| WO-2016172107 | Oct 2016 | WO |
| WO-2016196054 | Dec 2016 | WO |
| Entry |
|---|
| A Smart Card Alliance Payments Council White Paper; Publication date: Sep. 2011; Publication No. PC-11002; 191 Clarksville Rd. Princeton Junction, NJ 08550 www.smartcardalliance.org (Year: 2011). |
| How to Control Children's Spending on Debit Cards | Money | by Jill Paperworth, May 10, 2009, https:www.theguardian.com/money/2009/mar/.../children-debit-cards-online-spend . . . (Year: 2009). |
| Smart Card Alliance, “The Mobile Payments and NFC Landscape: A U.S. Perspective,” Sep. 2011. 53 pages. |
| “Cashcloud Mobile eWallet”, FinTech Forum Exchange, Jul. 1, 2016. 4 pages. |
| “Cashcloud mobile eWallet”, Popote Payments, www.popotepayments.com, 2016. 6 pages. |
| Lehdonvirta et al., UbiPay: Minimizing Transaction Costs with Smart Mobile Payments, Proceedings of the 6th International Conference on Mobile Technology, Application & Systems, ACM, Jan. 2009, retrieved from the Internet at http://www.researchgate.net/profile/Tatsuo_Nakajima/publication/220982951_UbiPay_minimizing_transaction_costs_with_smart_mobile_payments/links/548e9dad0cf225bf66a607bb.pdf on Oct. 30, 2015, 8 pages. |
| White, Ron, “How Computers Work”, Que Publishing, 7th Ed, Oct. 15, 2003, p. 4. 23 pages. |
| EMV, “Payment Tokenisation Specification Technical Framework”, 2014 EMVCO, LLC. 84 pages. |
| Kyrillidis, Mayes, Markantonakis; Card-present Transactions on the Internet Using the Smart CardWeb Server; 2013, IEEE; 12th (Year: 2013). |
| The University of Alaska staff, Managing Finance Reports with Vista Plus, Aug. 2008, The University of Alaska, web, 2-20 (Year: 2008). |
