HK1198068A

HK1198068A - Virtual wallet card selection apparatuses, methods and systems

Info

Publication number: HK1198068A
Application number: HK14111539.9A
Authority: HK
Inventors: S.查特吉
Original assignee: 维萨国际服务协会
Priority date: 2011-06-03
Filing date: 2012-06-01
Publication date: 2015-03-06

Description

Virtual wallet card selection device, method and system

This written patent application discloses and describes various novel innovative and inventive aspects of virtual wallet card selection techniques (hereinafter the present disclosure) and contains content that is protected by copyright, integrated circuit layout design, and/or other intellectual property rights. As this application appears in published patent office documents/records, the respective owner of the intellectual property rights is silent as to the facsimile reproduction of the disclosure by anyone, but otherwise reserves all rights whatsoever.

Priority declaration

Priority of U.S. provisional patent application serial No. 61/492,854 entitled "VIRTUAL WALLET CARD selective napparatuses, METHODS AND SYSTEMS", attorney docket No. P-42069PRV | 20270-.

Technical Field

The present invention relates generally to devices, methods and systems for electronic purchase transactions, and more particularly, to virtual wallet card selection devices, methods and systems ("VWCS").

Background

Consumer transactions require the consumer to select a product from a store shelf and then checkout the product at a checkout counter. The consumer is typically provided with a variety of payment options, such as cash, check, credit or debit card, by entering product information into a point-of-sale terminal device, or automatically by scanning the item barcode using an integrated barcode scanner. Once payment is made and approved, the point-of-sale terminal remembers the transaction in the merchant's computer system and generates a receipt indicating satisfactory completion of the transaction.

Drawings

The accompanying appendices, figures, pictures, etc., illustrate various examples, non-limiting, inventive aspects, embodiments, and features ("e.g.," or "examples") according to the present disclosure:

1A-C show block diagrams illustrating example aspects of a purchase transaction based on virtual wallet card selection in some embodiments of a VWCS;

fig. 2 shows an application user interface diagram illustrating example features for selecting a mobile application from a virtual wallet card selected from a plurality of payment options in some embodiments of the VWCS;

3A-C show application user interface diagrams illustrating example features of a virtual wallet card selection mobile application for obtaining user data and preventing fraud in some embodiments of a VWCS;

4A-C show data flow diagrams illustrating an example process of performing a card-based transaction using virtual wallet card selection in some embodiments of a VWCS;

5A-E show a logic flow diagram illustrating example aspects of the use of a virtual wallet card to select execution of a card-based transaction in some embodiments of a VWCS (e.g., a virtual wallet-based card transaction execution ("VW-CTE") component 500);

fig. 6 shows a user interface diagram illustrating an overview of example features of a virtual wallet application in some embodiments of a VWCS;

7A-G show user interface diagrams illustrating example features of a virtual wallet application in a shopping mode in some embodiments of the VWCS;

8A-F show user interface diagrams illustrating example features of a virtual wallet application in a payment mode in some embodiments of a VWCS;

fig. 9 shows a user interface diagram illustrating example features of a virtual wallet application in history mode in some embodiments of a VWCS;

10A-E show user interface diagrams illustrating example features of a virtual wallet application in a capture mode in some embodiments of a VWCS;

fig. 11 shows a user interface diagram illustrating example features of a virtual wallet application in a provisioning mode in some embodiments of a VWCS;

12A-B show user interface diagrams illustrating example features of a virtual wallet application in secure and privacy modes in some embodiments of a VWCS;

FIG. 13 shows a data diagram intent illustrating an example aspect of converting a user checkout request input into a checkout data display output via a user purchase checkout ("UPC") component;

FIG. 14 shows a logic flow diagram illustrating an example aspect of converting a user checkout request input into a checkout data display via a user purchase checkout ("UPC") component;

15A-B show data diagram intent illustrating example aspects of converting user virtual wallet access input to a purchase transaction receipt notification via a purchase transaction authorization ("PTA") component;

16A-B show a logic flow diagram illustrating example aspects of converting user virtual wallet access input into a purchase transaction receipt notification via a purchase transaction authorization ("PTA") component;

17A-B show data diagram intent illustrating example aspects of converting merchant transaction batch data queries into updated payment general ledger records via a purchase transaction clearing ("PTC") component;

18A-B show a logic flow diagram illustrating example aspects of converting merchant transaction batch data queries into updated payment general ledger records via a purchase transaction clearing ("PTC") component;

fig. 19 shows a block diagram illustrating example aspects of a VWCS controller.

The leading digit(s) of each reference number within the drawings indicates the figure in which the reference number is introduced and/or detailed. As such, a detailed discussion of reference numeral 101 will be found and/or introduced in FIG. 1. Reference numeral 201 is introduced in fig. 2, and so on.

Detailed Description

Virtual Wallet Card Selection (VWCS)

Virtual wallet card selection apparatus, methods, and systems (hereinafter "VWCS") convert virtual wallet card selection by a user using a mobile device via a VWCS component into a virtual wallet card-based transaction purchase notification. Fig. 1A-C show block diagrams illustrating example aspects of a purchase transaction based on virtual wallet card selection in some embodiments of a VWCS. VWCS has many features and capabilities, some of which are exemplified in fig. 1A. More details about fig. 1A may be found with respect to fig. 4A-5E. Referring to fig. 4A, in some implementations, a user (e.g., 101) may desire to purchase a product, service, offer, etc. (a "product") from a merchant. The user may communicate with a merchant server (e.g., 103) through a client such as, but not limited to: personal computers, mobile devices, televisions, point-of-sale terminals, kiosks, ATMs, and the like (e.g., 102 a). For example, the user may provide user input (e.g., purchase input 411) to the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but is not limited to: keyboard input, swiping a card, activating an RFID/NFC enabled hardware device (e.g., electronic card with multiple accounts, smartphone, tablet, etc.), mouse click, pressing a button on a joystick/game console, voice command, single/multi-touch gesture on a touch-sensitive interface, touch user interface element on a touch-sensitive display screen, etc. For example, a user may direct a browser application executing on a client device to a merchant's website, and may select a product from the website by clicking on a hyperlink presented to the user via the website. As another example, the client may obtain tracking 1 data from the user's card (e.g., credit card, debit card, prepaid card, debit card, etc.), such as the example tracking 1 data provided below:

%B123456789012345^PUBLIC/J.Q.^99011200000000000000**901******?*

(where, '123456789012345' is the card number of 'j.q.public', and has a CVV number 901. '990112' is the service code, and denotes a decimal number that changes randomly each time the card is used.)

In some implementations, the client may generate a purchase order message (e.g., 112) and provide the generated purchase order message (e.g., 113) to the merchant server. For example, a browser application executing on a client may provide a (secure) hypertext transfer protocol (http (s)) GET message on behalf of a user that includes product order details for a merchant server in the form of data formatted according to extensible markup language (XML). The following is an example HTTP (S) GET message for the merchant server that includes XML formatted purchase order message 413:

in some implementations, the merchant server may obtain the purchase order message from the client and may parse the purchase order message to extract details of the purchase order from the user. The merchant server may generate a card inquiry request (e.g., 114) to determine whether the transaction can be processed. For example, the merchant server may attempt to determine whether the user has sufficient funds to pay for the purchase in the card account to which the purchase order was provided. The merchant server may provide the generated card query request (e.g., 115) to an acquirer (acquirer) server (e.g., 104). For example, the acquirer server may be a server of an acquirer financial institution ("acquirer") that maintains the merchant account. For example, the proceeds for a transaction processed by a merchant may be deposited into an account number maintained by an acquirer. In some implementations, the card query request may include details such as, but not limited to: the cost of the user involved in the transaction, the card account details of the user, the user's bill and/or shipping information, etc. For example, the merchant server may provide an http(s) POST message including an XML formatted card query request 115 similar to the example listing provided below:

in some implementations, the acquirer server may generate a card authorization request (e.g., 116) using the acquired card inquiry request and provide the card authorization request (e.g., 117) to a payment network server (e.g., 105). For example, the acquirer server may redirect the http(s) POST message in the above example from the merchant server to the payment network server.

In some implementations, the payment network server may obtain the card authorization request from the acquirer server and may parse the card authorization request to extract details of the request, such as the user ID and purchase card details. The payment network server may attempt to determine whether the user has accessed a virtual wallet from which the user may select a card to use to complete the purchase transaction. In some implementations, the payment network server may query (e.g., 119) a payment network database (e.g., 107) for data regarding the user's virtual card selection options. In some implementations, the database may store: details of the user, an identification indicating whether the user has accessed the virtual wallet, an account number associated with the user's virtual wallet, and the like. For example, the database may be a relational database that is responsive to structured query language ("SQL") commands. The payment network server may execute a hypertext preprocessor (PHP) script including SQL commands to query the database for virtual wallet card selection options available to the user. An example PHP/SQL command that enumerates, explains the substantive aspects of the virtual wallet card selection query 119 for a database is provided below:

in response to obtaining the virtual wallet card selection query (e.g., 119), the payment network database may provide (e.g., 120) the requested virtual wallet card selection option to the payment network server. The payment network server may generate a request to select one payment option from the user's virtual wallet and provide (e.g., 122) a virtual wallet card selection request to a user device (e.g., 102 b), such as, but not limited to: personal computers, mobile devices, (interactive) televisions, personal digital assistants, tablet computers, e-book readers, game consoles, netbooks, laptops, etc. For example, the payment network server may provide an http(s) POST message including an XML formatted virtual wallet card selection request 122 similar to the example listing provided below:

the user device may display a virtual wallet card selection option (e.g., 123) to the user. For example, the user device may render a web page, electronic message, text/SMS message, buffer voicemail, ring tone, and/or play an audio message, etc., and provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a client device capable of vibrating such as a smartphone), and the like.

In some implementations, the user may provide a card selection input (e.g., 124) in response to a virtual wallet card selection option presented to the user by the user device. For example, the user may tap, swipe a touch screen of the mobile device, press a key on a keyboard, perform a single mouse click, etc. to provide for selecting a card from the user's virtual wallet to complete a purchase transaction with the card selected from the user's virtual wallet. The user device may generate a virtual wallet card selection response based on the user's card selection input and provide (e.g., 125) the virtual wallet card selection response to the payment network server. For example, the user device may provide an http(s) POST message including an XML formatted virtual wallet card selection response 125 similar to the example listing provided below:

in some implementations, the user may provide that the purchase transaction is to be processed as a split reimbursement (split holder), e.g., in the example virtual wallet card selection response 125 above, 60% of the cost is applied to one card and 40% to the other card. The user interface providing the split reimbursement option is described further below in the discussion with reference to FIGS. 8A-B.

Referring to FIG. 1B, in some implementations, a user (e.g., 101) may desire to purchase a product, service, and/or other offering ("product") in person. The user may, for example, enter (see, e.g., 102) a store, warehouse, etc. to purchase a product. The user may desire to personally purchase items for purchase that are available at the store (see, e.g., 103). In some implementations, a user may attempt to check out (see, e.g., 104) for a purchase item at a point of sale (POS) terminal (e.g., 105). For example, the user may swipe a paymentA card 106 (e.g., a credit card, debit card, prepaid card, etc., hereinafter referred to as a "universal card"). The POS terminal may provide details of the user's universal card to process the purchase transaction. For example, the POS terminal may provide purchase transaction details to a payment network 107 (e.g., a credit card company, an issuer bank, an acquirer bank, etc.) for payment processing. Based on the universal card details, the payment network may identify (e.g., 108) that a user associated with the universal card has accessed the virtual wallet card. The payment network may query the user (e.g., 109) for one of the cards selected from the user's virtual wallet, e.g., in real time. For example, the payment network may send a message (e.g., a (secure) hypertext transfer protocol (HTTP (s)) POST/GET message, an email message, a Short Message Service (SMS) message, an HTTP/real-time streaming protocol (RTSP) video stream, a text message, a Twitter) to a device of the user, e.g., 110 (e.g., a smartphone, a tablet, a netbook, a laptop, a personal digital assistant, a game console, etc.))^TMTwitter (tweet),Message/wall post) wall licensing), etc.) requests that the user select a payment option from the user's virtual wallet. Based on the message, the user interface presented by the user device may populate the user card selection options (see 110). In some examples, the most appropriate card may be selected by the user using the user device even if the universal card is not a credit card. Alternatively, the payment network server may select a preset card to process the purchase transaction with the preset card.

In some implementations, when retrieving the message, the device may provide an interface to the user to make a selection of a card from the user's virtual wallet to utilize to complete the purchase transaction. For example, the user's device may execute an application module ("app") through which the user's device may communicate with the payment network. The user device may display a virtual wallet card selection option obtained from the payment network via the application for the user. In some implementations, by performing a single action (e.g., tapping, swiping a touch screen of the mobile device, pressing a key on a keyboard, performing a single mouse click, etc.), the application may provide the user with an option to purchase the item 103 on the spot.

In some implementations, the application may provide various alternative choices to the user. For example, the application may provide the user with alternative merchants from which the user may obtain products and/or similar products, alternative products that are comparable to the purchased products, price information for competition between merchants, discounts, coupons, and/or other offers to the user, and so forth. In some implementations, the application may indicate that if the user purchases a product at another merchant, the user may earn reward points (rewarded points). In some implementations, the application may indicate that if the user purchases a product at another merchant, then the purchase transaction may need to be paid using fewer reward points, as the other merchant may have a better relationship with the reward point provider. In some implementations, the application may indicate that the user may obtain more reward points if a particular (or alternative) card is used to pay for the purchase transaction. In some implementations, the application may indicate that if the user purchases a card at an alternative merchant and/or uses an alternative card, the user may obtain a greater amount of cash back. In various implementations, the offers to the user, including and similar to those described herein, may originate from various entities and/or components, including but not limited to: merchants, payment networks, card issuers, acquirers, etc.

Referring to fig. lC, in some implementations, a user can purchase (e.g., 111) products from a current merchant and/or other merchants on-site by performing a single action on the user device (e.g., a tap of the user device's touch screen). In this implementation, the "card" (e.g., checking account, savings account, Paypal) selected from the user's virtual wallet (see, e.g., 112 a-b) is used^TMAccount, Google Checkout^TMAn account, credit card, debit card, prepaid card, etc.), the VWCS server may initiate a card-based purchase transaction. In some implementations, the VWCS can arbitrate due to considerations of transaction costsSanctioned (authorization) how a credit card payment network, in which entities such as merchants, card issuers, acquirers, payment networks and/or VWCS components are switchable (switch), handles payment for users.

In some implementations, a payment network (e.g., 113) may initiate a card-based purchase transaction (e.g., 114) and may generate a purchase confirmation receipt for the user. The VWCS server may provide a purchase confirmation receipt to the client device (e.g., 116 a-b). In some implementations, the user may desire to exit the store through the application after purchasing the item. In this implementation, the user may need to provide proof of purchase of the product at a store exit (e.g., 115). The user may provide evidence of product purchase (e.g., 116 a) with a purchase confirmation receipt obtained from the VWCS through an application on the client device. For example, the receipt may include a purchase identifier (e.g., 116 c). For example, the purchase identifier may include a barcode, a QR code, an image of a receipt, a video of the purchase action, and the like. Such a purchase confirmation may be utilized by the user as evidence of leaving the store. Thus, in some implementations, the user may gain better security in the transaction because the purchase may only be completed if the individual has both the user's universal card and access to the user's device and access to the application on the user's device. Furthermore, even at an out-of-date POS terminal, the user may still gain access to the user's virtual wallet through the user's device, thereby improving the user's efficiency and convenience in the user's shopping experience.

