Systems and methods for processing dormant virtual access devices

Information

  • Patent Grant
  • 10568016
  • Patent Number
    10,568,016
  • Date Filed
    Thursday, May 10, 2018
    6 years ago
  • Date Issued
    Tuesday, February 18, 2020
    4 years ago
Abstract
Embodiments of the invention are directed to ceasing the renewal of a virtual access device that is dormant. Some embodiments may receive a dormancy request from an authorization server, where the dormancy request includes information identifying a virtual access device. Embodiments may determine that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule. Certain embodiments may send a dormancy response to the authorization server indicating that the virtual access device is dormant. An authorization server may determine not to renew a virtual access device based at least upon the dormancy response. As such, the authorization server need not provision a mobile device with an updated virtual access device.
Description
BACKGROUND

Mobile phones can utilize access data to obtain access to a resource or a location. For example, a mobile phone may include data which is passed to an access device to allow the user of the mobile phone to access a room in a building. In another example, the mobile phone may have access data such as account data which may allow the user of the mobile phone to access an account to obtain a good.


In many cases, a resource provider may provide a consumer with access data that can be embedded on a physical access device, such as a physical card, a physical key, or a physical RFID tag. In some instances, the resource provider may also provision the mobile phone with the access data. For example, a building operator system or a transit system may provision a mobile phone with data that allows a user of the mobile phone to access a building or access a turnstile. In another example, a bank may provision the mobile phone with access data that allows the user of the mobile phone to access an account at the bank.


In instances where the mobile phone may be provisioned with the access data, a user can choose to have a mobile application and a virtual access device (e.g., a virtual payment device) provisioned onto the mobile device. Typically, the virtual access device is associated with a physical access device. In some instances, when the physical access device is renewed, any corresponding virtual access devices may also need to be renewed in order to remain usable.


This routine of renewing virtual access credentials for mobile devices whenever corresponding physical access devices are renewed poses several problems. For example, if the user has deleted the mobile application or has switched to a different mobile device, renewing the virtual access device may fail. A provisioning system may retry provisioning the renewed virtual access device several times before aborting. This can cause ineffective use of limited processing power. If virtual access devices are renewed in batch, this effect can compound to cause a significant load and potentially system failure. The systems of the resource providers can crash due to peak load during which too many renewal requests have failed and entered into a systematic retry process (e.g., due to users changing phones).


Without addressing these dormant access devices, the system (e.g., an issuer) may become overloaded from processing an overwhelmingly large number of re-provisioning attempts. There is a need to reduce the number of unnecessary renewals to minimize system overloading and to minimize delays on renewing those virtual access devices that need to be renewed.


Embodiments of the present invention are directed to methods and systems of minimizing system overload and infrastructure failures. Embodiments of the invention address this and other problems, individually and collectively.


BRIEF SUMMARY

Embodiments of the invention are directed to methods and systems that improve hardware resource usage and allocation by minimizing unnecessary reprovisioning attempts of dormant virtual access devices on user mobile devices.


Some embodiments provide techniques for identifying dormant virtual access devices (e.g., dormant virtual payment cards) that need not be renewed to minimize failed renewal requests. In some embodiments, a server may receive a dormancy request from an issuer server where the dormancy request includes information identifying a virtual payment device. The server may determine that the virtual payment device is dormant based on previous transactions involving the virtual payment device and at least one dormancy rule. In certain embodiments, the server may send a dormancy response to the issuer server indicating that the virtual payment device is dormant. From the dormancy response, the issuer server may determine to close the dormant virtual payment device instead of making attempts to provision a renewed virtual payment device on a user mobile device.


Identifying dormant virtual payment devices that need not be renewed can minimize failed provisioning attempts, as the user may have changed phones or deleted the mobile application, etc. Embodiments need not waste hardware resources to make unnecessary provisioning and reprovisioning attempts. Further, as there have been wide instances of issuers crashing due to peak load during which too many renewal requests have failed and entered into a systematic retry process, eliminating the need to send large numbers of renewal requests to various user mobile devices may dramatically reduce the processing load on the payment processor and issuer servers.


One embodiment of the invention is directed to a method of receiving, by a server computer, a dormancy request from an issuer computer, the dormancy request including information identifying a virtual payment device. The server computer may then determine that that the virtual payment device is dormant based on previous transactions involving the virtual payment device and at least one dormancy rule. The server computer may then send a dormancy response to the issuer computer indicating the that virtual payment device is dormant.


Further details regarding embodiments of the invention can be found in the Detailed Description and the Figures.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 illustrates a simplified block diagram of an example computing environment 100 in accordance with certain embodiments of the invention.



FIG. 2 shows an example system involving a virtual payment card that may be dormant in accordance with certain embodiments of the invention.



FIG. 3 shows an example payment device lifecycle, according to embodiments of the invention.



FIG. 4 illustrates an example process flow for renewing a virtual access device in accordance with certain embodiments of the invention.



FIG. 5 shows a flow chart for determining whether to renew a virtual access device and re-provision a user's mobile device in accordance with some embodiments of the invention.



FIG. 6 shows a flow chart for determining whether a virtual access device is dormant in accordance with certain embodiments of the invention.



FIG. 7 shows a block diagram of a computer apparatus.





DETAILED DESCRIPTION

In the past few years, mobile wallets have been gaining popularity. Wallet providers enable users to use virtual cards at access points by provisioning virtual cards onto the users' devices. Users may download a mobile application that allow users to install one or more cards onto the mobile application. The users may then make a payment at certain point of sale (POS) locations by pulling up a virtual card installed on the user's mobile device. In some instances, the user may gain access at an entry point by interfacing a virtual card installed on the user's mobile device with a reader at the entry point.


Similar to physical cards, virtual cards are renewed periodically to minimize the risk of fraud. In some instances where a virtual card has previously been provisioned onto the mobile device, the user may no longer be using the virtual card. The user may not be using the virtual card for many reasons, including a switch in mobile devices, having deleted the application, etc. As the issuers attempt to re-provision renewed virtual cards onto user devices that for example no longer exist or no longer have the mobile wallet application can cause system overload. The massive number of renewal requests can cause the infrastructure sending those requests to get into an enormous loop that cannot be handled at the peak performance load.


Embodiments of the invention can provide techniques for minimizing auto-renewal of a dormant virtual card if the renewal is unneeded. By identifying those dormant virtual cards that need not be auto-renewed, embodiments can minimize failed provisioning attempts and loads on provisioning servers. In some embodiments, dormant virtual cards can be identified by monitoring the activity level of a virtual card provisioned on a mobile device. Some embodiments may determine that renewal of a dormant virtual card is not needed when it is unlikely that the user will use the virtual card. Certain embodiments may then close the virtual card or re-engage customers by sending offers, etc.


In some embodiments, a dormant virtual card need not be renewed because, for example, the user may have changed phones where the virtual card provisioned on the previous phone has not been reprovisioned on the current phone, the user may have deleted an application from which the user could access and use the virtual payment device, and that the user is not transacting with the virtual payment device. By identifying these dormant virtual cards, some embodiments need not waste the resources to make unnecessary provisioning attempts for a renewed virtual device when it is unlikely that the user will use the renewed virtual device. Further, by identifying these devices in large numbers and eliminating the need to send large numbers of renewal requests, some embodiments may minimize the load and overhead processing failures at the issuer's processing devices.


Prior to discussing specific embodiments of the invention, some terms may be described in detail.


As used herein, a “mobile device” may comprise any electronic device that may be transported and operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g. 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, personal music players, hand-held specialized readers, wearable devices (e.g., watches), vehicles (e.g., cars), etc. A mobile device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device—i.e., using the other device as a relay—both devices taken together may be considered a single mobile device).


The term “server computer” may include a powerful computer or 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. Other examples of the server computer may include an application server, a file server, a mail server, a print server, a gaming server, etc. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. In some contexts, the server computer can refer to an application that executes and operates as a server according to a client-server protocol. In certain contexts, the server computer may refer to computing hardware that can or does execute a server application.


A “provisioning server computer” may include any suitable computer that can provision access data to a device.


