HK1196692B

HK1196692B - Payment privacy tokenization apparatuses, methods and systems

Info

Publication number: HK1196692B
Application number: HK14109951.2A
Authority: HK
Inventors: T‧W‧欧伯那
Original assignee: 维萨国际服务协会
Priority date: 2011-06-07
Filing date: 2012-06-07
Publication date: 2019-06-14

Description

Payment privacy tokenization apparatus, method and system

This written patent discloses and describes various novel innovations and inventive aspects of payment privacy tokenization techniques (hereinafter "publications"), and contains content that is subject to copyright, integrated circuit layout design, and/or other intellectual property protection. As this disclosure appears in published patent office documents/records, each owner of the intellectual property rights is silent as to the reproduction of a copy of the disclosure, but otherwise reserves all rights whatsoever.

Priority

Applicant claims priority from 35USC 119 to U.S. provisional patent application serial No. 61/494, 402 entitled "patent provisional patent application, METHODS NAD SYSTEMS", attorney docket No. P-42304PRV |20270-167PV, filed 2011, 6, month 7. The entire contents of the above application are expressly incorporated herein by reference.

Technical Field

The present innovations are generally directed to devices, methods, and systems for purchase transactions, and more particularly, to payment privacy tokenization devices, methods, and systems ("PPT").

Background

Card-based consumer transactions typically require the customer to type in a lot of details of a credit or debit card, or to utilize a payment method such as cash or check. Participation in card transactions requires the transfer of personal information to a wide range of third party merchants.

Drawings

The appendix and/or drawings show various non-limiting, exemplary inventive aspects in accordance with the present disclosure:

1A-1B represent block diagrams illustrating example aspects of payment tokenization in some embodiments of PPTs;

2A-B represent application user interface diagrams illustrating example features of an application interface for controlling tokenized payments for purchase transactions in some embodiments of PPTs;

figures 3A-C represent application user interface diagrams illustrating example features of a payment tokenized mobile application for obtaining user data and protecting against fraud in some embodiments of PPT;

figure 4 represents a data flow diagram illustrating an example process of joining a token-based purchase payment program in some embodiments of a PPT;

figure 5 represents a logic flow diagram illustrating an example aspect of incorporating a token-based purchase payment program, e.g., a token-based purchase registration ("TPE") component 500, in some embodiments of a PPT.

Figures 6A-E represent data flow diagrams illustrating an example process of performing a token-based purchase transaction in some embodiments of a PPT;

figures 7A-F represent logical flow diagrams illustrating exemplary aspects of performing a token-based purchase transaction in some embodiments of a PPT, such as a token-based purchase transaction execution ("tPTE") component 700;

figure 8 represents a user interface diagram showing an overview of example features of a virtual wallet application in some embodiments of a PPT;

figures 9A-G represent user interface diagrams illustrating example features of a virtual wallet application in a shopping mode in some embodiments of a PPT;

figures 10A-F represent user interface diagrams illustrating example features of a virtual wallet application in payment mode in some embodiments of PPT;

figure 11 represents a user interface diagram illustrating example features of a virtual wallet application in a history mode in some embodiments of PPT;

figures 12A-E represent user interface diagrams illustrating example features of a virtual wallet application in a capture mode in some embodiments of a PPT;

figure 13 represents a user interface diagram illustrating example features of a virtual wallet application in a provisioning mode in some embodiments of a PPT;

figures 14A-B represent user interface diagrams illustrating example features of a virtual wallet application in secure and privacy modes in some embodiments of a PPT;

figure 15 shows a block diagram illustrating an embodiment of a PPT controller.

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

Detailed Description

Payment Privacy Tokenization (PPT)

Payment privacy tokenization apparatus, methods and systems (hereinafter "PPT") convert payment token-based purchase orders into multi-issuer purchase payment funds transfers through PPT components.

Figures 1A-1B represent block diagrams illustrating example aspects of payment tokenization in some embodiments of PPTs. Referring to fig. 1A, in some implementations, a payment network system including payment network servers (e.g., local payment network server 114a and remote payment network server 114 b) located in a remote geographic area may be required to determine where to process a purchase transaction. For example, user 110a may be located in a remote geographic area and may access a website (e.g., 113) of a merchant (e.g., 112) in a different geographic area. In some implementations, user 110a may utilize client 111a to provide purchase input (e.g., 115 a) to merchant server 112. For example, the client 111a may provide a payment token (e.g., by a Playspan ultimatepage Lightbox object executing within a browser environment on the client 111 a) to maintain anonymity of the user. For example, the payment token may be an MD5 one-way cryptographic hash (hash) of the payment financial information and may not provide any personally identifying information for the user. Although the token may not contain identification information, it may be based on the identification information (e.g., based on a unique identifier); this has the advantage of populating the privacy enhanced data table with the country code of the user information through such hashing; the resulting table will maintain the anonymity of the user since the hash and country code cannot be used to identify the user, however, such a table may then be used to apply privacy rules specific to the country code and thereby route the token and payment processing to the payment server of the appropriate country, thereby preventing the user's private information from being seen with inappropriate authority (jurisdictions). In some implementations, the user 110a may wish to utilize a payment mechanism (mechanism) typically used in remote geographic locations (e.g., credit card, debit card, pre-paid card, stored value account, etc.) through a payment token. Thus, in some scenarios, a user from a remote geographic location may wish to utilize a payment mechanism designed for use in the remote geographic location to pay for purchases made at merchants located in the local geographic location without revealing any personally identifying information of the user to merchants or payment network servers located in the local geographic area.

For example, this scenario may be contrasted with user 111b utilizing client 110b and located in a local geographic location. For example, user 110b may utilize client 111b to provide purchase input to the same merchant website 113 of a merchant 112 located in a local geographic location. In some implementations, the merchant server 112 may provide purchase requests from both users to the same locally appropriate payment network server, e.g., 114 a. Thus, in some implementations, the local payment network server 114a may be required to determine whether to process payment locally for an incoming card authorization request or to transfer the request to a remotely located payment network server, e.g., 114 b. In some implementations, the local payment network server 114a may be required to make such a determination without utilizing any personally identifying information for the user. In some implementations, the local payment network server 114a may utilize a payment token provided by the user's client as a search term (term) to query the database. For example, the local payment network server may utilize hypertext preprocessor ("PHP") script containing structured query language ("SQL") commands (e.g., such as in the examples provided further below) to query the database using anonymous privacy preserving payment tokens. In response, the database may provide a variable (variable) indicating whether the request should be processed locally or remotely. In some implementations, the database may provide the IP address of a remote payment network server (e.g., such as remote payment network server 114 b) to which the local payment network server should forward the request. Thus, in some implementations, depending on the location of the user, the type of payment token used by the user, the account linked with the privacy-preserving anonymous payment token, etc., a request to process the user's payment token may be provided to an appropriate payment network server (e.g., 119). In this way, the PPT is able to route requests to a payment network server local to such requests. This may have the advantage of increased security and privacy, since the user's identification information does not have to be sent abroad. This may also have the advantage of potentially load balancing the processing of payment requests. In some implementations, the merchant's payment server may be aware of other regional payment servers and may contain a set of purchase source (authorization) management rules, where certain permissions may be identified as requiring that varying privacy levels (levels) be maintained. In these implementations, for example, when the payment request originates from a country (e.g., the european union) that requires maintaining the highest privacy level, the PPT may send a token and route the purchase transaction to an appropriate location (locality) relative to the purchase source. However, in an alternative example where the purchase source is from a location that does not have strict privacy requirements, the most readily available payment network server (e.g., current server, less loaded alternative server, etc.) may instead process the request.

Referring to FIG. 1B, in some implementations, a user may wish to purchase a product, service, and/or other offering ("product") from a merchant (e.g., 106). The user may wish to utilize a card such as 101a (e.g., debit card, credit card, pre-paid card, etc.), cash (or its equivalent) such as 102a, a security such as 103a, a virtual currency such as 104a, rewards, points, miles, and/or other payment options. However, the user may wish to remain anonymous to prevent the user's personal information from being collected by the merchant. As another example, the user may be alerted that the user's card data was abused to conduct a fraudulent transaction. In some implementations, the user may be able to utilize an alias (alias) or token in place of the payment information. For example, the user may be able to communicate a token (e.g., 101b, 102b, 103b, 104 b) to the merchant instead of complete card information, cash, or account information. Fig. 9A-14B illustrate various non-limiting advantageous aspects of a user utilizing a virtual wallet application to initiate a purchase transaction, including the option of "hiding" (cloak) the transaction using a payment token in place of payment information. The secure token arbiter may operate with a merchant to process transactions. For example, when a payment token is received from a user, the merchant may pass the token to the transaction arbitrator. The secure transaction arbiter may have the capability to parse the incoming token and determine the identity of the user for the token. The transaction arbiter may also determine financial payment information for processing the transaction. In some implementations, the transaction arbiter may also only have another token stored as payment information. In these implementations, the issuer of the token may be the only entity other than the user that knows the user's actual personal and/or financial information. Thus, in some implementations, a token may contain a combination of other tokens. For example, tokens held by the transaction arbiter may be directed to other tokens held by the transaction arbiter and/or the issuer. Thus, in some implementations, multiple layers of security for personal and financial information may be generated by building payment tokens accordingly. In some implementations, the token may specify a composition that includes a combination of other payment tokens. For example, the payment token 105 may indicate that a transaction may be processed by assigning a percentage (e.g., 55%) of the transaction expenditure (cost) to the token 101b (e.g., ultimately linked to the credit card information 101 a) and a different percentage (e.g., 45%) to a different token 102b (e.g., ultimately linked to the stored cash account 102 a). In some implementations, the percentage may be determined in real-time or near real-time. For example, the token arbiter may operate with an issuer having user accounts linked to the payment token to determine which user accounts should be charged and how much each user account should be charged (e.g., according to a predetermined algorithm). As another example, the percentage may be determined only when the transaction is processed, see e.g., 103b, 104b, e.g., by requesting the user to provide payment options when processing the purchase transaction.

In some implementations, an additional security formation layer (layer) is formed by using authentication methods. As an example, a user may be asked to liftFor the username and password to activate the payment token. As another example, the user may be required to provide a digital certificate to verify the user's identity before utilizing the payment token for the purchase transaction. As another example, a device fingerprint may be utilized. For example, a user's client device may be a device dedicated by the user, such as a smartphone, tablet and/or laptop computer, and so on. In some implementations, a custom hardware authentication chip, e.g., 103, may be arranged to communicate with the client. In various implementations, the chip may be embedded in the client, pre-installed in the client, attached to the client as a peripheral, and the like. In some implementations, the user may perform an authentication process using the client and the user's card linked to the user's payment token. For example, the authentication chip may be configured to identify the user's payment token physical card when the card is in proximity to the authentication chip. For example, the authentication chip and card may be Bluetooth enabled^TM、Wi-Fi^TMRFID tags, cellular connections (e.g., 3G, 4G), etc. Thus, to make a purchase with a payment token, in some implementations, a user may be required to present a payment token physical card to an authentication chip arranged to communicate with a client before the user can make a purchase reservation using the token. Thus, the system provides authenticity protection against others who may know the user's payment token from utilizing the user's payment token in fraudulent transactions.

Figures 2A-B represent application user interface diagrams illustrating example features of an application interface for controlling tokenized payment for purchase transactions in some embodiments of the PPT. In some implementations, an application executing on a user's device may include an application interface that provides various features to the user. In some implementations, the application may include an indication of the user's location (e.g., the name of the store, geographic location, information about aisles within the store, etc.), e.g., 201. The application may provide an indication of a payment amount due for the purchase of the product, e.g., 202. In some implementations, the application may provide various options for the user to pay the amount for purchasing the product. For example, the application may utilize GPS coordinates to determine the store where the user is located and direct the user to the merchant's website. In thatIn some implementations, the PPT may provide an API for directly participating in the merchant to facilitate transaction processing. In some implementations, a merchant brand PPT application may be developed using PPT functionality, and the merchant-designated PPT application may directly connect the user to a merchant's transaction processing system. For example, the user may select from a plurality of cards (e.g., credit cards, debit cards, pre-paid cards, etc.) from various card providers, e.g., 203. In some implementations, the application may provide the user with an option to pay a purchase amount by using funds contained in the user's bank account, e.g., check, savings, money market, current account (currentaccount), etc., e.g., 204. In some implementations, the user may have set a default option, by application, which card, bank account, etc. to use for the purchase transaction. In some implementations, the setting of such default options may allow a user to initiate a purchase transaction, e.g., 205, by clicking, tapping, swiping, and/or other remedial (remedial) user input action. In some implementations, when the user utilizes such options, the application may utilize the user's default settings to initiate the purchase transaction. In some implementations, the application may allow the user to utilize other accounts (e.g., Google)^TMCheckout、Paypal^TMAccount, etc.) to pay for the purchase transaction, e.g., 206. In some implementations, the application can allow the user to utilize reward points, airline miles, hotel points, electronic coupons, printed coupons (e.g., by capturing printed coupons similar to product identifiers), etc. to pay for purchase transactions, e.g., 207-208. In some implementations, the application may provide an option to provide express (express) authorization, e.g., 209, prior to initiating the purchase transaction. In some implementations, the application may provide a progress indicator to provide an indication about the progress of the transaction after the user has selected the option to initiate the purchase transaction, e.g., 210. In some implementations, the application may provide the user with historical information, e.g., 211, regarding the user's previous purchases through the application. In some implementations, the application may provide the user to share information about the purchase with other users (e.g., via email, SMS, etc.)Wall poster, Twitter^TMPushtext above, etc.) such as 212. In some implementations, the application may provide the user with an option to display product identification (identification) information captured by the client device (e.g., to present the product information to a customer service representative at an exit of the store), e.g., 214. In some implementations, a user, an application, a device, and/or a PPT may encounter an error in processing. In such a scenario, the user may be able to talk to a customer service representative (e.g., VerifyChat 213) to address difficulties in the purchase transaction process.

In some implementations, the user may choose to conduct transactions using a one-time token (e.g., an anonymous credit card number), see, e.g., 205 b. For example, PPT may utilize a set of tokenized and anonymized card details (see, e.g., "AnonCard 1," "AnonCard 2"). As another example, the PPT may generate a one-time anonymous set of card details, e.g., in real-time, to securely complete a purchase transaction (e.g., "Anon It 1X"). In such an implementation, the application may automatically set user profile (profile) settings so that any personally identifying information for the user will not be provided to the merchant and/or other entity. For example, the application may automatically send only a token or alias in place of the payment information. The payment system may process the token to obtain its associated payment information for processing the purchase transaction. In some implementations, the user may be required to enter a username and password to enable the anonymization feature.

In some implementations, the user may be able to control attributes of tokens associated with the user through a web interface, e.g., 220. For example, the user may be able to log into a web interface, e.g., 221, and visualize a payment token associated with the user, e.g., 223. The user may also be provided with a user interface element (element) that generates a new token. For example, the user interface may provide elements, e.g., 224, for creating a new token. The user interface may allow the user to select financial details 225, such as, but not limited to: a funding source from which the token is obtained, an account type of the token, an initial token value (e.g., for pre-funding and/or pore authorization), a value decay (decay) option (e.g., spending control to assist in time control of the user), billing address information, shipping address information, contact settings, security agreements, token administrator, user anonymization (for security) options, and so forth. In some implementations, the web interface may allow the user to select personal details 226, such as, but not limited to, token holder, frequency of contact (e.g., for token provision), token provision preferences, parental control (parental control), activated devices, and the like. In some implementations, the web interface may allow the user to specify activation (activation) 227 and expiration (expiration) 228 dates for the token.

Figures 3A-C represent application user interface diagrams illustrating example features of a payment tokenized mobile application for obtaining user data and protecting against fraud in some embodiments of a PPT. In some implementations, an application executing on the user's device may provide a "VerifyChat" feature for fraud prevention (e.g., by activating UI element 213 in fig. 2). For example, the PPT may detect anomalous and/or suspicious transactions. The PPT may utilize the VerifyChat feature to communicate with the user and verify the authenticity of the originator of the purchase transaction. In various implementations, the PPT may send an email message, a text (SMS) message, a text,Message, Twitter^TMTweets, text chats, voice chats, and/or video chats (e.g., AppleFaceTime), etc. to communicate with the user. For example, the PPT may initiate a video challenge for the user, e.g., 301. For example, a user may need to present himself/herself via video chat, e.g., 302. In some implementations, a customer service representative (e.g., agent 304 b) may manually determine the authenticity of the user using the user's video. In some implementations, the PPT may utilize facial, biometric (biometric), or the like recognition (e.g., using pattern classification techniques) to determine the identity of the user, e.g., 304 a. In some implementations, the application can provide a reference mark (marker)(e.g., crosshairs, target boxes, etc.), e.g., 303, so that the user can conduct a video to facilitate automatic identification of the user of the PPT. In some implementations, the user may not initiate the transaction, e.g., the transaction is fraudulent. In these implementations, the user may cancel the challenge, e.g., 305. The PPT may then cancel the transaction and/or initiate a fraud investigation process on behalf of the user.