Fig. 2 shows an application user interface diagram illustrating example features for selecting a mobile application from a virtual wallet card selected from a plurality of payment options in some embodiments of the VWCS. In some implementations, an application executing on a user's device may include an application interface that provides a plurality of features to the user. In some implementations, the application can include an indication (e.g., 201) of the user's location (e.g., the name of the merchant store, geographic location, information about aisles within the merchant store, etc.). The application may provide an indication of a payment amount due for the purchase of the product (e.g., 202). In some implementations, the application may be a userThe user provides a number of options to pay the amount to purchase the product. For example, the application may utilize GPS coordinates to determine that a store is present within range of the user and direct the user to the merchant's website. In some implementations, the VWCS may provide APIs directly to participating merchants to facilitate transaction processing. In some implementations, a merchant-brand VWCS application may be developed with VWCH functionality, which may directly connect the user to the merchant's transaction processing system. For example, the user may select (e.g., 203) from a number of cards (e.g., credit cards, debit cards, pre-paid cards, etc.) from a plurality of card providers. In some implementations, the application may provide the user with an option to pay for the purchase (e.g., 204) by using funds included in the user's bank account (e.g., check, savings, money market, cash account, etc.). In some implementations, the user may have default options for the setting of the card, bank account, for purchase transactions through the app. In some implementations, the setting of such default options may allow a user to initiate a shopping transaction (e.g., 205) via a single click, tap, swipe, and/or other remedial (remedial) user input action. In some implementations, when the user utilizes such an option, the application can initiate a shopping transaction using the user's default settings. In some implementations, the application may allow the user to utilize other accounts (e.g., Google)^TMCheckout, Paypal^TMAn account, etc.) to pay for the purchase transaction (e.g., 206). In some implementations, the application may allow the user to pay for the purchase transaction (e.g., 207-. In some implementations, the application may provide an option to provide explicit authorization (e.g., 209) prior to initiating the purchase transaction. In some implementations, the application may provide a progress indicator to provide an indication (e.g., 210) about the progress of the transaction after the user has selected an option to initiate a shopping transaction. In some implementations, the application may provide historical information (e.g., 211) to the user via the application regarding the user's previous purchases. In some implementations, the application mayThe user is provided with an option to share information about the purchase with other users (e.g., via email, SMS, etc.),Wall poster, Twitter^TMPush up, etc.) (e.g., 212). In some implementations, the application may provide an option to the user to display product identification information captured by the client device (e.g., to display product information to a customer service representative at an exit of the store) (e.g., 214). In some implementations, the user, application, device, or VWCS may encounter errors in the processing. In such a scenario, the user may be able to talk to a customer service representative (e.g., chat verification (VerifyChat) 213) to address difficulties in the purchase transaction process.

In some implementations, the user may choose to use a one-time anonymous credit card number to conduct a transaction (see, e.g., 205 b). For example, VWCS may utilize pre-specified anonymous card group details (see, e.g., AnonCard1, AnonCard 2). As another example, the VWCS may generate an anonymous card set detail once, e.g., in real-time, to securely complete the purchase transaction (e.g., Anon It 1X). In such implementations, the application may automatically set user profile (profile) settings so that any personally identifying information for the user will not be provided to the merchant and/or other entity. In some implementations, the user may be required to enter a username and password to enable the anonymization feature.

Fig. 3A-C show application user interface diagrams illustrating example features of a virtual wallet card selection mobile application for obtaining user data and preventing fraud in some embodiments of a VWCS. In some implementations, an application executing on the user's device may provide a chat verification feature to prevent fraud (e.g., by activating UI element 213 in fig. 2). For example, the VWCS may detect anomalous and/or suspicious transactions. The VWCS may communicate with the user using a chat verification feature and verify the authenticity of the originator of the purchase transaction. In various implementations, the VWCS may send an email message, a text (SMS) message, a,Message, Twitter^TMTwitter, text chat, voice chat, video chat (e.g., Apple FaceTime), and the like. For example, the VWCS may initiate a video challenge (challenge) to the user (e.g., 301). For example, a user needs to show himself/herself via video chat (e.g., 302). In some implementations, a customer service representative (e.g., agent 304 b) may manually determine the authenticity of a user using the user's video. In some implementations, the VWCS may determine the identity of the user (e.g., 304 a) using facial, biometric (biometric), or the like recognition (e.g., using pattern classification techniques). In some implementations, the application may provide a reference marker (e.g., crosshair, target box, etc.) (e.g., 303) so that the user may video to facilitate user automatic identification of the VWCS. In some implementations, the user may not initiate a transaction, for example, the transaction is fraudulent. In such an implementation, the user may cancel the challenge (e.g., 305). The VWCS may then cancel the transaction, and/or initiate a fraud investigation process on behalf of the user.

In some implementations, the VWCS may utilize a text challenge process to verify the authenticity of the user (e.g., 306). For example, the VWCS may be implemented via text chat, SMS messages, email, web browser, or web browser,Message, Twitter^TMTwitter, etc. communicates with the user. The VWCS may present a challenge question (e.g., 308) to the user. The application may provide a user input interface element (e.g., virtual keyboard 309) to answer the challenge question posed by the VWCS. In some implementations, the challenge question may be automatically randomly selected by the VWCS; in some implementations, the customer service representative may manually communicate with the user. In some implementations, the user may not initiate a transaction, for example, the transaction is fraudulent. In such an implementation, the user may cancel the text challenge (e.g., 307, 310). The VWCS may then cancel the transaction, and/or initiate fraud surveys on behalf of the userAnd (6) carrying out the process.

In some implementations, the application may be configured to identify a product identifier (e.g., a barcode, a QR code, etc.). For example, to prevent fraud, the application may require the user to take a snapshot of the item being purchased with the user's device, thereby ensuring that the person swiping the card also owns the user's device and purchases the item. In some implementations, a user may be required to log into an application to enable its features. Once enabled, the camera may provide an in-person one tap purchasing feature for the user. For example, the client device may have a camera via which the application may obtain images, video data, streaming real-time video, and so forth (e.g., 313). The application may be configured to analyze the input data, and search (e.g., 311) for a product identifier (e.g., 314). In some implementations, the application may overlay cross hairs, target boxes, etc. alignment reference marks (e.g., 315), such that a user may align the product identifier by using the reference marks to facilitate product identifier identification and interpretation. In some implementations, the application may include interface elements to allow the user to toggle between the product recognition mode and the product presentation interface display screen (see, e.g., 316), so that the user can accurately study the deals available to the user before capturing the product identifier. In some implementations, the application may provide the user with the ability to view previous product identifier captures (see, e.g., 317), so that the user may be able to better decide which product identifier the user desires to capture. In some implementations, the user may desire to cancel a product purchase; the application may provide a user interface element (e.g., 318) to the user to cancel the product identifier identification process and return to the interface screen utilized by the previous user. In some implementations, the user may be provided information about products, user settings, merchants, offers, etc. in the form of a list (see, e.g., 319), so that the user may better understand the user's purchase options. Various other features may be provided in the application (see, e.g., 320).

In some implementations, the user may be able to view and/or modify the user profile and/or the user's settings, for example, by activating user interface element 309 (see fig. 3A). For example, the user may be able to view/modify a username (e.g., 321 a-b), an account number (e.g., 322 a-b), a user security access code (e.g., 323 a-b), a user PIN (e.g., 324 a-b), a user address (e.g., 325 a-b), a social security number associated with the user (e.g., 326 a-b), a current device GPS location (e.g., 327 a-b), a user account of a merchant of a store in which the user is currently located (e.g., 328 a-b), a reward account of the user (e.g., 329 a-b), and so forth. In some implementations, the user may be able to select which of the data fields and their associated values should be sent to facilitate the purchase transaction, thereby providing enhanced data security for the user. For example, in the example illustration in FIG. 3C, the user has selected name 312a, account number 322a, security code 323a, merchant account ID328a, and reward account ID329a as fields (to be sent as part of the notification) to process the purchase transaction. In some implementations, the user can switch (toggle) fields and/or data values that are sent as part of the notification to process the purchase transaction. In some implementations, the application may provide multiple screens of stored data fields and/or associated values for user selection as part of the purchase order transmission. In some implementations, the application may provide the VWCS with the user's GPS location. Based on the user's GPS location, the VWCS may determine the user's environment (e.g., whether the user is in a store, a doctor's office, a hospital, a postal service office, etc.). Based on the circumstances, the user application may present the appropriate fields to the user from which the user may select fields and/or field values to send as part of the purchase order transmission.

For example, the user may go to a doctor's office and desire to pay a copay (copay) for the doctor's appointment. In addition to basic transaction information such as account number and name, the application may provide the user with the ability to select to transfer medical records, health information, which may be provided to medical providers, insurance companies, and transaction processors to coordinate payment among multiple parties. In some implementations, records may be sent and encrypted in a data format compatible with the health insurance Act and accountability Act (HIPAA), and only recipients authorized to view such records may have the appropriate decryption keys to decrypt and view private user information.

Various additional advantageous example features of such an application are further described in the discussion below with reference to fig. 6-18B.

Fig. 4A-C show data flow diagrams illustrating an example process of performing a card-based transaction using virtual wallet card selection in some embodiments of the VWCS. Referring to fig. 4A, in some implementations, a user (e.g., 401) may desire to purchase a product, service, offer, etc. (a "product") from a merchant. The user may communicate with a merchant server (e.g., 403) through clients such as, but not limited to: personal computers, mobile devices, televisions, point-of-sale terminals, kiosks, ATMs, and the like (e.g., 402 a). For example, the user may provide user input (e.g., purchase input 411) to the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but is not limited to: keyboard input, swiping a card, activating an RFID/NFC enabled hardware device (e.g., electronic card with multiple accounts, smart phone, tablet, etc.), mouse click, pressing a button on a joystick/game console, voice command, single/multi touch gesture on a touch sensitive interface, touch user interface element on a touch sensitive display screen, etc. For example, a user may direct a browser application executing on a client device to a merchant's website, and may select a product from the website by tapping a hyperlink exposed to the user via the website. As another example, the client may obtain tracking 1 data from the user's card (e.g., credit card, debit card, prepaid card, debit card, etc.), such as the example tracking 1 data provided below:

%B123456789012345^PUBLIC/J.Q.^99011200000000000000**901******?*

(where, '123456789012345' is the card number of 'j.q.public', and has a CVV number 901. '990112' is service code, and denotes a decimal number that changes randomly each time the card is used.)

In some implementations, the client can generate a purchase order message (e.g., 412) and provide the generated purchase order message (e.g., 413) to the merchant server. For example, a browser application executing on a client may provide a (secure) hypertext transfer protocol (http (s)) GET message on behalf of a user that includes product order details for a merchant server in the form of data formatted according to extensible markup language (XML). The following is an example HTTP (S) GET message for the merchant server that includes XML formatted purchase order message 413:

in some implementations, the merchant server may obtain the purchase order message from the client and may parse the purchase order message to extract details of the purchase order from the user. The merchant server may generate a card inquiry request (e.g., 414) to determine whether the transaction can be processed. For example, the merchant server may attempt to determine whether the user has sufficient funds to pay for the purchase in the card account to which the purchase order was provided. The merchant server may provide the generated card inquiry request (e.g., 415) to an acquirer server (e.g., 404). For example, the acquirer server may be a server of an acquirer financial institution ("acquirer") that maintains the merchant account. For example, the proceeds for a transaction processed by a merchant may be deposited into an account maintained by an acquirer. In some implementations, the card query request may include details such as, but not limited to: the cost of the user involved in the transaction, the card account details of the user, the user's bill and/or shipping information, etc. For example, the merchant server may provide an http(s) POST message including an XML formatted card query request 415 similar to the example listing provided below:

in some implementations, the acquirer server may generate a card authorization request (e.g., 416) using the acquired card inquiry request and provide the card authorization request (e.g., 417) to a payment network server (e.g., 405). For example, the acquirer server may redirect the http(s) POST message in the above example from the merchant server to the payment network server.

In some implementations, the payment network server may obtain the card authorization request from the acquirer server and may parse the card authorization request to extract details of the request, such as the user ID and purchase card details. The payment network server may attempt to determine whether the user has accessed a virtual wallet from which the user may select a card to use to complete the purchase transaction. In some implementations, the payment network server may query (e.g., 419) a payment network database (e.g., 407) to obtain data regarding the user's virtual card selection options. In some implementations, the database can store details of the user, an identification indicating whether the user has accessed the virtual wallet, an account number associated with the user's virtual wallet, and the like. For example, the database may be a relational database that is responsive to structured query language ("SQL") commands. The payment network server may execute a hypertext preprocessor (PHP) script including SQL commands to query the database for virtual wallet card selection options available to the user. An example PHP/SQL command that enumerates, explains the substantive aspects of the virtual wallet card selection query 419 for the database is provided below:

in response to obtaining the virtual wallet card selection query (e.g., 419), the payment network database may provide (e.g., 420) the requested virtual wallet card selection option to the payment network server. The payment network server may generate a request to select a payment option from the user's virtual wallet and provide (e.g., 422) a virtual wallet card selection request to a user device (e.g., 402 b), such as, but not limited to: personal computers, mobile devices, (interactive) televisions, personal digital assistants, tablet computers, e-book readers, game consoles, netbooks, laptops, etc. For example, the payment network server may provide an http(s) POST message including an XML formatted virtual wallet card selection request 422 similar to the example listing provided below:

the user device may display a virtual wallet card selection option (e.g., 423) to the user. For example, the user device may render a web page, electronic message, text/SMS message, buffer voicemail, ring tone, and/or play an audio message, etc., and provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a client device capable of vibrating such as a smartphone), and the like.

In some implementations, the user may provide a card selection input (e.g., 424) in response to a virtual wallet card selection option presented to the user by the user device. For example, the user may tap, swipe a touch screen of the mobile device, press a key on a keyboard, perform a single mouse click, etc. to provide for selecting a card from the user's virtual wallet to complete a purchase transaction with the card selected from the user's virtual wallet. The user device may generate a virtual wallet card selection response based on the user's card selection input and provide (e.g., 425) the virtual wallet card selection response to the payment network server. For example, the user device may provide an http(s) POST message including an XML formatted virtual wallet card selection response 425 similar to the example listing provided below:

in some implementations, the user may provide that the purchase transaction is to be processed as a separate reimbursement, e.g., in the example virtual wallet card selection response 425 above, 60% of the cost is applied to one card and 40% to the other card. The user interface providing the split reimbursement option is described further below in the discussion with reference to FIGS. 8A-B.

Referring to fig. 4B, in some implementations, the payment network server may obtain a virtual wallet card selection response from the user device and parse the virtual wallet card selection response to extract details of the virtual wallet card selection (427). Using the extracted field and field values, the payment network server may generate a query (e.g., 428) to an issuer server corresponding to a user card account selected from the user virtual wallet. For example, the user's card account may be linked to an issuer financial institution ("issuer"), such as a banking institution that issued the card account for the user. An issuer server (e.g., 406) of the issuer may maintain details of the user's card account. In some implementations, a database (e.g., payment network database 407) can store details of the issuer server and the card account number associated with the issuer server. For example, the database may be a relational database that is responsive to structured query language ("SQL") commands. The payment network server may execute a hypertext preprocessor (PHP) script including SQL commands to query the database for details of the issuer server. The following provides example PHP/SQL commands that enumerate and explain the substantive aspects of querying a database:

in response to obtaining the issuer server query (e.g., 428), the payment network database may provide (e.g., 429) the requested issuer server data to the payment network server. In some implementations, the payment network server may generate a card authorization request (e.g., 430) using the issuer server data to redirect the card authorization request from the acquirer server to the issuer server through the user's virtual wallet card selection. The payment network server may provide a card authorization request (e.g., 431) to the issuer server. In some implementations, the issuer server (e.g., 406) may parse the card authorization request and may query a database (e.g., user profile database 408), e.g., 432-. For example, the issuer server may issue PHP/SQL commands similar to the examples provided below:

in some implementations, when obtaining user data (e.g., 434), the issuer server may determine whether the user may pay for the transaction (e.g., 435) by using funds available in the account. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, has sufficient credit associated with the account, and so on. If the issuer server determines that the user may pay for the transaction by using funds available in the account, the server may provide an authorization message (e.g., 436) to the payment network server. For example, the server may provide an http(s) POST message similar to the example above. If the issuer server determines that the user cannot pay for the transaction by using funds available in the account, the payment network server may provide another virtual wallet card selection request to the user device unless the prior number of such requests provided exceeds a threshold, in which case the payment network server may indicate to the merchant server 403 that the transaction is not authorized.

In some implementations, the payment network server may obtain the authorization message and parse the message to extract the authorization details. Upon determining that the user has sufficient funds for the transaction, the payment network server generates a transaction data record from the card authorization request it receives and stores in a transaction database the authorization and transaction details associated with the transaction. For example, the payment network server may issue PHP/SQL commands similar to the following example listing to store transaction data in a database:

in some implementations, the payment network server may forward the authorization message to the acquirer server (e.g., 437), which in turn forwards the authorization message to the merchant server (e.g., 438). The merchant may obtain the authorization message and determine from it that the user has sufficient funds in the card account to conduct the transaction. The merchant server may add a transaction record for the user to a batch of transaction data related to the authorized transaction. For example, the merchant may add (append) XML data related to user transactions to an XML data file (e.g., 439) that includes XML data for transactions authorized by the respective user and store the XML data file (e.g., 440) in a database (e.g., merchant database 409). For example, a bulk XML data file may be structured similar to the example XML data structure template provided below:

in some implementations, the server can also generate a purchase receipt (e.g., 439) and provide the purchase receipt (e.g., 441) to the client. The client may present and display a purchase receipt (e.g., 442) to the user. For example, the client may render a web page, electronic message, text/SMS message, buffer voicemail, ring tone, and/or play an audio message, etc., and provide outputs including, but not limited to: sound, music, audio, video, graphics, haptic feedback, vibration alerts (e.g., on a client device capable of vibrating, such as a smartphone), and the like.

Referring to FIG. 4C, in some implementations, the merchant server may initiate a clearing (clearness) of a batch of authorized transactions. For example, the merchant server may generate a bulk data request (e.g., 443) and provide the request (e.g., 444) to a database (e.g., merchant database 409). For example, a merchant may query a relational database using PHP/SQL commands similar to the example provided above. In response to the batch data request, the database may provide the requested batch data (e.g., 445). Using the batch data obtained from the database, the server may generate a batch clearing request (e.g., 446) and provide the batch clearing request (e.g., 447) to the acquirer server (e.g., 404). For example, the merchant server provides an HTTP (S) POST message to the acquirer server that contains XML formatted bulk data in the message body. Using the obtained bulk clearing request, the acquirer server may generate a bulk payment request (e.g., 448) and provide the bulk payment request (e.g., 449) to the network payment server. The payment network server may parse the bulk payment request and extract transaction data (e.g., 450) for each transaction stored in the bulk payment request. The payment network server may store transaction data (e.g., 451) in a database (e.g., transaction database 410) for each transaction. For each extracted transaction, the payment network server may query a database (e.g., payment network database 407) for the address of the issuer server, e.g., 452-. For example, the payment network server may utilize PHP/SQL commands similar to the examples provided above. For each transaction for which it has extracted transaction data, the payment network server may generate a single payment request (e.g., 454) and provide the single payment request (e.g., 455) to the issuer server (e.g., 406). For example, the payment network server may provide an http(s) POST request similar to the example provided below:

in some implementations, the issuer server may generate payment instructions (e.g., 456). For example, the issuer server may issue a command to subtract funds from the user's account (or add a fee to the user's credit card account). The issuer server may issue payment instructions (e.g., 457) to a database (e.g., user profile database 408) that stores account information for the user. The issuer server may provide the funds-transfer message (e.g., 458) to the payment network server, which may forward the funds-transfer message to the acquirer server (e.g., 459). Example http(s) POST funds transfer messages are provided below:

in some implementations, the acquirer server may parse the funds-transfer message and associate the transaction with the merchant (e.g., using the request _ ID field in the above example). The acquirer server may then transfer the funds specified in the funds-transfer message to the merchant's account (e.g., 460).

Fig. 5A-E show a logic flow diagram illustrating example aspects of using a virtual wallet card to select to execute a card-based transaction (e.g., a virtual wallet-based card transaction execution ("VW-CTE") component 500) in some embodiments of a VWCS. In some implementations, the user may provide a user input (e.g., 501) to the client indicating the user's desire to purchase a product from the merchant. The client may generate a purchase order message (e.g., 502) and provide the generated purchase order message to the merchant server. In some implementations, the merchant server may obtain a purchase order message (e.g., 503) from the client and may parse the purchase order message to extract details of the purchase order from the user. An example parser that may be utilized by a merchant client is discussed further below with reference to FIG. 6. The merchant server may generate a card inquiry request (e.g., 504) to determine whether the transaction can be processed. For example, the merchant server may process the transaction only if the user has sufficient funds in the card account to which the purchase order was provided to pay for the purchase. The merchant server may provide the generated card inquiry request to the acquirer server. The acquirer server may parse the card query request (e.g., 505). The acquirer server may generate a card authorization request (e.g., 506) using the acquired card inquiry request and provide the card authorization request to the payment network server.

In some implementations, the payment network server may obtain the card authorization request from the acquirer server and may parse the card authorization request to extract details of the request (e.g., 507). For example, the payment network server may obtain the user's ID, the account number of the card that the user swiped at the client, and so on. The payment network server may attempt to determine whether the user has accessed a virtual wallet from which the user may select a card to use to complete the purchase transaction. In some implementations, the payment network server may generate a query (e.g., 508) to a payment network database to obtain virtual card selection options available to the user, as discussed in the description above with reference to fig. 4A. In response to the virtual wallet card selection query (e.g., 508), the payment network database may provide the requested virtual wallet card option (e.g., 509) to the payment network server. The payment network server may generate a request (e.g., 510) for selecting one of the payment option options from the user's virtual wallet and provide the virtual wallet card selection request to the user device. For example, the query results may return a list of several user e-wallet accounts (e.g., credit cards, debit cards, prepaid cards, etc. from a large number of issuers and merchants); the list of query results may be wrapped (wrap) into a dynamic user interface object (e.g., a wrapper such as HTML, XML, CSS, etc.; see FIG. 4A, 422) that can be rendered by the user device. In some implementations, the user device may present virtual wallet card selection options (e.g., 511) provided by the payment network database and display the virtual wallet card selection options (e.g., 512) to the user. For example, the selection object may be presented in a display portion on the screen, for example, in a network presentation object view.

