CN103797500A - Virtual wallet card selection apparatuses, methods and systems - Google Patents

Abstract

The virtual wallet card selection apparatuses, methods and systems ("VWCS") transform virtual wallet card selections by users utilizing mobile devices via VWCS components into virtual wallet card-based transaction purchase notifications. In one implementation, the VWCS is an apparatus, having a memory, computing processor, and network communication device that obtains a user authentication request for a purchase transaction, and extracts a universal card account number from it. Upon querying a database, the VWCS determines that the user has access to a virtual wallet and obtains virtual wallet card selection options for the user from the database. The VWCS provides the virtual wallet card selection options to a user mobile device, and obtains a user selection of an account included among the options. The VWCS initiates a purchase transaction using the user selection. Also, upon completion of authorization of the purchase transaction, the VWCS provides a purchase receipt to the user mobile device.

Description

Virtual wallet card selection device, method and system

This written patent application discloses and describes various new innovative and inventive aspects of virtual wallet card selection technology (hereinafter referred to as the present disclosure) and contains subject matter that is protected by copyright, integrated circuit layout design, and/or other intellectual property rights . The respective owners of this intellectual property have no objection to the facsimile reproduction by anyone of this disclosure as this application appears in published patent office files/records, but otherwise reserve all rights.

priority statement

This application was filed on June 3, 2011 in accordance with 35 USC §119, serial number 61/492,854, titled "VIRTUAL WALLET CARD SELECTION APPARATUSES, METHODS AND SYSTEMS", attorney docket number P-42069PRV|20270-139PV Priority of the above-mentioned application, the entire content of which is hereby expressly incorporated by reference.

technical field

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

Background technique

A consumer transaction requires a consumer to select a product from a store shelf and then check out for the product at a checkout counter. Product information is entered into a point-of-sale terminal device, or automatically entered by scanning an item's barcode with an integrated barcode scanner, and the customer is typically offered multiple payment options such as cash, check, credit or debit card. Once payment is made and approved, the point-of-sale terminal memorizes the transaction in the merchant's computer system and generates a receipt indicating satisfactory completion of the transaction.

Description of drawings

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

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

2 shows an application user interface diagram illustrating example features of a virtual wallet card selection mobile application for selecting from multiple 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 the VWCS;

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

5A-E show logic flow diagrams illustrating example aspects of using virtual wallet card selection to perform card-based transactions in some embodiments of the VWCS (e.g., a virtual wallet-based card transaction execution (“VW-CTE”) component 500). ;

Figure 6 shows a user interface diagram showing an overview of example features of a virtual wallet application in some embodiments of the VWCS;

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

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

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

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

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

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

13 shows a data graph diagram illustrating example aspects of converting user checkout request input to checkout data display output via a user purchase checkout ("UPC") component;

14 shows a logic flow diagram illustrating example aspects of converting user checkout request input to a display of checkout data via a User Purchase Checkout ("UPC") component;

15A-B show data graph schematic diagrams illustrating example aspects of converting user virtual wallet access inputs into purchase transaction receipt notifications via a Purchase Transaction Authorization (“PTA”) component;

16A-B show logic flow diagrams illustrating example aspects of converting user virtual wallet access inputs into purchase transaction receipt notifications via a Purchase Transaction Authorization (“PTA”) component;

17A-B show data graph diagrams illustrating example aspects of converting merchant transaction bulk data queries into updated payment ledger records via a purchase transaction clearing (“PTC”) component;

18A-B show logic flow diagrams illustrating example aspects of converting merchant transaction bulk data queries into updated payment ledger records via a purchase transaction clearing (“PTC”) component;

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

The initial digit of each reference number within a figure 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 et al.

Detailed ways

Virtual Wallet Card Selection (VWCS)

The virtual wallet card selection device, method and system (hereinafter referred to as "VWCS") converts the virtual wallet card selection made by the user using the mobile device through the VWCS component into a transaction purchase notification based on the virtual wallet card. 1A-C show block diagrams illustrating example aspects of virtual wallet card selection based purchase transactions in some embodiments of the VWCS. A VWCS has many features and capabilities, some of which are in Figure 1A as examples. Further details regarding Figure 1A can be found relative to Figures 4A-5E. Referring to FIG. 4A , in some implementations, a user (eg, 101 ) may desire to purchase a product, service, offering, etc. ("product") from a merchant. A user may communicate with a merchant server (eg, 103 ) through a client such as, but not limited to, a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, etc. (eg, 102a ). For example, a user may provide user input (eg, purchase input 411 ) to the client indicating the user's desire to purchase the product. In various implementations, user input may include, but is not limited to: keystrokes, card swipes, activation of RFID/NFC enabled hardware devices (e.g., electronic cards with multiple accounts, smartphones, tablets, etc.), mouse clicks, press Buttons on joysticks/game consoles, voice commands, single/multi-touch gestures on touch-sensitive interfaces, touch UI elements on touch-sensitive displays, 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 via the website by clicking on a hyperlink presented to the user. As another example, a client may obtain trace 1 data from a user's card (eg, credit card, debit card, prepaid card, payment card, etc.), such as example trace 1 data is provided below:

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

(Wherein, '123456789012345' is the card number of 'J.Q.Public' and has a CVV number of 901. '990112' is the service code, and *** represents a decimal number that changes randomly every time the card is used.)

In some implementations, the client generates a purchase order message (eg, 112 ) and provides the generated purchase order message to the merchant server (eg, 113 ). For example, a browser application executing on a client may provide a (secure) Hypertext Transfer Protocol (HTTP(S)) GET message on behalf of the user, which includes, in the form of data formatted according to Extensible Markup Language (XML), Product order details for merchant server. The following is an example HTTP(S) GET message to a merchant server including an XML-formatted purchase order message 413:

In some implementations, the merchant server can obtain a purchase order message from the client and can parse the purchase order message to extract details of the purchase order from the user. The merchant server generates a card lookup request (eg, 114) to determine if the transaction can be processed. For example, the merchant server may attempt to determine whether the user has sufficient funds in the card account to which the purchase order was provided to cover the purchase. The merchant server may provide the generated card lookup request (eg, 115 ) to an acquirer server (eg, 104 ). For example, the acquirer server may be the server of the acquiring financial institution ("acquirer") that maintains the merchant account. For example, proceeds of transactions processed by the merchant may be deposited into an account maintained by the acquirer. In some implementations, the card lookup request may include details such as, but not limited to, the user's expenses involved in the transaction, the user's card account details, user billing and/or shipping information, and the like. 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 can generate a card authorization request (eg, 116 ) using the retrieved card lookup request and provide the card authorization request (eg, 117 ) to the payment network server (eg, 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 can obtain the card authorization request from the acquirer server and can parse the card authorization request to extract details of the request, such as the user ID and purchasing card details. The payment network server may attempt to determine whether the user has access to 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 (eg, 119 ) the payment network database (eg, 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 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. Example PHP/SQL commands enumerating, illustrating the substantive aspects of the virtual wallet card selection query 119 to the database are provided below:

In response to a get virtual wallet card selection query (eg, 119 ), the payment network database may provide (eg, 120 ) the requested virtual wallet card selection options 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., 122) the virtual wallet card selection request to a user device (e.g., 102b), such as, but not limited to, a personal computer , 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 virtual wallet card selection options (eg, 123 ) to the user. For example, user equipment may present web pages, electronic messages, text/SMS messages, buffer voicemails, sound ringtones, and/or play audio messages, etc., and provide output including, but not limited to: sound, music, audio, video, Images, haptic feedback, vibration alerts (eg, on vibration-capable client devices such as smartphones), etc.

In some implementations, the user may provide a card selection input (eg, 124 ) in response to a virtual wallet card selection option presented to the user by the user device. For example, a user may tap, swipe a touchscreen of a mobile device, press a key on a keyboard, perform a single mouse click, etc. to provide a card selected 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 (eg, 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 will be processed as a splittender, e.g., in the example virtual wallet card selection response 125 above, 60% of the charge is applied to one card and 40% is applied to another card. A user interface that provides split payment options is described further below in the discussion with reference to FIGS. 8A-B .

消息/墙张贴）wall posting）等）请求用户从用户的虚拟钱包选择支付选项。基于该消息，用户设备所呈现的用户界面可填充用户卡选择选项（参见110）。在一些示例中，即使通用卡不是信用卡，通过用户使用用户设备也可选择最合适的卡。可替代地，支付网络服务器可以选择预设卡以利用该预设卡处理购买交易。Referring to FIG. 1B , in some implementations, a user (eg, 101 ) may desire to purchase products, services, and/or other offerings ("products") in person. A user may, for example, enter (see, eg, 102 ) a store, warehouse, etc. to purchase a product. The user may desire to personally source purchases available at the store (see, eg, 103 ). In some implementations, the user may attempt to check out the purchased item (see, eg, 104 ) at a point-of-sale (POS) terminal (eg, 105 ). For example, the user may swipe a payment card 106 (eg, 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 payment network 107 (eg, credit card company, issuer bank, acquirer bank, etc.) for payment processing. Based on the universal card details, the payment network may identify (eg, 108 ) that the user associated with the universal card has accessed the virtual wallet card. The payment network may query the user (eg, 109 ) for one of the cards selected from the user's virtual wallet, eg, in real time. For example, the payment network may send a message (e.g., (secure) Hypertext Transfer Protocol (HTTP(S)) POST/GET messages, email messages, Short Message Service (SMS) messages, HTTP/Real Time Streaming Protocol (RTSP) video streams, text messages, Twitter ^TM tweets,

message/wall posting) wall posting) etc.) request the user to select a payment option from the user's virtual wallet. Based on this message, the user interface presented by the user device may be populated with user card selection options (see 110). In some examples, even if the universal card is not a credit card, the most suitable card can be selected by the user using the user device. Alternatively, the payment network server may select a preset card with which to process the purchase transaction.

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

In some implementations, the application can provide the user with various alternative choices. For example, the app may provide the user with alternative merchants from which the user can acquire the product and/or similar products, alternative products comparable to the purchased product, competitive pricing information between merchants, discounts, coupons, and/or Or other provision for users, etc. In some implementations, the application may indicate that the user may earn reward points if the user purchases a product at another merchant. In some implementations, the application may indicate that if the user purchases a product at another merchant, fewer rewards points may need to be used to pay for the purchase because the other merchant may have a better relationship with the rewards point provider . In some implementations, the application may indicate that the user may earn more reward points if a particular (or alternative) card is used to pay for the purchase. In some implementations, the application may indicate that if the user purchases the card at an alternate merchant and/or uses an alternate card, the user may receive a greater amount of cash back. In various implementations, offerings to users 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, Acquirer, etc.

Referring to FIG. 1C , in some implementations, a user can purchase (eg, 111 ) products on the spot from the current merchant and/or other merchants by performing a single action on the user device (eg, a tap of the user device's touchscreen). In this implementation, the "card" (e.g., checking account, savings account, Paypal ^™ account, Google Checkout ^™ account, credit card, debit card, prepaid card) selected from the user's virtual wallet (see, e.g., 112a-b) etc.), the VWCS server may initiate a card-based purchase transaction. In some implementations, the VWCS is able to arbitrate how the credit card payment network processes payments to users due to consideration of transaction costs in which entities such as merchants, card issuers, acquirers, payment networks, and/or VWCS components Switchable.

In some implementations, the payment network (eg, 113) can initiate a card-based purchase transaction (eg, 114) and can generate a purchase confirmation receipt to the user. The VWCS server may provide a purchase confirmation receipt to the client device (eg, 116a-b). In some implementations, the user may desire to exit the store through the application after purchasing an item. In this implementation, the user may be required to provide proof of purchase of the product at the store exit (eg, 115). The user may provide proof of product purchase with a purchase confirmation receipt obtained from the VWCS through an application on the client device (eg, 116a). For example, a receipt may include a purchase identifier (eg, 116c). For example, a purchase identifier may include a barcode, a QR code, an image of a receipt, a video of the purchase action, and the like. The user may utilize such a purchase confirmation as evidence of leaving the store. Thus, in some implementations, the user may gain better security in the transaction since the purchase can 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 outdated POS terminals, users can still gain access to the user's virtual wallet through the user's device, thereby increasing user efficiency and convenience in the user's shopping experience.

上的墙张贴、Twitter^TM上的推特等）（例如，212）。在一些实现中，应用可向用户提供选项以显示由客户端设备捕获的产品识别信息(例如，以便在商店的出口向客户服务代表显示产品信息)（例如，214）。在一些实现中，用户、应用、设备或VWCS在处理中会遇到错误。在这样的场景下，用户可能够与客户服务代表交谈（例如，聊天验证（VerifyChat）213)以解决在购买交易过程中的困难。Figure 2 shows an application user interface diagram illustrating example features of a virtual wallet card selection mobile application for selecting from multiple 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 number of features to the user. In some implementations, the application can include an indication (eg, 201 ) of the user's location (eg, name of the merchant store, geographic location, information about an aisle within the merchant store, etc.). The application may provide an indication of the payment amount due for the purchase of the product (eg, 202 ). In some implementations, the application may provide the user with multiple options for paying an amount to purchase the product. For example, an application may utilize GPS coordinates to determine that a store is within range of the user and direct the user to the merchant's website. In some implementations, the VWCS may directly provide APIs to participating merchants to facilitate transaction processing. In some implementations, merchant-branded VWCS applications can be developed utilizing VWCH functionality, which can directly connect users to the merchant's transaction processing system. For example, a user may select (eg, 203 ) from several cards (eg, credit cards, debit cards, prepaid cards, etc.) from multiple card providers. In some implementations, the application can provide the user with an option to pay for the purchase (eg, 204 ) by using funds included in the user's bank account (eg, checking, savings, money market, cash account, etc.). In some implementations, the user may have set default options for cards, bank accounts for purchase transactions through the app. In some implementations, setting of such default options may allow a user to initiate a shopping transaction via a single click, tap, swipe, and/or other remedial user input action (eg, 205 ). In some implementations, when the user utilizes such an option, the application can utilize the user's default settings to initiate a shopping transaction. In some implementations, the application may allow the user to pay for purchases (eg, 206 ) with other accounts (eg, Google ^™ checkout, Paypal ^™ account, etc.). In some implementations, an application may allow a user to utilize rewards points, airline miles, hotel points, electronic coupons, printed coupons (e.g., by capturing a printed coupon similar to a product identifier ) etc. to pay for purchase transactions (eg, 207-208). In some implementations, the application may provide an option to provide explicit authorization (eg, 209 ) before initiating a purchase transaction. In some implementations, the application may provide a progress indicator to provide an indication of the progress of the transaction after the user has selected the option to initiate the shopping transaction (eg, 210 ). In some implementations, the application can provide the user via the application with historical information about the user's previous purchases (eg, 211 ). In some implementations, the app can provide the user with options to share information about purchases with other users (e.g., via email, SMS,

Wall posting on Twitter ^TM , etc.) (e.g., 212). In some implementations, the application may provide the user with an option to display product identification information captured by the client device (eg, to display product information to a customer service representative at the exit of the store) (eg, 214). In some implementations, a user, application, device, or VWCS encounters an error in processing. In such a scenario, the user may be able to chat with a customer service representative (eg, VerifyChat 213) to resolve difficulties during the purchase transaction.

In some implementations, the user may choose to use a one-time anonymous credit card number for the transaction (see, eg, 205b). For example, the VWCS may utilize pre-specified anonymous card deck details (see eg, AnonCard1, AnonCard2). As another example, a VWCS would generate an anonymous deck details such as in real-time once to securely complete a purchase transaction (eg, Anon It1X). In such implementations, the application may automatically set user profile settings such that any personally identifying information of the user will not be provided to merchants and/or other entities. In some implementations, the user may be required to enter a username and password to enable the anonymization feature.