In some implementations, the PPT may utilize a text challenge process to verify the authenticity of the user, e.g., 306. For example, PPT may be sent via text chat, SMS message, email, SMS, or the like,Message and/or Twitter^TMTweets, etc. communicate with the user. The PPT may present challenge questions to the user, e.g., 308. The application may provide a user input interface element (e.g., virtual keyboard 309) to answer the challenge question posed by the PPT. In some implementations, the challenge question may be automatically randomly selected by the PPT; in some implementations, a customer service representative may manually communicate with the user. In some implementations, the user may not initiate the transaction, e.g., the transaction is fraudulent. In these implementations, the user may cancel the text challenge, e.g., 307, 310. The PPT may then cancel the transaction and/or initiate a fraud investigation process on behalf of the user.

In some implementations, the application may be configured to identify a product identifier (e.g., a barcode, a QR code, etc.). For example, for fraud prevention, the application may require the user to utilize the user's device to obtain a snapshot of the item being purchased, thereby ensuring that the cardholder also possesses the user's device and purchases the item. In some implementations, a user may be required to log into an application to enable its features. Once enabled, the camera may provide a one tap (one tap) purchase feature for the user himself. For example, the client device may have a camera, e.g., 313, through which an application may obtain images, video data, streaming live video, and so on. The application may be configured to analyze the incoming data and search (e.g., 311) for a product identifier, e.g., 314. In some implementations, the application may overlay crosshairs, target boxes, and/or similar alignment reference marks, e.g., 315, such that a user may align (align) the product identifier using the reference marks, thereby facilitating product identifier identification and interpretation. In some implementations, the application may include an interface element (see, e.g., 316) that allows the user to toggle between the product recognition mode and the product providing interface display so that the user can accurately investigate the transactions available to the user before capturing the product identifier. In some implementations, the application may provide the user with the ability to view previous product identifier captures (e.g., see 317), so that the user may be able to better decide which product identifier the user wishes to capture. In some implementations, the user may wish to cancel a product purchase; the application may provide a user interface element (e.g., 318) to the user to cancel the product identifier identification process and return to the previous interface screen that the user was utilizing. In some implementations, information about products, user settings, merchants, offerings, and the like may be provided to the user in the form of a list (see, e.g., 319), so that the user may better understand the user's purchase options. Various other features may be provided in the application (see, e.g., 320).

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

For example, the user may travel to the doctor's office and wish to pay a co-paid medical fee (co-pay) for the doctor's appointment. In addition to basic transaction information such as account number and name, the application may provide the user with the ability to select to transfer medical records, health information that may be provided to medical providers, insurance companies, and transaction processors to coordinate payments between the parties. In some implementations, records may be sent and encrypted in a data format that conforms to the health insurance circulation and accountability act (HIPAA), and only recipients authorized to view these records may have the appropriate decryption keys to decrypt and view non-disclosed user information.

Figure 4 represents a data flow diagram illustrating an example process of joining a token-based purchase payment program in some embodiments of a PPT. In some implementations, a user (e.g., 401) may wish to purchase a product, service, offering, etc. (a "product") from a merchant. The user may communicate with the merchant server (e.g., 403 a) through a client (e.g., 402) such as, but not limited to, a personal computer, mobile device, television, point of sale terminal, kiosk, ATM, and the like. For example, the user may provide user input (e.g., purchase input 411) into the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but is not limited to: keyboard typing, swiping a card, activating an RFID/NFC enabled hardware device (e.g., electronic card with multiple accounts, smart phone, tablet, etc.), mouse click, pressing a button on a joystick/game console, voice command, single/multi touch gesture on a touch sensitive interface, touch user interface element on a touch sensitive display screen, etc. For example, a user may direct a browser application executing on a client device to a merchant's website and may select a product from the website by clicking on a hyperlink presented to the user through the website. As another example, the client may obtain tracking 1 data from the user's card (e.g., credit card, debit card, pre-paid card, charge card, etc.), such as the example tracking 1 data provided below:

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

in some implementations, the merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user. Based on the parsing, the merchant server may determine that the purchase order message is not tokenized, e.g., 414. When it is determined that the purchase order message is not tokenized, the merchant server may determine that the user needs to be provided with an option to register for the payment tokenization service. The merchant server may attempt to identify a token arbitrator to provide payment tokenization services for the user. For example, the merchant server may query (e.g., 415) a merchant database (e.g., 404) for the address of the token arbiter. For example, a merchant server may utilize a hypertext preprocessor ("PHP") script containing structured query language ("SQL") commands to query a relational database for the address of a token arbiter. An example PHP/SQL manifest (listing) for querying the database for the address of the token arbiter is provided below:

in response, the merchant database may provide a token arbiter address, e.g., 416. The merchant server may generate a tokenized invitation request, e.g., 417, on behalf of the user and provide the tokenized invitation request to the token server, e.g., 405. For example, the merchant server may provide an HTTP (S) POST message containing a tokenized invitation request similar to the following example:

in some implementations, the token server may parse the invitation request message and extract details of the user and the client from the message. The token server may generate (e.g., 419) a tokenization invitation and an application form for the user to complete the registration tokenization service. The token server may provide (e.g., 420) the tokenized invitation and application form to the client (either directly to the client or through the merchant server). For example, the token server may provide an HTTP (S) POST message containing XML data representing the tokenized input form 420, such as the following example HTTP (S) POST message:

the client can render (e.g., 421) the tokenized invitation and application forms and display (e.g., 422) the invitation and application forms (e.g., 423) to the user. In some implementations, the user may wish to register for a payment tokenization service and may provide token creation input to complete an application form, e.g., 423. The client may generate a completed application form and provide (e.g., 424) the token application (either directly or through the merchant server) to the token server. For example, the client may provide an HTTP (S) POST message for a token application 424 similar to the example below:

the token server may obtain the application form and parse the form to extract a data field (field) and values from the form to generate a token data record, e.g., 425. The token server may also determine a set of privacy rules, restrictions (restrictions), transaction processing rules (e.g., in which country the server involved in the transaction processing should reside) applicable to the token created for the user. For example, such a restriction may specify that all transactions involving tokens may only be processed at a server located inside a particular country (e.g., payment). As another example, the restrictions may be updated (e.g., periodically, automatically, on-demand) based on privacy and/or other laws governing the processing of (govern) transactions in the country. As another example, the restrictions may give weight (weight) to various factors (e.g., transaction processing server load balancing, network congestion, privacy constraints, security constraints, etc.), and may require weighting the factors (e.g., by calculating a weighted average score based on the factors) to determine the country in which the transaction is processed with the token. As another example, the token may specify a set of countries that may (or may not) process the transaction. For non-limiting explanatory purposes only, the following XML data structure shows example rules 427 that may be generated with respect to tokens and stored in a database table (see, e.g., fig. 15, privacy rules 1519n table) within the privacy rules database 406 b.

For example, the rules may specify where payment transactions should occur to prevent the customer's private payment information from being used outside of the territory specified by the privacy rules. For example, some countries with strict privacy controls will require that payment processing only occur in countries where the consumer has an account (see rule 1 below); other countries may have privacy controls that require payment processing to occur only in regions (e.g., any country in the EU, see rule 2 below); other countries may not have privacy restrictions, so payment processing may occur anywhere (see, e.g., rule 3 below), and this may allow rules that enhance load balancing and improve network efficiency by assigning processing to less-used servers (see, e.g., rule 4 below).

In some embodiments, the user may specify custom settings that override (override) default settings that may be provided by the token server based on the location of the issuer of the funding source under the token (undersying). In some embodiments, if the user provides custom settings to override the default settings provided by the token server, the token server may perform error checking of the custom settings to ensure that they are internally consistent, in compliance with applicable laws and rules, and/or in compliance with default network congestion and server load balancing rules for transaction processing within the payment network invoked by the funding source under the token. Also, in some embodiments, the token may not contain internal privacy rules, but may provide a unique identifier that may be used by the PPT to query a private country code database to identify the country (home country) and its privacy restrictions based on the owner of the token; for example, a token hash may be generated from a consumer's unique identifying information (e.g., account identifier, unique name/address/age/etc. pairing, social security number, etc.) such that the resulting hash will be unique to the consumer and the basis for a query that may be used to identify the consumer's home country, and then privacy rules associated with that home country may be applied in the payment resolution (resolution) of the routing token.

The token server may store the data extracted from the application form to a token database (e.g., 406 a) and store privacy/restriction settings 427 in privacy rules database 406 b. For example, the token server may issue PHP/SQL commands similar to the examples below:

figure 5 represents a logic flow diagram illustrating an example aspect of joining a token-based purchase payment program, e.g., a token-based purchase joining ("TPE") component 500, in some embodiments of a PPT. In some implementations, a user may wish to purchase a product, service, offering, etc ("product") from a merchant. The user may provide user input (e.g., purchase input 501) into the client indicating the user's desire to purchase the product. In some implementations, the client can generate a purchase order message (e.g., 502) and provide the generated purchase order message to the merchant server. The merchant server may obtain the purchase order message from the client and may parse the purchase order message to extract details of the purchase order from the user, e.g., 503. For example, the merchant server may utilize a resolver similar to the example resolver discussed below in the description with reference to FIG. 15. Based on the parsing, the merchant server may determine that the purchase order message is not tokenized, e.g., 504, with the option of "no". If the merchant server determines that the purchase order message is tokenized, the merchant server may invoke a process to process the transaction, such as tPTTE 700 described further below in the discussion of FIG. 7. When it is determined that the purchase order message is not tokenized, the merchant server may determine that the user needs to be provided the option to register for payment tokenization services. The merchant server may attempt to identify a token arbitrator to provide payment tokenization services for the user. For example, the merchant server may query (e.g., 505) the merchant database for the address of the token arbiter. In response, the merchant database may provide a token arbiter address, e.g., 506. The merchant server may generate a tokenized invitation request (e.g., 507) on behalf of the user and provide the tokenized invitation request to the token server.

In some implementations, the token server may parse the invitation request message and extract details of the user and the client from the message, e.g., 508. The token server may determine whether additional information from the user is needed to generate the token data structure and/or the token data record, e.g., 509. If additional information is required (e.g., if not all fields of the token data record can be completed with available information), the token server may generate a token entry form (e.g., 511) and provide the user with the token entry form. The token server may provide the token input form to the client (either directly to the client or through the merchant server). The client may render the form and display (e.g., 512) the form for the user. In some implementations, a user may obtain a form such as the example user interface diagram depicted in FIG. 2B.

In some implementations, the user may wish to register for a payment tokenization service and may provide token creation input to complete the form, e.g., 513 (e.g., in one example, the user may engage (engage) "hidden", see fig. 10A, 1022, or may otherwise provide an indication that they wish to enhance privacy in their transaction) (in an alternative example, the user may provide such an indication by requesting and/or otherwise purchasing a prepaid card, smart card, one-time-use card, credit card, debit card, smart phone, PDA, having token information contained therein). The client may generate a completed form and provide (e.g., 514) the form to the token server (either directly or through the merchant server). The token server may obtain the form and parse the form to extract data fields and values from the form to produce a token data record (e.g., 515). For example, regardless of the token request channel (e.g., merchant, issuer, acquirer (acquirer), payment network, user, etc.), the token server may generate a unique and parsable token identifier. In some implementations, the token server keeps track of all generated tokens by token identifiers, and as each token is created, subsequent requests to create tokens with the same token identifier will be denied. In some implementations, token record creation may be performed in series. For example, a serial sequence of token identifiers (serial series) may be created for each issuer, merchant, acquirer, and/or payment network. For example, each sequence may relate to a range of values that is unique to each source. In other implementations, rather than serial applications, the token identifiers may be assigned by random assignment. In some implementations, each token may be pre-funded (prefund). For example, the source of the token (e.g., the issuer, acquirer, independent token arbiter) may first obtain a guarantee that the token has been uniquely and exclusively allocated funds from the source to which the token is directed. Thus, in some implementations, the token may be pre-funded and pre-authorized for up to (or in the alternative, for exactly) a predefined purchase transaction amount. For example, the token server may generate a token data structure similar to the following example XML encoded data structure:

the token server may also determine a set of privacy rules, restrictions, transaction processing rules applicable to the token created for the user (e.g., in which country the server involved in the transaction processing should reside). The token server may store the token data structure to a token database and the privacy rules/restrictions/settings to a privacy rules database, e.g., 516. The token server may also provide the client with a token identifier, e.g., 517. The token may be provided as a data structure, as a file (via a file transfer protocol), as an attachment (e.g., via email), and/or otherwise provided to the client device for later use via HTTP (S) POST. The client may store and/or display the token identifier for the user, e.g., 518.

Figures 6A-E represent data flow diagrams illustrating an example process of performing a token-based purchase transaction in some embodiments of a PPT. In some implementations, a user (e.g., 601) may wish to purchase a product, service, offering, etc. (a "product") from a merchant. The user may communicate with the merchant server (e.g., 603 a) through a client (e.g., 602) such as, but not limited to, a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, etc. For example, the user may provide user input (e.g., purchase input 611) into the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but is not limited to: keyboard typing, swiping a card, activating an RFID/NFC enabled hardware device (e.g., electronic card with multiple accounts, smart phone, tablet, etc.), mouse click, pressing a button on a joystick/game console, voice command, single/multi touch gesture on a touch sensitive interface, touch user interface element on a touch sensitive display screen, etc. For example, a user may direct a browser application executing on a client device to a merchant's website and may select a product from the website by clicking on a hyperlink presented to the user through the website. As another example, the client may obtain tracking 1 data from the user's card (e.g., credit card, debit card, pre-paid card, charge card, etc.), such as the example tracking 1 data provided below:

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

in some implementations, the merchant server may obtain the purchase order message from the client and may parse the purchase order message to extract details of the purchase order from the user. Based on parsing the message, the merchant server may determine that the purchase order message is tokenized. The merchant server may issue a query (e.g., 615) to a merchant database (e.g., 604) to determine an arbitrator to process the tokenized purchase order. For example, a merchant server may utilize a hypertext preprocessor ("PHP") script containing structured query language ("SQL") commands to query a relational database for the address of a token arbiter. An example PHP/SQL listing for querying a database for token arbiter addresses is provided below:

in response, the merchant database may provide a token arbiter address, e.g., 616. The merchant server may generate a token arbitration request (e.g., 617) and provide the token arbitration request (e.g., 618) to the token server (e.g., 605). For example, the merchant server may provide an HTTP (S) POST message containing a token arbitration request similar to the example below:

in various implementations, the token server may be part of a merchant system (e.g., merchant processing), or part of a payment network (e.g., payment network server), or a separate server operating with the merchant, issuer, acquirer, and payment network. In general, it should be understood that any entity and/or component included in a PPT may function as a token arbiter. In some implementations, the token server may parse the token arbitration request message and extract the payment token from the message. The token server, using the payment token, may determine payment options for processing the transaction (or determine whether to request the user to provide payment option details). For example, the token server may issue (e.g., 619) a user issuer query to a database (e.g., token database 606) using the payment token as a search term in the query. For example, the token server may utilize PHP/SQL commands similar to the examples described above. In response, the token database may provide an issuer data response (e.g., 620) that contains data about the issuer contacted for the payment. For example, the issuer data response may include an XML encoded data file containing instructions for the token server on how to proceed with payment processing for the transaction. An example XML encoded issuer data file is provided below:

in some implementations, the token server may determine whether the user token is authenticated, e.g., 621. For example, if no XML data associated with the payment token is available, the token server may ensureThe given user does not register for the payment tokenization service. As another example, if the XML data indicates that the user must be queried for authentication (e.g., login and password), the token server may determine that authentication needs to be verified. The token server may initiate a user authentication session. For example, an application executing on the user's device may provide a "VerifyChat" feature (e.g., by activating UI element 213 in fig. 2) to guard against fraud. The token server may utilize the VerifyChat feature to communicate with the user and verify the authenticity of the originator (originator) of the purchase transaction. In various implementations, the token server may send an email message, a text (SMS) message, a message, or a message,Message, Twitter^TMText push, text chat, voice chat, video chat (e.g., Apple FaceTime), etc. to communicate with the user. For example, the token server may initiate a video challenge to the user. For example, a user may need to present himself/herself through video chat. In some implementations, the customer service representative may manually determine the authenticity of the user using a video of the user. In some implementations, the PPT may utilize facial, biometric, and/or similar recognition (e.g., using pattern classification techniques) to determine the identity of the user. In some implementations, the application may provide a reference marker (e.g., a crosshair, a target box, etc.) so that the user can make a video to facilitate automatic identification of the user of the PPT. As another example, the token server may request the user for a digital certificate to verify authenticity. As another example, the token server may request a username and password to enable (enable) a token for payment processing.