In some implementations, the user may provide a card selection input (e.g., 513) in response to a virtual wallet card selection option presented to the user by the user device. The user device may generate a virtual wallet card selection response (e.g., 514) based on the user's card selection input and provide the virtual wallet card selection response to the payment network server. In some implementations, the payment network server may wait at least a predetermined amount of time for a response from the user to the virtual wallet card selection request. If the wait time exceeds a predetermined amount of time, the payment network server may determine that the user's time has been exhausted, resulting in a timeout. This may provide a secure element for the user's virtual wallet. If the user has timed out (e.g., 515, yes option), the server may determine whether the user timed out more than a pre-specified number of times in the current transaction. If the user does not respond (or if the user's selections have all resulted in a successful authorization failure) more than a pre-specified threshold number of times (e.g., 516, option yes), then the payment network server may determine that the transaction must be cancelled and generate a message to the merchant server that authorization has failed (e.g., 517). In some implementations, the payment network server determines that the user has timed out (and/or that the number of times timed out for the current transaction has exceeded a predetermined threshold), the server may utilize a default virtual wallet card selection previously set by the user, and continue transaction processing by using the default selection. In some implementations, the payment network server may always use the user's default virtual wallet card selection and may not attempt to contact the user through the user device to obtain the user selection. It should be understood that different permutations and/or combinations of the features presented herein may be used to balance the security benefits of contacting a user for authorization and customizing a selection card from a virtual wallet for exploitation against reducing the number of times the user is contacted to effect the sought after transaction.

In some implementations, if the payment network server successfully captures a user selection of a valid card account from the virtual wallet card selection option, the payment network server may obtain a virtual wallet card selection response from the user device and may parse the virtual wallet card selection response to extract details of the virtual wallet card selection. Using the extracted fields and field values, the payment network server may generate a query (e.g., 518) to an issuer server corresponding to the user's card account. In response to obtaining the issuer server query, the payment network database may provide (e.g., 519) the requested issuer server data to the payment network server. In some implementations, the payment network server may utilize the issuer server data to generate a forwarded card authorization request (e.g., 520) to redirect the card authorization request from the acquirer server to the issuer server. The payment network server may provide the card authorization request to the issuer server. In some implementations, the issuer server may parse the card authorization request (e.g., 521) and may query a database (e.g., 522) for the user's card account according to the request details. In response, the database may provide the requested user data (e.g., 523). When obtaining user data, the issuer server may determine whether the user may pay for the transaction by using funds available in the account (e.g., 524). For example, by comparing data from the database to the transaction cost obtained from the card authorization request, the issuer server may determine whether the user has a sufficient balance remaining in the account, has sufficient credit associated with the account, and so on. If the issuer server determines that the user may pay for the transaction by using funds available in the account, the server may provide an authorization message to the payment network server (e.g., 525).

In some implementations, the payment network server may retrieve the authorization message and parse the message to extract authorization details (e.g., 526). When it is determined that the user has sufficient funds for the transaction (e.g., 527, yes option), the payment network server may extract the transaction card (e.g., 528) from the authorization message and/or card authorization request and generate a transaction data record (e.g., 529) using the card transaction details. The payment network server may provide the transaction data to a database for storage (e.g., 530). In some implementations, the payment network server may forward the authorization message (e.g., 531) to the acquirer server, which may in turn forward the authorization message (e.g., 532) to the merchant server. The merchant may retrieve the authorization message and parse the authorization message to extract its content (e.g., 533). The merchant server may determine whether the user has sufficient funds in the card account to conduct the transaction. If the merchant server determines that the user has sufficient funds (e.g., 534, yes option), the merchant server may add a record for the user's transaction to a set of transaction data related to the authorized transaction (e.g., 535 and 536). The merchant server may also generate a purchase receipt (e.g., 537) for the user. If the merchant server determines that the user does not have sufficient funds (e.g., 534, option no), the merchant server may generate an authorization failure message (e.g., 538). The merchant server may provide a purchase receipt or an authorization failure message to the client. The client can present and display (e.g., 538) a purchase receipt to the user.

In some implementations, the merchant server may initiate clearing of a batch of authorized transactions by generating a batch data request (e.g., 540) and providing the request to the database. In response to the batch data request, the database may provide the requested batch data (e.g., 541) to the merchant server. Using the batch data obtained from the database, the server may generate a batch clearing request (e.g., 542) and provide the batch clearing request to the acquirer server. Using the obtained bulk clearing request, the acquirer server may generate a bulk payment request (e.g., 544) and provide the bulk payment request to the payment network server. The payment network server may parse the batch payment request (e.g., 545), select a transaction stored in the batch data (e.g., 546), and extract transaction data for the transaction stored in the batch payment request (e.g., 547). The payment network server may generate a transaction data record (e.g., 548) and store the transaction data (e.g., 549) in a database. For the extracted transaction, the payment network server may generate an issuer server query for the address of the issuer server maintaining the account of the user requesting the transaction, (e.g., 550). The payment network server may provide the query to the database. In response, the database will provide the issuer server data requested by the payment network server (e.g., 551). The payment network server may generate a single payment request (e.g., 552) for the transaction for which it has extracted the transaction data and provide the single payment request to the issuer server using the issuer server data from the database.

In some implementations, the issuer server may obtain a single payment request and parse (e.g., 553) the single payment request to extract details of the request. Based on the extracted data, the issuer server may generate a payment command (e.g., 554). For example, the issuer server may issue a command to subtract funds from the user's account (or add a fee to the user's credit card account). The issuer server may issue payment instructions (e.g., 555) to a database that stores account information for the user. In response, the database may update the data record corresponding to the user account to reflect the debiting/charging (charge) of the user's account. After the payment order has been executed by the database, the issuer server may provide a funds transfer message (e.g., 556) to the payment network server.

In some implementations, the payment network server may check whether there are additional transactions in the batch that require clearing and reimbursement. If there are additional transactions (e.g., 557, option yes), the payment network server may process each transaction according to the steps described above. The payment network server may generate (e.g., 558) an aggregate (aggregate) funds transfer message reflecting the transfer of all transactions in the batch and provide (e.g., 559) the funds transfer message to the acquirer server. In response, the acquirer server transfers funds specified in the funds-transfer message to the merchant's account (e.g., 560).

Fig. 6 shows a user interface diagram illustrating an overview of example features of a virtual wallet application in some embodiments of the VWCS. Fig. 6 shows a diagram of various example features of a virtual wallet mobile application 600. Some of the displayed features include: wallet 601, social integration via Twitter, Facebook, etc., provisioning and loyalty 603, capturing mobile purchases 604, alerts 605, and security, setup and analysis 696. These features will be discussed further below.

Fig. 7A-G show user interface diagrams illustrating example features of a virtual wallet application in a shopping mode in some embodiments of the VWCS. Referring to fig. 7A, some embodiments of the virtual wallet mobile application facilitate and greatly enhance the consumer's shopping experience. Various shopping modes, as shown in FIG. 7A, may be available for consumer browsing. In one implementation, for example, the user may begin the shopping mode by selecting the store icon 710 at the bottom of the user interface. The user may enter an item in the search field 712 to search for and/or add an item 711 to the shopping cart. The user may also use voice activated shopping mode by speaking into the microphone 713 a name or description of an item to be searched for and/or added to the shopping cart. In further implementations, the user may also select other shopping options 714 such as current item 715, bill 716, address book 717, merchant 718, and local proximity 719.

In one embodiment, for example, the user may select the option current item 715 as shown in the leftmost user interface of FIG. 7A. When the current item 715 option is selected, an intermediate user interface may be displayed. As shown, the intermediary user interface may provide a current list of items 715a-h in the user's shopping cart 711. The user may select an item (e.g., item 715 a) to view product descriptions 715j of the selected item and/or other items from the same merchant. Along with the QR code 715k, which captures the information needed to enable the capture of the mobile purchase transaction, price and total payment information is also displayed.

Referring to FIG. 7B, in another embodiment, the user may select billing option 716. When billing option 716 is selected, the user interface may display lists 716a-h of bills and/or receipts from one or more merchants. Near each of the bills, additional information such as the date of visit, whether items from multiple stores are present, the last bill payment date, automatic payment, the number of items, etc. may be displayed. In one example, a wallet bill for shopping with a date of 2011, 1 month, 20 days is selected. The wallet shopping bill selection may display a user interface that provides a variety of information about the selected bill. For example, the user interface may display a list of purchased items 716k, QR code encoded data 716i for those items, a total number of items, and corresponding values 716 j. For example, there are 7 items worth $102.54 in the wallet bill of purchase selected. The user may now select any of the items and purchase again to add the purchased items. The user may also refresh offer 716j to clear the last invalid offer and/or search for a new offer applicable for the current purchase. As shown in fig. 7B, the user may select two items to repeat the purchase. When incremented, a message 716 can be displayed to confirm the addition of the two items, which causes the total number of items in the shopping cart to become 14.

Referring to FIG. 7C, in yet another embodiment, the user may select the address book option 717 to view the address book 717a, which includes a list 717b of contacts, and to make a cash transfer or payment. In one embodiment, the address book may identify each contact using each person's name and available and/or preferred payment methods. For example, contact Amanda G may pay via social payment (e.g., via Facebook) as indicated by icon 717 c. In another example, cash may be transferred to Brian S via a QR code as indicated by QR code icon 717 d. In yet another example, Charles B may accept payment via near field communication 717e, bluetooth 717f, and email 717 g. Payment may also be made via USB717h (e.g., by physically connecting two mobile devices) and social channels such as Twitter.

In one implementation, the user may select Joe P to make the payment. Joe P, as shown in the user interface, has an email icon 717g near his name indicating that Joe P accepts payments via email. When his name is selected, the user interface may display his contact information, such as email, phone, etc., and if the user wishes to pay JoeP by means other than email, the user may add another transfer mode 717j to his contact information and make a payment transfer. Referring to FIG. 7D, the user may be provided with a screen 717k in which the user may enter the number sent to Joe, as well as add other text content to provide Joe with a background 717l for payment transactions. The user may select a mode (e.g., SMS, email, social network) via user interface element 717m via which Joe may be contacted. As the user types, the entered text may be reviewed within GUI element 717 n. When the user has finished entering the necessary information, the user may press send button 717o to send Joe social information. Joe may be able to locate a virtual wallet application if Joe also has that applicationWithin an application or directly in a social network (e.g., for Twitter)^TM、Etc.) to the user, on the website of the user, the social payment information 717 p. Messages can be aggregated from various social networks and other sources (e.g., SMS, mail). A method of redemption (redeplication) appropriate for each message mode may be indicated along with the social payment information. In the diagram of FIG. 7D, SMS717q Joe received by Joe indicates that Joe can redeem the $5 retrieved by replying to the SMS and entering a Hash tag value # 1234. In the same diagram, Joe also goes throughMessage 717r is received, which includes a URL link that Joe may activate to initiate a redemption for $25 payment.

Referring to FIG. 7E, in some other embodiments, the user may select a merchant 718 from the list of options to select a list of merchants 718a-E in the shopping mode. In one implementation, the merchants in the list may be attached to, or have an affinity with, a wallet. In another implementation, the merchants may include a list of merchants that meet user-defined or other criteria. For example, the list may be merchants created by the user, who shop most frequently, or spend an extra total of x or three consecutive months shopping, etc. In one implementation, the user may further select one of the merchants, such as Amazon718 a. The user may then navigate through the list of merchants to find items of interest, such as 718 f-j. The user may make a selection of item 718j from Amazon718 a's catalog directly through the wallet without accessing the merchant site from a separate page. As shown in the rightmost user interface of FIG. 7D, selected items may be added to the shopping cart. Message 718k indicates that the selected item has been added to the shopping cart and that the number of items in the shopping cart that are now updated is 13.

Referring to FIG. 7F, in one embodiment, there may be a local proximity option 719 that may be selected by the user to view a listing of merchants that are very close in geographic proximity to the user. For example, the listings of merchants 719a-e may be merchants located near the user. In one implementation, the mobile application may be further identified based on the location of the user while the user is in the store. For example, when the user is in close proximity to a store, the location icon 719d may be displayed close to the store (e.g., Walgreens). In one implementation, in the event that the user moves away from the store (e.g., Walgreens), the mobile application may periodically refresh its location. In a further implementation, the user may navigate the offering of the selected Walgreens store through the mobile application. For example, a user may navigate through the items 5719f-j available on the Walgreens aisle 5 by using a mobile application. In one implementation, the user may select corn 719i from his or her mobile application to add to shopping cart 719 k.

Referring to FIG. 7G, in another embodiment, the local proximity option 719 may include a store map and other real-time map features in between. For example, when selecting the Walgreens store, the user may start an aisle map 719l that displays an organization showing the store and the user's location (indicated by the yellow circle). In one implementation, a user may easily configure a map to add one or more other users (e.g., the user's children) to share each other's location within the store. In another implementation, the user may have the option to start a shop view similar to the street view in the map. The store view 719n may display images/videos of the user's surroundings. For example, if a user is about to enter the aisle 5, the store view map may display a view of the aisle 5. Further, the user may manipulate the orientation of the map by using the navigation tool 719o to rotate the mobile store view forward, backward, right, left, and clockwise and counterclockwise.

Fig. 8A-F show user interface diagrams illustrating example features of a virtual wallet application in payment mode in some embodiments of the VWCS. Referring to fig. 8A, in one embodiment, the wallet mobile application may provide a user with a number of options for paying for a transaction via wallet mode 810. In one implementation, an example user interface 811 for making payments is displayed. The user interface may explicitly identify the amount 812 and currency 813 for the transaction. The amount may be a payable amount and the currency may include real currency, such as U.S. dollars and euros, and virtual currency, such as reward points. The amount of the transaction 814 may also be highlighted on the user interface. The user may select the funds tab 816 to select one or more forms of payment 817, which may include various credit cards, debit cards, gifts, rewards, and/or prepaid cards. The user may also have the option to pay in whole or in part with bonus points. For example, a graphical indicator 818 on the user interface displays the number of points available, and a graphical indicator 819 displays the equivalent of the number of points to be used for the payable amount 234.56 and the number of points in the selected currency (USD, for example).

In one implementation, a user may combine funds from multiple sources (sources) to pay for a transaction. The amount 815 displayed on the user interface may provide an indication of the amount of total funds covered up to now by the selected form of payment (e.g., discovery card and reward points). The user may select another form of payment from one or more forms of payment or adjust the amount to be debited until the amount 815 matches the amount due 814. Payment authorization begins once the amount to be debited is finalized by the user from one or more forms of payment.

In one implementation, the user may select secure transaction authorization by selecting the hide button 822 to effectively hide or hide some (e.g., preconfigured) or all of the identification information so that when the user selects the payment button 821, the transaction authorization proceeds in a secure and anonymous manner. In another implementation, the user may select the payment button 821, which may use standard authorization techniques for transaction processing. In yet another implementation, when the user selects the social button 823, a message regarding the transaction may be sent to one of more social networks (set by the user), which may post or announce the purchase transaction in the manner of a social forum, such as a wall post or tweet. In one implementation, the user may select the social payment processing option 823. Indicator 824 may display authorization and sending social sharing data in progress.

In another implementation, the limited payment mode 825 will be activated for certain purchasing activities (such as prescription purchases). The schema is activated to facilitate processing of specialized goods and services according to rules defined by an issuer, an insurer, a merchant, a payment processor, and/or other entities. In this mode, the user may scroll down the list of forms of payment under the funds tab to select a specific account amount, such as Flexible Spending Account (FSA) 827, health savings account (HAS), and the amount to be debited to the selected account. In one implementation, such a limited payment mode 825 process may disable social sharing of purchase information.

In one implementation, the wallet mobile application may facilitate the import of funds via an import funds user interface 828. For example, a user that is out of business may obtain lost business relief funds 829 via a wallet mobile application. In one implementation, the funding entity may also configure rules for using funds, as shown by process indication message 830. The wallet may read and apply the previous rules and may reject any purchases with unemployed funds that do not meet the criteria set by the rules. Example criteria may include, for example, a Merchant Category Code (MCC), time of transaction, location of transaction, etc. As an example, a transaction with a grocery merchant with MCC5411 would be approved, while a transaction with a bar merchant with MCC5813 would be denied.

Referring to fig. 8B, in one embodiment, the wallet mobile application may facilitate dynamic payment optimization based on factors such as user location, preferences, monetary value preferences, and the like. For example, when the user is in the united states, the country indicator 831 may display the national flag of the united states and set the currency 833 to the united states. In further implementations, the wallet mobile application may automatically reorder 835 the order in which forms of payment are listed to reflect popularity or acceptance of various forms of payment. In one implementation, the arrangement may reflect the user's preferences, which cannot be changed by the wallet mobile application.

Likewise, when a german user operates a wallet in germany, the mobile wallet application user interface may be dynamically updated to reflect the country 832 and currency 834 of operation. In further implementations, the wallet application may reorder the order in which the different forms of payment 836 are listed based on their acceptance in that country. Of course, the order of the forms of these payments may be modified by the user to accommodate his or her own preferences.

Referring to fig. 8C, in one embodiment, a payee tag 837 in the wallet mobile device application user interface may facilitate the user in selecting a payee of the one or more funds tags to receive the selected funds. In one implementation, the user interface may display a list of all payees 838 for which the user has previously conducted a transaction or is able to conduct a transaction. The user may then select one or more payees. Payee 838 may include a larger merchant such as amazon.com inc. and an individual such as Jane p.doe. Near each payee name, a list of acceptable payment modes for the payee may be displayed. In one implementation, the user may select payee Jane p.doe839 for receiving payment. When selected, the user interface may display additional identifying information associated with the payee.

Referring to fig. 8D, in one embodiment, a mode tab 840 may facilitate selection of a payment mode accepted by the payee. A large number of payment modes are available for selection. Example modes include: bluetooth 841, wireless 842, QR code 843 acquired through the user's capture movement, secure chip 844, Twitter845, Near Field Communication (NFC) 846, cell 847 for a robbery, QR code 848 provided through the user's capture movement, USB849, and FACEBOOK850, among others. In one implementation, only the payment mode accepted by the payee may be selected by the user. Other unacceptable payment modes may be disabled.

Referring to FIG. 8E, in one embodiment, providing a tag 851 can provide a real-time offer related to the items in the user's shopping cart. The user may select one or more offers from a list of applicable offers 852 for redemption. In one implementation, some offers may be combined while others may not. When a user selects an offer that is not combinable with another offer, the unselected offer may be disabled. In a further implementation, the offer recommended by the recommendation engine of the wallet application may be identified by an indicator such as that shown by 853. In a further implementation, the user may read the details of the offer by expanding the offer bar shown by 854 in the user interface.

Referring to fig. 8F, in one embodiment, a social tag 855 may facilitate integration of the wallet application with the social channel 856. In one implementation, a user may select one or more social channels 856 and may log in from the wallet application to the selected social channels by providing the wallet application with a social channel username and password 857 and a login 858. The user may then send or receive money through the integrated social channel using the social button 859. In further implementations, the user may send social sharing data, such as purchase information or links, through an integrated social channel. In another embodiment, the login credentials provided by the user may allow the VWCS to participate in intercept resolution.

Fig. 9 shows a user interface diagram illustrating example features of a virtual wallet application in history mode in some embodiments of a VWCS. In one embodiment, the user may select the history mode 910 to view a history of previous purchases and perform various actions on these previous purchases. For example, the user may enter merchant identification information, such as name, product, MCC, etc., in the search bar 911. In another implementation, the user may use voice activated search features by clicking on the microphone icon 914. The wallet application may query a storage area in the mobile device or elsewhere (e.g., one or more databases and/or tables remote from the mobile device) for transactions matching the search keywords. The user interface may then display the results of the query, such as transaction 915. The user interface may also identify the date 912 of the transaction, the item and merchant 913 associated with the transaction, the barcode of the receipt confirming that the transaction has been made, the amount of the transaction, and any other relevant information.

