Patent Grant
11068889
Users often manage multiple digital accounts associated with various entities. For example, these accounts may be associated with a variety of resource providing entities, such as merchants, digital wallet providers, and service providers. In some cases, a user may add a card account to these digital accounts to conduct transactions. Typically, the user may have to provide their card account information to each of the corresponding resource providing entities separately before conducting the transactions. This is cumbersome, since the user has to perform redundant steps of inputting the same card account information. Additionally, since each resource provider may run a different platform, the input process is not smooth and timely.
Furthermore, this process of adding a card account to digital accounts is even more cumbersome when the card account is for a new card. When a user applies for a card account, such as for a credit card, there is typically a delay until the user can utilize the card for transactions. For example, the user typically may wait until the card is made on plastic and shipped to the user, which can take at least five to seven days. This delay limits the user's ability to use the card. In addition, once the card is approved, if the user wishes to add their card account to other digital accounts, they need to add account information for the card manually for each digital account. It would be desirable to provide the user with the ability to use the new card as soon as possible.
Embodiments of the invention address this and other problems, individually and collectively.
Embodiments of the invention relate to systems and methods for provisioning account information to resource providing entities and devices. In some cases, the account information may be for an account that already exists or a new account requested by a user. Embodiments of the invention enable the user to control, through an issuer application (or a third party token portal), to which resource providing entities (e.g., merchants, digital wallet providers, service providers, etc.) the account information is provisioned. In some embodiments, the account information may include a tokenized card account information associated with a card account. In some cases, the token may also be provisioned to other devices (e.g., mobile device, tablet, wearable devices, etc.) indicated by the user. The devices may have a secure element or may be cloud-based. Embodiments of the invention make possible in-app provisioning of the card onto the user's device.
According to one embodiment of the invention, a server computer can perform a method. The server computer may send a list of participating resource providing entities to an authorization computer. The authorization computer may prompt a user operating a user device to make a selection from the list of participating resource providing entities. The server can then receive a selection of one or more resource providing entities from the participating resource providing entities and can receive a request to issue tokens associated with an account of the user for the one or more resource providing entities. For each of the one or more resource providing entities, the server computer can determine a token associated with the account of the user and can send the token to a resource providing entity computer associated with the resource providing entity, wherein the user conducts a transaction with the resource providing entity using the token.
The account may be a new account or an existing account. When the account is a new account, the server computer can receive account information associated with the account from the authorization computer. When the account is an existing account, the server computer can retrieve the account information associated with the account.
In some embodiments, the server computer can perform authentication processes. For each of the plurality of participating resource providing entities selected by the user, the server computer can prompt the user for authentication information for the participating resource providing entity and can send the authentication information to the participating resource providing entity. In some cases, the authentication information may be utilized to generate a new account for the user associated with the participating resource providing entity.
In some embodiments, the server computer can further determine an authentication method supported by the authorization computer. For each of the list of participating resource providing entities, the server computer can also determine an authentication method supported by the participating resource providing entity and can compare the authentication method supported by the participating resource providing entity and the authentication method supported by the authorization computer. Upon determining that the compared authentication methods match, the server computer can include the participating resource providing entity in the list of participating resource providing entities.
In some embodiments, the server computer can determine that at least one of the participating resource providing entities has an account on file for the user. The server computer can send, to the authorization computer, information indicating the at least one participating resource providing entity with which the user has the account on file. In some cases, the selection of the one or more resource providing entities by the user may include a participating resource providing entity that has an account on file for the user. In some cases, the user may further conduct the transaction using the account on file.
In some embodiments, the server computer can generate one or more links. In some implementations, the server computer may generate a link routed to the server computer and can send the link to the authorization computer. The user may activate the link using the user device after the authorization computer prompts the user. In some implementation, the server computer can generate a plurality of links routed to the plurality of resource providing entities and can send the plurality of links to the authorization computer. The user may activate the plurality of links using the user device after the authorization computer prompts the user.
Embodiments of the invention are further directed to a server computer comprising a processor and a computer readable medium. The computer readable medium can be coupled to the processor and can comprise code, executable by the processor, for implementing any of the methods described herein.
These and other embodiments of the invention are described in further detail below.
Embodiments of the invention relate to account information that can be provisioned to resource providing entities and devices. In some embodiments, the account information may be instantly issued to a user. For example, when the user applies for a new payment card with an authorizing entity using a user device, the user can be approved for the new payment card. Subsequently, tokens associated with the new payment card can be provisioned to the user device as well as to resource providing entities selected by the user. In other embodiments, tokens associated with the new payment card may be created at a later time following issuance of the card. Hence, embodiments of the invention are not limited to instant issuance of cards.
Additional steps may be performed to provide the new payment card account number or token associated with the new payment account number to account on file (e.g., card on file) merchants. Embodiments of the invention enable the user to control, through an issuer application (or a third party token portal), to which resource providing entities (e.g., merchants, digital wallet providers, service providers, etc.) the newly issued card's token is provisioned. In some embodiments, the token may also be provisioned to other devices (e.g., mobile device, tablet, wearable devices, etc.) indicated by the user. The devices may have a secure element or may be cloud-based. Embodiments of the invention make possible in-app provisioning of the card onto the user's device.
In some embodiments, the user may not be restricted to utilizing the tokens for recurring payments. For example, once a token is provisioned to a merchant or device, the token can be utilized for any transaction of any type (e.g., recurring, one-time, on-demand, etc.). Payment methods for the transactions may include eCommerce (electronic commerce), mCommerce (mobile commerce), In-app (purchases from within an application), NFC (near field communication), MST (Magnetic Secure Transmission™).
Further, embodiments of the invention are not limited to instant issuance and newly issued cards. Embodiments of the invention also enable provisioning of a user's existing cards to resource providing entities and devices. For example, the user may log in to their mobile or online banking account and push a token tied to one of their existing cards to resource providing entities participating in a tokenization program or to their other devices.
Further, embodiments of the invention are not limited to provisioning tokens to already existing accounts or profiles associated with the resource providing entities. Embodiments of the invention also enable the user to request the addition of tokens associated with a new or existing card to a new account or profile associated with a resource providing entity, in addition to an existing account or profile associated with a resource providing entity. In some cases, the new or existing accounts or profiles may be those associated with the user or a secondary user (e.g., family member, employee, etc.). The new account or profile can be created upon the user's request to provision tokens to the resource providing entity.
Before discussing specific embodiments and examples, some descriptions of terms used herein are provided below.
An “authorization request message” may be an electronic message that is sent to a payment processing network and/or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with (International Organization of Standardization) ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
An “authorization response message” may be an electronic message reply to an authorization request message generated by an issuing financial institution or a payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g. POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a payment processing network may generate or forward the authorization response message to the merchant.
A “token” may include a substitute identifier for some information. For example, a payment token may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For instance, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction. The token may also be used to represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived.
A “resource providing entity” may be an entity that may make resources available to a user. Examples of resource providing entities include merchants, vendors, suppliers, owners, traders, wallet providers, service providers, and the like. In some embodiments, such entities may be a single individual, small groups of individuals, or larger groups of individuals (e.g., companies). Resource providing entities may be associated with one or more physical locations (e.g., supermarkets, malls, stores, etc.) and online platforms (e.g., e-commerce websites, online companies, etc.). In some embodiments, resource providing entities may make available physical items (e.g., goods, products, etc.) to the user. In other embodiments, resource providing entities may make available digital resources (e.g., electronic documents, electronic files, etc.) to the user. In other embodiments, resource providing entities may manage access to certain resources by the user. In some embodiments, the resources may be services (e.g., digital wallet services). A resource providing entity may also be known as a resource provider or the like.
A “participating resource providing entity” may be a resource providing entity that is partaking in a program. In some cases, the participating resource providing entity may be a resource providing entity that is enrolled in a tokenization program. For example, the participating resource providing entity may have an account with a token service provider (e.g., processor server computer) and may be able to process transactions conducted utilizing tokenized account information (e.g., tokens).
An “authorization computer” can include any system involved in authorization of a transaction. The authorization computer may be operated by an authorizing entity. The authorization computer may determine whether a transaction can be authorized and may generate an authorization response message including an authorization status (also may be known as an authorization decision). In some embodiments, an authorization computer may be a payment account issuer computer. In some cases, the authorization computer may store contact information of one or more users. In other embodiments, the authorization computer may authorize non-financial transactions involving a user. For example, the authorization computer may make an authorization decision regarding whether the user can access a certain resource.
“Account information” may refer to any information associated with a user's account (e.g., a payment account and/or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include a PAN (Primary Account Number or “account number”), user name, expiration date, CVV (Card Verification Value), dCVV (Dynamic Card Verification Value), CVV2 (Card Verification Value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values are generally visible to a user (e.g., a consumer), whereas CVV and dCVV values are typically embedded in memory or authorization request messages and are not readily known to the user (although they are known to the issuer and payment processors). In some cases, account information may also be known as card account information.
“Contact information” may refer to any information that can be utilized to communicate with a user. For example, contact information may include an email address, a phone number, IP address, or other information. In some embodiments, contact information may serve as an alias identifier for a user.
“Transaction data” (which may also be known as transaction information) may refer to any data or information surrounding or related to a transaction. For example, transaction data may include transaction details and any data associated with the transaction that may be utilized by entities involved in the transaction process. For instance, the transaction data may include information useful for processing and/or verifying the transaction. Transaction data may also include any data or information surrounding or related to any participants partaking in or associated with the transaction. Example transaction data may include a transaction amount, transaction location, resources received (e.g., products, documents, etc.), information about the resources received (e.g., size, amount, type, etc.), resource providing entity data (e.g., merchant data, document owner data, etc.), user data, date and time of a transaction, payment method, and other relevant information.
A “card on file” may be alternatively referred to as an “account on file.” An account on file may refer to an account identifier (e.g., an account number) that is on file with a resource providing entity, such as a merchant, digital wallet, or other entity. In such situations, the account identifier may be used by a user to conduct purchases with the resource providing entity. The user does not need to specifically provide his or her account number to the resource providing entity when conducting a transaction, since the resource providing entity already has it. In some embodiments, account on file purchases may vary in frequency and/or amount and may represent an agreement between a cardholder and a merchant to purchase goods or services provided over a period of time or on demand.
A “server computer” can be a powerful computer or a cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server.
Access device 12 may be any suitable device that provides access to a remote system. Access device 12 may be in any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. Access device 12 may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, user device 10.
In some embodiments, where access device 12 may comprise a POS terminal, any suitable POS terminal may be used and can include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and/or mobile device. In some embodiments, a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or an “mPOS” terminal.
At step S1, the user may apply for a new account. In some embodiments, the user may see an advertisement for creating the new account, where the advertisement may lead to a website from which the user can send a request to apply for the new account. The website may be hosted by an authorization computer associated with an authorizing entity (e.g., issuer) that may issue the new account.
The advertisement may be in various forms. In some cases, the advertisement may be in the form of a physical poster, which may include a scannable code (e.g., QR code) or printed link. The user may scan the scannable code, which may open a browser on user device 10. In other cases, the user may type in the printed link to open the website. In other cases, the advertisement may be received by email or text message, and may include a link that the user may activate to be routed to the website. In yet other embodiments, the advertisement may be an online advertisement that may appear when the user is browsing the web. The advertisement may be clicked to route the user to the website.
After being routed the website, the user may be prompted to input information to apply for the new account. In some cases, the information may include a name, address, and contact information (e.g., email address, a phone number, etc.). In some cases, upon entering the information, the user may confirm the information by activating a software button (e.g., “Apply Now” button). This may trigger the information input by the user to be sent to the authorization computer, which may conduct an approval process to determine whether the new account can be created for the user. If generation of the account is approved, the authorization computer may generate the new account associated with the user. In some cases, generating the new account may comprise generating an account identifier associated with the new account.
At step S2, the user may be prompted with a plurality of participating resource providing entities from which the user can make a selection. The participating resource providing entities may be entities participating in a tokenization program. By selecting a resource providing entity, the user may indicate that they want to provision a token associated with the new account to the resource providing entity. In some cases, the participating resource providing entities may include various merchants, digital wallet providers, and service providers with which the user may or may not have an existing account or profile.
The user may be prompted with any suitable interface that enables selection of one or more participating resource providing entities. In some cases, the user interface may comprise selectable tiles labeled with identifiers (e.g., names) associated with a corresponding resource providing entity as shown in
In some embodiments, the participating resource providing entities may be presented in the user interface in a certain manner. For example, in some cases, the participating resource providing entities may be pre-selected when presented in the interface. In some cases, there participating resource providing entity may also be displayed at the top of the list of participating resource providing entities presented in the user interface. This may allow the user to easily confirm whether to add the new account to these pre-selected participating resource providing entities. However, the user may de-select any of the pre-selected participating resource providing entities to indicate that tokens associated with the new account should not be provisioned to that particular participating resource providing entity. The user may also select any additional participating resource providing entities to which tokens associated with the new account should be provisioned.
In some cases, upon making a selection of participating resource provider entities, the user may confirm the selection by activating a software button (e.g., “Confirm” button). This may trigger the selection to be sent to the authorization computer or to a processor server computer (e.g., token service provider). A token associated with the new account may be provisioned to each of the selected participating resource providing entities.
In an exemplary case, one of the selected participating resource providing entities may be a digital wallet provider. If the user already had an account associated with the selected digital wallet provider, a token may be provisioned to the existing account. If the user did not already have an account associated with the selected digital wallet provider, an account may be generated after which a token may be provisioned to the account associated with the digital wallet provider.
In an exemplary case, one of the selected participating resource providing entities may be a merchant. If the user already had an account associated with the selected merchant (e.g., account on file), a token may be provisioned to the existing account. If the user did not already have an account associated with the selected merchant, an account may be generated after which a token may be provisioned to the account associated with the merchant.
At step S3, the user may conduct a transaction utilizing a token provisioned to a selected participating resource providing entity. The selected participating resource providing entity may be a digital wallet provider, as described in the exemplary case above. The user may utilize user device 10 to run an application hosted by the digital wallet provider. In some embodiments, the application may be a digital wallet application that enables contactless transactions. In some cases, the user may indicate to the application to utilize the provisioned token for the transaction. In other cases, information related to the token may be pre-filled by the application. User device 10 may then communicate account information including the token to access device 12 to conduct the transaction. As a result, the new account can be utilized to conduct a transaction with the digital wallet application instantly after issuance.
At step S4, the user may conduct another transaction utilizing a token provisioned to another selected participating resource providing entity. The selected participating resource providing entity may be a merchant, as described in the exemplary case above. In some embodiments, the user may utilize user device 14 to conduct the transaction utilizing the provisioned token. In some embodiments, user device 14 may run a website or application hosted by the merchant. In some cases, the user may indicate to the application or website to utilize the provisioned token for the transaction. In other cases, information related to the token may be pre-filled by the application or website. The user may then conduct the transaction with the merchant using the provisioned token. As a result, the new account can be utilized to conduct a transaction with the merchant instantly after issuance.
While exemplary cases in which the user operates user device 10 and user device 14 are described above, embodiments are not so limited. For example, the tokens may be provisioned for use by another secondary user (e.g., family member, employee, etc.). Based upon the selection of participating resource providing entities by the user, the secondary user may be able to conduct transactions utilizing tokens associated with the user's account with the selected participating resource providing entities.
Further, while exemplary cases in which the provisioned token are associated with a newly issued account, embodiments are not so limited. For example, the provisioned token may be for an existing account associated with the user. In this case, the user may open an application associated with an authorization entity on user device 10, where the application may host the existing account. The user may indicate that they want to provision tokens associated with the existing account to a plurality of selected participating resource providing entities. For any of the selected participating resource providing entities with which no account or profile exists, an account or profile may be generated before a token is added to the generated account or profile. As a result, the user may control the provisioned tokens from the application associated with the authorization entity, while each of the selected resource providing entities may store the token for future use.
Embodiments of the invention may enable provisioning of tokens for various use cases, such as those shown in Table 1 below.
In some embodiments, the user may manage the provisioned tokens through an application (e.g., hosted by authorization entity) or a third party token portal. An exemplary user interface 300 is shown in
The communications network may comprise a plurality of networks for secure communication of data and information between entities. In some embodiments, the communications network may follow a suitable communication protocol to generate one or more secure communication channels between user device 103 and processor server computer 110. Any suitable communications protocol may be used for generating a communications channel. A communication channel may in some instance comprise a “secure communication channel,” which may be established in any known manner, including the use of mutual authentication and a session key and establishment of an SSL session. However, any method of creating a secure channel may be used. By establishing a secure channel, sensitive information may be securely transmitted to facilitate a transaction.
A user 101 (which may also be known as a consumer) may be a cardholder operating user device 103. User 101 may select one or more resource providing entities (e.g., merchants, digital wallet services providers, service providers etc.) to which to provision tokens associated with an account. In some embodiments, the account may be an existing account associated with user 101. In other embodiments, user 101 may request generation of a new account (e.g., new card account) from authorization computer 112. In some embodiments, user 101 may utilize the provisioned tokens associated with the account with service provider application 113 or other platforms related to the selected one or more resource providing entities to conduct a transaction using user device 103.
User device 103 may be any suitable device to conduct a transaction. User device 103 may include a memory that may store service provider application 113 and may be utilized to conduct transactions using service provider application 113. User device 103 may communicate over a communications network with one or more entities, including service provider computer 114 and processor server computer 110. User device 103 may be utilized in a card-not-present transaction, such as through a website hosted by a resource providing entity. In some embodiments, user device 103 may also be capable of communicating by contact or wirelessly with an access device at a payment terminal. In some embodiments, payment methods for the transactions may include eCommerce (electronic commerce), mCommerce (mobile commerce), In-app (purchases from within an application), NFC (near field communication), MST (Magnetic Secure Transmission™).
Some non-limiting examples of user device 103 may include mobile devices (e.g., cellular phones, keychain devices, personal digital assistants (PDAs), pagers, notebooks, laptops, notepads, smart watches, fitness bands, jewelry, etc.), automobiles with remote communication capabilities, personal computers, payment cards (e.g., smart cards, magnetic stripe cards, etc.), and the like. In some embodiments, user device 103 may be configured to communicate with one or more cellular networks.
Service provider application 113 may be accessible by user device 103. Service provider application 113 may be operated by service provider computer 114. In some embodiments, service provider application 113 may store a digital wallet and may include card account information associated with user 101. In some cases, the digital wallet may be a mobile wallet. Some exemplary service provider applications include a wallet application, a digital wallet application, a wallet provider application, a mobile wallet application, or the like.
Service provider computer 114 may issue a service provider account for a user. In some embodiments, service provider computer 114 may be associated with a service provider. In some cases, the service provider may be an application provider, which may be an entity that provides an application to a mobile device for use by a user. In some embodiments, the service provider may be a wallet provider computer and can provide a mobile wallet or payment application (e.g., wallet application) to the user device 103. Service provider computer 114 may operate a server computer that may send and receive messages to and from service provider application 113 on user device 103. The service provider account issued by service provider computer 114 may also be accessed by a website. In some embodiments, the service provider computer 114 may maintain one or more digital wallets for each user, and each digital wallet may be associated with payment data for one or more payment accounts. An example of a digital wallet may be Visa Checkout™. In some cases, the service provider may be known as a resource provider and service provider computer 114 may be known as a resource provider computer.
Resource provider computer 106 may be configured to receive and process transaction data. In some embodiments, the transaction data may be received from user device 103 or an access device in communication with user device 103. Resource provider computer 106 may engage in transactions, sell goods or services, or provide access to goods or services to the consumer. Resource provider computer 106 may accept transaction data in multiple forms and may use multiple tools to conduct different types of transactions. For example, resource provider computer 106 may sell goods and/or services via a website or application, and may accept payments over the Internet. Resource provider computer 106 may also be associated with a physical store that utilizes an access device that can receive transaction data from user device 103 for in-person transactions.
Transport computer 108 is typically a system for an entity (e.g., a bank) that has a business relationship with a particular merchant or other entity. Transport computer 108 may route an authorization request for a transaction to authorization computer 112 via processor server computer 110. In some cases, transport computer 108 may be known as an acquirer computer.
Processor server computer 110 may include data processing subsystems, networks, and operations used to support and deliver authorization services, and clearing and settlement services. An example of processor server computer 110 includes VisaNet®, operated by Visa®. Processor server computer 110 may include wired or wireless network, including the Internet. In some embodiments, processor server computer 110 may be a token service provider and may be in communication with token vault 116, which may store tokens associated with accounts of user 101. In some cases, processor server computer 110 may also be known as a payment processing server computer.
Token vault 116 may comprise any information related to tokens. For example, token vault 116 may store tokens associated with service provider application 113 and a mapping of the tokens to their associated accounts. Token vault 116 may comprise any sensitive information (e.g., account number) associated with the tokens. In some embodiments, processor server computer 110 may communicate with token vault 116 to de-tokenize a token. In some cases, token vault 116 may reside at processor server computer 110.
Authorization computer 112 may be a computer involved in authorization processes. In some embodiments, authorization computer 112 may be run by an entity that can issue accounts. When a transaction involves an account issued by authorization computer 112, authorization computer 112 may verify the account and respond with an authorization response message to transport computer 108 that may be forwarded to an access device, if applicable. Some systems may perform functions of both authorization computer 112 and transport computer 108.
Upon receiving a request from user 101 by user device 103 for a new account, authorization computer 112 may approve user 101 and prompt user 101 to select resource providing entities with which to utilize the new account. In some embodiments, authorization computer 112 may communicate with processor server computer 110 to request tokenization of the newly approved account. In some embodiments, authorization computer 112 may be an issuer computer associated with an authorizing entity (e.g., issuer bank) that issues a payment (credit/debit) card, account numbers or payment tokens utilized for the transactions.
At a later time (e.g., at the end of the day), a clearing and settlement process can occur between transport computer 108, processor server computer 110, and authorization computer 112.
Any of the computing devices (e.g., user device 103, resource provider computer 106, transport computer 108, processor server computer 110, service provider computer 114, and authorization computer 112) may include a processor and a computer readable medium comprising code, executable by the processor for performing the functionality described herein.
Embodiments of the invention enable provisioning of tokens to resource providing entities. There are several configurations of systems and computers, such as those described in
Embodiments of the invention may enable a one-to-many implementation in which an authorization computer may integrate with a plurality of resource providing entities through a single connection with a token provider, which may be a processor server computer. While not explicitly shown in
Processor server computer 510 may be capable of communicating with a plurality of resource providing entities. In some cases, processor server computer 510 may provision tokens to any of the plurality of resource providing entities upon request by any of authorization computers 512. The resource providing entities may include those associated with service provider computers 501, issuer digital wallet provider computers 502, third party digital wallet provider computers 503, merchant computers 504, and networked devices 505. Service provider computer 501 may be associated with any service providers that may store and utilize tokens for transactions. In some embodiments, service provider computers 501 may be provide services (e.g., Visa Checkout™) associated with processor server computer 510. Issuer digital wallet provider computers 502 may enable digital wallets for accounts issued by an authorization computer. Third party digital wallet provider computers 503 may be associated with third parties that provide digital wallets that may store a plurality of accounts. Digital wallets provided by issuer digital wallet provider computers 502 and third party digital wallet provider computers 503 may utilize tokens for transactions conducted with the digital wallets. Merchant computers 504 may be associated with a merchant, which may enable transactions to be conducted utilizing tokens. In some cases, merchant computers 504 may store accounts on file with information related to the tokens. Networked devices 505 may be any suitable devices that can communicate with other computing devices and may store data. In some embodiments, networked devices 505 may be known as IoT devices (Internet of Things devices), which may include wearable devices that can be utilized to conduct transactions with tokens.
In a one-to-many implementation, an exemplary process as shown in flow diagram 600 of
At step S61, user device 601 operated by a user may communicate with authorization computer 612. In some embodiments, user device 601 may run an application hosted by authorization computer 612. In other embodiments, user device 601 may run a browser for a website hosted by authorization computer 612. From within the application or browser, the user may send a request to provision tokens associated with their account (e.g., new or existing) to a plurality of selected resource providing entities. The resource providing entities may also be known as token requestors.
At step S62, authorization computer 612 may communicate with processor server computer 610 to request provisioning of the tokens. Processor server computer 610 may be a service provider that provides tokenization services. Processor server computer 610 may generate tokens for each of the plurality of resource providing entities.
At step S63, processor server computer 610 may communicate with resource provider computer 615. Resource provider computer 615 may be associated with a resource providing entity from the plurality of selected resource providing entities. In some cases, processor server computer 610 may send a token generated for the resource providing entity associated with resource provider computer 615 to resource provider computer 615. Prior to provisioning the token, an authentication process may be conducted between the user and resource provider computer 615. Various authentication methods may be utilized in the one-to-many implementation.
One type of authentication method may be straight through provisioning. In this case, existing integrations (e.g., Security Assertion Markup Language) between authorization computer 612 and processor server computer 610 may be leveraged. Processor server computer 610 may provide services that enable account creation and loading authentication information for resource providing entities. In an exemplary case, a service provided by processor server computer 610 may be Visa Checkout™. The user may access their Visa Checkout™ account through the application or website hosted by authorization computer 612 for authentication when requesting provisioning of the tokens.
Another exemplary authentication method for the one-to many implementation may utilize a pop-up display or the like. For example, when a user utilizes an application or website hosted by authorization computer 612 to request provisioning of tokens, a lightbox display may appear. The lightbox display may be pre-populated with some information related to the user. In some cases, the lightbox display may prompt the user to enter or create a password for an account or profile associated with resource provider computer 615 to which a token is to be provisioned.
At steps S64 and S65, resource provider computer 615 may send information confirming that the token was provisioned. In some embodiments, the information may be sent to authorization computer 612 via processor server computer 610. While
The one-to-many implementation as described above also enables authorization computers to select preferences related to authentication through a single platform, which is convenient. This configuration of preference may occur at any time. For example, authorization computer 612 may login to their account hosted by a processor server computer 610. Authorization computer 612 may select channels (e.g., application, browser, etc.) for which to enable push provisioning of tokens. Authorization computer 612 may further select authentication methods that are supported (e.g., Visa Checkout™, lightbox display, etc.). Authorization computer 612 may view a list of all resource providing entities (e.g., token requestors) that are compatible for push provisioning of tokens based on the selected channels and authentication methods. In some embodiments, authorization computer 612 may also view other information, such as reasons as to why some resource providing entities cannot be supported for push provisioning (e.g., incompatible channel or authentication method). The one-to-many implementation may enable authorization computers to “opt-in” for tokenization programs easily without having to interface with multiple resource providing entities.
In some embodiments, processor server computer 610 may determine and compare authentication methods and authentication channels supported by authorization computer 612 and those supported by a resource providing entity to determine whether the resource providing entity is to be provided to the user for selection. If the compared authentication methods and authentication channels match for an authorization computer and a resource providing entity match, processor server computer 610 may notify authorization computer 612 of the resource providing entity. Subsequently, authorization computer 612 may then prompt the user with a list of participating resource providing entities including the resource providing entity. In some embodiments, this comparison process may be conducted for each of the participating resource providing entities in the list of participating resource providing entities.
Embodiments of the invention may also enable another type of implementation, which may be known as a one-to-one implementation. A one-to-one implementation may enable an authorization computer to integrate directly with resource providing entities on an individual basis. For example, an authorization computer may enable token provisioning to each resource providing entity separately based on a standard (e.g., associated with a processor server computer) or proprietary APIs (e.g., push provisioning API).
In a one-to-one implementation as shown in
In a one-to-one implementation, an exemplary process as shown in flow diagram 800 of
At step S81, user device 801 operated by a user may communicate with authorization computer 812. In some embodiments, user device 801 may run an application hosted by authorization computer 812. In other embodiments, user device 801 may run a browser for a website hosted by authorization computer 812. From within the application or browser, the user may send a request to provision tokens associated with their account (e.g., new or existing) to a plurality of selected resource providing entities. The resource providing entities may also be known as token requestors.
At step S82, authorization computer 812 may communicate with resource provider computer 815 to request provisioning of a token to resource provider computer 815. Resource provider computer 815 may be associated with a resource providing entity from the plurality of resource providing entities selected by the user. In some embodiments, an authentication process may be performed between the user and resource provider computer 815.
One type of authentication method may comprise redirecting the user to a channel associated with the resource providing entity. For example, the user may be redirected from the application or browser hosted by authorization computer 812 to an application or website hosted by resource provider computer 815. In some embodiments, a page may be displayed prompting the user for information to complete account creation or the authentication process. For example, the user may create or enter a password to be utilized with their account or profile hosted by resource provider computer 815.
Another type of authentication method may comprise sending a message to enable a secondary user to login or create an account with the resource providing entity. For example, in some cases, the user may want to provision a token to a secondary user's account (e.g., family member's account, employee's account, etc.). In some embodiments, the user may enter an channel identifier (e.g., email address, phone number, etc.) associated with the secondary user, and authorization computer 812 may send a message to the secondary user through a channel (e.g., email, text message, etc.) associated with the channel identifier. The message may include a link that may direct the secondary user to an application or website hosted by resource provider computer 815, which may prompt the secondary user to input information to login or create an account. For example, the secondary user may create or enter a password to be utilized with their account or profile hosted by resource provider computer 815.
At step S83, resource provider computer 815 may request a token from processor server computer 810. In some cases, resource provider computer 815 may confirm to processor server computer 810 that the user or secondary user was authenticated based on information provided by the user before the token can be generated.
At step S84, processor server computer 810 may generate and provision a token to resource provider computer 815. Processor server computer 810 may generate a token meant for use with resource provider computer 815 and send it to resource provider computer 815.
At step S85, resource provider computer 815 may send information confirming that the token was provisioned. In some embodiments, the user may be redirected back to the application or website hosted by authorization computer 812. While
For example, certain steps described in
A method according to the embodiments of the invention can be described with respect to
At step 1, resource provider computer 906 may send a request to processor server computer 910 to sign up for tokenization. This sign up process may be conducted at any time prior to a transaction. The resource providing entity associated with resource provider computer 906 may request processor server computer 910 to participate in tokenized transactions, in which a user may utilize a token when making a payment with the resource providing entity. Upon receiving the request, processor server computer 910 may store information indicating the resource providing entity as a participating resource providing entity.
At step 2, the user may apply for a new card account using their user device 903. In some embodiments, the user may receive a promotion (e.g., by email, text message, etc.) to create a new card. The promotion may include a link which the user may activate to initiate a request for the new card. The user may activate the link (e.g., by clicking the link), which may launch an application (e.g., banking application) on user device 903. In some embodiments, the application may be hosted by authorization computer 912. The application may display a user interface requesting the user to enter information to be utilized to create the new card account with the authorizing entity associated with authorization computer 912. The user may enter the user information into user device 903.
At step 3, user device 903 may send a request for the new card account including the information entered by the user to authorization computer 912. In some embodiments, the information may include user information, such as name, address, and other contact information associated with the user.
At step 4, authorization computer 912 may approve the user based on the entered information. If authorization computer 912 approves the user, authorization computer 912 may issue the new card to the user. Authorization computer 912 may generate card account information for the new card requested by the user. In some embodiments, the card account information may include an account identifier (e.g., account number), an expiration date, a card verification value (CVV), and other transaction information that may be utilized for a transaction.
At step 5, authorization computer 912 may send the card account information for the new card and the user information to processor server computer 910. The information may be sent in any suitable manner, such as by an electronic message sent over a communications network. Processor server computer 910 may be a token service provider.
At step 6, processor server computer 910 may notify authorization computer 912 about a list of the participating resource providing entities that signed up for tokenization. In this exemplary case, resource provider computer 906 and service provider computer 914 may be associated with participating resource providing entities. In some embodiments, resource provider computer 906 may also be known as a merchant computer and service provider computer 914 may also be known as a digital wallet provider computer. Additionally, in some embodiments, processor server computer 910 may notify authorization computer 912 about a list of entities with preexisting tokens and thus already have an account on file associated with the user. This may enable instant association with preexisting tokens associated with the user.
At step 7, authorization computer 912 may prompt the user to make a selection from the participating resource providing entities with which utilize the new card. For example, authorization computer 912 may prompt the user using a user interface (e.g., including a list, tile options, etc.) displayed on user device 903 including the participating resource providing entities that are signed up for tokenization. In some embodiments, authorization computer 912 may also provide pre-selected resource providing entities that correspond to those resource providing entities with which the user already has an account (e.g., token) on file. However, the user may deselect any of the pre-selected resource providing entities if the user does not desire to utilize their new card with any of the pre-selected resource providing entities. Thus, the resource providing entities options provided to the user may be those with which the user may or may not already have an account on file. While
At step 8, the user may select one or more resource providing entities from the received list. The selection may be indicated by any suitable interaction with the user interface displayed on the user device of the user. For example, the user may confirm their selection by clicking on software or hardware buttons (e.g., checkboxes, tiles, etc.), inputting a voice command, or other suitable methods. In an exemplary case, the user may select a resource providing entity associated with resource provider computer 906 and a resource providing entity associated with service provider computer 914. While the exemplary case in which the user selects two resource providing entities is described in flowchart 900, in other embodiments, the user may select any suitable number of resource providing entities. User device 903 may send the selection of the one or more resource providing entities to processor server computer 910 with a request to issue tokens associated with the account of the user to the selected one or more resource providing entities.
In some embodiments, processor server computer 910 may verify communications sent from user device 903 in step 8. Processor server computer 910 may conduct a verification process based on information related to the user operating user device 903 or user device 903. For example, user device 903 may send an identifier (e.g., transaction identifier) along with the selection of one or more resource providing entities in step 8. In some cases, the identifier may be generated by user device 903 or authorization computer 912 hosting the application on user device 903. In some embodiments, the identifier may be generated based on any combination of a device identifier, timestamp, user information, IP address, or other information. Processor server computer 910 may check whether the identifier received from user device 903 in step 8 matches an identifier received previously from user device 903 (e.g., at step 3) or authorization computer 912 (e.g., at step 5).
At step 9, processor server computer 910 may tokenize the new card. Processor server computer 910 may generate one or more tokens associated with the account of the new card that may be utilized for transactions by the user. Processor server computer 910 may be in communication with a token vault, which may store the one or more tokens, a mapping between the one or more tokens and the account of the new card issued to the user, and any other information related to the token. During a transaction, processor server computer 910 may receive the one or more tokens and may de-tokenize the tokens based on information in the token vault, so that the transaction can be applied to the appropriate account associated with the token.
Processor server computer 910 may determine a token for each selected resource providing entity. Determining a token may comprise generating a token or identifying a token, if the token has been pre-generated. For example, processor server computer 910 may determine a first token to be provisioned to service provider computer 914 and a second token to be provisioned to resource provider computer 906. Both the first token and the second token may be associated with the newly issued card by authorization computer 912. In the exemplary flowchart 900, the user may already be enrolled with service provider computer 914 and may have an account on file with resource provider computer 206.
At step 10, processor server computer 910 may send the user information and the first token to service provider computer 914. Service provider computer 214 may be associated with a wallet provider selected by the user and that is supported by the authorizing entity associated with authorization computer 912. The user information and the first token may be sent in any suitable manner, such as by an electronic message sent over a communications network.
At step 11, service provider computer 914 may authenticate the user. In some embodiments, service provider computer 914 may conduct an authentication process with backend processing without requesting input from the user, such as checking whether the received user information matches information associated with the user already stored in its systems. Further details regarding exemplary authentication processes are described with respect to
At step 12, service provider computer 914 may store the received user information and the first token. Service provider computer 914 may store the first token such that it is associated with the newly issued card and the user information. Hence, the first token may be provisioned directly from the mobile banking application operated by the user to service provider computer 914.
At step 13, processor server computer 910 may send the user information and the second token to resource provider computer 906. Resource provider computer 906 may be associated with the resource providing entity (e.g., merchant) selected by the user. The user information and the second token may be sent in any suitable manner, such as by an electronic message sent over a communications network.
At step 14, resource provider computer 906 may authenticate the user. In some embodiments, resource provider computer 906 may conduct an authentication process with backend processing without requesting input from the user, such as checking whether the received user information matches information associated with the user already stored in its systems. Further details regarding exemplary authentication processes are described with respect to
At step 15, resource provider computer 906 may store the received user information and the second token. Resource provider computer 906 may store the second token such that it is associated with the newly issued card and the user information. Hence, the second token may be provisioned directly from the mobile banking application operated by the user to resource provider computer 906. In some embodiments, the second token may also be stored in association with other accounts on file (e.g., including preexisting tokens) that the user has with resource provider computer 906.
In some embodiments, steps 10 through 12 and steps 13 through 15 described above may be initiated at the same time or in a different order than as shown in flowchart 900. For example, processor server computer 910 may send information in step 13, followed by steps 14 and 15, to resource provider computer 906 before sending information in step 10, flowed by steps 11 and 12, to service provider computer 914, or may send information to resource provider computer 906 and service provider computer 914 at the same time.
At step 16, the user may utilize their user device 903 to conduct transactions with their newly provisioned tokens. For example, the user may access their digital wallet (e.g., by a wallet application) associated with service provider computer 914 and utilize the first token with the digital wallet to make a purchase. Additionally, the user may access an online website associated with resource provider computer 906 and utilize the second token to make another purchase. In subsequent purchases, the user may utilize the first token and second token. Hence, the tokens can be provisioned when the card is issued, which can enable the user to immediately access and utilize the tokens for transactions, including with account on file merchants. This is efficient, takes minimal effort by the user, and provides more flexibility for the user. Further, the use of tokenization enables security of the transactions since sensitive data is masked.
A concrete example of a case in which the steps of flowchart 900 may be performed is provided below. A user may be operating a user device and may receive a promotion for a new card by email. The user may click on the promotion, which can launch their mobile banking application on their user device. The user may enter user information to apply for the new card and send to an issuer hosting the application by pressing an “Apply” button. The issuer may approve the user and the new card may be issued to the user.
Subsequently, the user may be prompted to add their newly issued card (e.g., tokens) to participating resource providing entities. The user may be presented with a user interface including a list of resource providing entity names (e.g., vendors, retailers, digital wallet providers, etc.). The user may select one or more resource providing entities by clicking on the one or more resource providing entities indicated on the list. The user may select a digital wallet provider and a merchant, with which the user may already have accounts. A first token may be generated and pushed to the user's digital wallet provider account associated with the selected digital wallet provider and a second token may be generated and pushed to the user's merchant account associated with the selected merchant.
The provisioned tokens may then be available for immediate use by the user. For example, the user may go to a store to purchase a beverage. The user may utilize their digital wallet provider account with their user device to pay for the beverage with the account of their newly issued card. Additionally, the user may shop online with their merchant account using the same user device or another device. When the user checks out to make a purchase, the newly issued card may already be provisioned such that the user may select it from a list including other accounts on file that the user has with the merchant. In other cases, the account information (e.g., token) may be pre-filled on the checkout page. Subsequently, the user may then utilize the newly issued card to pay for the purchase.
As described above, the user may utilize their new card for transactions conducted at physical POS (point-of-sale) terminal, as well as transactions conducted remotely. For example, the user may pay for a transaction using their new card by a contactless transaction with an access device at a merchant. Additionally, the user may pay for an e-commerce transaction using their new card account. Hence, the user device may be any suitable device that may be capable of conducting both types of transactions. Some exemplary payment methods may include eCommerce (electronic commerce), mCommerce (mobile commerce), In-app (purchases from within an application), NFC (near field communication), and MST (Magnetic Secure Transmission™).
As indicated above with respect to the description related to
While the description related to
Embodiments of the invention may provide a number of advantages. For example, embodiments of the invention increase efficiency as a user no longer needs to wait to receive a plastic card in order to utilize a new card account and can have a new card immediately available, with minimal user input, on their mobile device once approved by an issuer. This forgoes the need for the user to manually set up accounts with multiple resource providing entities, which can be repetitive and cumbersome. In some cases, embodiments of the invention may enable users to be inclined to utilize their new card with new resource providing entities including digital wallet services and merchants, in addition to resource providing entities with which the user may already have an account on file, since tokens for the newly issued card can be easily provisioned with minimal user effort. Additionally, embodiments of the invention enable users to proactively create, view, and manage their tokens, which gives them control, security, flexibility, and the ability to better track their credentials. Regarding the processor server computer, embodiments of the invention also provide advantages. For example, leveraging the ability of token services provided by a processor server computer forgoes the need to build and manage any token vault by a third party, which may not be as efficient and secure.
Descriptions corresponding to
A method according to the embodiments of the invention can be described with respect to
At step 1, user 201 applies for a new card using their user device. For example, user 201 may be shopping online on a merchant website using their user device and may see an advertisement showing that conducting a checkout process with a card issued by the issuer associated with authorization computer 212 will give user 201 a discount User 201 may click on the advertisement, redirecting user 201 to a website associated with the authorizing entity and hosted by authorization computer 212. The website may display a user interface requesting user 201 to enter information to be utilized to create the new card with the issuer. User 201 may enter the information, which may be forwarded to authorization computer 212. In some embodiments, the information may include a user data (e.g., name, address, contact information, etc.).
At step 2, authorization computer 212 may approve user 201 based on the entered information. If authorization computer 212 approves user 201, authorization computer 212 may issue the new card to user 201. Authorization computer 212 may generate card information for the new card requested by user 201. In some embodiments, the card information may include an account identifier (e.g., account number), other account information (e.g., expiration date, CVV, etc.), and transaction information that may be utilized for a transaction. Card information may also be known as account information or card account information.
At step 3, authorization computer 212 may send the card information for the new card to processor server computer 210. In addition to the card information, authorization computer 212 may send cardholder information, cardholder contact information, and any additional future processing instructions. An example of a future processing instruction may be an instruction to not validate the consumer address when the consumer creates their account. The card information and additional information may be sent in any suitable manner, such as by an electronic message sent over a communications network. Processor server computer 210 may be a token service provider.
At step 4, processor server computer 210 may activate an account associated with the new card and may tokenize the new card. For example, processor server computer 210 may generate a token associated with the account of the new card that may be utilized for a transaction by user 201. Processor server computer 210 may be in communication with a token vault, which may store the token, a mapping between the token and the account of the new card issued to user 201, and any other information related to the token. During a transaction, processor server computer 210 may receive the token and may de-tokenize the token based on information in the token vault so, that the transaction can be applied to the appropriate account associated with the token.
At step 5, processor server computer 210 may send token information, which may be any information related to the token generated by processor server computer 210, to authorization computer 212. The token information may be sent in any suitable manner, such as by an electronic message sent over a communications network. In some embodiments, processor server computer 210 may also send authorization computer 212 an access link along with the token information. For example, the access link may be a link that can redirect user 201 using their user device to a website or application hosted by processor server computer 210.
At step 6, in some embodiments, authorization computer 112 may send a confirmation that the token information was received from processor server computer 210. In some embodiments, authorization computer 212 may send user information received in step 1 to processor server computer 210. In other embodiments, the user information may be sent with card information in step 3 or other appropriate step.
At step 7, authorization computer 212 may prompt user 201 to select wallet providers to utilize with the new card. For example, authorization computer 212 may prompt user 201 by a user interface (e.g., including a list, tile options, etc.) displayed on the user device of user 201. Authorization computer 212 may provide user 201 options to select wallet providers that are supported for use with the new card issued by the issuer associated with authorization computer 212. In some embodiments, user 201 may already be enrolled with one or more of the provided wallet providers. In other embodiments, user 201 may not be enrolled with one or more of the provided wallet providers.
At step 8, user 201 may select a wallet provider from the options provided by authorization computer 212. The selection may be indicated by any suitable interaction with the user interface displayed on the user device of user 201. For example, user 201 may confirm their selection of the wallet provider by clicking on a software or hardware button, inputting a voice command, or other suitable methods. While an exemplary case in which user 201 selects a single wallet provider is described in flowchart 1000 for simplicity, in some embodiments, user 201 may select multiple wallet providers from the provided options for which to utilize with the new card.
After user 201 selects the wallet provider, authorization computer 212 may redirect user 201 to processor server computer 210, so that the new card may be enrolled in the selected wallet provider. The redirection may be implemented in any suitable manner. For example, in one implementation, upon user 201 confirming their selection of the wallet provider, authorization computer 212 may redirect user 201 based on the access link provided by processor server computer 210 to authorization computer 212 in step 5. In another implementation, authorization computer 212 may embed the access link in a button clicked on by user 201 to confirm the selection of the wallet provider. The access link may be activated when the button is clicked by user 201, redirecting user 201 to a website hosted by processor server computer 210.
Processor server computer 210 may display, to user 201 by their user device, information that will be utilized to enroll the new card with the selected wallet provider. For example, the information may be user information and token information associated with the new card. Processor server computer 210 may request user 201 to validate the information before enrolling the new card with the wallet provider. For example, user 201 may check whether the displayed information is accurate and then may confirm to that the information is valid. User 201 may indicate the confirmation by clicking on a software or hardware button, inputting a voice command, or other suitable methods. In some embodiments, user 201 may validate the information prior to selecting the wallet provider.
At step 9, after user 201 validates the information, processor server computer 210 may send user information and token information to service provider computer 214. Service provider computer 214 may be associated with the wallet provider selected by user 201 and that is supported by the issuer associated with authorization computer 212. The user information and token information may be sent in any suitable manner, such as by an electronic message sent over a communications network.
At step 10, service provider computer 214 may store the received information in its local systems. Based on the received information, service provider computer 214 may determine whether user 201 has an existing account with service provider computer 214. For example, service provider computer 214 may check whether any existing account including the received user information (e.g., name, address, etc.) is stored in its systems.
At step 11, in some embodiments, service provider computer 214 may notify processor server computer 210 that the received information was stored. In some embodiments, service provider computer 214 may also notify whether user 201 has an existing account with service provider computer 214.
At step 12, service provider computer 214 may prompt user 201 to provide wallet provider account information. If service provider computer 214 determines that user 201 does not have an existing account, service provider computer 214 may prompt user 201 to create a new account. For example, service provider computer 214 may prompt user 201 to create a new username, password, and enter any other registration information (e.g., contact information) to generate the new account.
At step 13, in response to the prompt from service provider computer 214, user 201 may enter the wallet provider account information. If user 201 is creating a new account with service provider computer 214, user 201 may enter a new username, password, and enter any other registration information to generate the new account.
At step 14, service provider computer 214 may create a wallet provider account for user 201. The account may be associated with the registration information entered by user 201. Further, service provider computer 214 may link the new account to the token received by processor server computer 210 and associated with the new card issued by authorization computer 212. This can enable user 201 to utilize the newly issued card with their wallet provider account.
In other embodiments, user 201 may already have an existing account with service provider computer 214. In this case, at step 12, service provider computer 214 may simply prompt user 201 for a registered username and password. Further at step 13, if user 201 already has an existing account with service provider computer 214, user 201 may enter their registered username and password into a user interface on their user device to log in to their existing account. At step 14, service provider computer 214 may link the existing account to the token received by processor server computer 210 and associated with the new card issued by authorization computer 212.
At step 15, user 201 may conduct the checkout process on the merchant website using their newly issued card. User 201 may receive the advertised discount on their transaction. Hence, user 201 may request a new card and immediately may be able to utilize the newly issued card with a digital wallet for the transaction.
While the embodiments above describe the user device of user 201 being utilized for remote transactions (e.g., e-commerce transaction, online transaction, etc.), embodiments are not so limited. For example, embodiments of the invention may be extended to transactions that are conducted at a physical POS terminal, in which a similar flow to that of
As described above, in some embodiments, user 201 may select multiple wallet providers from the provided options for which to utilize with the new card. In this case, for each service provider selected by user 201, processor server computer 210 may send user information and token information to a wallet provider computer associated with each selected wallet provider. Additionally, each wallet provider computer that receives information from processor server computer 210 may perform steps 10-12, receive information from user 201 at step 13, and further perform step 14. Thus, the token associated with the newly issued card may be provisioned to multiple digital wallets of user 201, which may be immediately available for use by user 201.
A concrete example of a case in which the steps of flowchart 1000 may be performed is provided below. A user may be shopping at an online website of a merchant, where the website displays an advertisement that offers a discount of 25% off of the user's transaction if the user utilized a card issued by issuer. The user may click the advertisement and apply for a new card with the issuer, which may approve the user and send card account information to a processor server computer. The processor server computer, which may also be a token service provider, may tokenize the card (e.g., generate a new token) and send token information to the issuer computer associated with the issuer along with a link routed to the token service of the token service provider. Subsequently, the issuer computer may send the user the link.
The token service may then validate the user and ask the user with which wallet they would like to enroll. The user may select a wallet provider, such as Visa Checkout™, triggering the token service to send token information to a server associated with Visa Checkout™. The merchant may accept Visa Checkout™ transactions. The Visa Checkout™ server may then prompt the user to create a new Visa Checkout™ account or log in to an existing Visa Checkout™ account. Subsequently, the new token may be provisioned to the user's Visa Checkout™ account. The user may then conduct the transaction with the merchant using the newly issued card account with Visa Checkout™ and receive the advertised 25% discount.
Another use case according to embodiments of the invention is described below. A user may be at a mall and may see an advertisement to utilize a card issuer by a certain issuer for rewards (e.g., gaining loyalty points). The user may open a wallet provider application on their mobile device. The wallet provider application may allow the user to enroll with issuers. Accordingly, the wallet provider application may collect user information from the user and send it to the issuer computer associated with the issuer indicated in the advertisement. The issuer may approve the user and send new account information to a processor server computer, which may also be a token service provider. The processor server computer may tokenize the card, and send a token back to the issuer computer. The issuer computer may send the token to the wallet provider and the wallet provider may provision the token on the user's mobile device. The user can then utilize the mobile device for a checkout process with the advertised rewards applied. Hence, the card may be made available on the mobile device immediately after approval by the issuer.
In some embodiments, tokenization of card account information may not be performed. For example, in the case of flowchart 1000 of
A method according to the embodiments of the invention can be described with respect to
At step 1, user 301 may activate a card. User 301 may enter user data into their user device, which sends the entered user data to authorization computer 312. Authorization computer 312 may approve user 301 based on the entered information. If authorization computer 312 approves user 301, authorization computer 312 may issue the new card to user 301. Authorization computer 312 may generate card information for the new card requested by user 301. In some embodiments, the card information may include an account identifier (e.g., account number), other account information (e.g., expiration date, CVV, etc.), and transaction information that may be utilized for a transaction. Card information may also be known as account information or card account information.
At step 2, authorization computer 212 may enroll the user data in the tokenization program and by sending the user data and the card information for the new card to processor server computer 210. The user data may include cardholder information and cardholder contact information. In addition to the user data and card information, authorization computer 212 may send any additional future processing instructions. An example of a future processing instruction may be an instruction to not validate the consumer address when the consumer creates their account. The user data, card information, and additional instructions may be sent in any suitable manner, such as by an electronic message sent over a communications network.
At step 3, processor server computer 310 may store the received user data and card information and activate an account of user 301. The received user data and card information may be stored in association with user 301, such as in a data record for the account of user 301.
At step 4, processor server computer 310 may enroll the new card in the tokenization program. Processor server computer 310 may generate a token and token identifier for the new card. A token identifier may be a reference to a card account or token. In some embodiments, the token identifier may be specific to a wallet provider or may be a generic identifier that points to an account number. In some embodiments, processor server computer 310 may also generate card art for the new card.
At step 5, processor server computer 310 may generate links to wallet providers (WP links). In some embodiments, the links may be custom wallet provider links. The wallet providers for which processor server computer 310 generates links may be those which are supported by authorization computer 312.
At step 6, processor server computer 310 may send a response to authorization computer 312. The response may include the token identifier, any generated links to wallet providers, card art and other information helpful to authorization computer 312. In some embodiments, sending multiple wallet provider links may be optional.
At step 7, authorization computer 312 may deliver the token identifier and wallet provider links to user 301. In some embodiments, the wallet provider links may be provided in a user interface prompting user 301 to choose a wallet provider corresponding to one of the provided wallet provider links.
At step 8, user 301 may access the selected link received from authorization computer 312. User 301 may be able to select a link by clicking the link or a software button with the embedded link. While a case in which a single link is selected is described in this flow, in other cases, user 301 may select more than one link. In some embodiments, the selected link may be associated with service provider computer 314.
At step 9, in response to user 301 accessing the link, user 301 may be directed to browser 302. Browser 302 may open a website or application hosted by service provider computer 314.
At step 10, user 301 may visit the website or application hosted by service provider computer 314. At the backend, browser 302 may request any information utilized to run the website or application from service provider computer 314. For example, the information may include user interface components, instructions, or other information.
At step 11, service provider computer 314 may return the requested information to browser 302. This may enable browser 302 to display an appropriate page, such as a log in page, to user 301.
At step 12, user 301 may be prompted to log in to their account with service provider computer 314 by browser 302. User 301 may enter verification attributes into the user interface displayed by browser 302. The verification attributes may include a username, password, and the token identifier, which may then be transmitted to service provider computer 314 at step 13.
At step 14, service provider computer 314 may call processor server computer 310 to pull user data associated with user 301 and the newly issued card. For example, processor server computer 310 may open Application Programming Interfaces (APIs) to enable service provider computer 314 to pull data, which may include cardholder information, payment account information, and cardholder contact information. In some embodiments, service provider computer 314 may utilize the APIs to request processor server computer 310 to retrieve certain data. For example, service provider computer 314 may provide the token identifier to processor server computer 310 and request from processor server computer 310 the token associated with the account of user 301. Thus, instead of processor server computer 310 pushing data to service provider computer 314, such as described in
At step 15, processor server computer 310 may retrieve the token associated with the account of user 301 stored in its systems. Processor server computer 310 may send the retrieved token, cardholder information, payment account information, and cardholder contact information to service provider computer 314 at step 16.
At step 17, service provider computer 314 may enable the user to log in to their wallet provider account. Service provider computer 314 may store the information retrieved in steps 14 through 16, including cardholder information, payment account information, cardholder contact information, and token information, in association with the account of user 301.
At step 18, service provider computer 314 may display a notification to browser 302 that user 301 may utilize their new card with their wallet provider account associated with service provider computer 314. This may indicate that the token associated with the newly issued card is provisioned such that user 301 may utilize their new card for subsequent transactions.
A method according to the embodiments of the invention can be described with respect to
Steps 1 through 11 in flowchart 1200 may be similar to corresponding steps 1 through 11 described in flowchart 1100 of
At step 12, browser 402 may have open a website or application hosted by service provider computer 414. Browser 402 may render user 401 to sign up for an account with service provider computer 414 or sign in with an already existing account.
Accordingly, at step 13, if user 401 does not yet have an account with service provider computer 414, user 401 may create a username and password and provide any additional verification data requested by service provider computer 414. If user 401 already has an account with service provider computer 414, then user 401 may enter their registered username and password and any additional verification data requested by service provider computer 414 to enter their existing account. The additional verification data may include a token identifier associated with their new card account.
At step 14, service provider computer 414 may call processor server computer 310 to pull user data associated with user 401 and the newly issued card. For example, processor server computer 410 may open Application Programming Interfaces (APIs) to enable service provider computer 414 to pull data, which may include cardholder information, payment account information, and cardholder contact information. In some embodiments, service provider computer 414 may utilize the APIs to request processor server computer 410 to retrieve certain data. For example, service provider computer 414 may provide the token identifier to processor server computer 410 and request from processor server computer 410 the token associated with the account of user 401. Thus, instead of processor server computer 410 pushing data to service provider computer 414, such as described in
At step 15, processor server computer 410 may send cardholder information, payment account information, and cardholder contact information to service provider computer 414. Subsequently, at step 16, service provider computer 414 may save the received user data in a data record for the wallet provider account of user 401.
At step 17, service provider computer 414 may send a payload including the user data to a user interface displayed on browser 402 for confirmation by user 401. For example, service provider computer 414 may send web page form filled with user data associated with user 401. The form may display the user data in the user interface in editable fields, so that use 401 may change any values if desired.
At step 18, user 401 may view the data sent by service provider computer 414 and update or confirm the data. User 401 may update any data by editing the fields in the user interface. When finished editing, or if no edits are needed, user 401 may confirm the data is accurate by clicking on a button on browser 402. Subsequently, at 19, browser 402 may send an indication that user 401 confirmed the data of the wallet provider account to service provider computer 414. By allowing user 401 to confirm the data, service provider computer 414 ensures accuracy of data while forgoing the need for user 401 to input all the user data, which can be time consuming and cumbersome.
At step 20, service provider computer 414 may link the payload data to the wallet provider account of user 401. For example, service provider computer 414 may store the payload data in association with any other information related to the wallet provider account of user 401.
At step 21, service provider computer 414 may display a notification to browser 402 that user 401 may utilize their new card with their wallet provider account associated with service provider computer 414. This may indicate that the token associated with the newly issued card is provisioned such that user 401 may utilize their new card for subsequent transactions.
Embodiments of the invention may provide a number of advantages. For example, embodiments of the invention increase efficiency as a user no longer needs to wait to receive a plastic card in order to utilize a new card account and can have a new card immediately available, with minimal user input, on their mobile device once approved by an issuer. This forgoes the need for the user to manually add the new card to multiple digital wallets before use. This is in contrast to conventional systems, in which manual addition of the new card to a digital wallet disrupts user experience during a transaction, such as a checkout process.
Further, embodiments of the invention enable issuing a new card that can be utilized with a mobile wallet that was not yet installed on the mobile device when the card was issued. In other words, a digital wallet provider can be chosen after the new card is issued. This allows the user to easily utilize the issued card without the need for a previously installed mobile wallet that must be compatible with the issuer. This is convenient because the user may not know which digital wallets are compatible with the issuer before the new card is issued. Since the user is provided wallet provider options by the issuer computer, this provides the user the flexibility to choose amongst a plurality of wallet providers that may have different benefits. In addition, integrating tokenization processes with embodiments of the invention enables increased efficiency without compromising security of a transaction.
A computer system may be utilized to implement any of the entities or components described above. Subsystems of the computer system may be interconnected via a system bus. Additional subsystems may include a printer, a keyboard, a fixed disk (or other memory comprising computer readable media), a monitor, which is coupled to a display adapter, and others. Peripherals and input/output (I/O) devices, which couple to an I/O controller (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as by a serial port. For example, the serial port or external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may embody a computer readable medium. In some embodiments, the monitor may be a touch sensitive display screen.
A computer system can include a plurality of the same components or subsystems, e.g., connected together by external interface or by an internal interface. In some embodiments, computer systems, subsystem, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system. A client and a server can each include multiple systems, subsystems, or components.
It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g. an application specific integrated circuit or field programmable gate array) and/or using computer software with a generally programmable processor in a modular or integrated manner. As used herein, a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.
Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.
Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.
The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.
This application is a non-provisional of and claims the benefit of priority to U.S. Provisional Application No. 62/242,068, filed Oct. 15, 2015, and U.S. Provisional Application No. 62/242,074, filed Oct. 15, 2015, which are hereby incorporated by reference in its entirety for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5613012 | Hoffman | Mar 1997 | A |
| 5781438 | Lee | Jul 1998 | A |
| 5883810 | Franklin | Mar 1999 | A |
| 5953710 | Fleming | Sep 1999 | A |
| 5956699 | Wong | Sep 1999 | A |
| 6000832 | Franklin | Dec 1999 | A |
| 6014635 | Harris | Jan 2000 | A |
| 6044360 | Picciallo | Mar 2000 | A |
| 6163771 | Walker | Dec 2000 | A |
| 6227447 | Campisano | May 2001 | B1 |
| 6236981 | Hill | May 2001 | B1 |
| 6267292 | Walker | Jul 2001 | B1 |
| 6327578 | Linehan | Dec 2001 | B1 |
| 6341724 | Campisano | Jan 2002 | B2 |
| 6385596 | Wiser | May 2002 | B1 |
| 6422462 | Cohen | Jul 2002 | B1 |
| 6425523 | Shem Ur | Jul 2002 | B1 |
| 6592044 | Wong | Jul 2003 | B1 |
| 6636833 | Flitcroft | Oct 2003 | B1 |
| 6748367 | Lee | Jun 2004 | B1 |
| 6805287 | Bishop | Oct 2004 | B2 |
| 6879965 | Fung | Apr 2005 | B2 |
| 6891953 | DeMello | May 2005 | B1 |
| 6901387 | Wells | May 2005 | B2 |
| 6931382 | Laage | Aug 2005 | B2 |
| 6938019 | Uzo | Aug 2005 | B1 |
| 6941285 | Sarcanin | Sep 2005 | B2 |
| 6980670 | Hoffman | Dec 2005 | B1 |
| 6990470 | Hogan | Jan 2006 | B2 |
| 6991157 | Bishop | Jan 2006 | B2 |
| 7051929 | Li | May 2006 | B2 |
| 7069249 | Stolfo | Jun 2006 | B2 |
| 7103576 | Mann, III | Sep 2006 | B2 |
| 7113930 | Eccles | Sep 2006 | B2 |
| 7136835 | Flitcroft | Nov 2006 | B1 |
| 7177835 | Walker | Feb 2007 | B1 |
| 7177848 | Hogan | Feb 2007 | B2 |
| 7194437 | Britto | Mar 2007 | B1 |
| 7209561 | Shankar et al. | Apr 2007 | B1 |
| 7264154 | Harris | Sep 2007 | B2 |
| 7287692 | Patel | Oct 2007 | B1 |
| 7292999 | Hobson | Nov 2007 | B2 |
| 7350230 | Forrest | Mar 2008 | B2 |
| 7353382 | Labrou | Apr 2008 | B2 |
| 7379919 | Hogan | May 2008 | B2 |
| RE40444 | Linehan | Jul 2008 | E |
| 7415443 | Hobson | Aug 2008 | B2 |
| 7444676 | Asghari-Kamrani | Oct 2008 | B1 |
| 7469151 | Khan | Dec 2008 | B2 |
| 7548889 | Bhambri | Jun 2009 | B2 |
| 7567934 | Flitcroft | Jul 2009 | B2 |
| 7567936 | Peckover | Jul 2009 | B1 |
| 7571139 | Giordano | Aug 2009 | B1 |
| 7571142 | Flitcroft | Aug 2009 | B1 |
| 7580898 | Brown | Aug 2009 | B2 |
| 7584153 | Brown | Sep 2009 | B2 |
| 7593896 | Flitcroft | Sep 2009 | B1 |
| 7606560 | Labrou | Oct 2009 | B2 |
| 7627531 | Breck | Dec 2009 | B2 |
| 7627895 | Gifford | Dec 2009 | B2 |
| 7650314 | Saunders | Jan 2010 | B1 |
| 7685037 | Reiners | Mar 2010 | B2 |
| 7702578 | Fung | Apr 2010 | B2 |
| 7707120 | Dominguez | Apr 2010 | B2 |
| 7712655 | Wong | May 2010 | B2 |
| 7734527 | Uzo | Jun 2010 | B2 |
| 7753265 | Harris | Jul 2010 | B2 |
| 7770789 | Oder, II | Aug 2010 | B2 |
| 7784685 | Hopkins, III | Aug 2010 | B1 |
| 7793851 | Mullen | Sep 2010 | B2 |
| 7801826 | Labrou | Sep 2010 | B2 |
| 7805376 | Smith | Sep 2010 | B2 |
| 7805378 | Berardi | Sep 2010 | B2 |
| 7818264 | Hammad | Oct 2010 | B2 |
| 7828220 | Mullen | Nov 2010 | B2 |
| 7835960 | Breck | Nov 2010 | B2 |
| 7841523 | Oder, II | Nov 2010 | B2 |
| 7841539 | Hewton | Nov 2010 | B2 |
| 7844550 | Walker | Nov 2010 | B2 |
| 7848980 | Carlson | Dec 2010 | B2 |
| 7849020 | Johnson | Dec 2010 | B2 |
| 7853529 | Walker | Dec 2010 | B1 |
| 7853995 | Chow | Dec 2010 | B2 |
| 7865414 | Fung | Jan 2011 | B2 |
| 7873579 | Hobson | Jan 2011 | B2 |
| 7873580 | Hobson | Jan 2011 | B2 |
| 7890393 | Talbert | Feb 2011 | B2 |
| 7891563 | Oder, II | Feb 2011 | B2 |
| 7896238 | Fein | Mar 2011 | B2 |
| 7908216 | Davis et al. | Mar 2011 | B1 |
| 7922082 | Muscato | Apr 2011 | B2 |
| 7931195 | Mullen | Apr 2011 | B2 |
| 7937324 | Patterson | May 2011 | B2 |
| 7938318 | Fein | May 2011 | B2 |
| 7954705 | Mullen | Jun 2011 | B2 |
| 7959076 | Hopkins, III | Jun 2011 | B1 |
| 7996288 | Stolfo | Aug 2011 | B1 |
| 8025223 | Saunders | Sep 2011 | B2 |
| 8046256 | Chien | Oct 2011 | B2 |
| 8060448 | Jones | Nov 2011 | B2 |
| 8060449 | Zhu | Nov 2011 | B1 |
| 8074877 | Mullen | Dec 2011 | B2 |
| 8074879 | Harris | Dec 2011 | B2 |
| 8082210 | Hansen | Dec 2011 | B2 |
| 8095113 | Kean | Jan 2012 | B2 |
| 8104679 | Brown | Jan 2012 | B2 |
| RE43157 | Bishop | Feb 2012 | E |
| 8109436 | Hopkins, III | Feb 2012 | B1 |
| 8121942 | Carlson | Feb 2012 | B2 |
| 8121956 | Carlson | Feb 2012 | B2 |
| 8126449 | Beenau | Feb 2012 | B2 |
| 8132723 | Hogg et al. | Mar 2012 | B2 |
| 8171525 | Pelly | May 2012 | B1 |
| 8175973 | Davis et al. | May 2012 | B2 |
| 8190523 | Patterson | May 2012 | B2 |
| 8196813 | Vadhri | Jun 2012 | B2 |
| 8205791 | Randazza | Jun 2012 | B2 |
| 8219489 | Patterson | Jul 2012 | B2 |
| 8224702 | Mengerink | Jul 2012 | B2 |
| 8225385 | Chow | Jul 2012 | B2 |
| 8229852 | Carlson | Jul 2012 | B2 |
| 8265993 | Chien | Sep 2012 | B2 |
| 8280777 | Mengerink | Oct 2012 | B2 |
| 8281991 | Wentker et al. | Oct 2012 | B2 |
| 8328095 | Oder, II | Dec 2012 | B2 |
| 8336088 | Raj et al. | Dec 2012 | B2 |
| 8346666 | Lindelsee et al. | Jan 2013 | B2 |
| 8376225 | Hopkins, III | Feb 2013 | B1 |
| 8380177 | Laracey | Feb 2013 | B2 |
| 8387873 | Saunders | Mar 2013 | B2 |
| 8401539 | Beenau | Mar 2013 | B2 |
| 8401898 | Chien | Mar 2013 | B2 |
| 8402555 | Grecia | Mar 2013 | B2 |
| 8403211 | Brooks | Mar 2013 | B2 |
| 8412623 | Moon | Apr 2013 | B2 |
| 8412837 | Emigh | Apr 2013 | B1 |
| 8417642 | Oren | Apr 2013 | B2 |
| 8447699 | Batada | May 2013 | B2 |
| 8453223 | Svigals | May 2013 | B2 |
| 8453925 | Fisher | Jun 2013 | B2 |
| 8458487 | Palgon | Jun 2013 | B1 |
| 8484134 | Hobson | Jul 2013 | B2 |
| 8485437 | Mullen | Jul 2013 | B2 |
| 8494959 | Hathaway | Jul 2013 | B2 |
| 8498908 | Mengerink | Jul 2013 | B2 |
| 8504475 | Brand et al. | Aug 2013 | B2 |
| 8504478 | Saunders | Aug 2013 | B2 |
| 8510816 | Quach | Aug 2013 | B2 |
| 8433116 | Davis et al. | Sep 2013 | B2 |
| 8528067 | Hurry et al. | Sep 2013 | B2 |
| 8533860 | Grecia | Sep 2013 | B1 |
| 8538845 | Liberty | Sep 2013 | B2 |
| 8555079 | Shablygin | Oct 2013 | B2 |
| 8566168 | Bierbaum | Oct 2013 | B1 |
| 8567670 | Stanfield | Oct 2013 | B2 |
| 8571939 | Lindsey | Oct 2013 | B2 |
| 8577336 | Mechaley, Jr. | Nov 2013 | B2 |
| 8577803 | Chatterjee | Nov 2013 | B2 |
| 8577813 | Weiss | Nov 2013 | B2 |
| 8578176 | Mattsson | Nov 2013 | B2 |
| 8583494 | Fisher | Nov 2013 | B2 |
| 8584251 | Mcguire | Nov 2013 | B2 |
| 8589237 | Fisher | Nov 2013 | B2 |
| 8589271 | Evans | Nov 2013 | B2 |
| 8589291 | Carlson | Nov 2013 | B2 |
| 8595098 | Starai | Nov 2013 | B2 |
| 8595812 | Bomar | Nov 2013 | B2 |
| 8595850 | Spies | Nov 2013 | B2 |
| 8606638 | Dragt | Dec 2013 | B2 |
| 8606700 | Carlson | Dec 2013 | B2 |
| 8606720 | Baker | Dec 2013 | B1 |
| 8615468 | Varadarajan | Dec 2013 | B2 |
| 8620754 | Fisher | Dec 2013 | B2 |
| 8635157 | Smith | Jan 2014 | B2 |
| 8646059 | Von Behren | Feb 2014 | B1 |
| 8651374 | Brabson | Feb 2014 | B2 |
| 8656180 | Shablygin | Feb 2014 | B2 |
| 8751391 | Freund | Jun 2014 | B2 |
| 8762263 | Gauthier et al. | Jun 2014 | B2 |
| 8793186 | Patterson | Jul 2014 | B2 |
| 8838982 | Carlson et al. | Sep 2014 | B2 |
| 8856539 | Weiss | Oct 2014 | B2 |
| 8887308 | Grecia | Nov 2014 | B2 |
| 9065643 | Hurry et al. | Jun 2015 | B2 |
| 9070129 | Sheets et al. | Jun 2015 | B2 |
| 9100826 | Weiss | Aug 2015 | B2 |
| 9160741 | Wentker et al. | Oct 2015 | B2 |
| 9229964 | Stevelinck | Jan 2016 | B2 |
| 9245267 | Singh | Jan 2016 | B2 |
| 9249241 | Dai et al. | Feb 2016 | B2 |
| 9256871 | Anderson et al. | Feb 2016 | B2 |
| 9280765 | Hammad | Mar 2016 | B2 |
| 9530137 | Weiss | Dec 2016 | B2 |
| 9680942 | Dimmick | Jun 2017 | B2 |
| 9721087 | Duchin et al. | Aug 2017 | B1 |
| 20010029485 | Brody | Oct 2001 | A1 |
| 20010034720 | Armes | Oct 2001 | A1 |
| 20010054003 | Chien | Dec 2001 | A1 |
| 20020007320 | Hogan | Jan 2002 | A1 |
| 20020016749 | Borecki | Feb 2002 | A1 |
| 20020029193 | Ranjan | Mar 2002 | A1 |
| 20020035548 | Hogan | Mar 2002 | A1 |
| 20020073045 | Rubin | Jun 2002 | A1 |
| 20020116341 | Hogan | Aug 2002 | A1 |
| 20020133467 | Hobson | Sep 2002 | A1 |
| 20020147913 | Lun Yip | Oct 2002 | A1 |
| 20030028481 | Flitcroft | Feb 2003 | A1 |
| 20030130955 | Hawthorne | Jul 2003 | A1 |
| 20030191709 | Elston | Oct 2003 | A1 |
| 20030191945 | Keech | Oct 2003 | A1 |
| 20040010462 | Moon | Jan 2004 | A1 |
| 20040050928 | Bishop | Mar 2004 | A1 |
| 20040059682 | Hasumi | Mar 2004 | A1 |
| 20040093281 | Silverstein | May 2004 | A1 |
| 20040139008 | Mascavage | Jul 2004 | A1 |
| 20040143532 | Lee | Jul 2004 | A1 |
| 20040158532 | Breck | Aug 2004 | A1 |
| 20040210449 | Breck | Oct 2004 | A1 |
| 20040210498 | Freund | Oct 2004 | A1 |
| 20040232225 | Bishop | Nov 2004 | A1 |
| 20040260646 | Berardi | Dec 2004 | A1 |
| 20050037735 | Coutts | Feb 2005 | A1 |
| 20050080730 | Sorrentino | Apr 2005 | A1 |
| 20050108178 | York | May 2005 | A1 |
| 20050199709 | Linlor | Sep 2005 | A1 |
| 20050246293 | Ong | Nov 2005 | A1 |
| 20050269401 | Spitzer | Dec 2005 | A1 |
| 20050269402 | Spitzer | Dec 2005 | A1 |
| 20060026671 | Potter et al. | Feb 2006 | A1 |
| 20060235795 | Johnson | Oct 2006 | A1 |
| 20060237528 | Bishop | Oct 2006 | A1 |
| 20060278704 | Saunders | Dec 2006 | A1 |
| 20070107044 | Yuen | May 2007 | A1 |
| 20070129955 | Dalmia | Jun 2007 | A1 |
| 20070136193 | Starr | Jun 2007 | A1 |
| 20070136211 | Brown | Jun 2007 | A1 |
| 20070170247 | Friedman | Jul 2007 | A1 |
| 20070179885 | Bird | Aug 2007 | A1 |
| 20070208671 | Brown | Sep 2007 | A1 |
| 20070245414 | Chan | Oct 2007 | A1 |
| 20070288377 | Shaked | Dec 2007 | A1 |
| 20070291995 | Rivera | Dec 2007 | A1 |
| 20080015988 | Brown | Jan 2008 | A1 |
| 20080029607 | Mullen | Feb 2008 | A1 |
| 20080035738 | Mullen | Feb 2008 | A1 |
| 20080052226 | Agarwal | Feb 2008 | A1 |
| 20080054068 | Mullen | Mar 2008 | A1 |
| 20080054079 | Mullen | Mar 2008 | A1 |
| 20080054081 | Mullen | Mar 2008 | A1 |
| 20080065554 | Hogan | Mar 2008 | A1 |
| 20080065555 | Mullen | Mar 2008 | A1 |
| 20080201264 | Brown | Aug 2008 | A1 |
| 20080201265 | Hewton | Aug 2008 | A1 |
| 20080228646 | Myers | Sep 2008 | A1 |
| 20080243702 | Hart | Oct 2008 | A1 |
| 20080245855 | Fein | Oct 2008 | A1 |
| 20080245861 | Fein | Oct 2008 | A1 |
| 20080283591 | Oder, II | Nov 2008 | A1 |
| 20080302869 | Mullen | Dec 2008 | A1 |
| 20080302876 | Mullen | Dec 2008 | A1 |
| 20080313264 | Pestoni | Dec 2008 | A1 |
| 20090006262 | Brown | Jan 2009 | A1 |
| 20090010488 | Matsuoka | Jan 2009 | A1 |
| 20090037333 | Flitcroft | Feb 2009 | A1 |
| 20090037388 | Cooper | Feb 2009 | A1 |
| 20090043702 | Bennett | Feb 2009 | A1 |
| 20090048971 | Hathaway | Feb 2009 | A1 |
| 20090106112 | Dalmia | Apr 2009 | A1 |
| 20090106160 | Skowronek | Apr 2009 | A1 |
| 20090134217 | Flitcroft | May 2009 | A1 |
| 20090157555 | Biffle | Jun 2009 | A1 |
| 20090159673 | Mullen | Jun 2009 | A1 |
| 20090159700 | Mullen | Jun 2009 | A1 |
| 20090159707 | Mullen | Jun 2009 | A1 |
| 20090173782 | Muscato | Jul 2009 | A1 |
| 20090200371 | Kean | Aug 2009 | A1 |
| 20090248583 | Chhabra | Oct 2009 | A1 |
| 20090260072 | Rouskov et al. | Oct 2009 | A1 |
| 20090276347 | Kargman | Nov 2009 | A1 |
| 20090281948 | Carlson | Nov 2009 | A1 |
| 20090294527 | Brabson | Dec 2009 | A1 |
| 20090307139 | Mardikar | Dec 2009 | A1 |
| 20090308921 | Mullen | Dec 2009 | A1 |
| 20090327131 | Beenau | Dec 2009 | A1 |
| 20100008535 | Abulafia | Jan 2010 | A1 |
| 20100088237 | Wankmueller | Apr 2010 | A1 |
| 20100094755 | Kloster | Apr 2010 | A1 |
| 20100106644 | Annan | Apr 2010 | A1 |
| 20100120408 | Beenau | May 2010 | A1 |
| 20100133334 | Vadhri | Jun 2010 | A1 |
| 20100138347 | Chen | Jun 2010 | A1 |
| 20100145860 | Pelegero | Jun 2010 | A1 |
| 20100161433 | White | Jun 2010 | A1 |
| 20100185545 | Royyuru | Jul 2010 | A1 |
| 20100211505 | Saunders | Aug 2010 | A1 |
| 20100223186 | Hogan | Sep 2010 | A1 |
| 20100228668 | Hogan | Sep 2010 | A1 |
| 20100235284 | Moore | Sep 2010 | A1 |
| 20100257612 | McGuire et al. | Oct 2010 | A1 |
| 20100258620 | Torreyson | Oct 2010 | A1 |
| 20100291904 | Musfeldt | Nov 2010 | A1 |
| 20100299267 | Faith et al. | Nov 2010 | A1 |
| 20100306076 | Taveau | Dec 2010 | A1 |
| 20100325041 | Berardi | Dec 2010 | A1 |
| 20110010292 | Giordano | Jan 2011 | A1 |
| 20110016047 | Wu | Jan 2011 | A1 |
| 20110016320 | Bergsten | Jan 2011 | A1 |
| 20110040640 | Erikson | Feb 2011 | A1 |
| 20110047076 | Carlson et al. | Feb 2011 | A1 |
| 20110083018 | Kesanupalli | Apr 2011 | A1 |
| 20110087596 | Dorsey | Apr 2011 | A1 |
| 20110093397 | Carlson | Apr 2011 | A1 |
| 20110125597 | Oder, II | May 2011 | A1 |
| 20110153437 | Archer | Jun 2011 | A1 |
| 20110153498 | Makhotin et al. | Jun 2011 | A1 |
| 20110154466 | Harper | Jun 2011 | A1 |
| 20110161233 | Tieken | Jun 2011 | A1 |
| 20110178926 | Lindelsee et al. | Jul 2011 | A1 |
| 20110191244 | Dai | Aug 2011 | A1 |
| 20110238511 | Park | Sep 2011 | A1 |
| 20110238573 | Varadarajan | Sep 2011 | A1 |
| 20110246317 | Coppinger | Oct 2011 | A1 |
| 20110258111 | Raj et al. | Oct 2011 | A1 |
| 20110272471 | Mullen | Nov 2011 | A1 |
| 20110272478 | Mullen | Nov 2011 | A1 |
| 20110276380 | Mullen | Nov 2011 | A1 |
| 20110276381 | Mullen | Nov 2011 | A1 |
| 20110276424 | Mullen | Nov 2011 | A1 |
| 20110276425 | Mullen | Nov 2011 | A1 |
| 20110295745 | White | Dec 2011 | A1 |
| 20110302081 | Saunders | Dec 2011 | A1 |
| 20120023567 | Hammad | Jan 2012 | A1 |
| 20120028609 | Hruska | Feb 2012 | A1 |
| 20120030047 | Fuentes et al. | Feb 2012 | A1 |
| 20120035998 | Chien | Feb 2012 | A1 |
| 20120041881 | Basu | Feb 2012 | A1 |
| 20120047237 | Arvidsson | Feb 2012 | A1 |
| 20120066078 | Kingston | Mar 2012 | A1 |
| 20120072350 | Goldthwaite | Mar 2012 | A1 |
| 20120078735 | Bauer | Mar 2012 | A1 |
| 20120078798 | Downing | Mar 2012 | A1 |
| 20120078799 | Jackson | Mar 2012 | A1 |
| 20120095852 | Bauer | Apr 2012 | A1 |
| 20120095865 | Doherty | Apr 2012 | A1 |
| 20120116902 | Cardina | May 2012 | A1 |
| 20120123882 | Carlson | May 2012 | A1 |
| 20120123940 | Killian | May 2012 | A1 |
| 20120129514 | Beenau | May 2012 | A1 |
| 20120143767 | Abadir | Jun 2012 | A1 |
| 20120143772 | Abadir | Jun 2012 | A1 |
| 20120158580 | Eram | Jun 2012 | A1 |
| 20120158593 | Garfinkle | Jun 2012 | A1 |
| 20120173431 | Ritchie | Jul 2012 | A1 |
| 20120185386 | Salama | Jul 2012 | A1 |
| 20120197807 | Schlesser | Aug 2012 | A1 |
| 20120203664 | Torossian | Aug 2012 | A1 |
| 20120203666 | Torossian | Aug 2012 | A1 |
| 20120215688 | Musser | Aug 2012 | A1 |
| 20120215696 | Salonen | Aug 2012 | A1 |
| 20120221421 | Hammad | Aug 2012 | A1 |
| 20120226582 | Hammad | Sep 2012 | A1 |
| 20120231844 | Coppinger | Sep 2012 | A1 |
| 20120233004 | Bercaw | Sep 2012 | A1 |
| 20120246070 | Vadhri | Sep 2012 | A1 |
| 20120246071 | Jain | Sep 2012 | A1 |
| 20120246079 | Wilson et al. | Sep 2012 | A1 |
| 20120265631 | Cronic | Oct 2012 | A1 |
| 20120271770 | Harris | Oct 2012 | A1 |
| 20120297446 | Webb | Nov 2012 | A1 |
| 20120300932 | Cambridge | Nov 2012 | A1 |
| 20120303503 | Cambridge | Nov 2012 | A1 |
| 20120303961 | Kean | Nov 2012 | A1 |
| 20120304273 | Bailey | Nov 2012 | A1 |
| 20120310725 | Chien | Dec 2012 | A1 |
| 20120310831 | Harris | Dec 2012 | A1 |
| 20120316992 | Oborne | Dec 2012 | A1 |
| 20120317035 | Royyuru | Dec 2012 | A1 |
| 20120317036 | Bower | Dec 2012 | A1 |
| 20130017784 | Fisher | Jan 2013 | A1 |
| 20130018757 | Anderson et al. | Jan 2013 | A1 |
| 20130019098 | Gupta | Jan 2013 | A1 |
| 20130031006 | Mccullagh et al. | Jan 2013 | A1 |
| 20130036048 | Campos et al. | Feb 2013 | A1 |
| 20130054337 | Brendell | Feb 2013 | A1 |
| 20130054466 | Muscato | Feb 2013 | A1 |
| 20130054474 | Yeager | Feb 2013 | A1 |
| 20130081122 | Svigals | Mar 2013 | A1 |
| 20130091028 | Oder, II | Apr 2013 | A1 |
| 20130110658 | Lyman | May 2013 | A1 |
| 20130111599 | Gargiulo | May 2013 | A1 |
| 20130117185 | Collison | May 2013 | A1 |
| 20130124290 | Fisher | May 2013 | A1 |
| 20130124291 | Fisher | May 2013 | A1 |
| 20130124364 | Mittal | May 2013 | A1 |
| 20130138525 | Bercaw | May 2013 | A1 |
| 20130144888 | Faith | Jun 2013 | A1 |
| 20130145148 | Shablygin | Jun 2013 | A1 |
| 20130145172 | Shablygin | Jun 2013 | A1 |
| 20130159154 | Purves et al. | Jun 2013 | A1 |
| 20130159178 | Colon | Jun 2013 | A1 |
| 20130159184 | Thaw | Jun 2013 | A1 |
| 20130166402 | Parento | Jun 2013 | A1 |
| 20130166456 | Zhang | Jun 2013 | A1 |
| 20130173736 | Krzeminski | Jul 2013 | A1 |
| 20130185202 | Goldthwaite | Jul 2013 | A1 |
| 20130191227 | Pasa et al. | Jul 2013 | A1 |
| 20130191286 | Cronic | Jul 2013 | A1 |
| 20130191289 | Cronic | Jul 2013 | A1 |
| 20130198071 | Jurss | Aug 2013 | A1 |
| 20130198080 | Anderson et al. | Aug 2013 | A1 |
| 20130200146 | Moghadam | Aug 2013 | A1 |
| 20130204787 | Dubois | Aug 2013 | A1 |
| 20130204793 | Kerridge | Aug 2013 | A1 |
| 20130212007 | Mattsson | Aug 2013 | A1 |
| 20130212017 | Bangia | Aug 2013 | A1 |
| 20130212019 | Mattsson | Aug 2013 | A1 |
| 20130212024 | Mattsson | Aug 2013 | A1 |
| 20130212026 | Powell et al. | Aug 2013 | A1 |
| 20130212666 | Mattsson | Aug 2013 | A1 |
| 20130218698 | Moon | Aug 2013 | A1 |
| 20130218769 | Pourfallah et al. | Aug 2013 | A1 |
| 20130226799 | Raj | Aug 2013 | A1 |
| 20130226813 | Voltz | Aug 2013 | A1 |
| 20130246199 | Carlson | Sep 2013 | A1 |
| 20130246202 | Tobin | Sep 2013 | A1 |
| 20130246203 | Laracey | Sep 2013 | A1 |
| 20130246258 | Dessert | Sep 2013 | A1 |
| 20130246259 | Dessert | Sep 2013 | A1 |
| 20130246261 | Purves et al. | Sep 2013 | A1 |
| 20130246267 | Tobin | Sep 2013 | A1 |
| 20130254028 | Salci | Sep 2013 | A1 |
| 20130254052 | Royyuru | Sep 2013 | A1 |
| 20130254102 | Royyuru | Sep 2013 | A1 |
| 20130254117 | Von Mueller | Sep 2013 | A1 |
| 20130262296 | Thomas | Oct 2013 | A1 |
| 20130262302 | Lettow | Oct 2013 | A1 |
| 20130262315 | Hruska | Oct 2013 | A1 |
| 20130262316 | Hruska | Oct 2013 | A1 |
| 20130262317 | Collinge | Oct 2013 | A1 |
| 20130275300 | Killian | Oct 2013 | A1 |
| 20130275307 | Khan | Oct 2013 | A1 |
| 20130275308 | Paraskeva | Oct 2013 | A1 |
| 20130282502 | Jooste | Oct 2013 | A1 |
| 20130282575 | Mullen | Oct 2013 | A1 |
| 20130282588 | Hruska | Oct 2013 | A1 |
| 20130297501 | Monk et al. | Nov 2013 | A1 |
| 20130297504 | Nwokolo | Nov 2013 | A1 |
| 20130297508 | Belamant | Nov 2013 | A1 |
| 20130304649 | Cronic | Nov 2013 | A1 |
| 20130308778 | Fosmark | Nov 2013 | A1 |
| 20130311382 | Fosmark | Nov 2013 | A1 |
| 20130317982 | Mengerink | Nov 2013 | A1 |
| 20130332344 | Weber | Dec 2013 | A1 |
| 20130339253 | Sincai | Dec 2013 | A1 |
| 20130346305 | Mendes | Dec 2013 | A1 |
| 20130346314 | Mogollon | Dec 2013 | A1 |
| 20140007213 | Sanin | Jan 2014 | A1 |
| 20140013106 | Redpath | Jan 2014 | A1 |
| 20140013114 | Redpath | Jan 2014 | A1 |
| 20140013452 | Aissi et al. | Jan 2014 | A1 |
| 20140019352 | Shrivastava | Jan 2014 | A1 |
| 20140025581 | Calman | Jan 2014 | A1 |
| 20140025585 | Calman | Jan 2014 | A1 |
| 20140025958 | Calman | Jan 2014 | A1 |
| 20140032417 | Mattsson | Jan 2014 | A1 |
| 20140032418 | Weber | Jan 2014 | A1 |
| 20140032419 | Anderson et al. | Jan 2014 | A1 |
| 20140040137 | Carlson | Feb 2014 | A1 |
| 20140040139 | Brudnicki | Feb 2014 | A1 |
| 20140040144 | Plomske | Feb 2014 | A1 |
| 20140040145 | Ozvat | Feb 2014 | A1 |
| 20140040148 | Ozvat | Feb 2014 | A1 |
| 20140040628 | Fort | Feb 2014 | A1 |
| 20140041018 | Bomar | Feb 2014 | A1 |
| 20140046853 | Spies | Feb 2014 | A1 |
| 20140047551 | Nagasundaram et al. | Feb 2014 | A1 |
| 20140052532 | Tsai | Feb 2014 | A1 |
| 20140052620 | Rogers | Feb 2014 | A1 |
| 20140052637 | Jooste | Feb 2014 | A1 |
| 20140068706 | Aissi | Mar 2014 | A1 |
| 20140074637 | Hammad | Mar 2014 | A1 |
| 20140108172 | Weber et al. | Apr 2014 | A1 |
| 20140114857 | Griggs et al. | Apr 2014 | A1 |
| 20140143137 | Carlson | May 2014 | A1 |
| 20140164243 | Aabye et al. | Jun 2014 | A1 |
| 20140188586 | Carpenter et al. | Jul 2014 | A1 |
| 20140249945 | Gauthier | Sep 2014 | A1 |
| 20140294701 | Dai et al. | Oct 2014 | A1 |
| 20140297534 | Patterson | Oct 2014 | A1 |
| 20140310183 | Weber | Oct 2014 | A1 |
| 20140324690 | Allen et al. | Oct 2014 | A1 |
| 20140330721 | Wang | Nov 2014 | A1 |
| 20140330722 | Laxminarayanan et al. | Nov 2014 | A1 |
| 20140331265 | Mozell et al. | Nov 2014 | A1 |
| 20140337236 | Wong et al. | Nov 2014 | A1 |
| 20140344153 | Raj et al. | Nov 2014 | A1 |
| 20140372308 | Sheets | Dec 2014 | A1 |
| 20150012400 | Wassmer et al. | Jan 2015 | A1 |
| 20150019443 | Sheets et al. | Jan 2015 | A1 |
| 20150032625 | Dill | Jan 2015 | A1 |
| 20150032626 | Dill | Jan 2015 | A1 |
| 20150032627 | Dill | Jan 2015 | A1 |
| 20150046338 | Laxminarayanan | Feb 2015 | A1 |
| 20150046339 | Wong et al. | Feb 2015 | A1 |
| 20150052064 | Karpenko et al. | Feb 2015 | A1 |
| 20150088756 | Makhotin et al. | Mar 2015 | A1 |
| 20150106239 | Gaddam et al. | Apr 2015 | A1 |
| 20150112870 | Nagasundaram et al. | Apr 2015 | A1 |
| 20150112871 | Kumnick | Apr 2015 | A1 |
| 20150120472 | Aabye et al. | Apr 2015 | A1 |
| 20150127529 | Makhotin et al. | May 2015 | A1 |
| 20150127547 | Powell et al. | May 2015 | A1 |
| 20150140960 | Powell et al. | May 2015 | A1 |
| 20150142673 | Nelsen et al. | May 2015 | A1 |
| 20150161597 | Subramanian et al. | Jun 2015 | A1 |
| 20150178724 | Ngo et al. | Jun 2015 | A1 |
| 20150180836 | Wong et al. | Jun 2015 | A1 |
| 20150186864 | Jones et al. | Jul 2015 | A1 |
| 20150193222 | Pirzadeh et al. | Jul 2015 | A1 |
| 20150195133 | Sheets et al. | Jul 2015 | A1 |
| 20150199678 | Kaplinger et al. | Jul 2015 | A1 |
| 20150199679 | Palanisamy et al. | Jul 2015 | A1 |
| 20150199689 | Kumnick et al. | Jul 2015 | A1 |
| 20150220917 | Aabye et al. | Aug 2015 | A1 |
| 20150269566 | Gaddam et al. | Sep 2015 | A1 |
| 20150278799 | Palanisamy | Oct 2015 | A1 |
| 20150287037 | Salmon | Oct 2015 | A1 |
| 20150312038 | Palanisamy | Oct 2015 | A1 |
| 20150319158 | Kumnick | Nov 2015 | A1 |
| 20150324769 | Scipioni | Nov 2015 | A1 |
| 20150332262 | Lingappa | Nov 2015 | A1 |
| 20150356560 | Shastry et al. | Dec 2015 | A1 |
| 20150363781 | Badenhorst | Dec 2015 | A1 |
| 20160028550 | Gaddam et al. | Jan 2016 | A1 |
| 20160036790 | Shastry et al. | Feb 2016 | A1 |
| 20160042263 | Gaddam et al. | Feb 2016 | A1 |
| 20160065370 | Le Saint et al. | Mar 2016 | A1 |
| 20160078428 | Moser et al. | Mar 2016 | A1 |
| 20160092696 | Guglani et al. | Mar 2016 | A1 |
| 20160092872 | Prakash et al. | Mar 2016 | A1 |
| 20160092874 | O'Regan | Mar 2016 | A1 |
| 20160103675 | Aabye et al. | Apr 2016 | A1 |
| 20160119296 | Laxminarayanan et al. | Apr 2016 | A1 |
| 20160125405 | Alterman et al. | May 2016 | A1 |
| 20160125521 | Randel | May 2016 | A1 |
| 20160132878 | O'Regan | May 2016 | A1 |
| 20160197725 | Hammad | Jul 2016 | A1 |
| 20160224976 | Basu | Aug 2016 | A1 |
| 20160308995 | Youdale et al. | Oct 2016 | A1 |
| 20170017958 | Scott et al. | Jan 2017 | A1 |
| 20170046696 | Powell et al. | Feb 2017 | A1 |
| 20170091757 | Iloyd et al. | Mar 2017 | A1 |
| 20170103387 | Weber | Apr 2017 | A1 |
| 20170186001 | Reed et al. | Jun 2017 | A1 |
| 20170220818 | Nagasundaram et al. | Aug 2017 | A1 |
| 20170228723 | Taylor | Aug 2017 | A1 |
| 20170295155 | Wong et al. | Oct 2017 | A1 |
| 20170364903 | Lopez | Dec 2017 | A1 |
| Number | Date | Country |
|---|---|---|
| 101099181 | Jan 2008 | CN |
| 2156397 | Feb 2010 | EP |
| 2001035304 | May 2001 | WO |
| 2001035304 | May 2001 | WO |
| 2004042536 | May 2004 | WO |
| 2006113834 | Oct 2006 | WO |
| 2009032523 | Mar 2009 | WO |
| 2010078522 | Jul 2010 | WO |
| 2012068078 | May 2012 | WO |
| 2012098556 | Jul 2012 | WO |
| 2012142370 | Oct 2012 | WO |
| 2012167941 | Dec 2012 | WO |
| 2013048538 | Apr 2013 | WO |
| 2013056104 | Apr 2013 | WO |
| 2013119914 | Aug 2013 | WO |
| 2013179271 | Dec 2013 | WO |
| 2014170667 | Oct 2014 | WO |
| Entry |
|---|
| Petition for Inter Partes Review of U.S. Pat. No. 8,533,860 Challenging Claims 1-30 Under 35 U.S.C. § 312 and 37 C.F.R. § 42.104, filed Feb. 17, 2016, Before the USPTO Patent Trial and Appeal Board, IPR 2016-00600, 65 pages. |
| Wang, U.S. Appl. No. 62/000,288 (unpublished), Payment System Canonical Address Format filed May 19, 2014. |
| Sharma et al., U.S. Appl. No. 62/003,717 (unpublished), Mobile Merchant Application filed May 28, 2014. |
| Kalgi et al., U.S. Appl. No. 62/024,426, (unpublished) Secure Transactions Using Mobile Devices filed Jul. 14, 2014. |
| Prakash et al., U.S. Appl. No. 62/037,033 (unpublished), Sharing Payment Token filed Aug. 13, 2014. |
| Hoverson et al., U.S. Appl. No. 62/038,174 (unpublished), Customized Payment Gateway filed Aug. 15, 2014. |
| Wang, U.S. Appl. No. 62/042,050 (unpublished), Payment Device Authentication and Authorization System filed Aug. 26, 2014. |
| Gaddam et al., U.S. Appl. No. 62/053,736 (unpublished), Completing Transactions Without a User Payment Device filed Sep. 22, 2014. |
| Patterson, U.S. Appl. No. 62/054,346 (unpublished), Mirrored Token Vault filed Sep. 23, 2014. |
| Dimmick, U.S. Appl. No. 14/952,514 (unpublished), Systems Communications With Non-Sensitive Identifiers filed Nov. 25, 2015. |
| Dimmick, U.S. Appl. No. 14/952,444 (unpublished), Tokenization Request Via Access Device filed Nov. 25, 2015. |
| Prakash et al., U.S. Appl. No. 14/955,716 (unpublished), Provisioning Platform for Machine-To-Machine Devices filed Dec. 1, 2015. |
| Wong et al., U.S. Appl. No. 14/966,948 (unpublished), Automated Access Data Provisioning filed Dec. 11, 2015. |
| Stubbs et al., U.S. Appl. No. 62/103,522 (unpublished), Methods and Systems for Wallet Provider Provisioning filed Jan. 14, 2015. |
| McGuire, U.S. Appl. No. 14/600,523 (unpublished), Secure Payment Processing Using Authorization Request filed Jan. 20, 2015. |
| Flurscheim et al., U.S. Appl. No. 15/004,705 (unpublished), Cloud-Based Transactions With Magnetic Secure Transmission filed Jan. 22, 2016. |
| Flurscheim et al., U.S. Appl. No. 62/108,403 (unpublished), Wearables With NFC HCE filed Jan. 27, 2015. |
| Sabba et al., U.S. Appl. No. 15/011,366 (unpublished), Token Check Offline filed Jan. 29, 2016. |
| Patterson, U.S. Appl. No. 15/019,157 (unpublished), Token Processing Utilizing Multiple Authorizations filed Feb. 9, 2016. |
| Cash et al., U.S. Appl. No. 15/041,495 (unpublished), Peer Forward Authorization of Digital Requests filed Feb. 11, 2016. |
| Le Saint et al., U.S. Appl. No. 15/008,388 (unpublished), Methods for Secure Credential Provisioning filed Jan. 27, 2016. |
| Kinagi, U.S. Appl. No. 62/117,291 (unpublished), Token and Cryptogram Using Transaction Specific Information filed Feb. 17, 2015. |
| Galland et al. U.S. Appl. No. 62/128,709 (unpublished), Tokenizing Transaction Amounts filed Mar. 5, 2015. |
| Rangarajan et al., U.S. Appl. No. 61/751,763 (unpublished), Payments Bridge filed Jan. 11, 2013. |
| Li, U.S. Appl. No. 61/894,749 (unpublished), Methods and Systems for Authentication and Issuance of Tokens in a Secure Environment filed Oct. 23, 2013. |
| Aissi et al., U.S. Appl. No. 61/738,832 (unpublished), Management of Sensitive Data filed Dec. 18, 2012. |
| Wong et al., U.S. Appl. No. 61/879,362 (unpublished), Systems and Methods for Managing Mobile Cardholder Verification Methods filed Sep. 18, 2013. |
| Powell, U.S. Appl. No. 61/892,407 (unpublished), Issuer Over-The-Air Update Method and System filed Oct. 17, 2013. |
| Powell, U.S. Appl. No. No. 61/926,236 (unpublished), Methods and Systems for Provisioning Mobile Devices With Payment Credentials and Payment Token Identifiers filed Jan. 10, 2014. |
| Application No. CN201680060089.8 , Office Action, dated Sep. 1, 2020, 15 pages. |
| International Search Report dated Jan. 23, 2017, PCT Application No. PCT/US2016/057400, filed Oct. 17, 2016 (11 pages). |
| Singapore Application No. 11201801685, Examination Report dated May 27, 2020, 5 pages. |
| Chipman, et al., U.S. Appl. No. 15/265,282 (Unpublished), Self-Cleaning Token Vault, filed Sep. 14, 2016. |
| Lopez, et al., U.S. Appl. No. 15/462,658 (Unpublished), Replacing Token on a Multi-Token User Device, filed Mar. 17, 2017. |
| Kaja, et al., U.S. Appl. No. 15/585,077 (Unpublished), System and Method Using Interaction Token, filed May 2, 2017. |
| Number | Date | Country | |
|---|---|---|---|
| 20170109745 A1 | Apr 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62242068 | Oct 2015 | US | |
| 62242074 | Oct 2015 | US |