If the token server determines that the user is authenticated, the token server may provide a token authentication confirmation, e.g., 622 a. Also, if the token server determines that the user should be queried for payment options (e.g., instead of using only the settings predefined in the issuer data response 620), the token server may request payment options from the user. For example, the token server may provide an HTTP (S) POST message similar to the example above to the client 602. The client may render (e.g., 623) the token authentication confirmation and/or payment option request and display a message (e.g., 624) for the user.

In some implementations, the user may wish to enter customized payment options to process the current purchase transaction. In these implementations, for example, the user may provide a payment option input 626, such as discussed above in the description with reference to fig. 2, for example. The client may generate a payment option message using the user's input and provide the payment option message to the token server (e.g., 627). In some embodiments, the token server may obtain privacy rules/restrictions/settings (e.g., 628 a) from a privacy rules database, based on which the token server may determine the location and identity of the server to which the token server should send token data, issuer data, payment options, etc. for transaction processing. In some implementations, the token server may determine the issuer to contact for payment processing, e.g., 628b, using predefined issuer settings, privacy rules/restrictions/settings, and/or payment option inputs provided by the user. In some implementations, the token server can update issuer data stored in the token database, e.g., 629, using payment option inputs provided by the user.

In some implementations, the token server may provide token data, issuer data, and/or user payment option input to the payment network server, e.g., 634 (e.g., if the token server is separate from the payment network system). For example, the token server may provide an HTTP (S) POST message to a payment network server similar to the example above. The payment network server may process the transaction to transfer funds for the purchase into an account stored on the merchant's acquirer. For example, the acquirer may be a financial institution holding the merchant's account. For example, the proceeds of a transaction processed by a merchant may be deposited into an account maintained by a server of the acquirer.

In some implementations, the payment network server may generate a query to the issuer server corresponding to the payment token and the user-selected payment option, e.g., 635. For example, the user's payment token may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, that issue accounts for the user linked to the payment token. For example, such accounts may include, but are not limited to: credit cards, debit cards, prepaid cards, checks, savings, money markets, savings cards, and/or store (cash) value accounts, and the like. The issuer server (e.g., 609 a-n) of the issuer may maintain details of the user's account linked to the payment token. In some implementations, a database (e.g., payment network database 608) may store details of an issuer server associated with an issuer. For example, the database may be a relational database that is responsive to structured query language ("SQI") commands. The payment network server may query the payment network database for issuer server details. For example, the payment network server may execute a hypertext preprocessor ("PHP") script containing SQL commands to query the database for details of the issuer server. An example PHP/SQL command list showing the essential aspects of querying a database is provided below:

in response to obtaining the issuer server query (e.g., 635), the payment network database may provide (e.g., 636) the requested issuer server data to the payment network server. In some implementations, the payment network server may utilize the issuer server data to generate authorization requests (e.g., 637) for each of the issuer servers selected based on predefined payment settings associated with the token and/or payment option input by the user, and provide the card authorization requests (e.g., 638 a-n) to the issuer servers (e.g., 609 a-n). In some implementations, the authorization request may include details such as, but not limited to, the user's expenditure involved in the transaction, the user's card account details, the user's bill, and/or shipping information. For example, the payment network server may provide an HTTP (S) POST message containing an XML formatted authorization request similar to the example manifest provided below:

in some implementations, the issuer server may parse the authorization request and, based on the request details, may query a database (e.g., user profile databases 610 a-n) for data associated with accounts linked to the user's payment token. For example, the issuer server may issue PHP/SQL commands similar to the examples provided below:

in some implementations, when obtaining user data (e.g., 640 a-n), the issuer server may determine whether the user may use funds available in the account to pay for the transaction, e.g., 641 a-n. For example, the issuer server may determine whether the user has a sufficient remaining balance in the account, has sufficient credit associated with the account, and so on. Based on the determination, the issuer server may provide an authorization response (e.g., 642 a-n) to the payment network server. For example, the issuer server may provide an HTTP (S) POST message similar to the example above. In some implementations, if at least one issuer server determines that the user cannot pay for a transaction using funds available in the account (see, e.g., 643-644), the payment network server may re-request payment options from the user (e.g., by providing an authorization failure message 644 to the token server and requesting the token server to re-obtain payment option inputs from the user) and attempt authorization for the purchase transaction again. In some implementations, if the number of failed authorization attempts exceeds a threshold, the payment network server may abort the authorization process and provide an "authorization failed" message to the merchant server, token server, and/or client.

In some implementations, the payment network server may obtain an authorization message (see, e.g., 643, 646) that includes a notification of successful authorization and parse the message to extract authorization details. When it is determined that the user has sufficient funds for the transaction, the payment network server may generate a transaction data record (e.g., 645) from the authorization request and/or the authorization response and store the authorization related to the transaction and the details of the transaction in a transaction database. For example, the payment network server may issue PHP/SQL commands similar to the following example listing to store transaction data in the database:

in some implementations, the payment network server may forward the authorization success message (e.g., 646) to the token server, which may in turn forward the authorization success message (e.g., 647) to the merchant server. The merchant may obtain the authorization message and determine from it that the user has sufficient funds in the card account to conduct the transaction. The merchant server may add a record of the user's transaction to a collection of transaction data relating to the authorized transaction. For example, the merchant may append XML data pertaining to user transactions to an XML data file (e.g., 648) containing XML data for transactions that have been authorized for the respective user and store the XML data file (e.g., 649) in a database (e.g., merchant database 604). For example, a batch (batch) XML data file may be constructed that is similar to the example XML data structure template provided below:

in some implementations, the server may also generate a purchase receipt (e.g., 648) and provide the purchase receipt to the client (e.g., 650). The client can render and display (e.g., 651-652) a purchase receipt for the user. For example, the client may render a web page, electronic message, text/SMS message, buffer voicemail, ring tone and/or play an audio message, etc., and provide output including, but not limited to, sound, music, audio, video, images, haptic feedback, vibratory alerts (e.g., on a client device capable of vibrating such as a smartphone), etc.

Referring to FIG. 6E, in some implementations, the merchant server may initiate a clearing (clearness) of a set of authorized transactions. For example, the merchant server may generate a bulk data request (e.g., 653) and provide the request (e.g., 654) to a database (e.g., merchant database 604). For example, the merchant server may utilize PHP/SQL commands similar to the examples provided above to query the relational database. In response to the batch data request, the database may provide the requested batch data, e.g., 655. The server may generate a batch clearing request (e.g., 656) using the batch data obtained from the database and provide (e.g., 657) the batch clearing request to the acquirer server (e.g., 603 b). For example, the merchant server may provide an HTTP (S) POST message to the acquirer server that contains XML formatted bulk data in the message body. The acquirer server may generate (e.g., 658) a bulk payment request using the obtained bulk clearing request and provide the bulk payment request to a payment network server (e.g., 659). The payment network server may parse the bulk payment request and extract transaction data (e.g., 660) for each transaction stored in the bulk payment request. The payment network server may store transaction data (e.g., 661) for each transaction in a database (e.g., payment network database 608). For each extracted transaction, the payment network server may query (e.g., 662-663) a database (e.g., payment network database 608) for the address of the issuer server. For example, the payment network server may utilize PHP/SQL commands similar to the examples provided above. The payment network server may generate a single (individual) payment request (e.g., 664) for each transaction for which it has extracted transaction data and provide the single payment request (e.g., 665) to the issuer server (e.g., 609). For example, the payment network server may provide an HTTP (S) POST request similar to the following example:

in some implementations, the issuer server may generate the payment command (e.g., 666). For example, the issuer server may issue a command to deduct funds from the user's account (or add a fee to the user's credit card account). The issuer server may issue a payment command (e.g., 667) to a database (e.g., user profile database 610) that stores account information for the user. The issuer server may provide the funds-transfer message (e.g., 668) to the payment network server, which may forward (e.g., 669) the funds-transfer message to the acquirer server. An example HTTP (S) POST funds transfer message is provided below:

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

Figures 7A-F represent a logical flow diagram illustrating exemplary aspects of performing a token-based purchase transaction in some embodiments of a PPT, such as a token-based purchase transaction execution ("tPTE") component 700. In some implementations, a user may wish to purchase a product, service, offering, etc ("product") from a merchant. The user may communicate with the merchant server through the client. For example, the user may provide a purchase input (e.g., 701) into the client indicating the user's desire to purchase the product. In some implementations, the client can generate a tokenized purchase order message (e.g., 702) and provide the tokenized purchase order message to the merchant server. The merchant server may obtain the purchase order message from the client and may parse the purchase order message to extract details of the purchase order from the user. Based on parsing the message, the merchant may determine that the purchase order is tokenized (e.g., 703). If the merchant server determines that the purchase order is not tokenized (e.g., 704, option "no"), the merchant server may treat the transaction as a normal card-based transaction and bypass the token interpretation process. If the merchant server determines that the purchase order is tokenized (e.g., 704, option "yes"), the merchant server may issue a query (e.g., 705) to the merchant database to determine an arbitrator to process the tokenized purchase order. In response, the merchant database may provide a token arbiter address (e.g., 707). The merchant server may generate a token arbitration request (e.g., 708) and provide the token arbitration request to the token server.

In some implementations, the token server may parse the token arbitration request message and extract the payment token from the message. The token server may use the payment token to determine payment options for processing the transaction (or to determine whether to request the user to provide payment option details). For example, the token server may issue (e.g., 708) a user issuer query to the token database using the payment token as a search term in the query. In response, the token database may provide an issuer data response (e.g., 709) that contains data about the issuer contacted for the payment. In some implementations, the token server may determine whether the user token is authenticated (e.g., 710). If the token server determines that the user is not authenticated (e.g., 711, option "no"), the token server may generate an "authorization failure message" (e.g., 712 a) and initiate an error handling routine (routine) and/or a user registration routine (e.g., 712 b), such as the PTE500 component discussed above in the description with reference to FIG. 5. If the token server determines that the user is authorized (e.g., 711, option "yes"), the token server may continue processing at 713 a. The token server may generate a query 713a for token data from the token database and privacy rules, restrictions, settings, etc. associated with the token from the privacy rules database. For example, such a restriction may specify that all transactions involving tokens may only be processed at servers located inside a particular country. As another example, the restrictions may be updated (e.g., periodically, automatically, on-demand) based on privacy and/or other laws governing the processing of transactions in that country. As another example, the restrictions may give weight to various factors (e.g., transaction processing server load balancing, network congestion, privacy constraints, security constraints, etc.), and the factors may need to be weighted (e.g., by computing a weighted average score based on the factors) to determine the country in which the transaction is processed with the token. As another example, the token may specify a set of countries that may (or may not) process the transaction. The privacy rules database may provide the requested data to the token server. As has been discussed above, in embodiments where the token itself does not contain a country code, a private database table (e.g., 1519 o) may be used to resolve the consumer's home country, country code, and/or limitations thereof by using the token as a basis for querying such database table. The token server may utilize token data and/or privacy rules, restrictions, settings, etc. to determine whether the user should be queried for payment options (e.g., instead of using only predefined settings in the issuer data response), e.g., 714. If the token server determines that the user should be queried for payment option settings (e.g., 715, option "no"), the token server may request payment options from the user, e.g., 716. The client may render the payment option request and display the request, e.g., 717.

In some implementations, the user may wish to enter customized payment options to process the current purchase transaction. In such an implementation, the user may provide a payment option input 718. The client may generate a payment option message using the user's input and provide the payment option message to the token server. In some implementations, the token server may use predefined issuer settings, privacy rules, transaction processing limits, settings, etc. (obtained from a privacy rules database), and/or payment option inputs provided by the user to determine the identity (e.g., IP address, MAC address, URL, etc.) of the payment network, issuer's server contacted for payment processing, e.g., 719. In some implementations, the token server can update issuer data stored in the token database using payment option inputs provided by the user, e.g., 720. In some implementations, the token server may generate an "authorization in progress" message (e.g., 721) and provide the message to a merchant server, which may then forward (e.g., 722) the message to the client. The client can present and display (e.g., 723) an "authorized in progress" message to the user.

In some implementations, the token server may generate a message (e.g., 724) containing token data, issuer data, and/or user payment option inputs and provide the message to a payment network server selected using privacy rules, transaction processing limits, settings, etc. (e.g., if the token server is separate from the payment network system). The payment network server may process the transaction to transfer funds for the purchase into an account stored on the merchant's acquirer. If the merchant server initially receives a non-tokenized purchase order message (e.g., 725) for the client, the merchant server may generate a card inquiry request (e.g., 726) and provide the card inquiry request to the acquirer server. The acquirer server may parse the merchant server's request (e.g., 727), generate a card authorization request (e.g., 728), and provide the card authorization request to the payment network server. However, if the initial purchase order from the client is tokenized, the token server deconstructs (deconstruct) payment details to be utilized as discussed above and may provide token, issue, and payment options to the payment network server, e.g., 729.

In some implementations, the payment network server may generate a query (e.g., 729) to the issuer server corresponding to the payment token and the user-selected payment option. In some implementations, the payment network server may query the payment network database for issuer server details, e.g., 730. In response to obtaining the issuer server query, the payment network database may provide (e.g., 731) the requested issuer server data to the payment network server. In some implementations, the payment network server may utilize the issuer server data to generate authorization requests (e.g., 732) for each of the issuer servers selected based on predefined token-related payment settings and/or user payment option inputs, and provide the card authorization requests to the issuer servers. In some implementations, the issuer server may parse the authorization request (e.g., 733) and, based on the request details, may query a user profile database (e.g., 734) for data associated with the account linked to the user's payment token. In some implementations, when obtaining user data, e.g., 735, the issuer server may determine whether the user may pay for a transaction using funds available in the account (e.g., 736). For example, the issuer server may determine whether the user has a sufficient remaining balance in the account, has sufficient credit associated with the account, and so on. Based on the determination, the issuer server may generate and provide an authorization response (e.g., 737) to the payment network server. In some implementations, if at least one issuer server determines that the user cannot pay for the transaction using funds available in the account (see, e.g., 738, 739, option no), the payment network server may re-request payment options from the user (e.g., by providing an authorization failure message 644 to the token server and requesting the token server to re-obtain payment option input from the user) and attempt authorization for the purchase transaction again. In some implementations, if the number of failed authorization attempts exceeds a threshold (e.g., 740, with option "yes"), the payment network server may abort the authorization process and provide a "transaction terminate" message, e.g., 741, to the merchant server, token server, and/or client.

In some implementations, the payment network server may obtain an authorization message that includes a notification of successful authorization and parse the message to extract authorization details. When it is determined that the user has sufficient funds for the transaction (e.g., 739, option "yes"), the payment network server may generate a transaction data record (e.g., 742) from the authorization request and/or the authorization response and store (e.g., 743) the authorization related to the transaction and the details of the transaction in a transaction database. In some implementations, the payment network server can generate an authorization success message (e.g., 744) and forward the message to the token server, which can then forward (e.g., 745-756) the authorization success message to the acquirer server and/or the merchant server. In some embodiments, the authorization success message may not include personally identifying information, and in some embodiments may only include the payment token identifier. The merchant can obtain the authorization message and determine therefrom whether the transaction is authorized, e.g., 747-748. If the transaction is authorized (e.g., 748, yes option), the merchant server may add a record of the user's transaction to a collection of transaction data related to authorizing the transaction, e.g., 749-750. In some implementations, the server can also generate a purchase receipt, e.g., 751, and provide the purchase receipt to the client. The client may render and display (753) a purchase receipt for the user.

Referring to FIGS. 7E-F, in some implementations, the merchant server may initiate clearing of a batch of authorized transactions. For example, the merchant server may generate a batch data request (e.g., 754) and provide the request to the merchant database. In response to the batch data request, the merchant database may provide the requested batch data (e.g., 755). The server may generate a batch clearing request (e.g., 756) using the batch data obtained from the database and provide the batch clearing request to the acquirer server. The acquirer server may parse the bulk clearing request (e.g., 657) and generate (e.g., 758) a bulk payment request using the obtained bulk clearing request and provide the bulk payment request to the payment network server. The payment network server may parse the bulk payment request (e.g., 759) and extract transaction data for each transaction stored in the bulk payment request. For each payment request in the batch, the payment network server may extract the purchase transaction data (e.g., 761) and generate a transaction data record (e.g., 762). The payment network server may store transaction data (e.g., 763) for each transaction in a payment network database. For each extracted transaction, the payment network server may query (e.g., 764-765) the payment network database for the address of the issuer server. The payment network server may generate a single payment request (e.g., 766) for each transaction for which it has extracted transaction data and provide the single payment request to the issuer server.