In one implementation, a user may select a transaction (e.g., transaction 915) to view details of the transaction. For example, the user may view details of the items associated with the transaction and the amount 916 of each item. In a further implementation, the user may select display option 917 to view actions 918 the user may take with respect to the transaction or item in the transaction. For example, the user may add a photo to the transaction (e.g., the user's photo and the user's purchased iPad). In a further implementation, if a user previously shared a purchase via a social channel, a post including a photograph may be generated and sent to the social channel for publication. In one implementation, any sharing may be optional, and a user who does not share purchases via a social channel may still share photos directly from the historical pattern of the wallet application through one or more social channels of his or her choosing. In another implementation, the user may add transactions to the block, such as corporate expenses, family expenses, travel expenses, or other categories established by the user. Such groupings may facilitate settlement of end-of-year expenses, submission of reports of working expenses, submission of Value Added Tax (VAT) refunds, personal expenses, and the like. In yet another implementation, a user may purchase one or more items purchased in a transaction. The user may then perform the transaction without going to the merchant catalog or site to find the item. In further implementations, the user may also place one or more items in the transaction into a shopping cart for later purchase.

In another embodiment, the history mode may provide a facility for obtaining and displaying a rating (rating) of an item in a transaction. The source of the rating may be the user, friends of the user (e.g., from social channels, contacts, etc.), comments aggregated from the network, and so forth. The user interface may also allow a user to post messages to other users of a social channel (e.g., Twitter or Facebook) in some implementations. For example, display area 920 shows Facebook messages being exchanged between the two users. In one implementation, the user may share the link via message 921. Selecting such an embedded product link message may allow the user to view a description of the product and/or purchase the product directly from the historical schema.

In one embodiment, the history mode may also include a tool for deriving receipts. Export receipt pop-up window 922 may provide a number of options for exporting receipts for historical transactions. For example, a user may use one or more of options 925, which options 925 include: save (to local mobile storage, server, cloud account, etc.), print to printer, fax, email, etc. The user may utilize his or her address book 923 to look up an email or fax number for export. The user may also specify a format option 924 for exporting receipts. Example format options include, without limitation: text files (. doc,. txt,. rtf,. iif, etc.), spreadsheets (. csv,. xls, etc.), image files (. jpg,. tff,. png, etc.), portable document formats (. pdf), postscript (. ps), etc. The user can then click or tap export button 927 to initiate export of the receipt.

Fig. 10A-E show user interface diagrams illustrating example features of a virtual wallet application in capture mode in some embodiments of a VWCS. Referring to FIG. 10A, in one embodiment, a user may select a capture mode 2110 to access their capture features. The capture mode may process any machine-readable representation of the tabular data. Examples of such data include linear and 2D barcodes, such as UPC codes and QR codes. These codes can be found on receipts, product packaging, and the like. The capture mode may also process and manipulate pictures of receipts, products, offers, credit cards or other payment devices, and the like. An example user interface in capture mode is shown in FIG. 10A. The user may take a picture of the QR code 1015 and/or the barcode 1014 using his or her mobile phone. In one implementation, bar 1013 and capture box 1015 may help a user to correctly capture a code. For example, capture block 1015 as shown does not capture all of code 1016. Thus, the code captured in this view may not be analyzable, as the information in the code may be incomplete. This is indicated by the message on bar 1013 indicating that the capture mode is still looking for a code. When code 1016 is completely framed by capture box 1015, the message may be updated to capture discovery, for example. In one implementation, when a code is found, the user may initiate at least a capture by using the mobile device camera. In another implementation, the capture mode may capture the code automatically by using a mobile device camera.

Referring to FIG. 10B, in one embodiment, the capture mode may facilitate post-transaction payment reallocation (reallocation). For example, a user may purchase grocery and prescription items from a retailer Acme supermarket. The user uses his or her Visa card, for example, to pay for grocery and prescription items, either unintentionally or for the convenience of checkout. However, the user may have an FSA account that may be used to pay the prescription items and that will provide tax benefits to the user. In such a case, the user may use the capture mode to initiate transaction reassignment.

As shown, a user may enter search terms (e.g., a bill) in search bar 2121. The user may then identify in label 1022 the receipt 1023 that the user wants to redistribute. Alternatively, the user may directly capture a picture of a barcode on the receipt, and the capture mode may generate and display the receipt 1023 by using information from the barcode. The user can now reassign 1025. In some implementations, the user can also block (dispute) the transaction 1024 or archive 1026 the receipt.

In one implementation, when the reassignment button 1025 is selected, the wallet application may perform Optical Character Recognition (OCR) of the receipt. The items in the receipt may then be examined to identify which payment device or account may be charged for tax benefits or other benefits such as cashback, reward points, etc. for which of the one or more items. In this example, there is a tax benefit if the prescription drug charging the user's Visa card charges the user's FSA account. The wallet application may then perform reallocation as a backend. The redistribution process may include the wallet contacting the payment processor to debit the Visa card for the amount of the prescribed drug and to debit the user's FSA account for the same amount. In an alternative implementation, a payment processor (e.g., Visa or MasterCard) may take a receipt and OCR the receipt, identify payment accounts and items for redistribution, and perform redistribution. In one implementation, the wallet application may request that the user confirm that the fee is to be redistributed to another payment account for the selected item. A receipt 1027 can be generated after the reassignment process is complete. As discussed, the receipt shows that some charges have been moved from the Visa account to the FSA.

Referring to fig. 10C, in one embodiment, the capture mode may facilitate payment via a payment code, such as a barcode or QR code. For example, a user may capture a QR code for a transaction that has not yet been completed. The QR code may be displayed at a merchant POS terminal, website, or web application, and may be encoded with information identifying the purchase item, merchant details, and other related information. When a user captures, for example, a QR code, the capture mode may decode the information in the QR code and may use the decoded information to generate a receipt 1032. Once the QR code is identified, the navigation bar 1031 may indicate that the payment code is identified. The user may now have the option to add to the shopping cart 1033, pay 1034 with a default payment account or pay 1035 with a wallet.

In one implementation, the user may decide to utilize a default payment 1034. In this example wallet, the wallet application may then complete the purchase transaction using the user's default payment method. When the transaction is completed, a receipt may be automatically generated for proof of purchase. The user interface may also be updated to provide other options to process the completed transaction. Example options include social interaction 1037 for sharing purchase information with others, reassignment 1038 as discussed with respect to FIG. 10B, and archive 1039 for storing receipts.

Referring to FIG. 10D, in one embodiment, the capture mode may also facilitate providing recognition, application, and storage for future use. For example, in one implementation, the user may capture a provided code 1041 (e.g., a barcode, a QR code, etc.). The wallet application may then generate the offer text from the information encoded in the offer code 1042. The user may perform a number of operations on the provided code. For example, the user uses the find button 1043 to find all merchants accepting the offer code, nearby merchants accepting the offer code, products of merchants matching the offer code, and so forth. The user may also apply the code to the items currently in the shopping cart by using the add to shopping cart button 1044. In addition, the user may save the offer for future use by selecting save button 1045.

In one implementation, after the offer or coupon 1046 is applied, the user may have the option to find a qualified merchant and/or product by lookup, the user may enter the wallet by using 1048, and the user may also save the offer or coupon 1046 for later use.

Referring to fig. 10E, in one embodiment, the capture mode may also provide a tool for adding a source of funds to the wallet application. In one implementation, payment cards such as credit cards, debit cards, prepaid cards, smart cards, and other payment accounts may have an associated code such as a barcode or QR code. Such codes may have payment card information encoded therein, including but not limited to: name, address, payment card type, payment card account details, balance amount, spending limit, reward balance, etc. In one implementation, the code may be found on one side of the physical payment card. In another implementation, the code may be obtained by accessing an associated online account or other secure location. In yet another implementation, the code may be printed on a certificate accompanying the payment card. In one implementation, a user may capture a picture of the code. The wallet application may identify the payment card 1051 and may display text information 1052 encoded in the payment card. The user may then perform authentication of the information 1052 by selecting the authentication button 1053. In one implementation, the verification may include contacting the issuer of the payment card to confirm the decoded information 1052, as well as any other related information. In one implementation, the user can add a payment card to the wallet by selecting the add to wallet button 1054. The instruction to add a payment card to the wallet may cause the payment card to appear under the funds tab 816 discussed in fig. 8A as one of the forms of payment. The user may also cancel the import of the payment card as a funding source by selecting a cancel button 1055. When a payment card has been added to the wallet, the user interface may be updated to indicate that the import is complete via notification display 1056. The user may then access wallet 1057 to begin using the added payment card as a source of funds.

Fig. 11 shows a user interface diagram illustrating example features of a virtual wallet application in a provisioning mode in some embodiments of a VWCS. In some implementations, the VWCS may allow a user to search for the provision of products and/or services in the virtual wallet mobile application. For example, a user may enter text in a graphical user interface ("GUI") element 1111 or issue a voice command by activating GUI element 1112 and speaking a command to the device. In some implementations, the VWCS may provide offers based on the user's previous behavior, demographics, current location, current shopping cart selection or purchase items, and so forth. For example, if a user is at a physical store or an online shopping website and leaves the (virtual) store, then a merchant associated with the store desires to provide sweet-head transactions (sweet-head facilities) to attract consumers back to the (virtual) store. The merchant may provide such an offer 1113. For example, the offer may offer a discount and may include an expiration time. In some implementations, other users may provide the user with gifts (e.g., 1114) that the user can redeem. In some implementations, the provisioning section may include an alert (e.g., 1115) regarding payment of the unpaid funds to other users. In some implementations, the offer portion may include an alert (e.g., 1116) regarding the request for receipt of funds from other users. For example, such features may identify accounts receivable from other applications (e.g., mail, calendar, tasks, notes, reminders, alerts, etc.), or through manual entry by the user into the virtual wallet application. In some implementations, the offer portion may offer offers from participating merchants in the VWCS (e.g., 1117-. These offers can sometimes be aggregated through the use of a combination of participating merchants, e.g., 1117. In some implementations, the VWCS itself may provide for users that rely on users utilizing a particular form of payment from within the virtual wallet application (e.g., 1120).

