WO2013082190A1 - Transaction security graduated seasoning and risk shifting apparatuses, methods and systems - Google Patents

Transaction security graduated seasoning and risk shifting apparatuses, methods and systems Download PDF

Info

Publication number
WO2013082190A1
WO2013082190A1 PCT/US2012/066898 US2012066898W WO2013082190A1 WO 2013082190 A1 WO2013082190 A1 WO 2013082190A1 US 2012066898 W US2012066898 W US 2012066898W WO 2013082190 A1 WO2013082190 A1 WO 2013082190A1
Authority
WO
WIPO (PCT)
Prior art keywords
risk
transaction
mitigation
request
user
Prior art date
Application number
PCT/US2012/066898
Other languages
French (fr)
Inventor
Ayman Hammad
Edward Katzin
Craig O'connell
Shaw Li
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/434,818 external-priority patent/US20130218765A1/en
Application filed by Visa International Service Association filed Critical Visa International Service Association
Priority to PCT/US2013/020411 priority Critical patent/WO2013103912A1/en
Priority to CN201380001482.6A priority patent/CN103843024A/en
Priority to JP2014551377A priority patent/JP6153947B2/en
Priority to AU2013207407A priority patent/AU2013207407A1/en
Priority to EP13733776.2A priority patent/EP2801065A4/en
Priority to KR1020137028128A priority patent/KR20140121764A/en
Priority to US13/735,802 priority patent/US20130218721A1/en
Publication of WO2013082190A1 publication Critical patent/WO2013082190A1/en
Priority to PCT/US2014/010378 priority patent/WO2015112108A1/en
Priority to HK15104251.9A priority patent/HK1203680A1/en
Priority to US16/198,591 priority patent/US10685379B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/384—Payment protocols; Details thereof using social networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles

Definitions

  • the present innovations generally address apparatuses, methods, and4 systems for electronic security, and more particularly, include TRANSACTION5 SECURITY GRADUATED SEASONING AND RISK SHIFTING APPARATUSES,6 METHODS AND SYSTEMS ("TSGS"). 7 BACKGROUND
  • Consumer transactions typically require a customer to select a product9 from a store shelf or website, and then to check the out at a checkout counter or0 webpage.
  • the customer usually has to provide login information to proceed to checkout,1 or enter a 4-digit PIN number to authorize a transaction at checkout.
  • the point-of-sale terminal memorializes the transaction in the3 merchant's computer system, and a receipt is generated indicating the satisfactory4 consummation of the transaction.
  • FIGURES lA-C show block diagrams illustrating example aspects of the TSGS
  • FIGURES 2A-2H show diagrams illustrating example TSGS logic flows and component configuration
  • FIGURE 3 shows a datagraph diagram illustrating examples of transforming user virtual wallet activity via a User Wallet Activity Recording ("UWAR”) component into stored user wallet activity records;
  • UWAR User Wallet Activity Recording
  • FIGURE 4 shows a logic flow diagram illustrating examples of transforming user virtual wallet activity via a User Wallet Activity Recording (“UWAR”) component into stored user wallet activity records;
  • UWAR User Wallet Activity Recording
  • FIGURE 5 shows a datagraph diagram illustrating examples of transforming user fraud reporting inputs via a Fraud Data Recording ("FDR”) component into stored fraud report data records;
  • FDR Fraud Data Recording
  • FIGURES 6A-B shows a logic flow diagram illustrating examples of transforming historical virtual wallet fraud reports via a Statistical Risk Analysis (“SRA”) component into transaction risk assessment data and rules;
  • SRA Statistical Risk Analysis
  • FIGURE 7 shows a logic flow diagram illustrating examples of transforming transaction requests, security inputs, historical wallet activity data, and transaction risk assessment data/rules via a Transaction Risk Assessment ("TRA") component into transaction risk assessment type/score signals;
  • FIGURES 8A-D show block and logic flow diagrams illustrating examples of transforming transaction risk type and score assessments, security data, and transaction risk allocation offer responses, via Graduated Security Escalation (“GSE”) and Transaction Risk Shifting (“TRS”) components, into transaction authorization notifications/triggers and transaction denial notifications;
  • GSE Graduated Security Escalation
  • TRS Transaction Risk Shifting
  • FIGURE 9 shows a datagraph diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout (“UPC”) component into a checkout data display output;
  • FIGURE 10 shows a logic flow diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout (“UPC") component into a checkout data display;
  • FIGURES 11A-B show datagraph diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization (“PTA”) component into a purchase transaction receipt notification;
  • FIGURES 12A-B show logic flow diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization (“PTA”) component into a purchase transaction receipt notification;
  • FIGURES 13A-B show datagraph diagrams illustrating example aspects of transforming a merchant transaction batch data query via a Purchase Transaction Clearance (“PTC”) component into an updated payment ledger record;
  • PTC Purchase Transaction Clearance
  • FIGURE 15 shows a user interface diagram illustrating an overview of example features of virtual wallet applications in some embodiments of the TSGS;
  • FIGURES 16A-G show user interface diagrams illustrating example features of virtual wallet applications in a shopping mode, in some embodiments of the TSGS;
  • FIGURES 17A-F show user interface diagrams illustrating example features of virtual wallet applications in a payment mode, in some embodiments of the TSGS;
  • FIGURE 18 shows a user interface diagram illustrating example features of virtual wallet applications, in a history mode, in some embodiments of the TSGS;
  • FIGURES 19A-E show user interface diagrams illustrating example features of virtual wallet applications in a snap mode, in some embodiments of the TSGS;
  • FIGURE 20 shows a user interface diagram illustrating example features of virtual wallet applications, in an offers mode, in some embodiments of the TSGS;
  • FIGURES 21A-B show user interface diagrams illustrating example features of virtual wallet applications, in a security and privacy mode, in some embodiments of the TSGS;
  • FIGURES 22A-F include example data flows, where the TSGS may be effected, and illustrates various additional advantageous aspects of the TSGS; and
  • FIGURE 23 shows a block diagram illustrating example aspects of a TSGS controller.
  • the leading number of each reference number within the drawings indicates the figure in which that reference number is introduced and/or detailed. As such, a detailed discussion of reference number 101 would be found and/or introduced in Figure 1.
  • Reference number 201 is introduced in Figure 2, etc.
  • the TRANSACTION SECURITY GRADUATED SEASONING AND RISK SHIFTING APPARATUSES, METHODS AND SYSTEMS provides a platform for securely storing consumer payment credentials in a trusted repository with the assurance that the credential is both valid and associated with its rightful user.
  • the TSGS may shift fraud liability from the merchant, which would otherwise have liability for unauthenticated CNP transactions, to the issuer, e.g., via various transaction challenges as further discussed in Table 16.
  • digital wallets which are introduced as a mechanism to facilitate ease of payment, particularly when conducting transactions from mobile devices, may provide access to payment/account data that is remotely stored.
  • a first layer of consumer validation to access/use the remote payment information may be a user login (username / password), which may be susceptible to account takeover and unauthorized use. Additional data, such as a consumer's device information obtained during the session, may be used to help further validate that the authorized user is accessing the remote payment data.
  • Another type of data obtained from the consumer's device i.e. laptop, tablet, mobile
  • device printing may enable the merchants to determine if they have "seen” this consumer using this device before. This information can also be used to evaluate the risk of the transaction.
  • the consumer enters information on the merchant's website that indicates they reside in the U.S., but the consumer's device shows a foreign location and the device is configured to support a non-English language. This could represent a suspicious transaction and the merchant might request additional information to validate the consumer's identity.
  • the TSGS may create a new authentication method by obtaining and tracking information about the consumer's device, combining the PAN, user's wallet login and device information to create a unique 'Stored Credential' record.
  • the TSGS may include a multi-factor authentication procedure including authenticating wallet login (e.g., user name and password), the consumer device, and/or the like.
  • authenticating wallet login e.g., user name and password
  • future transactions using the same Stored Credential may be considered 'Authenticated' with no additional action required from the consumer (i.e., reducing friction at time of purchase)
  • the TSGS may transform user virtual wallet activity and historical fraud reports, via TSGS components, into transaction authorization triggers generated pursuant to graduated, transaction risk-appropriate, escalated security protocols.
  • FIGURES lA-B show block diagrams illustrating example aspects of the TSGS.
  • the TSGS may allow a user to engage in a purchase transaction with a merchant using one or more accounts stored in a virtual wallet of the user.
  • the user may download and install a TSGS mobile wallet component on a mobile device (e.g., an Apple iPhone, a BlackBerry, a Google Android, a Samsung Galaxy, etc.) or other portable web-enabled computing device.
  • a mobile device e.g., an Apple iPhone, a BlackBerry, a Google Android, a Samsung Galaxy, etc.
  • a user may be able to access a virtual wallet account from a point-of-sale ("POS") terminal in a merchant store, or on a merchant website.
  • POS point-of-sale
  • Alternative and/or complementary user interfaces are also contemplated including: desktop applications, plug-ins to existing applications, stand alone mobile applications, web based applications (e.g., applications with web objects/frames, HTML 5 applications/wrappers, web pages, etc.), and/or the like.
  • the TSGS may perform security checks before authorizing a transaction using an account from the user's virtual wallet. For example, the TSGS may assess transaction risks associated with authorizing the transaction to be completed. For example, the TSGS may identify one or more transaction risk types, and associated risk scores to each of the transaction risk types. Examples of risk types include, without limitation: user fraud, merchant fraud, insufficient account funds, product return, television advertisement scams, product recall, account hacks, wire fraud, mail fraud, spyware/malware invading transaction privacy, etc. The TSGS may require specific security protocols to be adopted depending on the transaction risk types.
  • the TSGS may determine a risk score associated with each risk type, and modify the security protocols followed to authorize the transaction depending on the risk scores. For example, the TSGS may determine a risk score for each risk type based on factors such as, without limitation: the type of the current transaction (e.g., user enrollment into a new request, purchase transaction, modifying user wallet settings, modifying privacy settings, accessing personal information), current user transaction request details, historical (including recent/real-time) user virtual wallet activity, historical fraud reporting data (e.g., including parameters correlated to fraudulent activity), responses to secure authentication requests, etc. [0037] In some embodiments, the TSGS may categorize risks associated with a type of transaction risk into graduated levels.
  • the TSGS may appropriately escalate (or de-escalate, as the case may be) the security protocol(s) required to mitigate the risk. For example, where a transaction risk type is at a higher risk level, the TSGS may escalate the security protocol required to authorize the transaction to a more secure protocol, which in some scenarios may come with additional attendant burden on the entity (e.g., a user) required to engage in the security protocol.
  • a first tier of (low) risk may only require a security protocol set 1 (103a), which may have a low burden.
  • the protocol may only require a response from a device of the user, without requiring the user to provide any input for the device to generate a response. For example, if a device has to provide its IP address, user intervention may not be required.
  • a transaction risk type 101 e.g., risk typei (111), risk type 2 (112), risk type 3 (113)
  • the TSGS may escalate the protocols employed from security protocol set 1 to security protocol set 2 (103b) (which may pose a higher burden to one of the entities involved in the transaction).
  • the TSGS may escalate the security protocol set for the entities involved in the transaction to security protocol set 3 (103c) or security protocol set 4 (103d).
  • different transaction risk types may be escalated at different values of risk scores associated with each of the risk types, either dependent on or independent of the escalation of security protocols for any of the other transaction risk types associated with the transaction.
  • the graduated levels for the different transaction risk type may be drawn at different values of transaction risk scores associated with the transaction risk types.
  • the set of entities engaged in a security protocol associated with one graduate risk level may be the same as, of different from, the set of entities engaged in a different security protocol associated with a different graduated risk level.
  • each of the transaction risk types 101 may be its own independent axis that can result in an N-dimensional security transaction familiarity Cartesian space.
  • historical tracking of the different types of fraud may be aggregated over time, to create plots/curves.
  • Figure lC shows a 3-dimensional space where security authentication acts as the y-axis, security authentication level acts as the x-axis, and familiarity level acts as the z-axis.
  • the curved space along the x-z plane may create surface models connected to the curves of the y-x plane, thereby making surface models showing relationships between security authentication burden 102, transaction risk 101, and familiarity amelioration levels 112.
  • first- and or second-level derivative of any point in the surface models may be taken to attain a risk rate level which may be used, when normalized, as a basis for risk amount mitigation weights (e.g., see the "risk mitigation amount” column in Table 16 and FIGURE 8A).
  • second-level derivatives may be taken from a three-dimensional surface model, and similarly (n-i)th level derivatives may be taken from a n-dimensional surface model, in order to generate a risk rate level.
  • the first-level derivative of any two-dimensional plane projection of a three-dimensional surface may be utilized to calculate risk mitigation amount.
  • the selection of a security protocol may be dependent on the amount of burden (e.g., amount of time, amount of user input, amount of attention that needs to be paid, etc.) imposed on the entity (e.g., a user) engaged in the security protocol. For example, if a risk can be mitigated by either of two sets of protocols, and one set imposes a lesser burden on the entity engaged in the security protocol than the other, then the first set may be chosen in some embodiments.
  • the security protocol that imposes the least burden on a human may be chosen, even if it means that the burden imposed on a device (e.g., the user's Smartphone) may be higher.
  • the TSGS may choose security protocols that can mitigate the risk while minimizing the intrusion into the user's experience, or minimizing the amount of attention the user needs to pay to the security protocol.
  • the TSGS may determine a transaction risk level 111, of a transaction risk type associated with a transaction request, based on the familiarity 112 that the TSGS has with the parameters of the transaction request.
  • the TSGS may calculate the transaction risk(s) associated with the transaction request as being higher compared to when the TSGS has a higher level of familiarity with the originating device (see curve in FIGURE lB for transaction parameter 1, 116a).
  • Such familiarity-based transaction risk assessment may extend to any parameter of the current transaction request.
  • FIGURE lB shows two curves representing the dependence of the transaction risk level of a transaction risk type associated with the transaction request on the familiarity of the TSGS with the sales channel (e.g., mobile, online, physical store, etc.) utilize for the transaction (see 116b), and the dependence of the transaction risk level of a transaction risk type associated with the transaction request on the familiarity of the TSGS with the geographic location of the originator of the transaction (see 116b).
  • Other parameters to which such familiarity-based transaction risk assessment may extend include, without limitation: user ID; merchant ID; product type; product ID; transaction cost; payment mechanism (e.g., account numbers); geographical location; payment currency; combinations thereof and/or the like.
  • the TSGS may determine that the familiarity of a transaction parameter is such that the transaction risk contribution of that parameter may be neglected in the calculation of transaction risk. Such a parameters may be determined to be "seasoned” 115, whereas parameters that the TSGS may determine may not (yet) be neglected in the calculation of transaction risk may be considered "unseasoned” 114.
  • the TSGS may utilize different seasoning thresholds 113 to determine the seasoning of different parameters in the calculation of transaction risk. Further, in various embodiments, the calculation of transaction risk may depend on numerous factors besides the seasoning levels of the parameters of the transaction request.
  • authentication of a transaction can be done separately from authorization/payment, in any environment (e.g., electronic commerce, mobile payments, person-to-person, etc.).
  • authentication may be integrated into the authorization flow, e.g., as illustrated in FIGURE 11A.
  • consumer credentials as well as device credentials may be evaluated for risk and fraud management.
  • the TSGS may apply graduated authentication and fraud review appropriate to the action being taken and the actual risk of loss or data compromise.
  • the TSGS may utilize non- invasive technologies where possible.
  • Examples of risks that the TSGS may eliminate or mitigate using graduated authentication during scenarios including, without limitation: merchant on-boarding and authentication; merchant transaction processing (e.g., platform review of merchant activity); merchant login, and maintenance; merchant pay- out/deposit changes, user creation etc.; consumer registration; consumer login; consumer maintenance (e.g., updating preferences, reviewing transactions, rewards, etc.); adding cards, shipping address, payment methods, etc.; reviewing transactions; and/or the like.
  • merchant transaction processing e.g., platform review of merchant activity
  • merchant login, and maintenance merchant pay- out/deposit changes, user creation etc.
  • consumer registration consumer login
  • consumer maintenance e.g., updating preferences, reviewing transactions, rewards, etc.
  • adding cards shipping address, payment methods, etc.
  • reviewing transactions and/or the like.
  • the TSGS may provide gradated, escalatable, initial evaluations and requirements, and may have customized authenticated decision trees applied to them using a variety of data elements including, without limitation: federated IDs; username/account alias; password; IP address; device fingerprint-issuer record comparison; device fingerprint-wallet record comparison; address verification services; identification challenge questions; merchant IP address; merchant device; merchant BIN; merchant card number; merchant-stored shipping address; email address; phone number; CW; and/or the like.
  • a failure of authentication may result not in a full denial of the transaction, but in an escalation of the challenge presented to the entity taking the action.
  • the risk in such transaction may be assessed using indicators available in data fields including, without limitation: category of action; type of action; user history; merchant history; device intelligence data elements; merchant category; product category; product quantity; product price point; and/or the like.
  • the TSGS may also utilize device fingerprinting data in real-time risk assessment/security protocol graduation for online and/or mobile transactions.
  • Authentication challenges during protocol escalation may include calls to third-party identification services (e.g., Idology, Experian, Accurint, 192.com, Dunn & Bradstreet, etc.). Such third-party calls may be saved for the highest risk events, such as merchant automated underwriting or high risk/high price consumer initiated events.
  • third-party identification services e.g., Idology, Experian, Accurint, 192.com, Dunn & Bradstreet, etc.
  • FIGURE 2A shows a block diagram illustrating an example TSGS logic flow and component configuration.
  • a user, a merchant, a user device, etc. may request the TSGS to authorize a purchase transaction, e.g., 211.
  • the request may take the form of a card authorization request, such as that card authorization request 1116, depicted in the example purchase transaction authorization ("PTA") component of FIGURE 11.
  • PTA purchase transaction authorization
  • the TSGS may obtain historical data on user's activity (including recent or real-time user behavior in the virtual wallet) in the user's (or user-related) virtual wallet from a database, e.g., 212.
  • the TSGS may utilize a component such as the example user wallet activity recording (“UWAR”) component of FIGURES 3-4 to generate historical user wallet activity data records that are stored in the database.
  • the TSGS may also obtain historical virtual wallet fraud data reports, e.g., 213, to inform transaction risk analysis.
  • the TSGS may utilize a component such as the example fraud data recording (“FDR") component of FIGURE 5 to generate historical (virtual wallet) fraud data records that are stored in a database.
  • the TSGS may perform a Statistical Risk Analysis, e.g., 214, on the historical fraud data records to generate transaction risk assessment reference data points, rules, score weights, etc., e.g., 215.
  • the TSGS may utilize a component such as the example Statistical Risk Analysis (“SRA”) component of FIGURES 6A-B to generate the transaction risk assessment reference data points, rules, score weights, etc.
  • SRA Statistical Risk Analysis
  • the TSGS may identify a set of transaction risk types associated with the current transaction request, and may calculate a risk score associated with each of the transaction risk types, e.g., 216.
  • the TSGS may utilize a component such as the example transaction risk assessment (“TRA”) component of FIGURE 7, to identify a set of transaction risk types associated with the current transaction request, and calculate risk scores associated with each of the transaction risk types.
  • TRA transaction risk assessment
  • the TSGS may attempt to allocate the transaction risks associated with the current transaction request to one or more entities involved in the current transaction (e.g., user, merchant, issuer, acquirer, payment service processor, payment network, etc.).
  • the TSGS may provide an offer to one or more of the entities to assume (a portion of) the risk type associated with the transaction, e.g., 219.
  • the TSGS may offer a discount, rewards, incentive, bonus, future payout, reduced transaction fees, etc., in exchange for the entity assuming the risk specified in the offer. If any of the entities accept the offer to assume (a portion of) the risk type, then the TSGS may recalculate the risk score associated with the risk type.
  • the TSGS may authorize the transaction (assuming no other transaction risks are present that need to be mitigated). If the risk score is not at an acceptably low level, then the TSGS may select a set of security protocols for the entities involved in the transaction to engage in before authorizing the transaction, e.g., 222.
  • the TSGS may utilize a component such as the example graduated security protocol escalation ("GSPE") and transaction risk shifting (“TRS”) components of FIGURES 8A-C, to select a set of security protocols for the entities involved in the transaction to engage in before authorizing the transaction.
  • GSPE graduated security protocol escalation
  • TRS transaction risk shifting
  • the TSGS may deny the transaction, e.g., 225. If, however, there are security protocols that may mitigate the risk if successfully completed, then the TSGS may request the entities involved in the transaction (e.g., user, user device, merchant, merchant device, issuer, acquirer, etc.) to provide security data, e.g., 224, 219. The entities may provide the requested security data, otherwise the TSGS may deny the transaction request.
  • the entities involved in the transaction e.g., user, user device, merchant, merchant device, issuer, acquirer, etc.
  • the entities may provide the requested security data, otherwise the TSGS may deny the transaction request.
  • the TSGS may utilize the new security data, in addition to the previously mentioned data, to re-assess the risk(s) involved in the transaction, and if needed, re-apply the above-mentioned procedure until the level of each transaction risk type is reduced to acceptable levels, or the risks are assumed by one of the entities involved in the transaction.
  • the TSGS may authorize the transaction for execution, e.g., 226.
  • FIGURE 2B provides a data flow diagram illustrating transaction flow of the stored credential within embodiments of the TSGS.
  • a consumer 240 may finalize purchase and confirms payment method, e.g., by submitting a payment request with card selection and purchase item information 231 to the merchant 241.
  • the merchant 241 may provide consumer 240 with options to checkout via a digital wallet, e.g., by presenting a "V.me” checkout button on a checkout page for online shopping 232.
  • the consumer's digital wallet 242 may send authentication request 233 to a stored credential service server (e.g., hosted by a processing network such as VisaNet, etc.) via a new 3-D Secure protocol message 243 to determine whether the stored credential (e.g., consumer wallet-ID/V.me GUID, PAN, consumer device information, etc.) has been previously authenticated.
  • a stored credential service server e.g., hosted by a processing network such as VisaNet, etc.
  • the TSGS may determine whether the consumer's stored credential is authenticated, and TSGS may perform real-time risk assessment for the transaction (e.g., Visa Dynamic Network Analytics (VDNA), etc.).
  • VDNA Visa Dynamic Network Analytics
  • the consumer's stored credential is authenticated and the transaction may yield a low risk 244, no additional authentication is needed and the transaction is sent to the digital wallet to process the authorization 235.
  • consumer's stored credential is non- authenticated/suspect (e.g., first time consumer device has been used with this PAN, the 1 PAN has been reported as fraud by the issuer) or the transaction is high risk 245, TSGS
  • FIGURES 2C-2D provide alternative embodiments of transaction flows for
  • the wallet provider may generate a
  • 9 wallet provider may send the required data to a SCS component using a SCS Request
  • the SCSReq message may be a new message using the 3D
  • a SCS Response (SCSRes) message 249 may be created by the SCS
  • the SCS messages may be logged (e.g. in CMLS) and saved (e.g. in the
  • an exemplary SCSReq message For example, in one implementation, an exemplary SCSReq message
  • 15 252 may comprise fields as shown in the following table:
  • the SCSReqAmount element may contain the
  • SCSReqCurrencyExponent may contain the
  • Japanese Yen may contain a value
  • the TSGS may verify SCS Participation of the issuer 252.
  • the TSGS may allow Visa users with the appropriate permissions to define 'SCS Participation' rules, which may identify the account ranges that are participating in SCS for a given market and/or wallet provider.
  • the TSGS may create a new organization type called 'SCS Wallet', which may have status and contact information fields.
  • Each 'SCS Wallet' organization may have a unique identifier called the 'Agent Unique ID," whose value may be edited on a Member Admin screen.
  • a Visa Risk Manager may access the VRM Member Admin screen to remove product configuration options, replace BID/ BIN Billing section with a section called 'Billing', which may provide Under 'Billing' enable radio buttons with the following options: "Billing Start Date" and "Do Not Bill”.
  • the VRM may Click on an "Entitlement” button may take the user to a "Wallet Participation” screen.
  • users may create rules that identify which markets and/or issuers are participating in SCS.
  • the VRM Rule Definition screen may be used as a baseline.
  • the VRM may create a new rule type in VRM called "SCS Participation," which may support the following parameters: User BID, Issuer BIN, Issuer Country Code, Account Range, Product ID, Product Sub Type, and Rules Value Lists, and/or the like.
  • the 'SCS Participation' rules may support all operators, including but not limited to the OR operator.
  • An example of a 'SCS Participation' rule may take a form similar to the following:
  • VRM may select the appropriate account ranges by applying the "SCS Participation' rules, wherein the participating account ranges may be recalculated and published to the Stored Credential Service on a daily basis.
  • each wallet provider may have its own set of "SCS Participation" rules.
  • TSGS may compare the PAN to the list of participating account ranges
  • the TSGS may proceed with 253.
  • the TSGS may proceed with 259 to generate a SCS response
  • the TSGS may allow users with the appropriate0 permissions to create rules that identify which transactions require additional1 authentication.
  • the rules may be created to support markets that have2 mandates for multi-factor authentication.
  • An example of an 'Authentication Required'3 rule may take a form similar to "All debit CNP transactions on cards issued in Brazil”4 require multi factor authentication.
  • the "SCS Wallet" may have access to a new rule5 type in VRM called "Authentication Required.” "Authentication Required' rules may use6 a subset of existing VRM rule parameters, and may add 2-3 new ones (e.g. Agent Unique7 ID may be a new rule parameter).
  • SCS authentication may8 include a 'Processing Option' including 'Require Authentication,' and/or the like.
  • the established authentication rule may be published to the TSGS0 within 15 minutes. 1 [0057]
  • the TSGS may apply 'Authentication Required'2 rules for incoming transactions to flag any transaction if the PAN requires3 authentication 253. The results of this rule evaluation9 may be populated in the4 SCSResAuthReqdlndfield in the SCSRes message (as further discussed in 259).
  • TSGS may get the SCS status of the submitted6 credential included in the transaction request message, e.g., SCSReq 248.
  • the TSGS7 database may have tables that track the authentication status for each credential.
  • a credential may refer to any of, but not limited to the following elements:9 Customer's Wallet ID (e.g. in the case of V.me, the V.me Global User ID or 'GUID'),0 PAN, device information (may further include multiple fields that may be defined during detailed design), and/or the like.
  • each credential may have any of: Authenticated, Non Authenticated, Suspect, and/or the like.
  • the TSGS may proceed to high risk transaction verification 257. Otherwise, if the SCS status is non-authenticated or suspect, the TSGS may proceed to 259.
  • the credential status verification at 256 may be performed via SCS modules including device matching logic, which may be required to determine a match between the data in the SCSReq message and the previously stored credentials in the TSGS database.
  • device matching logic may verify whether information from the device where a transaction is originated matches with the device information previously stored associated with the user credential (e.g., a registered mobile device for a user's mobile wallet, etc.), as different devices with different device information (e.g. Android vs. iPhone).
  • the device matching logic may use the data in the SCSRes as an input and calculate a percent match between the device information in the message and the device information in the database. If the percent match is above a certain threshold, to be determined during detailed design, the 'Credential" may be considered a match. If the SCSReq data matches multiple 'Credentials', the 'Credential' with the highest match percent rate may be considered as the match result.
  • the credential status verification at 256 may include SCS transaction history verification.
  • the transaction history of the 'credentials may be generated from a series of data including, but not limited to: authorization data, authorization data for all active agent unique ID's may be sent to SCS, and/or the like.
  • the list of fields may include an Agent Unique ID and CAW fields.
  • the authorization data may be sent from a processing network (e.g., VisaNet, etc.) to the TSGS within 3-5 minutes upon request for authorization data history, and the TSGS database may retain 1 year of rolling history for authorization data.
  • the TSGS may generate fraud reports based on the SCS status verification, which may be sent to a processing network hourly.
  • the TSGS database may retain l year of rolling history for fraud reports.
  • a wallet provider may send updates to TSGS when accounts are provisioned to the wallet, and exception data on non-Visa accounts may be sent to TSGS daily.
  • the TSGS database may support authorized access to all data for support and troubleshooting. It may support all necessary security/ encryption requirements.
  • the TSGS may perform fraud matching. For example, when a fraud report is received, the status of the associated 'Credential' in the TSGS database may be updated based on the following logic: first, the fraud report may be matched to the corresponding authorization request; the authorization may then be matched to the corresponding wallet transaction data; the result of this match may provide the Global User ID (GUID), PAN, and Device information used when the fraudulent transaction occurred. If the auth can be matched to a TSGS transaction from step 2, update the status of all 'Credentials' associated with the PAN and/or Device to 'Suspect' (may include multiple wallet).
  • GUID Global User ID
  • PAN Personal Area Network
  • Device information used when the fraudulent transaction occurred.
  • the TSGS may update the status of all 'Credentials' associated with the PAN to 'Suspect'.
  • this fraud matching process may be run hourly, after TSGS receives its new fraud reports.
  • the fraud matching logic may use a new value called the Stored Credential Verification Value (SCW). That value may be available in the SCSRes and in the auth (in most cases).
  • SCW Stored Credential Verification Value
  • the TSGS may perform SCS load request processing for a consumer to load an account into his/her wallet.
  • the digital wallet provider may require the consumer to complete an authentication procedure.
  • the wallet provider may send a SCSLdReq message to TSGS upon consumer adding account/card to wallet, wallet initiating an authentication procedure, and wallet provider sending authorization to the processing network.
  • an SCSLdReq message may be a new message using the 3D Secure protocol. 1 [o o 66]
  • the wallet provider may send a SCS load request
  • TSGS may receive a stored credential service load
  • the TSGS may determine whether the issuer is a participant of SCS 262, which may be similar to 252 in FIGURE 2C. If not, the TSGS may proceed to generate a SCSLoadRes message with an appropriate reason code 264. If yes, the TSGS may continue to determine whether the credentials received already exists in the SCS.
  • the TSGS may receive authorization records from the processing network 265, and update SCS status of the credential 266, and subsequently generate an updated SCSLoadRes message with the appropriate reason code based on the updated information 267.
  • a stored credential service load response message 269 may be generated and returned to the wallet provider, which may take a form similar to the following:
  • SCS may update the status of that 'Credential."
  • SCS may first check if the Market/Issuer is participating in SCS 262. If the Market/Issuer is not participating, SCS may generate SCSLdRes message with 'Not Participating' reason code 264. [ 0071 ] If the Market/Issuer is participating, the SCS may proceed to query the TSGS Status tables to determine if a 'Credential' already exists 263. If the 'Credential' already exists, the SCS may generate SCSLdRes message with 'Already Loaded' reason code 264. If the 'Credential' does not exist, the SCS may generate the SCSLdRes message with 'Load Pending' reason code 264.
  • an issuer may extend an offer to participate in a digital wallet (e.g., V.me, etc.) to a set of banking customers.
  • the offer might appear on the issuer's online banking site. If the banking customer clicks on the offer, he or she may have the opportunity to create his or her digital wallet and/or add an card/account to an existing digital wallet.
  • TSGS may send a SCSLdReq message and TSGS may update the status of that 'Credential' to 'Authenticated.' A 'Credential's' status may be updated to 'Authenticated' when the wallet provider has successfully authenticated a wallet transaction, and the subsequent authorization is approved.
  • TSGS may query all the incoming authorizations that match this
  • the status of the 'Credential' used in the approved authorization may be updated to
  • a 'Credential' may also be updated through a
  • I I process called History Authentication.
  • History Authentication 'Non- 12 Authenticated' 'Credentials' may be updated to 'Authenticated' status if they meet the
  • VRM 20 may be configurable via a screen in VRM that is available to users with the appropriate
  • an 'Authenticated' 'Credential' may be updated to a
  • the TSGS database may retain an audit trail of all status updates for each
  • SCS may send required
  • the TSGS may proceed to the next step based on the SCS status 256:
  • the TSGS may proceed to high risk
  • wallet users with the appropriate
  • 35 permissions may create rules that identify high risk transactions 257.
  • a user, and/or the wallet provider may create a new rule type in Visa Risk Manager called "SCS High Risk," which may be applied to all account ranges participating in TSGS, and may use a subset of existing VRM rule parameters (e.g., may add up to 5 new ones (e.g. Agent Unique ID may be a new rule parameter), etc.).
  • the rules may be applied across all wallet providers or specific rules may be applied for a wallet provider.
  • the rules may support all operators (including OR).
  • an issuer may create the "SCS High Risk" Rules, e.g., a new Product Option called 'Stored Credential Service' on the Member Admin Screen for Issuer organization types.
  • the issuer may add a new column to the Entitlement screen for 'SCS' in order to authorize wallet users with the appropriate permissions to flag the issuer's account ranges that are participating in SCS.
  • account ranges for issuer type organizations that are participating in TSGS may be published to TSGS daily. Issuer organizations with the stored credential product option may have access to the TSGS high risk rule type in the rules admin page.
  • issuer defined TSGS High Risk rules may only be applied to the issuer's participating account ranges; or issuers may only be allowed to identify rules within a defined range of risk scores. In such ways, issuers are allowed to flag certain accounts as 'Step Up Requested' (e.g., 258), or 'Exclude' specific PANs from being evaluated by TSGS high risk rules. Issuer and/or a user may request step up and exclude up to 15 accounts at a time via a VRM GUI or by uploading a file (e.g.
  • transactions may first be evaluated by 'SCS High Risk' Rules - issuers (i.e., issuer's high risk rules). If a transaction is triggered by an issuer's high risk rule, the transaction may not be evaluated by wallet provider's (e.g., Visa, etc.) high risk rules.
  • wallet provider's e.g., Visa, etc.
  • the TSTS may proceed to flag transactions as 'Step Up Requested' 258.
  • TSGS may notify the wallet provider that the 'Credential' has an 'Authenticated' status, but the transaction was flagged as high risk based on 'SCS High Risk' rules OR issuer "Step Up Requested" rule. If the transaction triggers an issuer's high risk rule, the SCSRes may have these values:
  • the internal reason code field may be logged, but not sent to the wallet provider in the SCSRes message. If the transaction triggers Visa's high risk rule, the SCSRes may have these values:
  • the TSGS may proceed to generate a SCS response at 259.
  • an exemplary SCSRes message 249 may includes fields such as:
  • a field such as "POS Entry Mode” may be used to indicate modes of a POS, e.g., all transactions that are participating in TSGS may receive a POS Entry Mode (PEM) of 96, an allowed value for this field.
  • PEM POS Entry Mode
  • the SCSRes messages for participating transactions may generate a SCW (Stored Credential Verification Value). This is a unique identifier that is similar to a CAW generated from a VbV transaction.
  • the SCW may need its own unique usage code to differentiate it from CAW.
  • the SCW may be carried through to the authorization and may be validated in a processing network.
  • the SCW may contain the authentication status of the transaction (ECI) as well as characteristics of the device, as determined by TSGS.
  • the SCS status reason code (external or internal) may be included in the SCSRes message.
  • the database may also return a SCS Status Reason Code for internal use. This reason code may be logged but not be included in the SCSRes message send to the wallet provider. Internal reason codes may provide additional information on what event last impacted the status (e.g. the status of the 'Credential' was set as 'Authenticated' because it was Issuer Provisioned).
  • the allowed values for the reason code fields based on the TSGS status is provided in a similar form as the following:
  • the TSGS may verify TSGS participation and allow users with permissions to define 'SCS Participation' rules which may identify the account ranges that are participating in TSGS for a given market and/or wallet provider.
  • the following table shows some key values based on different transaction flows.
  • Step Up 'Step Up Requested Visa' d' Requested or 'Step Up Requested:
  • TSGS may send PAN, Transaction details and the SCW to the processing network.
  • the TSGS may Send SCSRes to VDNA, e.g., 260.
  • VDNA may be updated with the final disposition of the SCSRes.
  • Reports may be available in VRM (for Visa and Issuers) which includes but is not limited to: activity reports for Visa and issuers (e.g.
  • an environment such as Product Interoperability Testing (PIT) may be available so that wallet providers can test TSGS messages (e.g., SCSReq, SCSRes).
  • PIT Product Interoperability Testing
  • Other 3D secure message changes may include 3-D secure SCSReq/Res and PAReq/Res messages are extended to carry additional information.
  • V.Me via their CyberSource MPI, may be able to support all new extensions to 3DS messages. Additional changes may also be required in order to carry appropriate fields (e.g., Agent Unique ID) into Authorization.
  • TSGS may support the new VEReq/Res extensions in order to support TSGS Advice message processing.
  • SCS may create a new message, SCSAdviceReq, using transaction characteristics of the SCSReq & SCSRes messages.
  • SCS may send a new message, SCSAdviceReq, to the appropriate SCS URL (returned in the VERes).
  • Communication between TSGS and the issuing SCS may be via server-to- server connection (i.e., not via browser redirect like a conventional 3-D Secure PAReq/Res exchange).
  • SCS may receive a new message, SCSAdviceRes, from the Issuer SCS indicating the originating message was received successfully.
  • TSGS may: verify the Acquirer ID value and the presence of a valid TSGS Agent Unique ID value; validate that client certificate's Common Name field corresponds to the presenting client.
  • the common name value and ip address of the presenting server must match.
  • the presenting server IP address must be inclusive of the value of the common name field.
  • the presenting server must have a registered DNS entry that corresponds to the presenting IP address(es).
  • the TSGS Server may perform a DNS lookup on the presenting IP address; the results must match the Fully Qualified Domain Name in the certificate common name field.
  • the TSGS may further validate the client certificate's has not expired, and query the Visa CRL to ensure client certificate has not been revoked. Should any of the above edits fail, the TSGS server may return an appropriate iReqCode to the originating server (i.e., sender of the SCSRequest message). If all edits pass, TSGS may allow the consuming service to establish a connection to the TSGS server.
  • TSGS may log SSL certificate details for all client certificates presented by merchants and all server certificates presented by consuming endpoints.
  • the log may contain: a certificate serial number, a certificate common name field, a certificate subject name, a valid from date, a valid to date, and/or the like.
  • the TSGS may receive a stored credential service advice request message, which may take a form similar to the following: Table 7.
  • Table 7 Example SCS Advice Request Data Structure
  • SCSReqAmount element may contain the value 12345.
  • SCSReqCurrencyExponent may contain the
  • Japanese Yen may contain a value of
  • the TSGS may generate a stored credential service advice response message, which may take a form similar to the following:
  • an error message may take a form similar to the following:
  • a verify enrollment request message may take a form similar to the following:
  • Agent Unique ID Message VE eqAgentUniquelD
  • Advice message TSGS may be sending.
  • a verify enrollment response message may take a form similar to the following:
  • Advice message TSGS may be sending.
  • Advice message TSGS may be sending.
  • a payer authentication request message may take a form similar to the following:
  • Additional TSGS embodiments may further include electronic commerce indicator (ECI) validation in the processing network.
  • ECI electronic commerce indicator
  • a processing network e.g., Visa, etc.
  • a processing network may perform additional checks to ensure that TSGS transactions where Step Up was requested only receive ECI 5's if "step up" processing was successful.
  • Authorizations that meet the following criteria may be evaluated by the processing network :
  • TSGS may compare the CAW data in the authorization to the SCW data stored in the processing network using the following logic:
  • TSGS may compare the CAW data in the authorization to the SCW data stored using the following logic:
  • the TSGS processing rules may specify that TSGS may automatically get downgraded to ECI 7 if:
  • SCW may require a new Usage Code be defined in order to support the different inputs used in the SCW algorithm.
  • TSGS may compare the ECI value in the SCW to the ECI
  • the TSGS may check the TSGS Client ID
  • 14 POS entry mode may be adjusted from a 96 to a 01 (e.g., see 252 in FIGURE 2C and 262
  • the TSGS may require a digital certificate be
  • 19 certificate hierarchy may be established.
  • Client certificates issued to the TSGS may be established.
  • VbV Visa e-Commerce Root.
  • a new sub-CA e-Commerce Credential CA
  • the new e-Commerce Credential CA may be a peer of the e-Commerce Issuing
  • the key length of e-Commerce Credential CA is 2048-bits.
  • 25 Credential CA may issue TSGS client certificates to TSGS consuming services.
  • 26 client certificates may have also have a key length of 2048-bits, with a validity period of
  • 28 revocation may include: PKI key compromises, incorrect certificate information, a
  • FIGURES 2E-2F provide a logic flow diagram illustrating exemplary transaction flows within an alternative embodiment of TSGS.
  • a TSGS transaction may be initiated 271 at a digital wallet, e.g., by selection of an TSGS compliant service such as V.me.
  • a transaction may qualify for TSGS classification if the payment credentials used originate from a trusted repository and have been previously authenticated.
  • the TSGS may be triggered 271 at a variety of scenarios, such as but not limited to user enrollment, user logs into their wallet account, user adds a card, user makes a purchase, merchant submits an auth request, reseller onboard a new merchant, or reseller on boards a new merchant, V.me or Visa on boards a new merchant, merchant or acquirer provides visa with notification of chargeback, V.me fraud analyst or sanction list officer needs to disable a wallet, V.me fraud analyst or sanction list officer needs to re-enable a wallet, and/or the like.
  • the TSGS may assess the fraud risk 272 upon receiving the transaction request, e.g., by calculating a TSGS risk score.
  • TSGS may perform fraud risk assessments via a risk/sanction list, e.g., for the V.me properties (consumer, developer center and merchant control panel) and PlaySpan's legacy business (UPay).
  • TSGS may perform risk checks to address the risks that would negatively impact customers, brand and operations, including account take over (e.g., fraudster gains control of a consumer wallet, developer account, merchant account or UPay wallet, etc.), unauthorized use of payment instrument (e.g., fraudster steals payment info (PAN, address, etc.) and creates a wallet to conduct fraudulent purchases), merchant risk (e.g., TSGS may not enroll merchants that may harm the brand, like merchants in high-risk industries, merchants with poor business practices related to processing of consumer orders, dispute management, etc.; or provide incentives to merchants who may not have the credit worthiness to pay V.me fees, etc.), unauthorized use of MCP (e.g., unauthorized user gains access to the MCP and performs malicious actions such as
  • TSGS may perform government sanction check with regard to merchants. For example, TSGS may need to prevent certain merchants from transacting on the V.me platform (e.g., terrorists, fraudsters, etc.). TSGS may use lists provided by various governments. In one implementation, TSGS may perform a check when a merchant enrolls on the V.me platform, including direct merchants, self-service on-boarded merchants, non-us acquirer reseller merchants, non-acquirer reseller merchants, merchants that are behind psp resellers like digital river (potential requirement), and/or the like.
  • V.me platform including direct merchants, self-service on-boarded merchants, non-us acquirer reseller merchants, non-acquirer reseller merchants, merchants that are behind psp resellers like digital river (potential requirement), and/or the like.
  • risk/sanction list assessments may require access to external (non-V.me/UPay) services, and TSGS may provide access to external components, including device fingerprinting for browser-sessions and mobile applications (e.g., ThreatMetrix for device fingerprinting, etc.), IP address decoding (e.g., MaxMind data, Quova, etc.), account verifications including security code and AVS during card additions and updates, advanced authorization (AA) risk score, age of risk score, compromised account risk condition code (CARCC), compromised event reference ID (CERID), card product information (e.g., product type (credit, debit, prepaid), product subtype or ID (non- reloadable prepaid, etc.), issuing country, issuer, network (Visa, etc.), and/or the like.
  • device fingerprinting for browser-sessions and mobile applications
  • IP address decoding e.g., MaxMind data, Quova, etc.
  • account verifications including security code and AVS during card additions and updates
  • AA advanced authorization
  • An example of sanction list for risk checks may take a form similar to the following:
  • Sanction list Sanction list check Sanction list check Sanction list check Sanction list check batch process (?) (maybe) [00119]
  • TSGS may allow, deny or take some other action. In situations such as enrollment, the action is internal (e.g., Visa is the only consumer of an 'allow' decision). In other situations such as purchase, TSGS will provide information to the merchant (e.g., risk indicators, risk score, reason codes, etc.).
  • An example of sanction list check results may take a form similar to the following:
  • the assessment results may be translatable into a specific user experience, e.g., TSGS providing a certain UI message which will provide meaningful information to a legitimate user, but not provide information to a fraudster which would benefit their future fraudulent attempts such as "For security purposes, you are unable to add or edit payments at this time” versus "You have exceeded the number of payment changes in a 24 hour period, please try again in 6 hours,” etc; or sending an email message in the case of "Sanction List Disabled Wallet,” etc.
  • TSGS providing a certain UI message which will provide meaningful information to a legitimate user, but not provide information to a fraudster which would benefit their future fraudulent attempts such as "For security purposes, you are unable to add or edit payments at this time” versus "You have exceeded the number of payment changes in a 24 hour period, please try again in 6 hours,” etc; or sending an email message in the case of "Sanction List Disabled Wallet,” etc.
  • each SCS-compliant wallet-initiated transaction may include POS Entry Mode (PEM) to indicate whether or not the transaction qualifies for the TSGS classification along with an Electronic Commerce Indicator (ECI) code (05 or 06) confirming authentication status and liability shift.
  • TSGS classified transactions may be coded with the 96 POS Entry Mode (e.g., see FIGURE 2G).
  • the TSGS may generate a transaction request message 274 (e.g., the SCSReq
  • a response message may be
  • the TSGS may generate
  • the SCSRes message indicates the transaction is not authenticated 275b, the TSGS may
  • 9 TSGS may proceed to generate authorization 287. Otherwise, the TSGS may further
  • TSGS may determine whether the transaction was
  • the TSGS may perform mobile
  • the TSGS may obtain verification via SMS
  • the TSGS may update the SCS status to "authenticated" 286 and proceed to
  • the TSGS may terminate the transaction 285
  • the TSGS may invoke a step-up
  • Step-up procedures may apply to consumers, merchants
  • the TSGS may determine additional authentication is required
  • user can address the step-up during the event, e.g., turning off alerts.
  • step-up authentication options may include: static security questions, dynamic security
  • Step-up authentication results may
  • the TSGS may perform procedures similar to that following 275b, e.g., when the SCSRes message indicates the transaction is not authenticated at 275b, to authorize the transaction at 287, or to terminate the transaction 285.
  • the TSGS may provide authentication services while focusing on a positive consumer wallet experience, which may lead to a reduction in shopping cart abandonment during payment, as compared to the traditional dual factor authentication.
  • TSGS may provide additional data elements available for review, TSGS provides robust, real-time authentication which includes not only history but predictive risk assessment.
  • TSGS may capture device related information at the time the cardholder authentication occurs, and subsequently store the information including: PAN, Expiration date, Device details, Mobile # (optional), Date / time, Wallet ID (GUID), Authentication method.
  • V.me may generate a request message to the TSGS data store to determine if the device with PAN has previously been authenticated.
  • TSGS may then send a response message back to V.me with the most recent TSGS status per the classifications.
  • FIGURE 2G provides a table of exemplary status classification within embodiments of the TSGS.
  • the TSGS may generate authorization messages to identify digital wallet transactions (V.me) utilizing TSGS with a new POS entry mode code '96' to indicate a stored credential initiated the transaction.
  • CAW value may be generated by V.me and sent to the issuer in the 0100 or 0200.
  • V.me may be populating the existing AID Agent Unique ID with unique V.me indicator.
  • an 3D secure authentication message may be adopted to define a new message protocol to include device profile information and enhanced risk score calculated (e.g., see 217 in FIGURE 2A).
  • FIGURE 2H provides an exemplary block diagram illustrate alternative
  • a 'stored credential' may be authenticated in multiple ways. For example, a 'stored credential' may be authenticated in multiple ways.
  • a procedure may be performed 291 when 1) new account is loaded, 2) new
  • 6 292 may provision and authenticate consumer via online banking credential (or
  • the TSGS may capture consumer device information.
  • the TSGS may capture consumer device information.
  • the authentication may be performed based on valid history of use 293, e.g., after X days
  • the stored credential may be considered "authenticated.”
  • FIGURE 3 shows a datagraph diagram illustrating examples of
  • UWAR User Wallet Activity Recording
  • a user e.g., a user, e.g., a user
  • 13 301 may provide inputs into a user wallet device or point-of-sale terminal ("device”),
  • the user input may include, but not be limited to: a single tap (e.g., a
  • buttons on a joystick/game console depressing buttons on a joystick/game console, voice commands, single/multi-touch
  • Such physical user input may be representative of the
  • the user may select from the virtual wallet.
  • the user may select from the virtual wallet.
  • FIGURES 15-21 depict various features
  • the device may determine whether the user wallet activity
  • the device may present a wallet activity
  • the user may be able to set (e.g., via privacy control settings), the type, amount, detail, etc. of user wallet activity that may be provided by the device to the server.
  • the device may generate a user wallet activity record, and provide the user wallet activity record to the wallet server.
  • the record may include a batch of user actions aggregated together, and sent as a single message, or the record may include a single user action sent per message.
  • the device may provide the user wallet activity record 314 to a pay gateway server, e.g., 304a, as a HTTP(S) POST message including XML-formatted data, substantially in the form of the example below:
  • the pay gateway server may obtain the user wallet activity record from the device, and may parse the user wallet activity record to extact the data field and their associated values.
  • the pay gateway server may store, e.g., 315, the extracted fields and data values in a pay gateway database, e.g., 304b.
  • the pay gateway server may issue hypertext preprocessor/structured query language ("PHP/SQL") commands to store the data to a database table (such as FIGURE 23, Behavior Data 2319 ⁇ ).
  • PHP/SQL hypertext preprocessor/structured query language
  • An example user wallet activity record store command 315 substantially in the form of PHP/SQL commands, is provided below:
  • VALUES ($userid, time(), $actdata_xml ) " ) ; // add data to table in database
  • FIGURE 4 shows a logic flow diagram illustrating examples of transforming user virtual wallet activity via a User Wallet Activity Recording ("UWAR”) component into stored user wallet activity records.
  • UWAR User Wallet Activity Recording
  • a user may provide inputs, e.g., 401, into a user wallet device or point-of-sale terminal (“device”), representing user actions within a virtual wallet of the user.
  • the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a touch screen interface, keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, Smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch- sensitive display, and/or the like.
  • a single tap e.g., a one-tap mobile app purchasing embodiment
  • a RFID/NFC enabled hardware device e.g., electronic card having multiple accounts, Smartphone, tablet, etc.
  • Such physical user input may be representative of the user's desire to perform an action within the virtual wallet.
  • the user may desire to perform a price check for a product (e.g., by scanning the product's barcode using the user device), snap a QR code, add a product to an electronic shopping cart, request a purchase, select payment options, etc.
  • FIGURES 15-21 depict various features that avirtual wallet application may provide to a user; thus, any of the features described herein, and like features, may be activated by the user, and such user actions may be 1 recorded.
  • the device may identify the user activity, e.g., 402. For example, the device
  • the device may determine whether the user wallet activity should be
  • the device may
  • the device may
  • the wallet activity transmission notification for the user via a display of the device e.g.,
  • the user may be able to set (e.g., via privacy control
  • the device may generate a user wallet activity record
  • the wallet server 14 provide the user wallet activity record to the wallet server, e.g., 407.
  • the wallet server e.g., 407.
  • 15 record may include a batch of user actions aggregated together, and sent as a single
  • the record may include a single user action sent per message.
  • the pay gateway server may obtain the user wallet activity record from is the device, and may parse the user wallet activity record to extract the data field and
  • the pay gateway server may utilize a parser such as
  • the pay gateway server may store,
  • FIGURE 5 shows a datagraph diagram illustrating examples of
  • FDR Fraud Data Recording
  • a user e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g., a user, e.g.,
  • 26 501 may wish to report a fraudulent activity involving the user's virtual wallet.
  • the fraudulent activity may include missing (or unintended additional)
  • the user may provide a fraud report
  • the user input may
  • a single tap e.g., a one-tap mobile app purchasing 1 embodiment
  • a touch screen interface keyboard entry
  • card swipe activating a
  • the client may generate and provide a fraud report form request
  • the client may provide the
  • the pay gateway server may query a database, e.g., 504b, for the fraud
  • report form e.g., 513-514
  • fraud report form e.g., 515
  • the pay gateway server may provide a HTML input form to the client.
  • 17 client may display, e.g., 516, the fraud report form for the user.
  • the fraud report form for the user.
  • the user may provide fraud report form input into the client, e.g., 517,
  • a fraud report data response e.g., 518
  • the pay gateway server may parse the fraud report data response and extract the
  • FIGURES 6A-B shows a logic flow diagram illustrating examples of
  • FIGURE 6A illustrates 25 (“SRA") component into transaction risk assessment data and rules.
  • 26 depicts a 3-dimensional risk parameter plot space, which may be utilized to extract
  • each dot e.g., 605
  • each dot represents an individual instance of a
  • Example parameters may include, without limitation: user type, user ID, geographical region, issuer ID, merchant ID, account type, transaction cost, sales channel, product type, number of products, number of accounts used to pay for the transaction, terminal device type, transaction origination geo-political region, social messaging settings, privacy settings for the transaction, type of transaction (e.g., enrollment, purchase, etc.), in-store/online, prior user wallet activity, prior user purchases, real-time user behavior, recent price scans, etc.
  • type of transaction e.g., enrollment, purchase, etc.
  • in-store/online prior user wallet activity, prior user purchases, real-time user behavior, recent price scans, etc.
  • the risk data points fall into four clusters 6o4a-d.
  • the TSGS may define four risk types - one associated with each of the clusters.
  • the boundary surface equation may serve as a rule to determine whether a transaction falls into a risk type defined by a cluster of risk data points.
  • the number of data points within each cluster may serve as an indicator of the magnitude of risk associated with the risk cluster, e.g., a risk score weight.
  • the TSGS may normalize a risk score weight for a cluster/risk type (e.g., by dividing the number of risk data points in a cluster) by: a total number of risk data points, a total number of transaction (non-risky, as well as risky), a total number of non-risky transactions that would also fall within the boundary surface of the cluster, etc.
  • the boundary surface equations and the risk score weights for each cluster/risk type may be utilized by the TSGS to assess the risk of a current transaction.
  • the TSGS may obtain aggregated fraud (or other forms of risk) data reports for statistical analysis, e.g., 611.
  • the TSGS may select a fraud data report for processing, e.g., 612, and may parse the report to extract the data fields from the report, e.g., 613.
  • the TSGS may resolve the data fields from the fraud report into the parameters of the N-dimensional risk analysis plot parameters being used to plot the fraud reports as data points in the risk analysis, e.g., 614.
  • the TSGS may parse the report to extract the data values for each plot parameters, from the report, e.g., 615.
  • the TSGS may plot a data point reporesenting the fraud report within the N-dimensional risk analysis plot, e.g., 616.
  • the TSGS may plot a data point for each of the fraud reports in the 1 aggregated fraud data reports, see 617.
  • the TSGS may
  • the TSGS may assign a risk type number (e.g., risk type 1,
  • 5 TSGS may identify an equation (e.g., a polynomial equation that results in a least mean
  • the TSGS may identify
  • the TSGS may correlate each of
  • the TSGS may calculate a risk score weight for each risk type (i.e., each risk type).
  • the TSGS may store the boundary surface equations and the risk score weights, as well
  • FIGURE 7 shows a logic flow diagram illustrating examples of
  • the TSGS may obtain a current transaction request for a user associated with a virtual
  • the TSGS may identify all other transactions (current, recent), recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent, recent
  • the TSGS may aggregate the identified
  • the TSGS may also obtain transaction risk assessment rules
  • TSGS may obtain such rules using components such as the example statistical rsk
  • the TSGS may select a transaction risk
  • the TSGS may
  • the TSGS may determine whether the current transaction falls within the boundaries of the surface defining the cluster of risk data points representing transaction risk of a particular type within the N-dimensional risk analysis plot, e.g., 708. If the current transaction falls within the boundary surface of the cluster, e.g., 709, option "Yes,” then it may be susceptible to the same type of transaction risk.
  • the TSGS may assign the risk type number, and risk score weight associated with the transaction risk assessment rule, to the current transaction, e.g., 710.
  • the TSGS may perform such a procedure on the current transaction request for all transaction risk assessment rules, see 711.
  • the TSGS may return the assigned risk types and their associated risk scores (e.g., for graduated security protocol escalation, see, e.g., FIGURE 8B).
  • FIGURES 8A-C show block and logic flow diagrams illustrating examples of transforming transaction risk type and score assessments, security data, and transaction risk allocation offer responses, via Graduated Security Escalation (“GSE”) (see FIGURE 8B) and Transaction Risk Shifting (“TRS”) (see FIGURE 8C) components, into transaction authorization notifications/triggers and transaction denial notifications.
  • GSE Graduated Security Escalation
  • TRS Transaction Risk Shifting
  • Table 16 shows a different amount of risk mitigation for different transaction types of risk with different challenge types, challenge variations under the challenge type, and/or different challenge media.
  • each protocol may be associated with a
  • transaction risk type 804 such as but not limited to user account fraud 804a, merchant
  • each transaction risk challenge 802 and its variations 807 may be
  • 1 security challenge associated with a challenge medium is accorded with a burden level,2 including an intrusiveness indicator 803a (low to high), bandwidth usage 803b (low to3 high), latency 803c (low to high), and/or the like.
  • a burden level 2 including an intrusiveness indicator 803a (low to high), bandwidth usage 803b (low to3 high), latency 803c (low to high), and/or the like.
  • the TSGS employs4 video chat to confirm the user's identity, e.g., via vocal/facial recognition
  • the5 intrusiveness may be high; bandwidth usage may be high; and latency may be high.
  • the intrusiveness may be low with low bandwidth usage, and medium latency.
  • the TSGS may generate a numeric risk mitigation amount for9 each challenge variation associated with a challenge medium: the greater the mitigation0 amount value is, the more secure the transaction may be after TSGS's challenge1 procedures. 2 [ 00145 ]
  • the transaction risk type 804 user account fraud 804a may3 comprise user identity theft (e.g., stolen wallet credentials, stolen credit card, etc.), ip 1 fraud (e.g., stolen mobile wallet device, fake IP address, etc.), account hacking (e.g.,
  • the TSGS may assess such risk type 804a via
  • biometrics challenge type 804a such as, but not limited to requesting the transaction
  • Such fingerprint verification procedure may have a low
  • the transaction risk may be mitigated by 0.65, e.g., the total transaction
  • risk score may be subtracted the risk mitigation amount of 0.65.
  • biometrics challenge including retina scan 807b, voice
  • voice recognition 807c challenge may be applied via phone
  • device 850a e.g., POS/ATM terminals that are equipped with a
  • VoIP 850c 19 speaker, etc.
  • video chat 8sod video chat 8sod
  • audio message 850 ⁇ and/or the like.
  • facial recognition challenge 8o7d may be applied via MMS 8sof,
  • 21 device e.g., a camera equipped at a POS/AMT terminal, etc.
  • video chat 8sod e.g., video chat 8sod
  • SMS 851c eWallet 8sid (e.g., a built-in feature from the electronic wallet to
  • the TSGS may recommend test identity of the
  • 29 type activities 807I e.g., protocols previously used for transaction security challenges in
  • 31 fingerprint 802b e.g., hardware and/or software parameters of the user device that 1 initiates the transaction such as, but not limited to IP address 8o8a, UUID 8o8b, OS
  • 5 verification 802b may be applied via database query 851a, device 850a, and/or the like.
  • the TSGS may challenge the account fraud
  • a password 8o8j via the device (e.g., eWallet, web, POS/ATM, etc. 850a).
  • the device e.g., eWallet, web, POS/ATM, etc. 850a.
  • the TSGS may challenge the account fraud
  • user selected question e.g., favorite food, pet's name, etc.
  • the TSGS may challenge the account fraud via
  • issuer notification 808s e.g., issuer notifies that
  • RSS feeds 8o8t e.g., Fraudwatch
  • RSS feeds for fraud alerts may be obtained from Fraudwatch International
  • transaction risk types may include merchant fraud
  • the TSGS may check the merchant fingerprint 8o2g (e.g.,
  • past transaction record 802I1 e.g., whether the merchant has completed successful
  • Internet alert 8021 e.g., web searches 8iof on whether the merchant is
  • the TSGS may apply such challenges via POS terminal
  • HTTP messages 854 e.g., verifying merchant fingerprint
  • database query e.g.,
  • the TSGS may challenge on the
  • the historical transaction record 802k challenge may include
  • the TSGS may challenge on the
  • the historical transaction record challenge 802I may
  • MCC item category
  • Further example security protocols include, without limitation: obtaining
  • the TSGS may lookup a security protocol stack
  • TSGS has assessed that a received transaction as a risk score of 0.83 (e.g., a 1 teeth whitening product purchase at an online store that the user has never purchased
  • 3 transaction risk threshold is 0.3 (e.g., any transaction with a risk score greater than 0.3
  • the TSGS may challenge the transaction to mitigate the risk.
  • the TSGS may form a query on the protocol stack
  • the TSGS may further form a
  • the TSGS desires a low bandwidth usage level and low latency solution, the biometrics
  • 12 fingerprint challenge 807a may be adopted, e.g., by requesting the user to scan his/her
  • the TSGS may query on a security protocol
  • 16 TSGS may specify a type of transaction risk, and desired burden level parameters (e.g.,
  • FIGURE 8A provides an alternative example security protocol stack table
  • the TSGS may
  • 26 obtain a set of transaction risk types and associated transaction risk scores, e.g., 811.
  • the risk types and scores may be generated by a component such as the
  • the TSGS may select a risk type, risk score pair to attempt to mitigate, e.g., 812.
  • the TSGS may
  • the TSGS may provide an offer to one or more of the 1 entities to assume (a portion of) the risk type associated with the transaction. For example, the TSGS may provide an offer to one or more of the 1 entities to assume (a portion of) the risk type associated with the transaction. For
  • the TSGS may offer a discount, rewards, incentive, bonus, future payout,
  • the TSGS may recalculate the risk score associated with the risk type. For example,
  • the user may be able to bear a risk that the merchant is fraudulent, in exchange for a
  • the merchant may be able to bear the risk that the user is
  • the payment network, issuer, or acquirer may be able to bear such risk.
  • the TSGS may generate transaction risk allocation offers
  • the TSGS may provide the offers and obtain the
  • the TSGS may move on to the next transaction risk to mitigate (see 827).
  • the TSGS may identify entities that can provide security data to
  • a mobile merchant can provide seller digital certificate
  • a user suspected of being fraudulent may be asked to
  • the TSGS may obtain,
  • the TSGS may also obtain the associated security burdens and risk
  • the TSGS may identify the combination of security protocols (and associated entities that may have to engage the security protocols) that poses the minimum burden to a user experience, e.g., 820.
  • the TSGS may seek to minimize: the number of security protocols used, number of entities solicited for security data, security protocol processing time, security protocol processing overhead (e.g., cost, computational complexity), and/or the like. [ 00161 ]
  • the TSGS may generate security data requests for the identified entities, e.g., 821, and obtain security data from the entities, e.g., 822.
  • the TSGS may calculate an updated risk score for the transaction risk type, e.g., 823.
  • the TSGS may utilize a component such as the example Transaction Risk Assessment ("TRA") component of FIGURE 7.
  • the TSGS may compare the updated risk score to the predetermined maximum acceptable threshold risk value for the risk type in the current transaction, and determine whether the risk score has been lowered below the threshold. If the risk has been lowered enough, e.g., 824, option "Yes," the TSGS may move on to the next transaction risk to mitigate, see 827.
  • TRA Transaction Risk Assessment
  • the TSGS may determine whether the number of security data requests, security protocol processing time, transaction authorization attempts, etc. have exceeded a predetermined value, e.g., 825. If the timeout has occurred, the TSGS may generate a transaction denial notification, e.g., 826. Otherwise, the TSGS may iteratively perform the above-mentioned procedure for the risk type, until the risk type is sufficiently mitigated (below the risk threshold), or the transaction is denied (see 813-826).
  • the TSGS may perform such a transaction risk allocation and graduated security protocol escalation procedure for each transaction risk type involved in the current transaction (see 827), until the transaction is either authorized, see 828, or denied, see 827.
  • the TSGS may obtain a set of transaction risk types and associated transaction risk scores, e.g., 831.
  • the risk types and scores may be generated by a component such as the example Transaction Risk Assessment ("TRA") component for FIGURE 7.
  • TRA Transaction Risk Assessment
  • the TSGS may select a risk type, risk score pair to attempt to mitigate, e.g., 832.
  • the TSGS may identify a set of candidate entities (e.g., consumer, merchant, issuer, acquirer, payment network, payment service provider, third-party service provider, etc.) that may be able to assume the risk, e.g., in exchange for consideration.
  • the TSGS may request bids from one or more of the entities to assume (a portion of) the risk type associated with the transaction.
  • the TSGS may request bids for a discount, rewards, incentive, bonus, future payout, reduced transaction fees, etc., in exchange for the entity assuming the risk specified in the bid request. If any of the entities accept to assume (a portion of) the risk type, then the TSGS may recalculate the risk score associated with the risk type.
  • the user may be able to bear a risk that the merchant is fraudulent, in exchange for a discount on the purchase, or for a discount in payment processing fees for the payment network.
  • the merchant may be able to bear the risk that the user is fraudulent, which may result in a refund request by the actual user at a later date.
  • the payment network, issuer, or acquirer may be able to bear such risk.
  • the TSGS may allow one or more entities to provide security data that mitigates one or more risk types associated with the transaction.
  • the entity providing that security data may be exempted from bearing risk associated with that risk type if the transaction were processed, and the risk associated with that risk type may be reallocated among the other entities participating in the transaction.
  • one or more entities may be able to provide authenticating data (e.g., a digital certificate, digital fingerprint data, an MD5 hash authenticating a user login, a device fingerprint, biometric data from the consumer, previously authenticated stored credentials stored in a database of federated profiles of consumers and agreed upon by the entities to the transaction as being sufficient to mitigate a specific type of risk, etc.) and be exempted from risks that the provided data mitigates.
  • authenticating data e.g., a digital certificate, digital fingerprint data, an MD5 hash authenticating a user login, a device fingerprint, biometric data from the consumer, previously authenticated stored credentials stored in a database of federated profiles of consumers and agreed upon by the entities to the transaction as being sufficient to mitigate a specific type of risk, etc.
  • an entity offering security data to mitigate risk may be excluded from obtaining a reward for bearing that risk in the transaction.
  • providing the security data may entitle the entity to obtain a reward for mitigating the risk (e.g., in some embodiments, provided the risk purportedly mitigated by the security data does not manifest itself upon completion of the transaction authorization).
  • the TSGS may obtain an initial allocation of the transaction risk and revenue sharing (e.g., proceeds of the transaction) among the identified entities, e.g., from a database storing predetermined default allocations of risk and revenue among the entities, e.g., 834.
  • the TSGS may generate transaction risk bid requests for the identified entities, e.g., 835.
  • the TSGS may provide the transaction risk bid requests and obtain the responses from the entities, e.g., 836.
  • bids may be of two types. First, an entity may offer to accept the risk associated with the risk type in exchange for a revenue allocation.
  • an entity may offer security data mitigating that risk in exchange for being exempted from that risk type.
  • the TSGS may identify the bid types obtained from the entities, e.g., 837. If any bids are of the first type, see e.g., 838, option "Yes," the TSGS may select the bid requesting the lowest revenue allocation in exchange for accepting the risk associated with the risk type as the winner of the bidding contest, e.g., 839. The TSGS may then continue processing the other risk types (see 849). For example, if the risk associated with the risk type is accepted in its entirety (or to an amount sufficient for the TSGS to continue the transaction), the TSGS may move on to the next transaction risk to mitigate (see 849).
  • the TSGS may select one of the security data offers provided by the entities, e.g., 840.
  • a mobile merchant can provide seller digital certificate credentials to assure the TSGS that the mobile merchant may be trusted in the transaction, and can be traced should any problems arise from the transaction in the future.
  • a user suspected of being fraudulent may be asked to engage in any of the security protocols listed in FIGURE 8A.
  • the TSGS may obtain, from a database, a pre- determined maximum acceptable threshold risk value for the risk type, as well as a list of security protocols, e.g., 841, available that, if completed successfully by the identified entities that can provide security data to mitigate the risk, would sufficiently mitigate the risk to continue transaction processing of the current transaction.
  • the TSGS may generate a security data request for the identified entity, and obtain the security data from the entity, e.g., 841.
  • the TSGS may calculate an updated risk score for the transaction risk type, e.g., 842.
  • the TSGS may utilize a component such as the example Transaction Risk Assessment ("TRA") component of FIGURE 7.
  • TRA Transaction Risk Assessment
  • the TSGS may compare the updated risk score to the predetermined maximum acceptable threshold risk value for the risk type in the current transaction, and determine whether the risk score associated with that risk type has been lowered below the threshold, e.g., 843. If the risk has been lowered enough, e.g., 843, option "Yes," the TSGS may exempt the security-data-offering entity from bearing the risk associated with the risk type, reallocate the risk associated with that risk type among the other remaining entities besides the security-data-offering entity, and move on to the next transaction risk to mitigate as needed, see e.g., 846-849.
  • the TSGS may select another security data offering entity to see if any additional risk shifting need be performed among the entities with respect to the risk type being processed, see 844.
  • the TSGS may perform such risk shifting between the entities until no more entities are available to provide security data to shift the risk associated the transaction risk type to other entities.
  • the TSGS may accordingly reallocate the risk associated with the risk type among the remaining entities, e.g., 845. If the risk associated with the transaction risk type is still greater than a maximum allowable limit, e.g., 846, option "Yes,” the TSGS may determine whether the number of security data requests, security protocol processing time, transaction authorization attempts, etc.
  • the TSGS may generate a transaction denial notification, e.g., 848. Otherwise, the TSGS may iteratively perform the above-mentioned procedure, until each risk type is sufficiently mitigated (below its associated risk threshold) and reallocated among the various entities, or the transaction is denied (see 846-850).
  • the TSGS may perform such a transaction risk allocation and graduated security protocol escalation procedure for each transaction risk type involved in the current transaction (see 849), until the transaction is either authorized, see 850, or denied, see 848.
  • TSGS risk assessment may include rules configuration (e.g., block user's device if they login more than 10 times in 10 minutes). Rule may be applicable to data fields such as but not limited to Event (login result, add card, timestamp, etc.), User profile (username, date of enrollment, time since first transaction, # of addresses on file, source of enrollment, wallet settings like alerts, when users change profile and fields changes like billing or shipping addresses, etc.), User history (successful vs. unsuccessful logins, successful vs.
  • Rules configuration e.g., block user's device if they login more than 10 times in 10 minutes.
  • Rule may be applicable to data fields such as but not limited to Event (login result, add card, timestamp, etc.), User profile (username, date of enrollment, time since first transaction, # of addresses on file, source of enrollment, wallet settings like alerts, when users change profile and fields changes like billing or shipping addresses, etc.), User history (successful vs. unsuccessful logins, successful
  • a rule editor may allow events to have their own rules (enrollment rules vs. login rules, etc.), different rule profiles (Canadian purchase rules, US purchase rules, high risk merchant rules, low-risk (pre-provisioned) consumer rules, etc.), and/or the like. Rules may be nested (if order > $400 and risk score > 80 then decline else if order ⁇ $400 and risk score > 90 then decline, review, etc.). Rules may handle string, number, date values (e.g., later than May 1st 2011), relative date values (e.g., current date vs. enrollment date > 90 days), and use multiple list types (positive, negative, BINs, zip codes, merchants, etc.).
  • Velocity/anomaly rules may include single attribute (e.g., single device ID seen more than xx times in x days), two attribute (e.g., enrollment attempts (attrib 1) from device ID (attrib 2) greater than xx attempts in xx minutes), three attribute (e.g., purchases (attrib 1) from specific customer (attrib 2) at specific merchant (attrib 3) exceeds $xx in xx days), and/or the like.
  • the anomaly rules may further include "NOT" versions of the above.
  • the attribute anomaly rule type may include one primary attribute and one secondary attribute (e.g., specific PAN (primary attribute) is used across more than x wallets (secondary attribute) in x days), multiple primary attributes and one secondary attribute (e.g., rule fires if 1 wallet (1st primary attrib) receives deny (2nd primary attrib) during card addition (3rd primary attrib) on 5+ PANs (secondary attrib)), one primary attribute and multiple secondary attributes, multiple primary attributes and multiple secondary attributes, and "NOT" versions of the above (e.g., rule fires if wallet (primary) has not been used with device (secondary attrib)).
  • PAN primary attribute
  • secondary attribute e.g., specific PAN (primary attribute) is used across more than x wallets (secondary attribute) in x days
  • multiple primary attributes and one secondary attribute e.g., rule fires if 1 wallet (1st primary attrib) receives deny (2nd primary attrib) during card addition (3
  • TSGS may exempt certain events (geography, brand, card type, product id, context, sub context) from velocity/anomaly rules (e.g., excluding issuer updates toward card lockout or don't count non-reloadable prepaid declines toward card lockout, etc.), track velocity by event type (e.g., number of times IP address has been seen for enrollments only, etc.), track velocity/anomalies across multiple event types (e.g., number of times IP address has been seen), and/or the like.
  • velocity/anomaly rules e.g., excluding issuer updates toward card lockout or don't count non-reloadable prepaid declines toward card lockout, etc.
  • track velocity by event type e.g., number of times IP address has been seen for enrollments only, etc.
  • track velocity/anomalies across multiple event types e.g., number of times IP address has been seen
  • velocity/anomaly rules may be configurable by time frame (minutes to multiple days), and velocity/anomaly metrics may be based on count, cumulative dollar amount, or count only if above/below certain dollar amounts.
  • rules may be created based on various states, including device locked out, wallet locked out, wallet disabled for sanction list reasons, wallet disabled for fraud reasons, wallet disabled for fraud/sanction list reasons, wallet in card lockout, user hasn't answered challenge question successfully for particular device, and/or the like.
  • TSGS may further monitor the impact of the rules on declined enrollments, logins, card-add events and transactions, and apply logics to specify the rule impact to the different events of the accounts including: review, deny/reject, disable wallet, monitor, accept.
  • TSGS may further write rules in audit mode to review potential impacts before making those rules impact decisions, and logging of who creates/edits the rules.
  • risk rules on behalf of merchant (e.g., value add services) and other participants, including merchant configurable rules that either stop auth request from being submitted to issuer, or rules that permit a decline and auth reversal post-issuer auth orization, packaged rule sets available by merchant vertical, and/or the like.
  • a set of variables for the rules may include: dollar amount, risk score, and a handful of others.
  • a risk scoring engine provides a complementary approach to rules. For example, it may provide a fine-grained risk assessment based on the zip code risk indices. The risk 1 scoring engine may have access to the same data used by the rules editor. In one
  • TSGS may support different model segments such as by country,
  • truth data may be available to the risk scoring
  • Risk models may be able to connect different
  • wallets e.g., wallet of user "John” was created on the same device as wallet of user
  • Risk engine may have access to historical data for
  • related risk events may be traceable.
  • risk assessment of a transaction or wallet may be linkable to wallet activity
  • 16 TSGS may keep a record for the wallet status, e.g., whether wallet is disabled or in
  • CSR can refer customers to call issuers or merchants.
  • FIGURE 8D provides a logic flow diagram illustrating aspects of
  • 26 855a e.g., merchants, acquirers, issuers, consumers, third party payment gateways,
  • the TSGS may receive a
  • 30 transaction request 860 (e.g., see 211 in FIGURE 2A, etc.), and may generate a risk score
  • the TSGS may load assessment rules 861 (e.g., see Risk Rules table 2 ⁇ 9 ⁇ in FIGURE 23).
  • assessment rules may indicate a maximum tolerable risk threshold (e.g., any transaction having a risk score greater than the maximum threshold may be denied without further mitigation, etc.).
  • the assessment rules may specify other participants' requirements, e.g., transactions directed to Bank of America accounts shall be directed to the issuer to mitigate the risk, transactions from Amazon.com shall be directed to Amazon.com to mitigate the risk, etc.
  • TSGS may configure assessment rules that transactions from newly enrolled merchants (e.g., less than six months, etc.) shall be directed to the merchants to perform transaction risk mitigation so that TSGS may shift transaction risks to the new merchants who may not have established a long term credit history with TSGS.
  • the TSGS may reject the transaction 863. Otherwise, the TSGS may determine whether the risk score is greater than a TSGS tolerable threshold 862b (e.g., 0.75, etc.), which is lower than the maximum tolerable threshold. If yes, the TSGS may not perform the transaction risk mitigation, but may direct the transaction request to other TSGS participants 855a. For example, the TSGS may send mitigation offers to merchants, acquirers, issuers, third party gateways (e.g., CyberSource, etc.), consumers, and/or the like to mitigate the transaction risk 864.
  • a maximum tolerable threshold e.g. 0.95, etc.
  • TSGS may provide a (Secure) Hypertext Transfer Protocol ("HTTP(S)”) POST message including the mitigation offer in the form of data formatted according to the extensible Markup Language (“XML").
  • HTTP(S) Secure Hypertext Transfer Protocol
  • XML extensible Markup Language

Abstract

The TRANSACTION SECURITY GRADUATED SEASONING AND RISK SHIFTING APPARATUSES, METHODS AND SYSTEMS ("TSGS") transform user virtual wallet activity and historical fraud reports via TSGS components into transaction authorization triggers generated pursuant to graduated, transaction risk-appropriate, escalated security protocols. In one implementation, the TSGS receives a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment; processes the current transaction request to identify a transaction risk type associated with the request; calculates a quantitative transaction risk level associated with the transaction risk type; executes on the device a comparative analysis, based on the calculated transaction risk level, to determine the application of a graduated security protocol for processing the current transaction request; and requests the input of a security data via the user interface in accordance with the selected security protocol.

Description

1 TRANSACTION SECURITY GRADUATED SEASONING AND RISK
2 SHIFTING APPARATUSES, METHODS AND SYSTEMS
3 [oooi] This application for letters patent discloses and describes various novel
4 innovations and inventive aspects of TRANSACTION SECURITY GRADUATED
5 SEASONING AND RISK SHIFTING technology (hereinafter "disclosure") and contains
6 material that is subject to copyright, mask work, and/or other intellectual property
7 protection. The respective owners of such intellectual property have no objection to the
8 facsimile reproduction of the disclosure by anyone as it appears in published Patent
9 Office file/records, but otherwise reserve all rights.
10 PRIORITY CLAIM
11 [0002] This application claims priority under Patent Cooperation Treaty and 35
12 USC §119 to United States provisional patent application serial no. 61/563,941 filed
13 November 28, 2011, entitled "WALLET VERIFICATION APPARATUSES, METHODS
14 AND SYSTEMS," attorney docket no. 13US01I20270-179PV, United States provisional
15 patent application serial no. 61/569,371, filed December 12, 2011, entitled "WALLET
16 VERIFICATION APPARATUSES, METHODS AND SYSTEMS," attorney docket no.
17 13US03I 20270-179PV2, and United States provisional patent application serial no. is 61/723,083 filed November 6, 2012, entitled "AUTHENTICATED STORED
19 CREDENTIAL MANAGEMENT APPARATUSES, METHODS AND SYSTEMS," attorney
20 docket no. 324US01I 20270-245PV.
21 [0003] This application is also a continuation-in-part of, and claims priority
22 under Patent Cooperation Treaty and 35 USC §§ 120 and 365 to United States
23 nonprovisional patent application serial no. 13/434,818 filed March 29, 2012, entitled
24 "GRADUATED SECURITY SEASONING APPARATUSES, METHODS AND SYSTEMS,"
25 attorney docket no. 233US01I 20270-230US, which in turn claims priority under 35 USC
26 § 119 to: United States provisional patent application serial no. 61/469,063 filed March 1 29, 2011, entitled "WALLET TRANSACTION AUTHENTICATION APPARATUSES,
2 METHODS AND SYSTEMS," attorney docket no. P-42167PRVI 20270-144PV2; United
3 States provisional patent application serial no. 61/563,941 filed November 28, 2011,
4 entitled "WALLET VERIFICATION APPARATUSES, METHODS AND SYSTEMS,"
5 attorney docket no. 13US01I 20270-179PV; United States provisional patent application
6 serial no. 61/569,371 filed December 12, 2011, entitled "WALLET VERIFICATION
7 APPARATUSES, METHODS AND SYSTEMS," attorney docket no. 13US03120270-
8 179PV2; and United States provisional patent application serial no. 61/566,969 filed
9 December 5, 2011, entitled "DYNAMIC NETWORK ANALYTICS SYSTEM." The entire0 contents of the aforementioned applications are expressly incorporated by reference1 herein. 2 FIELD
3 [ 0004 ] The present innovations generally address apparatuses, methods, and4 systems for electronic security, and more particularly, include TRANSACTION5 SECURITY GRADUATED SEASONING AND RISK SHIFTING APPARATUSES,6 METHODS AND SYSTEMS ("TSGS"). 7 BACKGROUND
8 [ 0005 ] Consumer transactions typically require a customer to select a product9 from a store shelf or website, and then to check the out at a checkout counter or0 webpage. The customer usually has to provide login information to proceed to checkout,1 or enter a 4-digit PIN number to authorize a transaction at checkout. Once payment is2 made and approved, the point-of-sale terminal memorializes the transaction in the3 merchant's computer system, and a receipt is generated indicating the satisfactory4 consummation of the transaction. BRIEF DESCRIPTION OF THE DRAWINGS
[ 0006 ] The accompanying appendices, drawings, figures, images, etc. illustrate various example, non-limiting, inventive aspects, embodiments, and features ("e.g.," or "example(s)") in accordance with the present disclosure: [ 0007] FIGURES lA-C show block diagrams illustrating example aspects of the TSGS; [ 0008 ] FIGURES 2A-2H show diagrams illustrating example TSGS logic flows and component configuration; [ 0009 ] FIGURE 3 shows a datagraph diagram illustrating examples of transforming user virtual wallet activity via a User Wallet Activity Recording ("UWAR") component into stored user wallet activity records;
[ 0010 ] FIGURE 4 shows a logic flow diagram illustrating examples of transforming user virtual wallet activity via a User Wallet Activity Recording ("UWAR") component into stored user wallet activity records;
[ 0011] FIGURE 5 shows a datagraph diagram illustrating examples of transforming user fraud reporting inputs via a Fraud Data Recording ("FDR") component into stored fraud report data records;
[ 0012 ] FIGURES 6A-B shows a logic flow diagram illustrating examples of transforming historical virtual wallet fraud reports via a Statistical Risk Analysis ("SRA") component into transaction risk assessment data and rules;
[ 0013 ] FIGURE 7 shows a logic flow diagram illustrating examples of transforming transaction requests, security inputs, historical wallet activity data, and transaction risk assessment data/rules via a Transaction Risk Assessment ("TRA") component into transaction risk assessment type/score signals; [ 0014] FIGURES 8A-D show block and logic flow diagrams illustrating examples of transforming transaction risk type and score assessments, security data, and transaction risk allocation offer responses, via Graduated Security Escalation ("GSE") and Transaction Risk Shifting ("TRS") components, into transaction authorization notifications/triggers and transaction denial notifications;
[ 0015 ] FIGURE 9 shows a datagraph diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout ("UPC") component into a checkout data display output; [ 0016 ] FIGURE 10 shows a logic flow diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout ("UPC") component into a checkout data display; [ 0017] FIGURES 11A-B show datagraph diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization ("PTA") component into a purchase transaction receipt notification; [ 0018 ] FIGURES 12A-B show logic flow diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization ("PTA") component into a purchase transaction receipt notification; [ 0019 ] FIGURES 13A-B show datagraph diagrams illustrating example aspects of transforming a merchant transaction batch data query via a Purchase Transaction Clearance ("PTC") component into an updated payment ledger record; [ 0020 ] FIGURES 14A-B show logic flow diagrams illustrating example aspects of transforming a merchant transaction batch data query via a Purchase Transaction Clearance ("PTC") component into an updated payment ledger record;
[ 0021] FIGURE 15 shows a user interface diagram illustrating an overview of example features of virtual wallet applications in some embodiments of the TSGS; [ 0022 ] FIGURES 16A-G show user interface diagrams illustrating example features of virtual wallet applications in a shopping mode, in some embodiments of the TSGS;
[ 0023 ] FIGURES 17A-F show user interface diagrams illustrating example features of virtual wallet applications in a payment mode, in some embodiments of the TSGS;
[ 0024] FIGURE 18 shows a user interface diagram illustrating example features of virtual wallet applications, in a history mode, in some embodiments of the TSGS; [ 0025 ] FIGURES 19A-E show user interface diagrams illustrating example features of virtual wallet applications in a snap mode, in some embodiments of the TSGS; [ 0026 ] FIGURE 20 shows a user interface diagram illustrating example features of virtual wallet applications, in an offers mode, in some embodiments of the TSGS;
[ 0027] FIGURES 21A-B show user interface diagrams illustrating example features of virtual wallet applications, in a security and privacy mode, in some embodiments of the TSGS; [ 0028 ] FIGURES 22A-F include example data flows, where the TSGS may be effected, and illustrates various additional advantageous aspects of the TSGS; and [ 0029 ] FIGURE 23 shows a block diagram illustrating example aspects of a TSGS controller. [ 0030 ] The leading number of each reference number within the drawings indicates the figure in which that reference number is introduced and/or detailed. As such, a detailed discussion of reference number 101 would be found and/or introduced in Figure 1. Reference number 201 is introduced in Figure 2, etc.
DETAILED DESCRIPTION TRANSACTION SECURITY GRADUATED SEASONING AND RISK SHIFTING (TSGS)
[ 0031] The TRANSACTION SECURITY GRADUATED SEASONING AND RISK SHIFTING APPARATUSES, METHODS AND SYSTEMS (hereinafter "TSGS") provides a platform for securely storing consumer payment credentials in a trusted repository with the assurance that the credential is both valid and associated with its rightful user. In one embodiment, the TSGS may shift fraud liability from the merchant, which would otherwise have liability for unauthenticated CNP transactions, to the issuer, e.g., via various transaction challenges as further discussed in Table 16. [ 0032 ] For example, digital wallets which are introduced as a mechanism to facilitate ease of payment, particularly when conducting transactions from mobile devices, may provide access to payment/account data that is remotely stored. As such, validating that the correct/authorized consumer is accessing their remotely stored payment data is critical to ensure the safety/soundness of the payment. In one implementation, a first layer of consumer validation to access/use the remote payment information may be a user login (username / password), which may be susceptible to account takeover and unauthorized use. Additional data, such as a consumer's device information obtained during the session, may be used to help further validate that the authorized user is accessing the remote payment data. [ 0033 ] Another type of data obtained from the consumer's device (i.e. laptop, tablet, mobile), e.g., device printing, may enable the merchants to determine if they have "seen" this consumer using this device before. This information can also be used to evaluate the risk of the transaction. For example, say the consumer enters information on the merchant's website that indicates they reside in the U.S., but the consumer's device shows a foreign location and the device is configured to support a non-English language. This could represent a suspicious transaction and the merchant might request additional information to validate the consumer's identity.
[0034] Within implementations, the TSGS may create a new authentication method by obtaining and tracking information about the consumer's device, combining the PAN, user's wallet login and device information to create a unique 'Stored Credential' record. For example, the TSGS may include a multi-factor authentication procedure including authenticating wallet login (e.g., user name and password), the consumer device, and/or the like. In one implementation, once a 'Stored Credential' achieves 'Authenticated' status, future transactions using the same Stored Credential may be considered 'Authenticated' with no additional action required from the consumer (i.e., reducing friction at time of purchase)
[0035] In another embodiment, the TSGS may transform user virtual wallet activity and historical fraud reports, via TSGS components, into transaction authorization triggers generated pursuant to graduated, transaction risk-appropriate, escalated security protocols. FIGURES lA-B show block diagrams illustrating example aspects of the TSGS. With reference to FIGURE lA, in some embodiments, the TSGS may allow a user to engage in a purchase transaction with a merchant using one or more accounts stored in a virtual wallet of the user. For example, the user may download and install a TSGS mobile wallet component on a mobile device (e.g., an Apple iPhone, a BlackBerry, a Google Android, a Samsung Galaxy, etc.) or other portable web-enabled computing device. As another example, a user may be able to access a virtual wallet account from a point-of-sale ("POS") terminal in a merchant store, or on a merchant website. Alternative and/or complementary user interfaces are also contemplated including: desktop applications, plug-ins to existing applications, stand alone mobile applications, web based applications (e.g., applications with web objects/frames, HTML 5 applications/wrappers, web pages, etc.), and/or the like.
[0036] In some embodiments, the TSGS may perform security checks before authorizing a transaction using an account from the user's virtual wallet. For example, the TSGS may assess transaction risks associated with authorizing the transaction to be completed. For example, the TSGS may identify one or more transaction risk types, and associated risk scores to each of the transaction risk types. Examples of risk types include, without limitation: user fraud, merchant fraud, insufficient account funds, product return, television advertisement scams, product recall, account hacks, wire fraud, mail fraud, spyware/malware invading transaction privacy, etc. The TSGS may require specific security protocols to be adopted depending on the transaction risk types. In some embodiments, the TSGS may determine a risk score associated with each risk type, and modify the security protocols followed to authorize the transaction depending on the risk scores. For example, the TSGS may determine a risk score for each risk type based on factors such as, without limitation: the type of the current transaction (e.g., user enrollment into a new request, purchase transaction, modifying user wallet settings, modifying privacy settings, accessing personal information), current user transaction request details, historical (including recent/real-time) user virtual wallet activity, historical fraud reporting data (e.g., including parameters correlated to fraudulent activity), responses to secure authentication requests, etc. [0037] In some embodiments, the TSGS may categorize risks associated with a type of transaction risk into graduated levels. According to the graduated level of the risk type, the TSGS may appropriately escalate (or de-escalate, as the case may be) the security protocol(s) required to mitigate the risk. For example, where a transaction risk type is at a higher risk level, the TSGS may escalate the security protocol required to authorize the transaction to a more secure protocol, which in some scenarios may come with additional attendant burden on the entity (e.g., a user) required to engage in the security protocol. [0038 ] With reference to FIGURE lA, a first tier of (low) risk may only require a security protocol set 1 (103a), which may have a low burden. For example, the protocol may only require a response from a device of the user, without requiring the user to provide any input for the device to generate a response. For example, if a device has to provide its IP address, user intervention may not be required. However, if a transaction risk type 101 (e.g., risk typei (111), risk type 2 (112), risk type 3 (113)), has a higher risk score, then the TSGS may escalate the protocols employed from security protocol set 1 to security protocol set 2 (103b) (which may pose a higher burden to one of the entities involved in the transaction). Similarly, as the transaction risk score for a transaction risk type increases, the TSGS may escalate the security protocol set for the entities involved in the transaction to security protocol set 3 (103c) or security protocol set 4 (103d).
[ o o 39 ] It is to be understood that different transaction risk types may be escalated at different values of risk scores associated with each of the risk types, either dependent on or independent of the escalation of security protocols for any of the other transaction risk types associated with the transaction. For example, the graduated levels for the different transaction risk type may be drawn at different values of transaction risk scores associated with the transaction risk types. Further, it is to be understood that the set of entities engaged in a security protocol associated with one graduate risk level may be the same as, of different from, the set of entities engaged in a different security protocol associated with a different graduated risk level.
[0040] It should be noted that each of the transaction risk types 101 (e.g., user fraud, merchant fraud, insufficient funds, etc.) may be its own independent axis that can result in an N-dimensional security transaction familiarity Cartesian space. Within implementations, historical tracking of the different types of fraud may be aggregated over time, to create plots/curves.
[0041] Similarly, additional dimensional axis may be added with regard to security authentication level and burden 102 by employing any of the columns found in the example security protocols table 801 in FIGURE 8A. For example, Figure lC shows a 3-dimensional space where security authentication acts as the y-axis, security authentication level acts as the x-axis, and familiarity level acts as the z-axis. It should be noted that the curved space along the x-z plane may create surface models connected to the curves of the y-x plane, thereby making surface models showing relationships between security authentication burden 102, transaction risk 101, and familiarity amelioration levels 112. It should further be noted that a first- and or second-level derivative of any point in the surface models may be taken to attain a risk rate level which may be used, when normalized, as a basis for risk amount mitigation weights (e.g., see the "risk mitigation amount" column in Table 16 and FIGURE 8A). For example, second-level derivatives may be taken from a three-dimensional surface model, and similarly (n-i)th level derivatives may be taken from a n-dimensional surface model, in order to generate a risk rate level. As another example, the first-level derivative of any two-dimensional plane projection of a three-dimensional surface (e.g., the x-z, y-z or x-y planes shown in FIUGRE lC) may be utilized to calculate risk mitigation amount. [0042] In some embodiments, the selection of a security protocol may be dependent on the amount of burden (e.g., amount of time, amount of user input, amount of attention that needs to be paid, etc.) imposed on the entity (e.g., a user) engaged in the security protocol. For example, if a risk can be mitigated by either of two sets of protocols, and one set imposes a lesser burden on the entity engaged in the security protocol than the other, then the first set may be chosen in some embodiments. Similarly, in some embodiments, the security protocol that imposes the least burden on a human (e.g., a user) may be chosen, even if it means that the burden imposed on a device (e.g., the user's Smartphone) may be higher. For example, the TSGS may choose security protocols that can mitigate the risk while minimizing the intrusion into the user's experience, or minimizing the amount of attention the user needs to pay to the security protocol. [0043] With reference to FIGURE lB, in some embodiments, the TSGS may determine a transaction risk level 111, of a transaction risk type associated with a transaction request, based on the familiarity 112 that the TSGS has with the parameters of the transaction request. For example, when the TSGS has a low level of familiarity with an originating device (e.g., a Smartphone, desktop computer, point-of-sale terminal), the TSGS may calculate the transaction risk(s) associated with the transaction request as being higher compared to when the TSGS has a higher level of familiarity with the originating device (see curve in FIGURE lB for transaction parameter 1, 116a). Such familiarity-based transaction risk assessment may extend to any parameter of the current transaction request. For example, FIGURE lB shows two curves representing the dependence of the transaction risk level of a transaction risk type associated with the transaction request on the familiarity of the TSGS with the sales channel (e.g., mobile, online, physical store, etc.) utilize for the transaction (see 116b), and the dependence of the transaction risk level of a transaction risk type associated with the transaction request on the familiarity of the TSGS with the geographic location of the originator of the transaction (see 116b). Other parameters to which such familiarity-based transaction risk assessment may extend include, without limitation: user ID; merchant ID; product type; product ID; transaction cost; payment mechanism (e.g., account numbers); geographical location; payment currency; combinations thereof and/or the like. In some embodiments, the TSGS may determine that the familiarity of a transaction parameter is such that the transaction risk contribution of that parameter may be neglected in the calculation of transaction risk. Such a parameters may be determined to be "seasoned" 115, whereas parameters that the TSGS may determine may not (yet) be neglected in the calculation of transaction risk may be considered "unseasoned" 114. In some embodiments, the TSGS may utilize different seasoning thresholds 113 to determine the seasoning of different parameters in the calculation of transaction risk. Further, in various embodiments, the calculation of transaction risk may depend on numerous factors besides the seasoning levels of the parameters of the transaction request. [0044] Accordingly, in some embodiments of the TSGS, authentication of a transaction can be done separately from authorization/payment, in any environment (e.g., electronic commerce, mobile payments, person-to-person, etc.). In some embodiments, authentication may be integrated into the authorization flow, e.g., as illustrated in FIGURE 11A. In some embodiments, consumer credentials as well as device credentials may be evaluated for risk and fraud management. In general, the TSGS may apply graduated authentication and fraud review appropriate to the action being taken and the actual risk of loss or data compromise. The TSGS may utilize non- invasive technologies where possible. Examples of risks that the TSGS may eliminate or mitigate using graduated authentication during scenarios including, without limitation: merchant on-boarding and authentication; merchant transaction processing (e.g., platform review of merchant activity); merchant login, and maintenance; merchant pay- out/deposit changes, user creation etc.; consumer registration; consumer login; consumer maintenance (e.g., updating preferences, reviewing transactions, rewards, etc.); adding cards, shipping address, payment methods, etc.; reviewing transactions; and/or the like. In all such activities, the TSGS may provide gradated, escalatable, initial evaluations and requirements, and may have customized authenticated decision trees applied to them using a variety of data elements including, without limitation: federated IDs; username/account alias; password; IP address; device fingerprint-issuer record comparison; device fingerprint-wallet record comparison; address verification services; identification challenge questions; merchant IP address; merchant device; merchant BIN; merchant card number; merchant-stored shipping address; email address; phone number; CW; and/or the like. In some embodiments of the TSGS, a failure of authentication may result not in a full denial of the transaction, but in an escalation of the challenge presented to the entity taking the action. The risk in such transaction may be assessed using indicators available in data fields including, without limitation: category of action; type of action; user history; merchant history; device intelligence data elements; merchant category; product category; product quantity; product price point; and/or the like. The TSGS may also utilize device fingerprinting data in real-time risk assessment/security protocol graduation for online and/or mobile transactions. Authentication challenges during protocol escalation may include calls to third-party identification services (e.g., Idology, Experian, Accurint, 192.com, Dunn & Bradstreet, etc.). Such third-party calls may be saved for the highest risk events, such as merchant automated underwriting or high risk/high price consumer initiated events.
[ 0045 ] FIGURE 2A shows a block diagram illustrating an example TSGS logic flow and component configuration. In some embodiments, a user, a merchant, a user device, etc. may request the TSGS to authorize a purchase transaction, e.g., 211. For example, the request may take the form of a card authorization request, such as that card authorization request 1116, depicted in the example purchase transaction authorization ("PTA") component of FIGURE 11. The TSGS may obtain historical data on user's activity (including recent or real-time user behavior in the virtual wallet) in the user's (or user-related) virtual wallet from a database, e.g., 212. For example, the TSGS may utilize a component such as the example user wallet activity recording ("UWAR") component of FIGURES 3-4 to generate historical user wallet activity data records that are stored in the database. In some embodiments, the TSGS may also obtain historical virtual wallet fraud data reports, e.g., 213, to inform transaction risk analysis. For example, the TSGS may utilize a component such as the example fraud data recording ("FDR") component of FIGURE 5 to generate historical (virtual wallet) fraud data records that are stored in a database. The TSGS may perform a Statistical Risk Analysis, e.g., 214, on the historical fraud data records to generate transaction risk assessment reference data points, rules, score weights, etc., e.g., 215. For example, the TSGS may utilize a component such as the example Statistical Risk Analysis ("SRA") component of FIGURES 6A-B to generate the transaction risk assessment reference data points, rules, score weights, etc. Using the current transaction request data, the user's historical virtual wallet activity, and historical fraud data-based transaction risk assessment reference data points, rules, score weights, etc., the TSGS may identify a set of transaction risk types associated with the current transaction request, and may calculate a risk score associated with each of the transaction risk types, e.g., 216. For example, the TSGS may utilize a component such as the example transaction risk assessment ("TRA") component of FIGURE 7, to identify a set of transaction risk types associated with the current transaction request, and calculate risk scores associated with each of the transaction risk types. [0046] In some embodiments, the TSGS may attempt to allocate the transaction risks associated with the current transaction request to one or more entities involved in the current transaction (e.g., user, merchant, issuer, acquirer, payment service processor, payment network, etc.). For example, the TSGS may provide an offer to one or more of the entities to assume (a portion of) the risk type associated with the transaction, e.g., 219. For example, the TSGS may offer a discount, rewards, incentive, bonus, future payout, reduced transaction fees, etc., in exchange for the entity assuming the risk specified in the offer. If any of the entities accept the offer to assume (a portion of) the risk type, then the TSGS may recalculate the risk score associated with the risk type. If the risk score is acceptable, see 221, (e.g., lower than a maximum allowable risk threshold value for the risk type for the current transaction), then the TSGS may authorize the transaction (assuming no other transaction risks are present that need to be mitigated). If the risk score is not at an acceptably low level, then the TSGS may select a set of security protocols for the entities involved in the transaction to engage in before authorizing the transaction, e.g., 222. For example, the TSGS may utilize a component such as the example graduated security protocol escalation ("GSPE") and transaction risk shifting ("TRS") components of FIGURES 8A-C, to select a set of security protocols for the entities involved in the transaction to engage in before authorizing the transaction. If there are no security protocols that can be engaged in to mitigate the transaction risks (see 223), the TSGS may deny the transaction, e.g., 225. If, however, there are security protocols that may mitigate the risk if successfully completed, then the TSGS may request the entities involved in the transaction (e.g., user, user device, merchant, merchant device, issuer, acquirer, etc.) to provide security data, e.g., 224, 219. The entities may provide the requested security data, otherwise the TSGS may deny the transaction request. The TSGS may utilize the new security data, in addition to the previously mentioned data, to re-assess the risk(s) involved in the transaction, and if needed, re-apply the above-mentioned procedure until the level of each transaction risk type is reduced to acceptable levels, or the risks are assumed by one of the entities involved in the transaction. Upon obtaining confirmation that the risk types are all at acceptable levels, the TSGS may authorize the transaction for execution, e.g., 226. [0047] FIGURE 2B provides a data flow diagram illustrating transaction flow of the stored credential within embodiments of the TSGS. As shown in FIGURE 2B, a consumer 240 may finalize purchase and confirms payment method, e.g., by submitting a payment request with card selection and purchase item information 231 to the merchant 241. The merchant 241 may provide consumer 240 with options to checkout via a digital wallet, e.g., by presenting a "V.me" checkout button on a checkout page for online shopping 232. In one implementation, the consumer's digital wallet 242 may send authentication request 233 to a stored credential service server (e.g., hosted by a processing network such as VisaNet, etc.) via a new 3-D Secure protocol message 243 to determine whether the stored credential (e.g., consumer wallet-ID/V.me GUID, PAN, consumer device information, etc.) has been previously authenticated. [0048] In one implementation, the TSGS may determine whether the consumer's stored credential is authenticated, and TSGS may perform real-time risk assessment for the transaction (e.g., Visa Dynamic Network Analytics (VDNA), etc.). For example, in one implementation, if the consumer's stored credential is authenticated and the transaction may yield a low risk 244, no additional authentication is needed and the transaction is sent to the digital wallet to process the authorization 235. [0049] In another implementation, if consumer's stored credential is non- authenticated/suspect (e.g., first time consumer device has been used with this PAN, the 1 PAN has been reported as fraud by the issuer) or the transaction is high risk 245, TSGS
2 may send the response to the digital wallet provider, which may proceed to authenticate
3 the consumer via existing 3-D Secure payer authentication protocol 236.
4 [0050] FIGURES 2C-2D provide alternative embodiments of transaction flows for
5 stored credential service (SCS) processing component within embodiments of the TSGS.
6 In one implementation, as shown in FIGURE 2C, the wallet provider may generate a
7 SCS request message wherein a transactions may originate from V.me or another Visa
8 approved 3rd party digital wallet provider such as Google, etc (e.g., see 251). The digital
9 wallet provider may send the required data to a SCS component using a SCS Request
10 (SCSReq) message 248. The SCSReq message may be a new message using the 3D
11 Secure protocol. A SCS Response (SCSRes) message 249 may be created by the SCS
12 component as the response message back to the wallet provider. In one
13 implementation, the SCS messages may be logged (e.g. in CMLS) and saved (e.g. in the
14 TSGS database). For example, in one implementation, an exemplary SCSReq message
15 252 may comprise fields as shown in the following table:
16
Field Name Inclusion DTD Element
Message Version Required SCSReqVersion
(Length - 2, Alphanumeric)
Value Definition
"01" Version number of request
being presented.
SCS Agent Unique ID Required SCSReqAgentUniquelD
(Length - 1-16, Alphanumeric)
Consumer GUID Required SCSReqConsumerGUID
(Length 1- 36, Alphanumeric Special)
Element that uniquely identifies the
consumer to the wallet provider.
Cardholder PAN Required SCSReqPan
(Length - 15-21, Numeric digits)
Card Expiry Date Required SCSReqPanExpiry
(Length - 4, Numeric digits, YYMM)
Transaction Timestamp Required SCSReqTime (Length - 14, Numeric digits,
YYYYMMDDHHMMSS)
Transaction Amount Required SCSReqAmount
(Length - 1-12, Numeric digits)
Purchase amount in minor units of currency
with all punctuation removed.
Example: If the purchase is for USD 123.45,
the SCSReqAmount element may contain the
value 12345.
Currency Code Required SCSReqCurrencyCode
(Length - 3, Numeric digits)
Currency in which Transaction Amount is
expressed.
ISO 4217 three-digit currency code.
Currency Exponent Required SCSReqCurrencyExponent (Length - 1, Numeric digit)
The minor units of currency specified in
ISO 4217.
Example: If the purchase is for USD, the
SCSReqCurrencyExponent may contain the
value of 2; Japanese Yen may contain a value
of
0.
USD Amount Optional SCSReqUSDAmount
(Length - 1-12, Numeric digits,
9999999999v99)
Purchase amount expressed in USD (for
transactions made in other currencies).
Shipping Address Required SCSReqShipAddress
Length Attribute
25 AN Address Line 1
25 AN Address Line 2 25 AN Province, State
3 Country (ISO-3166)
Billing Address Required SCSReqBillAddress
Length Attribute
25 AN Address Line 1
25 AN Address Line 2
25 AN Province, State
3 Country (ISO-3166)
Confirmation email Required SCSReqEmail
(Length - 1-36, Alphanumeric Special)
Email address used for transaction.
Mobile Phone Number Optional SCSReqMobile
(Length - 1-25, Numeric)
Mobile number entered at transaction.
Transaction Attributes Required SCSReqTxnAttributes
Length Attribute
4 AN MCC
1 (Y/N) Expedited Shipping
Requested?
1 (Y/N) New Shipping Address for
Transaction?
1 (Y/N) Purchase includes Pre-Paid
card(s)?
1 (Y/N) Purchase includes Jewelry?
1 (Y/N) Purchase includes
Electronic goods?
1 (Y/N) Anonymous IP Proxy
Detected?
Device Attributes Optional SCSReqDeviceAttributes
Length Attribute
5 AN Browser Language
1 (Y/N) JavaScript enabled?
1 (Y/N) Flash enabled?
1 (Y/N) Cookies enabled?
1 (Y/N) Images enabled?
16 AN ISP
Extension Optional Extension Any data necessary to support requirements
that are not otherwise defined in the SCS eq
message must be carried in an instance of
Message Extension. [ 0051 ] In one implementation, the TSGS may verify SCS Participation of the issuer 252. For example, the TSGS may allow Visa users with the appropriate permissions to define 'SCS Participation' rules, which may identify the account ranges that are participating in SCS for a given market and/or wallet provider. For example, in one implementation, the TSGS may create a new organization type called 'SCS Wallet', which may have status and contact information fields. Each 'SCS Wallet' organization may have a unique identifier called the 'Agent Unique ID," whose value may be edited on a Member Admin screen. [ 0052 ] For example, in one implementation, a Visa Risk Manager (VRM) may access the VRM Member Admin screen to remove product configuration options, replace BID/ BIN Billing section with a section called 'Billing', which may provide Under 'Billing' enable radio buttons with the following options: "Billing Start Date" and "Do Not Bill". In one implementation, the VRM may Click on an "Entitlement" button may take the user to a "Wallet Participation" screen. On this screen, users may create rules that identify which markets and/or issuers are participating in SCS. The VRM Rule Definition screen may be used as a baseline. [ 0053 ] In one implementation, the VRM may create a new rule type in VRM called "SCS Participation," which may support the following parameters: User BID, Issuer BIN, Issuer Country Code, Account Range, Product ID, Product Sub Type, and Rules Value Lists, and/or the like. In one implementation, the 'SCS Participation' rules may support all operators, including but not limited to the OR operator. An example of a 'SCS Participation' rule may take a form similar to the following:
This account participates in TSGS if: Issuer Country Code in (Brazil, Australia) AND USER BID in (11111111)
AND Issuer BIN in Account List 'BINs' [ 0054 ] In one implementation, VRM may select the appropriate account ranges by applying the "SCS Participation' rules, wherein the participating account ranges may be recalculated and published to the Stored Credential Service on a daily basis. In one 1 implementation, each wallet provider may have its own set of "SCS Participation" rules.
2 [0055] In one implementation, upon receiving the SCSReq message from the
3 wallet provider, TSGS may compare the PAN to the list of participating account ranges
4 based on the 'SCS Participation" rule(s). If the PAN is in an account range that is
5 participating in TSGS for a particular wallet provider, the TSGS may proceed with 253.
6 Otherwise, if the PAN is not in an account range that is participating in TSGS for a
7 particular wallet provider, the TSGS may proceed with 259 to generate a SCS response
8 249 indicating status of the issuer (as further discussed at 259).
9 [0056 ] In one implementation, the TSGS may allow users with the appropriate0 permissions to create rules that identify which transactions require additional1 authentication. For example, the rules may be created to support markets that have2 mandates for multi-factor authentication. An example of an 'Authentication Required'3 rule may take a form similar to "All debit CNP transactions on cards issued in Brazil"4 require multi factor authentication. The "SCS Wallet" may have access to a new rule5 type in VRM called "Authentication Required." "Authentication Required' rules may use6 a subset of existing VRM rule parameters, and may add 2-3 new ones (e.g. Agent Unique7 ID may be a new rule parameter). Further implementations of SCS authentication may8 include a 'Processing Option' including 'Require Authentication,' and/or the like. In one9 implementation, the established authentication rule may be published to the TSGS0 within 15 minutes. 1 [0057] In one implementations, the TSGS may apply 'Authentication Required'2 rules for incoming transactions to flag any transaction if the PAN requires3 authentication 253. The results of this rule evaluation9 may be populated in the4 SCSResAuthReqdlndfield in the SCSRes message (as further discussed in 259). 5 [0058 ] In one implementation, TSGS may get the SCS status of the submitted6 credential included in the transaction request message, e.g., SCSReq 248. The TSGS7 database may have tables that track the authentication status for each credential. For8 example, a credential may refer to any of, but not limited to the following elements:9 Customer's Wallet ID (e.g. in the case of V.me, the V.me Global User ID or 'GUID'),0 PAN, device information (may further include multiple fields that may be defined during detailed design), and/or the like. As another example, each credential may have any of: Authenticated, Non Authenticated, Suspect, and/or the like. In one implementation, if the SCS status of the submitted credential is authenticated, the TSGS may proceed to high risk transaction verification 257. Otherwise, if the SCS status is non-authenticated or suspect, the TSGS may proceed to 259.
[0059] In one implementation, the credential status verification at 256 may be performed via SCS modules including device matching logic, which may be required to determine a match between the data in the SCSReq message and the previously stored credentials in the TSGS database. Such device matching logic may verify whether information from the device where a transaction is originated matches with the device information previously stored associated with the user credential (e.g., a registered mobile device for a user's mobile wallet, etc.), as different devices with different device information (e.g. Android vs. iPhone).
[ o o 6 o ] In one implementation, the device matching logic may use the data in the SCSRes as an input and calculate a percent match between the device information in the message and the device information in the database. If the percent match is above a certain threshold, to be determined during detailed design, the 'Credential" may be considered a match. If the SCSReq data matches multiple 'Credentials', the 'Credential' with the highest match percent rate may be considered as the match result.
[0061] In another implementation, the credential status verification at 256 may include SCS transaction history verification. For example, the transaction history of the 'credentials" may be generated from a series of data including, but not limited to: authorization data, authorization data for all active agent unique ID's may be sent to SCS, and/or the like. In one implementation, the list of fields may include an Agent Unique ID and CAW fields. Within implementations, the authorization data may be sent from a processing network (e.g., VisaNet, etc.) to the TSGS within 3-5 minutes upon request for authorization data history, and the TSGS database may retain 1 year of rolling history for authorization data.
[0062] Within implementations, the TSGS may generate fraud reports based on the SCS status verification, which may be sent to a processing network hourly. In one implementation, the TSGS database may retain l year of rolling history for fraud reports.
[ o o 63 ] In one implementation, a wallet provider may send updates to TSGS when accounts are provisioned to the wallet, and exception data on non-Visa accounts may be sent to TSGS daily. The TSGS database may support authorized access to all data for support and troubleshooting. It may support all necessary security/ encryption requirements.
[0064] In one implementation, the TSGS may perform fraud matching. For example, when a fraud report is received, the status of the associated 'Credential' in the TSGS database may be updated based on the following logic: first, the fraud report may be matched to the corresponding authorization request; the authorization may then be matched to the corresponding wallet transaction data; the result of this match may provide the Global User ID (GUID), PAN, and Device information used when the fraudulent transaction occurred. If the auth can be matched to a TSGS transaction from step 2, update the status of all 'Credentials' associated with the PAN and/or Device to 'Suspect' (may include multiple wallet). If the authorization request cannot be matched to a TSGS transaction, the TSGS may update the status of all 'Credentials' associated with the PAN to 'Suspect'. In one implementation, this fraud matching process may be run hourly, after TSGS receives its new fraud reports. For example, in one implementation, the fraud matching logic may use a new value called the Stored Credential Verification Value (SCW). That value may be available in the SCSRes and in the auth (in most cases).
[0065] Within implementations, as shown in one embodiment with reference to FIGURE 2D, the TSGS may perform SCS load request processing for a consumer to load an account into his/her wallet. For example, when a consumer adds an account/card to his or her wallet, the digital wallet provider may require the consumer to complete an authentication procedure. The wallet provider may send a SCSLdReq message to TSGS upon consumer adding account/card to wallet, wallet initiating an authentication procedure, and wallet provider sending authorization to the processing network. In one implementation, an SCSLdReq message may be a new message using the 3D Secure protocol. 1 [o o 66] As shown at FIGURE 2D, the wallet provider may send a SCS load request
2 261 to the SCS component at TSGS. TSGS may receive a stored credential service load
3 request message (e.g., SCSLdReq) 268 from a wallet provider, which may take a form
4 similar to the following:
Table 2. Example SCS Load Request Data Structure
Field Name Inclusion DTD Element
Message Version Required SCSLdReqVersion
(Length - 2, Alphanumeric)
Figure imgf000023_0001
SCS Agent Unique ID Required SCSReqLdAgentUniquelD
(Length - 1-16, Alphanumeric)
Consumer GUID Required SCSLdReqConsumerGUID
(Length - 36+, Alphanumeric)
Element that uniquely identifies the consumer
wallet provider.
Cardholder PAN Required SCSLdReqPan
(Length - 13-19, Numeric digits)
Device Attributes Required SCSLdReqDeviceAttributes
Figure imgf000023_0002
Cardholder Authentication Verification Value (CAW) Required SCSLdReqCAVV
(Length - 28, Alphanumeric)
Value obtained by the wallet provider during the
Verified by Visa authentication process.
Contains a Base64 encoded 20-byte value resulting in a
28-byte result.
Message Extension Optional Extension Any data necessary to support requirements that are
not otherwise defined in the SCSLd eq message must
be carried in an instance of Message Extension. [0067] Within implementations, the TSGS may determine whether the issuer is a participant of SCS 262, which may be similar to 252 in FIGURE 2C. If not, the TSGS may proceed to generate a SCSLoadRes message with an appropriate reason code 264. If yes, the TSGS may continue to determine whether the credentials received already exists in the SCS.
[0068] In another implementation, the TSGS may receive authorization records from the processing network 265, and update SCS status of the credential 266, and subsequently generate an updated SCSLoadRes message with the appropriate reason code based on the updated information 267. [0069] In another implementation, a stored credential service load response message 269 may be generated and returned to the wallet provider, which may take a form similar to the following:
Table 3. Example SCS Load Response Data Structure
Field Name Inclusion DTD Element
Message Version Required SCSLdResVersion
(Length - 2, Alphanumeric)
Value Definition
"01" Version number of response being
returned.
Load Status Required SCSLdResStatus
(Length - 1, Numeric digits)
Current status of record load process in TSGS
database. Defined values are:
Value Definition
s
0 Load pending
1 Load unsuccessful
2 Record loaded successfully
Reason Code Required SCSLdResReasonCode
(Length - 1, Alphanumeric) To be used in conjunction w/ TSGS Load Status.
Defined values as they correlate to TSGS Load Status
are:
Figure imgf000025_0001
Request CAW Required for SCSLdResCAVV
(Length - 28, Alphanumeric) non V.me
wallets
Value passed by the wallet provider in the original
SCSLdReq. Conditional
for V.me
Provided back to the wallet provider as a possible
method of state management.
Invalid Request Data Conditional IReq
Consists of one required and one optional element as
listed below.
Invalid Request Code Conditional IReq.iReqCode (Length - 1-3, Numeric)
Code indicating the problem identified in SCSLd Req.
Invalid Request Detail Optional IReq.iReqDetail
(Length - 0-2048, Alphanumeric)
May provide supporting detail, such as the specific
data elements that caused the Invalid Request Code.
Message Extension Optional Extension
Any data necessary to support requirements that are
not otherwise defined in the SCSRes message must be
carried in an instance of Message Extension.
Issuer Provisioning Indicator Conditional Extension (Length - 1, Alphanumeric)
Y = Issuer Provisioned
N = Not Issuer Provisioned [ 0070 ] When TSGS receives the SCSLdReq message 268, it may update the status of that 'Credential." In one implementation, SCS may first check if the Market/Issuer is participating in SCS 262. If the Market/Issuer is not participating, SCS may generate SCSLdRes message with 'Not Participating' reason code 264. [ 0071 ] If the Market/Issuer is participating, the SCS may proceed to query the TSGS Status tables to determine if a 'Credential' already exists 263. If the 'Credential' already exists, the SCS may generate SCSLdRes message with 'Already Loaded' reason code 264. If the 'Credential' does not exist, the SCS may generate the SCSLdRes message with 'Load Pending' reason code 264.
[ 0072 ] In one implementation, SCS may receive authorization records from a processing network 265, and query incoming authorizations and match them to SCSLdReq messages using the CAW value. For example, if the authorization response code is 'Approved' (the ECI = 5), and the authorization matches a SCSLdReq message, TSGS may update the status of the 'Credential' to 'Authenticated' 266 and generate a SCSLdRes message with 'Load Successful' reason code 267. In another example, if a matching authorization is not received within 48 hours of receiving a SCSLdReq message, TSGS may generate a SCSLdRes response with 'Load Failed' reason code 267. The SCS may send the generated SCSloadRes message including the reason code to approve or reject to the wallet provider 268.
[ 0073 ] Continuing on with 256 at FIGURE 2C, within implementations, an issuer may extend an offer to participate in a digital wallet (e.g., V.me, etc.) to a set of banking customers. The offer might appear on the issuer's online banking site. If the banking customer clicks on the offer, he or she may have the opportunity to create his or her digital wallet and/or add an card/account to an existing digital wallet. [ 0074] Within implementations, when an account is successfully added to a digital wallet via issuer provisioning, TSGS may send a SCSLdReq message and TSGS may update the status of that 'Credential' to 'Authenticated.' A 'Credential's' status may be updated to 'Authenticated' when the wallet provider has successfully authenticated a wallet transaction, and the subsequent authorization is approved. In one 1 implementation, TSGS may query all the incoming authorizations that match this
2 criteria:
3 The auth response code = 00 (approved)
4 The ΡΟΞ Entry Mode = 1 or 96
5 The ECI indicator = 5
6
I [ 0075 ] In one implementation, these authorizations may then be matched to the
8 SCSReq messages to obtain the GUID and device information used for that transaction.
9 The status of the 'Credential' used in the approved authorization may be updated to
10 "Authenticated." In another example, a 'Credential' may also be updated through a
I I process called History Authentication. For History Authentication, 'Non- 12 Authenticated' 'Credentials' may be updated to 'Authenticated' status if they meet the
13 following criteria:
14 At least X wallet transactions of >$Y USD have an approved authorization OR a
15 cumulative value of >$Z USD have approved authorizations
16 AND X days have passed since the above criteria was met with no fraud reported on the
17 PAN or device
18
19 [ 0076 ] The History Authentication updates may occur hourly, and these rules
20 may be configurable via a screen in VRM that is available to users with the appropriate
21 permissions.
22 [ 0077] In another example, an 'Authenticated' 'Credential' may be updated to a
23 'Non-Authenticated' status if it meets the following criteria:
24 X days have passed since the 'Credential' was updated with an 'Authenticated' status
25 AND there have not been any approved wallet transactions since then
26
27 [ 0078 ] The TSGS database may retain an audit trail of all status updates for each
28 'Credential' for a rolling 12 months.
29 [ 0079 ] In one implementation, continuing on with 254, SCS may send required
30 SCSReq data to the VDNA model to obtain a risk score for each transaction 255. The
31 score and reason code(s) from VDNA may be populated in the SCSRes message. In one
32 implementation, the TSGS may proceed to the next step based on the SCS status 256:
33 for example, for 'Authenticated' transactions, the TSGS may proceed to high risk
34 transaction processing 257. In one implementation, wallet users with the appropriate
35 permissions may create rules that identify high risk transactions 257.
36 [ 00 80 ] With reference to 257, for example, a user, and/or the wallet provider (e.g., Visa V.me, etc.) may create a new rule type in Visa Risk Manager called "SCS High Risk," which may be applied to all account ranges participating in TSGS, and may use a subset of existing VRM rule parameters (e.g., may add up to 5 new ones (e.g. Agent Unique ID may be a new rule parameter), etc.). For example, the rules may be applied across all wallet providers or specific rules may be applied for a wallet provider. As another example, the rules may support all operators (including OR). [ 0081 ] With reference to 257, as another example, an issuer may create the "SCS High Risk" Rules, e.g., a new Product Option called 'Stored Credential Service' on the Member Admin Screen for Issuer organization types. In one implementation, the issuer may add a new column to the Entitlement screen for 'SCS' in order to authorize wallet users with the appropriate permissions to flag the issuer's account ranges that are participating in SCS. Within implementations, account ranges for issuer type organizations that are participating in TSGS may be published to TSGS daily. Issuer organizations with the stored credential product option may have access to the TSGS high risk rule type in the rules admin page. This rule type may act the same for issuers as it does for wallet providers except for the following: issuer defined TSGS High Risk rules may only be applied to the issuer's participating account ranges; or issuers may only be allowed to identify rules within a defined range of risk scores. In such ways, issuers are allowed to flag certain accounts as 'Step Up Requested' (e.g., 258), or 'Exclude' specific PANs from being evaluated by TSGS high risk rules. Issuer and/or a user may request step up and exclude up to 15 accounts at a time via a VRM GUI or by uploading a file (e.g. up to 5 MB), e.g., request step up / exclude that are entered via the UI may be published to TSGS immediately; request step up / exclude file uploads can be processed with similar response times; and effective timeframes may be enabled for both request step up and exclusions. [ 0082 ] Continuing on with 257, transactions may first be evaluated by 'SCS High Risk' Rules - issuers (i.e., issuer's high risk rules). If a transaction is triggered by an issuer's high risk rule, the transaction may not be evaluated by wallet provider's (e.g., Visa, etc.) high risk rules. If the transaction meets the issuer's or Visa's high risk rule, or meets the PAN is on the issuer step up requested list, the TSTS may proceed to flag transactions as 'Step Up Requested' 258. In one implementation, as part of the SCSRes, TSGS may notify the wallet provider that the 'Credential' has an 'Authenticated' status, but the transaction was flagged as high risk based on 'SCS High Risk' rules OR issuer "Step Up Requested" rule. If the transaction triggers an issuer's high risk rule, the SCSRes may have these values:
SCSReasonCode = 'Step up Requested'
SCSReasonCodelnt field* = 'Step up requested - Issuer'*
[0083] In one implementation, the internal reason code field may be logged, but not sent to the wallet provider in the SCSRes message. If the transaction triggers Visa's high risk rule, the SCSRes may have these values:
SCSReasonCode = 'Step up Requested'
SCSReasonCodelnt field* = 'Step up requested - Visa'
[ o o 84 ] In another implementation, if the transaction does not meet the issuer's or Visa's high risk rule criteria, Or the PAN is on the issuer's exclude list, the TSGS may proceed to generate a SCS response at 259.
[0085] For example, an exemplary SCSRes message 249 may includes fields such as:
Table 4. Example Data Structure of SCSRes Messages
Field Name Inclusion DTD Element
Message Version Required SCSResVersion
(Length - 2, Alphanumeric)
Figure imgf000029_0001
Agent Unique ID Required SCSResAgentUniquelD
(Length - 1-16, Alphanumeric
Consumer GUID Required SCSResConsumerGUID
(Length - 1-36, Alphanumeric)
Device Identifier Required SCSResDeviceldentifier
(Length - 1-36, Alphanumeric)
Unique TSGS ID for the device used in the
transaction
Figure imgf000030_0002
Figure imgf000030_0001
(Length - 2, Numeric)
Stored Credential Verification Value (SCVV) Required SCSResSCVV
(Length - 20, Alphanumeric)
Invalid Request Data Conditio IReq
Consists of one required and one optional nal
element as listed below.
Invalid Request Code Required IReq.iReqCode
(Length - 1-3, Numeric)
Code indicating the problem identified in
SCSReq.
Invalid Request Detail Optional IReq.iReqDetail
(Length - 0-2048, Alphanumeric)
May provide supporting detail, such as the
specific data elements that caused the
Invalid Request Code.
Message Extension Optional Extension
Any data necessary to support requirements
that are not otherwise defined in the SCSRes
message must be carried in an instance of
Message Extension.
[0086 ] In one implementation, a field such as "POS Entry Mode" may be used to indicate modes of a POS, e.g., all transactions that are participating in TSGS may receive a POS Entry Mode (PEM) of 96, an allowed value for this field. Additionally, the SCSRes messages for participating transactions may generate a SCW (Stored Credential Verification Value). This is a unique identifier that is similar to a CAW generated from a VbV transaction. The SCW may need its own unique usage code to differentiate it from CAW. The SCW may be carried through to the authorization and may be validated in a processing network. The SCW may contain the authentication status of the transaction (ECI) as well as characteristics of the device, as determined by TSGS.
[0087] In another implementation, the SCS status reason code (external or internal) may be included in the SCSRes message. The database may also return a SCS Status Reason Code for internal use. This reason code may be logged but not be included in the SCSRes message send to the wallet provider. Internal reason codes may provide additional information on what event last impacted the status (e.g. the status of the 'Credential' was set as 'Authenticated' because it was Issuer Provisioned).
[0088] For example, the allowed values for the reason code fields based on the TSGS status is provided in a similar form as the following:
Table . Exam le SCS Reason Code
Figure imgf000032_0001
[0089] In another implementation, the TSGS may verify TSGS participation and allow users with permissions to define 'SCS Participation' rules which may identify the account ranges that are participating in TSGS for a given market and/or wallet provider.
[0090] For example, the following table shows some key values based on different transaction flows.
Table 6. Example SCS Status
STEP SCS Status PEM SCVV SCS Status Reason SCS Status Reason Code
Code (external) (Visa internal)
252 -> 259 N/A N/A N/A Not Participating Not Participating
256 -> 259 'Non 96 Populated N/A N/A
Authenticated
' or 'Suspect'
257 -> 259 'Authenticate 96 Populated N/A N/A
d'
258 -> 261 'Authenticate 96 Populated Step Up 'Step Up Requested: Visa' d' Requested or 'Step Up Requested:
Issuer' [ 0091] If the SCSRes message has a SCSResReasonCode code of "Step up Requested," TSGS may send PAN, Transaction details and the SCW to the processing network. [ 0092 ] In one implementation, the TSGS may Send SCSRes to VDNA, e.g., 260. VDNA may be updated with the final disposition of the SCSRes. [ 0093 ] In further implementations, Reports may be available in VRM (for Visa and Issuers) which includes but is not limited to: activity reports for Visa and issuers (e.g. Counts of SCSReq/ SCSRes messages broken out by status, external/ internal reason codes ECI and VDNA score bands), detailed reports containing all fields from SCSReq/ SCSRes, SCSLdReq/ SCSLdRes messages, reports summarizing the current TSGS status of credentials, audit reports that show all events that updated the status of a credential, effectiveness reports that link SCSReq/ SCSRes messages to fraud and auth data. These reports may appear in the reports section of VRM and be available to users with the appropriate permission. The data required to generate these reports may be available in a single logical repository so they can be joined and reconciled as needed. [ 0094] In further implementations, an environment such as Product Interoperability Testing (PIT) may be available so that wallet providers can test TSGS messages (e.g., SCSReq, SCSRes). [ 0095 ] Other 3D secure message changes may include 3-D secure SCSReq/Res and PAReq/Res messages are extended to carry additional information. For example, V.Me, via their CyberSource MPI, may be able to support all new extensions to 3DS messages. Additional changes may also be required in order to carry appropriate fields (e.g., Agent Unique ID) into Authorization. TSGS may support the new VEReq/Res extensions in order to support TSGS Advice message processing. [ 0096 ] After returning SCSRes to the consuming wallet service, TSGS may provide the issuer with final disposition of the transaction via a new process: SCS may send a 3-D Secure VEReq (w/ SCS-specific message extensions described above) to Visa's VbV Directory Server; SCS may receive a VERes in return; SCS may evaluate if the Issuer's SCS is capable of supporting the subsequent advice message by validating the SCS-specific message extension in the VERes. If supported (e.g., VEResSCSSupportConfirmed=Y): SCS may create a new message, SCSAdviceReq, using transaction characteristics of the SCSReq & SCSRes messages. SCS may send a new message, SCSAdviceReq, to the appropriate SCS URL (returned in the VERes). Important: Communication between TSGS and the issuing SCS may be via server-to- server connection (i.e., not via browser redirect like a conventional 3-D Secure PAReq/Res exchange). SCS may receive a new message, SCSAdviceRes, from the Issuer SCS indicating the originating message was received successfully.
[0097] Upon receiving an SCSReq (Stored Credential Request) message from an TSGS consuming service TSGS may: verify the Acquirer ID value and the presence of a valid TSGS Agent Unique ID value; validate that client certificate's Common Name field corresponds to the presenting client. For an IP address, the common name value and ip address of the presenting server must match. For an IP address range, the presenting server IP address must be inclusive of the value of the common name field. For a fully qualified domain name, the presenting server must have a registered DNS entry that corresponds to the presenting IP address(es). When a fully qualified domain name is contained in the common name, the TSGS Server may perform a DNS lookup on the presenting IP address; the results must match the Fully Qualified Domain Name in the certificate common name field. The TSGS may further validate the client certificate's has not expired, and query the Visa CRL to ensure client certificate has not been revoked. Should any of the above edits fail, the TSGS server may return an appropriate iReqCode to the originating server (i.e., sender of the SCSRequest message). If all edits pass, TSGS may allow the consuming service to establish a connection to the TSGS server.
[0098] In another implementation, TSGS may log SSL certificate details for all client certificates presented by merchants and all server certificates presented by consuming endpoints. The log may contain: a certificate serial number, a certificate common name field, a certificate subject name, a valid from date, a valid to date, and/or the like.
[0099] In another implementation, the TSGS may receive a stored credential service advice request message, which may take a form similar to the following: Table 7. Example SCS Advice Request Data Structure
Field Name Inclusion DTD Element
Message Version Required SCSReqVersion
(Length - 2, Alphanumeric)
Figure imgf000035_0001
Cardholder PAN Required SCSReqPan
(Length - 15-21, Numeric digits)
Card Expiry Date Required SCSReqPanExpiry
(Length - 4, Numeric digits, YYMM)
Transaction Timestamp Required SCSReqTime
(Length - 14, Numeric digits, YYYYMMDDHHM MSS)
Transaction Amount Required SCSReqAmount
(Length - 1-12, Numeric digits)
Purchase amount in minor units of currency with all
punctuation removed.
Example: If the purchase is for USD 123.45, the
SCSReqAmount element may contain the value 12345.
Currency Code Required SCSReqCurrencyCode
(Length - 3, Numeric digits)
Currency in which Transaction Amount is
expressed.
ISO 4217 three-digit currency code.
Currency Exponent Required SCSReqCurrencyExponent (Length - 1, Numeric digit)
The minor units of currency specified in
ISO 4217.
Example: If the purchase is for USD, the
SCSReqCurrencyExponent may contain the
value of 2; Japanese Yen may contain a value of
0.
USD Amount Optional SCSReqUSDAmount (Length - 1-12, Numeric digits, 9999999999v99)
Purchase amount expressed in USD (for transactions
made in other currencies).
Shipping Address Required SCSReqShipAddress
Figure imgf000036_0001
Billing Address Required SCSReqBillAddress
Figure imgf000036_0002
Confirmation email Required SCSReqEmail
(Length - 1-36, Alphanumeric Special)
Email address used for transaction.
Mobile Phone Number Optional SCSReqMobile
(Length - 1-25, Numeric)
Mobile number entered at transaction.
Transaction Attributes Required SCSReqTxnAttributes
Figure imgf000036_0003
Device Attributes Optional SCSReqDeviceAttributes
Length Attribute 5 AN Browser Language
1 (Y/N) JavaScript enabled?
1 (Y/N) Flash enabled?
1 (Y/N) Cookies enabled?
1 (Y/N) Images enabled?
16 AN ISP
Extension Optional Extension
Any data necessary to support requirements that are
not otherwise defined in the SCSAdvice eq message
must be carried in an instance of Message Extension. [o o i o o ] In another implementation, the TSGS may generate a stored credential service advice response message, which may take a form similar to the following:
Figure imgf000037_0001
[ O O l O l] In one implementation, an error message may take a form similar to the following:
Table 9. Example Error Message Data Structure
Field Name Inclusion DTD Element
Message Version Required SCSReqVersion
(Length - 2, Alphanumeric)
Figure imgf000037_0002
Error Code Required SCSErrorCode
(Length - 2, Numeric digits) Value returned may be in the range of 00 to 99.
Figure imgf000038_0001
Error Message Optional SCSErrorMessage
(Length - 0-2048, Alphanumeric)
Error Detail Optional SCSErrorMessage
(Length - 0-2048, Alphanumeric) [00102] In another implementation, a verify enrollment request message may take a form similar to the following:
Table 10. Example SCS Verification Enrollment Request Data Structure
Field Name Inclusion DTD Element
Agent Unique ID Message VE eqAgentUniquelD
(Length - 8, Alphanumeric) Extension
Figure imgf000038_0002
Additional Authentication Reason Code Message VEReqJacuzziAuthReasonCode (Length - 3, Alphanumeric) Extension
This field may contain a value that
indicates if one of the parties to the
transaction requested that it be sent
for further authentication.
The valid additional authentication
reason code values are shown.
SCS Advice Confirm Support Message VEReqSCSAdviceSupport (Length - 2, Alphanumeric) Extension
This field may contain a value that indicates the type of
Advice message TSGS may be sending. Value Definition
01 SCS Advice Update
[00103] In another implementation, a verify enrollment response message may take a form similar to the following:
Table 11. Example Verification Enrollment Response Data Structure
Field Name Inclusion DTD Element
SCS Advice Confirm Support Message VE esSCSAdviceSupport (Length - 2, Alphanumeric) Extension
This field may contain a value that indicates the type of
Advice message TSGS may be sending.
Figure imgf000039_0001
SCS Advice Confirm Support Message VEResSCSSupportConfirmed (Length - 1, Alphanumeric) Extension
This field may contain a value that indicates the type of
Advice message TSGS may be sending.
Figure imgf000039_0002
[00104] In another implementation, a payer authentication request message may take a form similar to the following:
Field Name Inclusion DTD Element
Agent Unique ID Message PAReqAgentUniquelD
(Length - 8, Alphanumeric) Extension
Value Definition a9001 V.me by Visa Europe (Jacuzzi)
xxxxx V.me
yyyyy SCS
Additional Authentication Reason Code Message PAReqAddAuthReasonCode (Length - 2, Alphanumeric) Extension
This field may contain a value that indicates if one of
the parties to the transaction requested that it be sent
for further authentication (step-up)
The valid additional authentication
reason code values are shown.
SCS Additional Authentication Method Message PAReqSCSAddAuthMethod (Length - 2, Alphanumeric) Extension
This field indicates how the wallet authenticated the
transaction. Allowed values include:
Note: This field may be updated and stored throughout
the TSGS transaction flow. [00105] Additional TSGS embodiments may further include electronic commerce indicator (ECI) validation in the processing network. For example, to ensure proper coding of the ECI field in authorizations generated by TSGS wallet providers, a processing network (e.g., Visa, etc.) may perform additional checks to ensure that TSGS transactions where Step Up was requested only receive ECI 5's if "step up" processing was successful. Authorizations that meet the following criteria may be evaluated by the processing network :
PEM = 9 6
AND ECI = 5
[00106] For these transactions, TSGS may compare the CAW data in the authorization to the SCW data stored in the processing network using the following logic:
If the CAW data in the authorization matches the SCVV data in VIP
Then downgrade the ECI to 7 [ 00107] For these transactions, TSGS may compare the CAW data in the authorization to the SCW data stored using the following logic:
if the CAW data in the authorization matches the SCVV data in VIP
Then downgrade the ECI to 7 [ 00108 ] For example, the TSGS processing rules may specify that TSGS may automatically get downgraded to ECI 7 if:
Issuer's ARDF BIN not enrolled in Visa
Acquirer processor not participating in Visa. [ 00109 ] In further implementations, the TSGS may perform SCW verification. For TSGS transactions (where the PEM=96) TSGS may need to verify that the SCW is valid. The validation process for SCW may be similar to that performed for CAWs. Based on the outcome, the CAW Results Code may be updated appropriately. If the SCW format is not valid, the ECI value may be set to 7. Exemplary SCW field values are provided in a form similar to the following:
Table 1 . Exam le SCW Field Values
Figure imgf000041_0001
[ 00110 ] SCW may require a new Usage Code be defined in order to support the different inputs used in the SCW algorithm.
[ 00111 ] In further implementations, TSGS may also be required to distinguish between an SCW and a CAW, as this may determine keys to be used in the validation of the value. All SCWs may use Visa keys (i.e., no Issuer-specific keys may need to be loaded). In one implementation, the TSGS may verify SCW Embedded Fields. For 1 TSGS transactions (where the PEM=96) TSGS may need to verify that the values within
2 the SCW match other part of the authorization message. Based on the outcome, the
3 CAW Results Code (44.13) may be updated appropriately.
4 [ 00112 ] For example, TSGS may compare the ECI value in the SCW to the ECI
5 value (field 126) to ensure they match. If the values do not match then the CAW Results
6 Code (44.13) should be set to 'CSW/ CAW authentication results invalid'. The ECI
7 value should be set to 7. As another example, US acquired authorizations from four
8 MCCS (4829, 5967, 6051, 7995) are downgraded to ECI 7, which may also apply to TSGS
9 transactions for US acquired transactions.
10 [ 00113 ] In further implementations, the TSGS may check the TSGS Client ID
11 (Agent Unique ID (field 126.18)) in the authorization message to confirm the merchant
12 is known, the agent unique ID to confirm whether the entity is TSGS
13 registered/certified. If the entity is either unknown and /or not TSGS registered, the
14 POS entry mode may be adjusted from a 96 to a 01 (e.g., see 252 in FIGURE 2C and 262
15 in FIGURE 2D, etc.).
16 [ 00114 ] In further implementations, the TSGS may require a digital certificate be
17 issued for each wallet provider. This may use the Certificate Authority process used for is VbV as a baseline. Each certificate may have a validity period of ten years. A new
19 certificate hierarchy may be established. Client certificates issued to the TSGS
20 consuming clients may use the same Root CA hierarchy that is currently used in support
21 of VbV (Visa e-Commerce Root). A new sub-CA (e-Commerce Credential CA) under the
22 Visa e-Commerce Root, however, may be required for the specific purpose of supporting
23 the SCS. The new e-Commerce Credential CA may be a peer of the e-Commerce Issuing
24 CA. The key length of e-Commerce Credential CA is 2048-bits. The e-Commerce
25 Credential CA may issue TSGS client certificates to TSGS consuming services. These
26 client certificates may have also have a key length of 2048-bits, with a validity period of
27 10 years. Visa may have discretion to revoke the TSGS certificate - reasons for
28 revocation may include: PKI key compromises, incorrect certificate information, a
29 change in name or business, etc.
30 [ 00115 ] FIGURES 2E-2F provide a logic flow diagram illustrating exemplary transaction flows within an alternative embodiment of TSGS. In one embodiment, at a merchant, A TSGS transaction may be initiated 271 at a digital wallet, e.g., by selection of an TSGS compliant service such as V.me. In one embodiment, a transaction may qualify for TSGS classification if the payment credentials used originate from a trusted repository and have been previously authenticated. In further implementations, the TSGS may be triggered 271 at a variety of scenarios, such as but not limited to user enrollment, user logs into their wallet account, user adds a card, user makes a purchase, merchant submits an auth request, reseller onboard a new merchant, or reseller on boards a new merchant, V.me or Visa on boards a new merchant, merchant or acquirer provides visa with notification of chargeback, V.me fraud analyst or sanction list officer needs to disable a wallet, V.me fraud analyst or sanction list officer needs to re-enable a wallet, and/or the like. [ 00116 ] In one implementation, the TSGS may assess the fraud risk 272 upon receiving the transaction request, e.g., by calculating a TSGS risk score. In one implementation, TSGS may perform fraud risk assessments via a risk/sanction list, e.g., for the V.me properties (consumer, developer center and merchant control panel) and PlaySpan's legacy business (UPay). For example, TSGS may perform risk checks to address the risks that would negatively impact customers, brand and operations, including account take over (e.g., fraudster gains control of a consumer wallet, developer account, merchant account or UPay wallet, etc.), unauthorized use of payment instrument (e.g., fraudster steals payment info (PAN, address, etc.) and creates a wallet to conduct fraudulent purchases), merchant risk (e.g., TSGS may not enroll merchants that may harm the brand, like merchants in high-risk industries, merchants with poor business practices related to processing of consumer orders, dispute management, etc.; or provide incentives to merchants who may not have the credit worthiness to pay V.me fees, etc.), unauthorized use of MCP (e.g., unauthorized user gains access to the MCP and performs malicious actions such as refunding transactions which should not be refunded or exports consumer information (name, address, email address) for malicious purposes or terminated/disgruntled employee accesses their MCP account to take malicious actions), DoS/SPAM (e.g., malicious user creates high number of wallets, floods the forgot password request service, pre-emptively blocks legitimate users from creating wallets and other malicious acts, etc.), reseller partner risk (e.g., all V.me merchant reseller partners must be in good standing with Visa Compliance and Risk programs and be registered, etc.), and/or the like. In further implementations, TSGS may perform sanction list checks to determine if users are permitted to use the system (e.g., not on OFAC list), and/or to comply with requirements from multiple governments.
[ooii7] In another implementation, TSGS may perform government sanction check with regard to merchants. For example, TSGS may need to prevent certain merchants from transacting on the V.me platform (e.g., terrorists, fraudsters, etc.). TSGS may use lists provided by various governments. In one implementation, TSGS may perform a check when a merchant enrolls on the V.me platform, including direct merchants, self-service on-boarded merchants, non-us acquirer reseller merchants, non-acquirer reseller merchants, merchants that are behind psp resellers like digital river (potential requirement), and/or the like. In another implementation, risk/sanction list assessments may require access to external (non-V.me/UPay) services, and TSGS may provide access to external components, including device fingerprinting for browser-sessions and mobile applications (e.g., ThreatMetrix for device fingerprinting, etc.), IP address decoding (e.g., MaxMind data, Quova, etc.), account verifications including security code and AVS during card additions and updates, advanced authorization (AA) risk score, age of risk score, compromised account risk condition code (CARCC), compromised event reference ID (CERID), card product information (e.g., product type (credit, debit, prepaid), product subtype or ID (non- reloadable prepaid, etc.), issuing country, issuer, network (Visa, etc.), and/or the like.
[00118] An example of sanction list for risk checks may take a form similar to the following:
Table 14. Example Sanction Check Application
Trigger Type Applicable Site
Consumer Developer Merchant / MCP PlaySpan
(UPay)
Enrollment Risk check Risk check Risk check, n/a
Sanction list check
Credit check of merchants?
Login Risk check Risk check Risk check n/a
Forgot password Risk check Risk check Risk check n/a
Add/update card Risk check n/a n/a n/a
Purchase Risk check n/a n/a Risk check
Sanction list check Sanction list check
(maybe)
Sanction list Sanction list check Sanction list check Sanction list check Sanction list check batch process (?) (maybe) [00119] Depending on the risk assessment and sanction list check, TSGS may allow, deny or take some other action. In situations such as enrollment, the action is internal (e.g., Visa is the only consumer of an 'allow' decision). In other situations such as purchase, TSGS will provide information to the merchant (e.g., risk indicators, risk score, reason codes, etc.).
[00120] An example of sanction list check results may take a form similar to the following:
Table 15. Example Outcomes of Sanction List Checks
Applicable Site
Consumer Developer Merchant / MCP PlaySpan
(UPay)
Enrollment Allow, Allow, Allow, n/a
Deny, Deny (risk or Deny (risk or
Device lockout sanction list), sanction list),
Device lockout Device lockout
Login Allow, Allow, Allow, n/a
Challenge, Challenge, Challenge,
Deny, Deny, Deny,
Device lockout, Device lockout, Device lockout,
Account lockout Account lockout Account lockout
Forgot password Allow, Allow, Allow, n/a
Device lockout Device lockout Device lockout
Add/update Allow, n/a n/a n/a
card Deny,
Card lockout
Purchase Allow, n/a n/a Allow,
Deny, Deny,
H/M/L risk Disable wallet assessment, Risk score,
Reason codes for
auth requests
processed from
MCP,
Disable wallet
Sanction list Disable wallet, Disable account Disable account, Disable wallet batch process Disable wallet but Disable account Disable account Disable wallet but review but review but review review
[00121] As show in Table 15, for example, under the "Allow" status, users may be permitted to enroll, login (subject to valid credentials), add a card, etc; under the "Deny," the user should not be permitted to take action; under the "Challenge," the user should be prompted with security questions or other step-up authentication. For instance, high risk score/users login different from regular devices/IPs. Under the "Device Lockout," the user should not be permitted to take action because device is currently being blocked; and under "Account Lockout," the user can't login; under "Card Lockout," the user can't add or edit cards for a period of time; under "Disable wallet or account," the user was found on government list (strong match); under "Disable wallet or account but review," the user may be found on government list (partial match) [ 00122 ] In one implementation, the assessment results may be translatable into a specific user experience, e.g., TSGS providing a certain UI message which will provide meaningful information to a legitimate user, but not provide information to a fraudster which would benefit their future fraudulent attempts such as "For security purposes, you are unable to add or edit payments at this time" versus "You have exceeded the number of payment changes in a 24 hour period, please try again in 6 hours," etc; or sending an email message in the case of "Sanction List Disabled Wallet," etc. [ 00123 ] For example, each SCS-compliant wallet-initiated transaction may include POS Entry Mode (PEM) to indicate whether or not the transaction qualifies for the TSGS classification along with an Electronic Commerce Indicator (ECI) code (05 or 06) confirming authentication status and liability shift. TSGS classified transactions may be coded with the 96 POS Entry Mode (e.g., see FIGURE 2G). [ 00124] If the risk score is less than a TSGS threshold (e.g., acceptable risk, etc.) 1 273a, the TSGS may generate a transaction request message 274 (e.g., the SCSReq
2 message 252 in FIGURE 2C, etc.) for the TSGS to process. A response message may be
3 returned, e.g., the SCSRes message 269 in FIGURE 2C. In one implementation, if the
4 SCSRes message indicates the transaction is authenticated 275a, the TSGS may generate
5 authorization for the transaction 287 (in FIGURE 2F). In another implementation, if
6 the SCSRes message indicates the transaction is not authenticated 275b, the TSGS may
7 send a request for the merchant to determine, or determine on behalf of the merchant,
8 whether the risk score is less than the merchant score threshold 276a-b. If yes, the
9 TSGS may proceed to generate authorization 287. Otherwise, the TSGS may further
10 evaluate the risk from store credentials.
11 [ 00125 ] For example, TSGS may determine whether the transaction was
12 originated from a mobile device or not 28ia-b. If yes, the TSGS may perform mobile
13 device fingerprint analysis 282 (such analysis may be carried by a third party vendor,
14 such as Vitrio, Nuance, Telesign, etc.). If not, the TSGS may obtain verification via SMS
15 or email, e.g., prompting an alert message for the consumer to verify the transaction
16 283. Within implementations, if the transaction verifications at 282-283 are successful
17 284a/c, the TSGS may update the SCS status to "authenticated" 286 and proceed to
18 generate authorization 287. Otherwise, the TSGS may terminate the transaction 285
19 when either of the verification at 282/283 fails 284b.
20 [ 00126 ] In another implementation, continuing on with 273b in FIGURE 2E, when
21 the risk score is greater than the TSGS threshold, the TSGS may invoke a step-up
22 authentication procedure 280. Step-up procedures may apply to consumers, merchants
23 and reseller partners. The TSGS may determine additional authentication is required
24 during these events: login, adding or updating a card, purchase, changing account
25 settings (e.g., turning off alerts), user can address the step-up during the event, e.g.,
26 challenge question appears and user answers it, screen appears within lightbox, etc.
27 step-up authentication options may include: static security questions, dynamic security
28 questions, 3D secure, out-of-band mobile authentication (receiving a pass code via
29 phone and entering it in lightbox), and/or the like. Step-up authentication results may
30 be made available to risk service so a complete view is maintained, and any relevant
31 velocity rules may be used and case management can be invoked to evaluate the wallet for fraud and potential disablement. [ 00127] In one implementation, following 280, the TSGS may perform procedures similar to that following 275b, e.g., when the SCSRes message indicates the transaction is not authenticated at 275b, to authorize the transaction at 287, or to terminate the transaction 285. [ 00128 ] In a further implementation, the TSGS may provide authentication services while focusing on a positive consumer wallet experience, which may lead to a reduction in shopping cart abandonment during payment, as compared to the traditional dual factor authentication. Within embodiments, TSGS may provide additional data elements available for review, TSGS provides robust, real-time authentication which includes not only history but predictive risk assessment. [ 00129 ] In one implementation, TSGS may capture device related information at the time the cardholder authentication occurs, and subsequently store the information including: PAN, Expiration date, Device details, Mobile # (optional), Date / time, Wallet ID (GUID), Authentication method. When future transactions occur for a given PAN, V.me may generate a request message to the TSGS data store to determine if the device with PAN has previously been authenticated. TSGS may then send a response message back to V.me with the most recent TSGS status per the classifications. FIGURE 2G provides a table of exemplary status classification within embodiments of the TSGS. [ 00130 ] In one embodiment, the TSGS may generate authorization messages to identify digital wallet transactions (V.me) utilizing TSGS with a new POS entry mode code '96' to indicate a stored credential initiated the transaction. In one implementation, the authorization messages may be authenticated via the device classified in the associated authorization message (0100 or 0200): ECI Value = 05 or 06. In one implementation, CAW value may be generated by V.me and sent to the issuer in the 0100 or 0200. V.me may be populating the existing AID Agent Unique ID with unique V.me indicator. [ 00131 ] In further implementations, an 3D secure authentication message may be adopted to define a new message protocol to include device profile information and enhanced risk score calculated ( e.g., see 217 in FIGURE 2A). 1 [ 00132 ] FIGURE 2H provides an exemplary block diagram illustrate alternative
2 embodiments of the authentication procedure of TSGS within embodiment of SCS.
3 Within embodiments, a 'stored credential' may be authenticated in multiple ways. For
4 example, a procedure may be performed 291 when 1) new account is loaded, 2) new
5 device is used, or 3) transaction is considered high-risk. In another example, an issuer
6 292 may provision and authenticate consumer via online banking credential (or
7 equivalent); the TSGS may capture consumer device information. In another example,
8 the authentication may be performed based on valid history of use 293, e.g., after X days
9 of use with no reported fraud, the stored credential may be considered "authenticated."
10 [ 00133 ] FIGURE 3 shows a datagraph diagram illustrating examples of
11 transforming user virtual wallet activity via a User Wallet Activity Recording ("UWAR")
12 component into stored user wallet activity records. In some embodiments, a user, e.g.,
13 301, may provide inputs into a user wallet device or point-of-sale terminal ("device"),
14 e.g., 302, representing user actions within a virtual wallet of the user. In various
15 implementations, the user input may include, but not be limited to: a single tap (e.g., a
16 one-tap mobile app purchasing embodiment) of a touch screen interface, keyboard
17 entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card
18 having multiple accounts, Smartphone, tablet, etc.) within the user device, mouse clicks,
19 depressing buttons on a joystick/game console, voice commands, single/multi-touch
20 gestures on a touch-sensitive interface, touching user interface elements on a touch-
21 sensitive display, and/or the like. Such physical user input may be representative of the
22 user's desire to perform an action within the virtual wallet. For example, the user may
23 desire to perform a price check for a product (e.g., by scanning the product's barcode
24 using the user device), snap a QR code, add a product to an electronic shopping cart,
25 request a purchase, select payment options, etc. FIGURES 15-21 depict various features
26 that a virtual wallet application may provide to a user; thus, any of the features
27 described herein, and any like features, may be activated by the user, and such user
28 actions may be recorded. The device may determine whether the user wallet activity
29 should be transmitted to a wallet server for recording, e.g., 312. Upon determining that
30 the user action should be recorded at a server, the device may present a wallet activity
31 transmission notification, e.g., 313, to the user. In some embodiments, the user may be able to set (e.g., via privacy control settings), the type, amount, detail, etc. of user wallet activity that may be provided by the device to the server. The device may generate a user wallet activity record, and provide the user wallet activity record to the wallet server. For example, the record may include a batch of user actions aggregated together, and sent as a single message, or the record may include a single user action sent per message. For example, the device may provide the user wallet activity record 314 to a pay gateway server, e.g., 304a, as a HTTP(S) POST message including XML-formatted data, substantially in the form of the example below:
POST /walletactivityrecord.php HTTP/1.1
Host: www.paygateway.com
Content-Type: Application/XML
Content-Length: 1283
<?XML version = "1.0" encoding = "UTF-8"?>
<activity_record>
<user_ID>j ohn . q. public</user_ID>
<timestamp>2052-ll-12 09 : 33 : 43</timestamp>
<action>
<type>scan</ type>
<target>QR</target>
<detail>
<merchant_params>
<merchant_id>54TBRELF8</merchant_id>
<merchant_name>BARNES, Inc . </merchant_name>
<merchant_auth_key>TMN45GER98</merchant_auth_key> </merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN>
<edition>2nd ed. </edition>
<cover>hardbound</ cover>
</product_params>
<quantity>2</quantity>
<unit_cost>$14.46</unit_cost>
<coupon_id>AY34567</ coupon_id>
<social_flag>ON</social_flag>
<social_message>Look what I bought today ! </social_message> <social_networks>facebook twitter</social_networks>
</detail>
</datatypel>
<! --optional parameters-->
<device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial> <device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDID>21343e34-14f4-8jn4-7yfe-124578632134</device_UDID> <device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<OS>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag>
</device_fingerprint> </activity_record>
[o o i34] In some embodiments, the pay gateway server may obtain the user wallet activity record from the device, and may parse the user wallet activity record to extact the data field and their associated values. The pay gateway server may store, e.g., 315, the extracted fields and data values in a pay gateway database, e.g., 304b. For example, the pay gateway server may issue hypertext preprocessor/structured query language ("PHP/SQL") commands to store the data to a database table (such as FIGURE 23, Behavior Data 2319η). An example user wallet activity record store command 315, substantially in the form of PHP/SQL commands, is provided below:
< ?PHP
header (' Content-Type : text/plain');
mysql_connect ( "254.92.185.103", $DBserver, $password) ; // access database server mysql_select ( "TSGS_DB . SQL" ) ; // select database to append
mysql_query (" INSERT INTO BehaviorDataTable (user_id, timestamp, action_data)
VALUES ($userid, time(), $actdata_xml ) " ) ; // add data to table in database
mysql_close ( "TSGS_DB . SQL" ) ; // close connection to database
?>
[00135] FIGURE 4 shows a logic flow diagram illustrating examples of transforming user virtual wallet activity via a User Wallet Activity Recording ("UWAR") component into stored user wallet activity records. In some embodiments, a user may provide inputs, e.g., 401, into a user wallet device or point-of-sale terminal ("device"), representing user actions within a virtual wallet of the user. In various implementations, the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a touch screen interface, keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, Smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch- sensitive display, and/or the like. Such physical user input may be representative of the user's desire to perform an action within the virtual wallet. For example, the user may desire to perform a price check for a product (e.g., by scanning the product's barcode using the user device), snap a QR code, add a product to an electronic shopping cart, request a purchase, select payment options, etc. FIGURES 15-21 depict various features that avirtual wallet application may provide to a user; thus, any of the features described herein, and like features, may be activated by the user, and such user actions may be 1 recorded. The device may identify the user activity, e.g., 402. For example, the device
2 may utilize the gesture-identification features of the operating system of the device, and
3 combine that information with the virtual wallet interface features to identify the user
4 action. The device may determine whether the user wallet activity should be
5 transmitted to a wallet server for recording, e.g., 403. For example, the device may
6 compare the recorded user activity to a list of actions (e.g., in a lookup table) to
7 determine whether the recorded user activity is present in the list. Upon determining
8 that the user action should be recorded at a server (404, option "Yes"), the device may
9 generate a wallet activity transmission notification, e.g., 405, for the user, and present
10 the wallet activity transmission notification for the user via a display of the device, e.g.,
11 406. In some embodiments, the user may be able to set (e.g., via privacy control
12 settings), the type, amount, detail, etc. of user wallet activity that may be provided by
13 the device to the server. The device may generate a user wallet activity record, and
14 provide the user wallet activity record to the wallet server, e.g., 407. For example, the
15 record may include a batch of user actions aggregated together, and sent as a single
16 message, or the record may include a single user action sent per message. In some
17 embodiments, the pay gateway server may obtain the user wallet activity record from is the device, and may parse the user wallet activity record to extract the data field and
19 their associated values. For example, the pay gateway server may utilize a parser such
20 as the example parsers described below in the discussion with reference to FIGURE 23,
21 to extract the data field and their associated values. The pay gateway server may store,
22 e.g., 408-409, the extracted fields and data values in a pay gateway database.
23 [ 00136 ] FIGURE 5 shows a datagraph diagram illustrating examples of
24 transforming user fraud reporting inputs via a Fraud Data Recording ("FDR")
25 component into stored fraud report data records. In some embodiments, a user, e.g.,
26 501, may wish to report a fraudulent activity involving the user's virtual wallet. For
27 example, the fraudulent activity may include missing (or unintended additional)
28 accounts within the user's virtual wallet, missing (or unintended additional)
29 transactions using the virtual wallet account, etc. The user may provide a fraud report
30 request input into a client, e.g., 502. In various implementations, the user input may
31 include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing 1 embodiment) of a touch screen interface, keyboard entry, card swipe, activating a
2 RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts,
3 Smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a
4 joystick/game console, voice commands, single/multi-touch gestures on a touch-
5 sensitive interface, touching user interface elements on a touch-sensitive display, and/or
6 the like. In response, the client may generate and provide a fraud report form request,
7 e.g., 512, to a pay gateway server, e.g., 504a. For example, the client may provide the
8 fraud report form request 512 as a HTTP(S) GET message, substantially in the form of
9 the example below:
10 GET /fraudreportform. html HTTP/ 1 . 1
11 From: jqp@mail.com
12 User-Agent: Firefox/ 1 . 0
13
14 [00137] The pay gateway server may query a database, e.g., 504b, for the fraud
15 report form, e.g., 513-514, and may provide the fraud report form, e.g., 515, to the client.
16 For example, the pay gateway server may provide a HTML input form to the client. The
17 client may display, e.g., 516, the fraud report form for the user. In some
18 implementations, the user may provide fraud report form input into the client, e.g., 517,
19 and the client may generate a fraud report data response, e.g., 518, for the pay gateway
20 server. The pay gateway server may parse the fraud report data response and extract the
21 data fields and their associated values, and generate a record for storage, e.g., 519, in a
22 database.
23 [00138] FIGURES 6A-B shows a logic flow diagram illustrating examples of
24 transforming historical virtual wallet fraud reports via a Statistical Risk Analysis
25 ("SRA") component into transaction risk assessment data and rules. FIGURE 6A
26 depicts a 3-dimensional risk parameter plot space, which may be utilized to extract
27 fraud detection rules using aggregated fraud reports from individual users. For
28 example, in FIGURE 6A, each dot, e.g., 605, represents an individual instance of a
29 fraudulent transaction reported by a user. In this example, the fraudulent transaction
30 may be defined by a sales channel 603 through which it occurred, a transaction cost
31 602, and a merchant ID 601. It is to be understood, however, that any parameter of a
32 current or prior transaction, user action, or event may be utilized as a parameter in an
33 N-dimensional plot, where N may be as large as necessary to accurately represent the fraudulent or otherwise risky transactions. Example parameters may include, without limitation: user type, user ID, geographical region, issuer ID, merchant ID, account type, transaction cost, sales channel, product type, number of products, number of accounts used to pay for the transaction, terminal device type, transaction origination geo-political region, social messaging settings, privacy settings for the transaction, type of transaction (e.g., enrollment, purchase, etc.), in-store/online, prior user wallet activity, prior user purchases, real-time user behavior, recent price scans, etc.
[ooi39] In the example of FIGURE 6A, the risk data points fall into four clusters 6o4a-d. Thus, the TSGS may define four risk types - one associated with each of the clusters. The TSGS may identify a boundary surface in the N-dimensional space (in FIGURE 6A, N=3), and may generate an equation that defines the boundary surface. Thus, the boundary surface equation may serve as a rule to determine whether a transaction falls into a risk type defined by a cluster of risk data points. The number of data points within each cluster may serve as an indicator of the magnitude of risk associated with the risk cluster, e.g., a risk score weight. The TSGS may normalize a risk score weight for a cluster/risk type (e.g., by dividing the number of risk data points in a cluster) by: a total number of risk data points, a total number of transaction (non-risky, as well as risky), a total number of non-risky transactions that would also fall within the boundary surface of the cluster, etc. Thus, the boundary surface equations and the risk score weights for each cluster/risk type may be utilized by the TSGS to assess the risk of a current transaction. [ 00140 ] Accordingly, with reference to FIGURE 6B, in some embodiments, the TSGS may obtain aggregated fraud (or other forms of risk) data reports for statistical analysis, e.g., 611. The TSGS may select a fraud data report for processing, e.g., 612, and may parse the report to extract the data fields from the report, e.g., 613. The TSGS may resolve the data fields from the fraud report into the parameters of the N-dimensional risk analysis plot parameters being used to plot the fraud reports as data points in the risk analysis, e.g., 614. The TSGS may parse the report to extract the data values for each plot parameters, from the report, e.g., 615. Using the data values, the TSGS may plot a data point reporesenting the fraud report within the N-dimensional risk analysis plot, e.g., 616. The TSGS may plot a data point for each of the fraud reports in the 1 aggregated fraud data reports, see 617. Upon completion of the plotting, the TSGS may
2 segment the N-dimensional parameter plot into clusters, e.g., 618, such as the clusters
3 in the plot of FIGURE 6A. The TSGS may assign a risk type number (e.g., risk type 1,
4 risk type 2, etc.) for each cluster in the risk analysis plot, e.g., 619. For each cluster, the
5 TSGS may identify an equation (e.g., a polynomial equation that results in a least mean
6 square-error) that defines the boundary of the cluster, e.g., 620. The TSGS may identify
7 the parameters that appear as variables in the boundary surface equation, e.g., 621, such
8 as, e.g., issuer routing number, user device type, etc. The TSGS may correlate each of
9 the identified parameters to entities involved in the transaction, so that these entities
10 may be requested to either assume the risk of transactions having risk of these types, or
11 request security data from these entities to mitigate the risk of these types of risk, e.g.,
12 622. Also, the TSGS may calculate a risk score weight for each risk type (i.e., each
13 cluster) using, e.g., ratio of the number of data points within cluster to the total number
14 of fraud data points; ratio of the number of data points within cluster to the number of
15 transactions falling within boundary surface (both fraudulent and non-fraudulent); etc.
16 The TSGS may store the boundary surface equations and the risk score weights, as well
17 as the identified entities that can either assume or mitigate the risk type, in a database.
18 [ 00141 ] FIGURE 7 shows a logic flow diagram illustrating examples of
19 transforming transaction requests, security inputs, historical wallet activity data, and
20 transaction risk assessment data/rules via a Transaction Risk Assessment ("TRA")
21 component into transaction risk assessment type/score signals. In some embodiments,
22 the TSGS may obtain a current transaction request for a user associated with a virtual
23 wallet account, e.g., 701. The TSGS may identify all other transactions (current, recent
24 or historical), as well as all user wallet activity (current, recent, or historical), matching
25 the user, or the virtual wallet account, e.g., 702. The TSGS may aggregate the identified
26 data for analysis, e.g., 703. The TSGS may also obtain transaction risk assessment rules
27 for specific risk types and their associated risk score weights, e.g., 704. For example, the
28 TSGS may obtain such rules using components such as the example statistical rsk
29 analysis ("SRA") component of FIGURES 6A-B. The TSGS may select a transaction risk
30 assessment rule for processing, for a particular risk type, e.g., 705. The TSGS may
31 extract the boundary surface equation for the transaction risk assessment rule (see the discussion of FIGURES 6A-B), e.g., 706, and calculate a rule score by apply the aggregated data to the extracted boundary surface equation corresponding to the transaction risk assessment rule, e.g., 707. The TSGS may determine whether the current transaction falls within the boundaries of the surface defining the cluster of risk data points representing transaction risk of a particular type within the N-dimensional risk analysis plot, e.g., 708. If the current transaction falls within the boundary surface of the cluster, e.g., 709, option "Yes," then it may be susceptible to the same type of transaction risk. The TSGS may assign the risk type number, and risk score weight associated with the transaction risk assessment rule, to the current transaction, e.g., 710. The TSGS may perform such a procedure on the current transaction request for all transaction risk assessment rules, see 711. Upon completing the rule processing, the TSGS may return the assigned risk types and their associated risk scores (e.g., for graduated security protocol escalation, see, e.g., FIGURE 8B). [ 00142 ] FIGURES 8A-C show block and logic flow diagrams illustrating examples of transforming transaction risk type and score assessments, security data, and transaction risk allocation offer responses, via Graduated Security Escalation ("GSE") (see FIGURE 8B) and Transaction Risk Shifting ("TRS") (see FIGURE 8C) components, into transaction authorization notifications/triggers and transaction denial notifications. As shown in the exemplary security protocols stack in Table 16. (also reflected in FIGURES 8A), each security protocol may provide a different amount of risk mitigation for different transaction types of risk with different challenge types, challenge variations under the challenge type, and/or different challenge media.
Figure imgf000056_0001
Figure imgf000057_0001
Figure imgf000058_0001
Figure imgf000059_0001
Figure imgf000060_0001
Figure imgf000061_0001
2 [ 00144 ] For example, as shown in Table 16, each protocol may be associated with a
3 transaction risk type 804, such as but not limited to user account fraud 804a, merchant
4 fraud 804b, insufficient funds risk 804c, inadvertent request risk 8o4d, and/or the like.
5 In one implementation, for each transaction risk type 804, a number of challenges types
6 802 (with variations) may be adopted by the TSGS to assess and mitigate the risk. In
7 one implementation, each transaction risk challenge 802 and its variations 807 may be
8 applied via a challenge medium 806, and a burden level 803 to carry out such challenge
9 via a challenge medium is provided, and the risk mitigation amount 805 associated with0 such challenge type is provided by the protocol stack Table 16. In one implementation,1 security challenge associated with a challenge medium is accorded with a burden level,2 including an intrusiveness indicator 803a (low to high), bandwidth usage 803b (low to3 high), latency 803c (low to high), and/or the like. For example, when the TSGS employs4 video chat to confirm the user's identity, e.g., via vocal/facial recognition, the5 intrusiveness may be high; bandwidth usage may be high; and latency may be high. As6 another example, when the TSGS sends a user PIN to the user's cellular phone number7 via SMS, the intrusiveness may be low with low bandwidth usage, and medium latency.8 In one implementation, the TSGS may generate a numeric risk mitigation amount for9 each challenge variation associated with a challenge medium: the greater the mitigation0 amount value is, the more secure the transaction may be after TSGS's challenge1 procedures. 2 [ 00145 ] For example, the transaction risk type 804 user account fraud 804a may3 comprise user identity theft (e.g., stolen wallet credentials, stolen credit card, etc.), ip 1 fraud (e.g., stolen mobile wallet device, fake IP address, etc.), account hacking (e.g.,
2 cracked Visa V.me wallet account, etc.), issuer/merchant account fraud (e.g., stolen
3 issuer online banking account, stolen Amazon account and/or other merchant account,
4 etc.), and/or the like.
5 [o o i46 ] In one implementation, the TSGS may assess such risk type 804a via
6 biometrics challenge type 804a, such as, but not limited to requesting the transaction
7 originator to submit finger print 807a via a finger print scanning device 850a (e.g., at
8 POS/ATM, mobile device, etc.). Such fingerprint verification procedure may have a low
9 intrusiveness 803a level, low bandwidth 803b requirement, and have a low latency
10 803c. In one implementation, if the transaction originator passes the fingerprint
11 challenge 807a, the transaction risk may be mitigated by 0.65, e.g., the total transaction
12 risk score may be subtracted the risk mitigation amount of 0.65. In alternative
13 implementations, other biometrics challenge including retina scan 807b, voice
14 recognition 807c, facial recognition 8o7d, and/or the like may be carried out by the
15 TSGS to mitigate the transaction fraud risk.
16 [00147] For example, voice recognition 807c challenge may be applied via phone
17 850b (e.g., a automatic and/or human conducted call to the account holder's registered
18 phone number, etc.), device 850a (e.g., POS/ATM terminals that are equipped with a
19 speaker, etc.), VoIP 850c, video chat 8sod, audio message 850ε, and/or the like. In
20 another example, facial recognition challenge 8o7d may be applied via MMS 8sof,
21 device (e.g., a camera equipped at a POS/AMT terminal, etc.) 850a, video chat 8sod,
22 SMS 851c, eWallet 8sid (e.g., a built-in feature from the electronic wallet to
23 communicate with an account management representative, etc.), instant message 851ε,
24 email 8sif (e.g., send in photos of the transaction originator, etc.), and/or the like.
25 [00148 ] In another implementation, the TSGS may recommend test identity of the
26 transaction initiator via historical transaction record 802b (e.g., the account holder's
27 past transaction characteristics such as but not limited to spend amount 807I1, item
28 category 8o7f, frequency 8071, geo-location 8o7j, IP address 807k, historical challenge
29 type activities 807I (e.g., protocols previously used for transaction security challenges in
30 previous transactions, etc.), any combination of the above 807m, etc.), device
31 fingerprint 802b (e.g., hardware and/or software parameters of the user device that 1 initiates the transaction such as, but not limited to IP address 8o8a, UUID 8o8b, OS
2 version 8o8c, username 8o8d, browser version 8o8e, fonts/apps configuration stored
3 8o8f, app version number 8o8g, any combination of the above 8o8h, and/or the like),
4 and/or the like. Such historical transaction record challenge 802b and device fingerprint
5 verification 802b may be applied via database query 851a, device 850a, and/or the like.
6 [o o i49] In another implementation, the TSGS may challenge the account fraud
7 804a via user password challenge 8o2d, e.g., by requesting the transaction originator to
8 submit a password 8o8j via the device (e.g., eWallet, web, POS/ATM, etc. 850a).
9 [00150] In another implementation, the TSGS may challenge the account fraud
10 804a via user information challenge 8o2e, e.g., by requesting the transaction originator
11 to provide any of mother's maiden name 808I, birthday 808k, birth city 808m,
12 historical publication information (e.g., "where did you buy your second house?", etc.)
13 8o8n, user selected question (e.g., favorite food, pet's name, etc.) 8080, user selected or
14 provided image 8o8p, and/or the like. Such challenges may be applied to a transaction
15 originator individually, and/or in combination of one another 8o8q, via device, SMS,
16 MMS, eWallet, instant messages, email, phone, VoIP, video chat, web (e.g., online
17 banking site, etc.), and/or the like 852.
ΐδ [ο ο ΐ5ΐ] In another implementation, the TSGS may challenge the account fraud via
19 internet alert 8o2f, e.g., via Internet search 8o8r (e.g., search for negative news with
20 regard to fraud of the account, etc.), issuer notification 808s (e.g., issuer notifies that
21 the account has been fraudulently used, etc.), RSS feeds 8o8t (e.g., Fraudwatch
22 Phishing alerts, etc.) and any combination of the above 8o8u, and/or the like. For
23 example, RSS feeds for fraud alerts may be obtained from Fraudwatch International
24 (www.fraudwatchinternational.com/phishing/), United Nation Fraud Alerts
25 (www.un.org/en/aboutun/fraudalert/), Fraud Blogger
26 (www.fraudblogger.com/rssfeed.asp), other phishing alerts sites, and/or the like. Such
27 challenges may be carried out via Internet, processing network communication 853,
28 and/or the like.
29 [00152] Other examples of transaction risk types may include merchant fraud
30 802b, insufficient funds 802c, inadvertent request 8o2d, and/or the like. For example, 1 for merchant fraud 802b, the TSGS may check the merchant fingerprint 8o2g (e.g.,
2 merchant identify including any of MID 809a, POS ID 809b, URL 809c, server IP 8o9d,
3 etc.), past transaction record 802I1 (e.g., whether the merchant has completed successful
4 non-fraudulent transactions before, transaction volume 810a, the transaction item
5 category 810b, amount 810c, consumer geo-location 8iod, transaction IP address 8ioe,
6 and/or the like), Internet alert 8021 (e.g., web searches 8iof on whether the merchant is
7 fraudulent, historical record showing fraudulent history 8iog, and any combination of
8 the above 8ioh), and/or the like. The TSGS may apply such challenges via POS terminal
9 transmission, HTTP messages 854 (e.g., verifying merchant fingerprint), database query
10 851a, and/or the like.
11 [ 00153 ] As another example, for insufficient funds, the TSGS may challenge on the
12 purchaser's past transaction record 802k to determine the purchaser's credit card debt
13 payment status, purchasing patterns (e.g., frequency, item category, etc.). In one
14 implementation, the historical transaction record 802k challenge may include
15 challenges on credit score 8101, item category (MCC) 8oij, transaction amount 810k,
16 frequency 810I, geo-location 810m, combination of any above 8ion, and/or the like. As
17 another example, for inadvertent request (e.g., the purchaser may inadvertently submit
18 a transaction request by double-clicking, etc.), the TSGS may challenge on the
19 purchaser's past transition records 802I to determine whether the transaction request
20 accords with the purchaser's shopping pattern, whether there is an inadvertent double
21 click, and/or the like. For example, the historical transaction record challenge 802I may
22 further include item category (MCC) 8ioj, amount 810k, geo-location 810m, charge
23 back 8100, fraud/dispute 8iop, refunds 8ioq, repeated purchases 8ior, any
24 combination of the above 810s, and/or the like.
25 [ 00154] Further example security protocols include, without limitation: obtaining
26 a device IP address, obtaining a full device fingerprint, obtaining a user PIN from the
27 user, obtaining a user password, providing a text message challenge, placing an audio
28 call to the user, placing a video call to the user, and/or the like.
29 [ 00155 ] In one implementation, the TSGS may lookup a security protocol stack
30 table (e.g., Table 16, etc.) to adopt risk challenge type to mitigate transaction risk. For
31 example, if TSGS has assessed that a received transaction as a risk score of 0.83 (e.g., a 1 teeth whitening product purchase at an online store that the user has never purchased
2 with, nor has the user ever purchased any teeth whitening products, etc.) but a
3 transaction risk threshold is 0.3 (e.g., any transaction with a risk score greater than 0.3
4 cannot be processed), the TSGS may challenge the transaction to mitigate the risk. In
5 one implementation, if the TSGS has a the TSGS may form a query on the protocol stack
6 table to find out challenge types that are capable of providing a sufficient risk mitigation
7 amount to offset the initial high risk score, e.g., any risk mitigation amount 805 that is
8 greater than 0.83-0.3=0.53. In one implementation, the TSGS may further form a
9 query on the desired intrusiveness level 803a, bandwidth usage level 803b, and/or
10 latency level 803c to narrow down the options. For example, in one implementation, if
11 the TSGS desires a low bandwidth usage level and low latency solution, the biometrics
12 fingerprint challenge 807a may be adopted, e.g., by requesting the user to scan his/her
13 fingers at a POS/ATM terminal, a mobile device, etc.
14 [ 00156 ] In another implementation, the TSGS may query on a security protocol
15 table (e.g., see Table 16, etc.) to determine a security protocol to adopt. For example, the
16 TSGS may specify a type of transaction risk, and desired burden level parameters (e.g.,
17 low intrusiveness, low bandwidth, medium latency, etc.), and in turn obtain a suggested is security protocol (e.g., challenge type and challenge medium, etc.) for the TSGS to
19 perform. As another example, if the TSGS may query for the burden level indicators,
20 and the risk mitigation amount for a specific security protocol based on its challenge
21 type and medium.
22 [ 00157] FIGURE 8A provides an alternative example security protocol stack table
23 801, including the security data description 802, burden level 803, risk type 804, and
24 the risk amount mitigated 805.
25 [ 00158 ] With reference to FIGURE 8B, in some embodiments, the TSGS may
26 obtain a set of transaction risk types and associated transaction risk scores, e.g., 811.
27 For example, the risk types and scores may be generated by a component such as the
28 example Transaction Risk Assessment ("TRA") component for FIGURE 7. The TSGS
29 may select a risk type, risk score pair to attempt to mitigate, e.g., 812. The TSGS may
30 identify a set of candidate entities who may be able to assume the risk, e.g., in exchange
31 for consideration. For example, the TSGS may provide an offer to one or more of the 1 entities to assume (a portion of) the risk type associated with the transaction. For
2 example, the TSGS may offer a discount, rewards, incentive, bonus, future payout,
3 reduced transaction fees, etc., in exchange for the entity assuming the risk specified in
4 the offer. If any of the entities accept the offer to assume (a portion of) the risk type,
5 then the TSGS may recalculate the risk score associated with the risk type. For example,
6 the user may be able to bear a risk that the merchant is fraudulent, in exchange for a
7 discount on the purchase, or for a discount in payment processing fees for the payment
8 network. As another example, the merchant may be able to bear the risk that the user is
9 fraudulent, which may result in a refund request by the actual user at a later date. As an
10 alternative, the payment network, issuer, or acquirer may be able to bear such risk.
11 [ 00159 ] In some embodiments, upon identifying a list of entities who may be able
12 to bear the risk type, e.g., 813, the TSGS may generate transaction risk allocation offers
13 for the identified entities, e.g., 814. The TSGS may provide the offers and obtain the
14 responses from the solicited entities, e.g., 815. If the risk is accepted in its entirety (or to
15 an amount sufficient for the TSGS to continue the transaction), e.g., 816, option "Yes,"
16 the TSGS may move on to the next transaction risk to mitigate (see 827).
17 [ 00160 ] If the transaction risk is not assumed to a sufficient degree (e.g., as
18 compared to a pre-defined maximum acceptable risk threshold value for the risk type in
19 the current transaction, and stored in a database) by any of the solicited entities, e.g.,
20 816, option "No," the TSGS may identify entities that can provide security data to
21 mitigate risk. For example, a mobile merchant can provide seller digital certificate
22 credentials to assure the TSGS that the mobile merchant may be trusted in the
23 transaction, and can be traced should any problems arise from the transaction in the
24 future. As another example, a user suspected of being fraudulent may be asked to
25 engage in any of the security protocols listed in FIGURE 8A. The TSGS may obtain,
26 from a database, a pre-determined maximum acceptable threshold risk value for the risk
27 type, as well as a list of security protocols, e.g., 818, available that, if completed
28 successfully by the identified entities that can provide security data to mitigate the risk,
29 would sufficiently mitigate the risk to continue transaction processing of the current
30 transaction. The TSGS may also obtain the associated security burdens and risk
31 mitigation score capabilities of each of the identified security protocols, e.g., 819. In some embodiments, the TSGS may identify the combination of security protocols (and associated entities that may have to engage the security protocols) that poses the minimum burden to a user experience, e.g., 820. In alternate embodiments, the TSGS may seek to minimize: the number of security protocols used, number of entities solicited for security data, security protocol processing time, security protocol processing overhead (e.g., cost, computational complexity), and/or the like. [ 00161 ] The TSGS may generate security data requests for the identified entities, e.g., 821, and obtain security data from the entities, e.g., 822. Using the security data, the TSGS may calculate an updated risk score for the transaction risk type, e.g., 823. For example, the TSGS may utilize a component such as the example Transaction Risk Assessment ("TRA") component of FIGURE 7. The TSGS may compare the updated risk score to the predetermined maximum acceptable threshold risk value for the risk type in the current transaction, and determine whether the risk score has been lowered below the threshold. If the risk has been lowered enough, e.g., 824, option "Yes," the TSGS may move on to the next transaction risk to mitigate, see 827. If the risk score has not been lowered below the threshold, e.g., 824, option "No," then the TSGS may determine whether the number of security data requests, security protocol processing time, transaction authorization attempts, etc. have exceeded a predetermined value, e.g., 825. If the timeout has occurred, the TSGS may generate a transaction denial notification, e.g., 826. Otherwise, the TSGS may iteratively perform the above-mentioned procedure for the risk type, until the risk type is sufficiently mitigated (below the risk threshold), or the transaction is denied (see 813-826). The TSGS may perform such a transaction risk allocation and graduated security protocol escalation procedure for each transaction risk type involved in the current transaction (see 827), until the transaction is either authorized, see 828, or denied, see 827. [ 00162 ] With reference to FIGURE 8C, in some embodiments, the TSGS may obtain a set of transaction risk types and associated transaction risk scores, e.g., 831. For example, the risk types and scores may be generated by a component such as the example Transaction Risk Assessment ("TRA") component for FIGURE 7. The TSGS may select a risk type, risk score pair to attempt to mitigate, e.g., 832. The TSGS may identify a set of candidate entities (e.g., consumer, merchant, issuer, acquirer, payment network, payment service provider, third-party service provider, etc.) that may be able to assume the risk, e.g., in exchange for consideration. For example, the TSGS may request bids from one or more of the entities to assume (a portion of) the risk type associated with the transaction. For example, the TSGS may request bids for a discount, rewards, incentive, bonus, future payout, reduced transaction fees, etc., in exchange for the entity assuming the risk specified in the bid request. If any of the entities accept to assume (a portion of) the risk type, then the TSGS may recalculate the risk score associated with the risk type. For example, the user may be able to bear a risk that the merchant is fraudulent, in exchange for a discount on the purchase, or for a discount in payment processing fees for the payment network. As another example, the merchant may be able to bear the risk that the user is fraudulent, which may result in a refund request by the actual user at a later date. As an alternative, the payment network, issuer, or acquirer may be able to bear such risk. As still another example, the TSGS may allow one or more entities to provide security data that mitigates one or more risk types associated with the transaction. If the security data indeed serves to mitigate that risk type, the entity providing that security data may be exempted from bearing risk associated with that risk type if the transaction were processed, and the risk associated with that risk type may be reallocated among the other entities participating in the transaction. For example, one or more entities may be able to provide authenticating data (e.g., a digital certificate, digital fingerprint data, an MD5 hash authenticating a user login, a device fingerprint, biometric data from the consumer, previously authenticated stored credentials stored in a database of federated profiles of consumers and agreed upon by the entities to the transaction as being sufficient to mitigate a specific type of risk, etc.) and be exempted from risks that the provided data mitigates. In some embodiments, an entity offering security data to mitigate risk may be excluded from obtaining a reward for bearing that risk in the transaction. In alternate embodiments, providing the security data may entitle the entity to obtain a reward for mitigating the risk (e.g., in some embodiments, provided the risk purportedly mitigated by the security data does not manifest itself upon completion of the transaction authorization).
[00163] In some embodiments, upon identifying a list of entities that may be able to bear the risk type, e.g., 833, the TSGS may obtain an initial allocation of the transaction risk and revenue sharing (e.g., proceeds of the transaction) among the identified entities, e.g., from a database storing predetermined default allocations of risk and revenue among the entities, e.g., 834. The TSGS may generate transaction risk bid requests for the identified entities, e.g., 835. The TSGS may provide the transaction risk bid requests and obtain the responses from the entities, e.g., 836. For example, such bids may be of two types. First, an entity may offer to accept the risk associated with the risk type in exchange for a revenue allocation. Second, an entity may offer security data mitigating that risk in exchange for being exempted from that risk type. In some embodiments, the TSGS may identify the bid types obtained from the entities, e.g., 837. If any bids are of the first type, see e.g., 838, option "Yes," the TSGS may select the bid requesting the lowest revenue allocation in exchange for accepting the risk associated with the risk type as the winner of the bidding contest, e.g., 839. The TSGS may then continue processing the other risk types (see 849). For example, if the risk associated with the risk type is accepted in its entirety (or to an amount sufficient for the TSGS to continue the transaction), the TSGS may move on to the next transaction risk to mitigate (see 849). If no bids are of the first type, see e.g., 838, option "No," the TSGS may select one of the security data offers provided by the entities, e.g., 840. For example, a mobile merchant can provide seller digital certificate credentials to assure the TSGS that the mobile merchant may be trusted in the transaction, and can be traced should any problems arise from the transaction in the future. As another example, a user suspected of being fraudulent may be asked to engage in any of the security protocols listed in FIGURE 8A. The TSGS may obtain, from a database, a pre- determined maximum acceptable threshold risk value for the risk type, as well as a list of security protocols, e.g., 841, available that, if completed successfully by the identified entities that can provide security data to mitigate the risk, would sufficiently mitigate the risk to continue transaction processing of the current transaction. The TSGS may generate a security data request for the identified entity, and obtain the security data from the entity, e.g., 841. Using the security data, the TSGS may calculate an updated risk score for the transaction risk type, e.g., 842. For example, the TSGS may utilize a component such as the example Transaction Risk Assessment ("TRA") component of FIGURE 7. The TSGS may compare the updated risk score to the predetermined maximum acceptable threshold risk value for the risk type in the current transaction, and determine whether the risk score associated with that risk type has been lowered below the threshold, e.g., 843. If the risk has been lowered enough, e.g., 843, option "Yes," the TSGS may exempt the security-data-offering entity from bearing the risk associated with the risk type, reallocate the risk associated with that risk type among the other remaining entities besides the security-data-offering entity, and move on to the next transaction risk to mitigate as needed, see e.g., 846-849. If the risk score has not been lowered below the threshold, e.g., 843, option "No," then the TSGS may select another security data offering entity to see if any additional risk shifting need be performed among the entities with respect to the risk type being processed, see 844. The TSGS may perform such risk shifting between the entities until no more entities are available to provide security data to shift the risk associated the transaction risk type to other entities. The TSGS may accordingly reallocate the risk associated with the risk type among the remaining entities, e.g., 845. If the risk associated with the transaction risk type is still greater than a maximum allowable limit, e.g., 846, option "Yes," the TSGS may determine whether the number of security data requests, security protocol processing time, transaction authorization attempts, etc. have exceeded a predetermined value, e.g., 847. If the timeout has occurred, the TSGS may generate a transaction denial notification, e.g., 848. Otherwise, the TSGS may iteratively perform the above-mentioned procedure, until each risk type is sufficiently mitigated (below its associated risk threshold) and reallocated among the various entities, or the transaction is denied (see 846-850). The TSGS may perform such a transaction risk allocation and graduated security protocol escalation procedure for each transaction risk type involved in the current transaction (see 849), until the transaction is either authorized, see 850, or denied, see 848. [ 00164 ] Further implementations of TSGS risk assessment may include rules configuration (e.g., block user's device if they login more than 10 times in 10 minutes). Rule may be applicable to data fields such as but not limited to Event (login result, add card, timestamp, etc.), User profile (username, date of enrollment, time since first transaction, # of addresses on file, source of enrollment, wallet settings like alerts, when users change profile and fields changes like billing or shipping addresses, etc.), User history (successful vs. unsuccessful logins, successful vs. unsuccessful purchases, changes to billing address, changes to shipping address, latest status such as cancelled/completed, etc.), Device/network info (IP address, device ID, ISP, etc.), Payment instrument (PAN, product type, issuing country, AVS result code, AA score, etc.) should include activity for both successfully and unsuccessfully added payment instruments, Sanction list results (decision, score, etc.), Merchant (name, country, enrollment date, category, etc.), Transaction (order amount, currency code, auth amount, status, etc.), State (wallet in card lockout state, device in lockout state, user hasn't answered challenge question on new device yet, etc.), Velocity and attribute anomalies (number of purchases during a specified timeframe, number of users using device during specified timeframe, number of transactions shipped to the same addresses, etc.), other (third party data, calculations like distance between billing city and IP address, etc.). [ 00165 ] In one implementation, a rule editor may allow events to have their own rules (enrollment rules vs. login rules, etc.), different rule profiles (Canadian purchase rules, US purchase rules, high risk merchant rules, low-risk (pre-provisioned) consumer rules, etc.), and/or the like. Rules may be nested (if order > $400 and risk score > 80 then decline else if order < $400 and risk score > 90 then decline, review, etc.). Rules may handle string, number, date values (e.g., later than May 1st 2011), relative date values (e.g., current date vs. enrollment date > 90 days), and use multiple list types (positive, negative, BINs, zip codes, merchants, etc.). Velocity/anomaly rules may include single attribute (e.g., single device ID seen more than xx times in x days), two attribute (e.g., enrollment attempts (attrib 1) from device ID (attrib 2) greater than xx attempts in xx minutes), three attribute (e.g., purchases (attrib 1) from specific customer (attrib 2) at specific merchant (attrib 3) exceeds $xx in xx days), and/or the like. The anomaly rules may further include "NOT" versions of the above. [ 00166 ] In one implementation, the attribute anomaly rule type may include one primary attribute and one secondary attribute (e.g., specific PAN (primary attribute) is used across more than x wallets (secondary attribute) in x days), multiple primary attributes and one secondary attribute (e.g., rule fires if 1 wallet (1st primary attrib) receives deny (2nd primary attrib) during card addition (3rd primary attrib) on 5+ PANs (secondary attrib)), one primary attribute and multiple secondary attributes, multiple primary attributes and multiple secondary attributes, and "NOT" versions of the above (e.g., rule fires if wallet (primary) has not been used with device (secondary attrib)). [ o o i 67] In one implementation, TSGS may exempt certain events (geography, brand, card type, product id, context, sub context) from velocity/anomaly rules (e.g., excluding issuer updates toward card lockout or don't count non-reloadable prepaid declines toward card lockout, etc.), track velocity by event type (e.g., number of times IP address has been seen for enrollments only, etc.), track velocity/anomalies across multiple event types (e.g., number of times IP address has been seen), and/or the like. [ 00168 ] In another example, velocity/anomaly rules may be configurable by time frame (minutes to multiple days), and velocity/anomaly metrics may be based on count, cumulative dollar amount, or count only if above/below certain dollar amounts. [ 00169 ] In one implementation, rules may be created based on various states, including device locked out, wallet locked out, wallet disabled for sanction list reasons, wallet disabled for fraud reasons, wallet disabled for fraud/sanction list reasons, wallet in card lockout, user hasn't answered challenge question successfully for particular device, and/or the like. TSGS may further monitor the impact of the rules on declined enrollments, logins, card-add events and transactions, and apply logics to specify the rule impact to the different events of the accounts including: review, deny/reject, disable wallet, monitor, accept. TSGS may further write rules in audit mode to review potential impacts before making those rules impact decisions, and logging of who creates/edits the rules. [ 00170 ] In another implementation, TSGS may specify risk rules on behalf of merchant (e.g., value add services) and other participants, including merchant configurable rules that either stop auth request from being submitted to issuer, or rules that permit a decline and auth reversal post-issuer auth orization, packaged rule sets available by merchant vertical, and/or the like. A set of variables for the rules may include: dollar amount, risk score, and a handful of others. Within implementations, a risk scoring engine provides a complementary approach to rules. For example, it may provide a fine-grained risk assessment based on the zip code risk indices. The risk 1 scoring engine may have access to the same data used by the rules editor. In one
2 implementation, TSGS may support different model segments such as by country,
3 industry, e.g., Visa card versus non Visa cards, models, etc.
4 [ 00171] Within implementations, truth data may be available to the risk scoring
5 engine as soon as it is known, including TC 40 fraud data from VisaNet, chargebacks
6 data from merchants or acquirers, etc. Risk models may be able to connect different
7 wallets, e.g., wallet of user "John" was created on the same device as wallet of user
8 "Amy" which had a chargeback. Risk engine may have access to historical data for
9 velocity and other calculations.
10 [ 00172 ] Within implementations, related risk events may be traceable. For
11 example, risk assessment of a transaction or wallet may be linkable to wallet activity
12 during the checkout session resulting in an authorization, prior transaction and add-
13 card activity, login activity and enrollments. Accounts that are suspected of being
14 fraudulent or non-compliant may be disabled, e.g., when certain rules are triggered
15 (fails periodic sanction list check, risk velocity rules, etc.). Within implementation,
16 TSGS may keep a record for the wallet status, e.g., whether wallet is disabled or in
17 lockout, including type (temporary wallet lockout, temporary card lockout, permanent
18 wallet disablement), Reason for disablement (sanction list, fraud, sanction list/fraud,
19 etc.), History of enablement / disablement / re-enablement, Decline reason (issuers or
20 merchants declined). This way, CSR can refer customers to call issuers or merchants.,
21 User events including enrollment attempts, invalid credentials, any device lockout
22 information, provide data for offline analysis (hadoop, cae), raw data used in risk
23 analysis, decisions and risk scores, and/or the like.
24 [ 00173 ] FIGURE 8D provides a logic flow diagram illustrating aspects of
25 progressive transaction risk mitigation between TSGS 855b and other TSGS participants
26 855a (e.g., merchants, acquirers, issuers, consumers, third party payment gateways,
27 etc.) within an alternative embodiment of the TSGS. Within embodiments, TSGS and
28 other TSGS participants may perform transaction mitigation progressively based on a
29 hierarchy of tolerable risk thresholds. In one implementation, the TSGS may receive a
30 transaction request 860 (e.g., see 211 in FIGURE 2A, etc.), and may generate a risk score
31 (e.g., at 861) based on information in the transaction request (e.g., see SRA in FIGURE 6B, and TRA in FIGURE 7, etc.). In one implementation, the TSGS may load assessment rules 861 (e.g., see Risk Rules table 2βΐ9Γ in FIGURE 23). For example, such assessment rules may indicate a maximum tolerable risk threshold (e.g., any transaction having a risk score greater than the maximum threshold may be denied without further mitigation, etc.). As another example, the assessment rules may specify other participants' requirements, e.g., transactions directed to Bank of America accounts shall be directed to the issuer to mitigate the risk, transactions from Amazon.com shall be directed to Amazon.com to mitigate the risk, etc. As another example, TSGS may configure assessment rules that transactions from newly enrolled merchants (e.g., less than six months, etc.) shall be directed to the merchants to perform transaction risk mitigation so that TSGS may shift transaction risks to the new merchants who may not have established a long term credit history with TSGS.
[00174] In one implementation, if the risk score is too high 862a, greater than a maximum tolerable threshold (e.g., 0.95, etc.), the TSGS may reject the transaction 863. Otherwise, the TSGS may determine whether the risk score is greater than a TSGS tolerable threshold 862b (e.g., 0.75, etc.), which is lower than the maximum tolerable threshold. If yes, the TSGS may not perform the transaction risk mitigation, but may direct the transaction request to other TSGS participants 855a. For example, the TSGS may send mitigation offers to merchants, acquirers, issuers, third party gateways (e.g., CyberSource, etc.), consumers, and/or the like to mitigate the transaction risk 864. [00175] For example, TSGS may provide a (Secure) Hypertext Transfer Protocol ("HTTP(S)") POST message including the mitigation offer in the form of data formatted according to the extensible Markup Language ("XML"). An example listing of a mitigation offer from TSGS to other TSGS participants (e.g., 864), substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below: POST /mitigationoffer .php HTTP/1.1
Host: www.TSGS.com
Content-Type: Application/XML
Content-Length: 667
<?XML version = "1.0" encoding = "UTF-8"?>
<mitigation_offer>
<destination> Amazon.com </destination>
<participant_type> merchant <participant_type>
<mitigation_offer_reason> merchant rule </mitigation_offer_reason> <session_ID>4NFU4RGdsfds</session_ID>
<! --optional parameters--> <timestamp>2015-02-22 15 : 22 : 41</timestamp>
<transaction>
<transaction_id> erwfdesfe4324 </ transaction_id>
<user_ID>j ohn . q. publicSgmail . com</user_ID>
<device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial>
<device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDID>21343e34-14f4-8jn4-7yfe- 124578632134</device_UDID>
<device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<OS>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag> </device_fingerprint>
<merchant>
<merchant_id> amaz </merchant_id>
<merchant_name> Amazon.com </merchant_name>
</merchant>
<account>
<! --optional parameters—>
<account_no> 0000 0000 0000 0000 </account_no>
<issuer> Bank of America </issuer>
<routing_no> 00000 </routing_no>
</account>
</ transaction>
<TSGS_risk>
<device_risk> 0.02 </device_risk>
<reason_code> 01 </reason_code>
<account_risk> 0.33 </account_risk>
<total> 0.42 </total>
</TSGS_risk>
</mitigation_offer>
[00176] In an alternative implementation, even if the risk score does not exceed the TSGS tolerable threshold at 862b, TSGS may determine whether other participant mitigation is required 863 based on the rules loaded at 861 (e.g., TSGS may require all new merchants to mitigate the risk for the first six months upon enrollment with TSGS or other participants may specify rules to review transactions, etc.). [00177] In one implementation, if the requested other participant does not accept the mitigation requests/offers 865, the transaction may be rejected 863. Otherwise, the other participants may proceed to review the received mitigation offer and determine whether further mitigation is needed 866. For example, a merchant, e.g., Amazon.com, etc., may receive a mitigation offer for a transaction having a risk score of 0.42 (as in the above XML example), because Amazon.com has specified rules to review all transactions, but Amazon.com may have a merchant risk threshold at 0.5. As such, Amazon.com may determine no further mitigation is needed 866 and send a positive mitigation result to TSGS 868.
[ 00178 ] In another implementation, if mitigation is needed at 866, the other participants may perform an independent mitigation risk mitigation procedure. For example, a merchant, issuer, acquirer, etc. may have their customer service representatives to call a consumer. In another implementation, the other TSGS participants may load a risk shift mitigation component 867 (e.g., TSGS may provide API to the participants to use TSGS infrastructure to mitigate risk, etc.) to access the TSGS database including the TSGS security protocol stack as shown in Table 16. In one implementation, the transaction risk shift mitigation component may be loaded and/or provided by loading a webpage having an API and fields via which risk parameters, transaction context parameters, challenge/mitigation parameters, and/or the like, may be provided and/or obtained (e.g., via HTTP parameter POS), whereby TSGS may then provide to the TSGS participants and/or provide directly to the consumers/merchants involved in the transaction, a proper mitigation/challenge. For example, the TSGS may either provide a component for the participants to issue and execute a risk challenge, or may directly issue the risk challenges on behalf of the participants. In another implementation, the risk shift mitigation component may be provided to TSGS participants as a SDK comprising locally executable libraries. Upon mitigation procedure, the TSGS participants may send a mitigation result message to TSGS indicating positive/negative transaction security 868 (in the embodiment where TSGS executes the risk challenge on behalf of the TSGS participants, the TSGS may receive the mitigation results directly from the entities being challenged). For example, participants may provide a HTTP(S) POST message including the mitigation results in the form of data formatted according to XML. An example listing of a mitigation result from other TSGS participants to TSGS (e.g., 868), substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below:
POST /mitigationresult.php HTTP/1.1
Host: www.merchant.com
Content-Type: Application/XML
Content-Length: 667 <?XML version = "1.0" encoding = "UTF-8"?>
<mitigation_result>
<participant_type> merchant <participant_type>
<merchant_id> amaz </merchant_id>
<merchant_name> Amazon.com </merchant_name>
<timestamp>2015-02-22 15 : 23 : 41</timestamp>
<transaction>
<transaction_id> erwfdesfe4324 </ transaction_id>
<user_ID>j ohn . q. publicSgmail . com</user_ID>
<account_no> 0000 0000 0000 0000 </account_no>
<issuer> Bank of America </issuer>
<routing_no> 00000 </routing_no>
</account>
</ transaction>
<TSGS_risk>
<device_risk> 0.02 </device_risk>
<reason_code> 01 </reason_code>
<account_risk> 0.33 </account_risk>
<total> 0.42 </total>
</TSGS_risk>
<mitigation_protocol>
<protocol_id> UINF_093134 </protocol_id>
<protocol_type> user information </protocol_type> <protocol_subtype> security questions </protocol_subtype>
<protocol_medium> SMS </protocol_medium>
<estimated_mitigation> 0.3 </estimated_mitigation>
</mitigation_protocol>
<protocol_log>
<requested_q_l> "where is your high school?"
</protocol_q_l>
<stored_answer> New York, NY </ stored_answer>
<received_answer> Miami </received_answer>
<mitigation_amount> 0 </mitigation_amount>
</protocol_log>
<mitigation_amount> 0 </mitigation_amount>
<risk_after_mitigation> 0.42 </risk_after_mitigation>
<Alert> Account Fraud </Alert>
</mitigation_offer> [00179] In the above example, the mitigation result message shows the merchant, e.g., Amazon.com, has executed a security protocol for user information confirmation, e.g., location of user's high school. As the received answer is incorrect, the risk mitigation amount is o. In another implementation, an incorrect answer to the security question (and/or other negative outcome of the mitigation challenge, etc.) may have a negative mitigation amount so as to further increase the transaction risk, or act as a direct bar to the transaction. In one implementation, such user security questions may 1 be loaded from TSGS infrastructure. In another implementation, Amazon.com may
2 have previously collected and stored their own security questions.
3 [00180 ] In further implementations, when a challenge protocol fails to generate
4 positive outcomes, TSGS may generate alerts of fraudulent activities, e.g., wallet
5 disablement alerts, card used across multiple wallets, match on a sanction list, rules
6 trigger alerts, device lockout due to velocity, blocked domain, and/or the like. For
7 example, alerts may occur when the challenge results (system-wide or merchant
8 specific) are outside of certain norms, such as: enrollment attempts is greater than a
9 percentage of deny rate; login attempts is greater than a percentage of deny rate;
10 challenges is greater than a percentage of total logins; add/update card attempts is
11 greater than a percentage of deny rate; authorization attempts is greather than a
12 percentage of decline rate; sanction list checks is greater than a percentage of decline
13 rate, and/or the like. i4 [o o i 8 i] In one implementation, upon receiving the mitigation result message from
15 a TSGS participant, TSGS may store the mitigation amount to indicate the transaction
16 risk that has been shifted to the mitigation participant (e.g., see Transaction Record
17 table 2βΐ¾ in FIGURE 23). For example, in one implementation, when TSGS
18 determines a risk score exceeds TSGS tolerable threshold at 862b but a merchant then
19 determines such transaction is acceptable upon risk mitigation at 867, even if TSGS
20 authorizes the transaction upon the positive mitigation result provided by the merchant,
21 the merchant will bear the risk of the transaction.
22 [00182] Back to 863, when TSGS has determined no mitigation from other
23 participants is needed 863, TSGS may determine whether the risk score is too low to
24 need any mitigation 869. For example, TSGS may have a minimum risk threshold (e.g.,
25 0.1, etc.) that any transaction having a risk score lower than the minimum will
26 automatically be authorized. If mitigation is needed, TSGS may determine the user
27 purchase context 870, e.g., a geo-location of the consumer, network bandwidth,
28 purchasing medium of the consumer, etc (e.g., the XML checkout request example 912
29 in FIGURE 9 indicates the transaction was originated from a mobile device, etc.). Such
30 purchase context may facilitate TSGS to look up available mitigation options 871. For
31 example, if the transaction is originated from a PoS terminal, TSGS may include security 1 challenges that need PoS terminal transmission (e.g., see merchant fingerprint 8o2g in
2 Table 16). As another example, if the geo-location and/or IP address indicates the
3 transaction is originated from rural areas with limited bandwidth, TSGS may exclude
4 security challenges that need a high network transmission bandwidth (e.g., see video
5 chat 85od in Table 16, etc.).
6 [ o o i 83 ] In one implementation, TSGS may determine mitigation challenge that is
7 sufficient to reduce the risk score to a level lower than TSGS tolerable threshold 872
8 (e.g., see discussion with Table 16). If no such mitigation challenge is available from the
9 list generated at 872, TSGS may reject the transaction. If such mitigation is available
10 875, TSGS may issue and execute the challenge 876.
11 [ 00184] In one implementation, if the outcome of the mitigation is successful 880
12 (e.g., user has successfully answered security questions, device fingerprints matches
13 previously stored information, etc.), TSGS may authorize the transaction 881.
14 Otherwise, the transaction may be rejected 863.
15 [ 00185] Within implementations, TSGS may generate fraud reports based on the
16 risk shifting activities, including consumer events (e.g., enrollments, purchases and
17 other events) from a merchant-specific view, reseller-specific view, issuer-specific view
18 or an overall program level. In one implementation, reporting may cover: enrollments,
19 logins, card additions/updates, purchases and other events, both positive and negative
20 (e.g., number of cards successfully added to wallet and number of cards attempted and
21 rejected from being added to wallet), result of event (allow, deny, challenge, etc.), fraud
22 rate (merchant monitoring to identify non-eligibility) of merchant's Visa transactions
23 overall, fraud rate (merchant monitoring to identify non-eligibility) of merchant's V.me,
24 reason for negative cases (e.g., blocked domain, velocity), and/or the like.
25 [ 00186 ] In another implementation, merchant reporting may cover merchant
26 events such as onboarding and logins, including Result of event (allow, deny, challenge,
27 etc.) by merchant, reason for negative cases (e.g., blocked domain, velocity, sanction list
28 check), ability to slice/dice based on enrollment source (direct, reseller), timeframe,
29 geography, device and network characteristics, etc.
30 [ 00187] FIGURE 9 shows a datagraph diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout ("UPC") component into a checkout data display. In some embodiments, a user, e.g., 901a, may desire to purchase a product, service, offering, and/or the like ("product"), from a merchant via a merchant online site or in the merchant's store. The user may communicate with a merchant/acquirer ("merchant") server, e.g., 903a, via a client such as, but not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 902). For example, the user may provide user input, e.g., checkout input 911, into the client indicating the user's desire to purchase the product. In various embodiments, the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a touch screen interface, keyboard entry, card swipe, activating a RFID/NFC equipped hardware device (e.g., electronic card having multiple accounts, Smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi -touch gestures on a touch-sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like. As an example, a user in a merchant store may scan a product barcode of the product via a barcode scanner at a point-of-sale terminal. As another example, the user may select a product from a webpage catalog on the merchant's website, and add the product to a virtual shopping cart on the merchant's website. The user may then indicate the user's desire to checkout the items in the (virtual) shopping cart. For example, the user may activate a user interface element provided by the client to indicate the user's desire to complete the user purchase checkout. The client may generate a checkout request, e.g., 912, and provide the checkout request, e.g., 913, to the merchant server. For example, the client may provide a HTTP(S) POST message including the product details for the merchant server in the form of data formatted according to the XML. An example listing of a checkout request 912, substantially in the form of a HTTP(S) POST message including XML- formatted data, is provided below:
POST /checkoutrequest .php HTTP/ 1 . 1
Host: www.merchant.com
Content-Type: Application/XML
Content-Length: 667
<?XML version = " 1 . 0 " encoding = "UTF- 8 " ? >
<checkout_request>
<session_ID>4NFU4RG94</session_ID>
<! --optional parameters--> <timestamp>2015-02-22 15 : 22 : 41</timestamp>
<user_ID>j ohn . q. publicSgmail . com</user_ID>
<device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial> <device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDID>21343e34-14f4-8jn4-7yfe-124578632134</device_UDID> <device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<OS>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag>
</device_fingerprint>
</checkout_request>
[00188] In some embodiments, the merchant server may obtain the checkout request from the client, and extract the checkout detail (e.g., XML data) from the checkout request. For example, the merchant server may utilize a parser such as the example parsers described below in the discussion with reference to FIGURE 23. Based on parsing the checkout request 912, the merchant server may extract product data (e.g., product identifiers), as well as available PoS client data, from the checkout request. In some embodiments, using the product data, the merchant server may query, e.g., 914, a merchant/acquirer ("merchant") database, e.g., 903b, to obtain product data, e.g., 915, such as product information, product pricing, sales tax, offers, discounts, rewards, and/or other information to process the purchase transaction and/or provide value- added services for the user. For example, the merchant database may be a relational database responsive to Structured Query Language ("SQL") commands. The merchant server may execute a hypertext preprocessor ("PHP") script including SQL commands to query a database table (such as FIGURE 23, Products 2319I) for product data. An example product data query 914, substantially in the form of PHP/SQL commands, is provided below:
<?PHP
header (' Content-Type : text/plain');
mysql_connect ("254.93.179.112", $DBserver, $password) ; // access database server mysql_select_db ( "TSGS_DB . SQL" ) ; // select database table to search
//create query
$query = "SELECT product_title product_attributes_list product_price tax_info_list related_products_list offers_list discounts_list rewards_list merchants_list
merchant_availability_list FROM ProductsTable WHERE product_ID LIKE '%' $prodID";
$result = mysql_query ( $query) ; // perform the search query
mysql_close ( "TSGS_DB . SQL" ) ; // close database access
?> [00189] In some embodiments, in response to obtaining the product data, the merchant server may generate, e.g., 916, checkout data to provide for the PoS client. In some embodiments, such checkout data, e.g., 917, may be embodied, in part, in a HyperText Markup Language ("HTML") page including data for display, such as product detail, product pricing, total pricing, tax information, shipping information, offers, discounts, rewards, value-added service information, etc., and input fields to provide payment information to process the purchase transaction, such as account holder name, account number, billing address, shipping address, tip amount, etc. In some embodiments, the checkout data may be embodied, in part, in a Quick Response ("QR") code image that the PoS client can display, so that the user may capture the QR code using a user's device to obtain merchant and/or product data for generating a purchase transaction processing request. In some embodiments, a user alert mechanism may be built into the checkout data. For example, the merchant server may embed a URL specific to the transaction into the checkout data. In some embodiments, the alerts URL may further be embedded into optional level 3 data in card authorization requests, such as those discussed further below with reference to FIGURES 11-12. The URL may point to a webpage, data file, executable script, etc., stored on the merchant's server dedicated to the transaction that is the subject of the card authorization request. For example, the object pointed to by the URL may include details on the purchase transaction, e.g., products being purchased, purchase cost, time expiry, status of order processing, and/or the like. Thus, the merchant server may provide to the payment network the details of the transaction by passing the URL of the webpage to the payment network. In some embodiments, the payment network may provide notifications to the user, such as a payment receipt, transaction authorization confirmation message, shipping notification and/or the like. In such messages, the payment network may provide the URL to the user device. The user may navigate to the URL on the user's device to obtain alerts regarding the user's purchase, as well as other information such as offers, coupons, related products, rewards notifications, and/or the like. An example listing of a checkout data 917, substantially in the form of XML- formatted data, is provided below:
<?XML version = "1.0" encoding = "UTF-8"?>
<checkout data> <session_ID>4NFU4RG94</session_ID>
<! --optional data-->
<timestamp>2015-02-22 15 : 22 : 43</timestamp>
<expiry_lapse>00 : 00 : 30</expiry_lapse>
<total_cost>$121.49</total_cost>
<alerts_URL>www . merchant . com/ shopcarts .php?sessionID=4NFU4RG94</alerts_UR L>
<user_ID>j ohn . q. publicSgmail . com</user_ID>
<user_device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial>
<device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDI D>21343e34-14f4-8jn4-7yfe-124578632134</device_UDI D> <device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<OS>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag> </user_device_fingerprint>
<purchase_detail>
<cart>
<product>
<merchant_params>
<merchant_id>54TBRELF8</merchant_id>
<merchant_name>BARNES, Inc . </merchant_name> <merchant_auth_key>TMN45GER98</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN>
<edition>2nd ed. </edition>
<cover>hardbound</ cover>
</product_params>
<quantity>2</quantity>
<unit_cost>$14.46</unit_cost>
<coupon_id>AY34567</ coupon_id>
<social_flag>ON</social_flag>
<social_message>Look what I bought today ! </social_message> <social_networks>facebook twitter</social_networks>
</product>
<product>
<merchant_params>
<merchant_id>3FBCR4INC</merchant_id>
<merchant_name>Books , Inc . </merchant_name> <merchant_auth_key>lN484MCP</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>Sophie' s World</product_title> <ISBN>955-2-14-112310-0</ISBN>
<edition>NULL</edition>
<cover>hardbound</ cover>
</product_params>
<quantity>K/quantity>
<unit_cost>$34.78</unit_cost>
<coupon_id>null</coupon_id>
<social_flag>OFF</social_flag>
</product> </cart>
<cart>
<product>
<merchant_params>
<merchant_id>RFH5IB4FT</merchant_id>
<merchant_name>Amzn, Inc . </merchant_name> <merchant_auth_key>44543DSJFG</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>XML - a primer</product_title> <ISBN>938-2-14-1436710-0</ISBN>
<edition>2nd ed. </edition>
<cover>hardbound</ cover>
</product_params>
<quantity>K/quantity>
<unit_cost>$12.93</unit_cost>
<coupon_id>AY34567</coupon_id>
<social_flag>ON</social_flag>
<social_message>Look what I bought today ! </social_message> <social_networks>facebook twitter</social_networks>
</product>
<product>
<merchant_params>
<merchant_id>3FBCR4INC</merchant_id>
<merchant_name>BestBooks , Inc . </merchant_name> <merchant_auth_key>lN484MCP</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>Sophie' s Choice</product_title> <ISBN>938-2-14-168710-0</ISBN>
<edition>lst ed. </edition>
</product_params>
<quantity>K/quantity>
<unit_cost>$44.86</unit_cost>
<coupon_id>null</coupon_id>
<social_flag>OFF</social_flag>
</product>
</cart>
</purchase_detail>
<checkout_data>
[00190] Upon obtaining the checkout data, e.g., 917, the PoS client may render and display, e.g., 918, the checkout data for the user. [00191] FIGURE 10 shows a logic flow diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout ("UPC") component into a checkout data display. In some embodiments, a user may desire to purchase a product, service, offering, and/or the like ("product"), from a merchant via a merchant online site or in the merchant's store. The user may communicate with a merchant/acquirer ("merchant") server via a PoS client. For example, the user may provide user input, e.g., 1001, into the client indicating the user's desire to purchase the product. The client may generate a checkout request, e.g., 1002, and provide the checkout request to the merchant server. In some embodiments, the merchant server may obtain the checkout request from the client, and extract the checkout detail (e.g., XML data) from the checkout request. For example, the merchant server may utilize a parser such as the example parsers described below in the discussion with reference to FIGURE 23. Based on parsing the checkout request, the merchant server may extract product data (e.g., product identifiers), as well as available PoS client data, from the checkout request. In some embodiments, using the product data, the merchant server may query, e.g., 1003, a merchant/acquirer ("merchant") database to obtain product data, e.g., 1004, such as product information, product pricing, sales tax, offers, discounts, rewards, and/or other information to process the purchase transaction and/or provide value-added services for the user. In some embodiments, in response to obtaining the product data, the merchant server may generate, e.g., 1005, checkout data to provide, e.g., 1006, for the PoS client. Upon obtaining the checkout data, the PoS client may render and display, e.g., 1007, the checkout data for the user.
[ 00192 ] FIGURES 11A-B show datagraph diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization ("PTA") component into a purchase transaction receipt notification. With reference to FIGURE 11A, in some embodiments, a user, e.g., 1101a, may wish to utilize a virtual wallet account to purchase a product, service, offering, and/or the like ("product"), from a merchant via a merchant online site or in the merchant's store. The user may utilize a physical card, or a user wallet device, e.g., 1101b, to access the user's virtual wallet account. For example, the user wallet device may be a personal/laptop computer, cellular telephone, smartphone, tablet, eBook reader, netbook, gaming console, and/or the like. The user may provide a wallet access input, e.g., 1111 into the user wallet device. In various embodiments, the user input may include, but not be limited to: a single tap (e.g., a one- tap mobile app purchasing embodiment) of a touchscreen interface, keyboard entry, card swipe, activating a RFID/NFC equipped hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch- 1 sensitive display, and/or the like. In some embodiments, the user wallet device may
2 authenticate the user based on the user's wallet access input, and provide virtual wallet
3 features for the user.
4 [o o i93] In some embodiments, upon authenticating the user for access to virtual
5 wallet features, the user wallet device may provide a transaction authorization input,
6 e.g., 1114, to a point-of-sale ("PoS") client, e.g., 1102. For example, the user wallet device
7 may communicate with the PoS client via Bluetooth, Wi-Fi, cellular communication, one- or
8 two-way near-field communication ("NFC"), and/or the like. In embodiments where the user
9 utilizes a plastic card instead of the user wallet device, the user may swipe the plastic card at
10 the PoS client to transfer information from the plastic card into the PoS client. For example,
11 the PoS client may obtain, as transaction authorization input 1114, track 1 data from the
12 user's plastic card (e.g., credit card, debit card, prepaid card, charge card, etc.), such as
13 the example track 1 data provided below:
14 %B123456789012345APUBLIC/ J. Q. Λ 99011200000000000000** 901 ******?*
15 (wherein ,123456789012345' is the card number of V.Q. Public' and has a CVV number of
16 901. '990112' is a service code, and *** represents decimal digits which change
17 randomly each time the card is used.)
18
19 [00194] In embodiments where the user utilizes a user wallet device, the user
20 wallet device may provide payment information to the PoS client, formatted according
21 to a data formatting protocol appropriate to the communication mechanism employed
22 in the communication between the user wallet device and the PoS client. An example
23 listing of transaction authorization input 1114, substantially in the form of XML-
24 formatted data, is provided below:
25 <?XML version = "1.0" encoding = "UTF-8"?>
26 <transaction_authorization_input>
27 <payment_data>
28 <account>
29 <charge_priority>l</ charge_priority>
30 <charge_ratio>40%</charge_ratio>
31 <account_type>debit</account_type>
32 <value_exchange_symbol>USD</value_exchange_symbol>
33 <account_number>123456789012345</account_number>
34 <account_name>John Q. Public</account_name>
35 <bill_add>987 Green St #456, Chicago, IL 94652</bill_add>
36 <ship_add>987 Green St #456, Chicago, IL 94652</ship_add>
37 <CW_type>dynamic<CVV_type>
38
39 <CW>http: //www.paynet . com/dcvv . php?sessionID=4NFU4RG94</CW>
40 <cloak_flag>ON</cloak_flag>
41 <alert_rules>tar1 tar4 tar12</alert_rules>
42 <mode>NFC</mode> </account>
<account>
<charge_priority>l</ charge_priority>
<charge_ratio>60%</charge_ratio>
<account_type>rewards</account_type>
<value_exchange_symbol>VME</value_exchange_symbol>
<account_number>234567890123456</account_number>
<account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW_type>static<CW_type>
<CW>173</CVV>
<cloak_flag>ON</cloak_flag>
<alert_rules>tar1 tar4 tar12</alert_rules>
<mode>Bluetooth</mode>
</account>
<account>
<charge_priority>2</ charge_priority>
<charge_ratio>100%</ charge_ratio>
<account_number>345678901234567</account_number>
<account_type>credit</account_type>
<value_exchange_symbol>USD</value_exchange_symbol>
<account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW_type>static<CW_type>
<CW>173</CVV>
<cloak_flag>ON</cloak_flag>
<alert_rules>tar1 tar4 tar12</alert_rules>
<mode>NFC</mode>
</account>
</payment_data>
<! --optional data-->
<timestamp>2015-02-22 15 : 22 : 43</timestamp>
<expiry_lapse>00 : 00 : 30</expiry_lapse>
<secure_key>0445329070598623487956543322</secure_key>
<alerts_track_flag>TRUE</alerts_track_flag>
<device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial>
<device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDID>21343e34-14f4-8jn4-7yfe-124578632134</device_UDID> <device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<OS>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag> </device_fingerprint>
</transaction_authorization_input>
[00195] In some embodiments, the PoS client may generate a card authorization request, e.g., 1115, using the obtained transaction authorization input from the user wallet device, and/or product/checkout data (see, e.g., FIGURE 9, 915-917). An example listing of a card authorization request 1115-1116, substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below: POST /authorizationrequests .php HTTP/1.1
Host: www.acquirer.com
Content-Type: Application/XML
Content-Length: 1306
<?XML version = "1.0" encoding = "UTF-8"?>
<card_authorization_request>
<session_ID>4NFU4RG94</order_ID>
<! --optional data-->
<timestamp>2015-02-22 15 : 22 : 43</timestamp>
<expiry>00 : 00 : 30</expiry>
<alerts_URL>www . merchant . com/ shopcarts . php?sessionID=AEBB4356</alerts_URL >
<user_ID>j ohn . q. publicSgmail . com</user_ID>
<device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial>
<device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDID>21343e34-14f4-8jn4-7yfe-124578632134</device_UDID> <device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<0S>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag> </device_fingerprint>
<purchase_details>
<total_cost>$121.49</total_cost>
<cart>
<product>
<merchant_params>
<merchant_id>54TBRELF8</merchant_id>
<merchant_name>BARNES, Inc . </merchant_name> <merchant_auth_key>TMN45GER98</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN>
<edition>2nd ed. </edition>
<cover>hardbound</ cover>
</product_params>
<quantity>2</quantity>
<unit_cost>$14.46</unit_cost>
<coupon_id>AY34567</ coupon_id>
<social_flag>ON</social_flag>
<social_message>Look what I bought today ! </social_message> <social_networks>facebook twitter</social_networks>
</product>
<product>
<merchant_params>
<merchant_id>3FBCR4INC</merchant_id>
<merchant_name>Books , Inc . </merchant_name> <merchant_auth_key>lN484MCP</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>Sophie' s World</product_title> <ISBN>955-2-14-112310-0</ISBN>
<edition>NULL</edition>
<cover>hardbound</ cover> </product_params>
<quantity>K/quantity>
<unit_cost>$34.78</unit_cost>
<coupon_id>null</coupon_id>
<social_flag>OFF</ social_flag>
</product>
</cart>
<cart>
<product>
<merchant_params>
<merchant_id>RFH5IB4FT</merchant_id>
<merchant_name>Amzn, Inc . </merchant_name> <merchant_auth_key>44543DSJFG</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>XML - a primer</product_title> <ISBN>938-2-14-1436710-0</ISBN>
<edition>2nd ed. </edition>
<cover>hardbound</ cover>
</product_params>
<quantity>K/quantity>
<unit_cost>$12.93</unit_cost>
<coupon_id>AY34567</ coupon_id>
<social_flag>ON</social_flag>
<social_message>Look what I bought today ! </social_message> <social_networks>facebook twitter</social_networks>
</product>
<product>
<merchant_params>
<merchant_id>3FBCR4INC</merchant_id>
<merchant_name>BestBooks , Inc . </merchant_name> <merchant_auth_key>lN484MCP</merchant_auth_key>
</merchant_params>
<product_type>book</product_type>
<product_params>
<product_title>Sophie' s Choice</product_title> <ISBN>938-2-14-168710-0</ISBN>
<edition>lst ed. </edition>
</product_params>
<quantity>K/quantity>
<unit_cost>$44.86</unit_cost>
<coupon_id>null</coupon_id>
<social_flag>OFF</social_flag>
</product>
</cart>
</purchase_details>
<account_params>
<account>
<charge_priority>l</ charge_priority>
<charge_ratio>40%</charge_ratio>
<account_type>debit</account_type>
<value_exchange_symbol>USD</value_exchange_symbol>
<account_number>123456789012345</account_number> <account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW_type>dynamic<CVV_type>
<CW>http: //www.paynet . com/dcvv . php?sessionID=4NFU4RG94</CW>
<cloak_flag>ON</cloak_flag> <alert_rules>tar1 tar4 tar12</alert_rules>
<mode>NFC</mode>
</account>
<account>
<charge_priority>l</ charge_priority>
<charge_ratio>60%</charge_ratio>
<account_type>rewards</account_type>
<value_exchange_symbol>VME</value_exchange_symbol>
<account_number>234567890123456</account_number>
<account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW_type>static<CW_type>
<CW>173</CVV>
<cloak_flag>ON</cloak_flag>
<alert_rules>tar1 tar4 tar12</alert_rules>
<mode>Bluetooth</mode>
</account>
<account>
<charge_priority>2</ charge_priority>
<charge_ratio>100%</ charge_ratio>
<account_number>345678901234567</account_number>
<account_type>credit</account_type>
<value_exchange_symbol>USD</value_exchange_symbol>
<account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW_type>static<CW_type>
<CW>173</CVV>
<cloak_flag>ON</cloak_flag>
<alert_rules>tar1 tar4 tar12</alert_rules>
<mode>NFC</mode>
</account>
</account_params>
<shipping_info>
<shipping_adress>#ref-ANON-123-45- 678</ shipping_address>
<ship_type>expedited</ ship_type>
<ship_carrier>FedEx</ ship_carrier>
<ship_account>ANON-123-45-678</ship_account>
<tracking_flag>true</tracking_flag>
<sign_flag>false</sign_flag>
</ shipping_info>
</card_authorization_request>
[00196] In some embodiments, the card authorization request generated by the user device may include a minimum of information required to process the purchase transaction. For example, this may improve the efficiency of communicating the purchase transaction request, and may also advantageously improve the privacy protections provided to the user and/or merchant. For example, in some embodiments, the card authorization request may include at least a session ID for the user's shopping session with the merchant. The session ID may be utilized by any component and/or entity having the appropriate access authority to access a secure site on the merchant server to obtain alerts, reminders, and/or other data about the transaction(s) within that shopping session between the user and the merchant. In some embodiments, the PoS 1 client may provide the generated card authorization request to the merchant server, e.g.,
2 1116. The merchant server may forward the card authorization request to a pay gateway
3 server, e.g., 1104a, for routing the card authorization request to the appropriate payment
4 network for payment processing. For example, the pay gateway server may be able to
5 select from payment networks, such as Visa, Mastercard, American Express, Paypal,
6 etc., to process various types of transactions including, but not limited to: credit card,
7 debit card, prepaid card, B2B and/or like transactions. In some embodiments, the
8 merchant server may query a database, e.g., merchant/acquirer database 1103b, for a
9 network address of the payment gateway server, for example by using a portion of a user0 payment card number, or a user ID (such as an email address) as a keyword for the database1 query. For example, the merchant server may issue PHP/SQL commands to query a2 database table (such as FIGURE 23, Pay Gateways 2319b) for a URL of the pay gateway3 server. An example payment gateway address query 1117, substantially in the form of4 PHP/SQL commands, is provided below:
5 <?PHP
6 header (' Content-Type : text/plain');
7 mysql_connect ("254.93.179.112", $DBserver, $password) ; // access database server
8 mysql_select_db ( "TSGS_DB . SQL" ) ; // select database table to search
9 //create query
0 $query = "SELECT paygate_id paygate_address paygate_URL paygate_name FROM
1 PayGatewayTable WHERE card_num LIKE '%' $cardnum";
2 $result = mysql_query ( $query) ; // perform the search query
3 mysql_close ( "TSGS_DB . SQL" ) ; // close database access
4 ?>
5
6 [00197] In response, the merchant/acquirer database may provide the requested7 payment gateway address, e.g., 1118. The merchant server may forward the card8 authorization request to the pay gateway server using the provided address, e.g., 1119. In9 some embodiments, upon receiving the card authorization request from the merchant server,0 the pay gateway server may invoke a component to provide one or more services1 associated with purchase transaction authorization. For example, the pay gateway2 server may invoke components for fraud prevention, loyalty and/or rewards, and/or3 other services for which the user-merchant combination is authorized. The pay gateway4 server may forward the card authorization request to a pay network server, e.g., 1105a,5 for payment processing. For example, the pay gateway server may be able to select from6 payment networks, such as Visa, Mastercard, American Express, Paypal, etc., to process7 various types of transactions including, but not limited to: credit card, debit card, 1 prepaid card, B2B and/or like transactions. In some embodiments, the pay gateway
2 server may query a database, e.g., pay gateway database 1104b, for a network address of
3 the payment network server, for example by using a portion of a user payment card number,
4 or a user ID (such as an email address) as a keyword for the database query. For example,
5 the pay gateway server may issue PHP/SQL commands to query a database table (such
6 as FIGURE 23, Pay Gateways 2319b) for a URL of the pay network server. An example
7 payment network address query 1121, substantially in the form of PHP/SQL commands,
8 is provided below:
9 <?PHP
10 header (' Content-Type : text/plain');
11 mysql_connect ("254.93.179.112", $DBserver, $password) ; // access database server
12 mysql_select_db ( "TSGS_DB . SQL" ) ; // select database table to search
13 //create query
14 $query = "SELECT payNET_id payNET_address payNET_URL payNET_name FROM PayGatewayTable
15 WHERE card_num LIKE '%' $cardnum";
16 $result = mysql_query ( $query) ; // perform the search query
17 mysql_close ( "TSGS_DB . SQL" ) ; // close database access
18 ?>
19
20 [ 00198 ] In response, the payment gateway database may provide the requested
21 payment network address, e.g., 1122. The pay gateway server may forward the card
22 authorization request to the pay network server using the provided address, e.g., 1123.
23 [ 00199 ] With reference to FIGURE 11B, in some embodiments, the pay network
24 server may process the transaction so as to transfer funds for the purchase into an
25 account stored on an acquirer of the merchant. For example, the acquirer may be a
26 financial institution maintaining an account of the merchant. For example, the
27 proceeds of transactions processed by the merchant may be deposited into an account
28 maintained by at a server of the acquirer.
29 [ 00200 ] In some embodiments, the pay network server may generate a query, e.g.,
30 1124, for issuer server(s) corresponding to the user-selected payment options. For
31 example, the user's account may be linked to one or more issuer financial institutions
32 ("issuers"), such as banking institutions, which issued the account(s) for the user. For
33 example, such accounts may include, but not be limited to: credit card, debit card,
34 prepaid card, checking, savings, money market, certificates of deposit, stored (cash)
35 value accounts and/or the like. Issuer server(s), e.g., 1106a, of the issuer(s) may
36 maintain details of the user's account(s). In some embodiments, a database, e.g., pay network database 1105b, may store details of the issuer server(s) associated with the issuer(s). In some embodiments, the pay network server may query a database, e.g., pay network database 1105b, for a network address of the issuer(s) server(s), for example by using a portion of a user payment card number, or a user ID (such as an email address) as a keyword for the database query. For example, the merchant server may issue PHP/SQL commands to query a database table (such as FIGURE 23, Issuers 23191) for network address(es) of the issuer (s) server (s). An example issuer server address(es) query 1124, substantially in the form of PHP/SQL commands, is provided below:
<?PHP
header (' Content-Type : text/plain');
mysql_connect ("254.93.179.112", $DBserver, $password) ; // access database server mysql_select_db ( "TSGS_DB . SQL" ) ; // select database table to search
//create query
$query = "SELECT issuer_id issuer_address issuer_URL issuer_name FROM IssuersTable WHERE card_num LIKE '%' $cardnum";
$result = mysql_query ( $query) ; // perform the search query
mysql_close ( "TSGS_DB . SQL" ) ; // close database access
?>
[ 0 0 20 1 ] In response to obtaining the issuer server query, e.g., 1124, the pay network database may provide, e.g., 1125, the requested issuer server data to the pay network server. In some embodiments, the pay network server may utilize the issuer server data to generate funds authorization request(s), e.g., 1126, for each of the issuer server(s) selected based on the pre-defined payment settings associated with the user's virtual wallet, and/or the user's payment options input, and provide the funds authorization request(s) to the issuer server (s). In some embodiments, the funds authorization request(s) may include details such as, but not limited to: the costs to the user involved in the transaction, card account details of the user, user billing and/or shipping information, and/or the like. An example listing of a funds authorization request 1126, substantially in the form of a HTTP(S) POST message including XML- formatted data, is provided below:
POST /fundsauthorizationrequest .php HTTP/1.1
Host: www.issuer.com
Content-Type: Application/XML
Content-Length: 624
<?XML version = "1.0" encoding = "UTF-8"?>
<funds_authorization_request>
<request_ID>VNEl39FK</request_ID>
<timestamp>2015-02-22 15 : 22 : 44</timestamp>
<debit_amount>$72.89</debit_amount>
<account_params>
<account> <account_type>debit</account_type>
<value_exchange_symbol>USD</value_exchange_symbol>
<account_number>123456789012345</account_number>
<account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW>1234</CW>
</account>
</account_params>
<! --optional parameters—>
<user_device_fingerprint>
<device_IP>192.168.23.126</device_IP>
<device_MAC>0123.4567.89ab</device_MAC>
<device_serial>312456768798765432</device_serial> <device_ECID>00000AEBCDF12345</device_ECID>
<device_identifier>j qp_air</device_identifier>
<device_UDID>21343e34-14f4-8jn4-7yfe-124578632134</device_UDID> <device_browser>firefox 2.2</device_browser>
<device_type>smartphone</device_type>
<device_model>HTC Hero</device_model>
<OS>Android 2.2</OS>
<wallet_app_installed_flag>true</wallet_app_installed_flag>
</user_device_fingerprint>
</ funds_authorization_request>
[00202] In some embodiments, an issuer server may parse the authorization request(s), and based on the request details may query a database, e.g., user profile database 1106b, for data associated with an account linked to the user. For example, the merchant server may issue PHP/SQL commands to query a database table (such as FIGURE 23, Accounts 23i9d) for user account(s) data. An example user account(s) query 1127, substantially in the form of PHP/SQL commands, is provided below:
<?PHP
header (' Content-Type : text/plain');
mysql_connect ("254.93.179.112", $DBserver, $password) ; // access database server mysql_select_db ( "TSGS_DB . SQL" ) ; // select database table to search
//create query
$query = "SELECT issuer user_id user_name user_balance account_type FROM AccountsTable WHERE account_num LIKE '%' $accountnum" ;
$result = mysql_query ( $query) ; // perform the search query
mysql_close ( "TSGS_DB . SQL" ) ; // close database access
?>
[00203] In some embodiments, on obtaining the user account(s) data, e.g., 1128, the issuer server may determine whether the user can pay for the transaction using funds available in the account, 1129. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like. Based on the determination, the issuer server(s) may provide a funds authorization response, e.g., 1130, to the pay network server. For example, the issuer server(s) may provide a HTTP(S) POST message similar to the examples above. In some embodiments, if at least one issuer server determines that the user cannot pay for the transaction using the funds available in the account, the pay network server may request payment options again from the user (e.g., by providing an authorization fail message to the user device and requesting the user device to provide new payment options), and re-attempt authorization for the purchase transaction. In some embodiments, if the number of failed authorization attempts exceeds a threshold, the pay network server may abort the authorization process, and provide an "authorization fail" message to the merchant server, user device and/or client. [ 00204 ] In some embodiments, the pay network server may obtain the funds authorization response including a notification of successful authorization, and parse the message to extract authorization details. Upon determining that the user possesses sufficient funds for the transaction, e.g., 1131, the pay network server may invoke a component to provide value-add services for the user. [ 00205] In some embodiments, the pay network server may generate a transaction data record from the authorization request and/or authorization response, and store the details of the transaction and authorization relating to the transaction in a transactions database. For example, the pay network server may issue PHP/SQL commands to store the data to a database table (such as FIGURE 23, Transactions 23191). An example transaction store command, substantially in the form of PHP/SQL commands, is provided below:
<?PHP
header (' Content-Type : text/plain');
mysql_connect ( "254.92.185.103", $DBserver, $password) ; // access database server mysql_select ( "TSGS_DB . SQL" ) ; // select database to append
mysql_query ("INSERT INTO TransactionsTable (PurchasesTable (timestamp,
purchase_summary_list, num_products , product_summary, product_quantity,
transaction_cost, account_params_list, account_name, account_type, account_num, billing_addres, zipcode, phone, sign, merchant_params_list, merchant_id,
merchant_name, merchant_auth_key)
VALUES (time(), $purchase_summary_list, $num_products , $product_summary,
$product_quantity, $transaction_cost, $account_params_list, $account_name,
$account_type, $account_num, $billing_addres, $zipcode, $phone, $sign,
$merchant_params_list, $merchant_id, $merchant_name, $merchant_auth_key ) " ) ; // add data to table in database
mysql_close ( "TSGS_DB . SQL" ) ; // close connection to database
? >
[ 00206 ] In some embodiments, the pay network server may forward a transaction authorization response, e.g., 1132, to the user wallet device, PoS client, and/or merchant server. The merchant may obtain the transaction authorization response, and determine from it that the user possesses sufficient funds in the card account to conduct the transaction. The merchant server may add a record of the transaction for the user to a batch of transaction data relating to authorized transactions. For example, the merchant may append the XML data pertaining to the user transaction to an XML data file comprising XML data for transactions that have been authorized for various users, e.g., 1133, and store the XML data file, e.g., 1134, in a database, e.g., merchant database 404. For example, a batch XML data file may be structured similar to the example XML data structure template provided below:
<?XML version = "1.0" encoding = "UTF-8"?>
<merchant_data>
<merchant_id>3FBCR4INC</merchant_id>
<merchant_name>Books & Things, Inc . </merchant_name>
<merchant_auth_key>lNNF484MCP59CHB27365</merchant_auth_key> <account_number>12345678 9< /account_number>
</merchant_data>
<transaction_data>
<transaction 1>
</ transaction 1>
<transaction 2>
</ transaction 2> <transaction n>
</ transaction n>
</transaction_data>
[ 00207] In some embodiments, the server may also generate a purchase receipt, e.g., 1133, and provide the purchase receipt to the client, e.g., 1135. The client may render and display, e.g., 1136, the purchase receipt for the user. In some embodiments, the user's wallet device may also provide a notification of successful authorization to the user. For example, the PoS client/user device may render a webpage, electronic message, text / SMS message, buffer a voicemail, emit a ring tone, and/or play an audio message, etc., and provide output including, but not limited to: sounds, music, audio, video, images, tactile feedback, vibration alerts (e.g., on vibration-capable client devices such as a smartphone etc.), and/or the like. [ 00208 ] FIGURES 12A-B show logic flow diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization ("PTA") component into a purchase transaction receipt notification. With reference to FIGURE 12A, in some embodiments, a user may wish to utilize a virtual wallet account to purchase a product, service, offering, and/or the like ("product"), from a merchant via a merchant online site or in the merchant's store. The user may utilize a physical card, or a user wallet device to access the user's virtual wallet account. For example, the user wallet device may be a personal/laptop computer, cellular telephone, smartphone, tablet, eBook reader, netbook, gaming console, and/or the like. The user may provide a wallet access input, e.g., 1201, into the user wallet device. In various embodiments, the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a touchscreen interface, keyboard entry, card swipe, activating a RFID/NFC equipped hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like. In some embodiments, the user wallet device may authenticate the user based on the user's wallet access input, and provide virtual wallet features for the user, e.g., 1202-1203. [ 00209 ] In some embodiments, upon authenticating the user for access to virtual wallet features, the user wallet device may provide a transaction authorization input, e.g., 1204, to a point-of-sale ("PoS") client. For example, the user wallet device may communicate with the PoS client via Bluetooth, Wi-Fi, cellular communication, one- or two- way near-field communication ("NFC"), and/or the like. In embodiments where the user utilizes a plastic card instead of the user wallet device, the user may swipe the plastic card at the PoS client to transfer information from the plastic card into the PoS client. In embodiments where the user utilizes a user wallet device, the user wallet device may provide payment information to the PoS client, formatted according to a data formatting protocol appropriate to the communication mechanism employed in the communication between the user wallet device and the PoS client. [ 00210 ] In some embodiments, the PoS client may obtain the transaction authorization input, and parse the input to extract payment information from the 1 transaction authorization input, e.g., 1205. For example, the PoS client may utilize a
2 parser, such as the example parsers provided below in the discussion with reference to
3 FIGURE 23. The PoS client may generate a card authorization request, e.g., 1206, using
4 the obtained transaction authorization input from the user wallet device, and/or
5 product/checkout data (see, e.g., FIGURE 9, 915-917).
6 [00211 ] In some embodiments, the PoS client may provide the generated card
7 authorization request to the merchant server. The merchant server may forward the
8 card authorization request to a pay gateway server, for routing the card authorization
9 request to the appropriate payment network for payment processing. For example, the
10 pay gateway server may be able to select from payment networks, such as Visa,
11 Mastercard, American Express, Paypal, etc., to process various types of transactions
12 including, but not limited to: credit card, debit card, prepaid card, B2B and/or like
13 transactions. In some embodiments, the merchant server may query a database, e.g.,
14 1208, for a network address of the payment gateway server, for example by using a portion of
15 a user payment card number, or a user ID (such as an email address) as a keyword for the
16 database query. In response, the merchant/acquirer database may provide the requested
17 payment gateway address, e.g., 1210. The merchant server may forward the card is authorization request to the pay gateway server using the provided address. In some
19 embodiments, upon receiving the card authorization request from the merchant server, the
20 pay gateway server may invoke a component to provide one or more service associated
21 with purchase transaction authorization, e.g., 1211. For example, the pay gateway server
22 may invoke components for fraud prevention (see e.g., VerifyChat, FIGURE 3E), loyalty
23 and/or rewards, and/or other services for which the user-merchant combination is
24 authorized.
25 [ 00212 ] The pay gateway server may forward the card authorization request to a
26 pay network server for payment processing, e.g., 1214. For example, the pay gateway
27 server may be able to select from payment networks, such as Visa, Mastercard,
28 American Express, Paypal, etc., to process various types of transactions including, but
29 not limited to: credit card, debit card, prepaid card, B2B and/or like transactions. In
30 some embodiments, the pay gateway server may query a database, e.g., 1212, for a
31 network address of the payment network server, for example by using a portion of a user 1 payment card number, or a user ID (such as an email address) as a keyword for the database
2 query. In response, the payment gateway database may provide the requested payment
3 network address, e.g., 1213. The pay gateway server may forward the card authorization
4 request to the pay network server using the provided address, e.g., 1214.
5 [ 00213 ] With reference to FIGURE 12B, in some embodiments, the pay network
6 server may process the transaction so as to transfer funds for the purchase into an
7 account stored on an acquirer of the merchant. For example, the acquirer may be a
8 financial institution maintaining an account of the merchant. For example, the
9 proceeds of transactions processed by the merchant may be deposited into an account
10 maintained by at a server of the acquirer. In some embodiments, the pay network
11 server may generate a query, e.g., 1215, for issuer server(s) corresponding to the user-
12 selected payment options. For example, the user's account may be linked to one or
13 more issuer financial institutions ("issuers"), such as banking institutions, which issued
14 the account(s) for the user. For example, such accounts may include, but not be limited
15 to: credit card, debit card, prepaid card, checking, savings, money market, certificates of
16 deposit, stored (cash) value accounts and/or the like. Issuer server(s) of the issuer(s)
17 may maintain details of the user's account(s). In some embodiments, a database, e.g., a
18 pay network database, may store details of the issuer server (s) associated with the
19 issuer(s). In some embodiments, the pay network server may query a database, e.g.,
20 1215, for a network address of the issuer(s) server(s), for example by using a portion of a user
21 payment card number, or a user ID (such as an email address) as a keyword for the database
22 query.
23 [ 00214] In response to obtaining the issuer server query, the pay network database
24 may provide, e.g., 1216, the requested issuer server data to the pay network server. In
25 some embodiments, the pay network server may utilize the issuer server data to
26 generate funds authorization request(s), e.g., 1217, for each of the issuer server(s)
27 selected based on the pre-defined payment settings associated with the user's virtual
28 wallet, and/or the user's payment options input, and provide the funds authorization
29 request(s) to the issuer server(s). In some embodiments, the funds authorization
30 request(s) may include details such as, but not limited to: the costs to the user involved
31 in the transaction, card account details of the user, user billing and/or shipping information, and/or the like. In some embodiments, an issuer server may parse the authorization request(s), e.g., 1218, and based on the request details may query a database, e.g., 1219, for data associated with an account linked to the user. [ 00215 ] In some embodiments, on obtaining the user account(s) data, e.g., 1220, the issuer server may determine whether the user can pay for the transaction using funds available in the account, e.g., 1221. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like. Based on the determination, the issuer server(s) may provide a funds authorization response, e.g., 1222, to the pay network server. In some embodiments, if at least one issuer server determines that the user cannot pay for the transaction using the funds available in the account, the pay network server may request payment options again from the user (e.g., by providing an authorization fail message to the user device and requesting the user device to provide new payment options), and re-attempt authorization for the purchase transaction. In some embodiments, if the number of failed authorization attempts exceeds a threshold, the pay network server may abort the authorization process, and provide an "authorization fail" message to the merchant server, user device and/or client. [ 00216 ] In some embodiments, the pay network server may obtain the funds authorization response including a notification of successful authorization, and parse the message to extract authorization details. Upon determining that the user possesses sufficient funds for the transaction, e.g., 1223, the pay network server may invoke a component to provide value-add services for the user, e.g., 1223. [ 00217] In some embodiments, the pay network server may forward a transaction authorization response to the user wallet device, PoS client, and/or merchant server. The merchant may parse, e.g., 1224, the transaction authorization response, and determine from it that the user possesses sufficient funds in the card account to conduct the transaction, e.g., 1225, option"Yes." The merchant server may add a record of the transaction for the user to a batch of transaction data relating to authorized transactions. For example, the merchant may append the XML data pertaining to the user transaction to an XML data file comprising XML data for transactions that have been authorized for various users, e.g., 1226, and store the XML data file, e.g., 1227, in a 1 database. In some embodiments, the server may also generate a purchase receipt, e.g.,
2 1228, and provide the purchase receipt to the client. The client may render and display,
3 e.g., 1229, the purchase receipt for the user. In some embodiments, the user's wallet
4 device may also provide a notification of successful authorization to the user. For
5 example, the PoS client/user device may render a webpage, electronic message, text /
6 SMS message, buffer a voicemail, emit a ring tone, and/or play an audio message, etc.,
7 and provide output including, but not limited to: sounds, music, audio, video, images,
8 tactile feedback, vibration alerts (e.g., on vibration-capable client devices such as a
9 smartphone etc.), and/or the like. 0 [ 00218 ] FIGURES 13A-B show data flow diagrams illustrating example aspects of1 transforming a merchant transaction batch data query via a Purchase Transaction2 Clearance ("PTC") component into an updated payment ledger record. With reference3 to FIGURE 13A, in some embodiments, a merchant server, e.g., 1303a, may initiate4 clearance of a batch of authorized transactions. For example, the merchant server may5 generate a batch data request, e.g., 1311, and provide the request, to a merchant6 database, e.g., 1303b. For example, the merchant server may utilize PHP/SQL7 commands similar to the examples provided above to query a relational database. Ins response to the batch data request, the database may provide the requested batch data,9 e.g., 1312. The server may generate a batch clearance request, e.g., 1313, using the batch0 data obtained from the database, and provide, e.g., 1314, the batch clearance request to1 an acquirer server, e.g., 1307a. For example, the merchant server may provide a2 HTTP(S) POST message including XML-formatted batch data in the message body for3 the acquirer server. The acquirer server may generate, e.g., 1315, a batch payment4 request using the obtained batch clearance request, and provide, e.g., 1318, the batch5 payment request to the pay network server, e.g., 1305a. The pay network server may6 parse the batch payment request, and extract the transaction data for each transaction7 stored in the batch payment request, e.g., 1319. The pay network server may store the8 transaction data, e.g., 1320, for each transaction in a database, e.g., pay network9 database 1305b. In some embodiments, the pay network server may invoke a0 component to provide value-add analytics services based on analysis of the transactions1 of the merchant for whom the TSGS is clearing purchase transactions. Thus, in some embodiments, the pay network server may provide analytics-based value-added services for the merchant and/ or the merchant's users. [ 00219 ] With reference to FIGURE 13B, in some embodiments, for each extracted transaction, the pay network server may query, e.g., 1323, a database, e.g., pay network database 1305b, for an address of an issuer server. For example, the pay network server may utilize PHP/SQL commands similar to the examples provided above. The pay network server may generate an individual payment request, e.g., 1325, for each transaction for which it has extracted transaction data, and provide the individual payment request, e.g., 1325, to the issuer server, e.g., 1306a. For example, the pay network server may provide an individual payment request to the issuer server (s) as a HTTP(S) POST message including XML-formatted data. An example listing of an individual payment request 1325, substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below:
POST /paymentrequest . php HTTP/1.1
Host: www.issuer.com
Content-Type: Application/XML
Content-Length: 788
<?XML version = "1.0" encoding = "UTF-8"?>
<pay_request>
<request_ID>CNI4ICNW2</request_ID>
<timestamp>2015-02-22 17 : 00 : 01</timestamp>
<pay_amount>$72.89</pay_amount>
<account_params>
<account>
<account_type>debit</account_type>
<value_exchange_symbol>USD</value_exchange_symbol>
<account_number>123456789012345</account_number>
<account_name>John Q. Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW>1234</CW>
</account>
</account_params>
</pay_request>
[ 00220 ] In some embodiments, the issuer server may generate a payment command, e.g., 1327. For example, the issuer server may issue a command to deduct funds from the user's account (or add a charge to the user's credit card account). The issuer server may issue a payment command, e.g., 1327, to a database storing the user's account information, e.g., user profile database 1306b. The issuer server may provide an individual payment confirmation, e.g., 1328, to the pay network server, which may forward, e.g., 1329, the funds transfer message to the acquirer server. An example listing of an individual payment confirmation 1328, substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below:
POST /clearance .php HTTP/1.1
Host: www.acquirer.com
Content-Type: Application/XML
Content-Length: 206
<?XML version = "1.0" encoding = "UTF-8"?>
<deposit_ack>
<request_ID>CNI4ICNW2</request_ID>
<clear_flag>true</clear_flag>
<timestamp>2015-02-22 17 : 00 : 02</timestamp>
<deposit_amount>$72.89</deposit_amount>
</deposit_ack>
[ 0 0 22 1 ] In some embodiments, the acquirer server may parse the individual payment confirmation, and correlate the transaction (e.g., using the request_ID field in the example above) to the merchant. The acquirer server may then transfer the funds specified in the funds transfer message to an account of the merchant. For example, the acquirer server may query, e.g. 1330, an acquirer database 1307b for payment ledger and/or merchant account data, e.g., 1331. The acquirer server may utilize payment ledger and/or merchant account data from the acquirer database, along with the individual payment confirmation, to generate updated payment ledger and/or merchant account data, e.g., 1332. The acquirer server may then store, e.g., 1333, the updated payment ledger and/or merchant account data to the acquire database.
[ 0 0 2 22 ] FIGURES 14A-B show logic flow diagrams illustrating example aspects of transforming a merchant transaction batch data query via a Purchase Transaction Clearance ("PTC") component into an updated payment ledger record. With reference to FIGURE 14A, in some embodiments, a merchant server may initiate clearance of a batch of authorized transactions. For example, the merchant server may generate a batch data request, e.g., 1401, and provide the request to a merchant database. In response to the batch data request, the database may provide the requested batch data, e.g., 1402. The server may generate a batch clearance request, e.g., 1403, using the batch data obtained from the database, and provide the batch clearance request to an acquirer server. The acquirer server may parse, e.g., 1404, the obtained batch clearance request, and generate, e.g., 1407, a batch payment request using the obtained batch clearance request to provide, the batch payment request to a pay network server. For example, the acquirer server may query, e.g., 1405, an acquirer database for an address 1 of a payment network server, and utilize the obtained address, e.g., 1406, to forward the
2 generated batch payment request to the pay network server.
3 [ 00223 ] The pay network server may parse the batch payment request obtained
4 from the acquirer server, and extract the transaction data for each transaction stored in
5 the batch payment request, e.g., 1408. The pay network server may store the transaction
6 data, e.g., 1409, for each transaction in a pay network database. In some embodiments,
7 the pay network server may invoke a component, e.g., 1410, to provide analytics based
8 on the transactions of the merchant for whom purchase transaction are being cleared.
9 [ 00224] With reference to FIGURE 14B, in some embodiments, for each extracted
10 transaction, the pay network server may query, e.g., 1411, a pay network database for an
11 address of an issuer server. The pay network server may generate an individual
12 payment request, e.g., 1413, for each transaction for which it has extracted transaction
13 data, and provide the individual payment request to the issuer server. In some
14 embodiments, the issuer server may parse the individual payment request, e.g., 1414,
15 and generate a payment command, e.g., 1415, based on the parsed individual payment
16 request. For example, the issuer server may issue a command to deduct funds from the
17 user's account (or add a charge to the user's credit card account). The issuer server may is issue a payment command, e.g., 1415, to a database storing the user's account
19 information, e.g., a user profile database. The issuer server may provide an individual
20 payment confirmation, e.g., 1417, to the pay network server, which may forward, e.g.,
21 1418, the individual payment confirmation to the acquirer server.
22 [ 00225 ] In some embodiments, the acquirer server may parse the individual
23 payment confirmation, and correlate the transaction (e.g., using the request_ID field in
24 the example above) to the merchant. The acquirer server may then transfer the funds
25 specified in the funds transfer message to an account of the merchant. For example, the
26 acquirer server may query, e.g. 1419, an acquirer database for payment ledger and/or
27 merchant account data, e.g., 1420. The acquirer server may utilize payment ledger
28 and/or merchant account data from the acquirer database, along with the individual
29 payment confirmation, to generate updated payment ledger and/or merchant account
30 data, e.g., 1421. The acquirer server may then store, e.g., 1422, the updated payment
31 ledger and/or merchant account data to the acquire database. [ 00226 ] FIGURE 15 shows a user interface diagram illustrating an overview of example features of virtual wallet applications in some embodiments of the TSGS. FIGURE 15 shows an illustration of various exemplary features of a virtual wallet mobile application 1500. Some of the features displayed include a wallet 1501, social integration via TWITTER, FACEBOOK, etc., offers and loyalty 1503, snap mobile purchase 1504, alerts 1505 and security, setting and analytics 1596. These features are explored in further detail below. [ 00227] FIGURES 16A-G show user interface diagrams illustrating example features of virtual wallet applications in a shopping mode, in some embodiments of the TSGS. With reference to FIGURE 16A, some embodiments of the virtual wallet mobile app facilitate and greatly enhance the shopping experience of consumers. A variety of shopping modes, as shown in FIGURE 16A, may be available for a consumer to peruse. In one implementation, for example, a user may launch the shopping mode by selecting the shop icon 1610 at the bottom of the user interface. A user may type in an item in the search field 1612 to search and/or add an item to a cart 1611. A user may also use a voice activated shopping mode by saying the name or description of an item to be searched and/or added to the cart into a microphone 1613. In a further implementation, a user may also select other shopping options 1614 such as current items 1615, bills 1616, address book 1617, merchants 1618 and local proximity 1619. [ 00228 ] In one embodiment, for example, a user may select the option current items 1615, as shown in the left most user interface of FIGURE 16A. When the current items 1615 option is selected, the middle user interface may be displayed. As shown, the middle user interface may provide a current list of items i6isa-h in a user's shopping cart 1611. A user may select an item, for example item 1615a, to view product description i6i5j of the selected item and/or other items from the same merchant. The price and total payable information may also be displayed, along with a QR code 1615k that captures the information necessary to effect a snap mobile purchase transaction.
[ 00229 ] With reference to FIGURE 16B, in another embodiment, a user may select the bills 1616 option. Upon selecting the bills 1616 option, the user interface may display a list of bills and/or receipts i6i6a-h from one or more merchants. Next to each of the bills, additional information such as date of visit, whether items from multiple stores are present, last bill payment date, auto-payment, number of items, and/or the like may be displayed. In one example, the wallet shop bill 1616a dated January 20, 2015 may be selected. The wallet shop bill selection may display a user interface that provides a variety of information regarding the selected bill. For example, the user interface may display a list of items 1616k purchased, <<i6i6i>>, a total number of items and the corresponding value. For example, 7 items worth $102.54 were in the selected wallet shop bill. A user may now select any of the items and select buy again to add purchase the items. The user may also refresh offers i6i6j to clear any invalid offers from last time and/or search for new offers that may be applicable for the current purchase. As shown in FIGURE 16B, a user may select two items for repeat purchase. Upon addition, a message 1616I may be displayed to confirm the addition of the two items, which makes the total number of items in the cart 14. [ 00230 ] With reference to FIGURE 16C, in yet another embodiment, a user may select the address book option 1617 to view the address book 1617a which includes a list of contacts 1617b and make any money transfers or payments. In one embodiment, the address book may identify each contact using their names and available and/or preferred modes of payment. For example, a contact Amanda G. may be paid via social pay (e.g., via FACEBOOK) as indicated by the icon 1617c. In another example, money may be transferred to Brian S. via QR code as indicated by the QR code icon i6i7d. In yet another example, Charles B. may accept payment via near field communication i6i7e, Bluetooth i6i7f and email i6i7g. Payment may also be made via USB 1617I1 (e.g., by physically connecting two mobile devices) as well as other social channels such as TWITTER. [ 00231] In one implementation, a user may select Joe P. for payment. Joe P., as shown in the user interface, has an email icon i6i7g next to his name indicating that Joe P. accepts payment via email. When his name is selected, the user interface may display his contact information such as email, phone, etc. If a user wishes to make a payment to Joe P. by a method other than email, the user may add another transfer mode i6i7j to his contact information and make a payment transfer. With reference to FIGURE 16D, the user may be provided with a screen 1617k where the user can enter an amount to send Joe, as well as add other text to provide Joe with context for the payment 1 transaction 1617I. The user can choose modes (e.g., SMS, email, social networking) via
2 which Joe may be contacted via graphical user interface elements, 1617m. As the user
3 types, the text entered may be provided for review within a GUI element 1617η. When
4 the user has completed entering in the necessary information, the user can press the
5 send button 16170 to send the social message to Joe. If Joe also has a virtual wallet
6 application, Joe may be able to review 1617P social pay message within the app, or
7 directly at the website of the social network (e.g., for Twitter™, Facebook®, etc.).
8 Messages may be aggregated from the various social networks and other sources (e.g.,
9 SMS, email). The method of redemption appropriate for each messaging mode may be
10 indicated along with the social pay message. In the illustration in FIGURE 16D, the
11 SMS i6i7q Joe received indicates that Joe can redeem the $5 obtained via SMS by
12 replying to the SMS and entering the hash tag value '#1234'. In the same illustration,
13 Joe has also received a message i6i7r via Facebook®, which includes a URL link that
14 Joe can activate to initiate redemption of the $25 payment.
15 [00232] With reference to FIGURE 16E, in some other embodiments, a user may
16 select merchants 1618 from the list of options in the shopping mode to view a select list
17 of merchants i6i8a-e. In one implementation, the merchants in the list may be affiliated
18 to the wallet, or have affinity relationship with the wallet. In another implementation,
19 the merchants may include a list of merchants meeting a user-defined or other criteria.
20 For example, the list may be one that is curated by the user, merchants where the user
21 most frequently shops or spends more than an x amount of sum or shopped for three
22 consecutive months, and/or the like. In one implementation, the user may further select
23 one of the merchants, Amazon 1618a for example. The user may then navigate through
24 the merchant's listings to find items of interest such as i6i8f-j. Directly through the
25 wallet and without visiting the merchant site from a separate page, the user may make a
26 selection of an item i6i8j from the catalog of Amazon 1618a. As shown in the right most
27 user interface of FIGURE 16D, the selected item may then be added to cart. The message
28 1618k indicates that the selected item has been added to the cart, and updated number
29 of items in the cart is now 13.
30 [00233] With reference to FIGURE 16F, in one embodiment, there may be a local
31 proximity option 1619 which may be selected by a user to view a list of merchants that are geographically in close proximity to the user. For example, the list of merchants i6i9a-e may be the merchants that are located close to the user. In one implementation, the mobile application may further identify when the user in a store based on the user's location. For example, position icon i6i9d may be displayed next to a store (e.g., Walgreens) when the user is in close proximity to the store. In one implementation, the mobile application may refresh its location periodically in case the user moved away from the store (e.g., Walgreens). In a further implementation, the user may navigate the offerings of the selected Walgreens store through the mobile application. For example, the user may navigate, using the mobile application, to items i6i9f-j available on aisle 5 of Walgreens. In one implementation, the user may select corn 16191 from his or her mobile application to add to cart 1619k. [00234] With reference to FIGURE 16G, in another embodiment, the local proximity option 1619 may include a store map and a real time map features among others. For example, upon selecting the Walgreens store, the user may launch an aisle map 1619I which displays a map 1619m showing the organization of the store and the position of the user (indicated by a yellow circle). In one implementation, the user may easily configure the map to add one or more other users (e.g., user's kids) to share each other's location within the store. In another implementation, the user may have the option to launch a "store view" similar to street views in maps. The store view 1619η may display images/video of the user's surrounding. For example, if the user is about to enter aisle 5, the store view map may show the view of aisle 5. Further the user may manipulate the orientation of the map using the navigation tool 16190 to move the store view forwards, backwards, right, left as well clockwise and counterclockwise rotation
[00235] FIGURES 17A-F show user interface diagrams illustrating example features of virtual wallet applications in a payment mode, in some embodiments of the TSGS. With reference to FIGURE 17A, in one embodiment, the wallet mobile application may provide a user with a number of options for paying for a transaction via the wallet mode 1710. In one implementation, an example user interface 1711 for making a payment is shown. The user interface may clearly identify the amount 1712 and the currency 1713 for the transaction. The amount may be the amount payable and the currency may include real currencies such as dollars and euros, as well as virtual currencies such as reward points. The amount of the transaction 1714 may also be prominently displayed on the user interface. The user may select the funds tab 1716 to select one or more forms of payment 1717, which may include various credit, debit, gift, rewards and/or prepaid cards. The user may also have the option of paying, wholly or in part, with reward points. For example, the graphical indicator 1718 on the user interface shows the number of points available, the graphical indicator 1719 shows the number of points to be used towards the amount due 234.56 and the equivalent 1720 of the number of points in a selected currency (USD, for example). [ 00236] In one implementation, the user may combine funds from multiple sources to pay for the transaction. The amount 1715 displayed on the user interface may provide an indication of the amount of total funds covered so far by the selected forms of payment (e.g., Discover card and rewards points). The user may choose another form of payment or adjust the amount to be debited from one or more forms of payment until the amount 1715 matches the amount payable 1714. Once the amounts to be debited from one or more forms of payment are finalized by the user, payment authorization may begin. [ 00237] In one implementation, the user may select a secure authorization of the transaction by selecting the cloak button 1722 to effectively cloak or anonymize some (e.g., pre-configured) or all identifying information such that when the user selects pay button 1721, the transaction authorization is conducted in a secure and anonymous manner. In another implementation, the user may select the pay button 1721 which may use standard authorization techniques for transaction processing. In yet another implementation, when the user selects the social button 1723, a message regarding the transaction may be communicated to one of more social networks (set up by the user) which may post or announce the purchase transaction in a social forum such as a wall post or a tweet. In one implementation, the user may select a social payment processing option 1723. The indicator 1724 may show the authorizing and sending social share data in progress. [ 00238 ] In another implementation, a restricted payment mode 1725 may be activated for certain purchase activities such as prescription purchases. The mode may be activated in accordance with rules defined by issuers, insurers, merchants, payment processor and/or other entities to facilitate processing of specialized goods and services. In this mode, the user may scroll down the list of forms of payments 1726 under the funds tab to select specialized accounts such as a flexible spending account (FSA) 1727, health savings account (HAS), and/or the like and amounts to be debited to the selected accounts. In one implementation, such restricted payment mode 1725 processing may disable social sharing of purchase information. [00239] In one embodiment, the wallet mobile application may facilitate importing of funds via the import funds user interface 1728. For example, a user who is unemployed may obtain unemployment benefit fund 1729 via the wallet mobile application. In one implementation, the entity providing the funds may also configure rules for using the fund as shown by the processing indicator message 1730. The wallet may read and apply the rules prior, and may reject any purchases with the unemployment funds that fail to meet the criteria set by the rules. Example criteria may include, for example, merchant category code (MCC), time of transaction, location of transaction, and/or the like. As an example, a transaction with a grocery merchant having MCC 5411 may be approved, while a transaction with a bar merchant having an MCC 5813 may be refused. [ 00240 ] With reference to FIGURE 17B, in one embodiment, the wallet mobile application may facilitate dynamic payment optimization based on factors such as user location, preferences and currency value preferences among others. For example, when a user is in the United States, the country indicator 1731 may display a flag of the United States and may set the currency 1733 to the United States. In a further implementation, the wallet mobile application may automatically rearrange the order in which the forms of payments 1735 are listed to reflect the popularity or acceptability of various forms of payment. In one implementation, the arrangement may reflect the user's preference, which may not be changed by the wallet mobile application. [ 00241] Similarly, when a German user operates a wallet in Germany, the mobile wallet application user interface may be dynamically updated to reflect the country of operation 1732 and the currency 1734. In a further implementation, the wallet application may rearrange the order in which different forms of payment 1736 are listed based on their acceptance level in that country. Of course, the order of these forms of 1 payments may be modified by the user to suit his or her own preferences.
2 [ 00242 ] With reference to FIGURE 17C, in one embodiment, the payee tab 1737 in
3 the wallet mobile application user interface may facilitate user selection of one or more
4 payees receiving the funds selected in the funds tab. In one implementation, the user
5 interface may show a list of all payees 1738 with whom the user has previously
6 transacted or available to transact. The user may then select one or more payees. The
7 payees 1738 may include larger merchants such as Amazon.com Inc., and individuals
8 such as Jane P. Doe. Next to each payee name, a list of accepted payment modes for the
9 payee may be displayed. In one implementation, the user may select the payee Jane P.
10 Doe 1739 for receiving payment. Upon selection, the user interface may display
11 additional identifying information relating to the payee.
12 [ 00243 ] With reference to FIGURE 17D, in one embodiment, the mode tab 1740
13 may facilitate selection of a payment mode accepted by the payee. A number of payment
14 modes may be available for selection. Example modes include, blue tooth 1741, wireless
15 1742, snap mobile by user-obtained QR code 1743, secure chip 1744, TWITTER 1745,
16 near-field communication (NFC) 1746, cellular 1747, snap mobile by user-provided QR
17 code 1748, USB 1749 and FACEBOOK 1750, among others. In one implementation, only is the payment modes that are accepted by the payee may be selectable by the user. Other
19 non-accepted payment modes may be disabled.
20 [ 00244] With reference to FIGURE 17E, in one embodiment, the offers tab 1751
21 may provide real-time offers that are relevant to items in a user's cart for selection by
22 the user. The user may select one or more offers from the list of applicable offers 1752
23 for redemption. In one implementation, some offers may be combined, while others
24 may not. When the user selects an offer that may not be combined with another offer,
25 the unselected offers may be disabled. In a further implementation, offers that are
26 recommended by the wallet application's recommendation engine may be identified by
27 an indicator, such as the one shown by 1753. In a further implementation, the user may
28 read the details of the offer by expanding the offer row as shown by 1754 in the user
29 interface.
30 [ 00245 ] With reference to FIGURE 17F, in one embodiment, the social tab 1755 may facilitate integration of the wallet application with social channels 1756. In one implementation, a user may select one or more social channels 1756 and may sign in to the selected social channel from the wallet application by providing to the wallet application the social channel user name and password 1757 and signing in 1758. The user may then use the social button 1759 to send or receive money through the integrated social channels. In a further implementation, the user may send social share data such as purchase information or links through integrated social channels. In another embodiment, the user supplied login credentials may allow TSGS to engage in interception parsing. [00246] FIGURE 18 shows a user interface diagram illustrating example features of virtual wallet applications, in a history mode, in some embodiments of the TSGS. In one embodiment, a user may select the history mode 1810 to view a history of prior purchases and perform various actions on those prior purchases. For example, a user may enter a merchant identifying information such as name, product, MCC, and/or the like in the search bar 1811. In another implementation, the user may use voice activated search feature by clicking on the microphone icon 1814. The wallet application may query the storage areas in the mobile device or elsewhere (e.g., one or more databases and/or tables remote from the mobile device) for transactions matching the search keywords. The user interface may then display the results of the query such as transaction 1815. The user interface may also identify the date 1812 of the transaction, the merchants and items 1813 relating to the transaction, a barcode of the receipt confirming that a transaction was made, the amount of the transaction and any other relevant information. [00247] In one implementation, the user may select a transaction, for example transaction 1815, to view the details of the transaction. For example, the user may view the details of the items associated with the transaction and the amounts 1816 of each item. In a further implementation, the user may select the show option 1817 to view actions 1818 that the user may take in regards to the transaction or the items in the transaction. For example, the user may add a photo to the transaction (e.g., a picture of the user and the iPad the user bought). In a further implementation, if the user previously shared the purchase via social channels, a post including the photo may be generated and sent to the social channels for publishing. In one implementation, any sharing may be optional, and the user, who did not share the purchase via social channels, may still share the photo through one or more social channels of his or her choice directly from the history mode of the wallet application. In another implementation, the user may add the transaction to a group such as company expense, home expense, travel expense or other categories set up by the user. Such grouping may facilitate year-end accounting of expenses, submission of work expense reports, submission for value added tax (VAT) refunds, personal expenses, and/or the like. In yet another implementation, the user may buy one or more items purchased in the transaction. The user may then execute a transaction without going to the merchant catalog or site to find the items. In a further implementation, the user may also cart one or more items in the transaction for later purchase. [00248] The history mode, in another embodiment, may offer facilities for obtaining and displaying ratings 1819 of the items in the transaction. The source of the ratings may be the user, the user's friends (e.g., from social channels, contacts, etc.), reviews aggregated from the web, and/or the like. The user interface in some implementations may also allow the user to post messages to other users of social channels (e.g., TWITTER or FACEBOOK). For example, the display area 1820 shows FACEBOOK message exchanges between two users. In one implementation, a user may share a link via a message 1821. Selection of such a message having embedded link to a product may allow the user to view a description of the product and/or purchase the product directly from the history mode. [00249] In one embodiment, the history mode may also include facilities for exporting receipts. The export receipts pop up 1822 may provide a number of options for exporting the receipts of transactions in the history. For example, a user may use one or more of the options 1825, which include save (to local mobile memory, to server, to a cloud account, and/or the like), print to a printer, fax, email, and/or the like. The user may utilize his or her address book 1823 to look up email or fax number for exporting. The user may also specify format options 1824 for exporting receipts. Example format options may include, without limitation, text files (.doc, .txt, .rtf, iif, etc.), spreadsheet (.csv, .xls, etc.), image files (.jpg, .tff, .png, etc.), portable document format (.pdf), 1 postscript (.ps), and/or the like. The user may then click or tap the export button 1827 to
2 initiate export of receipts.
3 [ 00250 ] FIGURES 19A-E show user interface diagrams illustrating example
4 features of virtual wallet applications in a snap mode, in some embodiments of the
5 TSGS. With reference to FIGURE 19A, in one embodiment, a user may select the snap
6 mode 2110 to access its snap features. The snap mode may handle any machine-readable
7 representation of data. Examples of such data may include linear and 2D bar codes such
8 as UPC code and QR codes. These codes may be found on receipts, product packaging,
9 and/or the like. The snap mode may also process and handle pictures of receipts,
10 products, offers, credit cards or other payment devices, and/or the like. An example user
11 interface in snap mode is shown in FIGURE 19A. A user may use his or her mobile
12 phone to take a picture of a QR code 1915 and/or a barcode 1914. In one
13 implementation, the bar 1913 and snap frame 1915 may assist the user in snapping codes
14 properly. For example, the snap frame 1915, as shown, does not capture the entirety of
15 the code 1916. As such, the code captured in this view may not be resolvable as
16 information in the code may be incomplete. This is indicated by the message on the bar
17 1913 that indicates that the snap mode is still seeking the code. When the code 1916 is is completely framed by the snap frame 1915, the bar message may be updated to, for
19 example, "snap found." Upon finding the code, in one implementation, the user may
20 initiate code capture using the mobile device camera. In another implementation, the
21 snap mode may automatically snap the code using the mobile device camera.
22 [ 00251] With reference to FIGURE 19B, in one embodiment, the snap mode may
23 facilitate payment reallocation post transaction. For example, a user may buy grocery
24 and prescription items from a retailer Acme Supermarket. The user may, inadvertently
25 or for ease of checkout for example, use his or her Visa card to pay for both grocery and
26 prescription items. However, the user may have an FSA account that could be used to
27 pay for prescription items, and which would provide the user tax benefits. In such a
28 situation, the user may use the snap mode to initiate transaction reallocation.
29 [ 00252 ] As shown, the user may enter a search term (e.g., bills) in the search bar
30 2121. The user may then identify in the tab 1922 the receipt 1923 the user wants to
31 reallocate. Alternatively, the user may directly snap a picture of a barcode on a receipt, 1 and the snap mode may generate and display a receipt 1923 using information from the
2 barcode. The user may now reallocate 1925. In some implementations, the user may also
3 dispute the transaction 1924 or archive the receipt 1926.
4 [00253] In one implementation, when the reallocate button 1925 is selected, the
5 wallet application may perform optical character recognition (OCR) of the receipt. Each
6 of the items in the receipt may then be examined to identify one or more items which
7 could be charged to which payment device or account for tax or other benefits such as
8 cash back, reward points, etc. In this example, there is a tax benefit if the prescription
9 medication charged to the user's Visa card is charged to the user's FSA. The wallet
10 application may then perform the reallocation as the back end. The reallocation process
11 may include the wallet contacting the payment processor to credit the amount of the
12 prescription medication to the Visa card and debit the same amount to the user's FSA
13 account. In an alternate implementation, the payment processor (e.g., Visa or
14 MasterCard) may obtain and OCR the receipt, identify items and payment accounts for
15 reallocation and perform the reallocation. In one implementation, the wallet application
16 may request the user to confirm reallocation of charges for the selected items to another
17 payment account. The receipt 1927 may be generated after the completion of the
18 reallocation process. As discussed, the receipt shows that some charges have been
19 moved from the Visa account to the FSA.
20 [ 00254] With reference to FIGURE 19C, in one embodiment, the snap mode may
21 facilitate payment via pay code such as barcodes or QR codes. For example, a user may
22 snap a QR code of a transaction that is not yet complete. The QR code may be displayed
23 at a merchant POS terminal, a web site, or a web application and may be encoded with
24 information identifying items for purchase, merchant details and other relevant
25 information. When the user snaps such as a QR code, the snap mode may decode the
26 information in the QR code and may use the decoded information to generate a receipt
27 1932. Once the QR code is identified, the navigation bar 1931 may indicate that the pay
28 code is identified. The user may now have an option to add to cart 1933, pay with a
29 default payment account 1934 or pay with wallet 1935.
30 [ 00255] In one implementation, the user may decide to pay with default 1934. The
31 wallet application may then use the user's default method of payment, in this example 1 the wallet, to complete the purchase transaction. Upon completion of the transaction, a
2 receipt may be automatically generated for proof of purchase. The user interface may
3 also be updated to provide other options for handling a completed transaction. Example
4 options include social 1937 to share purchase information with others, reallocate 1938 as
5 discussed with regard to FIGURE 19B, and archive 1939 to store the receipt.
6 [ 00256 ] With reference to FIGURE 19D, in one embodiment, the snap mode may
7 also facilitate offer identification, application and storage for future use. For example, in
8 one implementation, a user may snap an offer code 1941 (e.g., a bar code, a QR code,
9 and/or the like). The wallet application may then generate an offer text 1942 from the
10 information encoded in the offer code. The user may perform a number of actions on the
11 offer code. For example, the user use the find button 1943 to find all merchants who
12 accept the offer code, merchants in the proximity who accept the offer code, products
13 from merchants that qualify for the offer code, and/or the like. The user may also apply
14 the offer code to items that are currently in the cart using the add to cart button 1944.
15 Furthermore, the user may also save the offer for future use by selecting the save button
16 1945.
17 [ 00257] In one implementation, after the offer or coupon 1946 is applied, the user
18 may have the option to find qualifying merchants and/or products using find, the user
19 may go to the wallet using 1948, and the user may also save the offer or coupon 1946 for
20 later use.
21 [ 00258 ] With reference to FIGURE 19E, in one embodiment, the snap mode may
22 also offer facilities for adding a funding source to the wallet application. In one
23 implementation, a pay card such as a credit card, debit card, pre-paid card, smart card
24 and other pay accounts may have an associated code such as a bar code or QR code.
25 Such a code may have encoded therein pay card information including, but not limited
26 to, name, address, pay card type, pay card account details, balance amount, spending
27 limit, rewards balance, and/or the like. In one implementation, the code may be found
28 on a face of the physical pay card. In another implementation, the code may be obtained
29 by accessing an associated online account or another secure location. In yet another
30 implementation, the code may be printed on a letter accompanying the pay card. A user,
31 in one implementation, may snap a picture of the code. The wallet application may identify the pay card 1951 and may display the textual information 1952 encoded in the pay card. The user may then perform verification of the information 1952 by selecting the verify button 1953. In one implementation, the verification may include contacting the issuer of the pay card for confirmation of the decoded information 1952 and any other relevant information. In one implementation, the user may add the pay card to the wallet by selecting the 'add to wallet' button 1954. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 1716 discussed in FIGURE 17A. The user may also cancel importing of the pay card as a funding source by selecting the cancel button 1955. When the pay card has been added to the wallet, the user interface may be updated to indicate that the importing is complete via the notification display 1956. The user may then access the wallet 1957 to begin using the added pay card as a funding source.
[00259] FIGURE 20 shows a user interface diagram illustrating example features of virtual wallet applications, in an offers mode, in some embodiments of the TSGS. In some implementations, the TSGS may allow a user to search for offers for products and/or services from within the virtual wallet mobile application. For example, the user may enter text into a graphical user interface ("GUI") element 2011, or issue voice commands by activating GUI element 2012 and speaking commands into the device. In some implementations, the TSGS may provide offers based on the user's prior behavior, demographics, current location, current cart selection or purchase items, and/or the like. For example, if a user is in a brick-and-mortar store, or an online shopping website, and leaves the (virtual) store, then the merchant associated with the store may desire to provide a sweetener deal to entice the consumer back into the (virtual) store. The merchant may provide such an offer 2013. For example, the offer may provide a discount, and may include an expiry time. In some implementations, other users may provide gifts (e.g., 2014) to the user, which the user may redeem. In some implementations, the offers section may include alerts as to payment of funds outstanding to other users (e.g., 2015). In some implementations, the offers section may include alerts as to requesting receipt of funds from other users (e.g., 2016). For example, such a feature may identify funds receivable from other applications (e.g., mail, calendar, tasks, notes, reminder programs, alarm, etc.), or by a manual entry by 1 the user into the virtual wallet application. In some implementations, the offers section
2 may provide offers from participating merchants in the TSGS, e.g., 2017-2019, 2020.
3 These offers may sometimes be assembled using a combination of participating
4 merchants, e.g., 2017. In some implementations, the TSGS itself may provide offers for
5 users contingent on the user utilizing particular payment forms from within the virtual
6 wallet application, e.g., 2020.
7 [ 00260 ] FIGURES 21A-B show user interface diagrams illustrating example
8 features of virtual wallet applications, in a security and privacy mode, in some
9 embodiments of the TSGS. With reference to FIGURE 21A, in some implementations,
10 the user may be able to view and/or modify the user profile and/or settings of the user,
11 e.g., by activating a user interface element. For example, the user may be able to
12 view/modify a user name (e.g., 2ina-b), account number (e.g., 2ii2a-b), user security
13 access code (e.g., 2113-b), user pin (e.g., 2114-b), user address (e.g., 2115-b), social
14 security number associated with the user (e.g., 2116-b), current device GPS location
15 (e.g., 2117-b), user account of the merchant in whose store the user currently is (e.g.,
16 2118-b), the user's rewards accounts (e.g., 2119-b), and/or the like. In some
17 implementations, the user may be able to select which of the data fields and their
18 associated values should be transmitted to facilitate the purchase transaction, thus
19 providing enhanced data security for the user. For example, in the example illustration
20 in FIGURE 21A, the user has selected the name 2111a, account number 2112a, security
21 code 2113a, merchant account ID 2118a and rewards account ID 2119a as the fields to be
22 sent as part of the notification to process the purchase transaction. In some
23 implementations, the user may toggle the fields and/or data values that are sent as part
24 of the notification to process the purchase transactions. In some implementations, the
25 app may provide multiple screens of data fields and/or associated values stored for the
26 user to select as part of the purchase order transmission. In some implementations, the
27 app may provide the TSGS with the GPS location of the user. Based on the GPS location
28 of the user, the TSGS may determine the context of the user (e.g., whether the user is in
29 a store, doctor's office, hospital, postal service office, etc.). Based on the context, the
30 user app may present the appropriate fields to the user, from which the user may select
31 fields and/or field values to send as part of the purchase order transmission. [ 00261] For example, a user may go to doctor's office and desire to pay the co-pay for doctor's appointment. In addition to basic transactional information such as account number and name, the app may provide the user the ability to select to transfer medical records, health information, which may be provided to the medical provider, insurance company, as well as the transaction processor to reconcile payments between the parties. In some implementations, the records may be sent in a Health Insurance Portability and Accountability Act (HIPAA)-compliant data format and encrypted, and only the recipients who are authorized to view such records may have appropriate decryption keys to decrypt and view the private user information. [ 00262 ] With reference to FIGURE 21B, in some implementations, the app executing on the user's device may provide a "VerifyChat" feature for fraud prevention. For example, the TSGS may detect an unusual and/or suspicious transaction. The TSGS 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 TSGS may send electronic mail message, text (SMS) messages, Facebook® messages, Twitter™ tweets, text chat, voice chat, video chat (e.g., Apple FaceTime), and/or the like to communicate with the user. For example, the TSGS may initiate a video challenge for the user, e.g., 2121. For example, the user may need to present him/her-self via a video chat, e.g., 2122. In some implementations, a customer service representative, e.g., agent 2124, may manually determine the authenticity of the user using the video of the user. In some implementations, the TSGS may utilize face, biometric and/or like recognition (e.g., using pattern classification techniques) to determine the identity of the user. In some implementations, the app may provide reference marker (e.g., cross-hairs, target box, etc.), e.g., 2123, so that the user may the video to facilitate the TSGS's automated recognition of the user. In some implementations, the user may not have initiated the transaction, e.g., the transaction is fraudulent. In such implementations, the user may cancel the challenge. The TSGS may then cancel the transaction, and/or initiate fraud investigation procedures on behalf of the user. [ 00263 ] In some implementations, the TSGS may utilize a text challenge procedure to verify the authenticity of the user, e.g., 2125. For example, the TSGS may 1 communicate with the user via text chat, SMS messages, electronic mail, Facebook®
2 messages, Twitter™ tweets, and/or the like. The TSGS may pose a challenge question,
3 e.g., 2126, for the user. The app may provide a user input interface element(s) (e.g.,
4 virtual keyboard 2128) to answer the challenge question posed by the TSGS. In some
5 implementations, the challenge question may be randomly selected by the TSGS
6 automatically; in some implementations, a customer service representative may
7 manually communicate with the user. In some implementations, the user may not have
8 initiated the transaction, e.g., the transaction is fraudulent. In such implementations,
9 the user may cancel the text challenge. The TSGS may cancel the transaction, and/or
10 initiate fraud investigation on behalf of the user.
11 [00264] FIGURES 22A-F include example data flows, where the TSGS may be
12 effected, and illustrates various additional advantageous aspects of the TSGS. With
13 reference to FIGURES 22A-D, effectuation of the TSGS may include additional example
14 embodiments such as those depicted in sub-figures (a)-(p). With reference to FIGURE
15 22E, in some embodiments, the TSGS may apply graduated authentication and fraud
16 review appropriate to the action being taken, and may thus mitigate risk in a variety of
17 risk areas, as illustrated. With reference to FIGURE 22F, in some embodiments, the
18 TSGS may provide graduated authentication-based consumer protection. Consumer
19 registration may be graduated based on the source of the registration and the actions
20 being taken. Some embodiments may reduce consumer enrollment friction using
21 features such as Visa RightCliq. For example, a consumer registering from a
22 participating issuer's website through a secure session may already have been screened
23 by the issuer; in such implementations, the enrollment process may be less intrusive to
24 the consumer than if they came directly to the enrollment site. The TSGS may utilize
25 tools to evaluate risk of a consumer including, without limitation, device firngerprint
26 and IP geolocation information, consumer entered data including email address,
27 consumer settings and consumer /virtual wallet interaction. For example, an example
28 consumer login may be made frictionless - the TSGS may vary authentication methods
29 so that the consumer does not feel that they are being challenged every time they take an
30 action. TSGS Controller
[ 00265 ] FIGURE 23 shows a block diagram illustrating example aspects of a TSGS controller 2301. In this embodiment, the TSGS controller 2301 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through various technologies, and/or other related data. [ 00266 ] Users, e.g., 2333a, which may be people and/or other systems, may engage information technology systems (e.g., computers) to facilitate information processing. In turn, computers employ processors to process information; such processors 2303 may be referred to as central processing units (CPU). One form of processor is referred to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory 2329 (e.g., registers, cache memory, random access memory, etc.). Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, which, may be executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources. Some resources that may be employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. These information technology systems may be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through a database program. These information technology systems provide interfaces that allow users to access and operate various system components. [ 00267] In one embodiment, the TSGS controller 2301 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user 1 input devices 2311; peripheral devices 2312; an optional cryptographic processor device
2 2328; and/or a communications network 2313. For example, the TSGS controller 2301
3 may be connected to and/or communicate with users, e.g., 2333a, operating client
4 device(s), e.g., 2333b, including, but not limited to, personal computer(s), server(s)
5 and/or various mobile device(s) including, but not limited to, cellular telephone(s),
6 smartphone(s) (e.g., iPhone®, Blackberry®, Android OS-based phones etc.), tablet
7 computer(s) (e.g., Apple iPad™, HP Slate™, Motorola Xoom™, etc.), eBook reader(s)
8 (e.g., Amazon Kindle™, Barnes and Noble's Nook™ eReader, etc.), laptop computer(s),
9 notebook(s), netbook(s), gaming console(s) (e.g., XBOX Live™, Nintendo® DS, Sony0 PlayStation® Portable, etc.), portable scanner(s), and/or the like. 1 [00268] Networks are commonly thought to comprise the interconnection and2 interoperation of clients, servers, and intermediary nodes in a graph topology. It should3 be noted that the term "server" as used throughout this application refers generally to a4 computer, other device, program, or combination thereof that processes and responds to5 the requests of remote users across a communications network. Servers serve their6 information to requesting "clients." The term "client" as used herein refers generally to a7 computer, program, other device, user and/or combination thereof that is capable of8 processing and making requests and obtaining and processing any responses from9 servers across a communications network. A computer, other device, program, or0 combination thereof that facilitates, processes information and requests, and/or1 furthers the passage of information from a source user to a destination user is2 commonly referred to as a "node." Networks are generally thought to facilitate the3 transfer of information from source points to destinations. A node specifically tasked4 with furthering the passage of information from a source to a destination is commonly5 called a "router." There are many forms of networks such as Local Area Networks6 (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc.7 For example, the Internet is generally accepted as being an interconnection of a8 multitude of networks whereby remote clients and servers may access and interoperate9 with one another. 0 [00269] The TSGS controller 2301 may be based on computer systems that may1 comprise, but are not limited to, components such as: a computer systemization 2302 1 connected to memory 2329.
2 Computer Systemization
3 [00270] A computer systemization 2302 may comprise a clock 2330, central
4 processing unit ("CPU(s)" and/or "processor(s)" (these terms are used interchangeably
5 throughout the disclosure unless noted to the contrary)) 2303, a memory 2329 (e.g., a
6 read only memory (ROM) 2306, a random access memory (RAM) 2305, etc.), and/or an
7 interface bus 2307, and most frequently, although not necessarily, are all interconnected
8 and/or communicating through a system bus 2304 on one or more (mother)board(s)
9 2302 having conductive and/or otherwise transportive circuit pathways through which
10 instructions (e.g., binary encoded signals) may travel to effectuate communications,
11 operations, storage, etc. The computer systemization may be connected to a power
12 source 2386; e.g., optionally the power source may be internal. Optionally, a
13 cryptographic processor 2326 and/or transceivers (e.g., ICs) 2374 may be connected to
14 the system bus. In another embodiment, the cryptographic processor and/or
15 transceivers may be connected as either internal and/or external peripheral devices
16 2312 via the interface bus I/O. In turn, the transceivers may be connected to antenna(s)
17 2375, thereby effectuating wireless transmission and reception of various
18 communication and/or sensor protocols; for example the antenna(s) may connect to: a
19 Texas Instruments WiLink WL1283 transceiver chip (e.g., providing 802.1m, Bluetooth
20 3.0, FM, global positioning system (GPS) (thereby allowing TSGS controller to
21 determine its location)); Broadcom BCM4329FKUBG transceiver chip (e.g., providing
22 802.1m, Bluetooth 2.1 + EDR, FM, etc.), BCM28150 (HSPA+) and BCM2076 (Bluetooth
23 4.0, GPS, etc.); a Broadcom BCM4750IUB8 receiver chip (e.g., GPS); an Infineon
24 Technologies X-Gold 618-PMB9800 (e.g., providing 2G/3G HSDPA/HSUPA
25 communications); Intel's XMM 7160 (LTE & DC-HSPA), Qualcom's CDMA(2000),
26 Mobile Data/Station Modem, Snapdragon; and/or the like. The system clock may have a
27 crystal oscillator and generates a base signal through the computer systemization's
28 circuit pathways. The clock may be coupled to the system bus and various clock
29 multipliers that may increase or decrease the base operating frequency for other
30 components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be referred to as communications. These communicative instructions may further be transmitted, received, and the cause of return and/or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. It should be understood that in alternative embodiments, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems. [ 00271 ] The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. Often, the processors themselves may incorporate various specialized processing units, such as, but not limited to: floating point units, integer processing units, integrated system (bus) controllers, logic operating units, memory management control units, etc., and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like. Additionally, processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 2329 beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state/value. The CPU may be a microprocessor such as: AMD's Athlon, Duron and/or Opteron; ARM's classic (e.g., ARM7/9/11), embedded (Coretx-M/R), application (Cortex-A), embedded and secure processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell processor; Intel's Atom, Celeron (Mobile), Core (2/Duo/i3/i5/i7), Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic and/or optic circuits) to execute stored instructions (i.e., program code). Such instruction passing facilitates communication within the TSGS controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed TSGS), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller mobile devices (e.g., smartphones, Personal Digital Assistants (PDAs), etc.) may be employed.
[00272] Depending on the particular implementation, features of the TSGS may be achieved by implementing a microcontroller such as CAST'S R8051XC2 microcontroller; Intel's MCS 51 (i.e., 8051 microcontroller); and/or the like. Also, to implement certain features of the TSGS, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the TSGS component collection (distributed or otherwise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of the TSGS may be implemented with embedded components that are configured and used to achieve a variety of features or signal processing. [00273] Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/ software solutions. For example, TSGS features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the TSGS features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the TSGS system designer/administrator, somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be programmed to perform the operation of basic logic gates such as AND, and XOR, or more complex combinational operators such as decoders or simple mathematical operations. In most FPGAs, the logic blocks also include memory elements, which may be circuit flip-flops or more complete blocks of memory. In some circumstances, the TSGS may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations. Alternate or coordinating implementations may migrate TSGS controller features to a final ASIC instead of or in addition to FPGAs. Depending on the implementation all of the aforementioned embedded components and microprocessors may be considered the "CPU" and/or "processor" for the TSGS. Power Source
[00274] The power source 2386 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy. The power cell 2386 is connected to at least one of the interconnected subsequent components of the TSGS thereby providing an electric current to all the interconnected components. In one example, the power source 2386 is connected to the system bus component 2304. In an alternative embodiment, an outside power source 2386 is provided through a connection across the I/O 2308 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power. Interface Adapters
[00275] Interface bus(ses) 2307 may accept, connect, and/or communicate to a number of interface adapters, frequently, although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 2308, storage interfaces 2309, network interfaces 2310, and/or the like. Optionally, cryptographic processor interfaces 2327 similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters may connect to the interface bus via expansion and/or slot architecture. Various expansion and/or slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, ExpressCard, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), Thunderbolt, and/or the like. [00276] Storage interfaces 2309 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 2314, removable disc devices, and/or the like. Storage interfaces may employ connection protocols 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, Ethernet, fiber channel, Small Computer Systems Interface (ASCASCI), Thunderbolt, Universal Serial Bus (USB), and/or the like. [00277] Network interfaces 2310 may accept, communicate, and/or connect to a communications network 2313. Through a communications network 2313, the TSGS controller is accessible through remote clients 2333b (e.g., computers with web browsers) by users 2333a. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 8o2.na-x, and/or the like. Should processing requirements dictate a greater amount speed and/or capacity, distributed network controllers (e.g., Distributed TSGS), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the TSGS controller. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces 2310 may be used to engage with various communications network types 2313. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks. [00278] Input Output interfaces (I/O) 2308 may accept, communicate, and/or connect to user input devices 2311, peripheral devices 2312, cryptographic processor devices 2328, and/or the like. I/O may employ connection protocols such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus (ADB), Bluetooth, IEEE I394a-b, serial, universal serial bus (USB); infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, DisplayPort, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless transceivers: 8o2.na/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/or the like. One output device may be a video display, which may take the form of a Cathode Ray Tube (CRT), Liquid Crystal Display (LCD), Light Emitting Diode (LED), Organic Light Emitting Diode (OLED), Plasma, and/or the like based monitor with an interface (e.g., VGA, DVI circuitry and cable) that accepts signals from a video interface. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Another output device is a television set, which accepts signals from a video interface. Often, the video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI connector accepting a DVI display cable, HDMI, etc.). [00279] User input devices 2311 often are a type of peripheral device 2312 (see below) and may include: card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors (e.g., accelerometers, ambient light, GPS, gyroscopes, proximity, etc.), styluses, and/or the like. [ 00280 ] Peripheral devices 2312 may be connected and/or communicate to I/O and/or other facilities of the like such as network interfaces, storage interfaces, directly to the interface bus, system bus, the CPU, and/or the like. Peripheral devices may be external, internal and/or part of the TSGS controller. Peripheral devices may include: antenna, audio devices (e.g., line-in, line-out, microphone input, speakers, etc.), cameras (e.g., still, video, webcam, etc.), dongles (e.g., for copy protection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added capabilities; e.g., crypto devices 2328), force-feedback devices (e.g., vibrating motors), near field communication (NFC) devices, network interfaces, printers, radio frequency identifiers (RFIDs), scanners, storage devices, transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, visors, and/or the like. Peripheral devices often include types of input devices (e.g., microphones, cameras, etc.). [ 00281 ] It should be noted that although user input devices and peripheral devices may be employed, the TSGS controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection. [ 00282 ] Cryptographic units such as, but not limited to, microcontrollers, processors 2326, interfaces 2327, and/or devices 2328 may be attached, and/or communicate with the TSGS controller. A MC68HC16 microcontroller, manufactured by Motorola Inc., may be used for and/or within cryptographic units. The MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions. Cryptographic units may also be configured as part of the CPU. Equivalent microcontrollers and/or processors may also be used. Other commercially available specialized cryptographic processors include: the Broadcom's CryptoNetX and other Security Processors; nCipher's nShield (e.g., Solo, Connect, etc.), SafeNet's Luna PCI (e.g., 7100) series; Semaphore Communications' 40 MHz Roadrunner 184; sMIP's (e.g., 208956); Sun's 1 Cryptographic Accelerators (e.g., Accelerator 6ooo PCIe Board, Accelerator 500
2 Daughtercard); Via Nano Processor (e.g., L2100, L2200, U2400) line, which is capable
3 of performing 500+ MB/s of cryptographic instructions; VLSI Technology's 33 MHz
4 6868; and/or the like.
5 Memory
6 [00283] Generally, any mechanization and/or embodiment allowing a processor to
7 affect the storage and/or retrieval of information is regarded as memory 2329. However,
8 memory is a fungible technology and resource, thus, any number of memory
9 embodiments may be employed in lieu of or in concert with one another. It is to be
10 understood that the TSGS controller and/or a computer systemization may employ
11 various forms of memory 2329. For example, a computer systemization may be
12 configured wherein the operation of on-chip CPU memory (e.g., registers), RAM, ROM,
13 and any other storage devices are provided by a paper punch tape or paper punch card
14 mechanism; however, such an embodiment would result in an extremely slow rate of
15 operation. In one configuration, memory 2329 may include ROM 2306, RAM 2305, and
16 a storage device 2314. A storage device 2314 may employ any number of computer
17 storage devices/systems. Storage devices may include a drum; a (fixed and/or
18 removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray,
19 CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.);
20 an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state
21 memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable
22 storage mediums; and/or other devices of the like. Thus, a computer systemization
23 generally requires and makes use of memory.
24 Component Collection
25 [00284] The memory 2329 may contain a collection of program and/or database
26 components and/or data such as, but not limited to: operating system component(s)
27 2315 (operating system); information server component(s) 2316 (information server);
28 user interface component(s) 2317 (user interface); Web browser component(s) 2318
29 (Web browser); database(s) 2319; mail server component(s) 2321; mail client 1 component(s) 2322; cryptographic server component(s) 2320 (cryptographic server);
2 the TSGS component(s) 2335; and/or the like (i.e., collectively a component collection).
3 These components may be stored and accessed from the storage devices and/or from
4 storage devices accessible through an interface bus. Although non-conventional
5 program components such as those in the component collection may be stored in a local
6 storage device 2314, they may also be loaded and/or stored in memory such as:
7 peripheral devices, RAM, remote storage facilities through a communications network,
8 ROM, various forms of memory, and/or the like.
9 Operating System
10 [00285] The operating system component 2315 is an executable program
11 component facilitating the operation of the TSGS controller. The operating system may
12 facilitate access of I/O, network interfaces, peripheral devices, storage devices, and/or
13 the like. The operating system may be a highly fault tolerant, scalable, and secure system
14 such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be OS; Unix and Unix-like
15 system distributions (such as AT&T's UNIX; Berkley Software Distribution (BSD)
16 variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributions
17 such as Red Hat, Ubuntu, and/or the like); and/or the like operating systems. However, is more limited and/or less secure operating systems also may be employed such as Apple
19 Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows
20 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like.
21 In addition, emobile operating systems such as Apple's iOS, Google's Android, Hewlett
22 Packard's WebOS, Microsofts Windows Mobile, and/or the like may be employed. Any
23 of these operating systems may be embedded within the hardware of the NICK
24 controller, and/or stored/loaded into memory/storage. An operating system may
25 communicate to and/or with other components in a component collection, including
26 itself, and/or the like. Most frequently, the operating system communicates with other
27 program components, user interfaces, and/or the like. For example, the operating
28 system may contain, communicate, generate, obtain, and/or provide program
29 component, system, user, and/or data communications, requests, and/or responses. The
30 operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like. The operating system may provide communications protocols that allow the TSGS controller to communicate with other entities through a communications network 2313. Various communication protocols may be used by the TSGS controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like. Information Server
[00286] An information server component 2316 is a stored program component that is executed by a CPU. The information server may be an Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the like. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM), Apple's iMessage, Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System 1 (DNS) resolution portion of an HTTP request is resolved to a particular information
2 server, the information server resolves requests for information at specified locations on
3 the TSGS controller based on the remainder of the HTTP request. For example, a
4 request such as http://123.124.125.126/myInformation.html might have the IP portion
5 of the request "123.124.125.126" resolved by a DNS server to an information server at
6 that IP address; that information server might in turn further parse the http request for
7 the "/mylnformation.html" portion of the request and resolve it to a location in memory
8 containing the information "mylnformation.html." Additionally, other information
9 serving protocols may be employed across various ports, e.g., FTP communications
10 across port 21, and/or the like. An information server may communicate to and/or with
11 other components in a component collection, including itself, and/or facilities of the
12 like. Most frequently, the information server communicates with the TSGS database
13 2319, operating systems, other program components, user interfaces, Web browsers,
14 and/or the like.
15 [00287] Access to the TSGS database may be achieved through a number of
16 database bridge mechanisms such as through scripting languages as enumerated below
17 (e.g., CGI) and through inter-application communication channels as enumerated below is (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed
19 through the bridge mechanism into appropriate grammars as required by the TSGS. In
20 one embodiment, the information server would provide a Web form accessible by a Web
21 browser. Entries made into supplied fields in the Web form are tagged as having been
22 entered into the particular fields, and parsed as such. The entered terms are then passed
23 along with the field tags, which act to instruct the parser to generate queries directed to
24 appropriate tables and/or fields. In one embodiment, the parser may generate queries in
25 standard SQL by instantiating a search string with the proper join/select commands
26 based on the tagged text entries, wherein the resulting command is provided over the
27 bridge mechanism to the TSGS as a query. Upon generating query results from the
28 query, the results are passed over the bridge mechanism, and may be parsed for
29 formatting and generation of a new results Web page by the bridge mechanism. Such a
30 new results Web page is then provided to the information server, which may supply it to
31 the requesting Web browser. [00288] Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. User Interface
[00289] Computer interfaces in some respects are similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, and status. Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, capabilities, operation, and display of data and computer hardware and operating system resources, and status. Operation interfaces are commonly called user interfaces. Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System's Aqua and iOS's Cocoa Touch, IBM's OS/2, Google's Android Mobile UI, Microsoft's Windows 2000/2003/3.1/95/98/CE/Millenium/ Mobile/NT/XP/Vista/7/8 (i.e., Aero, Metro), Unix's X-Windows (e.g., which may include additional Unix graphic 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.aculo.us, SWFObject, Yahoo! User Interface, any of which may be used and) provide a baseline and means of accessing and displaying information graphically to users.
[00290] A user interface component 2317 is a stored program component that is executed by a CPU. The user interface may be a graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system. A user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Web Browser
[00291] A Web browser component 2318 is a stored program component that is executed by a CPU. The Web browser may be a hypertext viewing application such as Goofle's (Mobile) Chrome, Microsoft Internet Explorer, Netscape Navigator, Apple's (Mobile) Safari, embedded web browser objects such as through Apple's Cocoa (Touch) object class, and/or the like. Secure Web browsing may be supplied with i28bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., Chrome, FireFox, Internet Explorer, Safari Plug-in, and/or the like APIs), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, smartphones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Also, in place of a Web browser and information server, a combined application may be developed to perform similar operations of both. The combined application would similarly effect the obtaining and the provision of information to users, user agents, and/or the like from the TSGS equipped nodes. The combined application may be nugatory on systems employing standard Web browsers. Mail Server
[00292] A mail server component 2321 is a stored program component that is executed by a CPU 2303. The mail server may be an Internet mail server such as, but not limited to Apple's Mail Server (3), dovect, sendmail, Microsoft Exchange, and/or the like. The mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traversing through and/or to the TSGS.
[00293] Access to the TSGS mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.
[00294] Also, a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Mail Client
[00295] A mail client component 2322 is a stored program component that is executed by a CPU 2303. The mail client may be a mail viewing application such as Apple (Mobile) Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages. Cryptographic Server
[00296] A cryptographic server component 2320 is a stored program component that is executed by a CPU 2303, cryptographic processor 2326, cryptographic processor interface 2327, cryptographic processor device 2328, and/or the like. Cryptographic processor interfaces may allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a CPU. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. The cryptographic component may facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash operation), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. Employing such encryption security protocols, the TSGS may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of "security authorization" whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for an digital audio file. A cryptographic component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable the TSGS component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on the TSGS and facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. The TSGS Database
[00297] The TSGS database component 2319 may be embodied in a database and its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data. The database may be any of a number of fault tolerant, relational, scalable, secure databases, such as DB2, MySQL, Oracle, Sybase, and/or the like. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the "one" side of a one-to-many relationship.
[00298] Alternatively, the TSGS database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of capabilities encapsulated within a given object. If the TSGS database is implemented as a data- structure, the use of the TSGS database 2319 may be integrated into another component such as the TSGS component 2335. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated. [ 00299 ] In one embodiment, the database component 2319 includes several tables 23i9a-s. A Users table 2319a may include fields such as, but not limited to: user_id, ssn, dob, first_name, last_name, age, state, address_firstline, address_secondline, zipcode, devices_list, contact_info, contact_type, alt_contact_info, alt_contact_type, username_domain, username (clear) including failed enroll/login attempt, username (hash) including failed enroll/login attempt, enrollment_date, wallet_age, date_first_transaction, date_last_transaction, number_cards, number_of addresses, new_enrollment_flag, verified_email_flag, enrollment_country, enrollment_source (issuer, merchant, dest site, etc.), enrollment_source_id (e.g., issuer id, merchant id), wallet settings (subscribed to alerts for a card, etc.), and/or the like. The Users table may support and/or track multiple entity accounts on a TSGS. [ 00300 ] A Devices table 2319b may include fields such as, but not limited to: device_ID, device_name, device_IP, device_GPS, device_MAC, device_serial, device_ECID, device_UDID, device_browser, device_type, device_model, device_version, device_OS, device_apps_list, device_securekey, wallet_app_installed_ flag, and/or the like. An Apps table 2319c may include fields such as, but not limited to: app_ID, app_name, app_type, app_dependencies, app_access_code, user_pin, and/or the like. [ 00301] An Accounts table 23i9d may include fields such as, but not limited to: account_number, account_security_code, account_name, issuer_acquirer_flag, issuer_name, acquirer_name, account_address, routing_number, access_API_call, linked_wallets_list, acct verification response code, card security code (esc) result code, Address Verification Results Code, System Trace Audit Number, Retrieval Reference Number, Approval Code, Response Source, and/or the like. A Merchants table 2319ε may include fields such as, but not limited to: merchant_id, merchant_name, merchant_address, store_id, ip_address, mac_address, auth_key, port_num, security_settings_list, and/or the like. An Issuers table 2319Ϊ may include fields such as, but not limited to: issuer_id, issuer_name, issuer_address, ip_address, mac_address, auth_key, port_num, security_settings_list, and/or the like. An Acquirers table 23i9g may include fields such as, but not limited to: account_firstname, account_lastname, account_type, account_num, account_ balance_list, billingaddress_ linei, billingaddress_ line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_linei, shippingaddress_line2, shipping_ zipcode, shipping_state, and/or the like. A Pay Gateways table 2319b may include fields such as, but not limited to: gateway_ID, gateway_IP, gateway_MAC, gateway_secure_key, gateway_access_list, gateway_API_call_list, gateway_services_list, and/or the like. A Shop Sessions table 23191 may include fields such as, but not limited to: user_id, session_id, alerts_URL, timestamp, expiry_lapse, merchant_id, store_id, device_type, device_ID, device_IP, device_MAC, device_browser, device_serial, device_ECID, device_model, device_OS, wallet_app_installed, total_cost, cart_ID_list, product_params_list, social_flag, social_message, social_networks_list, coupon_lists, accounts_list, CW2_lists, charge_ratio_list, charge_priority_list, value_exchange_symbols_list, bill_address, ship_address, cloak_flag, pay_mode, alerts_rules_list, and/or the like. A Transactions table 2319] may include fields such as, but not limited to: order_id, user_id, timestamp, transaction_cost, purchase_details_list, num_products, products_list, product_type, product_params_list, product_title, product_summary, quantity, user_id, client_id, client_ip, client_type, client_model, operating_system, os_version, app_installed_flag, user_id, account_firstname, account_lastname, account_type, account_num, account_priority_account_ratio, billingaddress_linei, billingaddress_line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_linei, shippingaddress_line2, shipping_ zipcode, shipping_state, merchant_id, merchant_name, merchant_auth_key, risk_score, risk mitigation_amount, risk_shift_entity, and/or the like. A Batches table 2319k may include fields such as, but not limited to: batch_id, transaction_id_list, timestamp_list, cleared_flag_list, clearance_trigger_ settings, and/or the like. A Ledgers table 2319I may include fields such as, but not limited to: request_id, timestamp, deposit_amount, batch_id, transaction_id, clear_flag, deposit_account, transaction_summary, payor_ name, payor_account, and/or the like. A Products table 2319m may include fields such as, but not limited to: product_ID, product_title, product_attributes_list, product_price, tax_info_list, related_products_ list, offers_list, discounts_list, rewards_list, merchants_list, merchant_availability_list, and/or the like. An Offers table 2319η may include fields such as, but not limited to: offer_ID, offer_title, offer_attributes_list, offer_price, offer_expiry, related_products_ list, discounts_list, rewards_list, merchants_list, merchant_availability_list, and/or the like. [00302] A Behavior Data table 23190 may include fields such as, but not limited to: user_id, timestamp, activity_type, activity_location, activity_attribute_list, activity_attribute_values_list, correlation_id, context, subcontext, siteminder login result (authsuccess, badusername, badpassword, challengesuccess, challengefailure), events_history (enrollment, logins, card additions/updates, purchases, shipping address additions, billing address changes, etc.), events_timestamp, results (successful login, unsuccessful login, auth declined, etc.), source_of_decline (issuer, merchant, V.me), status_latest_purchase (cancelled, complete, etc.), and/or the like. [00303] An Analytics table 2319P may include fields such as, but not limited to: report_id, user_id, report_type, report_algorithm_id, report_destination_address, and/or the like. A Fraud Reports table 23i9q may include fields such as, but not limited to: report_id, user_id, session_id, merchant_id, fraud_type, fraud_description, products_list, transaction_cost, timestamp, contact_info, and/or the like. A Risk Rules table 23i9r may include fields such as, but not limited to: rule_id, risk_type, transaction_type, rule_elements, rule_inputs, rule_processing, rule_outputs, rule_threshold, geo_scope, last_updated, rule_maximum_threshold, rule_merchant_needs, rule_entityi_threshold, rule_entity2_threshold, rule_entity3_threshold, rule entity 4_threshold (e.g., entities may be TSGS, merchants, acquirers, issuers, third party payment gateways, consumers, etc.), AA score, Age of AA score, risk assessment reason code 1, risk assessment reason code 2, carcc (compromised acct risk condition code), cerid, risk assessment condition code 3, requestorreferencedata, internal service indicator, action code, life cycle trace id, pos environment code, transport data, and/or the like. An Escalation Rules table 2319s may include fields such as, but not limited to: rule_id, risk_type, transaction_type, entity_type, rule_elements, rule_inputs, rule_processing, rule_outputs, rule_thresholds_list, geo_scope, last_updated, and/or the like.
[00304] In one embodiment, the TSGS database may interact with other database systems. For example, employing a distributed database system, queries and data access by search TSGS component may treat the combination of the TSGS database, an integrated data security layer database as a single database entity.
[00305] In one embodiment, user programs may contain various user interface primitives, which may serve to update the TSGS. Also, various accounts may require custom database tables depending upon the environments and the types of clients the TSGS may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components 23i9a-s. The TSGS may be configured to keep track of various settings, inputs, and parameters via database controllers.
[00306] The TSGS database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the TSGS database communicates with the TSGS component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data. The TSGSs
[00307] The TSGS component 2335 is a stored program component that is executed by a CPU. In one embodiment, the TSGS component incorporates any and/or all combinations of the aspects of the TSGS discussed in the previous figures. As such, the TSGS affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks. The features 1 and embodiments of the TSGS discussed herein increase network efficiency by reducing
2 data transfer requirements the use of more efficient data structures and mechanisms for
3 their transfer and storage. As a consequence, more data may be transferred in less time,
4 and latencies with regard to transactions, are also reduced. In many cases, such
5 reduction in storage, transfer time, bandwidth requirements, latencies, etc., may reduce
6 the capacity and structural infrastructure requirements to support the TSGS's features
7 and facilities, and in many cases reduce the costs, energy consumption/requirements,
8 and extend the life of TSGS's underlying infrastructure; this has the added benefit of
9 making the TSGS more reliable. Similarly, many of the features and mechanisms are
10 designed to be easier for users to use and access, thereby broadening the audience that
11 may enjoy/employ and exploit the feature sets of the TSGS; such ease of use also helps
12 to increase the reliability of the TSGS. In addition, the feature sets include heightened
13 security as noted via the Cryptographic components 2320, 2326, 2328 and throughout,
14 making access to the features and data more reliable and secure.
15 [00308] The TSGS component may transform user virtual wallet activity and
16 historical fraud reports via TSGS components into transaction authorization triggers
17 generated pursuant to graduated, transaction risk- appropriate, escalated security
18 protocols, and/or the like and use of the TSGS. In one embodiment, the TSGS
19 component 2335 takes inputs (e.g., current transaction request/security input 211;
20 historical wallet activity data 212; historical wallet fraud data reports 213; transaction
21 risk allocation offer acceptance 220; wallet activity 311; fraud report request input 511;
22 fraud report form 514; fraud report form input 517; checkout request 911; product data
23 915; wallet access input 1111; transaction authorization input 1114; payment gateway address
24 1118; payment network address 1122; issuer server address(es) 1125; funds authorization
25 request(s) 1126; user(s) account(s) data 1128; batch data 1312; payment network address
26 1316; issuer server address(es) 1324; individual payment request 1325; payment ledger,
27 merchant account data 1331; and/or the like) etc., and transforms the inputs via various
28 components (e.g., SCS 2349, GSPE 2348; TRA 2347; SRA 2346; FDR 2345; UWAR
29 2344; UPC 2341; PTA 2342; PTC 2343; and/or the like), into outputs (e.g., transaction
30 risk assessment data/rules 215; risk types/risk scores 217; transaction risk allocation
31 offers 219; transaction authorization 226; transaction denial 225; security data request 1 224; user wallet activity record 314-315; fraud report data record 519; checkout request
2 message 913; checkout data 917; card authorization request 1116, 1123; funds
3 authorization response(s) 1130; transaction authorization response 1132; batch append data
4 1134; purchase receipt 1135; batch clearance request 1314; batch payment request 1318;
5 transaction data 1320; individual payment confirmation 1328, 1329; updated payment
6 ledger, merchant account data 1333; and/or the like).
7 [00309] The TSGS component enabling access of information between nodes may
8 be developed by employing standard development tools and languages such as, but not
9 limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI)0 (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript,1 mapping tools, procedural and object oriented development tools, PERL, PHP, Python,2 shell scripts, SQL commands, web application server extensions, web development3 environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX & FLASH;4 AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype;5 script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo! User6 Interface; and/or the like), WebObjects, and/or the like. In one embodiment, the TSGS7 server employs a cryptographic server to encrypt and decrypt communications. The8 TSGS component may communicate to and/or with other components in a component9 collection, including itself, and/or facilities of the like. Most frequently, the TSGS0 component communicates with the TSGS database, operating systems, other program1 components, and/or the like. The TSGS may contain, communicate, generate, obtain,2 and/or provide program component, system, user, and/or data communications,3 requests, and/or responses. 4 Distributed TSGSs
5 [00310] The structure and/or operation of any of the TSGS node controller6 components may be combined, consolidated, and/or distributed in any number of ways7 to facilitate development and/or deployment. Similarly, the component collection may8 be combined in any number of ways to facilitate deployment and/or development. To9 accomplish this, one may integrate the components into a common code base or in a0 facility that can dynamically load the components on demand in an integrated fashion. [00311] The component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques.
[00312] The configuration of the TSGS controller may depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra- application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.
[00313] If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing capabilities, which in turn may form the basis of communication messages within and between components.
[00314] For example, a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.:
w3c -post http : / / . . . Valuel
[00315] where Valuei is discerned as being a parameter because "http://" is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable "Valuel" may be inserted into an "http://" post command and then sent. The grammar syntax itself may be presented as structured data that is interpreted and/or otherwise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., JSON, SOAP, and/or like parsers) that may be employed to parse (e.g., communications) data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration may depend upon the context, environment, and requirements of system deployment.
[00316] For example, in some implementations, the TSGS controller may be executing a PHP script implementing a Secure Sockets Layer ("SSL") socket server via the information server, which listens to incoming communications on a server port to which a client may send data, e.g., data encoded in JSON format. Upon identifying an 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 into PHP script variables, and store the data (e.g., client identifying information, etc.) and/or extracted information in a relational database accessible using the Structured Query Language ("SQL"). An exemplary listing, written substantially in the form of PHP/SQL commands, to accept JSON-encoded input data from a client device via a SSL connection, parse the data to extract variables, and store the data to a database, is provided below:
<?PHP
header (' Content-Type : text/plain');
// set ip address and port to listen to for incoming data
$address = 1192.168.0.100 ' ;
$port = 255;
// create a server-side SSL socket, listen for/accept incoming communication
$sock = socket_create (AF_INET, SOCK_STREAM, 0);
socket_bind ($sock, $address, $port) or die ( 'Could not bind to address');
socket_listen ($sock) ;
$client = socket_accept ($sock) ;
// read input data from client device in 1024 byte blocks until end of message do {
$ input = "";
$input = socket_read ( $client, 1024);
$data .= $input;
} while($input != "") ;
/ / parse data to extract variables
$obj = j son_decode ( $data, true) ;
/ / store input data in a database
mysql_connect ( "201.408.185.132 " , $DBserver , $password) ; // access database server mysql_select ( "CLIENT_DB . SQL" ) ; // select database to append
mysql_query ("INSERT INTO UserTable (transmission)
VALUES ($data)"); // add data to UserTable table in a CLIENT database
mysql_close ( "CLIENT_DB. SQL" ) ; // close connection to database
? >
[00317] Also, the following resources may be used to provide example embodiments regarding SOAP parser implementation:
http : / /www . xav . com/perl/ site/ lib/ SOAP/Parser . html
http : / /publib . boulder . ibm . com/ infocenter/tivihelp/v2rl/ index. j sp?topic=/com . ibm . IBMDI . doc/referenceguide295. htm
[00318] and other parser implementations:
http : / /publib . boulder . ibm . com/ infocenter/tivihelp/v2rl/ index. j sp?topic=/com . ibm . IBMDI . doc/referenceguide259. htm
[ o o 319 ] all of which are hereby expressly incorporated by reference herein.
[00320] Additional embodiments of the TSGS may include: l. A transaction risk shifting processor-implemented method embodiment, comprising:
obtaining an initial risk assessment indication associated with a transaction request from an assessment provider;
determining a challenge to ameliorate transaction risk to a desired risk level;
providing a facility to present the determined challenge;
obtaining results of the challenge; and
ameliorating the transaction risk based on a challenge response. 2. A transaction risk shifting processor-implemented method, comprising:
obtaining a current transaction request, the current transaction request utilizing a user virtual wallet account for purchase payment;
identifying a transaction risk type associated with the current transaction request;
calculating, via a processor, a transaction risk level associated with the transaction risk type;
providing a transaction risk shifting request including the calculated transaction risk level and the transaction risk type;
obtaining, in response to the transaction risk shifting request, a selection of a security protocol based on the calculated transaction risk level and security data in accordance with the security protocol;
generating an entity allocation of the transaction risk level associated with the transaction risk type; and
providing a notification of the entity allocation of the transaction risk level. 3. The method of embodiment 2, further comprising:
obtaining data on prior user wallet activity associated with the user virtual wallet account from a database; and
wherein the transaction risk type is identified using the data on the prior user wallet activity. 4. The method of embodiment 3, wherein the prior user wallet activity includes a product barcode price scan. 5. The method of embodiment 2, wherein the data on the prior user wallet activity includes a geographical location identifier for the prior user wallet activity. 6. The method of embodiment 2, wherein the current transaction request is a service enrollment request. 7. The method of embodiment 2, wherein the current transaction request is virtual wallet card addition request. 8. The method of embodiment 2, wherein the current transaction request is a purchase transaction request. 9. The method of embodiment 8, wherein the purchase transaction request is obtained from a mobile device. 10. The method of embodiment 2, wherein the transaction risk type is identified based on historical fraud data. 11. The method of embodiment 2, further comprising:
generating an offer, for an entity involved in processing the current transaction request, of a financial incentive in exchange for assuming the transaction risk level associated with the transaction risk type; and
providing the offer for the entity. 12. The method of embodiment 11, wherein the entity is one of: a user; a merchant; an issuer; an acquirer; a payment service provider; and a payment network. 13. The method of embodiment 2, wherein the selection of the security protocol is further based on a burden to respond to a security data request. 14. The method of embodiment 13, wherein the burden is measured by an amount of user intervention to respond to a security data request. 15. The method of embodiment 13, wherein the burden is measured by a network bandwidth required to respond to a security data request. 16. The method of embodiment 13, wherein the selection of the security protocol is based on minimizing the burden to respond to a security data request. 17. The method of embodiment 2, wherein a burden of the security protocol increases with increase in the transaction risk level associated with the transaction risk type. 18. The method of embodiment 2, further comprising:
identifying a second transaction risk type associated with the current transaction request; and
providing a second transaction risk shifting request based on the second transaction risk type. 19. The method of embodiment 18, wherein the second transaction risk shifting request is provided for an entity different than the one for which the transaction risk shifting request is provided. 20. The method of embodiment 2, wherein the calculation of the transaction risk level associated with the transaction risk type uses previously obtained security data. 21. A transaction risk shifting means embodiment, comprising:
means for obtaining a current transaction request, the current transaction request utilizing a user virtual wallet account for purchase payment;
means for identifying a transaction risk type associated with the current transaction request; means for calculating a transaction risk level associated with the transaction risk type;
means for providing a transaction risk shifting request including the calculated transaction risk level and the transaction risk type;
means for obtaining, in response to the transaction risk shifting request, a selection of a security protocol based on the calculated transaction risk level and security data in accordance with the security protocol;
means for generating an entity allocation of the transaction risk level associated with the transaction risk type; and
means for providing a notification of the entity allocation of the transaction risk level. 22. The means of embodiment 21, further comprising:
means for obtaining data on prior user wallet activity associated with the user virtual wallet account from a database; and
wherein the transaction risk type is identified using the data on the prior user wallet activity. 23. The means of embodiment 22, wherein the prior user wallet activity includes a product barcode price scan. 24. The means of embodiment 22, wherein the data on the prior user wallet activity includes a geographical location identifier for the prior user wallet activity. 25. The means of embodiment 24, wherein the geographical location identifier is a computer network address. 26. The means of embodiment 21, wherein the current transaction request is a service enrollment request. 27. The means of embodiment 21, wherein the current transaction request is virtual wallet card addition request. 28. The means of embodiment 21, wherein the current transaction request is a purchase transaction request. 29. The means of embodiment 28, wherein the purchase transaction request is obtained from a mobile device. 30. The means of embodiment 21, wherein the transaction risk type is identified based on historical fraud data. 31. The means of embodiment 21, further comprising:
means for generating an offer, for an entity involved in processing the current transaction request, of a financial incentive in exchange for assuming the transaction risk level associated with the transaction risk type; and
means for providing the offer for the entity. 32. The means of embodiment 31, wherein the entity is one of: a user; a merchant; an issuer; an acquirer; a payment service provider; and a payment network. 33. The means of embodiment 21, wherein the selection of the security protocol is further based on a burden to respond to a security data request. 34. The means of embodiment 33, wherein the burden is measured by an amount of user intervention to respond to a security data request. 35. The means of embodiment 33, wherein the burden is measured by a network bandwidth required to respond to a security data request. 36. The means of embodiment 33, wherein the selection of the security protocol is based on minimizing the burden to respond to a security data request. 37. The means of embodiment 21, wherein a burden of the security protocol increases with increase in the transaction risk level associated with the transaction risk type. 38. The means of embodiment 21, further comprising:
means for identifying a second transaction risk type associated with the current transaction request; and
means for providing a second transaction risk shifting request based on the second transaction risk type. 39. The means of embodiment 28, wherein the second transaction risk shifting request is provided for an entity different than the one for which the transaction risk shifting request is provided. 40. The means of embodiment 21, wherein the calculation of the transaction risk level associated with the transaction risk type uses previously obtained security data. 41. A transaction risk shifting system embodiment, comprising:
a processor; and
a memory disposed in communication with the processor and storing processor- executable instructions to:
obtain a current transaction request, the current transaction request utilizing a user virtual wallet account for purchase payment;
identify a transaction risk type associated with the current transaction request;
calculate, via the processor, a transaction risk level associated with the transaction risk type;
provide a transaction risk shifting request including the calculated transaction risk level and the transaction risk type;
obtain, in response to the transaction risk shifting request, a selection of a security protocol based on the calculated transaction risk level and security data in accordance with the security protocol;
generate an entity allocation of the transaction risk level associated with the transaction risk type; and
provide a notification of the entity allocation of the transaction risk level. 42. The system of embodiment 41, the memory further storing instructions to: obtain data on prior user wallet activity associated with the user virtual wallet account from a database; and
wherein the transaction risk type is identified using the data on the prior user wallet activity. 43. The system of embodiment 42, wherein the prior user wallet activity includes a product barcode price scan. 44. The system of embodiment 42, wherein the data on the prior user wallet activity includes a geographical location identifier for the prior user wallet activity. 45. The system of embodiment 44, wherein the grographical location identifier is a computer network address. 46. The system of embodiment 41, wherein the current transaction request is a service enrollment request. 47. The system of embodiment 41, wherein the current transaction request is virtual wallet card addition request. 48. The system of embodiment 41, wherein the current transaction request is a purchase transaction request. 49. The system of embodiment 48, wherein the purchase transaction request is obtained from a mobile device. 50. The system of embodiment 41, wherein the transaction risk type is identified based on historical fraud data. 51. The system of embodiment 41, the memory further storing instructions to: generate an offer, for an entity involved in processing the current transaction request, of a financial incentive in exchange for assuming the transaction risk level associated with the transaction risk type; and
provide the offer for the entity. 52. The system of embodiment 51, wherein the entity is one of: a user; a merchant; an issuer; an acquirer; a payment service provider; and a payment network. 53. The system of embodiment 41, wherein the selection of the security protocol is further based on a burden to respond to a security data request. 54. The system of embodiment 53, wherein the burden is measured by an amount of user intervention to respond to a security data request. 55. The system of embodiment 53, wherein the burden is measured by a network bandwidth required to respond to a security data request. 56. The system of embodiment 53, wherein the selection of the security protocol is based on minimizing the burden to respond to a security data request. 57. The system of embodiment 41, wherein a burden of the security protocol increases with increase in the transaction risk level associated with the transaction risk type. 58. The system of embodiment 41, the memory further storing instructions to: identify a second transaction risk type associated with the current transaction request; and
provide a second transaction risk shifting request based on the second transaction risk type. 59. The system of embodiment 58, wherein the second transaction risk shifting request is provided for an entity different than the one for which the transaction risk shifting request is provided. 60. The system of embodiment 41, wherein the calculation of the transaction risk level associated with the transaction risk type uses previously obtained security data. 61. A computer-readable tangible medium embodiment storing computer- executable transaction risk shifting instructions to:
obtain a current transaction request, the current transaction request utilizing a user virtual wallet account for purchase payment;
identify a transaction risk type associated with the current transaction request;
calculate a transaction risk level associated with the transaction risk type; provide a transaction risk shifting request including the calculated transaction risk level and the transaction risk type;
obtain, in response to the transaction risk shifting request, a selection of a security protocol based on the calculated transaction risk level and security data in accordance with the security protocol;
generate an entity allocation of the transaction risk level associated with the transaction risk type; and
provide a notification of the entity allocation of the transaction risk level. 62. The medium of embodiment 61, further storing instructions to:
obtain data on prior user wallet activity associated with the user virtual wallet account from a database; and
wherein the transaction risk type is identified using the data on the prior user wallet activity. 63. The medium of embodiment 42, wherein the prior user wallet activity includes a product barcode price scan. 64. The medium of embodiment 62, wherein the data on the prior user wallet activity includes a geographical location identifier for the prior user wallet activity. 65. The medium of embodiment 64, wherein the grographical location identifier is a computer network address. 66. The medium of embodiment 61, wherein the current transaction request is a service enrollment request. 67. The medium of embodiment 61, wherein the current transaction request is virtual wallet card addition request. 68. The medium of embodiment 61, wherein the current transaction request is a purchase transaction request. 69. The medium of embodiment 68, wherein the purchase transaction request is obtained from a mobile device. 70. The medium of embodiment 61, wherein the transaction risk type is identified based on historical fraud data. 71. The medium of embodiment 61, further storing instructions to:
generate an offer, for an entity involved in processing the current transaction request, of a financial incentive in exchange for assuming the transaction risk level associated with the transaction risk type; and
provide the offer for the entity. 72. The medium of embodiment 71, wherein the entity is one of: a user; a merchant; an issuer; an acquirer; a payment service provider; and a payment network. 73. The medium of embodiment 61, wherein the selection of the security protocol is further based on a burden to respond to a security data request. 74. The medium of embodiment 73, wherein the burden is measured by an amount of user intervention to respond to a security data request. 75. The medium of embodiment 73, wherein the burden is measured by a network bandwidth required to respond to a security data request. 76. The medium of embodiment 73, wherein the selection of the security protocol is based on minimizing the burden to respond to a security data request. 77. The medium of embodiment 61, wherein a burden of the security protocol increases with increase in the transaction risk level associated with the transaction risk type. 78. The medium of embodiment 61, further storing instructions to:
identify a second transaction risk type associated with the current transaction request; and
provide a second transaction risk shifting request based on the second transaction risk type. 79. The medium of embodiment 78, wherein the second transaction risk shifting request is provided for an entity different than the one for which the transaction risk shifting request is provided. 80. The medium of embodiment 61, wherein the calculation of the transaction risk level associated with the transaction risk type uses previously obtained security data. 81. A credential verification processor-implemented method embodiment, comprising:
receiving a payment transaction request including authentication credentials from an electronic wallet provider, said authentication credentials include payment account credentials and device information;
retrieving previously stored credential record;
determining a risk score based on the received authentication credential and stored credential record;
incorporating a risk status based on the risk score into an authentication response message; and
providing the authentication response message to the electronic wallet provider. [00321] In order to address various issues and advance the art, the entirety of this application for TRANSACTION SECURITY GRADUATED SEASONING AND RISK SHIFTING APPARATUSES, METHODS AND SYSTEMS (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, Appendices and/or otherwise) shows by way of illustration various example embodiments in which the claimed innovations may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed innovations. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the innovations or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It may be appreciated that many of those undescribed embodiments incorporate the same principles of the innovations and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, operational, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any data flow sequence(s), program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, processors, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are also contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the innovations, and inapplicable to others. In addition, the disclosure includes other innovations not presently claimed. Applicant reserves all rights in those presently unclaimed innovations, including the right to claim such innovations, file additional applications, continuations, continuations-in-part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, operational, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims. It is to be understood that, depending on the particular needs and/or characteristics of a TSGS individual and/or enterprise user, database configuration and/or relational model, data type, data transmission and/or network framework, syntax structure, and/or the like, various embodiments of the TSGS may be implemented that allow a great deal of flexibility and customization. For example, aspects of the TSGS may be adapted for building management, resource management, collaborative document production security, and/or like security systems. While various embodiments and discussions of the TSGS have been directed to electronic security, however, it is to be understood that the embodiments described herein may be readily configured and/or customized for a wide variety of other applications and/or implementations.

Claims

CLAI MS
What is claimed is:
l. A computer-implemented method for a graduated transaction risk shifting, the method comprising:
receiving a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
processing the current transaction request to identify a transaction risk type associated with the request;
calculating a quantitative transaction risk level associated with the transaction risk type;
executing on the device a comparative analysis, based on the calculated transaction risk level, to determine the application of a graduated security protocol for processing the current transaction request;
obtaining a risk mitigation outcome upon the instantiation of the transaction risk shifting protocol;
authorizing the transaction request when the risk mitigation outcome indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold; and
storing a risk mitigation amount associated with a transaction record.
2. The method of claim l, further comprising:
obtaining data on prior user wallet activity associated with the user virtual wallet account from a database; and
wherein the transaction risk type is identified using the data on the prior user wallet activity.
3. The method of claim 2, wherein the prior user wallet activity includes a product barcode price scan.
4. The method of claim 2 , wherein the data on the prior user wallet activity includes a geographical location identifier for the prior user wallet activity.
5. The method of claim 4, wherein the geographical location identifier is a computer network address.
6. The method of claim 1, wherein the current transaction request is a service enrollment request.
7. The method of claim 1, wherein the current transaction request is virtual wallet card addition request.
8. The method of claim 1, wherein the current transaction request is a purchase transaction request.
9. The method of claim 1, wherein the purchase transaction request is obtained from a mobile device.
10. The method of claim 1, wherein the transaction risk type is identified based on historical fraud data.
11. The method of claim 1, further comprising:
generating an offer, for an entity involved in processing the current transaction request, of a financial incentive in exchange for assuming the transaction risk level associated with the transaction risk type; and
providing the offer for the entity.
12. The method of claim 11, wherein the entity is one of: a user; a merchant; an issuer; an acquirer; a payment service provider; and a payment network.
13. The method of claim 1, wherein the selection of the security protocol is further based on a burden to respond to the security data request.
14. The method of claim 1, wherein the burden is measured by an amount of user intervention to respond to the security data request.
15. The method of claim 1, wherein the burden is measured by a network bandwidth required to respond to the security data request.
16. The method of claim 1, wherein the selection of the security protocol is based on minimizing the burden to respond to the security data request.
17. The method of claim 1, wherein a burden of the security protocol increases with increase in the transaction risk level associated with the transaction risk type.
18. The method of claim 1, further comprising:
identifying a second transaction risk type associated with the current transaction request;
selecting a second security protocol for processing the current transaction request; and
providing a second security data request in accordance with the selected second security protocol.
19. The method of claim 1, wherein the second security data request is provided for an entity different than the one for which the security data request is provided.
20. The method of claim 1, wherein the calculation of the transaction risk level associated with the transaction risk type uses previously obtained security data.
21. The method of claim 1, further comprising:
directing current transaction request to a risk mitigation participant.
22. The method of claim 21, wherein the risk mitigation participant comprises any of a merchant, an acquirer, an issuer, a third party payment gateway, and a consumer.
23. The method of claim 1, wherein the graduated security protocol is executed on behalf of a risk mitigation participant.
24. The method of claim 1, wherein the risk mitigation amount is shifted to a risk mitigation participant when the graduated security protocol is executed by or on behalf of the risk mitigation participant.
25. A graduated transaction risk shifting system, comprising:
means for receiving a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
means for processing the current transaction request to identify a transaction risk type associated with the request;
means for calculating a quantitative transaction risk level associated with the transaction risk type;
means for executing on the device a comparative analysis, based on the calculated transaction risk level, to determine the application of a graduated security protocol for processing the current transaction request; means for obtaining a risk mitigation outcome upon the instantiation of the transaction risk shifting protocol;
means for authorizing the transaction request when the risk mitigation outcome indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold; and
means for storing a risk mitigation amount associated with a transaction record..
26. A graduated transaction risk shifting apparatus, comprising:
a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to:
receive a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
process the current transaction request to identify a transaction risk type associated with the request;
calculate a quantitative transaction risk level associated with the transaction risk type;
execute on the device a comparative analysis, based on the calculated transaction risk level, to determine the application of a graduated security protocol for processing the current transaction request;
obtain a risk mitigation outcome upon the instantiation of the transaction risk shifting protocol;
authorize the transaction request when the risk mitigation outcome indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold; and
store a risk mitigation amount associated with a transaction record.
27. A computer-readable non-transitory medium storing computer-executable graduated transaction risk shifting instructions executable by a processor to:
receive a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
process the current transaction request to identify a transaction risk type associated with the request;
calculate a quantitative transaction risk level associated with the transaction risk type;
execute on the device a comparative analysis, based on the calculated transaction risk level, to determine the application of a graduated security protocol for processing the current transaction request;
obtain a risk mitigation outcome upon the instantiation of the transaction risk shifting protocol;
authorize the transaction request when the risk mitigation outcome indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold; and
store a risk mitigation amount associated with a transaction record.
28. A computer-implemented method for a graduated transaction risk shifting, the method comprising:
receiving a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
processing the current transaction request to identify a transaction risk type associated with the request;
calculating a quantitative transaction risk level associated with the transaction risk type;
executing on the device a comparative analysis, based on the calculated transaction risk level, to determine the application of a graduated security protocol for processing the current transaction request;
obtain a risk mitigation outcome upon the instantiation of the transaction risk shifting protocol;
authorize the transaction request when the risk mitigation outcome indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold; and
store a risk mitigation amount associated with a transaction record.
29. A graduated transaction risk shifting computer-implemented method, the method comprising:
receiving a current transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
processing the current transaction request to identify a transaction risk type associated with the request; calculating a quantitative transaction risk level associated with the transaction risk type;
determining the quantitative transaction risk level is greater than a tolerable transaction risk threshold;
retrieving a list of transaction risk shifting protocols associated with the transaction risk type from a database;
obtaining desired transaction risk shifting burden level parameters;
forming a query on the list of transaction risk shifting protocols for a transaction risk shifting protocol based on the desired transaction risk shifting burden level parameters,
the transaction risk shifting protocol having a risk mitigation amount sufficient to reduce the quantitative transaction risk level below the tolerable transaction risk threshold;
instantiating the transaction risk shifting protocol;
obtaining a risk mitigation outcome from the instantiation of the transaction risk shifting protocol;
authorizing the transaction request when the risk mitigation outcome indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold; and
storing the risk mitigation amount associated with a transaction record.
30. A graduated transaction risk shifting computer-implemented method, comprising:
receiving a transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
processing the current transaction request to identify a transaction risk type associated with the request;
calculating a quantitative transaction risk level associated with the transaction risk type;
determining the quantitative transaction risk level is greater than a tolerable transaction risk threshold; determining whether risk mitigation from a risk mitigation participant is needed based on the calculated quantitative transaction risk level and risk assessment rules;
directing the transaction request to the risk mitigation participant for risk mitigation when risk mitigation from a risk mitigation participant is needed, including:
sending a mitigation offer to the risk mitigation participant, obtaining an mitigation offer acceptance indication from the risk mitigation participant,
obtaining a mitigation outcome indication from the risk mitigation participant,
authorizing the transaction request and storing a risk amount shifted to the risk mitigation participant associated with a transaction record when the obtained mitigation outcome indication is positive of transaction risk, and
rejecting the transaction request when the obtained mitigation outcome indication is negative of transaction risk; and
instantiating a transaction risk shifting component when risk mitigation from a risk mitigation participant is not needed, including:
retrieving a list of transaction risk shifting protocols associated with the transaction risk type from a database,
obtaining desired transaction risk shifting burden level parameters, forming a query on the list of transaction risk shifting protocols for a transaction risk shifting protocol based on the desired transaction risk shifting burden level parameters,
the transaction risk shifting protocol having a risk mitigation amount sufficient to reduce the quantitative transaction risk level below the tolerable transaction risk threshold,
issuing and executing the transaction risk shifting protocol, obtaining a risk mitigation result in response to the execution of the transaction risk shifting protocol, and
authorizing the transaction request and storing the risk mitigation amount associated with a transaction record when the obtained risk mitigation result indicates the quantitative transaction risk level has been successfully reduced below the I tolerable transaction risk threshold.
2
3 31. The method of claim 30, wherein the risk mitigation participant comprises
4 any of a merchant, an acquirer, an issuer, a third party payment gateway, and a
5 consumer.
6
7 32. The method of claim 30, wherein the risk mitigation from the risk
8 mitigation participant is determined by rules specified by the risk mitigation
9 participant.
10
I I 33. The method of claim 30, wherein the risk mitigation participant performs 12 risk mitigation procedure separate from the transaction risk shifting component.
13
14 34. The method of claim 30, wherein the risk mitigation participant loads the
15 transaction risk shifting component via API calls.
16
17 35. The method of claim 30, further comprising:
18 determining consumer transaction context; and
19 determining desired transaction risk shifting burden level parameters
20 based on the determined consumer transaction context.
21
22 36. The method of claim 31, wherein the consumer transaction context
23 comprises any of an IP address, a geo-location, a device type and network bandwidth.
24
25 37. The method of claim 30, wherein the risk mitigation from a risk mitigation
26 participant is needed when the quantitative transaction risk level is greater than a
27 tolerable transaction risk threshold.
28
29 38. The method of claim 30, wherein the risk mitigation from a risk mitigation
30 participant is needed when the risk mitigation participant specifies requests to review
31 transactions in risk assessment rules.
32 39. A graduated transaction risk shifting system, comprising: means for receiving a transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
means for processing the current transaction request to identify a transaction risk type associated with the request;
means for calculating a quantitative transaction risk level associated with the transaction risk type;
means for determining the quantitative transaction risk level is greater than a tolerable transaction risk threshold;
means for determining whether risk mitigation from a risk mitigation participant is needed based on the calculated quantitative transaction risk level and risk assessment rules;
means for directing the transaction request to the risk mitigation participant for risk mitigation when risk mitigation from a risk mitigation participant is needed, including:
means for sending a mitigation offer to the risk mitigation participant,
means for obtaining an mitigation offer acceptance indication from the risk mitigation participant,
means for obtaining a mitigation outcome indication from the risk mitigation participant,
means for authorizing the transaction request and storing a risk amount shifted to the risk mitigation participant associated with a transaction record when the obtained mitigation outcome indication is positive of transaction risk, and means for rejecting the transaction request when the obtained mitigation outcome indication is negative of transaction risk; and
means for instantiating a transaction risk shifting component when risk mitigation from a risk mitigation participant is not needed, including:
means for retrieving a list of transaction risk shifting protocols associated with the transaction risk type from a database,
means for obtaining desired transaction risk shifting burden level parameters, means for forming a query on the list of transaction risk shifting protocols for a transaction risk shifting protocol based on the desired transaction risk shifting burden level parameters,
the transaction risk shifting protocol having a risk mitigation amount sufficient to reduce the quantitative transaction risk level below the tolerable transaction risk threshold,
means for issuing and executing the transaction risk shifting protocol,
means for obtaining a risk mitigation result in response to the execution of the transaction risk shifting protocol, and
means for authorizing the transaction request and storing the risk mitigation amount associated with a transaction record when the obtained risk mitigation result indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold. 40. A graduated transaction risk shifting apparatus, comprising:
a processor; and
a memory disposed in communication with the processor and storing processor- executable instructions to:
receive a transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
process the current transaction request to identify a transaction risk type associated with the request;
calculate a quantitative transaction risk level associated with the transaction risk type;
determine the quantitative transaction risk level is greater than a tolerable transaction risk threshold;
determine whether risk mitigation from a risk mitigation participant is needed based on the calculated quantitative transaction risk level and risk assessment rules;
direct the transaction request to the risk mitigation participant for risk mitigation when risk mitigation from a risk mitigation participant is needed, including: send a mitigation offer to the risk mitigation participant,
obtain an mitigation offer acceptance indication from the risk mitigation participant,
obtain a mitigation outcome indication from the risk mitigation participant,
authorize the transaction request and storing a risk amount shifted to the risk mitigation participant associated with a transaction record when the obtained mitigation outcome indication is positive of transaction risk, and
reject the transaction request when the obtained mitigation outcome indication is negative of transaction risk; and
instantiate a transaction risk shifting component when risk mitigation from a risk mitigation participant is not needed, including:
retrieve a list of transaction risk shifting protocols associated with the transaction risk type from a database,
obtain desired transaction risk shifting burden level parameters, form a query on the list of transaction risk shifting protocols for a transaction risk shifting protocol based on the desired transaction risk shifting burden level parameters,
the transaction risk shifting protocol having a risk mitigation amount sufficient to reduce the quantitative transaction risk level below the tolerable transaction risk threshold,
issue and executing the transaction risk shifting protocol, obtain a risk mitigation result in response to the execution of the transaction risk shifting protocol, and
authorize the transaction request and storing the risk mitigation amount associated with a transaction record when the obtained risk mitigation result indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold. 41. A computer-readable non-transitory medium storing computer-executable graduated transaction risk shifting instructions executable by a processor to, receive a transaction request via a user interface implemented on a computing device, the user interface utilizing a user virtual wallet account for purchase payment;
process the current transaction request to identify a transaction risk type associated with the request;
calculate a quantitative transaction risk level associated with the transaction risk type;
determine the quantitative transaction risk level is greater than a tolerable transaction risk threshold;
determine whether risk mitigation from a risk mitigation participant is needed based on the calculated quantitative transaction risk level and risk assessment rules;
direct the transaction request to the risk mitigation participant for risk mitigation when risk mitigation from a risk mitigation participant is needed, including:
send a mitigation offer to the risk mitigation participant,
obtain an mitigation offer acceptance indication from the risk mitigation participant,
obtain a mitigation outcome indication from the risk mitigation participant,
authorize the transaction request and storing a risk amount shifted to the risk mitigation participant associated with a transaction record when the obtained mitigation outcome indication is positive of transaction risk, and
reject the transaction request when the obtained mitigation outcome indication is negative of transaction risk; and
instantiate a transaction risk shifting component when risk mitigation from a risk mitigation participant is not needed, including:
retrieve a list of transaction risk shifting protocols associated with the transaction risk type from a database,
obtain desired transaction risk shifting burden level parameters, form a query on the list of transaction risk shifting protocols for a transaction risk shifting protocol based on the desired transaction risk shifting burden level parameters, the transaction risk shifting protocol having a risk mitigation amount sufficient to reduce the quantitative transaction risk level below the tolerable transaction risk threshold,
issue and executing the transaction risk shifting protocol, obtain a risk mitigation result in response to the execution of the transaction risk shifting protocol, and
authorize the transaction request and storing the risk mitigation amount associated with a transaction record when the obtained risk mitigation result indicates the quantitative transaction risk level has been successfully reduced below the tolerable transaction risk threshold.
PCT/US2012/066898 2011-11-28 2012-11-28 Transaction security graduated seasoning and risk shifting apparatuses, methods and systems WO2013082190A1 (en)

Priority Applications (10)

Application Number Priority Date Filing Date Title
KR1020137028128A KR20140121764A (en) 2012-01-05 2013-01-05 Transaction visual capturing apparatuses, methods and systems
EP13733776.2A EP2801065A4 (en) 2012-01-05 2013-01-05 Transaction visual capturing apparatuses, methods and systems
CN201380001482.6A CN103843024A (en) 2012-01-05 2013-01-05 Transaction visual capturing apparatuses, methods and systems
JP2014551377A JP6153947B2 (en) 2012-01-05 2013-01-05 Transaction video capture device, method and system
AU2013207407A AU2013207407A1 (en) 2012-01-05 2013-01-05 Transaction visual capturing apparatuses, methods and systems
PCT/US2013/020411 WO2013103912A1 (en) 2012-01-05 2013-01-05 Transaction visual capturing apparatuses, methods and systems
US13/735,802 US20130218721A1 (en) 2012-01-05 2013-01-07 Transaction visual capturing apparatuses, methods and systems
PCT/US2014/010378 WO2015112108A1 (en) 2012-11-28 2014-01-06 Multi disparate gesture actions and transactions apparatuses, methods and systems
HK15104251.9A HK1203680A1 (en) 2012-01-05 2015-05-05 Transaction visual capturing apparatuses, methods and systems
US16/198,591 US10685379B2 (en) 2012-01-05 2018-11-21 Wearable intelligent vision device apparatuses, methods and systems

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US201161563941P 2011-11-28 2011-11-28
US61/563,941 2011-11-28
US201161566969P 2011-12-05 2011-12-05
US61/566,969 2011-12-05
US201161569371P 2011-12-12 2011-12-12
US61/569,371 2011-12-12
US13/434,818 US20130218765A1 (en) 2011-03-29 2012-03-29 Graduated security seasoning apparatuses, methods and systems
US13/434,818 2012-03-29
US201261723083P 2012-11-06 2012-11-06
US61/723,083 2012-11-06

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/020411 Continuation-In-Part WO2013103912A1 (en) 2012-01-05 2013-01-05 Transaction visual capturing apparatuses, methods and systems

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/434,818 Continuation US20130218765A1 (en) 2011-03-29 2012-03-29 Graduated security seasoning apparatuses, methods and systems
US13/434,818 Continuation-In-Part US20130218765A1 (en) 2011-03-29 2012-03-29 Graduated security seasoning apparatuses, methods and systems

Publications (1)

Publication Number Publication Date
WO2013082190A1 true WO2013082190A1 (en) 2013-06-06

Family

ID=48536025

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/066898 WO2013082190A1 (en) 2011-11-28 2012-11-28 Transaction security graduated seasoning and risk shifting apparatuses, methods and systems

Country Status (1)

Country Link
WO (1) WO2013082190A1 (en)

Cited By (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014130642A2 (en) * 2013-02-25 2014-08-28 Mei, Inc. System to accept an item of value
WO2014210051A1 (en) * 2013-06-25 2014-12-31 Quisk, Inc. Fraud monitoring system with distributed cache
CN104867011A (en) * 2014-02-21 2015-08-26 中国电信股份有限公司 Method and device for carrying out safety control on mobile payment
WO2016019093A1 (en) * 2014-07-31 2016-02-04 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9305298B2 (en) 2013-03-22 2016-04-05 Nok Nok Labs, Inc. System and method for location-based authentication
EP3012771A1 (en) * 2014-10-22 2016-04-27 AO Kaspersky Lab System and method for protecting electronic money transactions
CN105550875A (en) * 2014-10-22 2016-05-04 卡巴斯基实验室股份制公司 System and method for protecting electronic money transactions
US9413533B1 (en) 2014-05-02 2016-08-09 Nok Nok Labs, Inc. System and method for authorizing a new authenticator
WO2016127040A1 (en) * 2015-02-07 2016-08-11 Alibaba Group Holding Limited Method and apparatus for providing security information of user device
US9455979B2 (en) 2014-07-31 2016-09-27 Nok Nok Labs, Inc. System and method for establishing trust using secure transmission protocols
US9577999B1 (en) 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
CN107148634A (en) * 2014-10-31 2017-09-08 金成吉 Integrate accumulation system, integration accumulation method and its NFC terminal devices
EP3226192A1 (en) * 2016-03-29 2017-10-04 NCR Corporation Security system monitoring techniques
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
CN109074577A (en) * 2016-05-17 2018-12-21 万事达卡国际公司 wallet management system
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
CN110245941A (en) * 2019-04-25 2019-09-17 阿里巴巴集团控股有限公司 A kind of transaction risk recognition methods and device
US10482468B2 (en) 2016-11-11 2019-11-19 Mastercard International Incorporated Systems and methods of improved electronic messaging
US10521791B2 (en) 2014-05-07 2019-12-31 Mastercard International Incorporated Systems and methods for communicating liability acceptance with payment card transactions
WO2020009769A1 (en) * 2018-07-06 2020-01-09 Mastercard International Incorporated System and method for electronic funds transfer (eft) security
CN110874743A (en) * 2019-10-11 2020-03-10 支付宝(杭州)信息技术有限公司 Method and device for determining account transaction risk
US10614452B2 (en) 2014-09-16 2020-04-07 Mastercard International Incorporated Systems and methods for providing risk based decisioning service to a merchant
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US20200134630A1 (en) * 2016-07-22 2020-04-30 Alibaba Group Holding Limited Method and device for controlling service operation risk
US10652282B2 (en) 2017-02-15 2020-05-12 Microsoft Technology Licensing, Llc Brokered authentication with risk sharing
CN111429145A (en) * 2020-03-26 2020-07-17 深圳市腾讯计算机系统有限公司 Risk control method and device for electronic transaction and electronic equipment
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10902415B2 (en) * 2018-01-23 2021-01-26 Advanced New Technologies Co., Ltd. Payment card binding method, trust evaluation method, apparatus, and electronic device
WO2021045767A1 (en) * 2019-09-05 2021-03-11 Visa International Service Association System, method, and computer program product for generating code to retrieve aggregation data for machine learning models
US11127005B2 (en) 2017-10-03 2021-09-21 The Toronto-Dominion Bank Network and method for clearing point-of-sale terminal pre-authorizations
US11227220B2 (en) * 2017-12-15 2022-01-18 Paypal, Inc. Automatic discovery of data required by a rule engine
US11301820B2 (en) * 2015-11-18 2022-04-12 International Business Machines Corporation Bi-directional feed between electronic calendar and credit-card authorization unit
US11301556B2 (en) 2016-08-31 2022-04-12 Advanced New Technologies Co., Ltd. Verification method and device
CN114612104A (en) * 2020-12-09 2022-06-10 支付宝(杭州)信息技术有限公司 Risk identification method and device and electronic equipment
US20220188828A1 (en) * 2020-12-10 2022-06-16 International Business Machines Corporation Transaction generation for analytics evaluation
US20220207385A1 (en) * 2017-12-15 2022-06-30 Paypal, Inc. Self learning data loading optimization for a rule engine
US11468446B2 (en) * 2017-01-23 2022-10-11 Advanced New Technologies Co., Ltd. Method for adjusting risk parameter, and method and device for risk identification
US20220391910A1 (en) * 2021-06-04 2022-12-08 Handle Financial, Inc. Action execution using decision engine scores with multiple merchants
US11651341B2 (en) * 2016-01-08 2023-05-16 Worldpay, Llc Multi-platform electronic payment transaction risk profiling
CN116151832A (en) * 2023-04-18 2023-05-23 支付宝(杭州)信息技术有限公司 Interactive wind control system and method
US11727388B1 (en) 2015-07-31 2023-08-15 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11755773B1 (en) 2016-07-01 2023-09-12 Wells Fargo Bank, N.A. Access control tower
US11756114B1 (en) 2017-07-06 2023-09-12 Wells Fargo Bank, N.A. Data control tower
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
US11818135B1 (en) 2021-01-05 2023-11-14 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US11823205B1 (en) 2015-03-27 2023-11-21 Wells Fargo Bank, N.A. Token management system
US20230376964A1 (en) * 2022-05-23 2023-11-23 Gen Digital Inc. Systems and methods for detecting unauthorized online transactions
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
US11853456B1 (en) 2016-07-01 2023-12-26 Wells Fargo Bank, N.A. Unlinking applications from accounts
US11868993B1 (en) 2008-10-31 2024-01-09 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11869013B1 (en) * 2017-04-25 2024-01-09 Wells Fargo Bank, N.A. System and method for card control
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11915230B1 (en) 2008-10-31 2024-02-27 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11947918B2 (en) 2020-09-04 2024-04-02 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020138371A1 (en) * 2001-03-20 2002-09-26 David Lawrence Online transaction risk management
US20050097320A1 (en) * 2003-09-12 2005-05-05 Lior Golan System and method for risk based authentication
US20070106582A1 (en) * 2005-10-04 2007-05-10 Baker James C System and method of detecting fraud
US20090234760A1 (en) * 2007-08-01 2009-09-17 Qpay Holdings Limited Transaction authorisation system and method
US20100125495A1 (en) * 2008-11-17 2010-05-20 Smith Steven M System and method of providing a mobile wallet at a mobile telephone
EP2273393A2 (en) * 1998-05-29 2011-01-12 Palm, Inc. Method and apparatus for communicating information over low bandwidth communications networks
US20110016052A1 (en) * 2009-07-16 2011-01-20 Scragg Ernest M Event Tracking and Velocity Fraud Rules for Financial Transactions
US20110196791A1 (en) * 2010-02-08 2011-08-11 Benedicto Hernandez Dominguez Fraud reduction system for transactions
US20110282778A1 (en) * 2001-05-30 2011-11-17 Wright William A Method and apparatus for evaluating fraud risk in an electronic commerce transaction

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2273393A2 (en) * 1998-05-29 2011-01-12 Palm, Inc. Method and apparatus for communicating information over low bandwidth communications networks
US20020138371A1 (en) * 2001-03-20 2002-09-26 David Lawrence Online transaction risk management
US20110282778A1 (en) * 2001-05-30 2011-11-17 Wright William A Method and apparatus for evaluating fraud risk in an electronic commerce transaction
US20050097320A1 (en) * 2003-09-12 2005-05-05 Lior Golan System and method for risk based authentication
US20070106582A1 (en) * 2005-10-04 2007-05-10 Baker James C System and method of detecting fraud
US20090234760A1 (en) * 2007-08-01 2009-09-17 Qpay Holdings Limited Transaction authorisation system and method
US20100125495A1 (en) * 2008-11-17 2010-05-20 Smith Steven M System and method of providing a mobile wallet at a mobile telephone
US20110016052A1 (en) * 2009-07-16 2011-01-20 Scragg Ernest M Event Tracking and Velocity Fraud Rules for Financial Transactions
US20110196791A1 (en) * 2010-02-08 2011-08-11 Benedicto Hernandez Dominguez Fraud reduction system for transactions

Cited By (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11868993B1 (en) 2008-10-31 2024-01-09 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11880827B1 (en) 2008-10-31 2024-01-23 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11880846B1 (en) 2008-10-31 2024-01-23 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11900390B1 (en) 2008-10-31 2024-02-13 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11915230B1 (en) 2008-10-31 2024-02-27 Wells Fargo Bank, N.A. Payment vehicle with on and off function
WO2014130642A2 (en) * 2013-02-25 2014-08-28 Mei, Inc. System to accept an item of value
WO2014130642A3 (en) * 2013-02-25 2014-10-16 Mei, Inc. System to accept an item of value
US10176310B2 (en) 2013-03-22 2019-01-08 Nok Nok Labs, Inc. System and method for privacy-enhanced data synchronization
US9367676B2 (en) 2013-03-22 2016-06-14 Nok Nok Labs, Inc. System and method for confirming location using supplemental sensor and/or location data
US9396320B2 (en) 2013-03-22 2016-07-19 Nok Nok Labs, Inc. System and method for non-intrusive, privacy-preserving authentication
US9898596B2 (en) 2013-03-22 2018-02-20 Nok Nok Labs, Inc. System and method for eye tracking during authentication
US10776464B2 (en) 2013-03-22 2020-09-15 Nok Nok Labs, Inc. System and method for adaptive application of authentication policies
US10762181B2 (en) 2013-03-22 2020-09-01 Nok Nok Labs, Inc. System and method for user confirmation of online transactions
US11929997B2 (en) 2013-03-22 2024-03-12 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US10706132B2 (en) 2013-03-22 2020-07-07 Nok Nok Labs, Inc. System and method for adaptive user authentication
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US10268811B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. System and method for delegating trust to a new authenticator
US9305298B2 (en) 2013-03-22 2016-04-05 Nok Nok Labs, Inc. System and method for location-based authentication
US10366218B2 (en) 2013-03-22 2019-07-30 Nok Nok Labs, Inc. System and method for collecting and utilizing client data for risk assessment during authentication
US10282533B2 (en) 2013-03-22 2019-05-07 Nok Nok Labs, Inc. System and method for eye tracking during authentication
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
WO2014210051A1 (en) * 2013-06-25 2014-12-31 Quisk, Inc. Fraud monitoring system with distributed cache
US9519902B2 (en) 2013-06-25 2016-12-13 Quisk, Inc. Fraud monitoring system with distributed cache
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US10798087B2 (en) 2013-10-29 2020-10-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
CN104867011A (en) * 2014-02-21 2015-08-26 中国电信股份有限公司 Method and device for carrying out safety control on mobile payment
US10326761B2 (en) 2014-05-02 2019-06-18 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US9413533B1 (en) 2014-05-02 2016-08-09 Nok Nok Labs, Inc. System and method for authorizing a new authenticator
US9577999B1 (en) 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US11562356B2 (en) 2014-05-07 2023-01-24 Mastercard International Incorporated Systems and methods for communicating liability acceptance with payment card transactions
US10521791B2 (en) 2014-05-07 2019-12-31 Mastercard International Incorporated Systems and methods for communicating liability acceptance with payment card transactions
US9455979B2 (en) 2014-07-31 2016-09-27 Nok Nok Labs, Inc. System and method for establishing trust using secure transmission protocols
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
WO2016019093A1 (en) * 2014-07-31 2016-02-04 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US11501286B2 (en) 2014-09-16 2022-11-15 Mastercard International Incorporated Systems and methods for providing fraud indicator data within an authentication protocol
US10614452B2 (en) 2014-09-16 2020-04-07 Mastercard International Incorporated Systems and methods for providing risk based decisioning service to a merchant
US10657521B2 (en) 2014-09-16 2020-05-19 Mastercard International Incorporated Systems and methods for determining fraudulent transactions using digital wallet data
EP3012771A1 (en) * 2014-10-22 2016-04-27 AO Kaspersky Lab System and method for protecting electronic money transactions
CN105550875A (en) * 2014-10-22 2016-05-04 卡巴斯基实验室股份制公司 System and method for protecting electronic money transactions
US9542683B2 (en) 2014-10-22 2017-01-10 AO Kaspersky Lab System and method for protecting electronic money transactions
US11023916B2 (en) * 2014-10-31 2021-06-01 Seong-Kil Kim Bonus accumulation system, bonus accumulation method, and IoD-NFC terminal device therefor
US20170316441A1 (en) * 2014-10-31 2017-11-02 Seong-Kil Kim Bonus accumulation system, bonus accumulation method, and nfc terminal device therefor
CN107148634B (en) * 2014-10-31 2021-01-26 金成吉 Integral accumulation system, integral accumulation method and NFC terminal equipment thereof
CN107148634A (en) * 2014-10-31 2017-09-08 金成吉 Integrate accumulation system, integration accumulation method and its NFC terminal devices
WO2016127040A1 (en) * 2015-02-07 2016-08-11 Alibaba Group Holding Limited Method and apparatus for providing security information of user device
US11861594B1 (en) 2015-03-27 2024-01-02 Wells Fargo Bank, N.A. Token management system
US11823205B1 (en) 2015-03-27 2023-11-21 Wells Fargo Bank, N.A. Token management system
US11893588B1 (en) 2015-03-27 2024-02-06 Wells Fargo Bank, N.A. Token management system
US11727388B1 (en) 2015-07-31 2023-08-15 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11847633B1 (en) 2015-07-31 2023-12-19 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11900362B1 (en) 2015-07-31 2024-02-13 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11301820B2 (en) * 2015-11-18 2022-04-12 International Business Machines Corporation Bi-directional feed between electronic calendar and credit-card authorization unit
US11651341B2 (en) * 2016-01-08 2023-05-16 Worldpay, Llc Multi-platform electronic payment transaction risk profiling
US10341369B2 (en) 2016-03-29 2019-07-02 Ncr Corporation Security system monitoring techniques by mapping received security score with newly identified security score
EP3226192A1 (en) * 2016-03-29 2017-10-04 NCR Corporation Security system monitoring techniques
CN109074577A (en) * 2016-05-17 2018-12-21 万事达卡国际公司 wallet management system
US11914743B1 (en) 2016-07-01 2024-02-27 Wells Fargo Bank, N.A. Control tower for unlinking applications from accounts
US11895117B1 (en) 2016-07-01 2024-02-06 Wells Fargo Bank, N.A. Access control interface for managing entities and permissions
US11762535B1 (en) 2016-07-01 2023-09-19 Wells Fargo Bank, N.A. Control tower restrictions on third party platforms
US11886613B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for linking accounts to applications
US11928236B1 (en) 2016-07-01 2024-03-12 Wells Fargo Bank, N.A. Control tower for linking accounts to applications
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11899815B1 (en) 2016-07-01 2024-02-13 Wells Fargo Bank, N.A. Access control interface for managing entities and permissions
US11755773B1 (en) 2016-07-01 2023-09-12 Wells Fargo Bank, N.A. Access control tower
US11853456B1 (en) 2016-07-01 2023-12-26 Wells Fargo Bank, N.A. Unlinking applications from accounts
US20200134630A1 (en) * 2016-07-22 2020-04-30 Alibaba Group Holding Limited Method and device for controlling service operation risk
US20200242614A1 (en) * 2016-07-22 2020-07-30 Alibaba Group Holding Limited Method and device for controlling service operation risk
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US11301556B2 (en) 2016-08-31 2022-04-12 Advanced New Technologies Co., Ltd. Verification method and device
US10482468B2 (en) 2016-11-11 2019-11-19 Mastercard International Incorporated Systems and methods of improved electronic messaging
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US11468446B2 (en) * 2017-01-23 2022-10-11 Advanced New Technologies Co., Ltd. Method for adjusting risk parameter, and method and device for risk identification
US10652282B2 (en) 2017-02-15 2020-05-12 Microsoft Technology Licensing, Llc Brokered authentication with risk sharing
US11875358B1 (en) * 2017-04-25 2024-01-16 Wells Fargo Bank, N.A. System and method for card control
US11869013B1 (en) * 2017-04-25 2024-01-09 Wells Fargo Bank, N.A. System and method for card control
US11756114B1 (en) 2017-07-06 2023-09-12 Wells Fargo Bank, N.A. Data control tower
US11127005B2 (en) 2017-10-03 2021-09-21 The Toronto-Dominion Bank Network and method for clearing point-of-sale terminal pre-authorizations
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11900271B2 (en) 2017-12-15 2024-02-13 Paypal, Inc. Self learning data loading optimization for a rule engine
US20220207385A1 (en) * 2017-12-15 2022-06-30 Paypal, Inc. Self learning data loading optimization for a rule engine
US11227220B2 (en) * 2017-12-15 2022-01-18 Paypal, Inc. Automatic discovery of data required by a rule engine
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
US10902415B2 (en) * 2018-01-23 2021-01-26 Advanced New Technologies Co., Ltd. Payment card binding method, trust evaluation method, apparatus, and electronic device
US11107078B2 (en) 2018-07-06 2021-08-31 Mastercard International Incorporated System and method for electronic funds transfer (EFT) security
WO2020009769A1 (en) * 2018-07-06 2020-01-09 Mastercard International Incorporated System and method for electronic funds transfer (eft) security
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110245941B (en) * 2019-04-25 2023-06-30 创新先进技术有限公司 Transaction risk identification method and device
CN110245941A (en) * 2019-04-25 2019-09-17 阿里巴巴集团控股有限公司 A kind of transaction risk recognition methods and device
US11960480B2 (en) 2019-09-05 2024-04-16 Visa International Service Association System, method, and computer program product for generating code to retrieve aggregation data for machine learning models
WO2021045767A1 (en) * 2019-09-05 2021-03-11 Visa International Service Association System, method, and computer program product for generating code to retrieve aggregation data for machine learning models
CN110874743A (en) * 2019-10-11 2020-03-10 支付宝(杭州)信息技术有限公司 Method and device for determining account transaction risk
CN110874743B (en) * 2019-10-11 2023-04-07 支付宝(杭州)信息技术有限公司 Method and device for determining account transaction risk
CN111429145B (en) * 2020-03-26 2022-04-01 深圳市腾讯计算机系统有限公司 Risk control method and device for electronic transaction and electronic equipment
CN111429145A (en) * 2020-03-26 2020-07-17 深圳市腾讯计算机系统有限公司 Risk control method and device for electronic transaction and electronic equipment
US11947918B2 (en) 2020-09-04 2024-04-02 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
CN114612104A (en) * 2020-12-09 2022-06-10 支付宝(杭州)信息技术有限公司 Risk identification method and device and electronic equipment
US20220188828A1 (en) * 2020-12-10 2022-06-16 International Business Machines Corporation Transaction generation for analytics evaluation
US11818135B1 (en) 2021-01-05 2023-11-14 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US20220391910A1 (en) * 2021-06-04 2022-12-08 Handle Financial, Inc. Action execution using decision engine scores with multiple merchants
US20230376964A1 (en) * 2022-05-23 2023-11-23 Gen Digital Inc. Systems and methods for detecting unauthorized online transactions
CN116151832A (en) * 2023-04-18 2023-05-23 支付宝(杭州)信息技术有限公司 Interactive wind control system and method
CN116151832B (en) * 2023-04-18 2023-07-21 支付宝(杭州)信息技术有限公司 Interactive wind control system and method

Similar Documents

Publication Publication Date Title
US11715097B2 (en) Cloud-based virtual wallet NFC apparatuses, methods and systems
WO2013082190A1 (en) Transaction security graduated seasoning and risk shifting apparatuses, methods and systems
US11727392B2 (en) Multi-purpose virtual card transaction apparatuses, methods and systems
US11250352B2 (en) Secure anonymous transaction apparatuses, methods and systems
US20130144785A1 (en) Social network payment authentication apparatuses, methods and systems
US20130218765A1 (en) Graduated security seasoning apparatuses, methods and systems
US8577803B2 (en) Virtual wallet card selection apparatuses, methods and systems
AU2011261259B2 (en) Payment tokenization apparatuses, methods and systems
AU2017202809A1 (en) Social media payment platform apparatuses, methods and systems
US20120316992A1 (en) Payment privacy tokenization apparatuses, methods and systems
US20130024371A1 (en) Electronic offer optimization and redemption apparatuses, methods and systems
AU2016203811A1 (en) Universal electronic payment apparatuses, methods and systems
WO2013049359A1 (en) Social network payment authentication apparatuses, methods and systems
WO2014011691A1 (en) Multi-purpose virtual card transaction apparatuses, methods and systems
WO2013049329A1 (en) Electronic offer optimization and redemption apparatuses, methods and systems
WO2013044175A1 (en) Consumer transaction leash control apparatuses, methods and systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12852590

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12852590

Country of ref document: EP

Kind code of ref document: A1