In some implementations, the issuer server may parse the single payment request (e.g., 767) and generate a payment order (e.g., 768). For example, the issuer server may issue a command to deduct funds from the user's account (or add a fee to the user's credit card account). The issuer server may issue payment commands to the user profile database. The issuer server may generate a funds transfer message (e.g., 770) and provide the message to the payment network server. As described above, the system may process individual payment requests in the batch until all requests in the batch have been processed (see 771, for example). The payment network server may then generate a bulk funds transfer message (e.g., 772) and provide the bulk funds transfer message (e.g., 773) to the acquirer server. In some implementations, the acquirer server may parse the funds-transfer message and associate the transaction with the merchant. The acquirer server may then transfer the funds specified in the funds-transfer message to the merchant's account, e.g., 774.

Figure 8 represents a user interface diagram showing an overview of example features of a virtual wallet application in some embodiments of PPTs. Fig. 8 shows a diagram of various example features of a virtual wallet application 800. Some of the features displayed include wallet 801, social integration by TWITTER, FACEBOOK, etc., offers and loyalty 803, captures mobile purchases 804, alerts 805, and security, settings, and analytics 896. These features are explored in further detail below.

Figures 9A-G represent user interface diagrams illustrating example features of a virtual wallet application in a shopping mode in some embodiments of a PPT. Referring to fig. 9A, some embodiments of the virtual wallet mobile application facilitate and greatly enhance the consumer's shopping experience. The various shopping modes shown in FIG. 9A are available for the consumer to browse. For example, in one implementation, a user may initiate a shopping mode by selecting a shopping icon 910 at the bottom of the user interface. The user may type items in the search field 912 to search for items and/or add them to the shopping cart 911. The user may also use a voice activated shopping mode by speaking into the microphone 913 the name or description of the item to be searched for and/or added to the shopping cart. In other implementations, the user may also select other shopping options 914, such as current item 915, bill 916, address book 917, merchant 918, and local proximity 919.

In one embodiment, for example, the user may select the option current item 915 represented in the leftmost user interface of FIG. 9A. When the current item 915 option is selected, an intermediate user interface may be displayed. As shown, the intermediary user interface may provide a current list of items 915 a-h in the user's shopping cart 911. The user may select an item, such as item 915a, to view product descriptions 915j of the selected item and/or other items from the same merchant. The price and total due information may also be displayed along with the QR code 915k capturing the information needed to effect the capture of the mobile purchase transaction.

Referring to FIG. 9B, in another embodiment, the user may select the bill 916 option. When the bill 916 option is selected, the user interface may display a list of bills and/or receipts 916 a-h from one or more merchants. Near each of the bills, additional information may be displayed, such as access dates, whether there are items from multiple stores, last bill payment date, automatic payment and/or number of items, etc. In one example, wallet bill 916a may be selected for purchase on a date of 2011, 1 month, 20 days. 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 916k, < <916i > >, a total number of items, and a corresponding value. For example, 7 items worth $102.54 are in the wallet shopping bill of choice. The user may now select any of the items and choose to re-purchase to add the purchased items. The user may also refresh offer 916j to clear any invalid offers since the last time and/or search for new offers applicable to the current purchase. As shown in fig. 9B, the user may select two items for repeat purchase. When incremented, a message 916l may be displayed to confirm the increment of the two items, which results in a total number of items in the shopping cart of 14.

Referring to FIG. 9C, in yet another embodiment, the user can select the address book option 917a to view the address book 917a containing the list of contacts 917b and make any money transfer or payment. In one embodiment, the address book may use its name and available and/or preferred payment patterns to identify contacts. For example, contact Amanda g. may be paid through social payment (e.g., through facebook) indicated by icon 917 c. In another example, money may be transferred to Brian s.through a QR code indicated by QR code icon 917 d. In yet another example, Charles b. may accept payment through near field communication 917e, bluetooth 917f, and email 917 g. Payments may also be made through USB917h (e.g., by physically connecting two mobile devices) and other social channels such as TWITTER.

In one implementation, the user may select Joe p. for payment, as shown in the user interface, with an email icon 917g near its name indicating that Joe p. When his name is selected, the user interface may display its contact information, such as electronicMail, telephone, etc. If the user wishes to pay Joe P. by a method other than email, the user can add another transfer mode 917j to his contact information and make a payment transfer. Referring to FIG. 9D, the user may be provided with a screen 917k in which the user may type an amount to send Joe and an environment 917l that may add other text to provide Joe with a payment transaction. The user may select a mode (e.g., SMS, email, social network) through graphical user interface element 917m that may contact Joe. When the user types in, the typed text may be provided for review (review) within the GUI element 917 n. When the user is finished typing the necessary information, the user can press send button 917o to send a social message to Joe. If Joe also has a virtual wallet application, Joe may be able to be within the application or directly on a social network (e.g., for Twitter)^TM、Etc.) to consult 917p social payment messages. Messages may be aggregated from various social networks and other sources (e.g., SMS, email). A redemption (redeplication) method applicable to each message mode may be indicated along with the social payment message. In the diagram in FIG. 9D, Joe's received SMS917q indicates that Joe can redeem $5 obtained by SMS by replying to the SMS and typing in a Hash tag (tag) value "# 1234". In the same diagram, Joe also passesMessage 917r is received, which message 917r contains a URL link that Joe can activate to initiate a redemption for $25 payment.

Referring to FIG. 9E, in some other embodiments, the user may select a merchant 918 from the list of options in the shopping mode to view a selection list 918 a-E of merchants. In one implementation, the merchants in the list may be in close association with, or have a close relationship to, a wallet. In another implementation, the merchant may contain a list of merchants that meet user-defined or other criteria. For example, the list may be a list of organizations (treates) by users, merchants that the user purchases most frequently, or spends more than a total amount x or three consecutive months. In one implementation, the user may also select one of the merchants, such as Amazon918 a. The user may then navigate the list of merchants to find items of interest such as 918 f-j. The user may make a selection of item 918j from Amazon918 a's catalog when going directly through a wallet and without needing to access the merchant site from a separate page. As shown on the far right side of the user interface of FIG. 9D, the selected items may then be added to the shopping cart. The message 918k indicates that the selected item has been added to the shopping cart, and the updated number of items in the shopping cart is now 13.

Referring to FIG. 9F, in one embodiment, there may be a local proximity option 919 that may be selected by the user to view a list of merchants that are very close in geography to the user. For example, the list of merchants 919 a-e may be merchants located near the user. In one implementation, the mobile application may further identify the time the user is in the store based on the user's location. For example, when the user is very close to a store, the location icon 919d may be displayed close to the store (e.g., Walgreens). In one implementation, in the event that the user moves away from the store (e.g., Walgreens), the mobile application may periodically refresh its location. In another implementation, the user may navigate the offerings of the selected Walgreens store through a mobile application. For example, a user may navigate to items 919 f-j available on aisle 5 of Walgreens using a mobile application. In one implementation, the user may select grain 919i from his or her movements to add to the shopping cart 919 k.

Referring to fig. 9G, in another embodiment, the local proximity options 919 may include store maps and real-time map features, among others. For example, when a Walgreens store is selected, the user may launch an aisle map 919l that displays a map 919m representing the organization of the store and the user's location (indicated by the yellow circle). In one implementation, a user may easily configure a map to add one or more other users (e.g., the user's children) to share each other's location within the store. In another implementation, the user may have an option to launch a "shop view" similar to the street view in the map. The store view 919n may display images/videos around the user. For example, if a user is about to enter the aisle 5, the store view map may represent a view of the aisle 5. In addition, the user may manipulate the direction of the map using the navigation tool 919o to move forward, backward, right, left, and rotate the store view clockwise and counterclockwise.

Figures 10A-F represent user interface diagrams illustrating example features of a virtual wallet application in payment mode in some embodiments of PPT. Referring to fig. 10A, in one embodiment, the wallet mobile application may provide the user with a number of options for paying for transactions via wallet mode 1010. In one implementation, an example user interface 1011 for making a payment is shown. The user interface may clearly identify the amount 1012 and currency 1013 for the transaction. The amount may be the amount due, and the currency may include real currency such as U.S. dollars and euros, as well as virtual currency such as reward points. The amount 1014 of the transaction may also be prominently displayed on the user interface. The user may select the select funds tab 1016 to select one or more forms of payment 1017, which may include various credit, debit, gift, bonus, and/or prepaid cards. The user may also have the option to pay in whole or in part with reward points. For example, a graphical indicator 1018 on the user interface represents the number of points available, and a graphical indicator 1019 represents the equivalent 1020 of the number of points to be used to the amount due 234.56 and the number of points in the selected currency (e.g., USD).

In one implementation, a user may combine funds from multiple sources to pay for a transaction. The amount 1015 displayed on the user interface may provide the amount in the total funds covered up to now by the selected form of payment (e.g., Discover card and reward points). The user may select another form of payment or adjust the amount debited from one or more forms of payment until the amount 1015 matches the amount due 1014. Payment authorization may begin once the user finalizes the amount to be debited (debit) from one or more forms of payment.

In one implementation, the user may select secure authorization for the transaction by selecting the disguise button 1022 to effectively hide or hide some (e.g., preconfigured) or all of the identification information so that when the user selects the payment button 1021, the transaction authorization is conducted in a secure and anonymous manner. In another implementation, the user may select a payment button 1021, which may use standard authorization techniques for transaction processing. In yet another implementation, when the user selects the social button 1023, a message regarding the transaction may be sent to one or more social networks (set up by the user) that may post or announce the purchase transaction on a social forum, such as a wall post or tweet. In one implementation, the user may select the social payment processing option 1023. Indicator 1024 may represent an ongoing authorization and sending of social sharing data.

In another implementation, the restricted payment mode 1025 may be activated for certain purchase activities, such as prescription (description) purchases. The schema may be activated in accordance with rules defined by an issuer, an insurer, a merchant, a payment processor, and/or other entities to facilitate the processing of specialized goods and services. In this mode, the user may scroll down a list 1026 of forms of payment under the funds tab to select a specialized account (such as the Flexible Spending Account (FSA) 1027 and/or the health savings account (HAS), etc.) and the amount to be debited to the selected account. In one implementation, this limited payment mode 1925 processing may disable social sharing of purchase information.

In one implementation, the wallet mobile application facilitates the import of funds through an import funds user interface 1028. For example, a user who is out of business may obtain the out of business welfare fund 1029 through a wallet mobile application. In one implementation, the funding entity may also be configured with rules for using the funds represented by the process indicator message 1030. The wallet may read and apply the previous rules and may deny any purchases with unemployed funds that fail to meet the criteria set by the rules. Example criteria may include, for example, a Merchant Category Code (MCC), a time of the transaction, a location of the transaction, etc. As an example, a transaction with a grocery merchant having MCC5411 may be approved, while a transaction with a bar merchant having MCC5813 may be denied.

Referring to fig. 10B, in one embodiment, the wallet mobile application facilitates dynamic payment optimization based on factors such as user location, preferences, and monetary value preferences. For example, when the user is in the united states, the country indicator 1031 may display the national flag of the united states and may set the currency 1010 to U.S. dollars. In another implementation, the wallet mobile application may automatically reorder the order in which the forms 1035 of payments are listed to reflect the popularity and acceptability of the various forms of payments. In one implementation, the arrangement may reflect the user's preferences that are not changed by the wallet mobile application.

Similarly, when a german user operates a wallet in germany, the mobile wallet application user interface may be dynamically updated to reflect the country 1032 and currency 1034 of the operation. In another implementation, the wallet application may reorder the order in which the different payment forms 1036 are listed based on their acceptance in that country. Of course, the user may change the order of these forms of payment to suit his or her own preferences.

Referring to fig. 10C, in one embodiment, a payee tab 1037 in the wallet mobile application user interface may facilitate user selection of one or more payees receiving funds selected in the funds tab. In one implementation, the user interface can represent a list 1038 of all payees with whom the user has previously transacted or is available for transaction. The user may then select one or more payees. Payee 1038 may include a larger merchant such as amazon.com inc. and an individual such as janep.doe. Near each payee name, a list of accepted payment modes for the payee may be displayed. In one implementation, the user may select a payee Jane p.doe1039 for receiving the payment. When selected, the user interface may display additional identifying information related to the payee.

Referring to fig. 10D, in one embodiment, a mode tab 1040 may facilitate selection of a payment mode accepted by the payee. Multiple payment modes are available for selection. Example modes include bluetooth 1041, wireless 1042, capture movement by user obtained QR code 1043, secure chip 1044, TWITTER1045, Near Field Communication (NFC) 1046, cellular 1047, capture movement by user provided QR code 1048, USB1049, and FACEBOOK1050, among others. In one implementation, the user can only select the payment mode accepted by the payee. Other unacceptable payment modes may be disabled.

Referring to FIG. 10E, in one embodiment, providing a tab 1051 may provide a real-time offer related to items in the user's shopping cart for user selection. The user may select one or more offers from the list of available offers 1052 for redemption. In one implementation, some offers may be merged while others are not. When a user selects an offer that cannot be merged with another offer, the unselected offer may be disabled. In another implementation, the offer recommended by the recommendation engine of the wallet application may be identified by an indicator such as the indicator shown in 1053. In another implementation, the user may read the details of the offer by expanding the offer line denoted 1054 in the user interface.

Referring to fig. 10F, in one embodiment, a social tab 1055 may facilitate integration of a wallet application with a social channel 1056. In one implementation, a user may select one or more social channels 1056 and register 1058 with the wallet application to the selected social channel by providing the wallet application with a social channel username and password 1057. The user may then use the social button 1059 to send or receive money through the integrated social channel. In another implementation, a user may send social sharing data, such as purchasing information or links, through an integrated social channel. In another embodiment, the user-provided registration credentials may allow the PPT to participate in an interception (interception) resolution.

Figure 11 represents a user interface diagram illustrating example features of a virtual wallet application in a history mode in some embodiments of PPT. In one embodiment, the user may select the history mode 1110 to view a history of previous purchases and perform various actions on these previous purchases. For example, the user may enter merchant identification information such as a name, product, MCC, etc. in search bar 1111. In another implementation, the user may use a voice activated search feature by clicking on the microphone icon 1114. The wallet application may query a storage area of the mobile device or elsewhere (e.g., one or more databases and/or tables remote from the mobile device) for transactions matching the search keywords. The user interface may then display the results of the query, such as transaction 1115. The user interface may also identify the date 1112 of the transaction, the merchant and item 1113 associated with the transaction, the barcode of the receipt confirming the transaction was made, the amount of the transaction, and any other relevant information.

In one implementation, a user may select a transaction, such as transaction 1115, to view details of the transaction. For example, the user may view details of the items associated with the transaction and the amount 1116 of each item. In another implementation, the user may select display option 1117 to see actions 1118 the user may take with respect to the transaction or the item in the transaction. For example, the user may add a photo (e.g., a picture of the user and the iPad purchased by the user) to the transaction. In another implementation, if a user previously shared a purchase through 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 through a social channel may still share photos through his or her selected social channel(s) directly from the historical pattern of the wallet application. In another implementation, the user may add the transaction to a group such as corporate expenses, family expenses, travel expenses, or other categories established by the user. Such groupings can facilitate the annual final resolution of expenses, the submission of reports of working expenses, the submission of personal expenses, Value Added Tax (VAT) refunds, and the like. In yet another implementation, a user may purchase one or more items purchased in a transaction. The user may then perform the transaction without going to the merchant catalog or site to find the item. In another implementation, the user may also transport one or more items in the (cart) transaction with the shopping cart for later purchase.

In another embodiment, the historical pattern may facilitate obtaining and displaying ratings (rating) 1119 for items in the transaction. The source of the rating may be the user, friends of the user (e.g., from social channels, contacts, etc.), comments aggregated from the network, and so forth. The user interface in some implementations may also allow a user to post messages to other users of a social channel (e.g., TWITTER or FACEBOOK). For example, display area 1120 represents a FACEBOOK message exchange between two users. In one implementation, users may share links through the message 1121. Selecting such a message with an embedded product link may allow the user to view a description of the product and/or purchase the product directly from a historical pattern.

In one embodiment, the historical pattern may also contain tools for deriving receipts. Export receipt pop-up window 1122 may provide a number of options for exporting receipts for transactions in the history. For example, the user may use one or more of options 1125, including save (to local mobile storage, to a server, to a cloud account, etc.), print to printer, fax, email, etc. The user may utilize his or her address book 1123 to look up an email or fax number for export. The user may also specify a format option 1124 for exporting receipts. Example format options may include, but are not limited to, text files (. doc,. txt,. rtf,. iif, etc.), spreadsheets (. csv,. xls, etc.), image files (. jpg,. GIFf,. png, etc.), portable document formats (. pdf), postscript (. ps), and the like. The user may then click or tap export button 1127 to initiate an export receipt.