Fig. 12A-B show user interface diagrams illustrating example features of a virtual wallet application in secure and privacy modes in some embodiments of a VWCS. Referring to fig. 12A, in some implementations, a user may be able to view and/or modify a user profile and/or user's settings, for example, by activating a user interface element. For example, the user may be able to view/modify a username (e.g., 1211 a-b), an account number (e.g., 1212 a-b), a user security access code (e.g., 1213-b), a user pin (e.g., 1214-b), a user address (e.g., 1215-b), a social security number associated with the user (e.g., 1216-b), a current device GPS location (e.g., 1217-b), a user account (e.g., 1218-b) of a merchant at which the user is currently located, a rewards account (e.g., 1219-b) of the user, and so forth. In some implementations, the user may be able to select which data fields and their associated values should be communicated to facilitate the purchase transaction, thereby providing enhanced data security for the user. For example, in the example illustration of FIG. 12A, the user has selected the name 1211a, account number 1212A, security code 1213a, merchant account ID1218a, and reward account ID1219a as fields (to be sent as part of the notification) to process the purchase transaction. In some implementations, the user can switch fields and/or data values that are sent as part of the notification to process the purchase transaction. In some implementations, the application may provide multiple screens of stored data fields and/or associated values for user selection as part of the purchase order transmission. In some implementations, the application may provide the VWCS with the user's GPS location. Based on the user's GPS location, the VWCS may determine the user's environment (e.g., whether the user is in a store, a doctor's office, a hospital, a postal service office, etc.). Based on the circumstances, the user application may present the appropriate fields to the user from which the user may select fields and/or field values to send as part of the purchase order transmission.

For example, the user may go to a doctor's office and desire to pay a co-paid medical fee for the doctor's appointment. In addition to basic transaction information such as account number and name, the application may provide the user with the ability to select to transfer medical records, health information, which may be provided to medical providers, insurance companies, and transaction processors to coordinate payment among multiple parties. In some implementations, records may be sent and encrypted in a data format compatible with the health insurance Act and accountability Act (HIPAA), and only recipients authorized to view such records may have the appropriate decryption keys to decrypt and view private user information.

Referring to FIG. 12B, in some implementations, an application executing on a user's device may provide a chat verification feature to prevent fraud. For example, the VWCS may detect anomalous and/or suspicious transactions. The VWCS may communicate with the user using a chat verification feature and verify the authenticity of the originator of the purchase transaction. In various implementations, the VWCS may send an email message, a text (SMS) message, a,Message, Twitter^TMTwitter, text chat, voice chat, video chat (e.g., Apple FaceTime), and the like. For example, the VWCS may initiate a video challenge (e.g., 1221) to the user. For example, a user needs to show himself/herself via video chat (e.g., 1222). In some implementations, a customer service representative (e.g., agent 1224) may manually determine the authenticity of a user using the user's video. In some implementations, the VWCS may utilize facial, biometric, etc. recognition (e.g., using pattern classification techniques) to determine the identity of the user. In some implementations, the application may provide a reference marker (e.g., a cross-hair, a target box, etc.) (e.g., 1223) so that the user may visualize to facilitate user automatic identification of the VWCS. In some implementations, the user may not initiate a transaction, for example, the transaction is fraudulent. In such an implementation, the user may cancel the challenge. The VWCS may then cancel the transaction, and/or initiate a fraud investigation process on behalf of the user.

In some implementations, the VWCS may utilize a text challenge process to verify the authenticity of the user (e.g., 1225). For example, the VWCS may be implemented via text chat, SMS messages, email, web browser, or web browser,Message, Twitter^TMTwitter, etc. communicates with the user. The VWCS may present a challenge question (e.g., 1226) to the user. The application may provide a user input interface element (e.g., virtual keyboard 1228) to answer the challenge question posed by the VWCS. In some implementations, the challenge question may be automatically followed by the VWCSSelecting a machine; in some implementations, the customer service representative may manually communicate with the user. In some implementations, the user may not initiate a transaction, for example, the transaction is fraudulent. In such an implementation, the user may cancel the text challenge. The VWCS may cancel the transaction on behalf of the user, and/or initiate a fraud investigation process.

FIG. 13 shows a data diagram intent illustrating an example aspect of converting a user checkout request input into a checkout data display output via a user purchase checkout ("UPC") component. In some embodiments, a user (e.g., 1301 a) may desire to purchase a product, service, offer, etc. (product) from a merchant through a merchant online website or merchant's store. The user may communicate with a merchant/acquirer (merchant) server through clients (e.g., 1303 a) such as, but not limited to: personal computers, mobile devices, televisions, point-of-sale terminals, kiosks, ATMs, and the like (e.g., 1302). For example, the user may provide a user input (e.g., checkout input 1311) to the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but is not limited to: single tap of a touch screen interface (e.g., tapping a mobile application purchase embodiment), keyboard entry, swiping a card, activating a hardware device (e.g., electronic card with multiple accounts, smartphone, tablet, etc.) that hosts RFID/NFC within a user device, mouse click, pressing a key on a joystick/game console, voice command, single/multiple touch gesture on a touch sensitive interface, touch user interface element on a touch sensitive display screen, etc. As one example, a user at a merchant store may scan a product barcode for a product via a barcode scanner of a point-of-sale terminal. As another example, a user may select a product from a web catalog on a merchant's website and add the product to a virtual shopping cart on the merchant's website. The user may then indicate the user's desire to check out for items in the (virtual) shopping cart. For example, the user may activate a user interface element provided by the client to indicate a desire to complete the user's purchase checkout. The client can generate a checkout request (e.g., 1312) and provide the checkout request (e.g., 1313) to the merchant server. For example, the client may provide a (secure) hypertext transfer protocol (http (s)) POST message that includes product details for the merchant server in the form of data formatted according to extensible markup language (XML). An example listing of checkout requests 1312 is provided below, substantially in the form of an http(s) POST message including XML formatted data:

in some embodiments, the merchant server may obtain a checkout request from the client and extract checkout details (e.g., XML data) from the checkout request. For example, the merchant server may utilize a resolver such as the example resolver described in the discussion below with reference to FIG. 19. Based on resolving the checkout request 1312, the merchant server may extract product data (e.g., product identifier) from the checkout request along with the PoS client data that is available. In some embodiments, using the product data, the merchant server may query (e.g., 1314) a merchant/acquirer ("merchant") database (e.g., 1303 b) for product data (e.g., 1315), such as product information, product price, sales tax, offers, discounts, rewards, and/or other information to process the purchase transaction for the user and/or provide value-added services. For example, the merchant database may be a relational database that is responsive to structured query language ("SQL") commands. The merchant server may execute a hypertext preprocessor (PHP) script including SQL commands to query database tables (such as fig. 19, product 1919 l) for product data. An example product data query 1314 substantially in the form of PHP/SQL is provided below:

in some embodiments, in response to obtaining the product data, the merchant server may generate (e.g., 1316) checkout data to provide to the PoS client. In some implementations, such checkout data (e.g., 1317) may be partially contained in a hypertext markup language (HTML) page that includes data for display (such as product details, product price, total price, tax information, shipping information, offers, discounts, rewards, value added service information, etc.) and input fields (such as account holder name, account number, billing address, shipping address, tip amount, etc.) that provide payment information to process the purchase transaction. In some embodiments, the checkout data may be partially contained in a Quick Response (QR) code image displayable by the PoS client, such that the user may capture the QR code using the user's device to obtain merchant and/or product data to generate the purchase transaction processing request. In some embodiments, a user alert mechanism may be built into the checkout data. For example, the merchant server may embed a transaction-specific URL into the checkout data. In some embodiments, the alert URL may also be embedded in optional level 3 data in the card authorization request, such as those discussed further below with reference to fig. 15-16. The URL may point to a web page, data file, executable script, etc. stored on a merchant's server dedicated to the transaction (which is the subject of the card authorization request). For example, the object pointed to by the URL may include details about the purchase transaction, such as the product being purchased, the purchase cost, the time expiration (expiration), the order processing status, and the like. Thus, by passing the URL of the web page to the payment network, the merchant server may provide the details of the transaction to the payment network. In some embodiments, the payment network may provide notifications to the user, such as payment receipts, transaction authorization confirmation messages, shipping notifications, and the like. In such a message, the payment network may provide the URL to the user device. The user may navigate to a URL on the user's device to obtain alerts related to the user's purchase, as well as other information, such as offers, coupons, related products, reward notifications, and the like. An example listing of checkout data 1317 substantially in the form of XML formatted data is provided below:

upon acquiring the checkout data (e.g., 1317), the PoS client may present and display (e.g., 1318) the checkout data to the user.

FIG. 14 shows a logic flow diagram illustrating an example aspect of converting a user checkout request input into a checkout data display via a user purchase checkout ("UPC") component. In some embodiments, a user may desire to purchase a product, service, offer, etc. (product) from a merchant through a merchant online website or merchant's store. A user may communicate with a merchant/acquirer (merchant) server through a PoS client. For example, the user may provide user input (e.g., 1401) to the client indicating the user's desire to purchase the product. The client may generate a checkout request (e.g., 1402) and provide the checkout request to the merchant server. In some embodiments, the merchant server may obtain a checkout request from the client and extract checkout details (e.g., XML data) from the checkout request. For example, the merchant server may utilize a resolver such as the example resolver described in the discussion below with reference to FIG. 19. Based on parsing the checkout request, the merchant server may extract product data (e.g., a product identifier) from the checkout request along with available PoS client data. In some embodiments, using the product data, the merchant server may query (e.g., 1403) a merchant/acquirer ("merchant") database to obtain product data (e.g., 1404), such as product information, product price, sales tax, offers, discounts, rewards, and/or other information to process the purchase transaction and/or provide value-added services for the user. In some embodiments, in response to obtaining the product data, the merchant server may generate (e.g., 1405) checkout data to provide (e.g., 1406) to the PoS client. Upon acquiring the checkout data, the PoS client may present and display (e.g., 1407) the checkout data to the user.

15A-B show data diagram intents illustrating example aspects of converting user virtual wallet access input to a purchase transaction receipt notification via a purchase transaction authorization ("PTA") component. Referring to fig. 15A, in some embodiments, a user (e.g., 1501 a) may desire to purchase a product, service, offer, etc. (product) from a merchant using a virtual wallet card account via a merchant online website or merchant's store. The user may utilize a physical card (physical card) or a user wallet device (e.g., 1501 b) to access the user's virtual wallet account. For example, the user wallet device may be a personal computer/laptop, a cellular phone, a smart phone, a tablet, an e-book reader, a netbook, a game console, and so forth. The user may provide wallet access input (e.g., 1511) to the user wallet device. In various embodiments, the user input may include, but is not limited to: single tap of a touch screen interface (e.g., tapping a mobile application purchase embodiment), keyboard entry, swiping a card, activating a hardware device (e.g., electronic card with multiple accounts, smartphone, tablet, etc.) that hosts RFID/NFC within a user device, mouse click, pressing a key on a joystick/game console, voice command, single/multiple touch gesture on a touch sensitive interface, touch user interface element on a touch sensitive display screen, etc. In some embodiments, the user wallet device may authenticate the user according to the user's wallet access input and provide the user with virtual wallet features.

In some embodiments, when the user is authenticated for access to the virtual wallet feature, the user wallet device may provide transaction authorization input, e.g., 1514, to a point of sale (PoS) client, e.g., 1502. For example, the user wallet device may communicate with the PoS client via bluetooth, Wi-Fi, cellular communication, unidirectional or bidirectional near field communication ("NFC"), and/or the like. In embodiments where the user utilizes a plastic card rather than a user wallet device, the user may swipe the plastic card at the PoS client to convert the information from the plastic card to the PoS client. For example, the PoS client may obtain tracking 1 data from a user's plastic card (e.g., credit card, debit card, pre-paid card, payment card, etc.) as transaction authorization input 1514, such as the example tracking 1 data provided below:

%B123456789012345^PUBLIC/J.Q.^99011200000000000000**901******?*

(where '123456789012345' is the card number of 'j.q.public', and has a CVV number 901. '990112' is the service code, and denotes a decimal number that changes randomly each time the card is used)

In embodiments where the user utilizes a user wallet device, the user wallet device may provide payment information to the PoS client that is formatted according to a data format protocol suitable for the communication mechanism employed in the communication between the user wallet device and the PoS client. An example listing of transaction authorization inputs 1514, substantially in the form of XML formatted data, is provided below:

in some embodiments, the PoS client may generate a card authorization request (e.g., 1515), and/or product/checkout data (see, e.g., figure 13, 1315) using the transaction authorization input obtained from the user wallet device. An exemplary listing of card authorization requests 1515 and 1516, substantially in the form of http(s) POST messages comprising XML formatted data, is provided below:

in some embodiments, the card authorization request generated by the user device may include the minimum information required to process the purchase transaction. This may, for example, improve the efficiency of the purchase transaction request communication, and may also advantageously improve the privacy protection provided to the user and/or merchant. For example, in some embodiments, the card authorization request may include at least one session ID for a shopping session of the user with the merchant. The session ID may be utilized by any component and/or entity having appropriate access rights to a secure site on the merchant server to obtain alerts, reminders, and/or other data regarding the transaction during the user's and merchant's shopping session. In some embodiments, the PoS client may provide the generated card authorization request (e.g., 1516) to the merchant server. The merchant server may forward the card authorization request (e.g., 1504 a) to the payment gateway server for routing the card authorization request to the appropriate payment network for payment processing. For example, the payment gateway server can select from a payment network such as Visa, Mastercard, American Express, Paypal, etc. to handle various types of transactions including, but not limited to: credit card, debit card, prepaid card, B2B, and the like. In some embodiments, the merchant server may query a database (e.g., merchant/acquirer database 1503 b) for the network address of the payment gateway server, for example, by using the user ID (such as an email address) or a portion of the user's payment card number as a key for the database query. For example, the merchant server may issue a PHP/SQL command to query a database table (such as fig. 19, payment gateway 1919 h) for the URL of the payment gateway server. An example payment gateway address query 1517, substantially in the form of a PHP/SQL command, is provided below:

in response, the merchant/acquirer database may provide the requested payment gateway address (e.g., 1518). The merchant server may forward a card authorization request (e.g., 1519) to the payment gateway server using the provided address. In some embodiments, when a card authorization request is received from a merchant server, the payment gateway server may invoke (invoke) a component to provide one or more services associated with purchase transaction authorization. For example, the payment gateway server may invoke components for fraud prevention, loyalty and/or rewards, and/or other services for which the user-merchant combination is authorized. The payment gateway server may forward the card authorization request to a payment network server (e.g., 1505 a) for payment processing. For example, the payment gateway server can select from a payment network such as Visa, Mastercard, American Express, Paypal, etc. to handle various types of transactions including, but not limited to: credit card, debit card, prepaid card, B2B, and the like. In some embodiments, the payment gateway server may query a database (e.g., payment gateway database 1504 b) for the payment gateway server's network address, for example, by using a user ID (such as an email address) or a portion of the user's payment card number as a key for the database query. For example, the payment gateway server may issue a PHP/SQL command to query a database table (such as fig. 19, payment gateway 1919 h) for the URL of the payment gateway server. An example payment network address query 1521, substantially in the form of a PHP/SQL command, is provided below:

in response, the payment gateway database may provide the requested payment network address (e.g., 1522). The payment gateway server forwards the card authorization request (e.g., 1523) to the payment network server by using the provided address.

Referring to fig. 15B, in some embodiments, the payment network server may process the transaction in order to transfer funds for the purchase into an account stored on the merchant's acquirer. For example, the acquirer may be a financial institution that maintains the merchant's account. For example, the proceeds for a transaction processed by a merchant may be deposited into an account maintained by a server of the acquirer.

In some embodiments, the payment network server may generate a query (e.g., 1524) for the acquirer server corresponding to the payment option selected by the user. For example, a user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, that issue accounts for the user. For example, these accounts may include, but are not limited to: credit cards, debit cards, prepaid cards, checks, savings, money markets, deposit slips, storage (cash) accounts, and the like. An issuer server (e.g., 1506 a) of the issuer may maintain details of the user account. In some embodiments, a database (e.g., payment network database 1505 b) may store details of an issuer server associated with an issuer. In some embodiments, the payment network server may query a database (e.g., payment network database 1505 b) for the issuer server's network address, for example, by using the user ID (such as an email address) or a portion of the user's payment card number as a key for the database query. For example, the merchant server may issue a PHP/SQL command to query a database table (such as fig. 19, issuer 1919 f) for the network address of the issuer server. An example issuer server address query 1524, substantially in the form of a PHP/SQL command, is provided below:

in response to obtaining the issuer server query (e.g., 1524), the payment network database may provide (e.g., 1525) the requested issuer server data to the payment network server. In some embodiments, the payment network server may utilize the issuer server data to generate a funding authorization request (e.g., 1526) for each of the issuer servers selected based on predefined payment settings associated with the user's virtual wallet, and/or the user's payment option input, and provide the funding authorization request to the issuer server. In some embodiments, the funding authorization request includes details such as, but not limited to: the cost of the user involved in the transaction, details of the user's card account, user billing and/or shipping information, and the like. An example listing of funding authorization requests 1526, substantially in the form of an http(s) POST message including XML formatted data, is provided below:

in some implementations, the issuer server may parse the authorization request and query a database (e.g., user profile database 1506 b) for data associated with the account linked to the user according to the request details. For example, the merchant server may issue a PHP/SQL command to query database tables (e.g., FIG. 19, account 1919 d) for user account data. An example user account query 1527 substantially in the form of a PHP/SQL command is provided below:

in some embodiments, when obtaining user account data (e.g., 1528), the issuer server may determine whether the user may pay for the transaction by using funds available in the account (1529). For example, the issuer server may determine whether the user has sufficient balance remaining in the account, sufficient credit associated with the account, etc. Based on the determination, the issuer server may provide a funding authorization response to the payment network server (e.g., 1530). For example, the issuer server may provide an http(s) POST message similar to the example above. In some embodiments, if the at least one issuer server determines that the user cannot pay for the transaction by using funds available in the account, the payment network server may again request payment options from the user (e.g., by providing an authorization failure message to the user device and requesting the user device to provide new payment options), and again attempt authorization for the purchase transaction. In some embodiments, if the number of failed authorization attempts exceeds a threshold, the payment network server may abort the authorization process and provide an authorization failure message to the merchant server, the user device, and/or the client.

In some embodiments, the payment network server may obtain a funding authorization response that includes a notification of successful authorization and parse the message to extract authorization details. When it is determined that the user has sufficient funds (e.g., 1531) for the transaction, the payment network server may invoke a component to provide value added services to the user.

In some embodiments, the payment network server may generate a transaction data record from the authorization request and/or the authorization response and store the authorization related to the transaction and details of the transaction in a transaction database. For example, the payment network server may issue PHP/SQL commands to store data to database tables (such as fig. 19, transaction 1919 i). An example transaction storage command substantially in the form of a PHP/SQL command is provided below:

in some embodiments, the payment network server may forward the transaction authorization response (e.g., 1532) to the user wallet device, PoS client, and/or merchant server. The merchant may obtain the transaction authorization response and determine from it that the user has sufficient funds in the card account to conduct the transaction. The merchant server may add a record of the transaction for the user to a collection of transaction data related to the authorized transaction. For example, the merchant may add XML data related to user transactions to an XML data file (e.g., 1533) containing XML data for transactions for which the respective user has been authorized, and store the XML data file (e.g., 1534) in a database (e.g., merchant database 404). For example, a bulk XML data file similar to the example XML data structure template provided below may be constructed:

in some embodiments, the server may also generate a purchase receipt (e.g., 1533) and provide the purchase receipt (e.g., 1535) to the client. The client may present and display the purchase receipt (e.g., 1536) for the user. In some embodiments, the user's wallet device may also provide notification of successful authorization to the user. For example, the PoS client/user device may render web pages, electronic messages, text/SMS messages, buffer voice mails, make ring tones, and/or play audio messages, etc., and provide outputs including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a client device capable of vibrating, such as a smartphone), and the like.

16A-B show a logic flow diagram illustrating example aspects of converting user virtual wallet access input into a purchase transaction receipt notification via a purchase transaction authorization ("PTA") component. Referring to fig. 16A, in some embodiments, a user may wish to utilize a virtual wallet account via a merchant online website or in a merchant's store to purchase products, services, offers, etc. (the "products"). The user may utilize a physical card or a user wallet device to access the user's virtual wallet account. For example, the user wallet device may be a personal computer/laptop, a cellular phone, a smart phone, a tablet, an e-book reader, a netbook, a game console, and so forth. The user may provide wallet access input to the user wallet device (e.g., 1601). In various embodiments, the user input may include, but is not limited to: single tap of a touch screen interface (e.g., tapping a mobile application purchase embodiment), keyboard entry, swiping a card, activating an RFID/NFC equipped hardware device within a user device (e.g., electronic card with multiple accounts, smart phone, tablet, etc.), mouse click, pressing a button on a joystick/game console, voice command, single/multi-touch gesture on a touch sensitive interface, touch user interface element on a touch sensitive display screen, etc. In some embodiments, the user wallet device may authenticate the user based on the user's wallet access input and provide the user with virtual wallet features (e.g., 1602-.

In some embodiments, the user wallet device may provide transaction authorization input (e.g., 1604) to a point of sale (PoS) client when the user is authenticated to access the virtual wallet feature. For example, the user wallet device may communicate with the PoS client via bluetooth, Wi-Fi, cellular communication, one-way or two-way Near Field Communication (NFC), and/or the like. In embodiments where the user utilizes a plastic card rather than a user wallet device, the user may swipe the plastic card at the PoS client to communicate information from the plastic card to the PoS client. In embodiments where the user utilizes a user wallet device, the user wallet device may provide payment information to the PoS client, the payment information being formatted according to a data format protocol suitable for the communication mechanism used between the user wallet device and the PoS client.

In some embodiments, the PoS client may obtain the transaction authorization input and parse the input to extract payment information from the transaction authorization input (e.g., 1605). For example, the PoS client may utilize a parser such as the example parser provided in the discussion below with reference to fig. 19. The PoS client may generate a card authorization request (e.g., 1606) using the acquired transaction authorization input and/or product/checkout data from the user wallet device (see, e.g., figure 13, 1315) 1317).

In some embodiments, the PoS client may provide the generated card authorization request to the merchant server. The merchant server may forward the card authorization request to the payment gateway server to route the card authorization request to the appropriate payment network for payment processing. For example, the payment gateway server may be able to select from a payment network such as Visa, Mastercard, American Express, Paypal, etc. to handle various types of transactions including, but not limited to: credit card, debit card, prepaid card, B2B, and the like. In some embodiments, the merchant server may query the database (e.g., 1608) for the network address of the payment gateway server, for example, by using a portion of the user payment card number or user ID (such as an email address) as a key for the database query. In response, the merchant/acquirer database may provide the requested payment gateway address (e.g., 1610). The merchant server may forward the card authorization request to the payment gateway server by using the provided address. In some embodiments, upon receiving a card authorization request from a merchant server, the payment gateway server may invoke a component to provide one or more services associated with purchase transaction authorization (e.g., 1611). For example, the payment gateway server may invoke components for fraud prevention (see, e.g., chat verification, fig. 3E), loyalty and/or rewards, and/or other services for which the user-merchant combination is authorized.

The payment gateway server may forward the card authorization request to the payment network server for payment processing (e.g., 1614). For example, the payment gateway server may be able to select from a payment network such as Visa, Mastercard, American Express, Paypal, etc. to handle various types of transactions including, but not limited to: credit card, debit card, prepaid card, B2B, and the like. In some embodiments, the payment gateway server may query a database (e.g., 1612) for the network address of the payment network server, for example, by using the user payment card number or user ID (such as an email address) as a key for the database query. In response, the payment gateway database may provide the requested payment network address (e.g., 1613). The payment gateway server may forward the card authorization request (e.g., 1614) to the payment network server by using the provided address.

Referring to fig. 16B, in some embodiments, the payment network server may process the transaction in order to transfer funds for the purchase into an account stored on the acquirer for the merchant. For example, the acquirer may be a financial institution that maintains the merchant's account. For example, the proceeds of a transaction processed by a merchant may be deposited into an account maintained by a server of the acquirer. In some embodiments, the payment network server may generate a query (e.g., 1615) for the issuer server corresponding to the payment option selected by the user. For example, the user's account may be linked to one or more issuer financial institutions (issuers), such as banking institutions, that issue the user's account. For example, such accounts may include, but are not limited to: credit cards, debit cards, prepaid cards, checks, savings, money markets, deposit slips, stored (cash) value accounts, and the like. The issuer server of the issuer maintains details of the user's account. In some embodiments, a database (e.g., a payment network database) may store details of an issuer server associated with an issuer. In some embodiments, the payment network server may query a database (e.g., 1615) for the issuer server's network address, for example, by using the user payment card number or user ID (such as an email address) as a key for the database query.

In response to obtaining the issuer server query, the payment network database may provide the requested issuer server data (e.g., 1616) to the payment network server. In some embodiments, for each of the issuer servers selected based on predefined payment settings associated with the user's virtual wallet, and/or payment option inputs by the user, the payment network server may utilize the issuer server data to generate a funding authorization request (e.g., 1617) and provide the funding authorization request to the issuer server. In some embodiments, the funding authorization request may include details such as, but not limited to: the cost of the user involved in the transaction, the card account details of the user, the user's bill and/or shipping information, etc. In some embodiments, the issuer server may parse the authorization request (e.g., 1618) and, based on the request details, may query a database (e.g., 1619) for data associated with the account linked to the user.

In some embodiments, when obtaining user account data (e.g., 1620), the issuer server may determine whether the user may pay for a transaction by using funds available in the account (e.g., 1621). For example, the issuer server may determine whether the user has sufficient balance remaining in the account, sufficient credit associated with the account, etc. Based on the determination, the issuer server may provide a funding authorization response (e.g., 1622) to the payment network server. In some embodiments, if the at least one issuer server determines that the user cannot pay for the transaction by using funds available in the account, the payment network server may again request payment options from the user (e.g., by providing an authorization failure message to the user device and requesting the user device to provide new payment options), and again attempt authorization for the purchase transaction. In some embodiments, if the number of failed authorization attempts exceeds a threshold, the payment network server may abort the authorization process and provide an authorization failure message to the merchant server, the user device, and/or the client.

In some embodiments, the payment network server may obtain a funding authorization response that includes a notification of successful authorization and parse the message to extract authorization details. When it is determined that the user has sufficient funds (e.g., 1623) for the transaction, the payment network server may invoke a component to provide value added services (e.g., 1623) to the user.

In some embodiments, the payment network server may forward the transaction authorization response to the user wallet device, PoS client, and/or merchant server. The merchant may parse the transaction authorization response (e.g., 1624) and determine from it that the user has sufficient funds in the card account to conduct the transaction (e.g., 1625 option yes). The merchant server may add a record of the transaction for the user to a collection of transaction data related to the authorized transaction. For example, the merchant may add XML data related to user transactions to an XML data file (e.g., 1626) containing XML data for transactions for which the respective user has been authorized, and store the XML data file (e.g., 1627) in a database. In some embodiments, the server may also generate a purchase receipt (e.g., 1628) and provide the purchase receipt to the client. The client may present and display the purchase receipt (e.g., 1629) for the user. In some embodiments, the user's wallet device may also provide notification of successful authorization to the user. For example, the PoS client/user device may render web pages, electronic messages, text/SMS messages, buffer voice mails, make ring tones, and/or play audio messages, etc., and provide outputs including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a client device capable of vibrating, such as a smartphone), and the like.

17A-B show data diagram intents that illustrate example aspects of converting merchant transaction batch data queries into updated Payment general ledger (leger) records via a purchase transaction clearing ("PTC") component. Referring to FIG. 17A, in some embodiments, a merchant server (e.g., 1703 a) may initiate clearing of a set of authorized transactions. For example, the merchant server may generate a bulk data request (e.g., 1711) and provide the request to a merchant database (e.g., 1703 b). For example, the merchant server may query the relational database using PHP/SQL commands similar to the examples provided above. In response to the batch data request, the database may provide the requested batch data (e.g., 1712). The server may generate a batch clearing request (e.g., 1713) by using the batch data obtained from the database and provide the batch clearing request (e.g., 1714) to the acquirer server (e.g., 1707 a). For example, the merchant server may provide an http(s) POST message to the acquirer server that includes XML formatted bulk data in the message body. The acquirer server may generate a bulk payment request (e.g., 1715) by using the acquired bulk clearing request, and provide the bulk payment request (e.g., 1718) to the payment network server (e.g., 1705 a). The payment network server may parse the bulk payment request and extract transaction data (e.g., 1719) for each transaction stored in the bulk payment request. The payment network server may store transaction data (e.g., 1720) for each transaction in a database (e.g., payment network database 1705 b). In some embodiments, the payment network server may invoke a component to provide a value added analysis service that is based on an analysis of the transaction of the merchant that the VWCS cleared the purchase transaction. Thus, in some embodiments, the payment network server may provide analytics-based value-added services to the merchant and/or the user of the merchant.