“Access data” may include any suitable data that can be used to access a resource or create data that can access a resource. In some embodiments, access data may be account information for a payment account. Account information may include a PAN, payment token, expiration date, verification values (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data may be data that can be used to activate account data. For example, in some cases, account information may be stored on a mobile device, but may not be activated until specific information is received by the mobile device. This specific information may be characterized as access information in some embodiments. In other embodiments, access data could include data that can be used to access a location. Such information may be ticket information for an event, data to access a building, transit ticket information, etc. Access data can be part of a physical access device or a virtual access device.


A “physical access device” may be a physical device for enabling access to goods or services. The physical access device may be a hardware object or a physical object. As examples of physical objects, the access device may comprise a substrate such as a paper or plastic card, and information that is printed, embossed, encoded, or otherwise included at or near a surface of an object. A hardware object can relate to circuitry (e.g., permanent voltage values). An example of a physical access device is a physical payment device such as a physical credit card, an RFID tag, etc. A physical payment device may be used to make a payment transaction and may be associated with a value such as a monetary value, a discount, or store credit. A physical payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or a person. Another example of a physical access device is a physical pass such as a bus pass, a ticket, a transit card, or any other types of device that allows a user to gain access to an establishment, a location, an event, or a service. In some instances, a physical access device may include access data or a token that allows a user to obtain access to a building, a location, goods, and/or services.


A “virtual access device” may be a virtual device for enabling access to goods or services. The virtual access device may be a software object (e.g., access data). A software object can relate to non-permanent data stored on a device such as a mobile phone, a tablet, etc. An example of a virtual access device is a virtual payment device. A virtual payment device may be associated with a value such as a monetary value, a discount, or store credit, and a virtual payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or a person. A virtual payment device may be used to conduct a payment transaction, e.g., via a payment reader at a POS. In another example, a virtual payment device can include a tokenized version of a physical payment card's payment credentials. Another example of a virtual access device is a virtual pass such as credit, credentials, or other types of digital data (e.g., e-ticket) that can be stored on a device such as a mobile phone. The virtual pass may be used to enable a user to gain access to an establishment, a location, an event, or a service. A virtual access device may be associated with a physical access device. For example, a virtual payment device can include the same payment credentials (e.g., primary account number, expiration date, CVV) as a physical payment device. There can be a physical access device that corresponds to the virtual access device where both devise have similar or the same credentials. Both devices may be used by a user to obtain access to a location, a building, an event, a service, etc. In some instances, a virtual access device may refer to access data or a token that allows a user to obtain access to a building, a location, goods, and/or services.


An “application” may be a computer program that is used for a specific purpose.


An “access point device” may be any suitable device for obtaining access to a resource. An access point device may generally be located in any suitable location, such as at the location of a merchant. An access point device may be in any suitable form. Some examples of access point devices include POS devices, 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, Websites, and the like. An access point device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, an access device (e.g., physical or virtual access device) and/or a user mobile device. In some embodiments, where an access point device may comprise a POS terminal, any suitable POS terminal may be used and may 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 portable communication device.


An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user that is associated with a portable communication device such as an account enrolled in a mobile application installed on a portable communication device. An issuer may also issue account parameters associated with the account to a portable communication device. An issuer may be associated with a host system that performs some or all of the functions of the issuer on behalf of the issuer.


A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.


An “acquirer” may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers.


A “transaction processing network” may include a network that can process and route transaction request messages. An exemplary transaction processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, may include a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. There can be transaction processing networks for a payment organization, a transit authority, a building system, a ticketing system, etc.


An “authorization request message” may be an electronic message that is a request to authorize a transaction. In some embodiments, it 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 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 dCW (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. In some embodiments, it is 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 refer to a substitute identifier for some information. For example, a transaction token may include an identifier for a transaction 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 transaction 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 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. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.


A “token service provider” may refer to an entity including one or more server computers in a token service system that generates, processes, and maintains tokens. The token service provider may include or be in communication with a token vault where the generated tokens are stored. Specifically, the token vault may maintain one-to-one mapping between a token and the data (e.g., a real account identifier) represented by the token. A token service provider may provide reports or data output to reporting tools regarding approved, pending, or declined token requests, including any assigned token requestor identifiers (IDs). The token service provider may provide data output related to token-based transactions to reporting tools and applications and present the token and/or the data substituted by the token (e.g., real account identifiers) as appropriate in the reporting output. An example of a token service provider is Visa Token Service. A token service provider can be operated by a transaction processing network, an issuer, or other entities.


A “processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).


A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.


Various embodiments will now be discussed in greater detail with reference to the accompanying figures, beginning with FIG. 1.


I. Example Computing Environment



FIG. 1 illustrates a simplified block diagram of an example computing environment 100 in accordance with certain embodiments of the invention. As shown, computing environment 100 includes a virtual device processing system 110 communicatively coupled to a mobile device 105 via a communication network 115. The embodiment depicted in FIG. 1 is merely an example and is not intended to unduly limit the claimed embodiments of the present invention. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. For example, certain components of virtual device processing system 110 such as a dormancy determiner 105 can be part of mobile device 105 or can be running on one or more servers.


The various subsystems depicted in FIG. 1 may be implemented in software, in hardware, or in combinations thereof. In some embodiments, the software may be stored on a transitory or non-transitory computer-readable medium and/or be executed by one or more processors. It should be appreciated that system 110 may include other components than those depicted in FIG. 1. For example, system 110 may have more or fewer components than those shown in FIG. 1, may combine two or more components, or may have a different configuration or arrangement of components. In some embodiments, system 110 may be part of a number of servers.


Mobile device 105 may be of various different types, including, but not limited to a portable or handheld device such as a laptop, a mobile phone, a tablet, etc., and other types of devices. The mobile device 105 may comprise a mobile application 145 with a virtual access device 150. In some embodiments, mobile device 105 can enable a user to gain access to a location or obtain authorization for a payment transaction. The user can use virtual access device 150 on mobile device 105 at a point of sale (POS) to make purchases for goods or services. In some instances, the user may also use virtual access device 150 on mobile device 105 at an access point (e.g., a building entrance, a movie theatre entrance, a ticketing station, a subway turnstile, an electronic reader at a bus station, etc.) to gain access to a location.


Communication network 115 facilitates communications between one or more client devices such as mobile device 105 and virtual device processing system 110. Communication network 115 can be of various types and can include one or more communication networks or infrastructure. For example, communication network 115 can include, without restriction, the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet network, a public or private network, a wired network, a wireless network, and the like, and combinations thereof. Different communication protocols may be used to facilitate the communications including both wired and wireless protocols such as IEEE 802.11 suite of protocols, TCP/IP, IPX, SAN, AppleTalk, Bluetooth, and other protocols.


In certain embodiments, virtual device processing system 110 includes multiple subsystems including a dormancy determiner (also referred to as dormancy determination server) 120, a dormant device processor 125, a virtual device provisioner 130, a dormancy notifier 135, and an ad manager 140. One or more communication paths may be provided that enable the one or more subsystems to communicate with and exchange data with one another.


In some embodiments, dormancy determiner 120 can be part of a token service provider and can determine whether an access device such as a virtual payment card (e.g., a token) is dormant or not. Some embodiments may determine that an access device is dormant when the access device is not being used and has been in a dormant state. For instance, a physical access card (e.g., a bus pass, a subway card) may be determined to be dormant when there have been no transactions conducted using the access card for more than a threshold period of time (e.g., 30 days, 60 days, 90 days). In another instance, a virtual payment card (e.g., a credit/debit card) may be determined to be dormant when the user has not conducted any payment transactions using the virtual payment card, despite having used the physical payment card within a threshold period of time. In some instances, a virtual payment card may not have been used by a user for various reasons, such as the user having changed phones where the virtual payment card was provisioned on the previous phone and not on the new phone, the user having deleted the application that previously stored the virtual payment card, etc.


In some embodiments, dormancy determiner 120 may determine that the access device is dormant by accessing data storage (e.g., a database) that stores transaction data associated with the access device. Dormancy determiner 120 may determine that the access device is dormant if the last transaction was from before a threshold time interval or if there was never any transactions shown in the transaction data.


Different systems may define dormancy of an access device differently. There may be a set of dormancy rules that can be implemented to define the dormancy of an access device. In one instance, the dormancy rule may be that an access device is dormant if there have been no transaction conducted using the access device for more than 6 months. In another instance, a dormancy rule may specify that a virtual access device is dormant when a previous transaction occurred more than a threshold time period ago. In yet another instance, a dormancy rule may be that an access device is dormant if the user is no longer using the same mobile device onto which the access device was previously provisioned. Certain embodiments may obtain this type of information from an electronic wallet provider or a mobile device provider.


Some embodiments may determine that an access device is dormant when the access device satisfies multiple dormancy rules. The system administrators may select the dormancy rules to apply to the access devices in determining whether an access device is dormant. Some embodiments may have different set of dormancy rules that apply to different types of access devices (e.g., payment card versus building access card) when a determination is made as to whether an access device is dormant.


Some embodiments may determine that an access device is dormant when the credentials associated with the access device has not been used in a transaction within a certain period of time (e.g., 30 days, 60 days, 90 days). In certain embodiments, dormancy determiner 105 can access and monitor transaction data for a number of credentials and determine whether a particular set of credentials have been used in any type of transaction (e.g., purchasing goods or services, accessing a venue).


In some embodiments, dormancy determiner 120 can be implemented by one or more servers in a payment processing network. The one or more servers can access transaction history associated with a virtual payment card and one or more dormancy rules to make a determination as to whether the virtual payment card is dormant. In some embodiments, the one or more servers can determine that the virtual payment card is dormant upon determining that there has been inactivity by the virtual payment card for more than a year. Dormancy determiner 120 may also be implemented by one or more servers of an issuer bank, a transit network (e.g., for a subway system, for a bus system), an access network (e.g., for a building or any type of location) or any other entity that may provision or no longer provision a user's mobile device with a virtual access device.


In certain embodiments, a virtual device provisioner 130 can be configured to provision a computing device (e.g., a mobile device 105) with access data such as virtual access device 150. Provisioner 130 can be one or more provisioning server computers and can include a processor and a computer readable medium comprising code which causes the processor to perform any suitable method associated with provisioning the computing device with access data. Provisioner 130 may maintain a database of addresses (e.g., an IP or internet protocol address or phone number) for various mobile devices that can be provisioned with access data and also maintain a database of access data to be provisioned. The access data to be provisioned may have been previously obtained by an issuer operating an authorization computer system and/or a payment processor operating a validation entity computer.


By provisioning the computing device with the access device (i.e., provisioning the computing device with access data), the computing device can have a copy of credentials associated with the access device and can use the credentials to perform an access transaction. For instance, a mobile device that is provisioned with access data can allow a user to access an account to pay for a good or service at a merchant. In another instance, a mobile device that is provisioned with access data can be used to give the user access to a location such as a building. In this instance, the mobile device can interact with an access point device (not shown) and pass access data to the access point device. The access point device may locally verify the received access data or it may communicate with a remotely located authentication server computer (not shown). The remotely located authentication server computer may verify that the access data is authentic and may transmit a signal indicating this back to the access point device. The access point device may then proceed to let the user enter the building.


In some embodiments, provisioner 130 may be one or more servers of an issuer bank. In certain embodiments, provisioner 130 may be one or more servers of an entity that issues access devices, such as a transit operator, a building operator, a payment card issuer, etc. An example of provisioner 130 is provisioning server computer 270 described in FIG. 2. One of ordinary skill in the art would know that there are various methods in provisioning a set of credentials and/or any other identifying information (e.g., a device ID) associated with an access device onto a mobile device such as a smartphone.


In certain embodiments, dormant device processor 125 can determine how to process the access device upon receiving the information as to whether the virtual access device is dormant. Dormant device processor 125 can use the information on whether an access device is dormant and other types of information (e.g., whether the mobile device onto which the access device was provisioned is no longer being used by the user) to make a determination as to what to do with the virtual access device. In some embodiments, upon determining that a virtual payment card is dormant, dormant device processor 125 can determine not to renew the virtual payment card and not to re-provision a renewed virtual payment card onto a mobile device. In certain embodiments, dormant device processor 125 may determine to close an old virtual payment card and email the customer a notification. In some embodiments, dormant device processor 125 can instruct notifier 135 to send a notification to the subscriber of the virtual payment card to notify the subscriber that the virtual payment card will be closed due to inactivity.


In some embodiments, dormant device processor 125 can be one or more servers that are part of an access device network (e.g., a payment processing network) or an access device issuer (e.g., an issuer bank). Dormant device processor 125 can receive information from other entities such as an electronic wallet provider or mobile device provider and determine whether the user has been using other payment devices also provisioned and stored on the same mobile device. Upon determining that the user has been using other payment devices via the mobile device, dormant device processor 125 may determine to re-provision an updated or renewed version of the dormant virtual card. In certain embodiments, dormant device processor 125 may determine not to re-provision the dormant virtual card upon determining that the user has not used the virtual card beyond a threshold period of time while the user has continued to use the other virtual cards.


In some embodiments, dormancy notifier 135 can send out one or more notifications to an access device holder. In some embodiments, dormant device processor 125 may determine to close an account associated with a virtual access device e.g., upon determining that the virtual access device is dormant. Dormant device processor 125 may request dormancy notifier 135 to send out a notification to the dormant device holder informing the device holder closure of the account. In some embodiments, notifier 135 can send a card owner a message indicating that the card will be closed within a certain number of days. In certain embodiments, notifier 135 can also send a message to the owner requesting confirmation of card renewal. In some embodiments, notifier 135 can be part of one or more servers of an access device issuer, such as a payment card issuer bank.


In certain embodiments, ad manager 140 can send one or more advertisements to a mobile device to incentivize the user to use a virtual access device. In some embodiments, upon determining that a virtual access device is dormant, dormant device processor 125 may cause ad manager 140 to select or generate an ad that gives the user a benefit (e.g., a percentage of cash back, a free gift card, a discount or coupon for one or more merchants) in exchange for the user using the virtual access device. Some embodiments may provide tailored ads to a user based on the user's preferences, historical activities, etc. in determining an effective ad to encourage the user to use the virtual access device.


Further, ad manager 140 in some embodiments can send incentives to a mobile device to encourage the user to request renewal of a virtual payment device. Ad manager 140 can also provide promotional offers and other incentives to the consumer during such engagements to promote usage. As such, consumer engagement with the issuer may be increased.


Systems depicted in some of the figures may be provided in various configurations. In some embodiments, the systems may be configured as a distributed system where one or more components of the system are distributed across one or more networks in one or more cloud infrastructure systems.


II. Example System



FIG. 2 shows an example system 200 involving a virtual payment card that may be dormant in accordance with certain embodiments of the invention. System 200 comprises a mobile device 220 and a physical payment device 215 which both may be associated with a consumer 210. The mobile device 220 may comprise a mobile application 225 with a virtual payment device 227. The consumer 210 may be able to use the physical payment device 215 and/or the virtual payment device 227 for purchases at a merchant. The system 200 may further comprise a merchant computer 230, an acquirer computer 240, a payment processing network (also referred to as transaction processing network or transaction processing computer(s)) 250, and an issuer computer (also referred to as authorization computer) 260, all of which may all be in direct or indirect communication with one another. The system 200 may also comprise a provisioning server computer 270, which may be in communication with the mobile device 220, the issuer computer 260, and any other suitable entity. The system 200 may also include a digital wallet server computer 280.


The physical payment device 215 may store payment credentials associated with the consumer 210. For example, the physical payment device 215 may store a PAN (primary account number) or a token, as well as personal information such as a name, address, email address, phone number, or any other suitable consumer 210 identification information. The physical payment device 215 may provide the payment credentials to the merchant computer 230 or a merchant access device during a transaction (e.g., via magnetic stripe, NFC, etc.).


The virtual payment device 227 may also include payment credentials associated with the consumer 210. For example, the virtual payment device 227 may include a PAN or a token, as well as personal information such as a name, address, email address, phone number, or any other suitable consumer 210 identification information. The virtual payment device 227 may be associated with the physical payment device 215. For example, the virtual payment device 227 may include the same PAN as the physical payment device 215, or the virtual payment device 227 may include a token based on the PAN of the physical payment device 215.


The mobile device 220 may be able to provide the payment credentials of the virtual payment device 227 to the merchant computer 230 or a merchant access device during a transaction (e.g., via NFC or other short range communication). For example, the mobile device 220 may execute the mobile application 225, and the mobile application 225 may utilize communication capabilities of the mobile device 220 for providing the payment credentials.


The merchant (which may operate the merchant computer 230) may engage in transactions, sell goods or services, or provide access to goods or services to the consumer 210.


The acquirer computer 240 may be associated with the merchant computer 230, and may manage authorization requests on behalf of merchant 230. The acquirer 240 may forward an authorization request from the merchant 230 to the payment processing network 250.


The payment processing network 250 may be disposed between the acquirer computer 240 and the issuer computer 260. The payment processing network 250 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the payment processing network 250 may comprise a server computer, coupled to a network interface (e.g. by an external communication interface), and a database(s) of information. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The payment processing network 250 may use any suitable wired or wireless network, including the Internet.


The payment processing network 250 may also be able to analyze the usage of a given payment device. For example, the payment processing network 250 may be able to determine whether a given virtual payment device is dormant or being actively used. In some embodiments, payment processing network 250 may make the dormancy determination by accessing and monitoring payment transactions performed by a given payment device.


Certain embodiments may determine that a given virtual payment device is dormant when payment processing network 250 does not observe any transactions performed by the virtual payment device within a threshold time interval (e.g., 60 days, a year, 2 years, 5 years). Some embodiments may determine that the virtual payment device when there have not been any activity associated with the virtual payment device. For instance, the virtual payment device may be determined to be dormant if the user has not accessed the virtual payment device's online profile to view the account for more than a threshold period of time.


In some embodiments, payment processing network 250 may be able to obtain additional data related to a mobile device onto which a given virtual payment device is provisioned. For instance, payment processing network 250 may determine whether the mobile device is still operational and being used by the same user by sending a request to the mobile device providers, cellular network service providers, internet service providers, etc. In another instance, payment processing network 250 may determine whether the mobile application where the virtual payment device is saved is still operational and being used by the same user. Some embodiments may send a request to an electronic wallet provider to determine whether the user is using one or more other virtual payment cards. Certain embodiments may receive an indication that other virtual payment cards are still being used by the user. In some such embodiments, payment processing network 250 (or issuer computer 260) may still determine that the virtual payment device should be renewed, despite the dormancy of the given virtual payment device.


The issuer computer 260 may issue a payment account and an associated payment device 215 (e.g., a physical plastic payment card, a payment tag) to the consumer 210. The issuer computer 260 may also issue a virtual payment device 227 for the consumer's mobile device 220. The issuer computer 260 may renew the payment device 215 and/or the virtual payment device 227 when appropriate. The issuer computer 260 may also process authorization requests received from the merchant 230.


In some embodiments, the issuer computer 260 may not be able to determine whether the virtual payment device 227 is being utilized. For example, incoming authorization request messages may contain the same payment credential information, regardless of whether the physical payment device 215 or virtual payment device 227 was used for the transaction. Some embodiments may determine that the virtual payment device 227 is being used in a payment transaction instead of the physical payment device 215 by requesting transaction information from payment processing network 250.


In some embodiments, transactions conducted by a virtual payment device 227 can be differentiated by transaction conducted by a physical payment device 215 via a variety of methods. For instance, payment processing network 250 may notate the transactions conducted by a virtual payment device differently compared to transactions conducted by a physical payment device (e.g., by marking next to each transaction whether the transaction was made by the virtual payment device). Further, the virtual payment device may have a different PAN, CVV, or other types of identifiers (e.g., identification numbers) that can differentiate its payment transactions against those transactions made by the counterpart physical payment device.


The provisioning computer 270 may be able to provision the virtual payment device 227 to the mobile device 220. The provisioning computer 270 may be associated with the issuer computer 260, the payment processing computer 250, or any other suitable entity. In some embodiments, upon determining that virtual payment device 227 is dormant (and in some instances, that mobile device 220 is also dormant), issuer computer 260 (or payment processing computer 250) may determine not to renew the virtual payment device 227. As such, provisioning computer 270 need not re-provision an updated or renewed virtual payment device to the mobile device 220. This can minimize any failed provisioning attempts and potential re-provisioning loops that could cause an overload on the processing bandwidth.


As described, in some embodiments, issuer may determine to not renew certain virtual payment cards upon determining that the virtual payment card and/or the mobile device are dormant. Upon determining that the virtual payment card is not dormant, the issuer may proceed to provision a renewed virtual payment card onto the user's mobile device. Some embodiments may make the determination as to whether to cancel the auto-renewal of a virtual payment card by requesting additional data from digital wallet server computer 280.


The digital wallet server computer 280 may be configured to maintain a digital wallet associated with the user of the mobile device 220 as well as other users. A “digital wallet” can store user profile information, payment information (e.g. PANs or primary account numbers, payment tokens (i.e., PAN substitutes), verification values such as CVVs, etc.), bank account information, and/or the like and can be used in a variety of transactions, such as but not limited to eCommerce, social networks, money transfer/personal payments, mobile commerce, proximity payments, gaming, and/or the like for retail purchases, digital goods purchases, utility payments, purchasing games or gaming credits from gaming websites, transferring funds between users, and/or the like.


In some embodiments, transaction processing network 250 or authorization computer 260 may send a request to digital wallet server computer 280 to determine whether a user's various other access devices (e.g., credit/debit card, transit pass) are dormant. Transaction processing computer(s) 250 and/or authorization computer 260 may then make a determination as to whether to renew a virtual access device based on the received response, in addition to the dormancy of the virtual access device.


In some embodiments, instead of inquiring the payment processing network regarding the dormancy of a particular virtual access device, embodiments may simply send a request to digital wallet server computer 280 to determine whether a particular virtual access device (or in some instances other virtual access devices and/or a mobile application being provided by digital wallet server computer 280) has activity. Upon determining that the user has performed one or more transactions using the particular virtual access device (or one or more of the other virtual access devices and/or the mobile application), an issuer computer 260 may determine to renew the particular virtual access device.


Some embodiments may mark the virtual access device as do not renew upon receiving a response from digital wallet server computer 280 that the particular virtual access device has not been active (e.g., user has not performed any transactions using the virtual access device, user has not interacted with the virtual access device by adding credit to it or by changing a profile associated with the virtual access device). Certain embodiments may determine to cease to renew the particular virtual access device upon determining that not only is the particular virtual access device inactive, but there has also not been any user activity associated with the mobile application provided by the digital wallet service (e.g., user has not interacted with other virtual access devices accessible via the mobile application, user has not interacted with a user profile created using the mobile application).


Each of the entities in FIG. 2 may communicate through any suitable communication channel or communications network. A suitable communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like.


III. Example Life Cycle of an Access Device


Access device such as payment cards have expiration dates to help protect against fraud. The expiration dates allow merchants and issuers to validate that a card is open and valid (e.g., through real-time authorization). That is, expiration dates may serve as an additional mechanism than the card number for authorizing a transaction. It is important for these access devices to be renewed every so often so that the expiration dates may be updated.



FIG. 3 shows an example payment device lifecycle 300 according to embodiments of the invention. Typically, a physical payment device will have an expiration date. When the physical payment device expires, an issuer computer may automatically renew (or reissue) a new physical payment device, optionally with the same payment credentials or new payment credentials. This is one example of a natural renewal or reissue process.


There are also forced renewal processes, where the physical payment device may be renewed before the expiration date. For example, as shown in FIG. 3, the consumer may report that the physical payment device was lost or stolen, or the consumer may report that a physical payment device was fraudulently used. A consumer can report these events by telephone, via a mobile application (e.g., that uses a token service provider such as Visa Token Services), or via any other suitable means of communication. In these situations, the issuer computer may immediately renew the physical payment device (e.g., by mailing a new physical payment device to the consumer), and the new physical payment device may have new payment credentials.


In some instances, the issuer computer may not renew the physical payment device. Instead, as shown in FIG. 3, the issuer computer may close the physical payment device and/or associated payment account, or the issuer computer may leave the physical payment device in its current state.


These payment device lifecycle events can also apply to virtual payment devices. For example, a virtual payment device may be associated with a physical payment device, and it may be necessary to renew the virtual payment device when the physical payment device is being renewed (e.g., the original virtual payment device may become inoperative when the physical payment device is renewed). However, it may be inefficient to automatically renew a virtual payment device whenever the corresponding physical payment device is renewed, as the consumer may have switched to a different mobile device, deleted or stopped using the mobile application, or otherwise stopped using the virtual payment device. The following description provides a process for determining whether to renew a virtual payment device based on dormancy, consumer preference, and any other suitable information, such that virtual payment devices can be selectively renewed.


IV. Example Process for Renewing and Re-provisioning a Virtual Access Device



FIG. 4 illustrates an example process flow 400 for renewing a virtual access device in accordance with certain embodiments of the invention. In some embodiments, an issuer computer (e.g., issuer computer 260) may renew a physical access device such as physical payment device 215. In certain embodiments, renewing the physical payment device 215 may trigger the issuer computer 260 to evaluate the best way to proceed with respect to the virtual payment device 227 provisioned on mobile device 220.


At step S410, the issuer computer 260 may renew the physical payment device 215, and the issuer computer 260 may identify an associated virtual payment device 227. In some embodiments, a physical payment device is not required. Some embodiments may only have virtual access devices provisioned on a mobile device. As such, a trigger to determine whether the virtual access device need to be renewed can be an expiration date associated with the virtual access device. In some embodiments, the trigger may be a renewal date that occurs periodically (e.g., every year since the opening date of the virtual access device, every other year, every 5 years, etc.).


At step S412, the issuer computer 260 may send an activity request message to the payment processing network 250. The request may include information about the virtual payment device 227, the consumer 210, the mobile device 220, and any other suitable information. In some embodiments, the information about the virtual payment device 227 can include a PAN, a CVV, a pin number, an expiration date, any other type of identifier, or a combination of the above.


At step S414, the payment processing network 250 may determine whether the virtual payment device 227 is being actively utilized or whether the virtual payment device 227 is dormant. The payment processing network 250 may be able to identify previous transactions that involved the virtual payment device 227. The payment processing network 250 may determine how recently the virtual payment device 227 was used and how frequently the virtual payment device 227 is used.


In some embodiments, the payment processing network 250 may determine whether the virtual payment device 227 is dormant or active based on a number of factors. For example, the virtual payment device 227 may be considered dormant if the virtual payment device 227 has not been used within the last week, month, ninety days, six months, a year, or any other suitable amount of time. In another example, the virtual payment device 227 may be considered dormant if it is used less than any suitable frequency, such as once a month. The date on which the virtual payment device 227 was initially added, and the most recent date when the virtual payment device 227 was serviced (e.g., renewed) can also be considered when determining dormancy. One of ordinary skill in the art would recognize that dormancy can be identified in a number of other ways. Rules for determining dormancy can be set by the payment processing network 250, issuer computer 260, or any other suitable entity.


At step S416, the payment processing network 250 may send an activity response message back to the issuer computer 260, the message indicating whether the virtual payment device 227 is active or dormant. In some embodiments, the response message may also include information such as how long the virtual payment device 227 has been dormant, details on one or more of the most recent activities and their dates, locations, associated merchants, and transaction amounts, etc.


In some embodiments, instead of responding to issuer computer 260 queries, the payment processing network 250 may send batch updates for all virtual payment devices. In other embodiments, the issuer computer 260 may be able to determine whether the virtual payment device 227 is active or dormant without querying other entities such as the payment processing network 250.


At step S418, the issuer computer 260 may determine how to proceed based on whether the virtual payment device 227 is active or dormant. For example, if the virtual payment device 227 is dormant, the issuer computer 260 may send a request to the mobile device 220, asking the consumer 210 whether renewal of the virtual payment device 227 is desired.


Several other actions can be taken by the issuer computer 260 at this point. For example, in some embodiments, if the virtual payment device 227 is dormant, the issuer computer 260 may automatically close the virtual payment device 227 without consulting the consumer 210. In some embodiments, the issuer computer 260 may close the virtual payment device 227 and send a notification message to the consumer 210 notifying the consumer 210 that the virtual payment device 227 (or an account associated with the virtual payment device 227) has been closed and is no longer accessible.


Also, in some embodiments, if the virtual payment device 227 is active, the issuer computer 260 may automatically renew the virtual payment device 227 (e.g., by provisioning an updated virtual payment device 227). Alternatively, the issuer computer 260 may close the current virtual payment device 227 and query the consumer 210 about renewing a new virtual payment device 227 regardless of whether the virtual payment device 227 is active or dormant (e.g., in order to be certain whether the consumer 210 still wants to use the virtual payment device 227, and/or to drive consumer engagement).


Further, in some embodiments, the issuer computer 260 may determine how to proceed further based on whether the mobile device 220 and/or the mobile application 225 are dormant or active. For example, if the mobile device 220 and/or the mobile application 225 are dormant and the virtual payment device 227 is dormant, then the issuer computer 260 may not renew the virtual payment device 227 and may not re-provision the updated virtual payment device onto mobile application 225 stored on mobile device 220. However, in some embodiments, if the mobile device 220 and/or the mobile application 225 are not dormant but active (e.g., the consumer 210 may be using other mobile applications or may be using other access devices stored on the mobile application 225) then issuer computer 260 may determine to renew the virtual payment device 227 and re-provision the updated virtual payment device onto mobile application 225 (e.g., without requesting input from the user).


At step S420, the issuer computer 260 may send a renewal request message to the consumer 210, upon determining that the virtual payment device 227 is to be renewed. As described, in some embodiments, the determination may be made upon determining that the virtual payment device 227 is dormant. In certain embodiments, the determination to renew may be made upon determining that the virtual payment device 277, the mobile application 225 servicing the virtual payment device 277, and/or the mobile device 220 are dormant. The renewal request message may be sent via email, SMS, mobile application 225 notification, or any other suitable form of communication. The request may be sent to a consumer 210 contact address associated with the virtual payment device 227. The renewal request may ask the consumer 210 whether or not the virtual payment device 227 should be renewed. In some embodiments, the renewal request message may include a promotional offer or other incentive for the consumer 210 to have the virtual payment device 227 renewed and to encourage usage.


At step S422, the consumer 210 may indicate whether or not the virtual payment device 227 should be renewed. For example, the consumer 210 may respond to an email or SMS, or the consumer 210 may select an option in the mobile application 225. The consumer 210 may also be able to provide updated contact information (e.g., in case the consumer 210 is now using a different mobile device 220).


At step S424, the mobile application 220 (or other consumer device associated with the consumer 210) may send a renewal response message back to the issuer computer 260 (e.g., via email, SMS, mobile application 125, etc.). Some embodiments may not send a renewal request message to the consumer 210 and automatically renews the virtual payment device 227 without receiving a renewal response message.


At step S426, the issuer computer 260 may determine whether to renew, close, leave, or send an alternative instruction regarding the virtual payment device 227. The issuer computer 260 may determine whether to renew based on the consumer's response, the activity/dormancy of the virtual payment device 227, the activity/dormancy of mobile device 225, the activity/dormancy of mobile application 220, potential fraud associated with the virtual payment device 227, and/or any other suitable factor. For example, if the consumer 210 indicated that the virtual payment device 227 should be renewed, the issuer computer 260 may proceed to renew the virtual payment device 227.


In some embodiments, if the consumer 210 does not respond to the renewal request, the issuer computer 260 may determine that the virtual payment device 227 will be closed and will not be renewed. For example, the consumer 210 may not have responded because the consumer 210 is no longer using the mobile device 220, has deleted or stopped using the mobile application 225, or is no longer interested in using the virtual payment device 227. In these cases, renewing the virtual payment device 227 may not provide any benefit.


Furthermore, renewing the virtual payment device 277 and re-provisioning the mobile device 220 or mobile application 225 when the consumer 210 is no longer using the mobile device 220 or the mobile application 225 may cause multiple failed re-provisioning attempts. As the issuer computer 260 repeatedly attempts to provision and re-provision the virtual payment device onto the mobile device 220, the systematic retry process may cause the issuer's system to crash due to peak load during which too many renewal requests failed. Identifying these virtual payment devices that need not be renewed and re-provisioned enable the stopping of the creation of unnecessary issuer support tickets, increasing over-the-air provisioning success rates, and minimizing loads on the payment processing network (e.g., VTS) and issuer infrastructure.


In some embodiments, the issuer computer 260 may not query the consumer 210, and may decide whether to issue based solely on the activity/dormancy of the virtual payment device 227.


At step S428, the issuer computer 260 may proceed to renew the virtual payment device 227 and/or the mobile application 225. In some embodiments, the issuer computer 260 may instruct the payment processing network 250 or the provisioning computer 270 (that may be part of the issuer) to provision the virtual payment device 227 to the mobile device 220. The same payment credentials may be provided, or the old payment credentials may be replaced with new payment credentials (e.g., a new PAN or payment token). The renewed virtual payment device may also have a new expiration date and/or other identifiers that may distinguish it from the previously existing virtual payment device 227.


In some embodiments, the payment processing network 250 may orchestrate provisioning instead of the issuer computer 260, and the payment processing network 250 may perform one or more of the above steps instead of the issuer computer 260.


V. Example Flow for Determining Whether to Renew a Virtual Access Device


Embodiments may determine whether to renew a virtual access device such as a virtual payment device, based on one or more factors including dormancy. Certain embodiments may determine that a virtual payment device need not be renewed when it has been determined that the virtual payment device or a mobile device to which the virtual payment device is provisioned is dormant.



FIG. 5 shows a flow chart 500 for determining whether to renew a virtual access device and re-provision a user's mobile device in accordance with some embodiments of the invention. Some embodiments may auto-renew a virtual access device upon certain trigger events, such as upon its expiration date, upon the renewal of its counterpart physical access device, when the credentials, the counterpart physical access device, or a consumer device (e.g., the user's mobile device) has been reported stolen or lost, or when the customer requests a re-issue due to potential fraudulent uses, etc. Certain embodiments may auto-renew a virtual access device at the same time or within a timeframe that a counterpart physical access device is being renewed. As it may be inefficient and ineffective to auto-renew all virtual access devices while some virtual access devices may be dormant, some embodiments may determine whether to renew based on a number of factors including a dormancy of the virtual access device.


The process illustrated by flow chart 500 can be performed by one or more processors on one or more servers (such as an authorization server) that are part of an access device issuer such as a payment card issuer, a transit pass issuer, etc. In some embodiments, a portion of the process described by flow chart 500 may also be performed by a transaction processing network, such as a payment processing network.


Some embodiments may not renew a virtual access device although the physical access device is being renewed. In some instances, although the physical access device is still being used by a user on a regular basis, the virtual access device may be dormant (e.g., being used at a low rate or below a threshold frequency). As such, embodiments may determine that it would not be productive to renew the virtual access device and re-provision the user's device with the new virtual access device. Certain embodiments may perform a determination as to whether to renew the virtual access device based on a number of factors in addition to the dormancy of the device. For example, some embodiments may renew the virtual access device upon determining that other virtual access devices (e.g., other virtual payment cards) provisioned on the user's device are still being used by the user. In some such embodiments, the user's mobile device is still being used by the user (i.e., the user has not changed devices) and the mobile application hosting the virtual payment cards has not been deleted by the user.


At block 505, a determination is made as to whether a virtual access device is dormant. Some embodiments may trigger the determination to be made upon determining that an expiration date is coming up (e.g., within a threshold number of days or weeks from the expiration date), that a physical counterpart has been or is being renewed, if there has been potential fraud reported, if a mobile device onto which the virtual access device was initially provisioned has been reported lost or stolen, etc. The determination in some embodiments may be made by a transaction processing network such as a payment processing network or an access device issuer such as a virtual card issuer.


Some embodiments may make the determination that a virtual access device may be dormant by sending a request to a transaction processing network (e.g., a payment processing network, a transit system, a ticket processing network). In some embodiments, a virtual access device may be determined to be dormant when there have not been transactions conducted using the virtual access device (e.g., its payment credentials) for beyond a threshold period of time. Certain embodiments may determine that a virtual access device is dormant when the frequency of transaction is below a threshold number. The transaction processing network may access a database to determine past instances of transactions conducted using the virtual access device, the date and time of the transactions, and the frequency of transactions, etc. Different embodiments may make the determination as to whether a virtual access device is dormant differently.


At block 510, upon determining that the virtual access device is not dormant, the virtual access device may be renewed. Some embodiments may provision the updated virtual access device onto the mobile device. In some embodiments, prior to provisioning the updated virtual access device onto the mobile device, a confirmation may be sent to the user to confirm that the user would like the updated virtual access device to be re-provisioned onto the same mobile device. Some embodiments allow the user to input additional mobile devices (e.g., a mobile tablet, a mobile computer) that the user would like the renewed virtual access device provisioned. Certain embodiments enable the user to input another device that the user would like the renewed virtual access device provisioned instead. Upon receiving a confirmation as to the devices that the user would like the renewed virtual access device provisioned, an issuer server may provision the renewed virtual access device onto those one or more devices.


While some embodiments may determine not to renew the virtual access device based just on the dormancy of the virtual access device, certain embodiments may make the determination based on a number of factors, e.g., dormancy of the mobile application or mobile device onto which the virtual access device is provisioned. At block 515, upon determining that the virtual access device is dormant, a determination can be made as to whether the mobile device (e.g., mobile device 220 from FIG. 2) is no longer in use.


In some embodiments, the determination can be made by sending a request to one or more electronic wallet service providers (e.g., Apple Pay®, Google Wallet®, etc.) or mobile device providers (e.g., Google, Samsung, Apple, etc.) in some instances. The request may be for transaction history associated with a user's mobile application (e.g., mobile application 225 from FIG. 2) that hosts multiple access devices. The one or more electronic wallet providers may host a payment service via a mobile application. In some embodiments, the mobile device may be determined to still be in use (i.e., not dormant) if the user is using the mobile application to conduct transactions using one or more access devices, regardless of whether the one or more access devices includes the virtual access device at issue. In certain embodiments, the mobile device may be determined to still be in use if the user is interacting with the mobile application. For example, if the user is checking a balance or transaction history associated with any of the access devices hosted by the mobile application.


In some embodiments, the mobile device may be determined to still be in use (i.e., not dormant) if the user is still using the same mobile device previously subscribed for the virtual access device. Some embodiments may determine that the user is still using the same mobile device by sending a request to a cellular network service provider or internet service provider. Various methods may be used in making the determination. Upon determining that the mobile device (and/or mobile application) is still in use and not no longer being used by the user at block 515, the virtual access device may be renewed at block 510. Some embodiments may renew the virtual access device and re-provision the updated virtual access device onto the mobile device. Certain embodiments may also determine not to renew the particular virtual access device although other virtual access devices are still being used.


At block 520, upon determining that the mobile device (and/or mobile application) is no longer in use at block 515, the virtual access device may be marked as do not renew. Some embodiments may notate the virtual access device as one to skip auto-renewal e.g., in a database. The access device issuer or the authorization server may then automatically renew various virtual access devices other than those notated as do not renew. By identifying those virtual access devices that need not be renewed, the authorization server need not request a new token for those virtual access devices to be provisioned onto the users' mobile devices. This in turn can reduce the processing load on the authorization server and the token service provider.


At block 525, a notification indicating possible account closure can be sent to the user. Some embodiments may send an e-mail message to an e-mail account, a letter to a physical address, a text message, or other types of messages to the user informing the user that the virtual access device may be closed and therefore no longer usable in a transaction. Instead of a notification of closure, some embodiments may inquire whether the user does intend to close the virtual access device or if the user instead would like to have the access device renewed.


At block 530, a determination can be made as to whether a request to renew has been received. In some embodiments, upon receiving the notification of potential closure of the virtual access device, the user may send a request to renew the virtual access device.


At block 535, upon determining that the request to renew has not been received, the account can be closed and a notification of the account closure can be sent to the user. Upon determining that the request to renew has been received, at block 510, the virtual access device can be renewed. Some embodiments may wait for a response from the user as to whether the user would like to renew the virtual access device. If a response or a request to renew has not been receive for more than a threshold period of time, then an issuer may close the virtual access device.


VI. Example Flow for Determining a Dormancy of a Virtual Access Device


Various embodiments determine the dormancy of a virtual access device in making the determination as to whether to renew the virtual access device. Some embodiments determine the dormancy of one or more virtual access devices periodically and without being prompted by any trigger. This serves as a cleaning mechanism that eliminates unnecessary renewals ahead of time. Certain embodiments determine the dormancy of the virtual access device when an expiration date of the virtual access device is approaching. In some embodiments, the dormancy of a virtual access device can be determined by one or more servers at an issuer or one or more servers that are part of a transaction processing network (e.g., payment processing network).



FIG. 6 shows a flow chart 600 for determining whether a virtual access device is dormant in accordance with certain embodiments of the invention. In some embodiments, a virtual access device is dormant if there has been an activity level below a certain threshold. Some embodiments may send a dormancy response to a dormancy status requestor in response to a request for a virtual access device's dormancy status. The process illustrated by flow chart 600 can be performed by one or more processors on one or more servers that are part of a transaction processing network such as a transit network or a payment processing network. A transaction processing network may process payment transactions or other types of access transactions.


At block 605, a dormancy request from a server can be received, where the dormancy request includes information identifying a virtual access device. In some embodiments, the information identifying a virtual access device can include user profile information, payment information (e.g. PANs or primary account numbers, payment tokens (i.e., PAN substitutes), verification values such as CVVs, etc.), bank account information, and/or the like and can be used in a variety of transactions, such as but not limited to eCommerce, social networks, money transfer/personal payments, mobile commerce, proximity payments, gaming, and/or the like for retail purchases, digital goods purchases, utility payments, purchasing games or gaming credits from gaming websites, transferring funds between users, and/or the like PAN, a device ID associated with the virtual access device, or a combination of identifiers. For instance, information identifying a virtual access device such as a payment card can include a PAN, expiration date, security code, a token, or a combination of the above. In another instance, information identifying a virtual access device such as an access card can include a serial code, identification numbers, etc. In certain embodiments, the information identifying a virtual access device can be used to identify a particular user account and/or access device among a list of other identifiers. For instance, the PAN of a virtual payment card can be used to search a database of transactions to determine whether the virtual payment card has been used and how often.


At block 610, the virtual access device can be determined to be dormant based on previous transactions involving the virtual access device and at least one dormancy rule. Some embodiments may analyze the past transactions of the virtual access device in determining whether the device is dormant. In some embodiments, one or more dormancy rules can be specified by a system administrator defining how to classify a virtual access device as a dormant device. A dormancy rule can specify that a transaction activity level below a certain threshold may be considered a dormant device. For instance, a dormancy rule can specify that a virtual access device is dormant if there were fewer than 3 transactions within the past 6 months. Another dormancy rule can specify that an access device is dormant if the most recent transaction occurred more than a threshold time period ago (e.g., 6 months, a year, 2 years) from a present date. Another dormancy rule can specify that a virtual access device is dormant if the usage frequency (starting from the opening date of the virtual access device) is below a threshold frequency in combination with the most recent transaction being prior to a threshold time interval from a current date. Different embodiments may define different sets of dormancy rules.


Some embodiments may determine whether a virtual access is dormant based on other or additional factors to transaction history. Some embodiments may determine that a virtual access device is dormant even when the physical access device has some activity level. In some such embodiments, the dormancy rule may specify that the virtual access device may be determined to be dormant even when the user is conducting transactions using the physical counterpart device. Certain embodiments may determine that a virtual access device is dormant only when the credentials associated with the device has not been used beyond a threshold period of time, regardless of whether the credentials are stored on the physical or virtual access devices. Different embodiments may determine that a virtual access device is dormant based on a different set of dormancy rules.


Further, some embodiments may determine dormancy of one or more virtual access devices associated with the user by sending a request to an electronic wallet provider. As such, embodiments may determine whether the user's mobile device is still active regardless of the inactivity on the particular virtual card. Upon determining that the user is still using one or more other virtual cards on the mobile device, certain embodiments may determine that the particular virtual card is indeed dormant. Certain embodiments may receive a response from the electronic wallet provider where the response indicates an activity level associated with the one or more virtual access devices associated with the user. The authorization server may then determine whether to renew the virtual access device based on the dormancy response and the response from the electronic wallet provider.


At block 615, the dormancy response indicating that the virtual access device is dormant can be sent to the server. In certain embodiments, an authorization server may determine whether to renew the virtual access device based on the dormancy response. In some embodiments, the authorization server may determine not to renew the virtual access device based on the dormancy response. As such, the token service provider need not generate a new token for the renewal of the virtual access device. In some embodiments, the new token may be generated by a server computer operated by the token service provider or the transaction processing network. Some embodiments may send the determination of whether a virtual access device is dormant in response to the request for dormancy.


In some embodiments, the dormancy response can include an indication as to whether the device is dormant or an activity level of the device's past transactions. For instance, the dormancy response can be a binary response or it can include a number (e.g., 1-10) or a tag (e.g., high, low, medium) that indicates the device's historical activity level.


Upon receiving the dormancy response that the virtual access device is dormant, the server (e.g., an issuer server) may then determine to close the account and send the user a notification of the device or account closure. In some embodiments, the server may determine whether to close the account associated with the virtual card or to renew the virtual card and re-provision the card onto the user's device based on a number of factors in addition to the virtual access device being dormant.


As described, upon receiving a dormancy response indicating that a virtual access device is dormant, the issuer (e.g., an authorization server) can be caused to cease a renewal of the virtual access device. In some embodiments, the issuer can be cause to cease the renewal upon receiving an additional dormancy response from a wallet provider (e.g., where the dormancy response indicates that the mobile application provided by the wallet provider or the user's other access devices being hosted by the wallet provider are dormant). Causing the issuer to cease a renewal can include causing the issuer to mark the virtual access device as “not to renew” or “skip” such that when the issuer performs bulk renewals, the issuer computer skips the virtual access device. In certain embodiments, causing the issuer computer to cease the renewal (e.g., by marking the virtual access device in a database) can thereby save the issuer computing from having to provision a new virtual access device onto the user's mobile device.


In some embodiments, upon receiving the dormancy request from the authorization server, a server that is part of the transaction processing network can send a message to a user associated with the virtual access device inquiring whether to keep the virtual access device active. The server may receive a response indicating that the user does not want to keep the virtual access device active. In this instance, the server may then send the response to the authorization server and enable the authorization server to determine whether to renew the virtual access device based on the dormancy response the response from the user.


In some embodiments, the authorization server may be caused to cease the renewal of a virtual access device based on the dormancy of the mobile application and/or one or more of the other virtual access devices associated with a user in addition to the dormancy of a particular virtual access device of the user. Embodiments may determine the dormancy of the mobile application and/or one or more other virtual access devices being hosted by the mobile application.


Some embodiments may determine that at least one of the mobile application or one or more other virtual access devices being hosted by the mobile application is not dormant. Embodiments may then send the determination that at least one of the mobile application or other virtual access devices is not dormant to the authorization server, and thereby cause the authorization server to provision a new virtual access device onto the mobile device, the new virtual access device replacing the virtual access device.


The issuer computer (or the authorization computer) may perform the determination as to whether to renew various virtual access devices for millions and billions of users, where each virtual access device is slated to be renewed at some point. After identifying those virtual devices that should still be renewed, the issuer computer may then proceed to renew and provision those virtual access devices while leaving the virtual access devices determined to not be renewed alone or closing those virtual access devices. Instead of auto-renewing those virtual access devices that have been flagged, the authorization computer would cease to renew those virtual access devices.


By identifying those that need not be renewed, there would no longer be a need to provision (and possibly re-provision due to repeated failed attempts) an updated virtual access device onto the user's mobile device. By not attempting to re-provision a new virtual access device onto the user's mobile device, computing resources can be saved and potential systemic crashes due to peak load can be prevented. Enabling the authorization computer to determine that the authorization computer no longer needs to re-provision an updated virtual access device onto a user's mobile device can allow the authorization computer to devote its computing resources to other tasks and minimize any unnecessary processing expenditures.


As there are millions and potentially billions of access devices being issued by an issuer each year, there can be billions of renewals that are due for any particular year. By identifying those virtual access devices that need not be renewed (e.g., where there is no longer a use to the user and that the user would not use the virtual access device whether it is renewed or not), the number of new tokens that need to be requested by an authorization server may be reduced. This, in turn, can significantly reduce the processing load on the token service provider (operated by a transaction processing network, or in some instances an issuer) and the authorization server (operated by the issuer). Furthermore, instances of issuers and transaction processing networks crashing due to peak load during which too many renewal requests are being made at certain times of the day or year can also be drastically reduced.


VII. Computer System



FIG. 7 is a high level block diagram of a computer system 700 that may be used to implement any of the entities or components described above. The subsystems shown in FIG. 7 are interconnected via a system bus 750. Additional subsystems include a printer 708, keyboard 716, fixed disk 718, and monitor 712, which is coupled to display adapter 710. Peripherals and input/output (I/O) devices, which couple to I/O controller 702, can be connected to the computer system by any number of means known in the art, such as a serial port. For example, serial port 714 or external interface 720 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 700 allows the central processor 706 to communicate with each subsystem and to control the execution of instructions from system memory 704 or the fixed disk 718, as well as the exchange of information between subsystems. The system memory 704 and/or the fixed disk may embody a computer-readable medium.


Embodiments of the invention have a number of advantages. For example, in embodiments of the invention, efficiency and efficacy can be improved for a provisioning system. Instead of automatically attempting to renew every virtual payment device when a corresponding physical payment device is renewed, virtual payment devices can be renewed selectively. For example, virtual payment devices may be renewed if they are active, or if the consumer indicates a desire to continue using the virtual payment device. This improves over-the-air provisioning success rates, and prevents wasting effort on attempting to provision virtual payment devices for consumers that will not use them, to mobile devices that are no longer being used, and to mobile applications that have been deleted. This also prevents building excessive processing load and potential system crashes due to repeated attempts to provision virtual payment devices to mobile devices and applications that are no longer active.


Further advantages include driving consumer engagement. For example, in some embodiments, a virtual payment device may not be renewed unless the consumer requests renewal, such that the consumer regularly engages with the issuer. Also, promotional offers and other incentives can be provided to the consumer during such engagements in order to promote usage.


As described, the inventive service may involve implementing one or more functions, processes, operations or method steps. It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc. 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 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++ or Perl 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, such as a 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 CD-ROM. Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.


While certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not intended to be restrictive of the broad invention, and that this invention is not to be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those with ordinary skill in the art.


As used herein, the use of “a”, “an” or “the” is intended to mean “at least one”, unless specifically indicated to the contrary.

Claims
  • 1. A computing system comprising: at least one processor and at least one memory coupled to the at least one processor, the at least one memory storing instructions, which when executed by the at least one processor cause the at least one processor to: send a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceive a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the instructions, which when executed by the at least one processor further cause the at least one processor to: determine whether to renew the virtual access device based on the dormancy response, and wherein renewing the virtual access device comprises provisioning an updated virtual access device to a mobile device with the virtual access device.
  • 2. The computing system of claim 1, wherein the instructions, which when executed by the at least one processor further cause the at least one processor to: cease a renewal of the virtual access device based on the dormancy response.
  • 3. The computing system of claim 1, wherein a dormancy rule in the at least one dormancy rule specifies that the virtual access device is determined to be dormant when a previous transaction occurred more than a threshold time period ago.
  • 4. A computing system comprising: at least one processor and at least one memory coupled to the at least one processor, the at least one memory storing instructions, which when executed by the at least one processor cause the at least one processor to:send a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceive a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the virtual access device is associated with a mobile application running on a mobile device, wherein the transaction processing computer determines a dormancy of at least one of the mobile application or one or more other virtual access devices being hosted by the mobile application, and wherein the instructions, which when executed by the at least one processor further cause the at least one processor to:cease a renewal of the virtual access device based on the dormancy response and the dormancy of at least one of the mobile application, or one or more of the other virtual access devices.
  • 5. A computing system comprising: at least one processor and at least one memory coupled to the at least one processor, the at least one memory storing instructions, which when executed by the at least one processor cause the at least one processor to:send a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceive a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the virtual access device is associated with a user, wherein the transaction processing computer determines a dormancy of one or more virtual access devices associated with the user by sending a request to an electronic wallet provider, wherein the transaction processing computer receives a response from the electronic wallet provider, the response indicating an activity level associated with the one or more virtual access devices associated with the user, and wherein the instructions, which when executed by the at least one processor further cause the at least one processor to:determine whether to renew the virtual access device based on the dormancy response and the response from the electronic wallet provider.
  • 6. The computing system of claim 1, wherein the transaction processing computer sends a message to a user associated with the virtual access device inquiring whether to keep the virtual access device active, wherein the transaction processing computer receives a response indicating that the user does not want to keep the virtual access device active, wherein the transaction processing computer sends the response from the user to the computing system, and wherein the instructions, which when executed by the at least one processor further cause the at least one processor to: receive, from the transaction processing computer, the response from the user; anddetermine whether to renew the virtual access device based on the dormancy response and the response from the user.
  • 7. The computing system of claim 1, wherein a physical access device corresponds to the virtual access device, and wherein both the physical access device and the virtual access device enable a user to obtain access to a building.
  • 8. The computing system of claim 1, wherein the instructions, which when executed by the at least one processor further cause the at least one processor to: determine not to renew the virtual access device based at least on the dormancy response, and wherein the transaction processing computer thereby need not generate a new token for a renewal of the virtual access device.
  • 9. A computing system comprising: at least one processor and at least one memory coupled to the at least one processor, the at least one memory storing instructions, which when executed by the at least one processor cause the at least one processor to:send a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceive a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the virtual access device is associated with a mobile application running on a mobile device, wherein the transaction processing computer determines that at least one of the mobile application or one or more other virtual access devices being hosted by the mobile application is not dormant, and wherein the instructions, which when executed by the at least one processor further cause the at least one processor to:receive the determination that at least one of the mobile application or other virtual access devices is not dormant from the transaction processing computer; andprovision a new virtual access device onto the mobile device, the new virtual access device replacing the virtual access device.
  • 10. A method comprising: sending, by a server computer, a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule;receiving, by the server computer, a dormancy response from the transaction processing computer indicating that the virtual access device is dormant; anddetermining whether to renew the virtual access device based on the dormancy response, and wherein renewing the virtual access device comprises provisioning an updated virtual access device to a mobile device with the virtual access device.
  • 11. The method of claim 10, further comprising: determining whether to renew the virtual access device based on the dormancy response.
  • 12. The method of claim 10, further comprising: ceasing a renewal of the virtual access device based on the dormancy response.
  • 13. The method of claim 10, wherein a dormancy rule in the at least one dormancy rule specifies that the virtual access device is determined to be dormant when a previous transaction occurred more than a threshold time period ago.
  • 14. A method comprising: sending, by a server computer, a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceiving, by the server computer, a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the virtual access device is associated with a mobile application running on a mobile device, wherein the transaction processing computer determines a dormancy of at least one of the mobile application or one or more other virtual access devices being hosted by the mobile application, and wherein the method further comprises:ceasing a renewal of the virtual access device based on the dormancy response and the dormancy of at least one of the mobile application or one or more of the other virtual access devices.
  • 15. A method comprising: sending, by a server computer, a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceiving, by the server computer, a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the virtual access device is associated with a user, wherein the transaction processing computer determines a dormancy of one or more virtual access devices associated with the user by sending a request to an electronic wallet provider, wherein the transaction processing computer receives a response from the electronic wallet provider, the response indicating an activity level associated with the one or more virtual access devices associated with the user, and wherein the method further comprises:determining whether to renew the virtual access device based on the dormancy response and the response from the electronic wallet provider.
  • 16. The method of claim 10, wherein the transaction processing computer sends a message to a user associated with the virtual access device inquiring whether to keep the virtual access device active, wherein the transaction processing computer receives a response indicating that the user does not want to keep the virtual access device active, wherein the transaction processing computer sends the response from the user to the server computer, and wherein the method further comprises: receiving, from the transaction processing computer, the response from the user; anddetermining whether to renew the virtual access device based on the dormancy response and the response from the user.
  • 17. The method of claim 10, wherein a physical access device corresponds to the virtual access device, and wherein both the physical access device and the virtual access device enable a user to obtain access to a building.
  • 18. The method of claim 10, further comprising: determining not to renew the virtual access device based at least on the dormancy response, and wherein the transaction processing computer thereby need not generate a new token for a renewal of the virtual access device.
  • 19. A method comprising: sending, by a server computer, a dormancy request to a transaction processing computer, the dormancy request including information identifying a virtual access device, wherein the transaction processing computer determines that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule; andreceiving, by the server computer, a dormancy response from the transaction processing computer indicating that the virtual access device is dormant,wherein the virtual access device is associated with a mobile application running on a mobile device, wherein the transaction processing computer determines that at least one of the mobile application or one or more other virtual access devices being hosted by the mobile application is not dormant, and wherein the method further comprises:receiving the determination that at least one of the mobile application or other virtual access devices is not dormant from the transaction processing computer; andprovisioning a new virtual access device onto the mobile device, the new virtual access device replacing the virtual access device.
CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 15/130,854, filed Apr. 15, 2016, which is a non-provisional application of and claims the benefit of priority to U.S. Provisional Application No. 62/148,642, filed on Apr. 16, 2015, which is herein incorporated by reference in its entirety for all purposes.

US Referenced Citations (560)
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 et al. 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
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
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
20030140146 Akers et al. Jul 2003 A1
20030172335 Sharma Sep 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
20060235795 Johnson Oct 2006 A1
20060237528 Bishop Oct 2006 A1
20060278704 Saunders Dec 2006 A1
20070088948 Ji et al. Apr 2007 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
20090249063 Sakurai 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
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
20120159483 He 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
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
20130111076 Vaynberg et al. 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
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
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
20140068725 Zhang et al. 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
20140165060 Muller Jun 2014 A1
20140188586 Carpenter et al. Jul 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
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
20150081544 Wong et al. Mar 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
20150175178 Ignatius 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
20150195176 Vasseur 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
20150288694 Liebl, III Oct 2015 A1
20150312038 Palanisamy Oct 2015 A1
20150319158 Kumnick Nov 2015 A1
20150332262 Lingappa Nov 2015 A1
20150356560 Shastry et al. Dec 2015 A1
20160021194 Prabhakar et al. Jan 2016 A1
20160028550 Gaddam et al. Jan 2016 A1
20160042263 Gaddam et al. Feb 2016 A1
20160065370 Le Saint et al. Mar 2016 A1
20160092696 Guglani et al. Mar 2016 A1
20160092872 Prakash et al. Mar 2016 A1
20160103675 Aabye et al. Apr 2016 A1
20160119296 Laxminarayanan et al. Apr 2016 A1
20160140545 Flurscheim et al. May 2016 A1
20160147560 Jolfaei et al. May 2016 A1
20160148197 Dimmick May 2016 A1
20160148212 Dimmick May 2016 A1
20160171435 Newton Jun 2016 A1
20160171479 Prakash et al. Jun 2016 A1
20160173483 Wong et al. Jun 2016 A1
20160210628 McGuire Jul 2016 A1
20160218875 Le Saint et al. Jul 2016 A1
20160224976 Basu Aug 2016 A1
20160224977 Sabba et al. Aug 2016 A1
20160232527 Patterson Aug 2016 A1
20160239842 Cash et al. Aug 2016 A1
20170046696 Powell et al. Feb 2017 A1
20170103387 Weber Apr 2017 A1
20170150549 Olsson et al. May 2017 A1
20170220818 Nagasundaram et al. Aug 2017 A1
20170228723 Taylor Aug 2017 A1
20170364422 Antony Dec 2017 A1
20180088979 Jiang Mar 2018 A1
20190025903 Mehta Jan 2019 A1
20190056969 Khandros Feb 2019 A1
20190065230 Tsirkin Feb 2019 A1
Foreign Referenced Citations (15)
Number Date Country
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
Non-Patent Literature Citations (21)
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.
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.
Wang, U.S. Appl. No. 62/000,288 (unpublished), Payment System Canonical Address Format filed on May 19, 2014.
Sharma et al., U.S. Appl. No. 62/003,717 (unpublished), Mobile Merchant Application filed on May 28, 2014.
Kalgi et al., U.S. Appl. No. 62/024,426, (unpublished) Secure Transactions Using Mobile Devices filed on Jul. 14, 2014.
Prakash et al., U.S. Appl. No. 62/037,033 (unpublished), Sharing Payment Token filed on Aug. 13, 2014.
Hoverson et al., U.S. Appl. No. 62/038,174 (unpublished), Customized Payment Gateway filed on Aug. 15, 2014.
Wang, U.S. Appl. No. 62/042,050 (unpublished), Payment Device Authentication and Authorization System filed on Aug. 26, 2014.
Gaddam et al., U.S. Appl. No. 62/053,736 (unpublished), Completing Transactions Without a User Payment Device filed on Sep. 22, 2014.
Patterson, U.S. Appl. No. 62/054,346 (unpublished), Mirrored Token Vault filed on Sep. 23, 2014.
Stubbs et al., U.S. Appl. No. 62/103,522 (unpublished), Methods and Systems for Wallet Provider Provisioning filed on Jan. 14, 2015.
Flurscheim et al., U.S. Appl. No. 62/108,403 (unpublished), Wearables With NFC HCE filed on Jan. 27, 2015.
Kinagi, U.S. Appl. No. 62/117,291 (unpublished), Token and Cryptogram Using Transaction Specific Information filed on Feb. 17, 2015.
Galland et al. U.S. Appl. No. 62/128,709 (unpublished), Tokenizing Transaction Amounts filed on Mar. 5, 2015.
Rangarajan et al., U.S. Appl. No. 61/751,763 (unpublished), Payments Bridge filed on 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 on Oct. 23, 2013.
Aissi et al., U.S. Appl. No. 61/738,832 (unpublished), Management of Sensitive Data filed on Dec. 18, 2012.
Powell, U.S. Appl. No. 61/892,407 (unpublished), Issuer Over-The-Air Update Method and System filed on Oct. 17, 2013.
Powell, U.S. Appl. No. 61/926,236 (unpublished), Methods and Systems for Provisioning Mobile Devices With Payment Credentials and Payment Token Identifiers filed on Jan. 10, 2014.
U.S. Appl. No. 15/130,854 , “Non-Final Office Action”, dated Nov. 17, 2017, 7 pages.
Related Publications (1)
Number Date Country
20180262970 A1 Sep 2018 US
Provisional Applications (1)
Number Date Country
62148642 Apr 2015 US
Continuations (1)
Number Date Country
Parent 15130854 Apr 2016 US
Child 15976429 US