Figures 12A-E represent user interface diagrams illustrating example features of a virtual wallet application in a capture mode in some embodiments of a PPT. Referring to FIG. 12A, in one embodiment, a user may select a capture mode 2110 to access their capture features. The capture mode may process any machine-readable representation of the data. Examples of such data may include linear and 2D barcodes such as UPC codes and QR codes. These codes may be found on receipts, product packaging, and the like. The capture mode may also process and manipulate pictures of receipts, products, offers, credit cards or other payment devices, and the like. An example user interface in capture mode is shown in FIG. 12A. The user may use his or her mobile phone to take a picture of the QR code 1215 and/or barcode 1214. In one implementation, bar 1213 and capture block 1215 may assist the user in capturing code as appropriate. For example, as shown, capture block 1215 does not capture all of code 1216. Thus, the code captured in this view may not be resolvable because the information in the code may not be complete. This is indicated by the message on bar 1213 indicating that the capture mode is still looking for the code. When code 1216 is fully framed by Capture Block 1215, the bar message may be updated to, for example, "discovery Capture". In one implementation, when a code is found, a user may initiate a code capture using a mobile device camera. In another implementation, the capture mode may automatically capture code using a mobile device camera.

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

As shown, the user may type in a search term (e.g., a bill) in search bar 2121. The user may then identify in tab 1222 a receipt 1225 that the user wishes to reassign. Alternatively, the user may directly capture a picture of the barcode on the receipt, and the capture mode may use information from the barcode to generate and display the receipt 1223. The user may now reassign 1225. In some implementations, the user may also propose an objection 1224 to the transaction or archive a receipt 1226.

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

Referring to FIG. 12C, in one embodiment, the capture mode may facilitate payment by 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 been completed. The QR code may be displayed on a merchant POS terminal, website, or web application and may 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 may decode the information in the QR code and may use the decoded information to generate a receipt 1232. Once the QR code is identified, the navigation bar 1231 may indicate that the payment code is identified. The user may now have the option to add to the shopping cart 1233, pay 1234 with a default payment account, or pay 1235 with a wallet.

In one implementation, the user may decide to utilize default payment 1234. The wallet application may then use the user's default payment method, in this example, a wallet, to complete the purchase transaction. Upon completion of the transaction, evidence of receipt for purchase may be automatically generated. The user interface may also be updated to provide other options for processing the completed transaction. Example options include social 1237 for sharing purchase information with others, reassignment 1238 discussed with respect to FIG. 12B, and archive 1239 for storing receipts.

Referring to FIG. 12D, in one embodiment, the capture mode may also facilitate providing recognition, application, and storage for future use. For example, in one implementation, a user may capture a provided code 1241 (e.g., a barcode, a QR code, etc.). The wallet application may then generate the offer text 1242 from the information encoded in the offer code. The user may perform a number of actions on the provided code. For example, the user uses find button 1243 to find all merchants that accept the provided code, nearby merchants that accept the provided code, products from merchants that match the provided code, and so forth. The user can also provide a code to the item application currently in the shopping cart using the add to shopping cart button 1244. In addition, the user can also save the offer for future use by selecting a save button 1245.

In one implementation, after applying the offer or coupon 1246, the user may have the option to use the find to find a qualified merchant and/or product, the user may use 1248 to go to a wallet, and the user may also save the offer or coupon 1246 for later use.

Referring to fig. 12E, in one embodiment, the capture mode may also provide functionality for adding a source of funds to the wallet application. In one implementation, payment cards such as credit cards, debit cards, prepaid cards, smart cards, and other payment accounts may have an associated code such as a barcode or QR code. Such codes may have encoded therein payment card information including, but not limited to, name, address, payment card type, payment card account details, balance, spending limit, reward balance, etc. In one implementation, the code may be found on the surface of a physical payment card. In another implementation, the code may be obtained by accessing an associated online account or another secure location. In yet another implementation, the code may be printed on a letter (letter) accompanying the payment card. In one implementation, a user may capture a picture of the code. The wallet application may recognize the payment 1251 and may display text information 1252 encoded in the payment card. The user may then select the verify button 1253 to perform verification of the information 1252. In one implementation, the verification may include contacting the issuer of the payment to confirm the decoded information 1252 and any other related information. In one implementation, the user can add a payment card to the wallet by selecting the "add wallet" button 1254. The instruction to add a payment card to the wallet may cause the payment card to appear as one of the payment forms under the funds tab 1016 discussed in fig. 10A. The user may also cancel importing the payment card as a funding source by selecting a cancel button 1255. When a payment card has been added to the wallet, the user interface may be updated to indicate that the import is complete via notification display 1256. The user may then access the wallet 1257 to begin using the added payment card as a funding source.

Figure 13 represents a user interface diagram illustrating example features of a virtual wallet application in a provisioning mode in some embodiments of a PPT. In some implementations, the PPT may allow a user to search for offers for products and/or services from within the virtual wallet mobile application. For example, a user may type text into a graphical user interface ("GUI") element 1311, or issue a voice command by activating the GUI element 1312 and speaking the command to the device. In some implementations, the PPT may be provided based on a user's previous behavior, demographics, current location, current shopping cart selection or purchase items, and so forth. For example, if a user is at a physical store or an online shopping website and leaves a (virtual) store, a merchant associated with the store may wish to provide sweet-head (sweet-head) transactions to attract consumers back to the (virtual) store. The merchant may provide such offers 1313. For example, the offer may offer a discount and may include an expiration time. In some implementations, other users may provide gifts (e.g., 1314) to the user, which the user may redeem. In some implementations, the offer portion may include a warning (e.g., 1315) to pay unpaid funds to other users. In some implementations, the offer portion may include an alert (e.g., 1316) from other users requesting receipt of funds. For example, such features may identify funds that may be received from other applications (e.g., mail, calendar, tasks, notes, reminders, alerts, etc.) or manually entered into the virtual wallet application by the user. In some implementations, the offer portion can provide offers from participating merchants in the PPT, e.g., 1317-1319, 1320. Sometimes these offers can be assembled (assembled) using a merger of participating merchants, e.g., 1317. In some implementations, the PPT itself may provide a user from within the virtual wallet application depending on the user utilizing a particular form of payment, e.g., 1320.

Figures 14A-B represent user interface diagrams illustrating example features of a virtual wallet application in secure and privacy modes in some embodiments of a PPT. Referring to fig. 14A, in some implementations, a user may be able to view and/or modify a user profile and/or settings of the user by activating a user interface element. For example, the user may be able to view/modify a user name (e.g., 1411 a-b), an account number (e.g., 1412 a-b), a user security access code (e.g., 1413-b), a user PIN (e.g., 1414-b), a user address (e.g., 1415-b), a social security number associated with the user (e.g., 1416-b), a current device GPS location (e.g., 1417-b), a user account of a merchant with whom the user is currently in their store (e.g., 1418-b), a reward account of the user (e.g., 1419-b), and so forth. In some implementations, the user may be able to select which data fields and their associated values should be communicated to facilitate the purchase transaction, thereby providing enhanced data security for the user. For example, in the example diagram in fig. 14A, the user has selected name 1411a, account number 1412a, security code 1413a, merchant account ID1418a, and rewards account ID1419a as the domains to be sent as part of the notification to process the purchase transaction. In some implementations, the user can switch the domain and/or data value sent as part of the notification to process the purchase transaction. In some implementations, the application may provide multiple screens of data fields and/or stored associated values for user selection as part of the purchase order transfer. In some implementations, the application may provide the user's GPS location to the PPT. Based on the user's GPS location, the PPT may determine the user's environment (e.g., whether the user is in a store, a doctor's office, a hospital, a postal service, etc.). Based on the circumstances, the user application may present the user with the appropriate fields from which the user may select the fields and/or field values sent as part of the purchase order transmission.

For example, the user may travel to a doctor's office and wish to pay a copay medical fee for the doctor's appointment. In addition to basic transaction information such as account number and name, the application may provide the user with the ability to select to transfer medical records, health information that may be provided to medical providers, insurance companies, and transaction processors to coordinate payments between the parties. In some implementations, records may be sent and encrypted in a data format that conforms to the health insurance circulation and accountability act (HIPAA), and only recipients authorized to view these records may have the appropriate decryption keys to decrypt and view non-disclosed user information.

Referring to fig. 14B, in some implementations, an application executing on a user's device may provide a "VerifyChat" feature for fraud prevention. For example, the PPT may detect unusual and/or suspicious transactions. The PPT may utilize the VerifyChat feature to communicate with the user and verify the authenticity of the originator of the purchase transaction. In various implementations, the PPT may send an email message, a text (SMS) message, a text,Message, Twitter^TMTweets, text chats, voice chats, video chats (e.g., Apple FaceTime), etc. to communicate with the user. For example, the PPT may initiate a video challenge for the user, e.g., 1421. For example, a user may need to present himself/herself through video chat, e.g., 1422. In some implementations, a customer service representative, such as agent 1424, may manually determine the authenticity of the user using the user's video. In some implementations, the PPT may utilize facial, biometric, and/or similar recognition (e.g., using pattern classification techniques) to determine the identity of the user. In some implementations, the application may provide a reference marker (e.g., crosshair, target box, etc.), such as 1423, so that the user may conduct a video to facilitate automatic identification of the user's PPT. In some implementations, the userThe transaction may not be initiated, e.g., the transaction is fraudulent. In these implementations, the user may cancel the challenge. The PPT may then cancel the transaction and/or initiate a fraud investigation process on behalf of the user.

In some implementations, the PPT may utilize a text challenge process to verify the authenticity of the user, e.g., 1425. For example, PPT may be sent via text chat, SMS message, email, SMS, or the like,Message, Twitter^TMTweets, etc. communicate with the user. The PPT may present challenge questions to the user, e.g., 1426. The application may provide a user input interface element (e.g., virtual keyboard 1428) to answer the challenge question posed by the PPT. In some implementations, the challenge question may be automatically randomly selected by the PPT; in some implementations, the customer service representative may manually communicate with the user. In some implementations, the user may not initiate the transaction, e.g., the transaction is fraudulent. In these implementations, the user may cancel the text challenge. The PPT may then cancel the transaction and/or initiate a fraud investigation on behalf of the user.

PPT controller

Figure 15 shows a block diagram of an inventive aspect of a PPT controller 1501. In this embodiment, PPT controller 1501 may be used to facilitate interaction with a computer through various techniques and/or other related data collection, processing, storage, searching, serving, identification, indication, generation, matching, and/or the like.

In general, a user, who may be a person and/or other system, may engage an information technology system (e.g., a computer) to facilitate information processing. And the computer uses the processor to process the information; such a processor 1503 may be referred to as a Central Processing Unit (CPU). One form of processor is known as a microprocessor. The CPU uses the communication circuit to enable various actions by binary encoding signals used as instructions. These instructions may be operational and/or data instructions that contain and/or reference other instructions and data in various processor-accessible and operable areas of the memory 1529 (e.g., registers, cache memory, random access memory, etc.). Such communication instructions may be stored and/or transmitted as program and data components in batches (e.g., multiple batches of instructions) to facilitate the desired action. These stored instruction codes, e.g., programs, may interface with the CPU circuit components and other motherboard and/or system components to perform desired actions. One type of program is a computer operating system, which is executable by a CPU on a computer; the operating system enables and facilitates user access to and operation of computer information technology and resources. These resources that may be used in information technology systems include: input and output mechanisms that allow data to be transferred to and from the computer; a memory capable of storing data; and a processor that can process the information. These information technology systems can be used to collect data for later retrieval, analysis, and manipulation, and these actions can be facilitated by a database program. These information technology systems provide interfaces that allow users to access and operate various system components.

In one embodiment, PPT controller 1501 may be in communication with entities such as, but not limited to, one or more user input devices 1511, peripheral devices 1512, optional cryptographic processor device 1528, and/or communication network 1513. For example, PPT controller 1501 may be connected to and/or communicate with a user operating a client device, including but not limited to a personal computer, a server, and/or various mobile devices, including but not limited to a cellular telephone, a smart phone (e.g.,android OS-based phones, etc.), tablet computers (e.g., Apple iPad)^TM、HP Slate^TM、Motorola Xoom^TMEtc.), eBook reader (e.g., Amazon Kindle^TMBrook, Barnes and Noble^TMedreader, etc.), laptop, notebook, netbook, and/or game console (e.g., XBOX player)^TM、DS、SonyPortable, etc.) and/or a Portable scanner, etc.

It is generally recognized that a network includes the interconnection and interaction of clients, servers, and intermediate nodes in a graphical layout. It should be noted that the term "server" as used in this application generally refers to a computer, other device, program, or combination thereof that processes and responds to requests of remote users across a communication network. The server serves the requested "client" with the information. The term "client" as used herein generally refers to a computer, program, other device, user, and/or combination thereof that is capable of processing and making requests across a communication network and obtaining and processing any responses from a server. Computers, other devices, programs, or combinations thereof that facilitate, process, and/or direct the passage of information from a source user to a destination user are generally referred to as "nodes". Networks are generally considered to be advantageous for transferring information from a source to a destination. Nodes that have the task of facilitating the forwarding of information from a source to a destination are generally referred to as "routers". There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), wireless networks (WLANs), and so forth. For example, the Internet is generally accepted as an interconnection of networks, whereby remote clients and servers can access and interact with each other.

The PPT controller 1501 may be based on a computer system that may include, but is not limited to, components such as a computer systemization 1502 coupled to a computer 1529.

Computerisation

The computer systemization 1502 may include a clock 1530, a central processing unit ("CPU" and/or "processor" (unless noted to the contrary, these terms are used interchangeably throughout this disclosure)), 1503, memory 1529 (e.g., Read Only Memory (ROM) 1506, Random Access Memory (RAM) 1505, etc.), and/or an interface bus 1507, which are often, although not necessarily, interconnected and/or in communication via a system bus 1504 on one or more (mother) boards 1502 having conductive and/or otherwise transmitting circuit paths by which instructions (e.g., binary encoded signals) may travel to effect communications, actions, storage, and so forth. Optionally, computer systemization may be connected to an internal power supply 1586; for example, optionally, the power source may be internal. Optionally, an encryption processor 1526 and/or a transceiver (e.g., IC) 1574 may be connected to the system bus. In another embodiment, the crypto processor and/or transceiver may be connected as an internal and/or external peripheral 1512 through an interface bus I/O. The transceiver, in turn, may be connected to an antenna 1575, thereby enabling wireless transmission and reception of various communication and/or sensor protocols; for example, the antenna may be connected to a Texas Instruments WiLink WL1283 transceiver chip (e.g., providing 802.11n, Bluetooth3.0, FM, Global Positioning System (GPS) (thereby allowing the PPT controller to determine its location)), a Broadcom BCM4329FKUBG transceiver chip (e.g., providing 802.11n, Bluetooth2.1+ EDR, FM, etc.), a Broadcom BCM4750IUB8 receiver chip (e.g., GPS), and/or an Infinetechnology X-Gold618 PMB9800 (e.g., providing 2G/3G HSDPA/HSA communications), among others. The system clock typically has a crystal oscillator and generates the fundamental signals through the circuit paths of the computer systemization. The clock is typically coupled to the system bus and various clock multiplexers which increase or decrease the fundamental operating frequency of other components interconnected in the computer systemization. The clocks and various components in the computer systemization drive signals embodying information throughout the system. Such transmission and reception of instructions embodying information in a computer system is generally referred to as communication. These communication instructions may also be transmitted, received, and result in return and/or reply communications arriving beyond the immediate computer system: communication networks, input devices, other computer systemization and/or peripheral devices, and the like. It should be appreciated that in alternative embodiments, any of the above components may be directly connected to each other, to the CPU, and/or, as illustrated by the various computer systems, organized in a number of variations.

The CPU includes at least one high speed data processor sufficient to execute program components for performing user and/or system generated requests. The processor itself often incorporates various special purpose processing units, such as, but not limited to: an integrated system (bus) controller, a memory management control unit, a floating point unit, and even special purpose processing sub-units, such as a graphics processing unit and/or a digital signal processing unit. Additionally, the processor may contain internal fast-access addressable memory, and be able to map and address memory 1529 beyond the processor itself; internal memory may include, but is not limited to, fast registers, various levels of cache memory (e.g., levels 1, 2, 3, etc.), RAM, and the like. The processor may access the memory by using a memory address space that is accessible by instruction addresses, which the processor may indicate and decode, allowing it to access circuit paths leading to a particular memory address space having memory states. The CPU may be a microprocessor, such as: athlon, Duron and/or Operon of AMD; applications, embedded and secure processors of the ARM; dragonball and PowerPC from IBM and/or Motorola; cell processors by IBM and Sony; celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale from Intel; and/or the like. The CPU interacts with the memory through instructions passing through conductive and/or transmission conduits (e.g., (printed) electronic and/or optical circuits) to execute stored instructions (i.e., program code) according to conventional data processing techniques. Such commands facilitate communication within the PPT controller and beyond the various interfaces. Distributed processors (e.g., DistributedPPT), central processing machines, multi-core, parallel, and/or supercomputer architectures can similarly be used provided that the processing requirements indicate higher speed and/or greater capacity. Alternatively, if the deployment requirements indicate greater portability, a smaller Personal Digital Assistant (PDA) may be used.

