Delivering user data using resource addresses

Abstract

Methods and systems are provided for pre-provisioning tokens on a mobile device without installing an application on the mobile device. A server computer may: receive credentials associated with a user account; the certificate is encrypted; generating a payload in the form of a remote resource address; generating an application associated with the remote resource address; transmitting the application to a mobile device in response to the mobile device navigating to the remote resource address; when the application is executed on the mobile device, receiving the payload from the application; and pre-provisioning a token associated with the user account on a digital wallet of the mobile device when the application is executed on the mobile device without being installed on the mobile device.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is a PCT application that claims the priority benefit of U.S. Provisional Application No. 63 / 423,326, filed on November 7, 2022, titled "DELIVERING USER DATA USING RESOURCE ADDRESS", which is incorporated herein by reference in its entirety for all purposes. Background Art

[0003] Digital wallets allow users of mobile devices to complete transactions or provide credentials, such as transportation credentials or event tickets. However, in order to provision a credential or a transaction card on a digital wallet, the user must first download an application associated with the provider of the credential or transaction card to the mobile device. This results in inefficiencies in adding the credential or transaction card to the digital wallet. Additionally, the user may have to use storage space on the mobile device for an application that is used once for provisioning the credential or transaction card and will not be used again. This is especially true when the user wishes to provision a newly created account or an existing account not associated with a physical card to the digital wallet. This results in an inefficient and disjointed user experience when the user attempts to add a credential or transaction card to the digital wallet for subsequent use.

[0004] Embodiments of this application, individually and collectively, solve these and other problems. Summary of the Invention

[0005] One embodiment includes a method. The method includes: receiving, by a server computer, a credential associated with a user account; encrypting, by the server computer, the credential with an encryption key to generate an encrypted credential, wherein the encrypted credential is unique to the user account; generating, by the server computer, a payload in the form of a remote resource address, wherein the payload includes the encrypted credential; generating, by the server computer, an application associated with the remote resource address; transmitting, by the server computer, the application to a mobile device in response to the mobile device navigating to the remote resource address, wherein navigating to the remote resource address on the mobile device triggers the execution of the application on the mobile device without installing the application on the mobile device; receiving, by the server computer, from the mobile device, the payload from the application when the application is executed on the mobile device, wherein the application retrieves the payload from the remote resource address; and provisioning, by the server computer, a token associated with the user account on the digital wallet of the mobile device when the application is executed on the mobile device without being installed on the mobile device.

[0006] Another embodiment includes a server computer that includes: one or more processors; and a computer-readable medium that includes code executable by the one or more processors to perform steps including: receiving credentials associated with a user account; encrypting the credentials with an encryption key to generate encrypted credentials, where the encrypted credentials are unique to the user account; generating a payload in the form of a remote resource address, where the payload includes the encrypted credentials; generating an application associated with the remote resource address and the encrypted credentials; transmitting the application incorporating the remote resource address to a mobile device in response to the mobile device navigating to the remote resource address, where navigating to the remote resource address on the mobile device triggers execution of the application on the mobile device without installing the application on the mobile device; receiving, from the mobile device, the payload from the application when the application is executed on the mobile device, where the application retrieves the payload from the remote resource address; and provisioning a token associated with the user account on a digital wallet of the mobile device when the application is executed on the mobile device without being installed on the mobile device.

[0007] Another embodiment includes a method. The method includes: receiving, by the mobile device, a selection of the remote resource address; navigating, in response to the selection, by the mobile device to the remote resource address; receiving, in response to the navigation, by the mobile device an application; executing, by the mobile device, the application on the mobile device without installing the application, where the application disappears from the mobile device when executed; receiving, in response to execution of the application on the mobile device, by the mobile device a token from the server computer, where the token is provisioned on a digital wallet of the mobile device; and transacting, by the mobile device, using the token provisioned on the mobile device.

[0008] Additional details regarding the embodiments can be seen in the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A block diagram illustrating a system according to various embodiments.

[0010] Figure 2 A block diagram illustrating an exemplary server computer according to various embodiments.

[0011] Figure 3 A block diagram illustrating an exemplary user device according to various embodiments.

[0012] Figure 4 A flowchart illustrating a method according to various embodiments.

[0013] Figure 5 A flowchart showing a method according to various embodiments is presented.

[0014] Figure 6A and 6B A flowchart showing a process according to various embodiments is presented.

[0015] Figures 7A-7D A flowchart showing a process according to various embodiments is presented.

[0016] Figure 8A and 8B A series of exemplary interfaces according to various embodiments are presented. DETAILED DESCRIPTION

[0017] Embodiments include systems and methods for enabling a user to complete a provisioning process or other functions via a mobile device and using an application without having to download the application to the mobile device. For example, the disclosed embodiments may allow a user to interact with or execute application functions without downloading the application to the mobile device, thereby facilitating seamless interaction with a resource provider (i.e., the resource provider associated with the application) and optimizing mobile device functionality without using memory space when storing the complete application.

[0018] For example, a user may be eligible to receive a credential (e.g., a gift card) from a credential issuer such as a resource provider. Typically, in order to receive a digital version of the credential, the user must download an application associated with the resource provider to their mobile device in order to be able to receive the credential and load the credential into a digital wallet on their mobile device. However, the disclosed embodiments enable the user to receive the credential and load the credential into their digital wallet without the additional requirement of downloading the application. For example, instead of downloading the application, a unique Uniform Resource Locator (URL) may be provided to the user via the web browser of their mobile device. By navigating to the URL, the user can cause the mobile device to trigger the execution of a lightweight application (e.g., App clip TM or Instant App TM ) that is configured to support provisioning a token on a digital wallet on the mobile device without downloading the entire application on the mobile device. Thus, via the lightweight application, the user can accept the credential and load the credential into their digital wallet without the additional effort, time, and resources associated with downloading an application on the mobile device.

[0019] Additionally, due to the lack of available memory on the mobile device, the user's ability to download applications may be restricted. In some embodiments, without administrator approval, users may not be permitted to download applications on the mobile device (e.g., without employer approval, an employee may not be permitted to download applications). The process of obtaining approval for only provisioning digital credentials can be cumbersome and inefficient. In another example, if the mobile device is not connected to Wi-Fi, the user may have limited bandwidth or available data usage for downloading the complete application. Typically, when downloading an application on the user device, information about the user of the user device is shared with the resource provider or the entity managing the application. When users are more experienced and / or more concerned about the types of personal information they share with third parties, they may be reluctant to share any personal information with the resource provider managing the application. Therefore, unless absolutely necessary, users may be reluctant to download any applications on their user devices. Thus, the disclosed embodiments enable users to provision credentials on the digital wallet without the need for the user to download and install applications on their mobile devices. Accordingly, the embodiments provide improved data security and prevent the sharing of personal information with third parties against the will of the personal information owner. Thus, the embodiments allow compliance with domestic and foreign data privacy laws and regulations (e.g., General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA)).

[0020] In an example of the disclosed embodiments, the server computer may receive credentials associated with a user account. The credentials may be, for example, information unique to the user account, such as the primary account number (PAN), card verification value (CVV), account holder name, account holder address, etc. The server computer may generate an encrypted credential by encrypting the received credential with an encryption key. The server computer may then generate a payload in the form of a remote resource address, such as a URL, and may generate an application associated with the remote resource address (e.g., a lightweight application in the form of an App Clip TM or an Instant App TM ).

[0021] In the disclosed embodiments, the server computer may transmit the application to the mobile device in response to the mobile device navigating to the remote resource address. For example, navigating to the remote resource address on the mobile device triggers the execution of the application on the mobile device without installing the application on the mobile device. When the application is executed on the mobile device, the server computer receives a payload (e.g., an encrypted credential) from the application. For example, the application may retrieve the payload from the remote resource address and cause the mobile device to transmit the payload to the server computer.

[0022] Finally, when the mobile device executes an application, the server computer can provision credentials on the mobile device's digital wallet. This can be done without installing the application on the mobile device. For example, the application executed by the mobile device can be a lightweight version of an application configured to enable the mobile device to complete one or more tasks. According to various embodiments, the server computer provisions credentials on the digital wallet by obtaining and provisioning a token associated with the user account on the digital wallet.

[0023] The systems and methods described herein facilitate the seamless use of lightweight applications to enable the addition of credentials (e.g., account identifiers, payment methods, or other forms of certificates or vouchers) to a digital wallet without the user having to download the application to the mobile device. Accordingly, embodiments improve the user experience and enable the user to add a digital wallet without additional time and resources (e.g., memory and data usage) and data sharing associated with downloading an application.

[0024] Accordingly, the disclosed embodiments enable a user to execute an application accessed via a remote resource address via a mobile device without having to download the application to the mobile device. Before discussing specific embodiments, some terms may be described in detail.

[0025] A "user" may include an individual. In some instances, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0026] A "mobile device" (sometimes referred to as a mobile communication device or user device) may include any suitable electronic device that a user can transport and operate, and the mobile device may also provide the ability to communicate remotely with a network. The mobile communication device may communicate using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, 5G, or similar network), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that can 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, netbooks, laptop computers, wearable devices (e.g., watches, rings, glasses), vehicles (e.g., cars and motorcycles), personal music players, handheld dedicated readers, etc. The mobile device may include any suitable hardware and software for performing such functions and may also include multiple devices or components (e.g., two devices connected together may be considered a single mobile device when the device remotely accesses the network by connecting to another device, i.e., using another device as a modem).

[0027] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authorization. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used for authentication. Examples of credentials include value vouchers, identification cards, authentication documents, access cards, passwords, and other login information, etc.

[0028] A "payment credential" can include any suitable information associated with an account (e.g., a payment account and / or a payment device associated with the account). Such information can be directly related to the account or can be derived from information associated with the account. Examples of payment credentials can include a PAN (primary account number or "account number"), username, expiration date, and verification value, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, token, etc. An example of a PAN is a 16 - digit number, such as "40001234 5678 9010". In some embodiments, a payment credential can include additional information that can be used to authorize a transaction. For example, a payment credential can include a password associated with the transaction.

[0029] A "digital wallet" can include an electronic device that allows an individual to conduct e - commerce transactions. A digital wallet can store user profile information, credentials, payment credentials, bank account information, one or more digital wallet identifiers, etc., and can be used in various transactions, such as but not limited to e - commerce, social networking, money transfer / personal payment, mobile commerce, proximity payment, gaming, etc., for retail purchases, digital goods purchases, utility payments, purchasing games or game tokens from a gaming website, transferring money between users, etc. A digital wallet can be designed to simplify the purchase and payment process. A digital wallet can allow a user to load one or more payment cards onto the digital wallet for payment without having to enter the account number or present a physical card. A digital wallet can include a money transfer application.

[0030] A "credential issuer" can be an entity that can provide credentials to a user. For example, a credential issuer can provide credentials such as digital payment cards, digital gift cards, digital commuter cards, digital tickets, digital licenses, etc. Credentials can be provisioned onto the digital wallet of a mobile device so that the mobile device can use the credentials to complete transactions, prove identity, enter events, etc. A credential issuer can be a resource provider, a bank, a transportation authority, a ticketing system, a licensing agency, a health agency, etc., or any entity that provides digital credentials unique to one or more users.

[0031] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, venue and residential operators, etc. A "merchant" can generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0032] A "server computer" can include a powerful computer or a cluster of computers associated with a payment processor or other financial entity. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers acting as a unit. In one instance, a server computer can be a database server coupled to a web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers.

[0033] A "credential issuer computer" can include a computer, server, or a series of interconnected computers maintained by or associated with a credential issuer. The credential issuer can include a resource provider, and the resource provider can include an entity (e.g., a merchant, a retailer) that provides resources (e.g., goods / services) to a user. The credential issuer computer can provide a web page / portal that allows a user to access an interactive computing environment associated with the credential issuer. Information provided by the user can be referred to as "interaction data". Interaction data can include information related to the requested goods / services (e.g., item number, total value of goods / services), user details (e.g., user name, age, address), user device details, etc.

[0034] Figure 1 System 100 is shown including a plurality of components. System 100 includes a credential issuer computer 110, a server computer 120, and a mobile device 130, each of which can be embodied by one or more computers. According to the disclosed embodiments, one or more components of System 100 can be used to provision a token on the mobile device 130.

[0035] The credential issuer computer 110 can be associated with a credential issuer. The credential issuer can be an entity that issues credentials to a user. For example, the credential issuer can be a resource provider, which can be an entity that provides resources such as goods, services, information, and / or access. Examples of resource providers include merchants, access devices, secure data access points, etc. A merchant is generally an entity that participates in a transaction and is capable of selling goods or services or providing access to goods or services. The resource provider can accept various forms of payment (e.g., a payment card such as a credit card or debit card) and can use various tools to conduct different types of transactions. In another example, the credential issuer can be a bank, where the bank issues credentials such as a bank card or prepaid card associated with a user account.

[0036] For example, as an incentive for opening a new account, the bank can provide a credential (e.g., a prepaid gift card) to the user. The prepaid gift card can be associated with a resource provider. Thus, the credential issuer can provision a credential associated with another entity or a credential that can be used to complete a transaction with another entity. In another example, the resource provider can provide a credential (e.g., a prepaid card) to the user, where the credential is a prepaid debit card that can be used to complete a transaction with any resource provider that accepts the prepaid debit card.

[0037] An example of the mobile device 130 is a device capable of executing one or more applications stored thereon, such as a smart phone, a smart watch, a wearable device, etc. For example, the mobile device 130 can be configured to obtain and execute the application 135 without downloading and installing the application 135 on the mobile device 130. For example, the application 135 can be an App clip TM or an Instant App TM which is a form of lightweight application configured to support the provisioning of tokens on a digital wallet. The application 135 can be an application generated by the server computer 120 in response to a request from the credential issuer computer 110 to generate an application and a remote resource address associated with the user's user account.

[0038] The mobile device 130 can be capable of interacting with the server computer 120. The mobile device 130, the credential issuer computer 110, and the server computer 125 can all communicate operably with each other via any suitable communication channel or communication network. Suitable communication networks can be any one and / or combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an operation task as an Internet node (OMNI), a secure custom connection, a wide area network (WAN), a wireless network (e.g., using protocols such as but not limited to the Wireless Application Protocol (WAP), I-mode, etc.), etc.

[0039] Messages between computers, networks, servers, and devices can be transmitted using secure communication protocols, such as but not limited to, Secure File Transfer Protocol (SFTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO8583), etc.

[0040] Server computer 120 can be associated with a payment processor, which can be an entity that implements payment processing between a resource provider and a user (e.g., a user associated with mobile device 130). Server computer 120 can communicate with credential issuer computer 110, for example, to receive a request to generate a remote resource address (e.g., a URL) that includes a payload for a specific user. For example, credential issuer computer 110 can transmit a request to server computer 120, where the request includes credentials associated with a user account.

[0041] In response to the request, server computer 120 can encrypt the credentials and generate a payload that includes the encrypted credentials. Server computer 120 can also generate an application associated with the remote resource address. This application can be, for example, an AppClip TM or an Instant App TM lightweight application that is configured to perform a specific task, such as provisioning a token on a digital wallet. The generated application 135 can be transmitted to mobile device 130. For example, a user can navigate to the remote resource address via a web browser installed on mobile device 130. Navigating to the remote resource address can trigger the execution of the generated application 135 on mobile device 130.

[0042] When application 135 is executed by mobile device 130, application 135 can retrieve the payload from the remote resource address and transmit the payload (including the encrypted credentials) to server computer 120. In response to receiving the payload, server computer 120 can provision a token associated with the user or user account on digital wallet 140 of mobile device 130. As previously described, application 135 can be a lightweight application that performs a specific task or function but is not installed on mobile device 130. The lightweight application is configured to deliver digital content to mobile device 130 without being installed on mobile device 130.

[0043] Thus, the components of system 100 can interact to enable a credential provider to provision a token (e.g., a payment card) on mobile device 130 using application 135 (e.g., a lightweight application) and a unique remote access address, without the user having to download and install an application on mobile device 130.

[0044] Server computer 120 may include a data processing subsystem, network, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. For example, server computer 120 may include a server (e.g., coupled to a network interface by an external communication interface) and a database of information. Server computer 120 may represent a transaction processing network. An exemplary transaction processing network may include VisaNet TM . Such as VisaNet TM A transaction processing network like VisaNet is capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet TM includes a VIP system (Visa Integrated Payment System) for processing authorization requests and a Base II system for performing clearing and settlement services. Server computer 120 may use any suitable wired or wireless network, including the Internet.

[0045] An example of server computer 120 is shown in Figure 2 . Server computer 120 may include a processor 120(a) operably coupled to a computer-readable medium 120(b) (e.g., one or more memory chips, etc.), a memory 120(n), and a network interface 120(o).

[0046] Computer-readable medium 125(b) may include instructions or code executable by a processor (e.g., processor 125(a)). The instructions may include instructions for communicating with mobile device 130 and / or credential issuer computer 110 to provision a token on mobile device 130, as well as instructions for any other suitable functions as described herein. For example, computer-readable medium 125(b) may store: an authentication module 120(c); an on-board module 120(d); a processing module 120(e); a notification module 120(f); an upgrade authentication module 120(g); a payment SDK module 120(h); a device management system (DMS) module 120(i); a consumer identity and access management (B2CIAM) module 120(j); a push SDK module 120(k); an ICS module 120(l); and an application programming interface 120(m). In some embodiments, one or more of the modules may be part of an application generation platform. For example, the application generation platform may include the on-board module 120(d). In some instances, the application generation platform may be a system separate from server computer 120 or may be a subsystem within server computer 120.

[0047] In some embodiments, the server computer 120 may have a different architecture. For example, in some embodiments, each module may be associated with a separate processor, memory, and computer-readable medium within the server computer. In other embodiments, a first processor may be communicatively coupled to a first computer-readable medium that stores: an authentication module 120(c); an on-board module 120(d); a processing module 120(e); a notification module 120(f); and a first API. In this instance, a second processor may be communicatively coupled to a second computer-readable medium that stores: an upgrade authentication module 120(h); a payment SDK module 120(h); a DMS module 120(i); a B2C IAM module 120(j); a push SDK module 120(k); an ICS module 120(l); and a second API. In yet another instance, certain modules and / or functionality may be performed by one or more systems separate from the server computer 120. As a non-limiting example, the authentication module 120(c) may be performed by a separate authentication system configured to communicate with the server computer 120 and the credential issuer computer 110.

[0048] The modules stored by the computer-readable medium 120(b) may be used to complete the process of provisioning a token on the mobile device 130 without downloading an application to the mobile device 130. For example, the modules may be configured to generate a remote resource address for a particular user / user account, provide the remote resource address to the mobile device 130, and in response to the mobile device 130 navigating to the remote resource address, provide a payload to the server computer 120 to cause the server computer 120 to provision a token on the digital wallet 140 of the mobile device 130. The specific functionality of each module will be discussed in more detail below in conjunction with Figures 6A-7D Each module's specific functionality will be discussed in more detail.

[0049] The memory 120(n) may be a database or other memory, a physical storage device, or a cloud-based storage device. The memory 120(n) may store, for example, credentials or authentication information associated with one or more credential issuers and / or one or more users. The memory 120(n) may further include registration information associated with the user. For example, a user may be associated with one or more digital wallets. The memory 120(n) may store information pointing to one or more digital wallets of the user.

[0050] The computer-readable medium 120(b) may further include instructions stored thereon that, when executed by the processor 120(a), cause the server computer 120 to perform a method including: receiving, by the server computer, credentials associated with a user account; encrypting, by the server computer, the credentials with an encryption key to generate encrypted credentials, wherein the encrypted credentials are unique to the user account; generating, by the server computer, a payload in the form of a remote resource address, wherein the payload includes the encrypted credentials; generating, by the server computer, an application associated with the remote resource address; transmitting, by the server computer, the application to the mobile device in response to the mobile device navigating to the remote resource address, wherein navigating to the remote resource address on the mobile device triggers the execution of the application on the mobile device without installing the application on the mobile device; receiving, by the server computer, from the mobile device a payload from the application when the application is executed on the mobile device, wherein the application retrieves the payload from the remote resource address; and provisioning, by the server computer, a token associated with the user account on the digital wallet of the mobile device when the application is executed on the mobile device without being installed on the mobile device.

[0051] An example of a mobile device 130 according to some embodiments is shown in Figure 3 . The mobile device 130 may include a processor 130(a) operatively coupled to a computer-readable medium 130(b) (e.g., one or more memory chips, etc.), a memory 130(c), input elements 130(d) such as buttons, output devices 130(e) (e.g., a display, speakers, etc.), and a network interface 130(f). A housing may house one or more of these components.

[0052] The computer-readable medium 130(b) may include instructions or code executable by a processor (e.g., processor 130(a)). The instructions may include instructions for communicating with a server computer, such as server computer 120, to receive a provisioned token, and instructions for any other suitable function as described herein.

[0053] The computer-readable medium 130(b) may include a series of instructions that, when executed, cause the processor 130(a) to communicate with the server computer 120 to receive a message including a remote resource address via a messaging application 130(h). The messaging application 130(h) may be a Short Message Service (SMS) application, a text messaging component of the mobile device 130, or an instant messaging application (e.g., Whatsapp TM)。In some embodiments, the remote resource address can be received by using the input element 130(d) of the mobile device 130 (e.g., a camera), QR code, or barcode scanning. In another example, the remote resource address can be received by the mobile device 130 in a push notification received via the near field communication (NFC) capabilities of the mobile device 130.

[0054] The remote resource address can be provided or otherwise displayed to the user via the output device 130(e) of the mobile device 130. The mobile device 130 can receive a selection of the remote resource address, for example, via the input element 130(d).

[0055] In response to the user navigating to the remote resource address, the mobile device 130 can receive, for example, via the network interface 130(f), an application associated with the credential issuer. The application can be stored, for example, in the memory 130(c) of the mobile device 130 and can be executed by the processor 130(a). Upon execution, the application is deleted from the memory 130(c). In response to the execution of the application, the mobile device 130 can receive, via the network interface 130(f), a token provisioned on the digital wallet application 130(g) of the mobile device 130 from the server computer 120. For example, the digital wallet application 130(g) can provide a digital wallet 140.

[0056] The computer-readable medium 130(b) can also include instructions stored thereon that, when executed by the processor 130(a), cause the mobile device 130 to perform a method, including: receiving, at the mobile device, a message including a remote resource address that includes encrypted user data and is associated with a server computer; receiving, by the mobile device, a selection of the remote resource address; in response to the selection, navigating, by the mobile device, to the remote resource address; in response to the navigation, receiving, by the mobile device, an application; executing, by the mobile device, the application on the mobile device without installing the application, where the application disappears from the mobile device upon execution; in response to executing the application on the mobile device, receiving, by the mobile device, a token from the server computer, where the token is provisioned on the digital wallet of the mobile device; and using, by the mobile device, the token provisioned on the mobile device for a transaction.

[0057] The method 400 according to an example of the present application can be described with respect to Figure 4 this.

[0058] The method 400 enables the server computer to provision a token on a mobile device associated with a user without downloading an application thereon. In a particular example, the method 400 can be used to generate a remote resource address that is configured to cause a lightweight application to execute on the mobile device 130, and the execution of the lightweight application results in the provisioning of a token on the digital wallet of the mobile device.