Referring to fig. 17B, in some embodiments, for each extracted transaction, the payment network server may query a database (e.g., payment network database 1705B), e.g., 1723, for the address of the issuer server. For example, the payment network server may utilize PHP/SQL commands similar to the examples provided above. The payment network server may generate a single payment request (e.g., 1725) for each transaction for which transaction data has been extracted and provide the single payment request (e.g., 1725) to the issuer server, e.g., 1706 a. For example, the payment network server may provide a single payment request to the issuer server as an http(s) POST message that includes data in XML format. An example listing of a single payment request 1725 substantially in the form of an http(s) POST message (which includes XML formatted data) is provided below:

in some embodiments, the issuer server may generate the payment command (e.g., 1727). For example, the issuer server may issue a command to deduct funds from the user's account number (or add a fee to the user's credit card account). The issuer server may issue a payment command (e.g., 1727) to a database (e.g., user profile database 1706 b) that stores account information for the user. The issuer server may provide a single payment confirmation (e.g., 1728) to the payment network server, which may forward the funds transfer message (e.g., 1729) to the acquirer server. An example listing of a single payment confirmation 1728, substantially in the form of an http(s) POST message (which includes XML formatted data) is provided below:

in some embodiments, the acquirer server may parse a single payment confirmation and correlate the transaction with the merchant ((e.g., using the request _ ID field in the example above) the acquirer server may then transfer the funds specified in the funds transfer message to the merchant's account. for example, the acquirer server may query the acquirer database 1707b (e.g., 1730) for payment ledger and/or merchant account data (e.g., 1731). the acquirer server may utilize the payment ledger and/or merchant account data from the acquirer database, along with the single payment confirmation, to generate updated payment ledger and/or merchant account data (e.g., 1732). the acquirer server may then store the updated payment ledger and/or merchant account data to the acquirer database (e.g., 1733).

18A-B show a logic flow diagram illustrating example aspects of converting merchant transaction batch data queries into updated payment general ledger records via a purchase transaction clearing ("PTC") component. Referring to FIG. 18A, in some embodiments, the merchant server may initiate clearing of a batch of authorized transactions. For example, the merchant server may generate a batch data request (e.g., 1801) and provide the request to the merchant database. In response to the batch data request, the database may provide the requested batch data (e.g., 1802). The server may generate a batch clearing request (e.g., 1803) by using the batch data obtained from the database and provide the batch clearing request to the acquirer server. The acquirer server may parse the acquired bulk clearing request (e.g., 1804) and generate a bulk payment request (e.g., 1807) by using the acquired bulk clearing request to provide the bulk payment request to the payment network server. For example, the acquirer server may query the acquirer server (e.g., 1805) for the address of the payment network server and use the acquired address to forward the generated batch payment request to the payment network server (e.g., 1806).

The payment network server may parse the batch payment request obtained from the acquirer server and extract transaction data (e.g., 1808) for each transaction stored in the batch payment request. The payment network server may store transaction data for each transaction in a payment network database (e.g., 1809). In some embodiments, the payment network server may invoke a component to provide analysis of the merchant's transaction based on the purchase transaction being cleared.

Referring to fig. 18B, in some embodiments, for each extracted transaction, the payment network server may query a payment network database (e.g., 1811) for the address of the issuer server. The payment network server may generate a single payment request (e.g., 1813) for each transaction for which transaction data has been extracted and provide the single payment request to the issuer server. In some embodiments, the issuer server may parse a single payment request (e.g., 1814) and generate a payment order based on the parsed single payment request (e.g., 1815). For example, the issuer server may issue a command to deduct funds from the user's account (or add a fee to the user's credit card account). The issuer server may issue payment commands (e.g., 1815) to a database (e.g., a user profile database) that stores account information for the user. The issuer server may provide a single payment confirmation (e.g., 1817) to the payment network server, which may forward the single payment confirmation (e.g., 1818) to the acquirer server.

In some embodiments, the acquirer server may resolve a single payment confirmation and associate the transaction with the merchant (e.g., by using the request _ ID field in the above example). The acquirer server may then transfer the funds specified in the funds-transfer message to the merchant's account. The acquirer server may query an acquirer database (e.g., 1819) for payment ledger and/or merchant account data (e.g., 1820). The acquirer server may utilize the payment ledger and/or merchant account data from the acquirer database along with a single payment confirmation to generate updated payment ledger and/or merchant account data (e.g., 1821). The acquirer server may then store the updated payment ledger and/or merchant account data to an acquirer database (e.g., 1822).

VWCS controller

Fig. 19 shows a block diagram illustrating exemplary aspects of the VWCS controller 1901. In this embodiment, the VWCS controller 1901 may be used to aggregate, process, store, search, service, identify, indicate, generate, match, and/or facilitate interaction with a computer, and/or other related data through various techniques.

A user (e.g., 1933 a), which may be a person and/or other system, may participate in an information technology system (e.g., a computer) to facilitate information processing. In turn, computers use processors to process information; such a processor 1903 may be referred to as a Central Processing Unit (CPU). One form of processor is known as a microprocessor. The CPU utilizes a communication circuit (communicating circuit) to transfer binary-coded signals used as instructions to enable various operations. These instructions may be operational instructions and/or data instructions that contain and/or relate to other instructions and data in various processor-accessible and operational areas of memory 1929 (e.g., registers, cache memory, random access memory, etc.). Such communication instructions may be stored and/or transmitted in batches (e.g., batch instructions) as program and/or data components to facilitate the desired operations. These stored instruction codes (e.g., programs) may participate in the CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, which is executable on a computer by a CPU; the operating system allows and facilitates user access to and operation of computer information technology and resources. Some resources that may be used in an information technology system include: input and output mechanisms by which data may be transferred to and from a computer; a memory in which data may be stored; and a processor where information may be processed. These information technology systems can be used to collect data for later retrieval, analysis, and manipulation, which can be facilitated by database programs. These information technology systems provide interfaces that allow users to access and operate various system components.

In an embodiment, the VWCS controller 1901 may connect and/or communicate with an entity. These entities include, but are not limited to: one or more users from user input devices 1911; peripheral devices 1912, an optional cryptographic processor device 1928, and/or a communication network 1913. For example, VWCS controller 1901 may connect and/or communicate with a user (e.g., 1933 a), operating client devices (e.g., 1933 b) including, but not limited to: personal computers, servers, and/or various mobile devices including, but not limited to: a cellular telephone, a smart phone (e.g.,android OS based phones, etc.), tablet computers (e.g., Apple iPad)^TM，HP Slate^TM，MotorolaXoom^TMEtc.), e-book reader (e.g., Amazon Kindle)^TM，Barnes andNoble’s Nook^TMElectronic reading deviceReader, etc.), laptop, notebook, netbook, game console (e.g., XBOX Live)^TM，DS，SonyPortable, etc.), Portable scanners, etc.

A network is generally considered to contain the interconnections and inter-working between clients, servers, and intermediate nodes in a graphical topology. It should be noted that the term server as used throughout this application generally refers to a computer, other device, program, or combination thereof that responds to and processes requests of remote users over a communication network. The server supplies its information to the requesting client. The term client, as used herein, generally refers to a computer, program, other device, user, and/or combination thereof capable of processing and making requests and obtaining and processing any responses from a server over a communication network. Computers, other devices, programs, or combinations thereof that facilitate, process, and request the communication of information and/or information from a source user to a destination user are often referred to as nodes. Networks are generally thought to facilitate the transfer of information from a source point to a destination. Nodes that are specifically tasked with facilitating the transfer of information from a source to a destination are often referred to as routers. There are many forms of networks, such as Local Area Networks (LANs), piconets, Wide Area Networks (WANs), wireless networks (WLANs), and so on. For example, the internet is generally considered to be an interconnection of multiple networks through which remote clients and servers can access and interoperate with each other.

The VWCS controller 1901 may be based on a computer system that includes, but is not limited to, components such as the computer systemization 1902 connected to a memory 1929.

Computerisation

Computer systemization 1902 may include a clock 1930, a central processing unit (CPU and/or processor (unless otherwise stated these terms are used interchangeably throughout the present invention)) 1903, a memory 1929 (e.g., Read Only Memory (ROM) 1906, Random Access Memory (RAM) 1905, etc.), and/or an interface bus 1907, and most often, although not necessarily, all interconnected and communicating via a system bus on (host) board 1902 having one or more electrically conductive and/or other transmissive circuit paths through which instructions (e.g., binary encoded signals) may travel to effectuate communication, operation, storage, etc. The computer systemization may be connected to a power supply 1986, for example, the power supply may be built in, optionally. Optionally, a crypto processor 1926 and/or a transceiver (e.g., ICs) 1974 may be coupled to the system bus. In another embodiment, the crypto processor and/or transceiver may be connected as an internal and/or external peripheral device 1912 through the interface bus I/O. Further, the transceiver may be connected to an antenna 1975, thereby performing wireless transceiving of various communication and/or sensor protocols; for example, the antenna may be connected to: a Texas device's WiLinkWL1283 transceiver chip (e.g., providing 802.11n, Bluetooth 3.0, FM, Global Positioning System (GPS) (thus allowing a VWCS controller to determine its location)), a Broadcom BCM4329FKUBG transceiver chip (e.g., providing 802.11n, Bluetooth 2.1+ EDR, FM, etc.), BCM28150(HSPA +) and BCM2076 (Bluetooth 4.0, GPS, etc.), a Broadcom BCM4750IUB8 transceiver chip (e.g., GPS), an Infineon Technologies X-Gold618-PMB9800 (e.g., providing 2G/3GHSDPA/HSUPA communications), Intel's XMM7160(LTE & DC-HSPA), high-throughput CDMA (2000), Mobile data/station Modem, Snapdagon, etc. The system clock may have a crystal oscillator and generate a reference signal through a circuit path that is systematized by the computer. The clock may be coupled to the system bus and to various clock multipliers that increase or decrease the reference operating frequency of other interconnected components in the computer systemization. Clocks and various components in computer systematization cause signals containing information to be transmitted in a computer system. Such sending and receiving of instructions containing information in a computer system may be referred to as communication. Further, these communication instructions may be transmitted, received, and cause the return and/or reply communication outside of the instant computer systemization to: communication networks, input devices, other computer systemations, peripheral devices, and the like. It will be appreciated that in alternative embodiments, any of the components mentioned above may be directly connected to each other, to the PCU and/or in various organizations as exemplified by various computer systems.

The CPU includes at least one high-speed data processor capable of executing program components to perform user and/or system generated requests. Typically, the processor itself will incorporate various specific processing units such as, but not limited to: floating point arithmetic units, integer processing units, integrated system (bus) processors, logical operations units, memory management control units, etc., and even more specific processing subunits such as image processing units, digital signal processing units, etc. Further, the processor includes, in addition to the processor itself, an internal fast-access addressable memory, mappable and addressable memory 1929; internal memory may include, but is not limited to: fast registers, various levels of buffer memory (e.g., levels 1, 2, 3, etc.), RAM, etc. The processor may access this memory using a memory address space accessible by instruction addresses, where the processor may build and decode to allow access to a circuit path controlled by a particular memory address having a memory state/value. The CPU may be a microprocessor, for example: athlon, Duron and/or Opteron, AMD, Classic, ARM (e.g., ARM7/9/11), Embedded (Coretx-M/R), application (Cortex-A), Embedded secure processors, Dragon ball and PowerPC, IBM and/or Motorola, cellular processors, Intel Atom, Celeron (Mobile), Core (2/Duo/i3/i5/i7), Itanium, Pentium, Xeon, and/or XScale, processors. Such instruction transfer facilitates communication both inside and outside the VWCS controller via various interfaces. Distributed processor (e.g., distributed VWCS), host, multi-core, parallel, and/or supercomputer architectures may similarly be employed if faster speed and/or power is required to process the request. Alternatively, smaller mobile devices (e.g., cell phones, Personal Digital Assistants (PDAs), etc.) may be employed if more portability is required for the deployment request.

Depending on the particular implementation, the characteristics of the VWCS may be achieved by implementing a microprocessor such as a CAST's R8051XC2 microprocessor, Intel's MCS51(i.e., 8051 microprocessor), etc. Furthermore, to implement certain features of the VWCS, some features may be implemented by means of embedded components, such as: t application specific integrated circuits ("ASICs"), digital signal processing ("DSPs"), field programmable memories ("FPGAs"), and the like. For example, any of the set of VWCS components (distributed or otherwise) and/or the characteristics implemented by the microprocessor and/or embedded components; e.g., by ASIC, coprocessor, DSP, FPGA, etc. Alternatively, some implementations of the VWCS may be implemented with embedded components configured and used to implement a number of features and signal processing.

Depending on the particular implementation, the embedded components may include software, hardware, and/or a combination of software/hardware. For example, the VWCS features discussed herein may be achieved by implementing FPGAs, which is a programmable semiconductor device including programmable logic elements called "logic blocks" and programmable interconnects, such as the high performance FPGA Virtex family and/or the low cost Spartan family manufactured by Xilinx. After the FPGA is manufactured, the logic blocks and interconnect blocks may be programmed by a customer or designer to implement any of the features of the VWCS. A programmable interconnectable hierarchy allows the logic blocks to be interconnected as required by the VWCS system designer/administrator, similar to a single chip programmable circuit lab board. An FPGA logic block can be programmed to perform basic logic gate operations such as and, or more complex joint operations such as decoding or simple mathematical operations. In multiple FPGAs, the logic blocks also include memory components, which may be latch circuits or multiple integral blocks of memory. In some cases, the VWCS can be developed on a conventional FPGA and then ported to a fixed version more like an ASIC. Alternative or equivalent implementations may also port the VWCS controller features to a final ASIC as an alternative or in addition to the FPGAs. By virtue of all the implementations mentioned above, the embedded components and the microprocessor may be considered as "CPU" and/or "processor" of the VWCS.

Power supply

Power supply 1986 may be of any standard form for powering small electronic circuit board devices, for example, including the following batteries: alkaline, lithium hydride, lithium polymer, nickel cadmium, solar cells, and the like. Other types of ac or dc power sources may be used. In one embodiment, in the case of a solar cell, the housing provides an aperture through which the solar cell can extract light energy. Battery 1986 is connected to any of the following components of the interconnected VWCS to provide current to all interconnected components. In one embodiment, power supply 1986 is connected to system bus component 1904. In an alternative embodiment, external power 1986 is provided by interfacing with I/O1908. For example, a USB and/or IEEE1394 connection carries both data and power over the connection and is therefore a suitable power source.

Interface adapter

The interface bus 1907 may receive, connect and/or communicate with a plurality of interface adapters, typically, although not necessarily, in the form of adapter cards such as, but not limited to: input output interfaces (I/O) 1908, storage interfaces 1909, network interfaces 1910, and the like. Optionally, a crypto processor interface 1927 may similarly be connected to the interface bus. The interface bus provides communication between interface adapters and other components in the computer systemization. The interface adapter is adapted to a compatible interface bus. The interface adapter may be connected to the interface bus via an expansion and/or slot fabric. Different expansion and/or slot configurations may be employed, such as but not limited to: accelerated Graphics Port (AGP), card bus, ExpressCard, (extended) industry standard architecture ((E) ISA), Micro Channel Architecture (MCA), NuBus, parallel component interconnect (extended) (pci (x)), pci express, Personal Computer Memory Card International Association (PCMCIA), Thunderbolt, and the like.

The storage interface 1909 may receive, communicate, and/or connect with a plurality of storage devices, such as, but not limited to: storage devices 1914, removable disk devices, etc. The storage interface may employ a connection protocol such as, but not limited to: (advanced) advanced technology attachment (packet interface) (Ultra) ata (pi), (enhanced) integrated circuit devices ((E) IDE), Institute of Electrical and Electronics Engineers (IEEE)1394, ethernet, fibre channel, Small Computer System Interface (SCSI), Thunderbolt, Universal Serial Bus (USB), and the like.

The network interface 1910 may receive, communicate with, and/or connect with a communication network 1913. Through the communications network 1913, a user 1933a may access the VWCS controller through a remote client 1933b (e.g., a computer with a web browser). The network interface may employ a connection protocol such as, but not limited to: direct connections, ethernet (thick, thin, twisted pair 10/100/1000Base T, etc.), token ring, wireless connections such as ieee802.11a-x, etc. If faster speed and/or capability is required to process the request, the distributed network controller (e.g., distributed VWCS) architecture will similarly be used for pooling, load balancing, and/or other enhancements to the communication bandwidth required by the VWCS controller. The communication network may be any one and/or combination of: direct interconnects, the Internet, Local Area Networks (LANs), Metropolitan Area Networks (MANs), operational tasks as nodes in the Internet (OMNIs), secure customer connections, Wide Area Networks (WANs), wireless networks (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.), and the like. A network interface may be considered a particular form of input-output interface. Still further, multi-network interface 1910 may be used with various communication network forms 1913. For example, a multi-network interface may be employed to allow communication over broadcast, multicast, and/or unicast networks.

Input output interface (I/O) 1908 may receive, communicate, and/or connect to user input devices 1911, peripheral devices 1912, crypto-processor devices 1928, etc., the I/O may employ a connection protocol such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, etc.; data: apple Desktop Bus (ADB), Bluetooth, IEEE1394a-b, serial, Universal Serial Bus (USB), infrared, joystick, keyboard, digital audio, optical, PC AT, PS/2, parallel, radio, video interface, Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, display port, Digital Visual Interface (DVI), High Definition Multimedia Interface (HDMI), RCA, radio frequency antenna, S video, VGA, etc., wireless transceiver, 802.11a/b/g/n/x, Bluetooth, cellular (e.g., Code Division Multiple Access (CDMA), high speed packet Access technology (HSPA (+), high speed Downlink packet Access technology (HSDPA), Global System for Mobile communications (GSM), Long Term Evolution (LTE), WiMax, etc.), and the like. The output device may be a video display screen, which may be based on a Cathode Ray Tube (CRT), Liquid Crystal Display (LCD), Light Emitting Diode (LED), Organic Light Emitting Diode (OLED), plasma, etc. form of monitor having an interface capable of receiving signals from a video interface (e.g., VGA, DVI line cable). The video interface synthesizes information generated by the computer systematized and generates a video signal based on the synthesized information in the video memory frame. Another output device is a television set which receives signals from a video interface. Typically, the video interface provides the composed video information via a video connection interface that accepts a video display interface (e.g., an RCA composite video connector that accepts RCA composite video cable, a DVI connector that accepts DVI display cable, HDMI, etc.).

User input device 1911 is typically in the form of a peripheral device 1912 (see below), which may include: card readers, dongles, fingerprint readers, graphic tablets, joysticks, keyboards, microphones, mice, remote controls, retinal readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, touch pads, sensors (e.g., accelerometers, backlights, GPS, gyroscopes, proximity networks, etc.), styluses, and the like.

Peripheral devices 1912 may be coupled to and/or communicate with I/O and/or other similar devices, such as a network interface, a memory interface, a direct connection to an interface bus, a system bus, a CPU, and the like. The peripheral devices may be external, internal and/or part of the VWCS control. The peripheral device may include: an antenna, an audio device (e.g., incoming line, outgoing line, microphone input, speaker, etc.), a camera (e.g., still, video, webcam, etc.), a dongle (e.g., for copy protection, secure transactions with digital signatures, etc.), an external processor (for additional capabilities, e.g., encryption device 1928), a force feedback device (e.g., vibration motor, etc.), a Near Field Communication (NFC) device, a network interface, a printer, Radio Frequency Identification (RFID), a scanner, a storage device, a transceiver (e.g., cellular, GPS, etc.), a video device (e.g., goggles, monitors, etc.), a video source, armor, etc. The peripheral factory includes various types of input devices (e.g., microphones, cameras, etc.).

It should be noted that although user input devices and peripheral devices may be employed, the VWCS controller may be implemented as an embedded, dedicated, and/or monitor-less (e.g., headless) device, wherein access may be provided through a network interface connection.

Cryptographic units, such as, but not limited to, a microprocessor, processor 1926, interface 1927, and/or device 1928, may be attached to and/or in communication with the VWCS controller. The MC68HC16 microcontroller, manufactured by motorola, inc, can be used in and/or in the decryption unit. The MC68HC16 microcontroller utilizes 16-bit multiply and accumulate computation instructions in a 16MHZ configuration that requires less than one second to perform 512-bit RSA private key operations. The encryption unit supports communication authorization from the interaction agent and also allows anonymous transactions. The encryption unit may also be configured as part of the CPU. Equivalent microprocessors and/or processors may also be utilized. Other commercially available specialized encryption processors include: examples of security processors include, but are not limited to, Broadcom's CryptoNetX and other security processors, nShield by nCipher (e.g., Solo, Connect, etc.), the Luna PCI (e.g., 7100) series by SafeNet, 40MHz Roadrunner184 by Semaphor communications, sMIP (e.g., 208956), Sun's crypto accelerators (e.g., Acceler 6000PCIe board, Acceler 500Daughtercard), Via Nano processor (e.g., L2100, L2200, U2400) lines capable of executing 500+ MB/s crypto instructions, VLSI Technology 33MHz6868, etc.

Memory device

Generally, any mechanism and/or implementation that allows a processor to affect the storage and/or retrieval of information is referred to as memory 1929. However, memory is an alternative technology and resource, and thus any number of memory implementations may be used interchangeably with one another. It is to be appreciated that the VWCS controller and/or the computer systemization can employ various forms of memory 1929. For example, computer systematization may be configured as on-chip CPU memory (e.g., registers), RAM, ROM, and other storage devices, with the operation provided by a punched paper tape or paper punched card mechanism, but such implementation may result in a substantially lower operating speed. In one configuration, the memory 1929 may include ROM1906, RAM1905, and storage devices 1914. The storage devices 1914 may employ any number of computing storage devices/systems. The storage device may include a drum, a disk drive (fixed and/or removable); a magneto-optical drive, an optical drive (e.g., Blu-ray, CD ROM/RAM/recordable (R)/Rewritable (RW), DVD R/RW, HD DVD R/RW, etc.); other processor-readable storage media; and/or the like. Thus, computer systematization generally requires and uses memory.

Component collections

Memory 1929 may include a collection of programs and/or database components and/or data such as, but not limited to: an operating system component 1915, (operating system), an information server component 1916 (information server); a user interface component 1917 (user interface); a web browser component 1918 (web browser); a database 1919; a mail server component 1921; mail client component 1922; an encryption server component 1920 (encryption server); VWCS components 1935, and so on (e.g., a collection of components as a whole). These components may be stored from a storage device and/or accessed from a storage device via an interface bus. While non-traditional program components, such as those in the collection of components, may be stored in the local storage device 1914, they may also be loaded from and/or stored in a memory, such as: peripheral devices, RAM, remote memory devices over a communications network, ROM, various forms of memory, and the like.

Operating system

The operating system component 1915 is an executable program component that can facilitate operation of the VWCS controller. Operating systems may facilitate access to I/O, network interfaces, peripherals, storage devices, and the like. The operating system may be a highly fault-tolerant, extensible, and secure system, such as: apple's Macintosh OS X (Server), AT & T, Inc. project 9, the BE operating system, versions of Unix and Unix-like systems (e.g., AT & T UNIX; various Berkeley school software (BSD) s, e.g., FreeBSD, NetBSD, OpenBSD, etc., Linux releases, e.g., Red hat, Ubuntu, etc.), and/or the like. However, more restrictive and/or less secure operating systems may be employed, such as apple's Macintosh OS, IBM's OS/2, Microsoft's DOS, Microsoft's hungry Windows2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Server), Palm operating system, and the like. In addition, Mobile operating systems such as iOS for apple, Android for Google, WebOS for Hewlett packard, Windows Mobile for Microsoft, etc. may be used. Any of these operating systems may be embedded in the hardware of the NICK controller and/or stored/loaded into memory/storage. The operating system contracts with other components in the set of components, including itself, etc. Most often the operating system communicates with other program components, user interfaces, etc. For example, the operating system may include: communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, is capable of interacting with communication networks, data, I/O, peripheral devices, program components, memory, user input devices, and the like. The operating system may provide a communication protocol that allows the VWCS controller to communicate with other entities over the communication network 1913. The VWCS controller may use various communication protocols as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, etc.

Information server

The information server component 1916 is a stored program component that is executed by the CPU. The information server may be an internet information server such as, but not limited to, Apache of the Apache software foundation, microsoft's internet information server, etc. The information server may pass tools to allow execution of the program components. These tool Activity Server Pages (ASP), ActiveX, (ANSI) (Objective-) C (+ +), C # and/or NET, Common Gateway Interface (CGI) scripts, dynamic (D) HyperText markup language (HTML), animations, Java, JavaScript, Practical Extraction Report Language (PERL), HyperText preprocessor (PHP, pipe, Python, Wireless Application Protocol (WAP), WebObjects, etc. information servers may support secure communication protocols such as, but not limited to, File Transfer Protocol (FTP), HyperText transfer protocol (HTTP), secure HyperText transfer protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., instant messenger for American Online (AOL) (AIM), iMessage for apple, application exchange (APEX), ICQ, Internet Relay (IRC), Microsoft network (MSN) messenger services, presence and instant messaging Protocols (PRIM), session Initiation Protocol (SIP) of Internet Engineering Task Force (IETF), SIP for instant messaging and presence utilization extensions (simple), open XML-based extensible messaging and presence protocol (XMPP) (e.g., Instant Messaging and Presence Services (IMPS) of Jabber or Open Mobile Alliance (OMA)), instant messenger services of yahoo, etc. The information server provides results in the form of Web pages to a Web browser and allows the generation of Web pages to be manipulated by interacting with other program components. When the Domain Name System (DNS) resolution part of an HTTP request is resolved to a specific information server, the information server resolves the request based on the remaining part of the HTTP request to obtain information at a specified location in the VWCS controller. For example, a request such as http://123.124.125.126/myinformation. html may have the IP portion of the request "123.124.125.126" resolved by the DNS server to the information server with the IP address; the information server may further parse the "/myinformation. In addition, other information service protocols may be employed through the various ports, such as FTP communication through port 21, and the like. The information server may communicate with other components in the collection of components, including itself, or similar implementations, etc. Most often, the information server communicates with the VWCS database 1919, the operating system, other program components, the user interface, the Web browser, etc.

Access to the VWCS database may be accomplished through a number of database bridge mechanisms, such as through a communication channel between the scripting language (e.g., CGI) and the application, listed below (e.g., CORBA, WebObjects, etc.). Any data request initiated by the Web browser is parsed by the bridge mechanism into the appropriate syntax required by the VWCS. In one embodiment, the information server will provide a Web form that is accessible by a Web browser. The input fields provided in the Web form are marked as requiring entry into a particular domain, as is the parsing process. The entered condition is then passed along with the field tag to instruct the parser to generate a query directed to the appropriate table and/or field. In one embodiment, the parser will generate a standard SQL query based on the tagged text input by instantiating a search string with the appropriate join/select command, where the result command is provided as a query through the bridge mechanism to the VWCS. Once the query results are generated from the query, the results are transmitted through the bridge ring and are parsed by the bridge mechanism to format and produce new result web pages. This new resulting web page is then provided to the information server, which provides the resulting web page to the requesting web browser.

The information server may also include, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

User interface

The computer interface is similar in some respects to the operating interface of an automobile. The automobile operation interface elements such as a steering wheel, a gear shifting and a speedometer are convenient to access, operate and display automobile resources and states. Computer interactive interface elements such as checkboxes, cursors, menus, scroll bars and windows (commonly referred to collectively as widgets) also facilitate access, capabilities, operations and display of data, computer applications, operating system resources and states. The operation interface is generally referred to as a user interface. Graphical User Interfaces (GUIs) such as those available for Aqua and iOS of the apple Macintosh operating system, OS/2 of IBM, Android phone user interface of google, Windows2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/XP/Vista/7/8 (e.g., aviation, subway), X-Windows of Unix (e.g., where additional Unix graphical interface libraries and layers such as the K Desktop Environment (KDE), MythTV, and GNU web object model environment (GNOME)) web interface libraries (e.g., ACTIVEX, axx, (D) HTML, FLASH, Java, JavaScript, etc., interface libraries such as, but not limited to, Dojo, jquery (ui), MooTools, prototypes, script.

User interface component 1917 is a stored program component that is executed by the CPU. The user interface may be a graphical user interface provided by the operating system and/or operating environment as already discussed and/or on top. The user interface may be implemented textually and/or graphically to allow display, execution, interaction, manipulation, and/or operation of the program components and/or system devices. The user interface may provide convenience through which a user may influence, interact with, and/or operate a computer system. The user interface may communicate with other components in the collection of components, including itself, and/or similar devices, etc. Most often, the user interface communicates with an operating system, other program components, and the like. The user interface may include communications, generation, retrieval, and/or provision of program components, systems, users, and/or data communications, requests, and/or responses.

Web browser

The web browser component 1918 is a stored program component that is executed by the CPU. The Web browser may be a hypertext viewing application such as google's (mobile) Chrome browser, microsoft IE, netscape browser, apple (mobile) Safari browser, embedded Web browser objects such as cocoa (touch) objects through apple, etc. The secure web browser may provide 128-bit (or greater) encryption through HTTPS, SSL, etc. Web browsers allow program components to be executed by tools such as ActiveX, AJAX, (D) HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., Chrome browser, firefox, IE browser, Safari browser plug-in, and the like). Web browsers and similar information access tools may be integrated into palm top computers, cellular telephones, smart phones, and/or other mobile devices. The Web browser may communicate with other components in the collection of components, including itself, and/or similar devices, etc. Most often, a Web browser and information server, an operating system, an integrated program component (e.g., a plug-in), etc.; for example, it may involve communicating, generating, obtaining, and/or providing program components, systems, users, and/or data communications, requests, and/or responses. Further, instead of a web browser and an information server, a federated application may be developed to perform similar operations for both. The federated application also affects the acquisition and provision of information from the VWCS assembly node to the user, user agent, etc. The joint application will behave as a dummy on systems that employ standard web browsing.

Mail server

Mail server component 1921 is a stored program component executed by CPU 1903. The mail server may be an internet mail server such as, but not limited to, apple mail server (3), dovect, sendmail, Microsoft Exchange, etc. The mail server may allow program components to be executed by tools such as ASP, ActiveX, (ANSI) (Objective-) C (++), C # and/or. NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and the like. The mail server supports communication protocols such as, but not limited to: internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP 3), Simple Mail Transfer Protocol (SMTP), and the like. The mail server may route, forward and process incoming and outgoing mail information that has been sent, relay and/or otherwise traverse and/or reach the VWCS.

VWCS mail may be accessed through multiple APIs provided by various web servers and/or operating systems.

The mail server may also include, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, information, and/or responses.

Mail client

Mail client component 1922 is a stored program component executed by CPU 1903. The email client may be an email viewing application such as apple (cell phone) email, Microsoft environment, Microsoft Outlook Express, Mozilla, Thunderbird, etc. The mail client may support multiple transport protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, etc. A mail client may communicate with other components in a collection of components, including itself, and/or similar devices. Most often, the mail client communicates with a mail server, operating system, other mail clients, and the like; for example, it may involve communicating, generating, obtaining, and/or providing program components, systems, users, and/or data communications, requests, information, and/or responses. Generally, a mail client provides a tool to compose and send an email.

Encryption server

The crypto server component 1920 is a stored program component that is executed by the CPU1903, crypto processor 1926, crypto processor interface 1927, crypto processor device 1928, and the like. The encryption processor interface allows the encryption component to expedite encryption and/or decryption requests, however, the encryption component may alternatively run on the CPU. The encryption component allows for encryption and/or decryption of the provided data. The encryption component allows for symmetric and asymmetric (e.g., good protection (PGP)) encryption and/or decryption. The encryption component may employ encryption techniques such as, but not limited to: digital certificates (e.g., x.509 certificate authority), digital signatures, double signatures, envelopes, cryptographic access protection, public key management, and the like. The encryption component enables the facilitation of numerous (encryption and/or decryption) security protocols, such as, but not limited to: verification, Data Encryption Standard (DES), elliptic curve Encryption (ECC), International Data Encryption Algorithm (IDEA), message digest 5 (MD 5, which is a one-way hash operation), cipher, Rivest encryption (RC 5), Rijndael algorithm, RSA (which is an internet encryption and authentication system that uses algorithms developed in 1977 by Ron Rivest, Adi Shamir and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), secure hypertext transfer protocol (HTTPS), etc. With such an encryption security protocol, the VWCS encrypts all incoming and/or outgoing communications and may act as a node in a Virtual Private Network (VPN) with a broader communication network. The cryptographic component facilitates a process of "secure authentication" in which access to a resource is restricted by a security protocol, wherein a cryptographic group affects authorized access to the secure resource. In addition, the encryption component may provide a unique identifier for the content, for example, using an MD5 hash to obtain a unique signature for a digital audio file. The cryptographic component may communicate with other components in the set of components, including itself, and/or similar devices, etc. The encryption component supports an encryption scheme that allows secure transmission of information in the communication network, if desired, to enable the VWCS component to conduct secure transactions. The encryption component facilitates secure access to resources on the VWCS and to secure resources on a remote system, i.e. it may act as a client and/or server of the secure resources. Most often, the encryption component communicates with an information server, operating system, other program components, and the like. The cryptographic components may contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

VWCS database

The VWCS database component 1919 may be implemented as a database and the data it stores. The database is a stored program component that is executed by the CPU. The stored program component part configures the CPU to process the stored data. The database may be any of a number of fault-tolerant, relational, extensible, and secure databases, such as DB2, MySQL, Oracle, SYBASE, and the like. A relational database is an extension of a flat file. The relational database includes a series of related tables. The tables are interconnected by means of key fields. The use of key fields allows for merging of tables by indexing the key fields, i.e., the key fields act as two-dimensional pivot points to obtain merging information for different tables. Relationships typically represent links maintained between tables by matching primary keys. The primary key represents a field in a relational database that uniquely identifies a row in a table. Rather, they represent the side of a "one" in a one-to-many relationship to uniquely identify a row in a table.

Alternatively, the VWCS database may be implemented using various standard data structures, such as an array, hash, (linked) list, structure, structured text file (e.g., XML), table, and the like. Such data structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, etc. An object database may include a collection of objects grouped and/or connected together by common attributes, which may be associated with other collections of objects having common attributes. Object-oriented databases perform similarly to relational databases, with the exception that objects are not just pieces of data, but may have other types of capabilities encapsulated within a given object. The use of the VWCS database 1919 may also be integrated into another component, such as the VWCS component 1935, if the VWCS database is implemented as a data structure. Furthermore, the database may be implemented as a mixture of data structures, objects and relational structures. Databases can be centralized and/or distributed among countless variations through standard data processing techniques. Portions of the database, e.g., tables, may be exported and/or imported to enable decentralization and/or integration.

In one embodiment, the database component 1919 includes several tables 1919 a-p. The a-user table 1919a may include fields such as, but not limited to: user _ id, ssn, dob, first _ name, last _ name, age, state, address _ first, address _ second, zip code, device _ list, contact _ info, contact _ type, alt _ contact _ info, alt _ contact _ type, etc. The user table may support and/or track multiple entity accounts on the VWCS. The device table 1919b may include fields such as, but not limited to: device _ ID, device _ name, device _ IP, device _ GPS, device _ MAC, device _ service, device _ ECID, device _ UDID, device _ browser, device _ type, device _ model, device _ version, device _ OS, device _ apps _ list, device _ security, sink _ app _ instance _ flag, and the like. One application table 1919c may include fields such as, but not limited to: app _ ID, app _ name, app _ type, app _ dependencies, app _ access _ code, user _ pin, and the like. Account table 1919d may include fields such as, but not limited to: account _ number, account _ security _ code, account _ name, issuer _ acquirer _ flag, issuer _ name, cqirer _ name, account _ address, routing _ number, access _ API _ call, linked _ calls _ list, and the like. The merchant table 1919e may include fields such as, but not limited to: merchant _ id, merchant _ name, merchant _ address, store _ id, ip _ address, mac _ address, auth _ key, port _ num, security _ settings _ list, and the like. Issuer table 1919f may include fields such as, but not limited to: issuerjd, issuerjname, issuerjnadress, ip _ address, mac _ address, auth _ key, port _ num, security _ settings _ list, etc. The acquirer table 1919g may include fields such as, but not limited to: account _ firstname, account _ lastname, account _ type, account _ num, account _ balance _ list, gallingaddress _ line1, gallingaddress _ line2, galling _ zip code, galling _ state, lapping _ press, lapping address _ line1, lapping address _ line2, lapping _ zip code, lapping _ state, and the like. The payment gateway table 1919h may include fields such as, but not limited to: gateway _ ID, gateway _ IP, gateway _ MAC, gateway _ secure _ key, gateway _ access _ list, gateway _ API _ call _ list, gateway _ services _ list, and the like. The store session table 1919i may include fields such as, but not limited to: user _ ID, session _ ID, alerts _ URL, timing, expiration _ layer, merchant _ ID, store _ ID, device _ type, device _ ID, device _ IP, device _ MAC, device _ browse, device _ service, device _ ECID, device _ model, device _ OS, sink _ app _ instruction, total _ cost, car _ ID _ list, product _ parameters _ list, source _ flag, source _ message, source _ networks _ list, coupon _ lists, account _ list, CVV2_ lists, charge _ io _ list, target _ priority _ list, value _ list, load _ address _ list, and the like. Transaction table 1919j may include fields such as, but not limited to: order _ id, user _ id, time _ map, transaction _ cost, purchase _ details _ list, num _ products, products _ list, product _ type, product _ params _ list, product _ title, product _ summary, quality, user _ id, client _ id, client _ ip, client _ type, client _ model, operating _ system, os _ version, app _ instruction _ flag, user _ id, account _ firstname, account _ tname, account _ type, account _ num, account _ priority _ index, account _ loading _ file, account _ loading _ history, transaction _ loading _ file, account _ loading _ index, loading _ loading. The batch table 1919k may include fields such as, but not limited to: batch _ id, transaction _ id _ list, timestamp _ list, cleared _ flag _ list, clear _ trigger _ settings, and the like. The general ledger table 1919l may include fields such as, but not limited to: request _ id, timestamp, default _ count, batch _ id, transaction _ id, clear _ flag, default _ account, transaction _ summary, path _ name, path _ account, and the like. The product table 1919m may include fields such as, but not limited to: product _ ID, product _ title, product _ attributes _ list, product _ price, tax _ info _ list, related _ products _ list, offer _ list, discrepancies _ list, refreshs _ list, merchants _ list, merchant _ availability _ list, and the like. Provider table 1919n may include fields such as, but not limited to: offer _ ID, offer _ title, offer _ attributes _ list, offer _ print, offer _ exception, related _ products _ list, partitions _ list, forwards _ list, clusters _ list, cluster _ availability _ list, and the like. Behavior data table 1919o may include fields such as, but not limited to: user _ id, time, activity _ type, activity _ location, activity _ attribute _ list, activity _ attribute _ values _ list, and the like. The analysis table 1919p may include fields such as, but not limited to: report _ id, user _ id, report _ type, report _ algorithmid, report _ destination _ address, and the like.

In one embodiment, the VWCS database may communicate with other database systems. For example, in employing a distributed database system, searching the VWCS component for query and access data would take the combination of the VWCS database and an integrated data security layer database as a single database entity.

In one embodiment, the user program may contain various user interface primitives, which may be used to update the VWCS. Furthermore, various accounts may need to customize database tables according to the environment and the type of client that the VWCS needs to serve. It should be noted that any unique field may be designated as a key field. In another embodiment, the tables are distributed to their own databases and their respective database controllers (e.g., each individual database controller in the tables above). The database may further be distributed among several computer systemations and/or storage devices using standard data processing techniques. Likewise, by centralizing and/or distributing the different database components 1919a-p, the configuration of the decentralized database controller may change. The VWCS may be configured to keep track of various settings, inputs, and parameters through the database controller.

The VWCS database may communicate with other components in the set of components, including itself, and/or similar devices. Most often, the VWCS database communicates with the VWCS components, as well as other program components, and the like. The database may contain, maintain, and provide information and data related to other nodes.

VWCS

The VWCS component 1935 is a stored program component that is executed by the CPU. In one embodiment, the VWCS component incorporates any and/or all of the combinations of VWCS aspects discussed in the previous figures. Thus, the VWCS affects access, acquisition and provision of information, services, transactions, etc. through various communication networks. The features and implementations of the VWCS discussed herein use more efficient data structures and their transport, storage mechanisms to improve network efficiency by reducing data transport requirements. Thus, more data can be transferred in a shorter time and the time delay associated with the transaction is reduced. In many cases, this reduction in storage, transmission time, bandwidth requirements, latency, etc. will reduce the capacity and structural infrastructure requirements to support the features and facilities of the VWCS and, in many cases, reduce cost, energy consumption/requirements and extend the life of the VWCS underlying infrastructure; there is an additional benefit of making the VWCS more reliable. Similarly, many features and mechanisms are designed to facilitate user access and thus expand the audience that can enjoy/employ and utilize the features set of VWCS, which can also help enhance the reliability of VWCS. In addition, with cryptographic components 1920, 1926, 1928 and the entire cartridge, the feature set includes enhanced security features as mentioned above, making access to features and data more reliable and secure.

The VWCS component may convert virtual wallet card options made by a user using the mobile device through the VWCS component into virtual wallet card based transaction purchase prompts, and/or a VWCS-like use. In one embodiment, VWCS component 1935 inputs (e.g., purchase input 411, card selection input 424, virtual wallet card option 421, publisher's server data 429, user data 434, checkout request 1311, product data 1315, wallet access input 1511, transaction authorization input 1514, payment gateway address 1518, payment network address 1522, publisher's server address (es) 1525, fund authorization request 1526, user account data 1528, batch data 1712, payment network address 1716, publisher's server address (es) 1724, personal payment request 1725, payment itemization, merchant account data 1731, etc.), and converts the input to output (e.g., virtual wallet card selection request 422, authorization message 436-, 1523, fund authorization response 1530, transaction authorization response 1532, batch append data 1534, purchase receipt 1535, batch clearing request 1714, batch payment request 1718, transaction data 1720, individual payment confirmation 1728,17299, updated payment detail, merchant account data 1733, etc.).

The VWCS component is enabled to access information between nodes by development using standard development tools and languages, such as, but not limited to: apache component, Assembly, ActiveX, binary executable file (ANSI), (Objective-) C (++), C # and/or. NET, database adapter, CGI script, Java, JavaScript, mapping tool, process and object oriented development tool, PERL, PHP, Python, shell script, SQL commands, extensions to web application servers, web development environment and libraries (e.g., Microsoft's ActiveX, Adobe AIR, FLEX & FLASH; AJAX; (D) HTML; Dojo, JAVA, JavaScript; jquery (UI), oMoTools; Prototype; script. acuul. us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo user interface, etc.), Objects, and the like. In one embodiment, the VWCS server encrypts and decrypts communications using an encryption server. The VWCS component may be conducted with other components in the set of components, including itself, and/or similar devices. Most commonly, the VWCS component communicates with a VWCS database, an operating system, and other program components. The VWCS may contain communications, generation, retrieval, and/or provision of program components, systems, users, and/or data communications, requests, and/or responses.

Distributed VWCS

The structure and/or operation of any VWCS node controller component may be combined, consolidated, and/or distributed in any number to facilitate development and/or deployment. Likewise, a collection of components can be combined in any number to facilitate deployment and/or development. To this end, the components may be integrated into a common code base, or the components may be dynamically loaded in an integrated manner as desired.

The collection of components can be centralized and/or distributed over a myriad of variations, via standard data processing and/or development techniques. Multiple instances of any one program component in a collection of program components can be instantiated at a single node and/or across a large number of nodes through load balancing and/or data processing techniques to improve performance. Further, a single instance may also be distributed across multiple controllers and/or storage devices, e.g., databases. All cooperating program component instances and controllers may do so via standard data processing communication techniques.

The configuration of the VWCS controller will depend on the context of the system deployment. Factors such as, but not limited to, budget, capabilities, location, and/or use of underlying hardware resources may affect deployment requirements and configuration. Data may be transferred, retrieved, and/or provided whether a configuration results in a more centralized and/or integrated program component, a more distributed series of program components, and/or a combination of centralized and distributed configurations. Component instances that incorporate a common code base from a collection of program components can communicate, obtain, and/or provide data. This may be achieved by data processing communication techniques within the application, such as but not limited to: data references (e.g., pointers), internal messages, communication of object instance variables, shared memory space, variable passing, and the like.

If the components of a collection of components are discrete, independent, and/or external to each other, then communicating, obtaining, and/or providing data and/or to other components may be accomplished through inter-application communication techniques, such as, but not limited to: information channels of application interfaces (APIs) ((distributed) component object models ((D) COM), (distributed) object linking and embedding ((D) OLE), etc.), Common Object Request Broker Architecture (CORBA), Jini's local and remote application interfaces, JavaScript object notation (JSON), Remote Method Invocation (RMI), SOAP, process pipe, shared files, etc. Messages sent in the content space between separate components for inter-application communication or between a single component for intra-application communication may be implemented through the creation and parsing of a grammar. A grammar can be developed using development tools, such as lex, yacc, XML, etc., that allow for grammar generation and parsing capabilities, which in turn can form the basis for communication messages within and between components.

For example, a syntax may be arranged to identify the token of the HTTP post command, such as:

w3c-post http://...Value1

where Value1 is considered a parameter because "http://" is part of the grammar syntax, the following is considered part of the Value passed. Also under such a method, the variable "Value 1" may be inserted into the "http://" post command and then sent. The grammar syntax itself may be represented as structured data (e.g., a grammar description text file processed by lex, yacc, etc.) that may be translated and/or used to generate parsing mechanisms. Additionally, once the parsing mechanism is generated and/or instantiated, it may itself process and/or parse structured data, such as, but not limited to: text delimited by characters (e.g., tags), HTML, structured text streams, XML, and/or similar structured data. In another embodiment, the inter-application data processing protocol itself may have integrated and/or off-the-shelf parsers (e.g., JSON, SOAP, and/or the like) that are employed to parse (e.g., communicate) the data. Further, although the parsing grammar is used in message parsing, it is also possible to use: databases, data collection, data storage, structured data, and the like. Again, the configuration required will depend on the context, environment and requirements of the system deployment.

For example, in some implementations, the VWCS controller can execute a PHP script implementing a secure socket layer ("SSL") socket server through an information server that listens for incoming communications, e.g., JSON format encoded data, on the server port to which the client is to send data. Once an incoming communication is identified, the PHP script may read the incoming message from the client device, parse the received JSON-encoded text data into PHP script variables, extract the JSON-encoded text data therefrom, then store the data (e.g., client identification information, etc.) and/or extract information in a relational database accessible using Structured Query Language (SQL). An exemplary manifest, written substantially in the form of PHP/SQL commands, receives JSON-encoded input data from a client device over an SSL connection, parses the data to extract variables, and stores the data in a database, provides the following:

further, the following resources may be used to provide examples regarding SOAP parser implementations

Example (b):

http://www.xav.com/perl/site/lib/SOAP/Parser.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsptopic=/com.ibm.

IBMDI.doc/referenceguide295.htm

other resolvers implement:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsptopic=/com.ibm.IBMDI.doc/referenceguide259.htm

all of which are expressly incorporated herein by reference. Non-limiting exemplary embodiments highlighting a number of further advantageous aspects include:

1. an embodiment of a virtual wallet card selection means comprising means for:

obtaining a user authentication request for a purchase transaction;

extracting, via the computing processor, the universal card account number based on parsing the user authentication request;

determining that the user is authorized to access the virtual wallet based on querying the database using the universal card account number;

providing a user virtual wallet card selection request to a user device when it is determined that the user is authorized to access the virtual wallet;

obtaining a user selection of a virtual wallet card account; and

using user selection of the virtual wallet card account, a purchase transaction request message is provided for transaction processing.

2. The means of embodiment 1, further comprising means for:

upon completion of authorization of the purchase transaction based on the purchase transaction request message, a purchase receipt is provided to the user device.

3. The means of embodiment 1, further comprising means for:

acquiring a virtual wallet card selection option for a user; and

the user device is provided with a virtual wallet card selection option.

4. The apparatus of embodiment 3, wherein the virtual wallet card selection option is based on a universal card account number extracted from the user authentication request.

5. The apparatus of embodiment 4, wherein the universal card account number extracted from the user authentication request includes encoded virtual wallet card selection option information and user identification information.

6. The apparatus of embodiment 5, wherein the encoded virtual wallet card selection option information is encoded as indicia in a universal card account number extracted from the user authentication request.

7. The apparatus of embodiment 1, wherein the user selection of the virtual wallet card account comprises selecting an anonymous card account to process the purchase transaction.

8. The apparatus of embodiment 7, wherein the anonymous card account is a one-time anonymous card account generated in response to receiving a user selection of the virtual wallet card account.

9. The means of embodiment 1, further comprising means for:

obtaining user selections of a plurality of virtual wallet card accounts; and

wherein the purchase transaction request message includes an identification of a user selection of the plurality of virtual wallet card accounts.

10. The apparatus of embodiment 1, wherein the user device is a user mobile device executing a virtual wallet application.

To address various problems and improve upon the art, all aspects of this application (including covers, headings, sub-headings, technical fields, background, summary, brief summary, implementations, claims, abstract, drawings, appendix, and/or others) of a virtual wallet card selection device, method and system show by way of illustration embodiments in which the claimed invention may be practiced. The advantages and features of the present application are merely representative examples of embodiments and are not intended to be exhaustive and/or exclusive. They are merely useful in understanding and teaching the principles of the claims. It should be understood that they are not intended to be a representation of all claimed inventions. As such, certain aspects of the present disclosure are not discussed herein. That alternate embodiments may not be presented for a particular portion of the invention or that further undescribed alternate embodiments may be available for a portion is not considered to be a disclaimer of those alternate embodiments. It is to be understood that many of those undescribed embodiments incorporate the same principles of the invention, and that other embodiments are equivalent. As such, it is to be understood that other embodiments may be utilized and that functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope of the invention. As such, all examples and/or embodiments are to be considered non-limiting throughout this disclosure. Likewise, no inference should be made regarding those embodiments discussed herein relative to those not discussed herein, and as such, it is intended to reduce space and repetition. For example, it is to be understood that the logic and/or topology of any combination of any program components (collection of components), other components, and/or any set of existing features, as depicted in the figures and/or throughout the specification is not limited to a fixed order and/or arrangement of operations, but rather any disclosed order is exemplary and that the disclosure contemplates all equivalent practices regardless of order. Further, it is to be appreciated that such features are not limited to being performed serially, and that any number of threads, processes, services, servers, and/or the like may be performed asynchronously, concurrently, in parallel, concurrently, synchronously, and/or the like is contemplated by the present disclosure. Thus, some of these features may be mutually inconsistent and may not be present in a single embodiment. Similarly, certain features are applicable to one aspect of the invention and not to others. In addition, this disclosure also includes other inventions not presently claimed. Applicants reserve all rights in those inventions not presently claimed, including claims, supplemental applications, continuing applications, portions of continuing applications, and/or the like. As such, it should be understood that advantages, embodiments, examples, functionality, features, logic, organization, structure, topology, and/or other aspects of the disclosure are not to be considered as limiting of the disclosure as defined by the claims or as equivalents to the claims. It will be appreciated that embodiments of the VWCS may be implemented that allow for great flexibility and customization depending on the specific needs and/or characteristics of the VWCS individual and/or enterprise user, database configuration, relational model, data type, data transport and/or network framework, syntax structure, and/or the like. For example, aspects of the VWCS may be applicable to fraud prevention, online/virtual shopping, online financial management, and/or the like. While the various embodiments and discussions of the VWCS are directed to electronic shopping transactions, it is understood that the embodiments described herein may be readily configured and/or customized for various other and/or implementations.

Claims

1. A virtual wallet card selection system comprising:

a computing processor;

a network communication device arranged to communicate with the computing processor; and

a memory configured to communicate with the computing processor and storing instructions executable by the computing processor to:

obtaining a user authentication request for a purchase transaction via a network communication device operatively connected to a payment network server;

extracting, via a computing processor operatively connected to the payment network server, the universal card account number based on parsing the user authentication request;

determining that the user is authorized to access the virtual wallet based on querying a database memory operatively connected to the payment network server using the universal card account number;

determining, based on querying a database memory using a universal card account number, that a user desires to maintain privacy of user payment data from a merchant involved in a purchase transaction by utilizing secure network communications with a mobile device of the user to provide payment data to a payment network server to process the purchase transaction;

identifying, via a computing processor of a payment network server, a plurality of card selection options securely provided to a user mobile device of a user via a network communication device to maintain privacy of user payment data from a merchant involved in a purchase transaction;

providing, via the network communication device, a secure user virtual wallet card selection request including a card selection option to the user mobile device via encrypted out-of-band network communication when it is determined that the user is authorized to access the virtual wallet, thereby reducing network latency and bandwidth usage of the electronic payment communication network;

obtaining, at a payment network server via a network communication device, a user selection of a virtual wallet card account from the plurality of securely provided card selection options from a user mobile device via the network communication device;

providing, via the network communication device, the encrypted purchase transaction request message for transaction processing using the user selection of the virtual wallet card account.

2. A virtual wallet card selection system comprising:

a processor; and

a memory configured to communicate with the processor and to store processor-executable instructions for:

obtaining a user authentication request for a purchase transaction;

extracting, via the processor, the universal card account number based on parsing the user authentication request;

obtaining a user selection of a virtual wallet card account; and

3. The system of claim 2, the memory further storing instructions for:

4. The system of claim 2, the memory further storing instructions for:

acquiring a virtual wallet card selection option for a user; and

the user device is provided with a virtual wallet card selection option.

5. The system of claim 4, wherein the virtual wallet card selection option is based on a universal card account number extracted from the user authentication request.

6. The system of claim 5, wherein the universal card account number extracted from the user authentication request includes encoded virtual wallet card selection option information and user identification information.

7. The system of claim 6, wherein the encoded virtual wallet card selection option information is encoded as indicia in a universal card account number extracted from the user authentication request.

8. The system of claim 2, wherein the user selection of the virtual wallet card account comprises selecting an anonymous card account to process a purchase transaction.

9. The system of claim 8, wherein the anonymous card account is a one-time anonymous card account generated in response to receiving a user selection of the virtual wallet card account.

10. The system of claim 2, the memory further storing instructions for:

obtaining user selections of a plurality of virtual wallet card accounts; and

11. A non-transitory computer readable medium storing processor-executable virtual wallet card selection instructions for:

obtaining a user authentication request for a purchase transaction;

obtaining a user selection of a virtual wallet card account; and

12. The medium of claim 11 further storing instructions to:

13. The medium of claim 11 further storing instructions to:

acquiring a virtual wallet card selection option for a user; and

the user device is provided with a virtual wallet card selection option.

14. The medium of claim 13, wherein the virtual wallet card selection option is based on a universal card account number extracted from the user authentication request.

15. The medium of claim 14, wherein the universal card account number extracted from the user authentication request includes encoded virtual wallet card selection option information and user identification information.

16. The medium of claim 15, wherein the encoded virtual wallet card selection option information is encoded as indicia in a universal card account number extracted from the user authentication request.

17. The medium of claim 11, wherein the user selection of the virtual wallet card account comprises selecting an anonymous card account to process a purchase transaction.

18. The medium of claim 17, wherein the anonymous card account is a one-time anonymous card account generated in response to receiving a user selection of a virtual wallet card account.

19. The medium of claim 11 further storing instructions to:

obtaining user selections of a plurality of virtual wallet card accounts; and

20. The medium of claim 11, wherein the user device is a user mobile device executing a virtual wallet application.

21. A processor-implemented virtual wallet card selection method, comprising:

obtaining a user authentication request for a purchase transaction;

obtaining a user selection of a virtual wallet card account; and

22. The method of claim 21, further comprising:

23. The method of claim 21, further comprising:

acquiring a virtual wallet card selection option for a user; and

the user device is provided with a virtual wallet card selection option.

24. The method of claim 23, wherein the virtual wallet card selection option is based on a universal card account number extracted from the user authentication request.

25. The method of claim 24, wherein the universal card account number extracted from the user authentication request includes encoded virtual wallet card selection option information and user identification information.

26. The method of claim 25, wherein the encoded virtual wallet card selection option information is encoded as indicia in a universal card account number extracted from the user authentication request.

27. The method of claim 21, wherein the user selection of the virtual wallet card account comprises selecting an anonymous card account to process a purchase transaction.

28. The method of claim 27, wherein the anonymous card account is a one-time anonymous card account generated in response to receiving a user selection of a virtual wallet card account.

29. The method of claim 21, further comprising:

obtaining user selections of a plurality of virtual wallet card accounts; and

30. The method of claim 21, wherein the user device is a user mobile device executing a virtual wallet application.