Depending on the particular implementation, the features of the PPT may be implemented by implementing microcontrollers such as CAST's R8051XC2 microcontroller and/or Intel's MCS51 (i.e., 8051 microcontroller). Also, to implement certain features of the PPT, some feature implementations may rely on embedded components, such as application specific integrated circuits ("ASICs"), digital signal processing ("DSPs"), field programmable gate arrays ("FPGAs"), and/or similar embedding technologies. For example, any of the PPT component sets (distributed or otherwise) and/or features may be implemented by a microprocessor and/or by embedded components, e.g., by ASICs, co-processors, DSPs, and/or FPGAs, etc. Alternatively, some implementations of the PPT may be implemented by embedded components configured and used to implement various features or signal processing.

Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of hardware/software solutions. For example, the PPT features discussed herein may be implemented by implementing FPGAs, which are semiconductor devices containing programmable logic components called "logic blocks" and programmable interconnects such as the Virtex family of high performance FPGAs and/or the low cost Spartan family manufactured by Xilinx. The logic blocks and interconnects may be programmed by a customer or designer after the FPGA is manufactured to implement any of the PPT features. The hierarchy of programmable interconnects allows for interconnections to be made as required by the PPT system designer/administrator, somewhat analogous to a single chip programmable analog board. The logic blocks of the FPGA may be programmed to perform operations such as AND XOR basic logic gates or more complex combinational operators such as decoders or simple mathematical operations. In most FPGAs, the logic block also contains memory elements that can be more complete blocks of circuit flip-flops or memories. In some cases, PPTs may be developed on regular PPTs and then migrated into a fixed version more similar to an ASIC implementation. As an alternative to, or in addition to, an FPGA, an alternative or coordinated implementation may migrate PPT controller features to the final ASIC. Depending on the implementation, all of the above-described embedded components and microprocessors may be considered "CPUs" and/or "processors" for PPTs.

Power supply

The power supply 1586 may be of any standard form for supplying power to small electronic circuit board devices, such as the following power units: alkali, lithium hydride, lithium ion, lithium polymer, nickel cadmium, and/or solar cells, and the like. Other types of AC or DC power sources may also be used. In the case of a solar cell, in one embodiment, the housing provides an aperture through which the solar cell can capture photon energy. A power unit 1586 is connected to at least one of the interconnected back-end assemblies of the PPT, thereby providing current to all back-end assemblies. In one example, a power supply 1586 is coupled to the system bus component 1504. In an alternative embodiment, the external power source 1586 is provided through a connection across the I/O1508 interface. For example, USB and/or IEEE1394 connections carry data and power across the connection and are therefore suitable power sources.

Interface adapter

The interface bus 1507 may receive, connect to, and/or communicate with, a number of interface adapters, which may conventionally, but not necessarily, take the form of adapter cards, such as, but not limited to, input/output interfaces (I/O) 1508, storage interfaces 1509, and/or network interfaces 1510, among others. Optionally, a crypto processor interface 1527 may be similarly connected with the interface bus. The interface bus enables the interface adapters to communicate with each other and with other components of the computer system. The interface adapter is adapted to a compatible interface bus. Interface adapters are conventionally connected to the interface bus through a socket arrangement. Conventional slot architectures may be used such as, but not limited to, Accelerated Graphics Port (AGP), card line, (extended) industry Standard architecture ((E) ISA), Micro Channel Architecture (MCA), NuBus, peripheral component interconnect (extended) (PCI (X)), PCI Express, and/or Personal Computer Memory Card International Association (PCMCIA), among others.

The storage interface 1509 may accept, connect to, and/or communicate with a number of storage devices, such as, but not limited to, storage device 1514 and/or removable disk devices. The storage Interface may use a connection protocol such as, but not limited to, (Ultra) (Serial) advanced technology Attachment (Packet Interface) ((Ultra) (Serial) ATA (PI), (Enhanced) Integrated Drive Electronics ((E) IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fibre channel, Small Computer System Interface (SCSI), and/or Universal Serial Bus (USB), etc.

The network interface 1510 may accept, connect to, and/or communicate with a communication network 1513. Through communications network 1513, the PPT controller is accessible by user 1533a through remote client 1533b (e.g., a computer having a web browser). The network interface may use a connection protocol such as, but not limited to, direct connection, Ethernet (thick, thin, twisted pair 10/100/1000Base T, etc.), token ring, and/or wireless connection such as IEEE802.11 a-x. Should processing requirements dictate higher speeds and/or larger capacities, a Distributed network controller (e.g., Distributed PPT) architecture may similarly be used to centralize, load balance, and/or otherwise increase the communication bandwidth required by the PPT controller. The communication network may be any one and/or combination of the following: a direct interconnect, the internet, a Local Area Network (LAN), a Metropolitan Area Network (MAN), an operational task (OMNI) as a node on the internet, a secure customer connection, a wide area network (WN), and/or a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), and/or I-mode, etc.), and the like. A network interface may be considered a specialized form of input-output interface. Also, multiple network interfaces 1510 may be used to interface with various communication network types 1513. For example, multiple network interfaces may be used to allow communication over broadcast, multicast, and/or unicast networks.

Input/output interface (I/O) 1508 may accept, connect to, and/or communicate with user input device 1511, peripheral device 1512, and/or cryptographic processor device 1528, among others. I/O may use a connection protocol such as, but not limited to: audio: analog, digital, monaural, RCA, and/or stereo, etc.; data: apple Desktop Bus (ADB), IEEE1394a-b, serial, Universal Serial Bus (USB); infrared; a joystick; a keyboard; midi; optics; PC AT; PS/2; paralleling; radio, video interface: apple Desktop Connector (ADC), BNC, coaxial, component, composite, Digital Video Interface (DVI), High Definition Multimedia Interface (HDMI), RCA, RF antenna, S-Video, and/or VGA, etc.; a wireless transceiver; 802.11 a/b/g/n/x; bluetooth; cellular (e.g., Code Division Multiple Access (CDMA), high speed packet access (HSPA (+), High Speed Downlink Packet Access (HSDPA), global system for mobile communications (GSM), Long Term Evolution (LTE), WiMax, etc.), and so forth. A typical output device may include a video display that generally includes a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor having an interface (e.g., DVI circuitry and cabling) that receives signals from the video interface. The video interface composites information generated by the computer systematized and generates a video signal based on the composite information in the video memory frame. Another output device is a television set that receives signals from a video interface. Generally, the video interface provides the composite video information through a video connection interface that receives the video display interface (e.g., an RCA composite video connector that receives an RCA composite video cable; a DVI connector that receives a DVI display cable, etc.).

User input device 1511 is often a type of peripheral device 1512 (see below), and may include: a card reader, a hardware lock, a fingerprint reader, a glove, a graphics tablet, a joystick, a keyboard, a microphone, a mouse, a remote control, a retinal reader, a touch screen (e.g., capacitance, resistance, etc.), a trackball, a track pad, a sensor (e.g., accelerometer, ambient light, GPS, gyroscope, proximity, etc.), and/or a stylus, etc.

Peripheral devices 1512 may be connected to and/or communicate with I/O and/or other facilities such as network interfaces, storage interfaces, and/or directly with an interface bus, system bus, CPU, etc. The peripheral devices may be external to, internal to, or a part of the PPT controller. The peripheral device may include: an antenna, an audio device (e.g., line-in, line-out, microphone input, speaker, etc.), a camera (e.g., still, video, webcam, etc.), a hardware lock (e.g., for copy protection, secure transactions with digital signatures, etc.), an external processor (for greater capabilities, e.g., encryption device 1528), a force feedback device (e.g., a vibration motor), a network interface, a printer, a scanner, a storage device, a transceiver (e.g., cellular, GPS, etc.), a video device (e.g., goggles, a monitor, etc.), a video source and/or a mask, etc. Peripheral devices often contain multiple types of input devices (cameras).

It should be noted that while user input devices and peripheral devices may be used, the PPT controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access may be provided over a network interface connection.

Cryptographic units such as, but not limited to, microcontrollers, processors 1526, interfaces 1527, and/or devices 1528 may be fixed and/or in communication with the PPT controller. An MC68HC16 microcontroller manufactured by Motorola inc. The MC68HC16 microcontroller utilizes a 16-bit multiply and accumulate instruction in a 16MHz configuration and requires less than 1 second to perform 512-bit RSA private key operations. The encryption unit supports authorization of communications from the interaction agent and allows anonymous transactions. The encryption unit may also be configured as part of the CPU. Comparable microcontrollers and/or processors may also be used. Other commercially available specialized encryption processors include: broadcom's CryptoNetX and other security processors; nShield from nCipher, Luna PCI (e.g., 7100) series from SafeNet; 40MHz Roadrunner184 from Semaphore Communications; cryptographic accumulators from Sun (e.g., accumulator 6000PCIeBoard, accumulator 500 Daughtercard); a 500+ MB/s line of Via NanoProcessors (e.g., L2100, L2200, U2400) capable of executing encrypted instructions; 33MHz6868 for VLSI Technology; and so on.

Memory device

Generally, any mechanism and/or embodiment that allows a processor to affect the storage and/or retrieval of information is considered memory 1529. However, memory is an interchangeable technology and resource, and thus, any number of memory embodiments may be used in place of one another. It is to be appreciated that the PPT controller and/or computer systemization can employ various forms of memory 1529. For example, computer systemization may be configured wherein the actions of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage device are provided by a punched-paper tape or punched-paper card mechanism; however, such an embodiment would result in very slow motion. In a typical configuration, memory 1529 will include ROM1506, RAM1505, and storage device 1514. The storage device 1514 may be any conventional computer system storage. The storage device may include: a drum; (fixed and/or removable) disk drives; magnetic light driving; optical drives (i.e., Blueray, CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HDDVD R/RW, and the like); an array of devices (e.g., Redundant Array of Independent Disks (RAID)), solid-state memory devices (USB memory, solid-state drive (SSD), etc.); other processor-readable storage media and/or the like. Thus, computer systematization generally requires and utilizes memory.

Component collections

Memory 1529 may contain a collection of programs and/or database components and/or data such as, but not limited to: an operating system component 1515 (operating system), an information server component 1516 (information server), a user interface component 1517 (user interface), a web browser component 1518 (web browser), a database 1519, a mail server component 1521, a mail client component 1522, an encryption server component 1520 (encryption server), and/or a PPT component 1535, etc. (i.e., collectively referred to as a set of components). These components may be stored and accessed from a memory device and/or from a memory device accessible through an interface bus. While non-conventional program components, such as those in the component collection, are typically stored in the local storage device 1514, they may also be loaded into and/or stored in memory, such as a peripheral device, RAM, a remote storage facility, etc., via a communications network, ROM, and/or various forms of memory.

Operating system

Operating system component 1515 is an executable program component that facilitates actions by the PPT controller. Generally, an operating system facilitates access to I/O, network interfaces, peripheral devices and/or storage devices, and the like. The operating system may be a highly fault tolerant, scalable security system such as: apple Macintosh OS X (Server); AT & T Plan 9; be OS; unixand Unix-type system distributions (such as UNIX for AT & T; Berkley Software Distribution (BSD) variants such as FreeBSD, NetBSD, and/or OpenBSD; Linux distributions such as Red Hat and/or Ubuntu, etc.); and/or the like. More limited and/or less secure operating systems may be used, such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Server) and/or Palm OS, among others. The operating system may communicate with other components in the set of components, including itself, and so forth. The operating system most often communicates with other program components and/or user interfaces and the like. For example, an operating system may contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable communication with communication networks, data, I/O, peripherals, program components, memory, and/or user input devices, among others. The operating system may provide communication protocols that allow the PPT controller to communicate with other entities via the communication network 1513. As a subcarrier transport mechanism for interaction, the PPT controller may use various communication protocols such as, but not limited to, multicast, TCP/IP, UDP, and/or unicast, among others.

Information server