[0059] In step S402, method 400 may include receiving, by server computer 120, credentials associated with a user account. For example, in connection with a promotion, a resource provider may indicate the users or user accounts to which gift cards are to be sent. The resource provider may transmit to the server computer credentials associated with the user, such as a PAN, CVV, name, address, etc. Alternatively, in connection with a newly created user account, an account issuer may transmit to the server computer credentials associated with the user, such as a PAN, CVV, name, address, etc. The server computer may generate a unique remote resource address for the user as described below. In some instances, in response to a user completing a task, such as creating an account with a resource provider, the user may trigger the credential issuer computer 110 to transmit the user's credentials to the server computer 120.

[0060] In some instances, server computer 120 may present a graphical user interface (GUI) associated with the application generation platform of server computer 120 on mobile device 130. The GUI may include fields for receiving credentials associated with a user account. The GUI may be displayed to the user, for example, via the output device 130(e) of mobile device 130. Mobile device 130 may then transmit the received credentials to the application generation platform, such as to the on-board application 120(d).

[0061] In step S404, method 400 may include encrypting, by server computer 120, the credentials with an encryption key to generate encrypted credentials unique to the user or user account. For example, server computer 120 may implement one or more encryption techniques or generate a hash of the credentials.

[0062] In step S406, method 400 may include generating, by server computer 120, a payload in the form of a remote resource address, where the payload includes the encrypted credentials. Based on the credentials received by server computer 120, the remote resource address may be unique to the user. As an example, server computer 120 may generate a payload hash of the payload and incorporate the payload hash into the remote resource address.

[0063] In step S408, method 400 may include generating, by server computer 120, an application 135 associated with the remote resource address. Application 135 may be, for example, a lightweight application that can be received and executed by mobile device 130. For example, application 135 may be an App Clip TM or an InstantApp TMAfter the application 135 is executed, the application is deleted from the mobile device 130. Thus, the application 135 can be executed on the mobile device 130 without the user having to download the application to the mobile device 130.

[0064] In step S410, the method 400 can include transmitting the application 135 from the server computer 120 to the mobile device 130 in response to the mobile device 130 navigating to a remote resource address. For example, navigating to a remote resource address on the mobile device 130 can trigger the execution of the application 135 on the mobile device without installing the application on the mobile device.

[0065] In step S412, the method 400 can include receiving, by the server computer 120 from the mobile device 130, a payload from the application while the application 135 is being executed on the mobile device 130. For example, the application 135 can retrieve the payload from the remote resource address and transmit the retrieved payload to the server computer 120.

[0066] In some embodiments, step S412 can further include receiving, by the server computer 120, the payload while the application 135 is being executed on the mobile device 130. The server computer 120 can decrypt the encryption credentials in the payload using an encryption key and identify a token associated with the credentials (e.g., a token assigned to a user account).

[0067] In other embodiments, step S412 can also include authenticating the mobile device 130 and the user of the mobile device 130 by the server computer 120. For example, the server computer 120 can transmit instructions to cause the mobile device 130 to display a GUI configured to receive authentication information from the user of the mobile device 130. The server computer 120 can use the authentication information to authenticate the user or can transmit the authentication information to an authentication service for authentication. If the user is authenticated, the server computer 120 can generate a session key to communicate with the mobile device 130 and can transmit the session key to the mobile device 130. Then, the server computer 120 can initialize a session with the mobile device 130 using the session key and can securely retrieve the payload from the remote resource address. In another embodiment, executing the application 135 on the mobile device 130 can create an encrypted (e.g., secure) communication channel between the mobile device 130 and the server computer 120. Thus, via the secure communication channel, the server computer 120 receives the payload from the mobile device 130 and transmits a token to the mobile device.

[0068] In step S414, method 400 may include, when application 135 is executed on mobile device 130 without being installed on the mobile device, provisioning, by server computer 120, a token associated with a user account on digital wallet 140 of mobile device 130. Thus, provisioning the token on digital wallet 140 adds payment capabilities to mobile device 130 using the token. In other instances, provisioning the token on the digital wallet may add certificate or other digital credential capabilities associated with, for example, event or transportation tickets (e.g., concert tickets or airline tickets), commuter cards (e.g., transit cards), vaccination cards, licenses (e.g., digital driver's licenses or professional licenses), identification cards, mobile passports, etc.

[0069] In some embodiments, server computer 120 may transmit instructions to mobile device 130 to cause mobile device 130 to display a GUI to a user requesting to select a digital wallet. For example, a user or mobile device 130 may be associated with multiple digital wallets, such as on different devices or provided by different digital wallet applications. The user may select a particular digital wallet via the GUI, and the selection is transmitted from mobile device 130 to server computer 120. In response, server computer 120 provisions the token on the selected digital wallet.

[0070] In some embodiments, application 135 is configured to disappear from mobile device 130 once the token is provisioned on digital wallet 140. For example, application 135 may be configured with instructions to cause mobile device 130 to delete application 135 from the memory of mobile device 130 when the execution of application 135 is complete.

[0071] An exemplary process 500 for provisioning a token on digital wallet 140 of mobile device 130 and completing a transaction with the token is shown in Figure 5 below.

[0072] In step S502, process 500 may include receiving, at mobile device 130, a message including a remote resource address. The remote resource address may include encrypted user data and may be associated with server computer 120. The remote resource address may be generated by server computer 120 as described above and may be associated with the user.

[0073] In step S504, process 500 may include receiving, at mobile device 130, a selection of the remote resource address. For example, the remote resource address may be displayed as a selectable link or button via mobile device 130. In other options, the user may scan a QR code that directs the browser of mobile device 130 to open a web page displaying the selectable link or button. The user may select the remote resource address by clicking or pressing on the remote resource address or the link or button associated therewith.

[0074] In step S506, process 500 may include navigating, by the mobile device 130, to a remote resource address in response to the selection. For example, a web browser of the mobile device 130 may navigate to the location pointed to by the remote resource address.

[0075] In step S508, process 500 may include receiving, by the mobile device 130, an application 135 in response to the navigation. The application 135 may be received from the server computer 120. In some embodiments, the application 135 is received and temporarily stored in the memory 130(c) or other storage components of the mobile device 130.

[0076] In step S510, process 500 may include executing, by the mobile device 130, the application 135 on the mobile device 130 without installing the application. Additionally, the application 135 may be configured such that the application 135 disappears from the mobile device 130 when executed. For example, the application 135 may include instructions to delete or erase the application 135 from the memory 130(c) of the mobile device 130 by the mobile device 130.

[0077] In step S512, process 500 may include receiving, by the mobile device 130, a token from the server computer 120 in response to executing the application 135 on the mobile device 130. The token may be provisioned on the digital wallet 140 of the mobile device 130.

[0078] In step S514, process 500 may include the mobile device 130 conducting a transaction using the token provisioned on the mobile device 130. For example, using the token in the digital wallet 140, a user may complete a transaction via the mobile device 130 or using a tap-to-pay function of the mobile device 130 at a merchant location. In other instances, the token may cause the mobile device 130 to display a single-use barcode or QR code, e.g., for entry into a sporting event. In another instance, the token may be associated with a digital form of an identification such as a driver's license or with a digital record such as a medical record or vaccination card.

[0079] A method 600 according to an embodiment of the present application may be described with respect to Figure 6A and 6B performed. The method 600 may be executed by one or more components of the credential issuer computer 110, the server computer 120, and the on-board service provider 601. For example, one or more modules of the server computer 120 (e.g., the authentication module 120(c), the on-board module 120(d), the API 120(m), the processing module 120(e), and the notification module 120(f)) may communicate with the credential issuer computer 110 and the on-board service provider 601 to generate a remote resource address and a lightweight application.

[0080] The authentication module 120(c) can be configured to perform one or more functions to authenticate the identity of the credential issuer. For example, the authentication module 120(c) can authenticate the credential issuer based on authentication information associated with the credential issuer. In some embodiments, the authentication module 120(c) can receive credential issuer authentication information from the credential issuer computer 110 and communicate with an external authentication system to authenticate the credential issuer.

[0081] The on-board module 120(d) can be configured to perform one or more functions or processes to generate a remote resource address and a lightweight application or facilitate the generation of a remote resource address and a lightweight application. For example, the on-board module 120(d) can receive user and user account information and credentials used in generating the remote resource address. For example, the on-board module 120(d) can generate a payload that includes the user account information included in the remote resource address. The on-board module 120(d) can also generate a lightweight application, for example, by providing executable code configured to cause the mobile device 130 to extract the payload and transmit the payload to the server computer 120.

[0082] In some embodiments, the steps of method 600 can be performed by an on-board service provider 601, such as an application generation platform. The on-board service provider 601 can be a separate server and communicate with the server computer 120 via a network. In other embodiments, the on-board service provider 601 can be part of the server computer 120 or can be a subsystem of the server computer 120. The on-board service provider 601 can be configured to communicate with the on-board module 120(d) to perform all or part of the functionality of generating the lightweight application and the remote resource address.

[0083] The processing module 120(e) can be configured to communicate with the modules of the server computer 120 and with the on-board service provider 601 to transmit and receive information associated with the remote resource address and the lightweight application.

[0084] The notification module 120(f) can be configured to manage the notification preferences of one or more users. For example, the notification module 120(f) can be associated with a database that stores user notification preferences.

[0085] Method 600 can enable the credential issuer to generate a unique remote resource address and application for a user or user account.

[0086] In step S602, method 600 includes authenticating a credential issuer via an authentication module 120(c) of the online gateway or server computer 120. In some embodiments, the authentication module 120(c) may be executed by a processor 120(a) of the server computer 120, or may be executed by another processor of the server computer 120. The authentication module 120(c) may be configured to authenticate the credential issuer based on credentials provided by the credential issuer computer 110. In some embodiments, the authentication module 120(c) may communicate with an authentication service separate from the server computer 120 to authenticate the credential issuer and / or the credential issuer computer 110.

[0087] In step S604, method 600 includes transmitting a message indicating successful authentication of the credential issuer to the credential issuer computer 110 if the resource provider user is successfully authenticated by the authentication module 120(c).

[0088] In step S606, method 600 may include receiving a selection of the on-board module 120(d) via the credential issuer computer 110. For example, via the credential issuer computer 110, the credential issuer may select the on-board module 120(d) from a list of available applications, tools, or functionality available via the server computer 120.

[0089] In step S608, method 600 includes redirecting communication with the credential issuer computer 110 to the on-board application 120(d). For example, upon successful authentication of the credential issuer, a secure communication channel may be established with the on-board module 120(d). In some embodiments, the on-board module 120(d) may be executed by a processor 120(a) of the server computer 120, or may be executed by another processor of the server computer 120. In some embodiments, the on-board module 120(d) may be provided as a system separate from the server computer 120.

[0090] In step S610, method 600 includes navigating to an application configuration tool of the on-board module 120(d). For example, via a web browser or other interface, the credential issuer computer 110 may access and interact with the application configuration tool of the on-board module 120(d), which enables the credential issuer to establish a remote resource address and application unique to a particular user.

[0091] In step S612, method 600 includes presenting a remote resource address web page configured to receive user information and / or credentials from a credential issuer computer 110 for generating a remote resource address and an application. For example, a GUI may be displayed via the credential issuer computer 110, where one or more input fields are configured to receive information associated with a request to generate a remote resource address for provisioning a token on a digital wallet associated with a user.

[0092] In step S614, method 600 includes receiving, at the server computer 120 via the on-board module 120(d), credentials associated with a user account. The user account may be an account of a credential issuer associated with the user (e.g., a bank, a resource provider, or another entity), or may be a third-party account associated with an entity other than the credential issuer associated with the user. The credentials may include a PAN, a CVV, a name, an address, or other identifying information associated with the user account. In some embodiments, the credentials may be in the form of plain text data.

[0093] In step S616, method 600 includes passing the credentials to the API 120(m). In some embodiments, the credentials may be passed to a gateway or an API proxy configured to receive the credentials and a request for generating a remote resource address.

[0094] In step S618, method 600 includes authenticating the request. For example, the API 120(m) may authenticate the credentials and the user account before initiating the generation of the remote resource address. For example, the API 120(m) may communicate with a remote system and / or one or more databases to verify the user account and the credentials.

[0095] In step S620, method 600 includes passing the request for the remote resource address and the credentials to the on-board service provider 601. In some embodiments, the on-board service provider 601 may be provided by an external system or by a subsystem of the server computer 120. The on-board service provider 601 may be associated with the on-board module 120(d). In some embodiments, the on-board module 120(d) is provided by the on-board service provider 601.

[0096] In step S622, method 600 includes transmitting the request for the remote resource address and the credentials to the processing module 120(e). In some embodiments, the processing module 120(e) is associated with an additional external system or is executed by a subsystem of the server computer 120. In some embodiments, the processing module 120(e) is an application of the on-board service 601.

[0097] In step S624, method 600 includes requesting application configuration information from an on-board service provider 601 by processing module 120(e). The application configuration information can be, for example, executable code or configuration data associated with a remote resource address and / or desired characteristics of the application. Such executable code can include code or code fragments associated with tasks to be performed by the application (e.g., provisioning of tokens). The configuration data can include, for example, a desired encryption level for credentials.

[0098] In step S626, method 600 includes receiving application configuration information from an on-board service provider 601 by processing module 120(e).

[0099] In step S628, method 600 includes creating a unique request ID associated with a request from a credential issuer computer 110 for a remote resource address associated with a user. The unique ID can be used, for example, to troubleshoot any request errors or errors in generating the remote resource address and / or application.

[0100] In step S630, method 600 includes encrypting a payload. The payload can include, for example, one or more of credentials, a request ID, user account information, or a combination thereof.

[0101] In step S632, method 600 includes creating a hash of the encrypted payload by processing module 120(e).

[0102] In step S634, method 600 can include determining whether notifications are enabled for a request. For example, the method can include checking whether the user has contact information, such as a phone number or email address, and whether a preference for a type of notification is indicated. For example, an indication of whether notifications are enabled for a request can be received as part of the application configuration information. When notifications are enabled, the user can receive push notifications to mobile device 130 via text or email, where the notifications are associated with the provisioned tokens.

[0103] Now referring to Figure 6B which is a continuation of method 600, if notifications are enabled, method 600 can include optional steps S638 - S642. For example, in step S638, method 600 can include, for example, retrieving a phone number associated with a user account from a database and generating a hash of the phone number. Similarly, in step S640, method 600 can include, for example, retrieving an email address associated with a user account from a database and generating a hash of the email address.

[0104] If user account information, such as a telephone number and an email address, is lost or incorrect, then at step S642, method 600 may include generating an error that is communicated to the airborne service provider 601. Subsequently, the airborne service provider 601 may, for example, transmit a notification indicating that the user account contact information is unavailable or incorrect to the credential issuer computer 110. In some embodiments, the airborne service provider 601 may generate a push notification to request the user provider to be provided to the user via the mobile device 130, or update the contact information associated with the user account.

[0105] At step S644, method 600 includes storing, by the processing module 120(e), the encrypted payload, the payload hash, and optionally the telephone number hash and the email address hash.

[0106] At step S646, method 600 may include generating, by the processing module 120(e), a remote resource address. For example, the stored information, such as the encrypted payload, may be used to generate the remote resource address. Additionally, in some embodiments, the encrypted payload may be included in the remote resource address. As an example, the remote resource address may be in the following format: The remote resource address may be in the following format: "https: / / <domain> / dlink / push?payloadHash=xyz123...” or "https: / / <domain> / dlink / push?payload=ehij12hj....”。

[0107] In step S648, method 600 includes determining by processing module 120(e) whether notifications are enabled and, if notifications are enabled, transmitting a notification based on the indicated preferences.

[0108] In optional step S650, method 600 may include transmitting a remote resource address to verification module 120(f) for testing. Verification module 120(f) may verify the remote resource address, e.g., by testing that the remote resource address correctly points to an associated lightweight application configured to extract the payload and transmit it to server computer 120.

[0109] If the remote resource address is verified, verification module 120(f) may transmit a verification notification to processing module 120(e) in step S652.

[0110] In step S654, method 600 may include transmitting a notification status from processing module 120(e) to the on-board service provider 601. The notification status may indicate the successful creation of a remote resource address associated with the user account.

[0111] In step S656, method 600 may include the on-board service provider 601 transmitting a status notification to on-board module 120(d).

[0112] In step S658, method 600 may include on-board module 120(d) displaying the status (e.g., "success") and the remote resource address via the credential issuer computer 110.

[0113] Thus, method 600 may enable the credential issuer to generate a unique remote resource address for a user or user account. The remote resource address may include a payload and may enable a lightweight application to be received and executed by the user's mobile device 130. Execution of the application may transmit the payload to server computer 120, enabling the server computer to provision a token on digital wallet 140 of mobile device 130. This process is described in detail below.

[0114] An exemplary method 700 for provisioning a token on mobile device 130 without downloading an application to mobile device 130 is in Figures 7A through 7D shown in. Method 700 may be performed by one or more components of mobile device 130, server computer 120, and on-board service provider 601. For example, one or more modules of server computer 120 (e.g., push SDK module 120(k), upgrade authentication module 120(g), payment SDK module 120(h), and backend 120(h)-ⅰ, B2CIAM module 120(j), processing module 120(e), and DMS module 120(i)) may communicate with mobile device 130 and on-board service provider 601 to provision tokens on digital wallet 140 of mobile device 130.

[0115] The upgrade authentication module 120(g) may be configured to provide security to the provisioning process. For example, the upgrade authentication module 120(g) may be used to generate a one-time password (OTP) to further authenticate the user of mobile device 130 before provisioning credentials. In another embodiment, the upgrade authentication module 120(g) may request and verify other user information, such as biometric information.

[0116] The payment SDK module 120(h) and the payment SDK module backend 120(h)-i may be configured to perform one or more functional processes to generate tokens for provisioning to mobile device 130. For example, the payment SDK module 120(h) and backend 120(h)-i may communicate to generate tokens based on the received payload information.

[0117] The DMS module 120(i) may perform one or more processes or functions to manage the content provided to mobile device 130. For example, the DMS module 120(i) may generate one or more push notifications and transmit them to mobile device 130. The push notifications may be configured to cause mobile device 130 to display one or more GUIs to the user.

[0118] The B2CIAM module 120(j) may be configured to provide access management to one or more modules of server computer 120. For example, the B2CIAM module 120(j) may control access of mobile device 130 or the user of mobile device 130 to one or more APIs associated with server computer 120.

[0119] The push SDK module 120(k) may provide the functionality of push-provisioning tokens to mobile device 130. For example, the push SDK module 120(k) may be configured to receive tokens and token information and provision the tokens on the selected digital wallet installed on mobile device 130.

[0120] Method 700 can be initiated in response to the mobile device 130 receiving a remote resource address. The remote resource address can be received by the input device 130(d) of the mobile device 130. For example, the remote resource address can be received as a text message by scanning a QR code, or as a push message received via the NFC capabilities of the mobile device 130.

[0121] In step S701, method 700 includes navigating to the remote resource address. For example, the remote resource address can be displayed to the user via the display of the mobile device 130. The user can select or click on the remote resource address to cause, for example, the web browser application of the mobile device 130 to navigate to the remote resource address.

[0122] In step S702, method 700 includes obtaining the application 135 of the mobile device 130. For example, the application 135 can be temporarily stored in the memory 130(c) of the mobile device 130, where the application is stored and executed.

[0123] In step S703, method 700 includes registering the mobile device 130 with the DMS module 120(i) of the server computer 120. Registering the mobile device 130 can include assigning a device ID to the mobile device 130.

[0124] Upon successful registration, in step S704, method 700 can include transmitting the assigned device ID from the DMS module 120(i) to the application 135 on the mobile device 130. In some embodiments, the DMS module 120(i) can also transmit an authentication request, which can prompt the user to enter authentication information in the application 135. The authentication information can include a username / password combination, biometric information, PIN, or other information that can be used to verify the user's identity.

[0125] In step S705, method 700 can include transmitting the authentication information to the DMS module 120(i).

[0126] In step S706, method 700 can include generating a session key by the DMS module 120(i), and in step S707, transmitting a session access token to the application 135 on the mobile device 130.

[0127] In step S708, method 700 can include generating a session key by the application 135 using the session access token, and in step S709, the application 135 initializes a session using the session key via the push SDK module 120(k). The push SDK module 120(k) can include one or more tools or functionality to enable the application 135 to establish a secure communication channel with the server computer 120.

[0128] In step S710, the push SDK application 120(k) can communicate with the consumer identity and access management (B2CIAM) module 120(j) to authorize a session. Subsequently, in step S711, the B2CIAM module 120(j) can communicate with the processing module 120(e) to authorize a session with the processing module 120(e). In some embodiments, the B2CIAM module 120(j) can enable the server computer 120 to manage user identities such that the user of the mobile device 130 can be authenticated to a session between the application 135 and the server computer 120.

[0129] In step S712, method 700 includes communicating with the on-board service provider 601 to obtain details of the application 135. The application details can be stored in the database of the on-board service provider 601 and can indicate, for example, tasks to be completed by executing the application 135.

[0130] In step S713, method 700 includes: if the application details are successfully retrieved, transmitting a success status notification from the on-board service provider 601 to the processing module 120(e).

[0131] In step S714, method 700 includes generating a random number by the processing application 120(e), which is transmitted to the B2CIAM module 120(j) in step S715 and then to the application 135 in step S716.

[0132] In response to receiving the random number, in step S717, the application 135 can generate a welcome screen to be displayed to the user via the display of the mobile device 130. The welcome screen can be displayed, for example, as part of executing the application 135.

[0133] In step S718, the application 135 can read an encrypted payload included in the remote resource address. For example, reading the encrypted payload can include decrypting the payload using an encryption key to obtain plaintext data. The plaintext data can include credentials associated with the user's user account.

[0134] In step S719, the method can include transmitting the plaintext data to the B2CIAM module 120(j) and then transmitting the plaintext data to the processing module 120(e) in step S720.

[0135] In step S721, based on the received plaintext data, processing application 120(e) may request application configuration information associated with application 135 from the on-board service provider 601. The on-board service provider 601 may, for example, query a database to obtain the application configuration information associated with the remote resource address, and in step S722, may transmit the application configuration information to the processing module 120(e). In some embodiments, the configuration information may include technical capabilities or licenses associated with the mobile device 130.

[0136] Proceed to Figure 7B , which describes additional steps of method 700. In step S723, the retrieved information may be transmitted from the processing module 120(e) to the B2CIAM module 120(j), and subsequently in step S724 transmitted to the application 135.

[0137] In some embodiments, if the configuration information is not located in step S721, method 700 may include optional step S725, which generates a "feature not supported" error indicating that the mobile device 130 does not support push provisioning.

[0138] In step S726, method 700 may include transmitting the received random number and device information associated with the mobile device 130 to the B2CIAM module 120(j), and then in step S727 transmitted to the processing application. In some embodiments, the transmitted data may include an encrypted or decrypted payload. The device information may indicate, for example, the model, operating system, configuration, etc. of the mobile device 130.

[0139] In step S728, the processing module 120(e) may request application configuration information from the on-board service provider 601. In step S729, the on-board service provider 601 may provide the retrieved application configuration information to the processing module 120(e).

[0140] In step S730, the processing module 120(e) may analyze the configuration information to determine whether the lightweight application function is enabled on the mobile device 130.

[0141] If the lightweight application function is not enabled on the mobile device 130, method 700 may include optional steps S731 and S732. For example, in step S731, the processing module 120(e) may transmit an error message to the B2CIAM module 120(j), which in step S732 transmits the error message to the application 135. The error message may be displayed to the user via the display of the mobile device 130 and may indicate that the mobile device 130 does not have provisioning functionality.

[0142] In step S733, method 700 includes transferring the encrypted SDK payload from processing module 120(e) to B2CIAM module 120(j), and in step S734, transferring the encrypted SDK payload from B2CIAM module 120(j) to application 135.

[0143] In response to receiving the encrypted SDK payload, in step S735, application 135 may generate a request for a list of one or more digital wallets supported for provisioning on mobile device 130 and transmit the list to push SDK module 120(k). In step S736, push SDK module 120(k) may transmit the request to B2CIAM module 120(j).

[0144] In step S738, processing module 120(e) may request application configuration information associated with application 135 from an on-board service provider 601. The on-board service provider 601 may, for example, query a database to obtain application configuration information associated with a remote resource address and, in step S739, may transmit the application configuration information to processing module 120(e). In some embodiments, the configuration information may include technical capabilities or permissions associated with mobile device 130.

[0145] In some embodiments, in step S740, processing module 120(e) may verify the configuration information. Verifying the configuration information may include, for example, determining a list of digital wallets available for a user account or installed on mobile device 130.

[0146] In step S741, the list is transmitted to B2CIAM module 120(j), and in step S742, the list is transmitted from B2CIAM module 120(j) to push SDK module 120(k).

[0147] In step S743, push SDK module 120(k) may transmit the digital wallet list to B2CIAM module 120(j), and in step S744, as Figure 7C shown, the push SDK module transmits the list to processing module 120(e). Processing module 120(e) transmits a response to B2CIAM module 120(j) in step S745, the response is transmitted to push SDK module 120(k) in step S746, and the response is further transmitted to application 135 in step S747.

[0148] In step S748, method 700 may include displaying, by mobile device 130, a GUI listing one or more digital wallets available for the user to provision tokens. In step S749, the user may select a digital wallet (e.g., digital wallet 140) from the displayed list.

[0149] In step S750, the method may include initializing an access token with an upgrade authentication module 120(g). The upgrade authentication module 120(g) may be, for example, an additional security layer configured to authenticate a user before provisioning a token. In step S751, the upgrade authentication module 120(g) may verify the access token and transmit a response message to the application 135.

[0150] In step S752, method 700 may include the application 135 transmitting the encrypted SDK payload received in step S734. The upgrade authentication module 120(g) may further authenticate the user, for example, by providing a one-time password (OTP) or other multi-factor authentication (MFA) method to authenticate the user. In step S753, the upgrade authentication module 120(g) may transmit the authentication result to the application 135.

[0151] If the user is successfully authenticated, method 700 may proceed to step S754, where the application 135 transmits information indicating the selected digital wallet 140 to the push SDK module 120(k). The push SDK module 120(k) generates a request for a token to be provisioned on the digital wallet 140 and transmits the request to the B2CIAM module 120(j) in step S755. In step S756, the B2CIAM module transmits the request to the processing module 120(e).

[0152] In step S757, the processing module 120(e) receives the request and determines that the request is associated with the application 135 executing on the mobile device 130.

[0153] In some embodiments, method 700 may include optional steps S758 - S761. In step S758, the method may include the processing module 120(e) verifying that the user has been successfully verified by the upgrade module 120(g). If the user has not been successfully verified, the processing module 120(e) may transmit an error message to the B2CIAM module 120(j) in step S759. In step S760, the B2CIAM module 120(j) may transmit the error message to the push SDK module 120(k), and the push SDK module transmits the error message to the application 135 in step S761. In response to receiving the error message, the application 135 may generate a GUI including the error message and display the GUI on the mobile device 130.

[0154] In step S762, the processing module 120(e) may request a push payload from the Issuer and Consumer Services (ICS) module 120(l). The ICS module 120(l) may generate the push payload and, in step S763, transmit the push payload to the processing module 120(e). In step S764, the processing module 120(e) transmits the push payload to the B2CIAM module 120(j), which in turn transmits the push payload to the Push SDK module 120(k) in step S765.

[0155] The Push SDK module 120(k) may tokenize the push payload and, in step S766, may transmit the tokenized push payload to the Payment SDK module 120(h). Simultaneously or in concert, the Payment SDK module 120(h) may receive, in step S767, confirmation from the mobile device 130 that the user wishes to complete the provisioning process.

[0156] In step S768, method 700 includes transmitting the tokenized push payload from the Payment SDK module 120(h) to the backend system of the Payment SDK module 120(h)-i. The backend system of the Payment SDK module 120(h)-i may include, for example, additional functionality that is not directly accessible by the mobile device 130. In step S769, one or more processes of the backend system of the Payment SDK module 120(h)-i may verify the tokenized payload and transmit a token including the tokenized payload to the Payment SDK module 120(h). In turn, in step S770, the Payment SDK module 120(h) transmits the token to the Push SDK module 120(k), which provisions the token on the mobile device 130 via the application 135 in step S771. For example, the token may be provisioned on the selected digital wallet 140.

[0157] In step S772, the application 135 may display a message to the user indicating successful provisioning of the token on the digital wallet 140. In some embodiments, the application 135 may be automatically deleted from the memory 130(c) of the mobile device 130 upon completion of method 700. Once the token is provisioned, the token may be used to complete a transaction or gain access to restricted resources or locations using the mobile device 130.

[0158] Figure 8A and 8B A screenshot of a mobile device (e.g., mobile device 130) performing a process using a remote resource address according to some embodiments is shown. The QR code screen 810 (or web browser screen 815), partial screens 820 and 830, welcome screen 840, notification screen 850, and confirmation screen 860 may be shown as performing a process of provisioning a payment card or other credential (i.e., plaintext user data) into a digital wallet (e.g., digital wallet 140).

[0159] The mobile device 130 may display the QR code screen 810. The QR code screen 810 may be displayed after the user scans a QR code including a remote resource address using the camera or sensor of the mobile device 130. The remote resource address may include encrypted user data having encryption of a payment card such as a PAN, expiration date, etc.

[0160] In another embodiment, the mobile device 130 may display a selectable hyperlink 825 or button 835. The user may navigate to the link 825 or button 835 to access the remote resource address. In some embodiments, the hyperlink may be the remote resource address itself.

[0161] The remote resource address may be associated with the server computer 120 and may be generated in response to a request from the credential issuer computer 110 to generate a remote resource address for the user. The remote resource address may also include configuration information for starting an application 135 or a part of the application 135 for performing a process of provisioning a payload (a part of the plaintext user data) into the digital wallet 140 of the mobile device 130. The user may click the open button 802 to start a part of the application 135, thereby transmitting the payload to the server computer 120 and receiving, in response, a token provisioned on the digital wallet 140.

[0162] The mobile device 130 may display the partial screens 820 and 830 when the open button 802 is clicked. The partial screen 820 may include an input field configured to receive information for authenticating the mobile device 130 or the user. In the partial screen 820, the user may provide an email address 812 to continue the push provisioning. In the partial screen 830, the user may enter an email address. The user may select the continue button 814 to continue the push provisioning of the token.

[0163] In some embodiments, the mobile device 130 may display a wallet screen 840. The wallet screen 840 may provide an add wallet button 832 that enables a user to complete provisioning a payload (e.g., a payment card) on the digital wallet 140. The wallet screen 840 may also display payload information 834. In this example, the payload information may include a value that may be associated with a plaintext credential (e.g., an account number), such as twenty dollars. When the user clicks the add wallet button 832, the mobile device 130 may launch a notification screen 850.

[0164] The mobile device 130 may display a notification screen 850. The notification screen 850 may display a notification confirming that the payload will be shared with the digital wallet 140. When the user clicks or selects the consent button 842A from the notification 842, the mobile device 130 may display a confirmation screen 860 with details about the payment card added to the digital wallet 140.

[0165] The disclosed embodiments present several advantages over current provisioning techniques. For example, the disclosed systems and methods enable a user to provision a credential on a digital wallet without the need to download and install an application on their mobile device. This improves the user experience and facilitates seamless integration of functionality into the mobile device.

[0166] For example, by avoiding the need to download and install an application, a lightweight application enables a user to provision a credential without being limited by a lack of available memory on the mobile device. In other examples, the lightweight application fetched and executed by the mobile device enables a user to provision a credential on the mobile device without administrator approval. In another example, the disclosed systems and methods enable a user to provision a credential on a digital wallet even if the user has limited bandwidth or limited available data usage.

[0167] In addition, the disclosed embodiments improve user privacy and increase user data protection. For example, when an application is downloaded on a user device, information about the user of the user device is shared with a resource provider or an entity that manages the application. Therefore, unless absolutely necessary, a user may be reluctant to download any application on their user device. The disclosed embodiments reduce the risk of privacy loss or data leakage because a user can provision a credential on a digital wallet without downloading an application and without having to accept terms of use before provisioning the credential. Thus, the embodiments provide improved data security and prevent sharing of personal information with third parties against the will of the personal information owner. Thus, the embodiments allow compliance with domestic and foreign data privacy laws and regulations (e.g., the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA)).

[0168] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language, such as Java, C++, or Perl, which uses 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 random access memory (RAM), read-only memory (ROM), magnetic media (such as a hard disk drive or a floppy disk), or an integrated circuit package memory (such as flash memory or a solid-state storage device), or optical media (such as a CD-ROM). Any such computer-readable medium may reside on or within a single computing device and may be present on or within different computing devices within a system or network.

[0169] Although certain exemplary embodiments have been described in detail and shown in the drawings, it is to be understood that such embodiments are merely illustrative of the invention and are not intended to limit the invention, and the embodiments are not limited to the specific arrangements and structures shown and described, as various other modifications may occur to those of ordinary skill in the art.

[0170] As used herein, unless expressly indicated to the contrary, the use of "a / an" or "the" is intended to indicate "at least one".< / domain> < / domain>

Claims

1. A method, comprising: receiving, by a server computer, credentials associated with a user account; encrypting, by the server computer, the credentials with an encryption key to generate encrypted credentials, wherein the encrypted credentials are unique to the user account; generating, by the server computer, a payload in the form of a remote resource address, wherein the payload includes the encrypted credentials; generating, by the server computer, an application associated with the remote resource address; transmitting, by the server computer, the application to a mobile device in response to the mobile device navigating to the remote resource address, wherein navigating to the remote resource address on the mobile device triggers execution of the application on the mobile device without installing the application on the mobile device; receiving, by the server computer, from the mobile device, the payload from the application when the application is executed on the mobile device, wherein the application retrieves the payload from the remote resource address; and provisioning, by the server computer, a token associated with the user account on a digital wallet of the mobile device when the application is executed on the mobile device without being installed on the mobile device.

2. The method according to claim 1, further comprising: presenting, by the server computer, a graphical user interface associated with an application generation platform of the server computer on the mobile device, wherein the graphical user interface includes a field for receiving the credentials associated with the user account, and wherein the application generation platform receives the credentials from the graphical user interface.

3. The method according to claim 1, wherein receiving the payload from the application further comprising: receiving, by the server computer, the payload when the application is executed on the mobile device; decrypting, by the server computer, the encrypted credentials in the payload with the encryption key; identifying, by the server computer, the token associated with the credentials; receiving, by the server computer, a selection of the digital wallet from the mobile device; and provisioning, by the server computer, the token on the digital wallet.

4. The method according to claim 1, wherein provisioning the token on the digital wallet increases payment capabilities on the mobile device using the token.

5. The method according to claim 1, further comprising: generating, by the server computer, a payload hash of the payload; and incorporating, by the server computer, the payload hash into the remote resource address.

6. The method according to claim 1, wherein the application is a lightweight application configured to support provisioning of the token on the digital wallet.

7. The method according to claim 1, wherein receiving the payload from the application further comprising: authenticating, by the server computer, the mobile device and a user of the mobile device; generating, by the server computer, a session key to communicate with the mobile device; The session key is transmitted to the mobile device by the server computer; The server computer initializes a session with the mobile device using the session key; and The server computer retrieves the payload from the remote resource address.

8. The method according to claim 1, wherein navigating to the remote resource address on the mobile device executes the application on the mobile device.

9. The method according to claim 1, wherein the application is configured to disappear from the mobile device once the token is provisioned on the digital wallet.

10. The method according to claim 1, wherein executing the application on the mobile device creates an encrypted communication channel between the mobile device and the server computer, wherein the server computer receives the payload from the mobile device via the encrypted communication channel and transmits the token to the mobile device.

11. A server computer, comprising: One or more processors; and A computer-readable medium comprising code executable by the one or more processors to perform steps, the steps comprising: Receiving credentials associated with a user account; Encrypting the credentials with an encryption key to generate encrypted credentials, wherein the encrypted credentials are unique to the user account; Generating a payload in the form of a remote resource address, wherein the payload includes the encrypted credentials; Generating an application associated with the remote resource address and the encrypted credentials; Transmitting the application incorporating the remote resource address to the mobile device in response to the mobile device navigating to the remote resource address, wherein navigating to the remote resource address on the mobile device triggers execution of the application on the mobile device without installing the application on the mobile device; When the application is executed on the mobile device, receiving the payload from the application on the mobile device, wherein the application retrieves the payload from the remote resource address; and When the application is executed on the mobile device without being installed on the mobile device, provisioning a token associated with the user account on the digital wallet of the mobile device.

12. The server computer according to claim 11, wherein receiving the payload from the application further comprises: Receiving the payload when the application is executed on the mobile device; Decrypting the encrypted credentials in the payload using the encryption key; Identifying the token associated with the credentials; Receiving a selection of the digital wallet from the mobile device; and Provisioning the token on the digital wallet.

13. The server computer according to claim 11, wherein the code further performs steps when executed by the one or more processors, the steps comprising: Generating a payload hash of the payload; and Incorporating the payload hash into the remote resource address.

14. The server computer according to claim 11, wherein the application is a lightweight application configured to support provisioning of the token on the digital wallet and further configured to disappear from the mobile device once the token is provisioned on the digital wallet.

15. The server computer according to claim 11, wherein receiving the payload from the application further comprises: authenticating the mobile device and the user of the mobile device; generating a session key for communicating with the mobile device; transmitting the session key to the mobile device; initializing a session with the mobile device using the session key; and fetching the payload from the remote resource address.

16. The server computer according to claim 11, wherein navigating to the remote resource address on the mobile device executes the application on the mobile device.

17. The server computer according to claim 11, wherein executing the application on the mobile device creates an encrypted communication channel between the mobile device and the server computer, wherein the server computer receives the payload from the mobile device via the encrypted communication channel and transmits the token to the mobile device.

18. A method, comprising: receiving, at a mobile device, a message including a remote resource address that includes encrypted user data and is associated with a server computer; receiving, by the mobile device, a selection of the remote resource address; navigating, in response to the selection, by the mobile device to the remote resource address; receiving, in response to the navigation, an application by the mobile device; executing, by the mobile device, the application on the mobile device without installing the application, wherein the application disappears from the mobile device when executed; receiving, in response to executing the application on the mobile device, a token by the mobile device from the server computer, wherein the token is provisioned on a digital wallet of the mobile device; and using, by the mobile device, the token provisioned on the mobile device for a transaction.

19. The method according to claim 18, further comprising: establishing, when executing the application on the mobile device, an encrypted communication channel between the mobile device and the server computer, wherein the mobile device receives the token from the server computer via the encrypted communication channel.

20. The method according to claim 18, wherein the application is a lightweight application configured to support provisioning of the token on the digital wallet.

Images