消息、Twitter^TM推特、文本聊天、语音聊天、视频聊天（例如，Apple FaceTime）等与用户通信。例如，VWCS可向用户发起视频挑战（challenge）（例如，301）。例如，用户需要经由视频聊天展示他/她自身（例如，302）。在一些实现中，客户服务代表（例如，代理304b）可人工地确定使用用户的视频的用户的真实性。在一些实现中，VWCS可利用脸、生物计量（biometric）等识别（例如，使用模式分类技术）来确定用户的身份（例如，304a）。在一些实现中，应用可提供参照标记（referene marker）（例如，十字准线、目标框等）（例如，303），使得用户可视频以促进VWCS的用户自动识别。在一些实现中，用户可能没有发起交易，例如，该交易是诈骗性的。在这样的实现中，用户可取消挑战（例如，305）。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 the VWCS. In some implementations, an application executing on the user's device may provide a chat verification feature to prevent fraud (eg, by activating UI element 213 in FIG. 2 ). For example, VWCS can detect unusual and/or suspicious transactions. The VWCS can utilize the chat verification feature to communicate with the user and verify the authenticity of the originator of the purchase transaction. In various implementations, the VWCS can send email messages, text (SMS) messages,

Messages, Twitter ^TM tweets, text chats, voice chats, video chats (eg, Apple FaceTime), etc. to communicate with users. For example, the VWCS may initiate a video challenge (eg, 301 ) to the user. For example, a user needs to reveal himself/herself via video chat (eg, 302 ). In some implementations, a customer service representative (eg, agent 304b) may manually determine the authenticity of the user using the user's video. In some implementations, the VWCS may utilize facial, biometric, etc. recognition (eg, using pattern classification techniques) to determine the user's identity (eg, 304a). In some implementations, the application can provide a referene marker (eg, crosshair, target box, etc.) (eg, 303 ) that the user can video to facilitate automatic user identification of the VWCS. In some implementations, the user may not have initiated the transaction, eg, the transaction was fraudulent. In such an implementation, the user may cancel the challenge (eg, 305). The VWCS may then cancel the transaction, and/or initiate a fraud investigation process on behalf of the user.

消息、Twitter^TM推特等与用户通信。VWCS可对于用户提出挑战问题（例如，308）。应用可提供用户输入界面元素（例如，虚拟键盘309）以回答由VWCS所提出的挑战问题。在一些实现中，挑战问题可由VWCS自动地随机选择；在一些实现中，客户服务代表可人工地与用户通信。在一些实现中，用户可能没有发起交易，例如，该交易是诈骗性的。在这样的实现中，用户可取消文本挑战（例如，307，310）。VWCS接着代表用户可取消交易，和/或发起诈骗调查过程。In some implementations, the VWCS may utilize a text challenge process to verify the user's authenticity (eg, 306). For example, VWCS can be accessed via text chat, SMS message, email,

Messages, Twitter ^TM tweets, etc. communicate with users. The VWCS may pose challenge questions (eg, 308 ) to the user. The application may provide user input interface elements (eg, virtual keyboard 309 ) to answer the challenge questions posed by the VWCS. In some implementations, challenge questions can be randomly selected automatically by the VWCS; in some implementations, a customer service representative can communicate with the user manually. In some implementations, the user may not have initiated the transaction, eg, the transaction was fraudulent. In such implementations, the user may cancel the text challenge (eg, 307, 310). The VWCS can then cancel the transaction on behalf of the user, and/or initiate a fraud investigation process.

In some implementations, the application can be configured to recognize a product identifier (eg, barcode, QR code, etc.). For example, to prevent fraud, an app could ask the user to use the user's device to take a snapshot of the item being purchased, thereby ensuring that the person swiping the card also has the user's device and the purchased item. In some implementations, the user may be required to log into the application to enable its features. Once enabled, the camera provides the user with an in-person one tappurchasing feature. For example, a client device may have a camera via which an application may obtain images, video data, streaming real-time video, etc. (eg, 313 ). The application may be configured to analyze the input data, and search (eg, 311 ) for a product identifier (eg, 314 ). In some implementations, the application can overlay the alignment reference markers (eg, 315 ) with crosshairs, target boxes, etc., so that the user can facilitate product identifier recognition and interpretation by using the reference markers to align the product identifiers. In some implementations, the application may include an interface element to allow the user to switch back and forth between the product identification mode and the product offering interface display screen (see, e.g., 316 ), so that the user can accurately research the available information available to the user before capturing the product identifier. buy and sell. In some implementations, the application may provide the user with the ability to view previous product identifier captures (see, eg, 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 the product purchase; the application may provide the user with a user interface element (eg, 318 ) to cancel the product identifier identification process and return to the interface screen previously utilized by the user. In some implementations, the user is provided with information about products, user settings, merchants, offers, etc. in the form of a list (see eg, 319 ), so that the user can better understand the user's purchasing options. Various other features may be provided in the application (see, eg, 320).

In some implementations, the user may be able to view and/or modify the user profile and/or the user's settings, eg, by activating user interface element 309 (see FIG. 3A ). For example, a user may be able to view/modify username (eg, 321a-b), account number (eg, 322a-b), user security access code (eg, 323a-b), user PIN (eg, 324a-b), User address (e.g., 325a-b), social security number associated with the user (e.g., 326a-b), current device GPS location (e.g., 327a-b), user account at the merchant of the store where the user is currently located (e.g. , 328a-b), the user's rewards account (eg, 329a-b), etc. 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 the user with enhanced data security. For example, in the example illustration in FIG. 3C , the user has selected Name 312a, Account Number 322a, Security Code 323a, Merchant Account ID 328a, and Rewards Account ID 329a as fields (to be sent as part of the notification) to process the purchase transaction. In some implementations, the user can toggle the fields and/or data values sent as part of the notification to process the purchase transaction. In some implementations, the application may present 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 can provide the VWCS with the user's GPS location. Based on the user's GPS location, the VWCS can determine the user's environment (eg, whether the user is in a store, doctor's office, hospital, postal service office, etc.). Based on the circumstances, the user application can present the user with appropriate fields from which the user can select fields and/or field values to send as part of the purchase order transmission.

For example, a user may go to a doctor's office and expect to pay a copay for the doctor's appointment. In addition to basic transaction information such as account number and name, applications can provide users with the ability to choose to transfer medical records, health information, which can be provided to medical providers, insurance companies, and transaction processors to coordinate payments between multiple parties . In some implementations, records may be sent in a Health Insurance Portability and Accountability Act (HIPAA) compliant data format and encrypted, and only recipients authorized to view such records may have the appropriate decryption key to decrypt and view the private User Info.

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

4A-C show data flow diagrams illustrating an example process for using a virtual wallet card to select to perform a card-based transaction in some embodiments of the VWCS. Referring to FIG. 4A , in some implementations, a user (eg, 401 ) may desire to purchase a product, service, offer, etc. ("product") from a merchant. A user may communicate with a merchant server (eg, 403 ) through a client such as, but not limited to: personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, etc. (eg, 402a ). For example, a user may provide user input (eg, purchase input 411 ) to the client indicating the user's desire to purchase a product. In various implementations, user input may include, but is not limited to: keystrokes, card swipes, activation of RFID/NFC enabled hardware devices (e.g., electronic cards with multiple accounts, smartphones, tablets, etc.), mouse clicks, press Buttons on joysticks/game consoles, voice commands, single/multi-touch gestures on touch-sensitive interfaces, touch UI elements on touch-sensitive displays, etc. For example, a user can direct a browser application executing on a client device to a merchant's website, and can select a product from the website via the website by tapping a hyperlink presented to the user. As another example, a client may obtain trace 1 data from a user's card (eg, credit card, debit card, prepaid card, payment card, etc.), such as example trace 1 data is provided below:

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

(Where, '123456789012345' is the card number of 'J.Q.Public', and has CVV number 901. '990112' is the service code, and *** represents a decimal number that changes randomly every time the card is used.)

In some implementations, the client can generate a purchase order message (eg, 412 ) and provide the generated purchase order message to the merchant server (eg, 413 ). For example, a browser application executing on a client may provide a (secure) Hypertext Transfer Protocol (HTTP(S)) GET message on behalf of the user, which includes, in the form of data formatted according to Extensible Markup Language (XML), Product order details for merchant server. The following is an example HTTP(S) GET message to a merchant server including an XML-formatted purchase order message 413:

In some implementations, the merchant server can obtain a purchase order message from the client and can parse the purchase order message to extract details of the purchase order from the user. The merchant server may generate a card lookup request (eg, 414) to determine if the transaction can be processed. For example, the merchant server may attempt to determine whether the user has sufficient funds in the card account to which the purchase order was provided to cover the purchase. The merchant server may provide the generated card lookup request (eg, 415 ) to the acquirer server (eg, 404 ). For example, the acquirer server may be the server of the acquiring financial institution ("acquirer") that maintains the merchant account. For example, proceeds of transactions processed by the merchant may be deposited into an account maintained by the acquirer. In some implementations, the card lookup request may include details such as, but not limited to, the user's expenses involved in the transaction, the user's card account details, user billing and/or shipping information, and the like. 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 can use the retrieved card lookup request to generate a card authorization request (eg, 416 ) and provide the card authorization request to the payment network server (eg, 405 ) (eg, 417 ). 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 can obtain the card authorization request from the acquirer server and can parse the card authorization request to extract details of the request, such as the user ID and purchasing card details. The payment network server may attempt to determine whether the user has access to 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 (eg, 419 ) the payment network database (eg, 407 ) to obtain data about 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 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. Example PHP/SQL commands enumerating, illustrating the substantive aspects of the virtual wallet card selection query 419 to the database are provided below:

In response to the get virtual wallet card selection query (eg, 419 ), the payment network database may provide (eg, 420 ) the requested virtual wallet card selection options 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) the virtual wallet card selection request to a user device (e.g., 402b) such as, but not limited to: a personal Computers, mobile devices, (interactive) TVs, personal digital assistants, tablets, 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 virtual wallet card selection options to the user (eg, 423 ). For example, user equipment may present web pages, electronic messages, text/SMS messages, buffer voicemails, sound ringtones, and/or play audio messages, etc., and provide output including, but not limited to: sound, music, audio, video, Images, haptic feedback, vibration alerts (eg, on vibration-capable client devices such as smartphones), etc.

In some implementations, the user may provide a card selection input (eg, 424 ) in response to a virtual wallet card selection option presented to the user by the user device. For example, a user may tap, swipe a mobile device's touchscreen, press a key on a keyboard, perform a single mouse click, etc. to provide a card selected 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 (eg, 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 will be processed as split payments, e.g., in the example virtual wallet card selection response 425 above, 60% of the charge is applied to one card and 40% is applied to the other cards. A user interface that provides split payment options is described further below in the discussion with reference to FIGS. 8A-B .

Referring to Figure 4B, in some implementations, the payment network server may obtain the 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 fields and field values, the pay network server may generate a query (eg, 428 ) for the issuer server corresponding to the user's card account selected from the user's virtual wallet. For example, a user's card account may be linked to an issuer financial institution ("issuer"), such as the banking institution that issued the card account to the user. The issuer's issuer server (eg, 406 ) may maintain details of the user's card account. In some implementations, a database (eg, payment network database 407 ) can store details of issuer servers and card account numbers associated with issuer servers. For example, the database may be a relational database responsive to Structured Query Language ("SQL") commands. The payment web 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 illustrate the substantive aspects of querying a database:

In response to the get issuer server query (eg, 428), the pay network database may provide (eg, 429) the requested issuer server data to the pay network server. In some implementations, the payment network server may utilize the issuer server data to generate a card authorization request (eg, 430 ) to redirect the card authorization request from the acquirer server to the issuer server via the user's virtual wallet card selection. The payment network server may provide the card authorization request (eg, 431 ) to the issuer server. In some implementations, the issuer server (e.g., 406) can parse the card authorization request and can query a database (e.g., user profile database 408) for data on the user's card account selected from the user's virtual wallet according to the request details, e.g., 432-433. For example, the issuer server may issue PHP/SQL commands similar to the examples provided below:

In some implementations, when the user data is obtained (eg, 434), the issuer server can determine whether the user can pay for the transaction by using funds available in the account (eg, 435). For example, the issuer server may determine whether the user has sufficient balance remaining in the account, has sufficient credit associated with the account, and the like. If the issuer server determines that the user can pay for the transaction using funds available in the account, the server provides an authorization message to the payment network server (eg, 436). 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 In this 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 can obtain the authorization message and parse the message to extract authorization details. When it is determined that the user has sufficient funds for the transaction, the payment network server generates transaction data records from the card authorization requests it receives and stores the authorization and transaction details associated with the transaction in the transaction database. For example, the payment network server may issue PHP/SQL commands similar to the following example listings to store transaction data in the database:

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

In some implementations, the server may also generate a purchase receipt (eg, 439 ) and provide the purchase receipt to the client (eg, 441 ). The client can present and display the purchase receipt to the user (eg, 442 ). For example, a client may present web pages, electronic messages, text/SMS messages, buffer voicemails, sound ringtones, and/or play audio messages, etc., and provide output including, but not limited to: sound, music, audio, video, Graphics, haptic feedback, vibrating alerts (eg, on vibrating client devices such as smartphones), etc.

Referring to FIG. 4C , in some implementations, the merchant server can initiate clearness of a batch of authorized transactions. For example, the merchant server may generate a bulk data request (eg, 443 ) and provide the request (eg, 444 ) to a database (eg, merchant database 409 ). For example, a merchant can query a relational database using PHP/SQL commands similar to the examples provided above. In response to a bulk data request, the database may provide the requested bulk data (eg, 445). Using the bulk data retrieved from the database, the server can generate a bulk clearing request, (eg, 446 ), and provide the bulk clearing request, (eg, 447 ) to the acquirer server (eg, 404 ). For example, the merchant server provides the acquirer server with an HTTP(S) POST message containing XML-formatted bulk data in the message body. Using the obtained batch clearing request, the acquirer server will generate a batch payment request (for example, 448 ), and provide the batch payment request (for example, 449 ) to the network payment server. The payment network server may parse the batch payment request and extract transaction data (eg, 450 ) for each transaction stored in the batch payment request. The payment network server may store transaction data (eg, 451 ) in a database (eg, transaction database 410 ) for each transaction. For each extracted transaction, the pay network server may query a database (eg, pay network database 407 ), eg, 452-453, for the address of the issuer server. For example, a payment web 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 generates a single payment request (eg, 454 ) and provides the individual payment request (eg, 455 ) to the issuer server (eg, 406 ). For example, a payment web server may provide an HTTP(S) POST request similar to the example provided below:

In some implementations, the issuer server can generate payment instructions (eg, 456). For example, the issuer server may issue a command to subtract funds from the user's account (or add a charge to the user's credit card account). The issuer server may issue payment instructions (eg, 457 ) to a database (eg, user profile database 408 ) that stores the user's account information. The issuer server can provide the funds transfer message to the payment network server (eg, 458), and the payment network server can forward the funds transfer message to the acquirer server (eg, 459). A sample HTTP(S) POST funds transfer message is provided below:

In some implementations, the acquirer server can parse the funds transfer message and associate the transaction with the merchant (eg, 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 (eg, 460).

5A-E show logic flow diagrams illustrating example aspects of using virtual wallet card selection to perform card-based transactions (e.g., Virtual Wallet-based Card Transaction Execution (“VW-CTE”) component 500) in some embodiments of the VWCS. . In some implementations, the user may provide user input (eg, 501 ) to the client indicating the user's desire to purchase a product from the merchant. The client may generate a purchase order message (eg, 502 ) and provide the generated purchase order message to the merchant server. In some implementations, the merchant server can obtain a purchase order message from the client (eg, 503 ), and can parse the purchase order message to extract details of the purchase order from the user. Example parsers available to merchant clients are discussed further below with reference to FIG. 6 . The merchant server may generate a card lookup request (eg, 504) to determine if the transaction can be processed. For example, the merchant server will process the transaction only if the user has sufficient funds in the account of the card from which the shopping order was provided to pay for the purchase. The merchant server may provide the generated card lookup request to the acquirer server. The acquirer server may parse the card lookup request (eg, 505). The acquirer server may generate a card authorization request (eg, 506 ) using the obtained card inquiry request, and provide the card authorization request to the payment network server.

In some implementations, the payment network server can obtain the card authorization request from the acquirer server and can parse the card authorization request to extract details of the request (eg, 507). For example, the payment network server can obtain the ID of the user, the account number of the card swiped by the user at the client terminal, and the like. The payment network server may attempt to determine whether the user has access to a virtual wallet from which the user may select a card to use to complete the purchase transaction. In some implementations, the pay network server can generate a query (eg, 508 ) to the pay network database to obtain virtual card selection options available to the user, as discussed above in the description with reference to FIG. 4A . In response to the virtual wallet card selection query (eg, 508 ), the payment network database may provide the requested virtual wallet card options to the payment network server (eg, 509 ). The payment network server may generate a request to select one of the payment option options from the user's virtual wallet (eg, 510 ) and provide the virtual wallet card selection request to the user device. For example, 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; this list of query results may be wrapped into a dynamic user Interface objects (eg, HTML, XML, CSS, etc. wrappers; see FIG. 4A, 422 ) capable of being rendered by the user device. In some implementations, the user device may present virtual wallet card selection options provided by the payment network database (eg, 511 ) and display the virtual wallet card selection options to the user (eg, 512 ). For example, a selection object may be presented in a display portion on the screen, eg, in a web-presented object view.

In some implementations, the user may provide a card selection input (eg, 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 (eg, 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 run out, resulting in a timeout. This may provide an element of security to the user's virtual wallet. If the user has timed out (eg, 515, option is yes), the server may determine whether the user has 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 resulted in successful authorization failures) more than a pre-specified threshold number of times (eg, 516 with option Yes), the payment network server may determine that the transaction must be canceled and generate an authorization to the merchant server Failure message (for example, 517). In some implementations, the payment network server determines that the user has timed out (and/or the number of timeouts 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 use The default option is to continue transaction processing. In some implementations, the payment network server may always use the user's default virtual wallet card selection and not attempt to contact the user through the user device to obtain the user selection. It should be understood, however, that different permutations and/or combinations of the features presented herein may be used in contacting the user to obtain authorization and to customize the selected card from the virtual wallet in order to take advantage of the security benefits and reduce the number of times the user is contacted in order to achieve the sought after Balance between transactions.

In some implementations, if the payment network server successfully captures user selection of a valid card account from the virtual wallet card selection option, the payment network server may obtain the virtual wallet card selection response from the user device and may parse the virtual wallet card selection response , to extract the details of the virtual wallet card selection. Using the extracted fields and field values, the payment network server may generate a query (eg, 518 ) for the issuer server corresponding to the user's card account. In response to the get issuer server query, the pay network database may provide (eg, 519 ) the requested issuer server data to the pay network server. In some implementations, the payment network server may utilize the issuer server data to generate a forward card authorization request (eg, 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 can parse the card authorization request (eg, 521 ) and can query a database with the user's card account (eg, 522 ) based on the request details. In response, the database may provide the requested user data (eg, 523). When obtaining user data, the issuer server can determine whether the user can pay for the transaction by using funds available in the account (eg, 524 ). For example, by comparing data from the database with transaction costs obtained from card authorization requests, the issuer server can determine whether the user has sufficient balance remaining in the account, has sufficient credit associated with the account, etc. If the issuer server determines that the user can pay for the transaction by using funds available in the account, the server can provide an authorization message to the payment network server (eg, 525).

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

In some implementations, the merchant server can initiate clearing of a batch of authorized transactions by generating a batch of data requests (eg, 540) and providing the request to a database. In response to the bulk data request, the database may provide the requested bulk data to the merchant server (eg, 541 ). Using the bulk data fetched from the database, the server generates a bulk clearing request (eg, 542) and provides the bulk clearing request to the acquirer server. By using the obtained batch clearing request, the acquirer server generates a batch payment request (for example, 544), and provides the batch payment request to the payment network server. The payment network server may parse the bulk payment request (eg, 545 ), select transactions stored in the bulk payment request (eg, 546 ), and extract transaction data for the transactions stored in the bulk payment request (eg, 547 ). The payment network server may generate a transaction data record (eg, 548 ) and store the transaction data in a database (eg, 549 ). For the fetched 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, (eg, 550 ). The payment network server may provide queries to the database. In response, the database will provide the issuer server data requested by the payment network server (eg, 551 ). The payment network server may generate a single payment request for a transaction for which it has extracted transaction data, (eg, 552 ), and provide the single payment request to the issuer server using the issuer server data from the database.

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

In some implementations, the payment network server may check to see if there are additional transactions in the batch that need to be cleared and reimbursed. If there are additional transactions (eg, 557, option yes), the payment network server may process each transaction according to the steps described above. The payment network server may generate (eg, 558 ) an aggregate funds transfer message reflecting the transfer of all transactions in the batch, and provide (eg, 559 ) the funds transfer message to the acquirer server. In response, the acquirer server transfers the funds specified in the funds transfer message to the merchant's account (eg, 560).

Figure 6 shows a user interface diagram showing 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 features displayed include: Wallet 601 , Social Integration via Twitter, Facebook, etc., Offers and Integrity 603 , Capture Mobile Purchases 604 , Alerts 605 , and Security, Settings and Analytics 696 . These characteristics are further explored below.

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

In one embodiment, for example, a user may select 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 middle user interface may provide a current list of items 715a-h in the user's shopping cart 711. A user may select an item (eg, item 715a) to view a product description 715j for the selected item and/or other items from the same merchant. Price and total payment information is also displayed along with a QR code 715k capturing the information needed to enable capturing the mobile purchase transaction.

Referring to FIG. 7B , in another embodiment, the user may select a billing option 716 . When the bill option 716 is selected, the user interface may display a list 716a-h of bills and/or receipts from one or more merchants. Next to each of the bills, additional information such as date of visit, presence of items from multiple stores, last bill payment date, automatic payment, number of items, etc. can be displayed. In one example, a wallet shopping statement dated January 20, 2011 is selected. The wallet shopping bill selection may display a user interface that provides various information about the selected bill. For example, the user interface may display a list of purchased items 716k, QR code encoded data 716i about those items, the total number of items and corresponding values 716j. For example, there are 7 items worth $102.54 in the selected wallet shopping statement. The user can now select any one of the items and buy again to increase the purchased items. The user may also refresh offers 716j to clear last invalid offers and/or search for new offers applicable to the current purchase. As shown in Figure 7B, the user may select two items for repeat purchases. When added, a message 716 may be displayed to confirm the addition of two items, which brings the total number of items in the shopping cart to fourteen.

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

等）的网站上查阅社交支付信息717p。消息可从各个社会网络和其它来源（例如，SMS，邮件）聚合。适于每个消息模式的兑换（redemption）的方法可随着社交支付信息一起被指示。在图7D的示图中，Joe接收的SMS717q Joe指示Joe可通过回复SMS并输入哈希标签值#1234来兑换获取的$5。在同一示图中，Joe还经由接收消息717r，其包括Joe可激活以发起$25支付的兑换的URL链接。In one implementation, the user may select Joe P for payment. Joe P, as shown in the user interface, has an email icon 717g next to his name indicating that Joe P accepts payment via email. When his name is selected, the user interface can display his contact information, such as email, phone, etc. If the user wishes to pay JoeP by means other than email, the user can add another transfer mode 717j to his contact information and make payment transfers. Referring to Figure 7D, the user may be provided with a screen 717k where the user may enter an amount to send to Joe, and add other text content to provide Joe with context for the payment transaction 717l. The user may, via user interface element 717m, select a mode (eg, SMS, email, social networking) via which Joe may be contacted. As the user types, the entered text may be viewed within GUI element 717n. When the user has finished entering the necessary information, the user can press the send button 717o to have Joe send the social information. If Joe also has a virtual wallet application, Joe may be able to use it within the application or directly on a social network (e.g., for Twitter ^™ ,

etc.) on the website of social payment information 717p. Messages may be aggregated from various social networks and other sources (eg, SMS, mail). The method of redemption appropriate for each message mode may be indicated along with the social payment information. In the diagram of FIG. 7D , Joe receives SMS 717q Joe indicates that Joe can redeem the acquired $5 by replying to the SMS and entering the hash tag value #1234. In the same diagram, Joe also passes A message 717r is received that includes a URL link to the redemption that Joe can activate to initiate a $25 payment.

Referring to FIG. 7E , in some other embodiments, the user may select a merchant 718 from a list of options in a shopping mode and a selection list of merchants 718a-e. In one implementation, the merchants on the list may be affiliated with, or have an affinity with, the wallet. In another implementation, merchants may include a list of merchants that meet user-defined or other criteria. For example, the list may be created by the user, the merchants where the user most frequently shopped or spent an excess amount x, or shopped for three consecutive months, etc. In one implementation, the user may further select one of the merchants, such as Amazon 718a. The user can then navigate the entire merchant's listing to find items of interest, such as 718f-j. Directly through the wallet without accessing the merchant site from a separate page, the user can select items 718j from Amazon 718a's catalog. As shown in the rightmost user interface of Figure 7D, the selected item may be added to a shopping cart. Message 718k indicates that the selected item has been added to the shopping cart and that the updated number of items in the shopping cart is now thirteen.

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 list of businesses that are geographically very close to the user. For example, the list of businesses 719a-e may be businesses located near the user. In one implementation, the mobile application may further identify based on the user's location when the user is in the store. For example, location icon 719d may be displayed near a store (eg, Walgreens) when the user is very close to the store. In one implementation, the mobile application may periodically refresh its location as the user moves away from the store (eg, Walgreens). In a further implementation, the user can navigate through the mobile application to select Walgreens store offers. For example, a user may navigate items 5719f-j available on Walgreens aisle 5 by using the mobile application. In one implementation, the user can select corn 719i from his or her mobile application to add to cart 719k.

Referring to FIG. 7G, in another embodiment, a local proximity option 719 may include a store map and a real-time map feature among others. For example, when selecting a Walgreens store, the user may start an aisle map 7191 that shows the organization of the store and the location of the user (indicated by the yellow circle). In one implementation, a user can easily configure the map to add one or more other users (eg, the user's children) to share each other's locations within the store. In another implementation, the user may have the option to start a store 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 the user is about to enter aisle 5, the store view map may display a diagram of aisle 5. In addition, the user can manipulate the orientation of the map to move the store view forward, backward, right, left, and clockwise and counterclockwise by using the navigation tool 719o.

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 can provide the user with multiple options for paying for transactions via wallet mode 810 . In one implementation, an example user interface 811 for making a payment is displayed. The user interface can explicitly identify the amount 812 and currency 813 for the transaction. The amount may be an amount payable, and the currency may include real money such as dollars and euros, and virtual money such as reward points. The amount of the transaction 814 may also be prominently displayed 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, gift, rewards, and/or prepaid cards. Users may also have the option to pay in whole or in part with reward points. For example, a graphical indicator 818 on the user interface shows the number of points available, a graphical indicator 819 shows the number of points to be used for the amount due to pay 234.56 and the number of points in a selected currency (USD, for example) the equivalent of .

In one implementation, a user may combine funds from multiple 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 so far through the selected form of payment (eg, Discover Card and Rewards 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 payment forms.

In one implementation, the user may select a secure transaction authorization by selecting the hide button 822 to effectively hide or obscure some (e.g., pre-configured) or all identifying information such that when the user selects the pay button 821, the transaction is authorized in Do it 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 about the transaction can be sent to one of more social networks (set by the user), which can be in the form of a social forum (such as a wall post or twitter) to post or announce a purchase. In one implementation, the user may select the social payment processing option 823. Indicator 824 may show authorization and sending social sharing data in progress.

In another implementation, for certain purchases, such as prescription purchases, the restricted payment mode 825 will be activated. The schema is activated according to rules defined by issuers, insurers, merchants, payment processors, and/or other entities to facilitate the processing of specific goods and services. In this mode, the user may scroll down the list of forms of payment under the Funds tab to select a specialized account such as a Flexible Spending Account (FSA) 827, Health Savings Account (HAS), etc. and the amount to be debited to the selected The amount of the 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 can facilitate the import of funds via the import funds user interface 828 . For example, a user who is unemployed can access unemployment benefits funds 829 via the wallet mobile application. In one implementation, as indicated by process indication message 830, the entity providing the funds may also configure rules for using the funds. The wallet can read and apply previous rules, and can reject any purchases with unemployment funds that do not meet the criteria set by the rules. Example criteria may include, for example, Merchant Category Code (MCC), time of transaction, location of transaction, and the like. 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 declined.

Referring to Figure 8B, in one embodiment, the wallet mobile application can facilitate dynamic payment optimization based on factors such as user location, preferences, currency value preferences. For example, when the user is in the United States, the country indicator 831 may display the flag of the United States and set the currency 833 to the United States. In a further implementation, the wallet mobile application can automatically rearrange the order 835 in which the forms of payment are enumerated to reflect the popularity or acceptance of the various forms of payment. In one implementation, the ranking may reflect the user's preferences, which cannot be changed by the wallet mobile application.

Likewise, when a German user operates the wallet in Germany, the mobile wallet application user interface can be dynamically updated to reflect the country 832 and currency 834 of operation. In a further implementation, the wallet application may rearrange the order in which different forms of payment 836 are enumerated based on their acceptance in the country. Of course, the order of these forms of payment can be modified by the user to suit his or her own preferences.

Referring to FIG. 8C , in one embodiment, a Payee tab 837 in the wallet mobile device application user interface may facilitate the user's selection of one or more payees to receive funds selected in the funds tab. In one implementation, the user interface may display a list of all payees 838 that the user has previously transacted with or is able to transact with. The user can then select one or more payees. Payees 838 may include larger merchants such as Amazon.com Inc. as well as individuals such as Jane P. Doe. Next to each payee name, a list of acceptable payment modes for the payee may be displayed. In one implementation, the user may select a payee, Jane P. Doe 839, for receiving payments. When selected, the user interface may display additional identifying information associated with the payee.

Referring to Figure 8D, in one embodiment, a mode tab 840 may facilitate selection of payment modes accepted by the payee. A large number of payment modes are available. Example modes include: Bluetooth 841, Wireless 842, QR Code 843 via User's Snap Movement, Security Chip 844, Twitter 845, Near Field Communication (NFC) 846, Cellular 847 Snap, QR Code via User's Snap Movement 848, USB849 and FACEBOOK850, and others. In one implementation, only payment modes accepted by the payee may be selected by the user. Other unacceptable payment modes may be disabled.

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

Referring to FIG. 8F , in one embodiment, social tags 855 can facilitate integration of the wallet application with social channels 856 . In one implementation, the user can select one or more social channels 856 and can log in to the selected social channels from the wallet application by providing the social channel username and password 857 and login 858 to the wallet application. Users can then use the social buttons 859 to send or receive money through the integrated social channels. In a further implementation, users can send socially shared data, such as purchase information or links, through integrated social channels. In another embodiment, user-provided login credentials may allow the VWCS to participate in intercept resolution.

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

In one implementation, a user may select a transaction (eg, transaction 915) to view details of the transaction. For example, a user may view details of the items associated with the transaction and the amount 916 of each item. In a further implementation, the user can select the display option 917 to view actions 918 that the user can take with respect to the transaction or items in the transaction. For example, a user may add a photo to a transaction (eg, the user's photo and the user's purchase of an iPad). In a further implementation, if the user has previously shared a purchase via a social channel, a post including a photo may be generated and sent to the social channel for publication. In one implementation, any sharing may be optional, and a user who has not shared purchases via social channels can still share photos via one or more social channels of his or her choice directly from the wallet application's history mode. In another implementation, the user may add transactions to categories such as business expenses, household expenses, travel expenses, or other categories set up by the user. Such a grouping facilitates settlement of year-end expenses, submission of work expense reports, submission of value-added tax (VAT) refunds, personal expenses, etc. In yet another implementation, the user may purchase one or more items purchased in the transaction. The user can then perform the transaction without having to go to the merchant's directory or site to find the item. In a further implementation, the user may also place one or more items in the transaction into a shopping cart for future purchases.

In another embodiment, a history mode may provide a facility for obtaining and displaying ratings of items in a transaction. The source of the rating may be the user, the user's friends (eg, from social channels, contacts, etc.), reviews aggregated from the web, etc. The user interface may also, in some implementations, allow users to post messages to other users of social channels such as Twitter or Facebook. For example, display area 920 shows Facebook messages being exchanged between two users. In one implementation, the user may share the link via message 921 . Selecting such a product-linked message may allow the user to view a product's description and/or purchase the product directly from the history mode.

In one embodiment, the history mode may also include a tool for exporting receipts. The export receipt popup 922 may provide a number of options for exporting receipts for historical transactions. For example, the user may use one or more of options 925 including: save (to local removable storage, server, cloud account, etc.), print to printer, fax, email, etc. A user can use his or her address book 923 to look up email or fax numbers for export. The user may also specify format options 924 for exporting receipts. Example format options include, but are not limited to: text files (.doc, .txt, .rtf, .iif, etc.), spreadsheets (.csv, .xls, etc.), image files (.jpg, .tff, .png, etc.), Portable Document Format (.pdf), postscript (.ps), etc. The user can then click or tap the export button 927 to initiate the export of the receipt.

10A-E show user interface diagrams illustrating example features of a virtual wallet application in capture mode in some embodiments of the VWCS. Referring to FIG. 10A, in one embodiment, a user may select capture mode 2110 to access its capture features. Capture mode can handle arbitrary machine-readable table data representations. 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, etc. The capture mode can 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 Figure 10A. The user can take a picture of the QR code 1015 and/or the barcode 1014 using his or her mobile phone. In one implementation, a bar 1013 and a capture box 1015 can help the user correctly capture the code. For example, capture block 1015 as shown does not capture all of code 1016 . Thus, a code captured in this view may not be analyzable since the information in the code may be incomplete. This is indicated by a message on bar 1013 indicating that capture mode is still looking for a code. When the code 1016 is fully framed by the capture box 1015, the message may be updated, eg, the capture was found. In one implementation, when a code is found, the user can initiate code capture by using the mobile device camera. In another implementation, the capture mode can automatically capture codes by using the mobile device camera.

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

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

In one implementation, the wallet application may perform optical character recognition (OCR) of the receipt when the reallocate button 1025 is selected. The items in the receipt may then be examined to identify which payment device or account of one or more items may be charged to which payment device or account for tax benefit or other benefits such as cashback, reward points, and the like. In this example, there is a tax benefit if prescription drugs that are charged to the user's Visa card are charged to the user's FSA account. The wallet application can then perform the redistribution as a backend. The reallocation process may include the wallet contacting the payment processor to debit the amount of the prescription to the Visa card and debit the same amount to the user's FSA account. In an alternate implementation, a payment processor (eg, Visa or MasterCard) may capture and OCR the receipt, identify the payment account and item for reallocation, and perform the reallocation. In one implementation, the wallet application may request the user's confirmation to reallocate the fee for the selected item to another payment account. Receipt 1027 may be generated after the reallocation process is complete. As discussed, the receipt shows that some charges were moved from the Visa account to the FSA.

Referring to FIG. 10C , in one embodiment, the capture mode can 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 can be displayed at a merchant POS terminal, website, or web application, and can be encoded with information identifying the item purchased, merchant details, and other relevant information. When a user captures, for example, a QR code, the capture mode can decode the information in the QR code and can use the decoded information to generate a receipt 1032 . Once the QR code is recognized, the navigation bar 1031 may indicate that the payment code is recognized. The user may now have options to add to shopping cart 1033, pay 1034 with default payment account or pay 1035 with wallet.

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

Referring to Figure 10D, in one embodiment, capture mode can also facilitate providing identification, application, and storage for future use. For example, in one implementation, a user may capture an offer code 1041 (eg, barcode, QR code, etc.). The wallet application can then generate offer text 1042 from the information encoded in the offer code. The user can perform many operations on this provisioning code. For example, the user uses the search button 1043 to search for all merchants that accept the provided code, nearby merchants that accept the provided code, products of merchants that match the provided code, and the like. The user can also apply the code to items currently in the shopping cart by using the add to cart button 1044. Additionally, the user may also save the offer for future use by selecting the save button 1045 .

In one implementation, after an offer or coupon 1046 is applied, the user may have the option to find eligible merchants and/or products via a lookup, the user may enter the wallet using 1048, and the user may also save the offer or coupon 1046 for later use.

Referring to Figure 10E, in one embodiment, the capture mode may also provide tools for adding funding sources 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 a code 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, rewards balance, etc. In one implementation, the code can be found on the side of the physical payment card. In another implementation, the code can 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, the user can capture a picture of the code. The wallet application can recognize the payment card 1051 and can display textual information 1052 encoded in the payment card. The user may then perform verification of the information 1052 by selecting a verification button 1053 . In one implementation, verification may include contacting the issuer of the payment card to confirm the decoded information 1052 and any other relevant 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 the 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 can also cancel the import of a payment card as a funding source by selecting the cancel button 1055 . When the payment card has been added to the wallet, the user interface may be updated to indicate via notification display 1056 that the import is complete. The user can then access wallet 1057 to begin using the added payment card as a funding source.

Figure 11 shows a user interface diagram illustrating example features of a virtual wallet application in provisioning mode in some embodiments of the VWCS. In some implementations, the VWCS may allow users to search for product and/or service offerings in the virtual wallet mobile application. For example, a user may enter text into graphical user interface ("GUI") element 1111, or issue a voice command by activating GUI element 1112 and speaking the command into the device. In some implementations, the VWCS may provide offers based on the user's previous behavior, demographics, current location, current shopping cart selections or purchased items, and the like. For example, if a user is in a physical store or an online shopping site, and leaves the (virtual) store, then the merchant associated with the store expects to offer a sweetener deal to entice the consumer back to the (virtual) store. A merchant may provide such an offer 1113. For example, the offer may provide a discount and may include an expiration time. In some implementations, other users may provide the user with a user redeemable gift (eg, 1114 ). In some implementations, the offerings section can include an alert (eg, 1115 ) regarding payment of outstanding funds to other users. In some implementations, the offers section may include an alert (eg, 1116 ) about requesting receipt of funds from other users. For example, such features may identify funds receivable from other applications (eg, mail, calendar, tasks, notes, reminders, alarms, etc.), or through manual input by the user to the virtual wallet application. In some implementations, the offers portion can provide offers from participating merchants in the VWCS (eg, 1117-1119, 1120). These offers can sometimes be put together by using a combination of participating merchants, eg, 1117. In some implementations, the VWCS itself may provide offers (eg, 1120 ) from within the virtual wallet application to users dependent on users utilizing a particular form of payment.

12A-B show user interface diagrams illustrating example features of a virtual wallet application in a secure and private mode in some embodiments of the 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 user interface elements. For example, a user may be able to view/modify username (eg, 1211a-b), account number (eg, 1212a-b), user security access code (eg, 1213-b), user pin (eg, 1214-b), User address (e.g., 1215-b), social security number associated with the user (e.g., 1216-b), current device GPS location (e.g., 1217-b) user account at the merchant where the user is currently staying (e.g., 1218 -b), the user's rewards account (eg, 1219-b), etc. In some implementations, a user may be able to select which data fields and their associated values should be communicated to facilitate a purchase transaction, thereby providing the user with enhanced data security. For example, in the example illustration of FIG. 12A , the user has selected Name 1211a, Account Number 1212a, Security Code 1213a, Merchant Account ID 1218a, and Rewards Account ID 1219a as fields (to be sent as part of the notification) to process the purchase transaction. In some implementations, the user can toggle the fields and/or data values sent as part of the notification to process the purchase transaction. In some implementations, the application may present 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 can provide the VWCS with the user's GPS location. Based on the user's GPS location, the VWCS can determine the user's environment (eg, whether the user is in a store, doctor's office, hospital, postal service office, etc.). Based on the circumstances, the user application can present the user with appropriate fields from which the user can select fields and/or field values to send as part of the purchase order transmission.

For example, a user may go to a doctor's office and expect to pay a co-pay for the doctor's appointment. In addition to basic transaction information such as account number and name, applications can provide users with the ability to choose to transfer medical records, health information, which can be provided to medical providers, insurance companies, and transaction processors to coordinate payments between multiple parties . In some implementations, records may be sent in a Health Insurance Portability and Accountability Act (HIPAA) compliant data format and encrypted, and only recipients authorized to view such records may have the appropriate decryption key to decrypt and view the private User Info.

消息、Twitter^TM推特、文本聊天、语音聊天、视频聊天（例如，Apple FaceTime）等与用户通信。例如，VWCS可向用户发起视频挑战（例如，1221）。例如，用户需要经由视频聊天展示他/她自身（例如，1222）。在一些实现中，客户服务代表（例如，代理1224）可人工地确定使用用户的视频的用户的真实性。在一些实现中，VWCS可利用脸、生物计量等识别（例如，使用模式分类技术）来确定用户的身份。在一些实现中，应用可提供参照标记（例如，十字准线、目标框等）（例如，1223），使得用户可视频以促进VWCS的用户自动识别。在一些实现中，用户可能没有发起交易，例如，该交易是诈骗性的。在这样的实现中，用户可取消挑战。VWCS接着可取消交易，和/或代表用户发起诈骗调查过程。Referring to Figure 12B, in some implementations, an application executing on the user's device can provide a chat verification feature to prevent fraud. For example, VWCS can detect unusual and/or suspicious transactions. The VWCS can utilize the chat verification feature to communicate with the user and verify the authenticity of the originator of the purchase transaction. In various implementations, the VWCS can send email messages, text (SMS) messages,

Messages, Twitter ^TM tweets, text chats, voice chats, video chats (eg, Apple FaceTime), etc. to communicate with users. For example, the VWCS may initiate a video challenge (eg, 1221 ) to the user. For example, a user needs to present himself/herself via video chat (eg, 1222 ). In some implementations, a customer service representative (eg, agent 1224 ) may manually determine the authenticity of the user using the user's video. In some implementations, the VWCS may utilize facial, biometric, etc. recognition (eg, using pattern classification techniques) to determine the user's identity. In some implementations, the application can provide reference markers (eg, crosshairs, target boxes, etc.) (eg, 1223 ) so that the user can video to facilitate automatic user identification of the VWCS. In some implementations, the user may not have initiated the transaction, eg, the transaction was 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.

消息、Twitter^TM推特等与用户通信。VWCS可对于用户提出挑战问题（例如，1226）。应用可提供用户输入界面元素（例如，虚拟键盘1228）以回答由VWCS所提出的挑战问题。在一些实现中，挑战问题可由VWCS自动地随机选择；在一些实现中，客户服务代表可人工地与用户通信。在一些实现中，用户可能没有发起交易，例如，该交易是诈骗性的。在这样的实现中，用户可取消文本挑战。VWCS可代表用户取消交易，和/或发起诈骗调查过程。In some implementations, the VWCS may utilize a text challenge process to verify the user's authenticity (eg, 1225). For example, VWCS can be accessed via text chat, SMS message, email,

Messages, Twitter ^TM tweets, etc. communicate with users. The VWCS may pose challenge questions (eg, 1226) to the user. The application may provide user input interface elements (eg, virtual keyboard 1228 ) to answer challenge questions posed by the VWCS. In some implementations, challenge questions can be randomly selected automatically by the VWCS; in some implementations, a customer service representative can communicate with the user manually. In some implementations, the user may not have initiated the transaction, eg, the transaction was fraudulent. In such an implementation, the user may cancel the text challenge. VWCS may cancel transactions on behalf of users, and/or initiate a fraud investigation process.

13 shows a data graph diagram illustrating example aspects of converting user checkout request input to checkout data display output via a user purchase checkout ("UPC") component. In some embodiments, a user (eg, 1301a ) may desire to purchase a product, service, offer, etc. (product) from a merchant through the merchant's online website or the merchant's store. A user may communicate (eg, 1303a) with a merchant/acquirer (merchant) server through a client such as, but not limited to: personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, etc. (eg, 1302) . For example, a user may provide user input (eg, checkout input 1311 ) to the client indicating the user's desire to purchase the product. In various implementations, user input may include, but is not limited to: a single tap of a touch screen interface (e.g., tap mobile app purchase embodiment), keypad entry, swiping a card, activation of RFID/NFC-enabled hardware devices within the user device (e.g. electronic cards with multiple accounts, smartphones, tablets, etc.), mouse clicks, key presses on joysticks/game consoles, voice commands, single/multiple touch gestures on touch-sensitive interfaces, touch sensing Touch UI elements on the display, etc. As one example, a user in a merchant store may scan a product barcode for a product through a barcode scanner at 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 checkout the items in the (virtual) shopping cart. For example, a user may activate a user interface element provided by the client to indicate a desire to complete checkout of the user's purchase. The client may generate a checkout request (eg, 1312 ) and provide the checkout request to the merchant server (eg, 1313 ). For example, the client may provide a (secure) Hypertext Transfer Protocol (HTTP(S)) POST message including product details to the merchant server in the form of data formatted according to Extensible Markup Language (XML). An example listing of a checkout request 1312, substantially in the form of an HTTP(S) POST message including XML formatted data, is provided below:

In some embodiments, the merchant server may obtain the checkout request from the client and extract the checkout details (eg, XML data) from the checkout request. For example, the merchant server may utilize a parser such as the example parser described below in the discussion with reference to FIG. 19 . Based on parsing the checkout request 1312, the merchant server may extract product data (eg, product identifier) and available PoS client data from the checkout request. In some embodiments, using the product data, the merchant server may query (e.g., 1314) a merchant/acquirer (“merchant”) database (e.g., 1303b ) to obtain product data (e.g., 1315 ), such as product information, product prices, Sales tax, incentives, discounts, rewards, and/or other information to process purchases and/or provide value-added services to users. For example, the merchant database may be a relational database responsive to Structured Query Language ("SQL") commands. The merchant server may execute a hypertext preprocessor (PHP) script that includes SQL commands to query database tables (such as Figure 19, Product 1919l ) for product data. An example product data query 1314, essentially in PHP/SQL, is provided below:

In some embodiments, in response to obtaining the product data, the merchant server generates (eg, 1316 ) checkout data to provide to the PoS client. In some implementations, such checkout data (e.g., 1317) may be contained in part 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, incentives, value-added service information, etc.) and input fields that provide payment information to process purchases (such as account holder name, account number, billing address, shipping address, tip amount, etc.). In some embodiments, checkout data may be partially included in a Quick Response (QR) code image displayable by the PoS client so that the user may use the user's device to capture the QR code to obtain merchant and/or product data to generate a 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 transaction-specific URLs 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 FIGS. 15-16 . The URL may point to a web page, data file, executable script, etc. stored on the merchant's server dedicated to the transaction that 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 purchased, purchase cost, expiry, order processing status, and the like. Thus, by passing the URL of the webpage to the payment network, the merchant server can 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 can navigate to the URL on the user's device to obtain alerts and other information related to the user's purchases, such as offers, coupons, related products, reward notifications, and the like. The following provides an example enumeration of checkout data 1317 substantially in the form of XML formatted data:

When acquiring checkout data (eg, 1317 ), the PoS client presents and displays (eg, 1318 ) the checkout data to the user.

14 shows a logic flow diagram illustrating example aspects of converting user checkout request input to a display of checkout data 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 the merchant's online website or the merchant's store. Users can communicate with the merchant/acquirer (merchant) server through the PoS client. For example, a user may provide user input (eg, 1401 ) to the client indicating the user's desire to purchase the product. The client generates a checkout request (eg, 1402), and provides the checkout request to the merchant server. In some embodiments, the merchant server may obtain the checkout request from the client and extract the checkout details (eg, XML data) from the checkout request. For example, the merchant server may utilize a parser such as the example parser described below in the discussion with reference to FIG. 19 . Based on parsing the checkout request, the merchant server can extract product data (eg, product identifier) and available PoS client data from the checkout request. In some embodiments, using the product data, the merchant server may query (e.g., 1403) a merchant/acquirer (“merchant”) database for product data (e.g., 1404 ), such as product information, product prices, sales tax, incentives , discounts, rewards, and/or other information to process purchase transactions and/or provide value-added services to users. In some embodiments, in response to obtaining the product data, the merchant server generates (eg, 1405 ) checkout data to provide (eg, 1406 ) to the PoS client. When acquiring the checkout data, the PoS client presents and displays (eg, 1407 ) the checkout data to the user.

15A-B show data graph schematic diagrams illustrating example aspects of converting user virtual wallet access inputs into purchase transaction receipt notifications via a purchase transaction authorization ("PTA") component. Referring to FIG. 15A , in some embodiments, a user (eg, 1501a ) may desire to purchase a product, service, offer, etc. (product) from a merchant using a virtual wallet card account through the merchant's online website or the merchant's store. A user may utilize a physical card or a user wallet device (eg, 1501b) to access the user's virtual wallet account. For example, a user wallet device may be a personal computer/laptop, cell phone, smart phone, tablet, e-book reader, netbook, game console, and the like. A user may provide a wallet access input (eg, 1511 ) to the user wallet device. In various embodiments, user input may include, but is not limited to: a single tap of a touch screen interface (e.g., tap mobile app purchase embodiment), keypad entry, swiping a card, activation of RFID/NFC-enabled hardware within the user device Devices (e.g. digital cards with multiple accounts, smartphones, tablets, etc.), mouse clicks, key presses on joysticks/game consoles, voice commands, single/multiple touch gestures on touch-sensitive interfaces, touch Sensing touch user interface elements on the display, 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.

In some embodiments, when the user is authenticated for accessing the virtual wallet feature, the user wallet device may provide a transaction authorization input, eg, 1514, to a point-of-sale (PoS) client (eg, 1502 ). 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 the like. In embodiments where the user utilizes a plastic card instead of the user's wallet device, the user can swipe the plastic card at the PoS client to transfer information from the plastic card to the PoS client. For example, a PoS client may obtain Track 1 data from a user's plastic card (e.g., credit card, debit card, prepaid card, payment card, etc.) as transaction authorization input 1514, such as the example Track 1 data provided below:

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

(wherein '123456789012345' is the card number of 'J.Q.Public' and has a CVV number of 901. '990112' is the service code, and *** represents a decimal number that changes randomly every 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, which is captured according to a data format protocol suitable for the communication mechanism employed in the communication between the user wallet device and the PoS client. format. An example listing of transaction authorization input 1514 substantially in the form of XML formatted data is provided below:

In some embodiments, the PoS client may generate a card authorization request (eg, 1515 ), and/or product/checkout data (see, eg, FIG. 13 , 1315-1317 ) using transaction authorization input obtained from the user's wallet device. . An example enumeration of card authorization requests 1515-1516, substantially in the form of HTTP(S) POST messages including XML formatted data, is provided below:

In some embodiments, a card authorization request generated by a user device may include the minimum information required to process a purchase transaction. For example, this can increase the efficiency of communicating purchase transaction requests, and can also advantageously increase the privacy protections provided to users and/or merchants. For example, in some embodiments, the card authorization request may include at least one session ID for the user's shopping session with the merchant. This session ID can be utilized by any component and/or entity with appropriate access to the secure site on the merchant's server to obtain alerts, reminders, and/or other data about transactions during the user's and merchant's shopping session. In some embodiments, the PoS client may provide the generated card authorization request to the merchant server (eg, 1516). The merchant server may forward the card authorization request (eg, 1504a) 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 payment networks such as Visa, Mastercard, American Express, Paypal, etc. to process various types of transactions, including but not limited to: credit card, debit card, prepaid card, B2B, etc. transactions. In some embodiments, the merchant server may query the database for the network address of the payment gateway server (e.g., merchant/receiver Unilateral database 1503b). For example, the merchant server may issue a PHP/SQL command to query a database table for the URL of the payment gateway server (such as Figure 19, payment gateway 1919h). An example payment gateway address query 1517 is provided below, substantially in the form of a PHP/SQL command:

In response, the merchant/acquirer database may provide the requested payment gateway address (eg, 1518). The merchant server forwards the card authorization request (eg, 1519) to the payment gateway server using the address provided. 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. 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 the payment network server (eg, 1505a) for payment processing. For example, the payment gateway server can select from payment networks such as Visa, Mastercard, American Express, Paypal, etc. to process various types of transactions, including but not limited to: credit card, debit card, prepaid card, B2B, etc. transactions. In some embodiments, the payment gateway server may query the database for the network address of the payment gateway server (e.g., payment Gateway Database 1504b). For example, the payment gateway server may issue a PHP/SQL command to query a database table (such as Figure 19, payment gateway 1919h) for the URL of the payment gateway server. An example payment network address query 1521 is provided below, substantially in the form of a PHP/SQL command:

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

Referring to Figure 15B, in some embodiments, the payment network server may process the transaction to transfer funds for the purchase to 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, proceeds of transactions processed by the merchant may be deposited into an account maintained by the acquirer's server.

In some embodiments, the payment network server generates a query (eg, 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 the user's account. For example, these accounts may include, but are not limited to: credit cards, debit cards, prepaid cards, checking, savings, money market, certificates of deposit, storage (cash) accounts, and the like. The issuer's issuer server (eg, 1506a) may maintain user account details. In some embodiments, a database (eg, payment network database 1505b) may store details of issuer servers associated with issuers. In some embodiments, the payment network server may query the database for the network address of the issuer server (e.g., payment network database 1505b). For example, the merchant server may issue a PHP/SQL command to query a database table (such as Figure 19, issuer 1919f) for the network address of the issuer server. An example issuer server address query 1524 is provided below, substantially in the form of a PHP/SQL command:

In response to the get issuer server query (eg, 1524), the pay network database may provide (eg, 1525) the requested issuer server data to the pay network server. In some embodiments, the payment network server may utilize issuer server data to generate a payment 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 entry. Funds Authorization Request (eg, 1526), and provides the Funds Authorization Request to the issuer server. In some embodiments, the funds authorization request includes details such as, but not limited to, the user's expenses involved in the transaction, details of the user's card account, user billing and/or shipping information, and the like. An example enumeration of funds authorization request 1526, substantially in the form of an HTTP(S) POST message including XML formatted data, is provided below:

In some implementations, the issuer server can parse the authorization request and can query a database (eg, user profile database 1506b ) based on the request details for data associated with the account linked to the user. For example, the merchant server may issue PHP/SQL commands to query a database table (eg, Figure 19, Account 1919d ) for user account data. An example user account query 1527 is provided below, essentially in the form of a PHP/SQL command:

In some embodiments, when obtaining user account data (eg, 1528), the issuer server may determine whether the user can 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, has sufficient credit associated with the account, and the like. Based on this determination, the issuer server may provide a funds authorization response to the payment network server (eg, 1530). For example, the issuer server may provide an HTTP(S) POST message similar to the above example. In some embodiments, if at least one issuer server determines that the user cannot pay for the transaction 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 provides a new payment option), and authorization for the purchase transaction is attempted again. 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, user device, and/or client.

In some embodiments, the payment network server may obtain a funds authorization response including notification of successful authorization, and parse the message to extract authorization details. When it is determined that the user has sufficient funds for the transaction (for example, 1531), the payment network server may invoke components 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 and transaction details associated with the transaction in a transaction database. For example, the payment web server may issue PHP/SQL commands to store data to a database table (such as Figure 19, transaction 1919i). The following provides an example transaction store command basically in the form of a PHP/SQL command:

In some embodiments, the payment network server may forward the transaction authorization response (eg, 1532 ) to the user wallet device, the PoS client, and/or the merchant server. The merchant can take this transaction authorization response and determine from it that the user has sufficient funds in the card account to carry out the transaction. The merchant server may add a record of the user's transactions to a batch of transaction data related to authorized transactions. For example, a merchant may add XML data related to user transactions to an XML data file (e.g., 1533) containing XML data for transactions that individual users have authorized, and store the XML data in a database (e.g., merchant database 404) file (for example, 1534). For example, a bulk XML data file similar to the example XML data structure template provided below can be constructed:

In some embodiments, the server may also generate a purchase receipt (eg, 1533 ) and provide the purchase receipt to the client (eg, 1535 ). The client may present and display the purchase receipt for the user (eg, 1536). In some embodiments, the user's wallet device may also provide the user with a notification of successful authorization. For example, a PoS client/user device may present web pages, electronic messages, text/SMS messages, buffer voicemails, sound ringtones, and/or play audio messages, etc., and provide output including, but not limited to: sound, music, Audio, video, images, tactile feedback, vibrating alerts (eg, on vibrating client devices such as smartphones), etc.

16A-B show logic flow diagrams illustrating example aspects of converting user virtual wallet access inputs into purchase transaction receipt notifications 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's online website or in a merchant's store to purchase products, services, items for sale, etc. ("products"). A user may utilize a physical card or a user wallet device to access the user's virtual wallet account. For example, a user wallet device may be a personal computer/laptop, cell phone, smart phone, tablet, e-book reader, netbook, game console, and the like. A user may provide a wallet access input (eg, 1601 ) to the user wallet device. In various embodiments, user input may include, but is not limited to: a single tap of a touch screen interface (e.g., a tap mobile app purchase embodiment), keypad entry, swiping a card, activation of an RFID/NFC equipped hardware device within the user device ( e.g. electronic cards with multiple accounts, smartphones, tablets, etc.), mouse clicks, button presses on joysticks/game consoles, voice commands, single/multi-touch gestures on touch-sensitive interfaces, touch-sensitive displays On-screen touch UI elements, 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 (eg, 1602-1603).

In some embodiments, when a user is authenticated to access a virtual wallet feature, the user wallet device may provide a transaction authorization input to a point-of-sale (PoS) client (eg, 1604 ). 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 the like. In embodiments where the user utilizes a plastic card instead of the user's wallet device, the user can swipe the plastic card at the PoS client to transfer information from the plastic card to the PoS client. In an embodiment where the user utilizes a user wallet device, the user wallet device may provide the PoS client with payment information that is stored according to a data format protocol suitable for the communication mechanism used between the user wallet device and the PoS client. format.

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 (eg, 1605). For example, a PoS client may utilize a resolver such as the example resolver provided in the discussion below with reference to FIG. 19 . Using transaction authorization input and/or product/checkout data captured from the user's wallet device (see, eg, FIG. 13, 1315-1317), the PoS client may generate a card authorization request (eg, 1606).

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 payment networks such as Visa, Mastercard, American Express, Paypal, etc. to process various types of transactions, including but not limited to: credit card, debit card, prepaid card, B2B, etc. transactions. In some embodiments, the merchant server may query the database for the network address of the payment gateway server (eg, 1608 ), for example, by using part of the user's payment card number or user ID (such as an email address) as a key for the database lookup. In response, the merchant/acquirer database may provide the requested payment gateway address (eg, 1610). The merchant server can 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 components to provide one or more services associated with purchase transaction authorization (eg, 1611 ). For example, the payment gateway server may invoke components for fraud prevention (see eg 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 (eg, 1614). For example, the payment gateway server may be able to select from payment networks such as Visa, Mastercard, American Express, Paypal, etc. to process various types of transactions, including but not limited to: credit card, debit card, prepaid card, B2B, etc. transactions. In some embodiments, the payment gateway server may query the database (eg, 1612 ) for the network address of the payment network server, eg, by using the user's payment card number or user ID (such as an email address) as a key for the database lookup. In response, the payment gateway database may provide the requested payment network address (eg, 1613). The payment gateway server may forward the card authorization request to the payment network server by using the provided address (eg, 1614).

Referring to Figure 16B, in some embodiments, the payment network server may process the transaction to transfer funds for the purchase to 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, proceeds of transactions processed by the merchant may be deposited into an account maintained by the acquirer's server. In some embodiments, the payment network server may generate a query (eg, 1615 ) for an 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 issued the user's account. For example, such accounts may include, but are not limited to: credit cards, debit cards, prepaid cards, checking, savings, money market, certificates of deposit, stored (cash) value accounts, and the like. The issuer's issuer server maintains details of the user's account. In some embodiments, a database (eg, a payment network database) may store details of issuer servers associated with issuers. In some embodiments, the payment network server may query the database (eg, 1615 ) for the issuer server's network address, eg, by using the user's payment card number or user ID (such as an email address) as a key for the database lookup.

In response to the get issuer server query, the pay network database may provide the pay network server with the requested issuer server data (eg, 1616). In some embodiments, the payment network server may utilize issuer server data for each of the issuer servers selected based on predefined payment settings associated with the user's virtual wallet, and/or the user's input of payment options. to generate a funds authorization request (eg, 1617 ), and provide the funds authorization request to the issuer server. In some embodiments, the funds authorization request may include details such as, but not limited to, the user's expenses involved in the transaction, the user's card account details, user billing and/or shipping information, and the like. In some embodiments, the issuer server may parse the authorization request (eg, 1618 ) and based on the request details may query a database for data associated with the account linked to the user (eg, 1619 ).

In some embodiments, when obtaining user account data (eg, 1620), the issuer server may determine whether the user can pay for the transaction by using funds available in the account (eg, 1621). For example, the issuer server may determine whether the user has sufficient balance remaining in the account, has sufficient credit associated with the account, and the like. Based on this determination, the issuer server may provide a funds authorization response to the payment network server (eg, 1622). In some embodiments, if at least one issuer server determines that the user cannot pay for the transaction 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 provides a new payment option), and authorization for the purchase transaction is attempted again. 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, user device, and/or client.

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

In some embodiments, the payment network server may forward the transaction authorization response to the user wallet device, the PoS client, and/or the merchant server. The merchant can parse the transaction authorization response (eg, 1624) and determine from it that the user has sufficient funds in the card account to proceed with the transaction (eg, 1625 option is yes). The merchant server may add a record of the user's transactions to a batch of transaction data related to authorized transactions. For example, the merchant may add XML data related to user transactions to an XML data file (eg, 1626 ) containing XML data for transactions that the respective user has authorized, and store the XML data file (eg, 1627 ) in a database. In some embodiments, the server may also generate a purchase receipt (eg, 1628) and provide the purchase receipt to the client. The client may present and display the purchase receipt for the user (eg, 1629). In some embodiments, the user's wallet device may also provide the user with a notification of successful authorization. For example, a PoS client/user device may present web pages, electronic messages, text/SMS messages, buffer voicemails, sound ringtones, and/or play audio messages, etc., and provide output including, but not limited to: sound, music, Audio, video, images, tactile feedback, vibrating alerts (eg, on vibrating client devices such as smartphones), etc.

17A-B show data graph diagrams illustrating example aspects of converting merchant transaction bulk data queries into updated payment ledger records via a purchase transaction clearing ("PTC") component. Referring to Figure 17A, in some embodiments, a merchant server (eg, 1703a) may initiate clearing of a batch of authorized transactions. For example, a merchant server may generate a bulk data request (eg, 1711 ) and provide the request to a merchant database (eg, 1703b ). For example, a merchant server may query a relational database using PHP/SQL commands similar to the examples provided above. In response to the bulk data request, the database can provide the requested bulk data (eg, 1712 ). The server may generate a batch clearing request (eg, 1713 ) by using the batch data obtained from the database, and provide the batch clearing request (eg, 1714 ) to the acquirer server, (eg, 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 batch payment request (eg, 1715 ) by using the obtained batch clearing request, and provide the batch payment request (eg, 1718 ) to the payment network server (eg, 1705 a ). The payment network server may parse the bulk payment request and extract transaction data for each transaction stored in the bulk payment request (eg, 1719 ). The payment network server may store transaction data (eg, 1720) for each transaction in a database (eg, payment network database 1705b). In some embodiments, the payment network server may invoke a component to provide a value-added analysis service based on the analysis of the transaction by the merchant for which the VWCS clears the purchase transaction. Thus, in some embodiments, the payment network server may provide analytics-based value-added services to the merchant and/or the merchant's users.

Referring to Figure 17B, in some embodiments, for each extracted transaction, the pay network server may query a database (eg, pay network database 1705b), eg, 1723, for the address of the issuer server. For example, a payment web server may utilize PHP/SQL commands similar to the examples provided above. The payment network server may generate a single payment request (eg, 1725 ) for each transaction for which transaction data has been extracted, and provide the single payment request (eg, 1725 ) to the issuer server, eg, 1706a. For example, the payment network server may provide the issuer server with a single payment request as an HTTP(S) POST message including data in XML format. The following provides an example listing of a single payment request 1725 substantially in the form of an HTTP(S) POST message including XML formatted data:

In some embodiments, the issuer server may generate a payment command (eg: 1727). For example, the issuer server may issue a command to debit funds from the user's account (or add a charge to the user's credit card account). The issuer server may issue a payment command (eg, 1727 ) to a database storing the user's account information (eg, user profile database 1706b ). The issuer server can provide a single payment confirmation to the payment network server (eg, 1728), which can forward the funds transfer message to the acquirer server (eg, 1729). The following provides an example listing of a single payment confirmation 1728 substantially in the form of an HTTP(S) POST message including XML formatted data:

In some embodiments, the acquirer server can parse the single payment confirmation and associate the transaction with the merchant (eg, by using the request_ID field in the example above). The acquirer server can then transfer the funds specified in the funds transfer message to Merchant's account. For example, the acquirer server may query the acquirer database 1707b (eg, 1730) for payment ledger and/or merchant account data (eg, 1731). The acquirer server may utilize the payment ledger and/or Merchant account data, along with a 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 in the acquirer database (e.g., , 1733).

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

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

Referring to Figure 18B, in some embodiments, for each extracted transaction, the pay network server may query the pay network database (eg, 1811) for the address of the issuer server. The payment network server may generate (eg, 1813 ) a single payment request 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 (eg, 1814) the single payment request and generate a payment command (eg, 1815) based on the parsed single payment request. For example, the issuer server may issue a command to debit funds from the user's account (or add a charge to the user's credit card account). The issuer server may issue a payment command (eg, 1815) to a database storing the user's account information (eg, a user profile database). The issuer server may provide the single payment confirmation to the payment network server (eg, 1817), which may forward the single payment confirmation to the acquirer server (eg, 1818).

In some embodiments, the acquirer server can parse the single payment confirmation and associate the transaction with the merchant (eg, by 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. The acquirer server may query the acquirer database (eg, 1819) for payment ledger and/or merchant account data (eg, 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 (eg, 1821 ). The acquirer server may then store the updated payment ledger and/or merchant account data to the acquirer database (eg, 1822).

VWCS controller

FIG. 19 shows a block diagram illustrating example aspects of a VWCS controller 1901 . In this embodiment, the VWCS controller 1901 can be used to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interaction with computers, and/or other related The data.

Users (eg, 1933a), which may be people and/or other systems, may engage with information technology systems (eg, computers) to facilitate information processing. Computers, in turn, use processors to process information; such processors 1903 may be referred to as central processing units (CPUs). One form of processor is known as a microprocessor. The CPU utilizes a communication circuit (communicative circuit) to transmit binary-coded signals used as instructions to make various operations possible. These instructions may be operable instructions and/or involving other instructions and data in various processor-accessible and operable regions of memory 1929 (e.g., registers, cache memory, random access memory, etc.) data command. Such communication instructions may be stored and/or transmitted in batches (eg, batch instructions) as program and/or data components to effect desired operations. These stored instruction codes (eg, programs) may engage CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, executable on a computer by the CPU; the operating system allows and enables users to access and operate computer information technology and resources. Some of the resources that can be used in an information technology system include: input and output mechanisms by which data can be transferred to/from a computer; memory, by which data can be stored; and processors, by which information can be processed. These information technology systems can be used to collect data for later retrieval, analysis and manipulation, which can be facilitated through database programs. These information technology systems provide interfaces that allow users to access and operate various system components.

基于Android OS的电话等）、平板计算机（例如，Apple iPad^TM，HP Slate^TM，MotorolaXoom^TM等)、电子书阅读器（例如，Amazon Kindle^TM，Barnes andNoble’s Nook^TM电子阅读器等）、膝上型计算机、笔记本、上网本，游戏控制台（例如，XBOX Live^TM，

DS，SonyPortable等），便携式扫描仪等。In an embodiment, the VWCS controller 1901 may connect and/or communicate with the entity. These entities include, but are not limited to: one or more users from user input device 1911 ; peripheral device 1912 , optional encryption processor device 1928 , and/or communication network 1913 . For example, VWCS controller 1901 can connect and/or communicate with users (eg, 1933a), operate client devices (eg, 1933b), including but not limited to: personal computers, servers, and/or various mobile devices, Mobile devices include, but are not limited to: cellular phones, smart phones (eg,

Android OS-based phones, etc.), tablet computers (e.g., Apple iPad ^TM , HP Slate ^TM , MotorolaXoom ^{TM ,} etc.), e-book readers (e.g., Amazon Kindle ^TM , Barnes and Noble's Nook ^TM e-reader, etc.), laptops Computers, Notebooks, Netbooks, Game Consoles (for example, XBOX Live ^TM ,

DS, Sony Portable, etc.), portable scanners, etc.

A network is generally considered to contain the interconnection and intercommunication between clients, servers, and intermediate nodes in a graph topology. It should be noted that the term server used throughout this application generally refers to a computer, other equipment, a program, or a combination thereof that responds to and processes requests from remote users through 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 communications network. Computers, other devices, programs, or combinations thereof that facilitate, process information and requests and/or the transfer of information from source users to destination users are generally referred to as nodes. Networks are generally considered to facilitate the transfer of information from source to destination. Nodes specifically tasked with facilitating the transfer of information from sources to destinations are often referred to as routers. There are various forms of networks such as Local Area Networks (LANs), Piconets, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally considered to be an interconnection of multiple networks whereby remote clients and servers can access and interoperate with each other.

VWCS controller 1901 may be based on a computer system including but not limited to components such as computer system 1902 coupled with memory 1929 .

computerization

Computer system 1902 may include a clock 1930, a central processing unit (CPU and/or processor (unless stated to the contrary, these terms are used interchangeably throughout this disclosure)) 1903, memory 1929 (e.g., read-only memory (ROM) 1906, random access memory (RAM) 1905, etc.), and/or interface bus 1907, and most often, though not necessarily, they all pass through one or more electrically conductive and/or otherwise transmissive circuit paths The system bus on the (mother) board 1902 interconnects and communicates through these circuit paths through which instructions (eg, binary-encoded signals) may travel for communication, operation, storage, and the like. The computer system can be connected to a power supply 1986, for example, an optional power supply can be built-in. Optionally, encryption processor 1926 and/or transceivers (eg: ICs) 1974 may be coupled to the system bus. In another embodiment, cryptographic processors and/or transceivers may be connected as built-in and/or external peripherals 1912 via interface bus I/O. In addition, the transceiver can be connected to the antenna 1975, thereby performing wireless transceiving of various communication and/or sensor protocols; for example, the antenna can be connected to: a WiLinkWL1283 transceiver chip of a Texas device (for example: providing 802.11n, Bluetooth 3.0, FM, Global Positioning System (GPS) (so as to allow the VWCS controller to determine its position)); Broadcom BCM4329FKUBG transceiver chip (for example, providing 802.11n, Bluetooth 2.1+EDR, FM, etc.), BCM28150 (HSPA+) and BCM2076 ( Bluetooth 4.0, GPS, etc.); a Broadcom BCM4750IUB8 transceiver chip (for example, GPS); an Infineon Technologies X-Gold618-PMB9800 (for example, providing 2G/3GHSDPA/HSUPA communication); Intel’s XMM7160 (LTE&DC-HSPA), Qualcomm’s CDMA (2000), mobile data/station modem, Snapdragon, etc. The system clock can have a crystal oscillator and generate a reference signal through computer systemized circuit paths. The clock can be coupled to the system bus and various clock multipliers that can increase or decrease the base operating frequency of other interconnected components in the computer system. Clocks and various components in computer systems enable signals containing information to be transmitted within a computer system. This sending and receiving of instructions, including information, within a computer system may be referred to as a communication. Still further, these communication commands may be transmitted, received, sent with reasons for returning and/or acknowledging communications outside of the immediate computer system to: communication networks, input devices, other computer systems, peripherals, etc. It will be appreciated that in alternative embodiments, any of the above-mentioned components may be connected directly to each other, to the PCU and/or to various organizational forms employed by various computer system examples.

The CPU includes at least one high-speed data processor capable of executing program components to carry out user and/or system-generated requests. Usually, the processor itself will incorporate various specific processing units, such as, but not limited to: floating point unit, integer processing unit, integrated system (bus) processor, logical operation unit, memory management control unit, etc., and even Specific processing sub-units, for example, an image processing unit, a digital signal processing unit, and the like. Additionally, the processor includes internal fast-access addressable memory, mappable and addressable memory 1929, in addition to the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor can access this memory using a memory address space accessible through instruction addresses, where the processor can construct and decode circuit paths that allow access to specific memory address controls with memory states/values. The CPU can be a microprocessor, such as: AMD's Athlon, Duron and/or Opteron; ARM's classic (eg, ARM7/9/11), embedded (Coretx-M/R), application (Cortex-A), Embedded security processors; DragonBall and PowerPC from IBM and/or Motorola; cellular processors from IBM and Sony; Intel's Atom, Celeron (mobile), Core (2/Duo/i3/i5/i7), Itanium, Pentium , Xeon, and/or XScale and other processors. The CPU interacts with memory through instructions that are transmitted through conductive and/or transmissive conduits (e.g., (printed) electronic and/or optical circuit boards) to execute stored Instructions (for example: program code). This command transmission facilitates the internal and external communication of the VWCS controller through various interfaces. If greater speed and/or capacity is required to process requests, distributed processor (eg, distributed VWCS), mainframe, multi-core, parallel, and/or supercomputer architectures may similarly be employed. Alternatively, smaller mobile devices (eg, cell phones, personal digital assistants (PDAs), etc.) may also be employed if the deployment request requires more portability.

Depending on the specific implementation, the characteristics of VWCS can be achieved by implementing a microprocessor like CAST's R8051XC2 microprocessor; Intel's MCS51 (i.e., 8051 microprocessor), etc. Additionally, in order to implement specific features of the VWCS, some features may rely on embedded components such as: t Application Specific Integrated Circuit (“ASIC”), Digital Signal Processing (“DSP”), Field Programmable Memory (“FPGA”) ") and other embedded technologies. For example, any of the set of VWCS components (distributed or otherwise) and/or features implemented by microprocessors and/or embedded components; eg, by ASICs, coprocessors, DSPs, FPGAs, etc. Alternatively, some implementations of the VWCS may be implemented with embedded components configured and used to implement various features and signal processing.

Depending on the particular implementation, embedded components may include software, hardware, and/or a combination of software/hardware. For example, the VWCS features discussed here can be achieved by implementing FPGAs, which are semiconductor devices that include programmable logic components called "logic blocks" and programmable interconnects, such as the high-performance FPGAs manufactured by Xilinx Virtex series and /or low-cost Spartan series. After the FPGA is fabricated, logic blocks and interconnect blocks can be programmed by the customer or designer to implement any feature of the VWCS. A programmable interconnectable hierarchy allows logic blocks to be interconnected as desired by the VWCS system designer/manager, similar to a single-chip programmable breadboard. An FPGA logic block can be programmed to perform basic logic gate operations such as AND, OR, or more complex associative operations such as decoding or simple mathematical operations. In many FPGAs, the logic blocks also include memory components, which may be latch circuits or entire blocks of memory. In some cases, the VWCS can be developed on a regular FPGA and then ported to a fixed version more like an ASIC. Alternative or equivalent implementations can also port VWCS controller features to a final ASIC as an alternative or in addition to FPGAs. By virtue of all the implementations mentioned above, embedded components and microprocessors may be considered the "CPU" and/or "processor" of the VWCS.

power supply

The power supply 1986 can be of any standard form for powering small electronic circuit board devices, for example, including battery packs such as: alkaline, lithium hydride, lithium poly, nickel cadmium, solar cells, and the like. Other types of AC or DC power supplies may also be used. In one embodiment, if it is a solar cell, the casing provides a hole through which the solar cell can obtain light energy. A 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/O 1908 . For example, a USB and/or IEEE1394 connection carries data and power over the connection and is therefore a suitable power source.

interface adapter

Interface bus 1907 may receive, connect to, and/or communicate with a number of interface adapters, typically, though not necessarily, in the form of adapter cards, such as but not limited to: input-output interface (I/O) 1908, storage interface 1909 , network interface 1910, etc. Optionally, the encryption processor interface 1927 can be connected to the interface bus similarly. The interface bus provides communication between the interface adapters and other components in the computer system. Interface adapters are suitable for compatible interface buses. Interface adapters can be connected to the interface bus via expansion and/or slot structures. Different extensions and/or slot architectures can be used, such as but not limited to: Accelerated Graphics Port (AGP), Cardbus, ExpressCard, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Parallel Component Interconnect (Extended) (PCI(X)), PCIExpress, Personal Computer Memory Card International Association (PCMCIA), Thunderbolt, etc.

Storage interface 1909 may receive, communicate with, and/or interface with multiple storage devices, such as but not limited to: storage device 1914, removable disk devices, and the like. Storage interfaces may employ connectivity protocols such as, but not limited to: (Highly) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra)(Serial)ATA(PI)), (Enhanced) Integrated Circuit Device ((E)IDE ), Institute of Electrical and Electronics Engineers (IEEE) 1394, Ethernet, Fiber Channel, Small Computer System Interface (SCSI), Thunderbolt, Universal Serial Bus (USB), etc.

The network interface 1910 can receive, communicate with, and/or connect with a communication network 1913 . Through the communication network 1913, the VWCS controller is accessible by a user 1933a through a remote client 1933b (eg, a computer with a web browser). The network interface may employ connection protocols such as, but not limited to: direct connection, Ethernet (thick, thin, twisted pair 10/100/1000Base T, etc.), token ring, wireless connections such as IEEE802.11a-x, etc. If more speed and/or capacity is required to process requests, the distributed network controller (eg: distributed VWCS) architecture will similarly be used for pooling, load balancing, and/or other, enhanced communication required by the VWCS controller bandwidth. The communication network can be any one and/or combination of the following: direct interconnection, Internet, local area network (LAN); metropolitan area network (MAN); operational tasks as nodes in the Internet (OMNI); secure client connection; wide area network (WAN) ; Wireless network (for example: using protocols such as but not limited to: Wireless Application Protocol (WAP), I mode, etc.), etc. A network interface can be thought of as a specific form of an input-output interface. Furthermore, the multi-network interface 1910 can be used in various communication network forms 1913 . For example, multiple network interfaces may be employed to allow communication over broadcast, multicast and/or unicast networks.

Input and output interface (I/O) 1908 can receive, communicate, and/or connect to user input device 1911, peripheral device 1912, encryption processor device 1928, etc., I/O can adopt 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, DisplayPort, Digital Visual Interface (DVI), High-Definition Multimedia Interface (HDMI), RCA, RF Antenna, S-Video, VGA, etc.; Wireless Transceivers: 802.11a/b/g/n/x; Bluetooth; Cellular (e.g., Code Division Multiple Access access (CDMA), high-speed packet access technology (HSPA (+)), high-speed downlink packet access technology (HSDPA), global system for mobile communication (GSM), long-term evolution system (LTE), WiMax, etc.), etc. The output device can be a video display, which can be based on a cathode ray tube (CRT), liquid crystal display (LCD), light emitting diode (LED), organic light emitting diode (OLED), plasma, etc. A monitor capable of receiving a signal from a video interface (eg, VGA, DVI line cable). The video interface synthesizes the information generated by the computer system and generates a video signal based on the synthesized information in the video memory frame. Another output device is the television, which receives the signal from the video interface. Typically, the video interface provides composite video information through a video connection interface that accepts a video display interface (eg, an RCA composite video connector that accepts an RCA composite video cable, a DVI connector that accepts a DVI display cable, HDMI, etc.).

User input devices 1911 are typically in the form of peripheral devices 1912 (see below), which may include: card readers, dongles, fingerprint readers, graphics tablets, joysticks, keyboards, microphones, mice, remote controls, retina Readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors (e.g., accelerometers, backlights, GPS, gyroscopes, proximity networks, etc.), stylus, etc.

Peripherals 1912 may connect to and/or communicate with I/O and/or other similar devices, such as network interfaces, storage interfaces, direct connections to an interface bus, system bus, CPU, and the like. Peripherals can be external, internal and/or part of the VWCS control. Peripherals can include: antennas, audio equipment (e.g., line-in, line-out, mic-in, speakers, etc.), cameras (e.g., still, video, webcam, etc.), dongles (e.g., for copy protection, digitally signed secure transactions, etc.), external processors (for additional capabilities, e.g., encryption devices 1928), force feedback devices (e.g., vibration motors, etc.), near-field communication (NFC) devices, network interfaces, printers, radio frequency identification ( RFID), scanners, storage devices, transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, armor, etc. Peripherals factories include various types of input devices (for example, microphones, cameras, etc.).

It should be noted that although user input devices and peripherals may be employed, the VWCS controller may be implemented as an embedded, dedicated, and/or monitorless (e.g., headless) device where access can Provided via a network interface connection.

A cryptographic unit, such as, but not limited to, a microprocessor, processor 1926, interface 1927, and/or device 1928 may be attached to, and/or communicate with the VWCS controller. An MC68HC16 microcontroller, manufactured by Motorola, may be used and/or used in the decryption unit. The MC68HC16 microcontroller utilizes 16-bit multiply and accumulate calculation instructions in a 16MHZ configuration, which requires less than one second to perform 512-bit RSA private key operations. Cryptographic units support authorization of communications from interactive agents and also allow anonymous transactions. The encryption unit can also be configured as part of the CPU. Equivalent microprocessors and/or processors may also be utilized. Other commercially available specific encryption processors include: Broadcom's CryptoNetX and other security processors; nCipher's nShield (e.g., Solo, Connect, etc.), SafeNet's Luna PCI (e.g., 7100) series; Semaphore Communications' 40MHz Roadrunner184; sMIP (eg, 208956); Sun's cryptographic accelerator (eg, Accelerator 6000PCIe board, Accelerator 500Daughtercard); Via Nano processor (eg, L2100, L2200, U2400) line, which is capable of executing 500+ MB/s of cryptographic instructions; VLSI Technology's 33MHz6868, etc.

memory

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, so any number of memory implementations may be used interchangeably with each other. It will be appreciated that various forms of memory 1929 may be employed by the VWCS controller and/or computer system. For example, a computer system can be configured so that on-chip CPU memory (e.g., registers), RAM, ROM, and other storage operations are provided by a punched paper tape or paper punched card mechanism, but such an implementation would result in considerably lower operating speeds . In one configuration, memory 1929 may include ROM 1906 , RAM 1905 , and storage device 1914 . Storage 1914 may take the form of any number of computational storage devices/systems. Storage devices can include a magnetic drum, a magnetic 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 similar devices. Thus, computer systemization generally requires and uses memory.

component collection

Memory 1929 may include a collection of programs and/or database components and/or data such as, but not limited to: operating system component 1915, (operating system), information server component 1916 (information server); user interface component 1917 (user interface); Web browser component 1918 (web browser); database 1919; mail server component 1921; mail client component 1922; encryption server component 1920 (encryption server); These components may be stored from and/or accessed from the storage device via an interface bus. Although non-traditional program components such as those in the component set may be stored in local storage device 1914, they may also be loaded from and/or stored in memory, such as: peripherals, RAM, via Remote storage devices for communication networks, ROM, various forms of memory, etc.

operating system

The operating system component 1915 is an executable program component that facilitates the operation of the VWCS controller. An operating system can facilitate access to I/O, network interfaces, peripherals, storage devices, etc. The operating system can be a highly fault-tolerant, scalable and secure system, for example: Apple's Macintosh OS X (server), AT&T Corporation Plan 9; BE operating system; Unix and Unix-like systems release versions (such as AT&T's UNIX; various different Berkeley software (BSD) such as FreeBSD, NetBSD, OpenBSD, etc., Linux distributions such as Red Hat, Ubuntu, etc.) and/or similar operating systems. However, more restricted and/or less secure operating systems are also used, such as Apple's Macintosh OS, IBM's OS/2, Microsoft's DOS, Microsoft's Windows 2000/2003/3.1/95/98/CE /Millenium/NT/Vista/XP (server), Palm OS, etc. In addition, mobile operating systems, such as Apple's iOS, Google's Android, HP's WebOS, and Microsoft's Windows Mobile, can all be used. Any of these operating systems may be embedded into the hardware of the NICK controller, and/or stored/loaded into memory/storage. The operating system collates with other components in the component collection, which also includes itself and so on. Most often the operating system communicates with other program components, user interfaces, and so on. For example, an operating system may include program components that communicate, generate, obtain, and/or provide, system, user, and/or data communications, requests, and/or responses. Once executed by the CPU, the operating system is capable of interacting with communication networks, data, I/O, peripherals, program components, memory, user input devices, etc. The operating system may provide communication protocols that allow the VWCS controller to communicate with other entities over the communication network 1913 . The VWCS controller can use various communication protocols as a subcarrier transmission 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 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, Internet Information Server of Microsoft, and the like. The Information Server may implement tools to allow the execution of program components. These tools are Active Server Pages (ASP), ActiveX, (ANSI) (Objective-)C(++), C# and/or .NET, Common Gateway Interface (CGI) scripting, Dynamic (D) Hypertext Markup Language (HTML ), Animation, Java, JavaScript, Practical Extractable Reporting Language (PERL), Hypertext Preprocessor (PHP, Pipeline, Python, Wireless Application Protocol (WAP), WebObjects, etc. The message server may support secure communication protocols such as but not Limited to, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Secure Sockets Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM) ), Apple's iMessage, Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Networks (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Utilization Extensions (SIMPLE), the open XML-based Extensible Messaging and Presence Protocol (XMPP) (e.g., Jabber or the Open Mobile Alliance's (OMA's) Instant Messaging and Presence Services (IMPS)), Yahoo's Instant Messenger service, etc. The information server provides results in the form of Web pages to Web browsers and allows the generation of Web pages to be manipulated by interacting with other program components. When an HTTP request Domain Name System The (DNS) resolution part is resolved to a specific information server, and the information server resolves the request based on the rest of the HTTP request to obtain information at the specified location in the VWCS controller. For example, such as http://123.124.125.126/myInformation. The request of html can have the IP part "123.124.125.126" of the request, and the IP part is resolved to the information server with the IP address by the DNS server; the information server can further parse the "/myInformation.html" part in the HTTP request and It is parsed into a memory response location containing the information "myInformation.html". In addition, other information service protocols can be adopted through different ports, such as FTP communication through port 21, etc. The information server can communicate with other components in the component collection, This includes itself, or a similar implementation, etc. Most often, the Information Server communicates with the VWCS database 1919, operating systems, other program components, user interfaces, web browsers, and the like.

Access to the VWCS database can be achieved through multiple database bridge mechanisms, such as through the scripting languages listed below (eg, CGI) and communication channels between applications, listed below (eg, CORBA, WebObjects, etc.). Any data request initiated by a web browser will be parsed into the appropriate syntax required by VWCS through the bridge mechanism. In one embodiment, the information server will provide a web form accessible by a web browser. Input fields provided in web forms are marked as requiring specific fields, and the parsing process is the same. The entered condition is then passed along with this field tag to instruct the parser to generate a query pointing to the appropriate table and/or field. In one embodiment, the parser will generate standard SQL queries based on the tokenized text input by instantiating a search string with appropriate join/select commands, where the resulting commands are passed through the bridge mechanism to the VWCS as a query is provided. Once a query result is generated from a query, the result is passed through the bridge ring and parsed by the bridge mechanism to format and generate a new result page. This new resulting web page is then provided to the information server, which provides the resulting web page to the requesting web browser.

Information servers may also include, communicate, generate, obtain and/or provide program components, systems, users, and/or data communications, requests and/or responses.

user interface

A computer interface is in some ways similar to a car's operator interface. Automotive UI elements such as steering wheel, gear shift, and speedometer facilitate access, manipulation, and display of vehicle resources and status. Computer interface elements such as check boxes, cursors, menus, scroll bars, and windows (often collectively referred to as widgets) also facilitate access, capabilities, manipulation, and display of data, computer applications, operating system resources, and state. The operator interface is often referred to as the user interface. Graphical user interfaces (GUIs) such as Apple's Macintosh operating system's Aqua and iOS' Touchable, IBM's OS/2, Google's Android phone user interface, Microsoft's Windows2000/2003/3.1/95/98/CE/Millenium/Mobile/ NT/XP/Vista/7/8 (eg, Aero, Metro), Unix X-Windows (eg, which can include additional Unix GUI libraries and layers such as the K Desktop Environment (KDE), MythTV, and GNU Network Objects Model Environment (GNOME)), web interface libraries (eg, ACTIVEX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc., interface libraries such as but not limited to, Dojo, jQuery (UI), MooTools, Prototype, script. aculo.us, SWFObject, Yahoo UI, any of which may be used) provide a limit and means for accessing and graphically displaying information to the user.

The user interface component 1917 is a stored program component executed by the CPU. The user interface may be a graphical user interface as already discussed and/or provided by an overhead operating system and/or operating environment. The user interface may be implemented textually and/or graphically to allow display, execution, interaction, manipulation, and/or operation of program components and/or system devices. A user interface provides the facility by which a user can affect, interact with, and/or operate a computer system. A user interface can communicate with other components in a collection of components, including itself, and/or similar devices, and the like. Most often, the user interface communicates with the operating system, other program components, and so on. A user interface may include components that communicate, generate, acquire, and/or provide program, system, user, and/or data communications, requests, and/or responses.

browser

Web browser component 1918 is a stored program component executed by the CPU. A web browser can be a hypertext viewing application, such as Goofle's (mobile phone) Chrome browser, Microsoft IE, Netscape browser, Apple's (mobile phone) Safari browser, an embedded web browser object such as through Apple's Cocoa ( touch) object class, etc. Secure web browsers can provide 128-bit (or greater) encryption over HTTPS, SSL, etc. Web browsers allow access through tools such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., Chrome, Firefox, Internet Explorer, Safari plug-ins, etc.) to execute program components. Web browsers and similar information access tools can be integrated into handheld computers, cell phones, smart phones, and/or other mobile devices. The web browser can communicate with other components in the set of components, including itself, and/or similar devices, and the like. Most often, a web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), etc.; for example, it may contain components that communicate, generate, acquire, and/or provide program, system, user and/or Data communications, requests and/or responses. Furthermore, as an alternative to web browsers and information servers, joint applications can be developed to perform similar operations of both. Joint applications, also affect the acquisition and provision of information from VWCS assembly nodes to users, user agents, etc. Syndicated apps won't work on systems with standard web browsing.

Mail Server

The mail server component 1921 is a stored program component executed by the CPU 1903 . The mail server can be an Internet mail server such as but not limited to Apple's mail server (3), dovect, sendmail, Microsoft Exchange, etc. The mail server can allow access through tools such as ASP, ActiveX, (ANSI)(Objective-)C(++), C# and/or.NET, CGI scripts, Java, JavaScript, PERL, PHP, pipelines, Python, WebObjects, etc. to execute program components. The mail server supports communication protocols, such as but not limited to: Internet Message Access Protocol (IMAP), Message Application Programming Interface (MAPI)/Microsoft Exchange, Post Office Protocol (POP3), Simple Mail Transfer Protocol (SMTP), etc. The mail server may route, forward and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traverse and/or reach the VWCS.

VWCS mail can be accessed through a number of APIs provided by various web servers and/or operating systems.

Mail Server also includes, communicates, generates, acquires and/or provides program components, systems, users, and/or data communications, requests, messages, and/or responses.

mail client

Mail client component 1922 is a stored program component executed by CPU 1903. The mail client can be a mail viewing application, such as Apple (mobile phone) mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, etc. The mail client can support multiple transport protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, etc. A mail client can communicate with other components in the set of components, including itself, and/or similar devices. Most often, mail clients communicate with mail servers, operating systems, other mail clients, etc.; for example, it can include communicating, generating, obtaining, and/or providing program components, system, user, and/or data communications, requesting , message, and/or response. Generally speaking, mail clients provide a facility to compose and send emails.

encrypted server

Crypto server component 1920 is a stored program component executed by CPU 1903, crypto processor 1926, crypto processor interface 1927, crypto processor device 1928, and the like. The cryptographic handler interface allows the cryptographic component to expedite encryption and/or decryption requests; however, the cryptographic component, alternatively, would run on the CPU. The encryption component allows encryption and/or decryption of provided data. The encryption component allows symmetric and asymmetric (eg, well protected (PGP)) encryption and/or decryption. Encryption components can use encryption technologies, such as, but not limited to: digital certificates (such as X.509 authentication framework), digital signatures, double signatures, envelopes, password access protection, public key management, etc. The cryptographic component enables numerous (encryption and/or decryption) security protocols that will benefit, such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptic Curve Cryptography (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one-way hash operation), ciphers, Rivest encryption (RC5), Rijndael algorithm, RSA (this is an encryption and authentication system for the Internet, it is used by Ron Rivest, Adi Shamir and Leonard Adleman Algorithms developed in 1977), Secure Hash Algorithm (SHA), Secure Sockets Layer (SSL), Hypertext Transfer Protocol Secure (HTTPS), etc. Using such an encrypted security protocol, VWCS encrypts all incoming and/or outgoing communications and can act as a node in a virtual private network (VPN) with a wider communication network. The cryptographic component facilitates the process of "secure authentication," where access to resources is inhibited by security protocols, where cryptographic groups affect authorized access to secure resources. Additionally, the encryption component can provide a unique identifier for the content, for example, using MD5 hashing to obtain a unique signature for a digital audio file. The cryptographic component can communicate with other components in the set of components, including itself, and/or similar devices. If required, the encryption component supports encryption schemes that allow information to be securely transmitted in the communication network to enable the VWCS component to conduct secure transactions. The encryption component facilitates secure access to resources on the VWCS and facilitates access to secure resources on remote systems, that is, it can act as a client and/or server of secure resources. Most often, cryptographic components communicate with information servers, operating systems, other program components, and the like. A cryptographic component may contain, communicate, generate, obtain, and/or provide program components, system, user, and/or data communications, requests, and/or responses.

VWCS database

The VWCS database component 1919 can be implemented as a database and the data it stores. The database is a stored program component, which is executed by the CPU. The stored program components configure in part the CPU to process the stored data. The database can be any one of multiple fault-tolerant, relational, scalable, and secure databases, such as DB2, MySQL, Oracle, SYBASE, etc. Relational databases are an extension of flat files. A relational database consists of a series of related tables. Tables are interconnected through key fields. The use of key fields allows tables to be merged by indexing the key fields, ie, the key fields serve as two-dimensional pivot points to obtain merged information from different tables. Relationships typically represent links maintained between tables by matching primary keys. A primary key represents a field in a relational database that uniquely identifies a row in a table. More precisely, they represent the "one" side of a one-to-many relationship that uniquely identifies rows in a table.

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

In one embodiment, database component 1919 includes several tables 1919a-p. A user table 1919a may include fields such as but not limited to: user_id, ssn, dob, first_name, last_name, age, state, address_firstline, address_secondline, zipcode, devices_list, contact_info, contact_type, alt_contact_info, alt_contact_type, etc. A user table can 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_serial, device_ECID, device_UDID, device_browser, device_type, device_model, device_version, device_OS, device_apps_list, device_securekeyins, wallet_agfled, etc. An 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, etc. The account table 1919d may include fields such as but not limited to: account_number, account_security_code, account_name, issuer_acquirer_flag, issuer_name, acquirer_name, account_address, routing_number, access_API_call, linked_wallets_list, and the like. 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: issuer_id, issuer_name, issuer_address, ip_address, mac_address, auth_key, port_num, security_settings_list, and the like. The acquirer table 1919g may include fields such as, but not limited to: account_firstname, account_lastname, account_type, account_num, account_balance_list, billingaddress_line1, billingaddress_line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_line1, shippingaddress_line2, shipping_zipcode, etc. 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, etc. The store session table 1919i may include fields such as but not limited to: user_id, session_id, alerts_URL, timestamp, expiry_lapse, merchant_id, store_id, device_type, device_ID, device_IP, device_MAC, device_browser, device_serial, device_ECID, device_model, device_OS, wallet_app_installed, cart_ID_list, product_params_list, social_flag, social_message, social_networks_list, coupon_lists, accounts_list, CVV2_lists, charge_ratio_list, charge_priority_list, value_exchange_symbols_list, bill_address, ship_address, cloak_flag, pay_models, alerts_ru, etc. The transaction table 1919j may include fields such as but not limited to: order_id, user_id, timestamp, transaction_cost, purchase_details_list, num_products, products_list, product_type, product_params_list, product_title, product_summary, quantity, user_id, client_system_id, client_ip, client_type, client_atversion_moding ,app_installed_flag,user_id,account_firstname,account_lastname,account_type,account_num,account_priority_account_ratio,billingaddress_line1,billingaddress_line2,billing_zipcode,billing_state,shipping_preferences,shippingaddress_line1,shippingaddress_line2,shipping_zipcode,shipping_state,merchant_id,merchant_name,merchant_auth_key等。 The batch table 1919k may include fields such as but not limited to: batch_id, transaction_id_list, timestamp_list, cleared_flag_list, clearance_trigger_settings, etc. The general ledger table 19191 may include fields such as but not limited to: request_id, timestamp, deposit_amount, batch_id, transaction_id, clear_flag, deposit_account, transaction_summary, payor_name, payor_account, etc. The products 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, offers_list, discounts_list, rewards_list, merchants_list, merchant_availability_list, etc. Offer table 1919n may include fields such as but not limited to: offer_ID, offer_title, offer_attributes_list, offer_price, offer_expiry, related_products_list, discounts_list, rewards_list, merchants_list, merchant_availability_list, etc. The behavior data table 1919o may include fields such as but not limited to: user_id, timestamp, activity_type, activity_location, activity_attribute_list, activity_attribute_values_list, etc. Analysis table 1919p may include, such as, but not limited to, the following fields: report_id, user_id, report_type, report_algorithm_id, report_destination_address, etc.

In one embodiment, the VWCS database can communicate with other database systems. For example, in a distributed database system, searching for VWCS components to query and access data would combine 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. In addition, various accounts may require custom database tables depending on the environment and the type of clients that the VWCS needs to serve. It should be noted that any unique field can be designated as a key field. In another embodiment, these tables are distributed to their own databases and their respective database controllers (eg, a separate database controller for each of the above tables). Using standard data processing techniques, the database can further be distributed among several computer systems and/or storage devices. Also, by centralizing and/or distributing the various database components 1919a-p, the configuration of the decentralized database controllers may change. Through the database controller the VWCS can be configured to understand various settings, inputs and parameters.

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

VWCS

VWCS component 1935 is a stored program component executed by the CPU. In one embodiment, the VWCS component incorporates any and/or all of the combinations of aspects of the VWCS discussed in the previous figures. Thus, VWCS affects access, acquisition and provision of information, services, transactions, etc. through various communication networks. The features and implementations of VWCS discussed in this paper improve network efficiency by reducing data transmission requirements and using more efficient data structures and their transmission and storage mechanisms. As a result, more data can be transferred in less time, and the time lag associated with transactions is also reduced. In many cases, this reduction in storage, transfer time, bandwidth requirements, latency, etc. will reduce capacity and structural infrastructure requirements to support VWCS features and facilities and, in many cases, reduce cost, energy consumption/requirements, and prolongs the lifetime of the VWCS underlying infrastructure; with the added benefit of making the VWCS more reliable. Similarly, many of the features and mechanisms are designed for user-friendliness and access, thereby expanding the audience that can enjoy/employ and utilize the VWCS's feature set, and this ease-of-use can also help enhance the reliability of the VWCS. In addition, the feature set includes enhanced security as mentioned above through encryption components 1920, 1926, 1928 and the entire box, making access to features and data more reliable and secure.

The VWCS component can convert virtual wallet card options made by users using mobile devices through the VWCS component into virtual wallet card-based transactional purchase prompts, and/or VWCS-like uses. In one embodiment, VWCS component 1935 inputs (e.g., purchase input 411, card selection input 424; virtual wallet card option 421; issuer'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;Funds 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 ledger, merchant account data 1731, etc.), and through various components (e.g., VW-CTE1944; UPC1941; PTA1942; PTC1943, etc.) Wallet Card Selection Request 422; Authorization Message 436-438; Bulk Append Data 440; Purchase Receipt 441; Checkout Request Message 1313; Checkout Data 1317; Card Authorization Request 1516, 1523; 1534, Purchase Receipt 1535; Batch Clearing Request 1714; Batch Payment Request 1718; Transaction Data 1720, Individual Payment Confirmation 1728, 17299; Updated Payment Subsidiaries, Merchant Account Data 1733, etc.).

By using standard development tools and languages for development, VWCS components can access information between nodes, such as but not limited to: Apache components, Assembly, ActiveX, binary executable files (ANSI), (Objective-)C(++) , C# and/or.NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, procedural and object-oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, web development Environments and libraries (eg, Microsoft ActiveX, Adobe AIR, FLEX&FLASH;AJAX;(D)HTML; Dojo, JAVA, JavaScript; jQuery (UI); MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP) ;SWFObject; Yahoo UI, etc.), WebObjects, etc. In one embodiment, the VWCS server encrypts and decrypts communications using an encryption server. A VWCS component may interact with other components in a component collection, including itself, and/or similar means. Most commonly, VWCS components communicate with the VWCS database, operating system, and other program components. A VWCS may contain components that communicate, generate, acquire, and/or provide program, system, user, and/or data communications, requests, and/or responses.

Distributed VWCS

The structure and/or operation of any of the VWCS node controller components may be combined, consolidated, and/or distributed in any number to facilitate development and/or deployment. Likewise, collections of components can be combined in any number for ease of deployment and/or development. To achieve this, components can be integrated into a common code base, or a device that can dynamically load components in an integrated fashion on demand.

The set of components can be centralized and/or decentralized in countless variants through standard data processing and/or development techniques. Multiple instances of any one program component in the set of program components can be instantiated on a single node and/or across a large number of nodes through load balancing and/or data processing techniques to improve performance. Additionally, a single instance can also be distributed across multiple controllers and/or storage devices, eg, databases. All cooperating program component instances and controllers may do so through standard data processing communication techniques.

The configuration of the VWCS controller will depend on the context in which the system is deployed. Factors, such as, but not limited to, budget, capabilities, location, and/or utilization of underlying hardware resources, can affect deployment requirements and configurations. Data may be transmitted, retrieved, and/or provided regardless of whether the configuration results in a more centralized and/or integrated program component, a more distributed set of program components, and/or a combination between centralized and distributed configurations. Component instances incorporated into a common code base from a collection of program components can communicate, obtain and/or provide data. This can be achieved through data processing communication techniques within the application, such as but not limited to: data references (eg, pointers), internal messages, communication of object instance variables, shared memory space, variable passing, etc.

If the components of the Component Collection are discrete, independent, and/or external to each other, communicating, obtaining, and/or providing data to and/or to other components may be accomplished through inter-application communication techniques, such as but not limited to: Information channels for application interfaces (APIs); (distributed) Component Object Model ((D)COM), (distributed) Object Linking and Embedding ((D)OLE), etc.), Common Object Request Broker Architecture (CORBA), Jini Local and remote application interfaces, JavaScript Object Notation (JSON), Remote Method Invocation (RMI), SOAP, process pipelines, shared files, etc. Messages sent between discrete components for inter-application communication or within the content space of a single component for intra-application communication can be achieved through the creation and parsing of a grammar. A grammar can be developed by using development tools, for example, lex, yacc, XML, etc., which allow the generation and parsing capabilities of the grammar, which in turn can form the basis for communication messages within and between components.

For example, a grammar could be arranged to recognize tokens for HTTP post commands, such as:

w3c-post http://...Value1

Among them, Value1 is considered as a parameter, because "http://" is part of the grammar, and the content after that is considered as part of the passed value. Also, with this grammar, the variable "Value1" can be inserted into the "http://" post command and then sent. Grammar The grammar itself can represent structured data that can be translated and/or used to generate parsing mechanisms (eg, a text file of grammar descriptions for processing by lex, yacc, etc.). Additionally, once the parsing mechanism is generated and/or instantiated, it can itself process and/or parse structured data such as, but not limited to: text delineated by characters (e.g., tags), HTML, structured text streams, XML and/or or similar structured data. In another embodiment, the inter-application data processing protocol itself may have integrated and/or off-the-shelf parsers (for example, JSON, SOAP, and/or similar parsers), and use these parsers to parse (for example , communication) data. Additionally, the parsed grammar will be used in message parsing, but can also be parsed using: databases, data collections, data stores, structured data, etc. Again, the required configuration 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 that implements a Secure Sockets Layer (“SSL”) socket server through a message server that listens on the server port to which clients want to send data. The incoming communication is, for example, JSON-encoded data. Once the incoming communication has been identified, the PHP script can read the incoming message from the client device, parse the received JSON-encoded text data into a PHP script variable, extract the JSON-encoded text data from it, and then store the data (e.g., client-identified information, etc.) and/or use Structured Query Language (SQL) to extract information from accessible relational databases. An exemplary manifest, written basically as PHP/SQL commands to receive JSON-encoded input data from a client device over an SSL connection, parse the data to extract variables, and store the data into a database, is provided below :

Additionally, the following resources can be used to provide examples of SOAP parser implementations

Example:

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

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.

IBMDI.doc/referenceguide295.htm

Other parser implementations:

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

All of these are expressly incorporated herein by reference. Non-limiting exemplary embodiments highlighting numerous further advantageous aspects include:

1. A virtual wallet card selection means embodiment, including means for:

Obtain user authentication requests for purchase transactions;

Based on parsing the user authentication request, the universal card account number is extracted through the computing processor;

Based on querying the database using the universal card account number, it is determined that the user is authorized to access the virtual wallet;

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

obtain user selection of a virtual wallet card account; and

User selection using a virtual wallet card account, providing a purchase transaction request message for transaction processing.

2. The means as described in embodiment 1, further comprising means for:

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

3. The means as described in embodiment 1, further comprising means for:

Get the virtual wallet card selection options for the user; and

A virtual wallet card selection option is provided to the user device.

4. The approach 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 approach 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 approach of embodiment 5, wherein the encoded virtual wallet card selection option information is encoded as an indicia in the universal card account number extracted from the user authentication request.

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

8. The approach of embodiment 7, 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.

9. The means as described in embodiment 1, further comprising means for:

obtain user selection of multiple virtual wallet card accounts; and

Wherein, the purchase transaction request message includes user-selected identifications of the plurality of virtual wallet card accounts.

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

In order to solve various problems and improve technology, all of the present application (including cover, title, subtitle, technical field, background technology, content of the invention, description of drawings, specific implementation, and claims) of virtual wallet card selection device, method and system Book, Abstract, Drawings, Appendices, and/or other) show by way of illustration various embodiments in which the claimed invention may be practiced. The advantages and features of the present application are merely representative examples of embodiments, not exhaustive and/or exclusive. They just help to understand and tell the rationale for the statement. It should be understood that they are not representative of all claimed inventions. As such, certain aspects of the disclosure are not discussed here. The fact that alternative embodiments may not be presented for a particular portion of the invention, or that further undescribed alternative embodiments may be available for a portion, is not to be considered a disclaimer of those alternative embodiments. It is to be understood that many of those non-described 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 functional, logical, organizational, structural and/or topological changes may be made without departing from the scope of the present invention. As such, all examples and/or embodiments are considered non-limiting throughout this disclosure. Likewise, no inference should be made regarding those embodiments discussed here relative to those not discussed here, as such, it is to reduce space and repetition. For example, it is to be understood that the logic and/or topology of any combination of program components (collections of components), other components, and/or any existing feature set as depicted in the figures and/or throughout this specification is not limited to a fixed order of operation and/or permutations, but any order disclosed is exemplary only and this disclosure contemplates all equivalents, regardless of order. Furthermore, it is also understood that such features are not limited to serial execution, but that any number of threads, processes, services, servers, and/or the like may execute asynchronously, concurrently, in parallel, concurrently, synchronously, and and/or the present disclosure contemplates the like. As such, some of these features may be so contradictory that they cannot co-exist in a single embodiment. Similarly, certain features that apply to one aspect of the invention are not applicable to other aspects. In addition, this disclosure also includes other inventions that are not presently claimed. Applicants reserve all rights in those presently unclaimed inventions, including the right to claim such inventions, to file applications of addition, continuations, continuations in part, and/or the like. As such, it should be understood that the advantages, embodiments, examples, functionalities, features, logical, organizational, structural, topological and/or other aspects of the present disclosure are not only to be considered as essential to the present disclosure as defined in the claims. limitations or limitations on equivalents to the claims. It will be appreciated that depending on the specific needs and/or characteristics of VWCS individual and/or enterprise users, database configurations, relational models, data types, data transfer and/or network frameworks, syntax structures and/or etc. Various embodiments of VWCS for flexibility and customization. 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 relate to electronic shopping transactions, it will be appreciated that the embodiments described herein can be readily configured and/or customized for various other and/or implementations.

Claims (30)

1. A virtual wallet card selection system, comprising: computing processor; a network communication device configured to communicate with the computing processor; and A memory configured to communicate with the computing processor and storing instructions executable by the computing processor for: obtaining a user authentication request for a purchase transaction via a network communication device operatively connected to a payment network server; extracting the universal card account number based on parsing the user authentication request via a computing processor operatively connected to the payment network server; determining that the user is authorized to access the virtual wallet based on a query of a database memory operatively connected to the payment network server using the universal card account number; Determining that the user desires to maintain the user from the merchant involved in the purchase transaction by utilizing secure network communication with the user's mobile device to provide payment data to the payment network server for processing the purchase transaction based on a query of the database memory using the universal card account number privacy of payment data; identifying, via the computing processor of the payment network server, a plurality of card selection options securely provided to the user's mobile device via the network communication device to maintain privacy of the user's payment data from merchants involved in the purchase transaction; When it is determined that the user is authorized to access the virtual wallet, a secure user virtual wallet card selection request including card selection options is provided to the user's mobile device via encrypted out-of-band network communication via the network communication device, thereby reducing network delay of the electronic payment communication network and bandwidth usage; obtaining a user selection of a virtual wallet card account from the plurality of securely provided card selection options from the user mobile device via the network communication device at the payment network server; User selection using the virtual wallet card account via the network communication device provides an encrypted purchase transaction request message for transaction processing. 2. A virtual wallet card selection system, comprising: processor; and a memory arranged in communication with the processor and storing instructions executable by the processor for: Obtain user authentication requests for purchase transactions; Based on parsing the user authentication request, the general card account number is extracted through the processor; Based on querying the database using the universal card account number, it is determined that the user is authorized to access the virtual wallet; When it is determined that the user is authorized to access the virtual wallet, providing the user device with a user virtual wallet card selection request; obtain user selection of a virtual wallet card account; and User selection using a virtual wallet card account, providing a purchase transaction request message for transaction processing. 3. The system of claim 2, the memory further storing instructions for: When authorization of the purchase transaction is completed based on the purchase transaction request message, a purchase receipt is provided to the user device. 4. The system of claim 2, the memory further storing instructions for: Get the virtual wallet card selection options for the user; and A virtual wallet card selection option is provided to the user device. 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 an indicia in the universal card account number extracted from the user authentication request. 8. The system of claim 2, wherein user selection of a virtual wallet card account includes selection of 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 a virtual wallet card account. 10. The system of claim 2, the memory further storing instructions for: obtain user selection of multiple virtual wallet card accounts; and Wherein, the purchase transaction request message includes user-selected identifications of the plurality of virtual wallet card accounts. 11. A non-transitory computer readable medium storing processor-executable virtual wallet card selection instructions for: Obtain user authentication requests for purchase transactions; Based on parsing the user authentication request, the general card account number is extracted through the processor; Based on querying the database using the universal card account number, it is determined that the user is authorized to access the virtual wallet; When it is determined that the user is authorized to access the virtual wallet, providing the user device with a user virtual wallet card selection request; obtain user selection of a virtual wallet card account; and User selection using a virtual wallet card account, providing a purchase transaction request message for transaction processing. 12. The medium of claim 11 further storing instructions for: When authorization of the purchase transaction is completed based on the purchase transaction request message, a purchase receipt is provided to the user device. 13. The medium of claim 11 further storing instructions for: Get the virtual wallet card selection options for the user; and A virtual wallet card selection option is provided to the user device. 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 an indicia in a universal card account number extracted from the user authentication request. 17. The medium of claim 11, wherein user selection of a virtual wallet card account includes selection of 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 for: obtain user selection of multiple virtual wallet card accounts; and Wherein, the purchase transaction request message includes user-selected identifications of the plurality of virtual wallet card accounts. 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: Obtain user authentication requests for purchase transactions; Based on parsing the user authentication request, the universal card account number is extracted through the computing processor; Based on querying the database using the universal card account number, it is determined that the user is authorized to access the virtual wallet; When it is determined that the user is authorized to access the virtual wallet, providing the user device with a user virtual wallet card selection request; obtain user selection of a virtual wallet card account; and User selection using a virtual wallet card account, providing a purchase transaction request message for transaction processing. 22. The method of claim 21, further comprising: When authorization of the purchase transaction is completed based on the purchase transaction request message, a purchase receipt is provided to the user device. 23. The method of claim 21, further comprising: Get the virtual wallet card selection options for the user; and A virtual wallet card selection option is provided to the user device. 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 an indicia in the 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 includes selecting an anonymous card account to process the 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: obtain user selection of multiple virtual wallet card accounts; and Wherein, the purchase transaction request message includes user-selected identifications of the plurality of virtual wallet card accounts. 30. The method of claim 21, wherein the user device is a user mobile device executing a virtual wallet application.

Images