The information server component 1516 is a stored program component executed by the CPU. The information server may be a conventional internet information server such as, but not limited to, Apache by Apache Software Foundation and/or Microsoft's internet information server, etc. The information Server may allow program components to be executed by facilities such as Active Server Page (ASP), Active X, (ANSI) (Objective-) C (+), C #, and/or NET, Common Gateway Interface (CGI) script, dynamic (D) HyperText markup language (HTML), FLASH, Java, JavaScript, reactive Extraction reporting language (PERL), Hypertext Pre-Processor (PHP), pipe, Python, Wireless Application Protocol (WAP), and/or WebObject. The information server may support a secure communication Protocol such as, but not limited to, FileTransfer Protocol (FTP); HyperText Transfer Protocol (HTTP); secure Hypertexttransfer Protocol (HTTPS); secure Socket Layer (SSL), signaling protocols (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force (IETF) SessionInitiation Protocol (SIP), SIP for instance, Open XLM based on HTTP Messaging and Presence extensions (SIMPLE), Open XLM based on HTTP location Messaging and Presence Protocol (XMPP) (i.e., Javiber or Open Mobile Alliance's (HTTP's) Messaging and location server), and the like, and provide web page information in the form of a request to a web server that handles the request to resolve information to a web page by manipulating the HTTP server and other web page information on the web server, and the web server receives the request via a DNS server, a request such as http 123.124.125.126/myinformation html may have the IP portion "123.124.125.126" of the request resolved by the DSN server to the information server at that IP address, which in turn further parses the http request of the "/myinformation. html" portion of the request and resolves it into a location in memory that contains the information "/myinformation. html". In addition, other information services coordination may be used across the various ports, such as FTP communication across port 21, and so on. The information server may communicate with other components in the collection of components and/or similar facilities, including itself. The information server most often communicates with the PPT database 1519, an operating system, other program components, a user interface, and/or a web browser, among others.

Access to PPT databases can be achieved through several database bridge mechanisms, such as by enumerating a scripting language (e.g., CGI), and by enumerating inter-application communication channels (e.g., CORBA, WebObjects, etc.). Any data requests that are browsed through the web are parsed by the bridge authority into the appropriate syntax required by the PPT. In one embodiment, the information server may provide a form of network accessible by a web browser. Items that make up a web-formed offer bar are marked as being typed into a particular bar and analyzed accordingly. The typed-in item then passes along with the column tags, which are used to instruct the parser to generate a query directed to the appropriate table and/or the appropriate column. In one embodiment, the parser may generate a query in standard SQL by launching a search string with an appropriate join/select command based on the tag text entry, where the resulting command is provided as a query to the PPT on the bridge mechanism. As query results are generated from the query, the results are passed over the bridge authority, and the new results web page may be analyzed for its formatting and generation by the bridge authority. This new result web page is then provided to the information server, which can serve it to the requesting web browser.

Also, an information server can contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

User interface

The computer interface is similar in some respects to the car operating interface. Vehicle operator interfaces such as steering wheels, shifters, and speedometers facilitate access to, operation of, and display of vehicle resources and conditions. Computer interaction interface elements such as check boxes, cursors, menus, brushes, and windows (collectively referred to generally as widgets) similarly facilitate access, capabilities, operation, and display of data and computer hardware and operating system resources and states. The operation interface is generally referred to as a user interface. Such as Aqua of the apple macintosh operating system, OS/2 of IBM, Windows2000/2003/3.1/95/98/CE/Millenium/NT/XP/Vista/7 of Microsoft (i.e., Aero), X-Windows of Unix (e.g., may contain additional Unix graphical Interface libraries and layers such as K Desktop Environment (KDE), mythTV, and GNU Network Object Model Environment (GNOME)), web Interface libraries (e.g., ActiveX, AJAX, (D) HTML, FLASH, Java, JavaScript, etc., Interface libraries such as, but not limited to, Dojo, jQuery (UI), MooTools, Prototype, script.

The user interface component 1517 is a stored program component executed by the CPU. The user interface may be a conventional graphical user interface executed by, by and/or on an operating system and/or operating environment such as those already discussed. The user interface may allow program components and/or system facilities to be displayed, executed, interacted with, manipulated, and/or operated with text and various graphical facilities. The user interface provides a facility by which a user can influence, interact with, and/or operate the computer system. The user interface may communicate with other components in the collection of components and/or similar facilities, including itself. The user interface most often communicates with an operating system and/or other program components and the like. The user interface may contain, communicate, generate, obtain, and/or provide program components, systems, user, and/or data communications, requests, and/or responses.

Web browser

The web browser component 1518 is a stored program component that is executed by the CPU. The web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. The secure web browsing may be provisioned with 128-bit (or more) encryption via HTTPS and/or SSL, etc. The web browser allows program components to be executed through facilities such as ActiveX, AJAX, (D) HTML, FLASH, Java, JavaScript, and/or web browser plug-in APIs (e.g., FireFox, Safari plug-in, and/or similar APIs). Web browsers and similar information access tools may be integrated into PDAs, cell phones, or other mobile devices. The web browser may communicate with other components in the collection of components and/or similar facilities, including itself. The web browser most often communicates with information servers, operating systems, and/or integrated program components (e.g., plug-ins), etc.; for example, it can contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, and/or responses. Also, instead of a web browser and an information server, a combined application may be developed to perform similar actions of both. The combined application may similarly affect obtaining and providing information from the PPT-enabled node to the user and/or user agent, etc. On systems using standard web browsers, the combined application may not be important.

Mail server

The mail server 1521 is a stored program component executed by the CPU 1503. The mail server may be a conventional internet mail server such as, but not limited to, sending mail and/or Microsoft Exchange, etc. The mail server may allow program components to be executed through facilities such as PPT, ActiveX, (ANSI) (Objective-) C (++), C #, and/or NET, CGI script, Java, JavaScript, PERL, PHP, pipe, Python, and/or WebObjects, etc. The mail server may support communication protocols such as, but not limited to, Internet Message Access Protocol (IMAP), signaling application programming interface (MAPI)/Microsoft Exchange, postal protocol (POP 3), and/or Simple Mail Transfer Protocol (SMTP), among others. The mail server may route, forward, and process mail messages that are sent, relayed, and/or otherwise traverse and/or reach the PPT.

Access to PPT mail may be achieved through several APIs provided by a single web server component and/or operating system.

Also, a mail server may contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, information, and/or responses.

Mail client

The mail client component 1522 is a stored program component that is executed by the CPU 1503. The Mail client may be a conventional Mail viewing application such as Apple Mail, Microsoft Enterprise, Microsoft Outlook Express, Mozilla, and/or Thunderbird, among others. The mail client may support several transport protocols such as IMAP, Microsoft Exchange, POP3, and/or SMTP, among others. The mail client may communicate with other components in the collection of components and/or similar facilities, including itself. Mail clients most often communicate with mail servers, operating systems, and/or other mail clients, etc.; for example, it can contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, information, and/or responses. Generally, mail clients provide facilities for composing and transmitting electronic mail messages.

Encryption server

The crypto server component 1520 is a stored program component that is executed by the CPU1503, crypto processor 1526, crypto processor interface 1527, and/or crypto processor device 1528, and the like. The encryption processor interface will allow encryption and/or decryption requests to be performed by the encryption component; however, as an alternative, the cryptographic component may run on a conventional CPU. The encryption component allows for encryption and/or decryption of the provided data. The encryption component allows symmetric and asymmetric (e.g., Pretty GoodProtection (PGP)) encryption and/or decryption. The encryption component can employ encryption techniques such as, but not limited to, digital certificates (e.g., x.509 authorization frameworks), digital signatures, double signatures, wrapping, encrypted access protection, and/or public key management, among others. The cryptographic component would facilitate a number of (encryption and/or decryption) security protocols such as, but not limited to, checksum, Data Encryption Standard (DES), elliptic curve Encryption (ECC), International Data Encryption Algorithm (IDEA), message number 5 (MD 5, which is a one-way hash operation), encryption, Rivest Cipher (RC 5), Rijndael, RSA (which is an internet encryption and authorization system using an algorithm developed by Ron Rivest, Adi Shamir, and leonard Adleman in 1977), Secure HashAlgorithm (SHA), Secure Sockets Layer (SSL), and/or Secure hypertext transfer protocol (HTTPS), among others. By using such an encryption security protocol, the PPT may encrypt all incoming and/or outgoing communications and may act as nodes within a Virtual Private Network (VPN) over a wider communication network. The encryption component facilitates processing of "secure authorization" to prohibit access to the resource via a secure protocol, wherein the encryption component enables authorized access to the secure resource. In addition, the encryption component may provide a unique identifier for the content, for example, hashed using MD5 to obtain a unique signature for the digital audio file. The cryptographic component may communicate with other components in the set of components and/or similar facilities, including itself. The cryptographic component supports a cryptographic scheme that allows secure transfer of information across a communication network to enable the PPT component to participate in secure transactions if desired. The cryptographic component facilitates secure access to resources on the PPT and facilitates access to secure resources on the remote system; that is, it may act as a client and/or server for secure resources. The encryption component most often communicates with an information server, operating system, and/or other program components, etc. The cryptographic components may contain, communicate, generate, obtain, and/or provide program components, systems, user, and/or data communications, requests, and/or responses.

PPT database

The PPT database component 1519 may be embodied in a database and its stored database. The database is a stored program component executed by the CPU; the stored program component part configures the CPU to process the stored data. The database may be a conventional, fault tolerant, relational, hierarchical secure database, such as Oracle or Sybase. A relational database is an extension of a flat file. The relational database contains a series of relational tables. The tables are interconnected by key columns. Using the key column allows tables to be assembled by indexing the key column; that is, the key column serves as a dimension pivot for combining information from various tables. Relationships generally identify the links maintained between tables by matching the primary keys. The primary key represents a column that uniquely identifies a row of a table in a relational database. More specifically, they uniquely identify rows of a table on the "one" side of a one-to-many relationship.

Alternatively, the PPT database may be implemented using various standard data structures such as arrays, hashes, (linked) lists, structures, structural text files (e.g., XML), and/or tables. Such data structures may be stored in memory and/or in (build) files. In another alternative, object-oriented databases such as Frontier, ObjectStore, Poet, and/or Zope, etc. may be used. An object database may contain several sets of objects combined and/or linked together by common attributes; they may be related to other sets of objects by some common attributes. Object-oriented databases perform similarly to relational databases, except that objects are not merely data, but may have other types of capabilities encapsulated within a given object. If the PPT database is implemented as a data structure, the use of PPT database 1519 may be integrated into another component, such as PPT component 1535. Also, a database may be implemented as a combination of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in myriad variations by standard data processing techniques. Multiple portions of data, such as tables, may be output and/or input and thereby dispersed and/or integrated.

In one embodiment, the database component 1519 contains several tables 1519 a-n. The user table 1519a may include information such as, but not limited to, user _ id, token _ id, ssn, dob, first _ name, last _ name, age, state, address _ first, address _ second, zip code, view _ list, contact-info, contact _ type, alt _ contact _ info, and/or alt _ contact _ type, etc. The user table may support and/or track multiple entity accounts on the PPT. The device table 1519b may include fields such as, but not limited to, device _ ID, device _ name, device _ IP, device _ GPS, device _ MAC, device _ service, device _ ECID, device _ UDID, device _ browse, device _ type, device _ model, device-version, device _ OS, device _ apps _ list, device _ security, and/or sink _ app _ instance _ flag. The application table 1519c may include columns such as, but not limited to, app _ ID, app _ name, app _ type, app _ dependencies, app _ access _ code, and/or user _ pin. The account table 1519d may contain columns 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, and/or linked _ calls _ list. The merchant table 1519e may contain columns such as, but not limited to, merchant _ id, merchant _ name, merchant _ address. Issuer table 1519f may include columns such as, but not limited to, issuerjd, issuerjname, issuerjaddress, ip _ address, mac _ address, auth _ key, port _ num, and/or security _ settings _ list. Acquirer table 1519g may include fields such as, but not limited to, account _ firstname, account _ lastname, account _ type, account _ num, account _ balance _ ist, billingaddress _ line1, billingaddress _ line2, billingzipcode, billingstatus, ripping _ preferences, rippingaddress _ line1, rippingaddress _ line2, ripping _ zip code, and/or ripping _ state, among others. The token table 1519h may include columns such as, but not limited to, token _ id, token _ phrase, token _ issue, token _ md5, token _ security, user _ id, password, token _ composition _ list, and account _ link. Shopping session table 1519i may contain fields such as, but not limited to, user _ ID, session _ ID, alerts _ URL, time, expiration _ layer, merchant _ ID, store _ ID, device _ type, device _ ID, device _ IP, device _ MAC, device _ browse, device _ service, device _ ECID, device _ model, device _ OS, sink _ app _ insert, total _ cost, cart _ ID _ list, product _ params _ list, source _ flag, source _ message, source _ networks _ list, group _ lists, account _ lists, CVV2_ lists, charge _ io _ list, cell _ priority _ list, charge _ value _ list, exchange _ list, update _ list, address _ list, and the like. Transaction table 1519j may contain fields such as, but not limited to, order _ id, user _ id, time, transaction _ cost, purchase _ details _ list, num _ products, products _ list, product _ type, product _ params _ list, product _ title, product _ summary, quantity _ quantity, user _ id, client _ ip, client _ type, client _ model, operation _ system, os _ version, app _ instruction _ flag, user _ id, account _ fixed, account _ type, account _ number, account _ priority _ account _ individual _ index _ flag, access _ soluble _ code _ update, address _ fixed, address _ copy _ partition, transaction _ copy _ code, address _ copy _ code _ copy _. The batch table 1519k may include fields such as, but not limited to, batch _ id, transaction _ id _ list, timestamp _ list, cleared _ flag _ list, and/or clear _ trigger _ settings, among others. Ledger table 1519l may contain fields such as, but not limited to, request _ id, timestamp, destination _ count, batch _ id, transaction _ id, clear _ flag, destination _ account, transaction _ summary, path _ name, and/or path _ account, among others. The arbiter table 1519m may contain columns such as, but not limited to.

The arbiter table 1519m may contain columns such as, but not limited to. Arbiter table 1519m may contain fields such as, but not limited to, arbitor _ id, arbitor _ name, arbitor _ geo, arbitor _ IP, arbitor _ URL, and/or merchant _ service _ list. The privacy rule table 1519n may include fields such as, but not limited to, user _ id, token _ id, home _ location, home _ count, default _ private _ flag, private _ rule _ set _ id, count, private _ rule _ data, private _ rule _ triggers _ list, process _ recovery _ fault, process _ recovery _ list, and/or home _ token _ server _ ip. The privacy country code table 1519o may contain columns such as, but not limited to, token _ hash _ ID, count _ code, and/or privacy _ rule _ ID.

In one embodiment, the PPT database may interact with other database systems. For example, using a distributed database system, queries and data access by searching PPT components may treat the combination of a PPT database, an integrated data security layer database, as a single database entity.

In one embodiment, the user program may contain various user interface primitives that may be used to update the PPT. Also, various accounts may require customer database tables depending on the environment and type of client that the PPT may need to service. It should be noted that any unique column may always be designated as a key column. In an alternative embodiment, these tables are dispersed into their own databases and their respective database controllers (i.e., a single database controller for each of the above tables). The database may be further distributed over several computer systematized and/or storage devices using standard data processing techniques. Similarly, the configuration of the decentralized database controller may be changed by consolidating and/or distributing various database components 1519 a-n. The PPT may be configured to keep track of various settings, inputs, and parameters through a database controller.

The PPT database may communicate with other components in the collection of components and/or similar facilities, including itself. The PPT database most often communicates with PPT components and/or other program components, etc. The database may contain, maintain, and provide information about other nodes and data.

PPT

PPT component 1535 is a stored program component that is executed by the CPU. In one embodiment, the PPT component incorporates any and/or all combinations of the aspects of the PPT discussed in the figures above. Thus, PPT leverages access, obtaining and providing information, services, and/or transactions, etc., across various communication networks.

The PPT component can translate payment token based orders through the PPT component into multi-issuer purchase payment funds transfers and the like and use of the PPT. In one embodiment, the PPT component 1535 takes input (e.g., purchase input 411, token arbiter address 416, token generation input 423, purchase input 611, token arbiter address 616, issuer data response 620, payment option input 626, issuer server data 636, user data 640 a-n, batch data 655 and/or issuer server data 663, etc.) and the like and converts the input into output (e.g., tokenization invitation 420, token data 426, token authorization confirmation 622a, issuer data update 629, authorization in progress messages 630-31, token data 634, authorization failure message 644, transaction data 645, authorization response 642 a-n, authorization success message 646-47, batch additional data 649, purchase receipt 650, transaction data 661, and/or funds transfer messages 668-69, etc.) through various components (e.g., TPE1541 and/or tPTE1542, etc.). .

Access to PPT information between components may be developed using techniques such as, but not limited to, Apache components, Assembly, Active X, binary executable, (ANSI) (Objective-) C (++), C #, and/or NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, process and Object oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, Web application server extensions, Web development environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR; FLEX & FLASH; AJAX; (D) HTML; Dojo; Java; Javascript; jQuery (UI); MooTools; Prototype; script. account. us; Simple Object Access Protocol (SOAP); FObject; and/or Ad User Interface etc.) and/or WebObjects. In one embodiment, the PPT server uses an encryption server to encrypt and decrypt communications. The PPT component can communicate with other components in the set of components and/or similar facilities, including itself. The PPT components most often communicate with PPT databases, operating systems, and/or other program components, among others. The PPT may contain, communicate, generate, obtain and/or provide program components, systems, users and/or data communication requests and/or responses.

Distributed PPT

The structure and/or actions of any of the PPT node controller assemblies may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, a collection of components can be combined in any number of ways to facilitate development and/or deployment. To accomplish this, components may be integrated into a common code base or a facility that may dynamically load components on demand in an integrated manner.

The collection of components can be combined and/or distributed in myriad variations, by standard data processing and/or development techniques. Multiple instances of any of the program components in the collection of program components may be instantiated on a single node and/or across a large number of nodes to improve performance through load balancing and/or data processing techniques. Also, individual instances may be distributed across multiple controllers and/or storage devices; such as a database. All program component instances and controllers working together can do so by standard data processing communication techniques.

The configuration of the PPT controller will depend on the context of the system deployment. Factors such as, but not limited to, budget, capacity, location, and/or use of underlying hardware resources may affect deployment requirements and configurations. Data may be transferred, obtained, and/or provided whether or not a configuration results in a more consolidated and/or integrated program component, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration. Instances of components consolidated from a collection of program components into a common code base may communicate, obtain, and/or provide data. This may be accomplished through in-application data processing communication techniques such as, but not limited to, data referencing (e.g., pointers), internal signaling, object instance variable communication, shared memory space and/or variable passing, and the like.

If the component collection components are discrete, separate, and/or external to each other, they may be passed through information such as, but not limited to, Application Program Interfaces (APIs); (Distributed) Component Object Model ((D) COM) and/or (Distributed) Object Linking and Embedding ((D) OLE), etc.), Common Object Request Broker Architecture (CORBA), Jini local and Remote application program interfaces, JavaScript Object notification (JSON), Remote Method Invocation (RMI), SOAP, process pipe, and/or shared file, etc., enabling communication with, obtaining and/or providing data to other components. Messages sent between discrete components of intra-application communication or within a memory space of a single component of intra-application communication may be facilitated by generating and parsing a grammar. The grammar can be developed through the use of development tools such as lex, yacc, and/or XML, which allows for grammar generation and parsing capabilities, which in turn form the basis for communication messages within and between components.

For example, the grammar can be configured to recognize tokens for post-HTTP commands, such as:

here, Value1 is identified as a parameter because "http://" is part of the grammar rule and is followed as part of the post Value. Similarly, with this syntax, the variable "Value 1" can be inserted into the "http://" post command and then sent. The grammar rules themselves may be presented as interpreted structural data and/or otherwise used to generate parsing mechanisms (e.g., grammar rule description text files processed by lex, yacc, etc.). And, once the analysis mechanism is generated and/or instantiated, it may itself process and/or analyze structural data such as, but not limited to, character (e.g., tag) rendered text, HTML, structural text streams, XML, and/or similar structural data. In another embodiment, the in-application data processing protocol itself may have an integrated and/or readily available parser (e.g., JSON, SOAP, and/or the like) that may be used to analyze (e.g., communicate) the data. Also, parsing syntax may be used in addition to message parsing, and may also be used to parse: databases, data collections, data stores and/or structured data, and the like. Also, the desired configuration will depend on the context, environment, and requirements of the system deployment.

For example, in some implementations, the PPT controller may execute PHP scripts that implement a secure socket layer ("SSL") socket server through an information server that listens for incoming communications on a server port to which a client may send data, such as data encoded in JSON format. Upon identifying the incoming communication, the PHP script may read the incoming message from the client device, parse the received JSON-encoded text data to extract information from the JSON-encoded text data as PHP script variables, and store the data (e.g., client identification information, etc.) and/or the extracted information in a relational database accessible by using a structured query language ("SQL"). The following provides an example manifest written substantially in the form of PHP/SQL commands to receive JSON encoded input data from a client device over an SSL connection, analyze the data to extract variables, and store the data to a database:

also, the following resources may be used to provide example embodiments for SOAP parser implementations and other parser implementations, as follows:

other resolvers are implemented as:

the entire contents of which are expressly incorporated herein by reference.

To address various issues and advance the art, the entirety of this application (including covers, headings, sub-headings, fields, backgrounds, summary, brief description of the drawings, detailed description, claims, abstract, drawings, and/or appendix, etc.) of a payment privacy tokenization apparatus, method, and system is intended to be illustrative of various embodiments in which the claimed innovations may be practiced. The advantages and features of the application are merely representative of the embodiments and are not exhaustive and/or exclusive. They are provided merely as an aid to understanding and teaching the principles of the claims. It should be understood that they are not intended to be a representation of the full breadth of the innovations herein. Thus, certain aspects of the present disclosure are not disclosed herein. No alternative embodiments have been presented for a particular part of the innovation or other alternative embodiments not described may be used for some part should not be construed as a disclaimer of such alternative embodiments. It should be understood that many of these undescribed embodiments contain the same principles of innovation and others are equivalent. It is therefore to be understood that other embodiments may be utilized and that functional, logical, operational, organizational, structural and/or layout modifications may be made without departing from the scope and/or spirit of the disclosure. Accordingly, all examples and/or embodiments are to be considered in the present disclosure as non-limiting throughout. Also, with respect to the embodiments discussed herein, those embodiments not discussed herein for the purpose of saving space and reducing repetition should be inferred. For example, it should be understood that the logic and/or arrangement of any program components (collection of components), other components, and/or any combination of features present, depicted in the drawings and/or throughout is not limited to a fixed order of operation and/or configuration, but rather that any disclosed order is exemplary and that this disclosure contemplates all equivalents, whether or not in order. Moreover, it should be appreciated that these features are not limited to being performed serially, and that this disclosure contemplates any number of threads, processes, services, and/or servers, etc., that may be performed asynchronously, simultaneously, in parallel, and/or synchronously. Thus, some of these features may be mutually inconsistent as they may not be present in a single embodiment at the same time. Similarly, some features are applicable to one aspect of the innovation, and not to others. Additionally, the disclosure includes other innovations not currently claimed. Applicants reserve all rights to presently unclaimed innovations, including the rights to such innovations, their file attach applications, continuation, partial continuation, and/or division. Thus, it should be understood that advantages, embodiments, examples, functions, features, logic, operations, organizations, structures, arrangements, and/or other aspects of the disclosure should not be considered limiting of the disclosure as defined by the claims or limiting of the equivalents of the claims. It should be appreciated that various embodiments of PPT may be implemented that may enable a great deal of flexibility and customization, depending on the PPT individual and/or enterprise users, database configuration and/or relationship models, data types, data transfers, and/or specific requirements and/or characteristics and/or syntactic structures of the network framework, etc. For example, aspects of the PPT may be adapted for compression algorithms, security systems, communication optimization, and the like. While various embodiments and discussions of PPT are directed to retail commerce, it should be understood that the embodiments described herein can be readily configured and/or customized for a wide variety of other applications and/or implementations.

Claims

1. A payment privacy tokenization apparatus comprising:

a processor;

a network communication device operatively connected to the processor; and

a memory operatively connected with the processor and storing processor-executable instructions for:

obtaining, by the network communication device, a purchase transaction request containing a payment token in place of the payment information and a source location identifier for a geographic source of the purchase transaction request in a memory;

extracting, by the processor, a payment token contained in the purchase transaction request;

querying a transaction processing privacy rule set associated with the payment token from a database using the extracted payment token;

obtaining, in memory from a database, a transaction processing privacy rule set associated with a payment token;

extracting, by the processor, privacy rules from the obtained transaction processing privacy rule set;

determining, by the processor, whether the privacy rule prohibits submission of a purchase transaction request for processing in a country associated with the source location identifier; and

providing, by the network communication device, a purchase transaction request to a payment network server based on a determination of whether the privacy rule prohibits submission of the purchase transaction for processing in a country associated with the source location identifier.

2. The apparatus of claim 1, the memory further storing instructions for:

identifying, by the processor, an address of a payment network server located outside a country associated with the source location identifier when it is determined that the privacy rule prohibits submission of a purchase transaction for processing in the country associated with the source location identifier; and is

Wherein the purchase transaction request is provided to an address of an identified payment network server located outside the country associated with the source location identifier.

3. The apparatus of claim 1, the memory further storing instructions for:

identifying, by the processor, an address of a payment network server located within a country associated with the source location identifier when it is determined that the privacy rules require that a purchase transaction be submitted for processing in the country associated with the source location identifier; and is

Wherein the purchase transaction request is provided to an address of an identified payment network server located within a country associated with the source location identifier.

4. The apparatus of claim 1, the memory further storing instructions for:

identifying, by the processor, an address of a payment network server located within a country associated with the source location identifier when it is determined that the privacy rules allow the purchase transaction to be submitted for processing in the country associated with the source location identifier; and is

5. The apparatus of claim 1, the memory further storing instructions for:

querying a database for a set of factors for selecting a payment network server to which to provide a purchase transaction request when it is determined that the privacy rules allow submission of the purchase transaction for processing in one of the plurality of countries; and is

Obtaining, in memory from a database, the set of factors and the weight associated with each of the factors for selecting from the database a payment network server to which to provide the purchase transaction request;

identifying a set of candidate payment network servers to which purchase transactions may be provided for transaction processing;

calculating a weighted score for each of the candidate payment network servers using the factors and their associated weights;

selecting one from the set of candidate payment network servers based on the calculated weighted score; and is

Wherein the purchase transaction request is provided to an address associated with the selected payment network server.

6. The apparatus of claim 5, wherein the set of factors used to select the payment network server to which to provide the purchase transaction request includes network congestion.

7. The apparatus of claim 5, wherein server load balancing is included in the set of factors for selecting the payment network server to which to provide the purchase transaction request.

8. A payment privacy tokenization apparatus comprising means for:

obtaining a purchase transaction request containing a payment token in place of the payment information and a source location identifier for a geographic source of the purchase transaction request;

extracting a payment token contained in the purchase transaction request;

obtaining a transaction processing privacy rule set associated with a payment token;

extracting privacy rules from the obtained transaction processing privacy rule set;

determining whether the privacy rule prohibits submission of a purchase transaction request for processing in a country associated with the source location identifier; and

the purchase transaction request is provided to the payment network server in accordance with a determination of whether the privacy rules prohibit submission of the purchase transaction for processing in a country associated with the source location identifier.

9. The apparatus of claim 8, further comprising means for:

identifying an address of a payment network server located outside a country associated with the source location identifier when it is determined that the privacy rule prohibits submission of a purchase transaction for processing in the country associated with the source location identifier; and is

10. The apparatus of claim 8, further comprising means for:

identifying an address of a payment network server located within a country associated with the source location identifier when it is determined that the privacy rules require that a purchase transaction be submitted for processing in the country associated with the source location identifier; and is

11. The apparatus of claim 8, further comprising means for:

identifying an address of a payment network server located within a country associated with the source location identifier when it is determined that the privacy rules allow submission of a purchase transaction for processing in the country associated with the source location identifier; and is

12. The apparatus of claim 8, further comprising means for:

13. The apparatus of claim 12, wherein the set of factors used to select the payment network server to which to provide the purchase transaction request includes network congestion.

14. The apparatus of claim 12, wherein server load balancing is included in the set of factors used to select the payment network server to which the purchase transaction request is provided.

15. A payment privacy tokenization processor-implemented method comprising:

16. The method of claim 15, further comprising:

17. The method of claim 15, further comprising:

18. The method of claim 15, further comprising:

19. The method of claim 15, further comprising:

20. The method of claim 19, wherein network congestion is included in the set of factors used to select the payment network server to which the purchase transaction request is provided.

21. The method of claim 19, wherein server load balancing is included in the set of factors used to select the payment network server to which the purchase transaction request is provided.

22. A payment privacy token arbitration processor-implemented method, comprising:

receiving a purchase request from a user mobile device in a first country location;

responding to the purchase request with a payment request containing at least the requested payment amount;

receiving a one-way cryptographically hashed purchase token from the user mobile device, wherein the one-way cryptographically hashed purchase token was created at least by using the user account identifier;

querying a data privacy country code user database using a one-way cryptographic hash purchase token to determine a home code for the user;

querying a country code privacy rules database with a home code for the user to determine a privacy preserving requirement rule set;

generating at least one acceptable processing location identifier using the privacy preserving requirement rule set;

selecting a target country location for processing the purchase request, the target country location being one of:

a first country location, when the first country location is contained within at least one acceptable processing location, and

another country from the at least one acceptable processing location when the first country is not contained within the at least one acceptable processing location;

sending the one-way cryptographically hashed purchase token to a server in the target country location for processing the purchase request;

receiving confirmation from a server in the target country location that the payment request has been successfully processed; and

a confirmation that the purchase request has been authorized for the requested payment amount is transmitted to the user mobile device.

23. A payment privacy token arbitration processor-implemented method, comprising:

receiving a purchase request and a privacy-enhanced purchase token from a user device in a first national location;

determining a privacy preserving requirement rule set using the privacy enhanced purchase token, wherein determining the privacy preserving requirement rule set comprises:

querying a data privacy country code user database using the privacy enhanced purchase token to determine a home code for the user; and

selecting a target country location for processing the purchase request based on the privacy preserving requirements rule set; and

the purchase request is processed using a server located in the target country location.

24. The method of claim 23, wherein the user equipment is a mobile device.

25. The method of claim 24, wherein the mobile device is one of a smart card, a prepaid card, a credit card, a debit card, a smart phone, a PDA, a laptop computer, and a handheld computing device.

26. The method of claim 23, wherein the privacy-enhanced purchase token is generated using a user account identifier.

27. The method of claim 26, wherein the privacy-enhanced purchase token is further generated using a home identifier.

28. The method of claim 23, wherein the privacy enhanced purchase token includes a user home location identifier.

29. The method of claim 23, wherein the privacy-enhanced purchase token is generated using user payment account data.

30. The method of claim 23, wherein the privacy-enhanced purchase token is encrypted using an MD5 hash function.

31. The method of claim 23, wherein the privacy-enhanced purchase token is encrypted using an Elf64 hash function.

32. The method of claim 23, wherein the privacy-enhanced purchase token is encrypted using public key encryption.

33. The method of claim 23, wherein the privacy-enhanced purchase token is encrypted using a two-way encryption algorithm.

34. The method of claim 23, further comprising discerning content of the privacy-enhanced purchase token.

35. The method of claim 23, wherein privacy preserving requires that a rule set requires that payments are always processed in the user's home country.

36. The method of claim 23, wherein privacy preserving requires that a rule set requires that payments are always processed in a given area.

37. The method of claim 36, wherein the given region is the european union.

38. The method of claim 23, wherein the privacy preserving requirement rule set indicates that no prevention of sharing of user information is required and contains rules for effectively processing payments.

39. The method of claim 38, wherein efficiently processing the payment comprises sending payment processing to a server with less load.

40. The method of claim 38, wherein efficiently processing the payment comprises sending a payment process to a server on the network with less network congestion.

41. The method of claim 23, wherein the data privacy country code user database contains at least a user identifier and a country code.

42. The method of claim 23, wherein the country code privacy rules database contains at least a country code and an indication of a country that requires enhanced privacy preservation.

43. The method of claim 23, wherein selecting a target country location for processing the purchase request comprises:

the method further includes determining from the privacy preserving requirements rule set that the first country is unacceptable for processing the purchase request, and selecting from the privacy preserving requirements rule set a second country that is acceptable for processing the purchase request.

44. A payment privacy token arbitration processor-implemented system, comprising:

means for receiving a purchase request from a user mobile device in a first country location;

means for responding to the purchase request with a payment request containing at least the requested payment amount;

means for receiving a one-way cryptographically hashed purchase token from a user mobile device, wherein the one-way cryptographically hashed purchase token was created at least by using a user account identifier;

means for querying a data privacy country code user database using a one-way cryptographic hash purchase token to determine a home code for the user;

means for querying a country code privacy rules database with a home code for the user to determine a privacy preserving requirements rule set;

means for generating at least one acceptable processing location identifier using a privacy preserving requirement rule set;

means for selecting a target national location for processing the purchase request, the target national location being one of:

means for sending the one-way cryptographically hashed purchase token to a server in the target country location for processing the purchase request;

means for receiving confirmation from a server in the target country location that the payment request has been successfully processed; and

means for transmitting a confirmation to the user mobile device that the purchase request has been authorized for the requested payment amount.

45. A payment privacy token arbitration processor-implemented system, comprising:

means for receiving a purchase request and a privacy-enhanced purchase token from a user device in a first national location;

means for determining a privacy preserving requirement rule set using the privacy enhanced purchase token, wherein determining the privacy preserving requirement rule set comprises:

means for selecting a target country location for processing the purchase request based on the privacy preserving requirements rule set; and

means for processing the purchase request using a server located in the target country location.

46. The system of claim 45, wherein the user equipment is a mobile device.

47. The system of claim 45, wherein the mobile device is one of a smart card, a prepaid card, a credit card, a debit card, a smart phone, a PDA, a laptop computer, and a handheld computing device.

48. The system of claim 45, wherein the privacy enhanced purchase token is generated using a user account identifier.

49. The system according to claim 48, wherein the privacy enhanced purchase token is further generated using a home identifier.

50. The system of claim 45, wherein the privacy enhanced purchase token includes a user home location identifier.

51. The system of claim 45, wherein the privacy enhanced purchase token is generated using user payment account data.

52. The system according to claim 45, wherein the privacy enhanced purchase token is encrypted using an MD5 hash function.

53. The system according to claim 45, wherein the privacy enhanced purchase token is encrypted using an Elf64 hash function.

54. The system according to claim 45, wherein the privacy-enhanced purchase token is encrypted using public key encryption.

55. The system according to claim 45, wherein the privacy enhanced purchase token is encrypted using a two-way encryption algorithm.

56. The system of claim 45, further comprising means for discerning the content of the privacy enhanced purchase token.

57. The system of claim 45, wherein privacy preserving requirements rule sets require that payments are always processed in the user's home country.

58. The system of claim 45, wherein privacy preserving requires a rule set that requires payment to always be processed in a given area.

59. The system of claim 58 wherein the given region is the European Union.

60. The system of claim 45, wherein the privacy preserving requirement rule set indicates that no prevention of sharing of user information is required and contains rules for effectively processing payments.

61. The system of claim 60 wherein efficiently processing the payment includes sending payment processing to a server with less load.

62. The system of claim 60 wherein efficiently processing the payment comprises sending a payment process to a server on the network with less network congestion.

63. The system of claim 45 wherein the data privacy country code user database contains at least a user identifier and a country code.

64. The system of claim 45, wherein the country code privacy rules database contains at least a country code and an indication of a country that requires enhanced privacy preservation.

65. The system of claim 45, wherein selecting a target country location for processing the purchase request further comprises:

means for determining from the privacy preserving requirements rule set that the first country is not acceptable for processing the purchase request and selecting from the privacy preserving requirements rule set a second country that is acceptable for processing the purchase request.

66. A payment privacy token arbitration processor-implemented apparatus comprising:

a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions for:

67. A payment privacy token arbitration processor-implemented apparatus comprising:

a memory;

68. The apparatus of claim 67, wherein the user equipment is a mobile device.

69. The apparatus of claim 68, wherein the mobile device is one of a smart card, a prepaid card, a credit card, a debit card, a smart phone, a PDA, a laptop computer, and a handheld computing device.

70. The apparatus of claim 67, wherein the privacy enhanced purchase token is generated using a user account identifier.

71. The apparatus of claim 70, wherein the privacy-enhanced purchase token is further generated using a home identifier.

72. The apparatus of claim 67, wherein the privacy enhanced purchase token includes a user home location identifier.

73. The apparatus of claim 67, wherein the privacy enhanced purchase token is generated using user payment account data.

74. The apparatus according to claim 67, wherein the privacy-enhanced purchase token is encrypted using an MD5 hash function.

75. The apparatus according to claim 67, wherein the privacy enhanced purchase token is encrypted using an Elf64 hash function.

76. The apparatus of claim 67, wherein the privacy-enhanced purchase token is encrypted using public key encryption.

77. The apparatus of claim 67, wherein the privacy-enhanced purchase token is encrypted using a two-way encryption algorithm.

78. The apparatus of claim 67, further comprising identifying content of the privacy-enhanced purchase token.

79. The apparatus of claim 67, wherein the privacy preserving requirement rule set requires that payment be always processed in the user's home country.

80. The apparatus of claim 67, wherein privacy preserving requirements rule sets require that payments are always processed in a given area.

81. The apparatus of claim 80, wherein the given region is the European Union.

82. The apparatus of claim 67, wherein the privacy preserving requirement rule set indicates that no prevention of sharing of user information is required and includes rules for efficiently processing payments.

83. The apparatus of claim 82 wherein efficiently processing the payment comprises sending payment processing to a server with less load.

84. The apparatus of claim 82, wherein efficiently processing the payment comprises sending a payment process to a server on the network with less network congestion.

85. The apparatus of claim 67 wherein the data privacy country code user database contains at least a user identifier and a country code.

86. The apparatus of claim 67, wherein the country code privacy rules database contains at least a country code and an indication of a country that requires enhanced privacy preservation.

87. The apparatus of claim 67, wherein selecting the target country location for processing the purchase request comprises: