User device with core applet and custom package api

Abstract

A user device is disclosed. The user device includes a processor and a memory. The memory includes a core applet, an API interface, and a customized software package. The customized software package communicates with the core applet via the API interface. Another embodiment of invention includes a method comprising: obtaining a user device comprising a processor, and a memory comprising a core applet, an API interface, and a customized software package, wherein the customized software package communicates with the core applet via the API interface; and interacting the user device with an access device.

Description

PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01USER DEVICE WITH CORE APPLET AND CUSTOM PACKAGE APICROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application is a PCT application which claims priority to U.S. provisional application no. 63 / 687,621 , filed on August 27, 2024, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] There are instances where a first party supplies a first type of software and other second parties supply a second type of software for a single device such as an access card. The first type of software may be a common application that provides the core functions the access card. The second type of software may be, for example, a special type of security software to ensure that communication between the access card and an access device (e.g., an access terminal) are secure. In an example, the first party may be an organization that ensures that various components in an access system including the access card and the access device function as intended. The second parties may be manufacturers of the access cards.

[0003] A problem that exists is that each of the second parties may have their own specific implementation the second type of software. For example, the second software type may be software that performs a security operation. The code for the security operation may not be available in a standard library. Therefore, each second party (e.g., each card manufacturer) may have its own software security operation. In this example, a proprietary security API would be required from each card manufacturer for the preparation of an applet such as a JavaCard applet for the access card. Different versions of the applet would be required for different card manufacturers.

[0004] From the perspective of the first party, it is difficult to deliver a common applet for all card manufacturers since it is not interoperable in such situations. It is also time consuming to deliver multiple different versions of the common applet to differentPATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 card manufacturers. There are also logistical and practical difficulties in managing different versions of the common applet.

[0005] Embodiments of the disclosure address this problem and other problems individually and collectively.SUMMARY

[0006] One embodiment is related to a user device comprising: a processor; and a memory comprising: a) a core applet, b) an API interface, and c) a customized software package, wherein the customized software package communicates with the core applet via the API interface.

[0007] Another embodiment of the invention includes a method comprising: obtaining a user device comprising a processor, and a memory comprising a core applet, an API interface, and a customized software package, wherein the customized software package communicates with the core applet via the API interface; and interacting the user device with an access device.

[0008] Another embodiment of the invention includes a method comprising loading, by a computer, a core applet, an API interface, and a customized software package into a memory of a user device, the user device also comprising a processor coupled to the memory; and personalizing, by the computer, the user device with information relating to a user.

[0009] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 shows a block diagram of a user device according to embodiments.

[0011] FIG. 2 shows a diagram illustrating a two package applet creation method according to embodiments.

[0012] FIG. 3 shows a diagram of a user device in the form of a card.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0013] FIG. 4 shows an exemplary interaction process between a user device and an access device.DETAILED DESCRIPTION

[0014] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

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

[0016] A “user device” may include any suitable device that can be operated by a user. For example, a user device can be used to conduct a financial transaction, such as to provide payment credentials to a merchant. Suitable user devices can be hand-held and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). Example user devices may include cards such as smart cards, keychain devices, mobile phones, laptop computers wearable devices, etc. Other examples of user devices include access cards such as payment cards, transit cars, and access badges, smart media, transponders, and the like. If the user device is in the form of a debit, credit, or smartcard, the user device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.

[0017] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment.

[0018] “Interaction data” can include data related to and / or recorded during an interaction. In some embodiments, interaction data can be transaction data of the network data. Transaction data can comprise a plurality of data elements with data values.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0019] An “access device” may be any suitable device that provides access to a remote system. An access device may also be used for communicating with a coordination computer, a communication network, or any other suitable system. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), vending machines, automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like.

[0020] An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a mobile communication or payment device. For example, access devices can have card readers that can include electrical contacts, radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with portable devices such as payment cards.

[0021] An “applet” can include a small program that performs a specific task or tasks. An applet can be embedded within another larger application and has limited functionality. This allows applets to run quickly and reliably without demanding a lot of system resources. An applet can be a Java applet that is written in the Java programming language.

[0022] A “processor” may include a device that processes something. In some embodiments, a processor can include 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 a CPU comprising 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).PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0023] 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.

[0024] A “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. 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.

[0025] A “payment device” may include any suitable device that may be used to conduct a financial transaction, such as to provide payment credentials to a merchant. The payment device may be a software object, a hardware object, or a physical object. As examples of physical objects, the payment 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), and a software object can relate to non-permanent data stored on a device. A payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or a person. Suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). Example payment devices may include smart cards, magnetic stripe cards, keychain devices, etc. Other examples of payment devices include payment cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit, or smartcard, the payment device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0026] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable combination of characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0027] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expiration date, and verification values such as CVV, dCVV, CW2, dCVV2, and CVC3 values.

[0028] An “authorization request message” may be an electronic message that requests authorization for an interaction. In some embodiments, it is sent to a transaction processing computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with International Organization for Standardization (ISO) 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user 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 CW (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, 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 value, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0029] An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. 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 transaction processing computer) to the merchant's access device (e.g., PCS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0030] Embodiments of the invention can include a defined API interface such as a proprietary BDH (Blinded Diffie-Hellman) crypto (cryptography) API interface. In some embodiments, a JavaCard payment applet (an example of a core applet) interfaces with the API interface instead of proprietary API(s) from card manufacturers. In embodiments of the invention, one common interoperable core applet and the API interface can be delivered to many card manufacturers. The card manufacturers can implement the API interface by using their own proprietary crypto library. Card manufacturers can prepare their own customized software packages (e.g., crypto packages) on user devices such as payment cards along with the JavaCard payment applet and the API interface. A final delivery can include one common applet package, the API interface, and a manufacturer created customized software package (e.g., crypto package).

[0031] Instead of building a specific core applet for each card manufacturer that has a different customized software package, embodiments provide two components to each card manufacturer. One component can be a core function package (e.g., a core payment function package) including a core applet, and the other component is an interface package (e.g., a specific cryptographic interface package) including an API interface that is specific to the specific operation to be performed by the customized software package.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0032] As a specific illustrative example, the specific operation discussed herein is a Blinded Diffie-Hellman process. Blinded Diffie-Hellman is a variation of the standard Diffie-Hellman key exchange protocol that adds a layer of privacy by obscuring the public keys during the exchange. This prevents eavesdroppers from linking specific public keys to the participants involved in the exchange, even if they intercept the public key exchange.

[0033] In embodiments of the invention, the core function package can be fixed and can have defined behaviors. The interface package can contain the self-defined API interface for a specific crypto operation. The core function package can call the selfdefined API interface.

[0034] When working with different card manufacturers for the final access card (e.g., final payment card) delivery, each card manufacturer can implement the actual crypto operation using their own crypto method with the crypto interface package.

[0035] By using this proposed two package solution, it is possible to make a core applet package (e.g., a payment applet package that includes a core payment function package including a core applet and a crypto interface package including an API interface) and deliver it (e.g., transmit it) to all the card manufacturers. The entity that provides this common applet package need not create a different core applet package for every card manufacturer, thereby saving time and computing resources.

[0036] FIG. 1 shows a block diagram of a user device 102 according to embodiments. The exemplary user device 102 may comprise a processor 105. The processor 105 may be coupled to a memory 106, input / output elements 114, and a data store 116.

[0037] The memory 106 can include a core applet 108, an API interface 110, and a customized software package 112. The memory 106 can be used to store data and code. The memory 106 may be coupled to the processor 105, and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0038] The data store 116 can include one or more data storage devices that store data such as credentials, tokens, and other user related information. It may also store cryptographic keys, digital certificates, and the like.

[0039] The core applet 108 can include software configured to perform core functionality of the user device 102. The core applet 108 can be a Java applet. The core applet 108 can process interactions (e.g., payment transactions) performed using the user device 102. The core applet 108 can provide payment processing functionality to the user device 102. More specifically, the core applet 108 can be programmed to provide operations including user authentication, data authentication, application selection, application processing, offline risk management, offline data authentication, etc. The core applet 108 can be a Visa Smart Debit Credit (VSDC) application with cryptogram version number (CVN) ’167’26’ (without Kernal 8 - ECC BDH), or equivalent application. The core applet 108 need not provide payment operations. In some embodiments, the core applet can provide access operations which allow a user to access a secure location. Such operations can include verifying an access device identifier, authenticating a user, signing data, etc.

[0040] In some embodiments, the core applet 108 can include a VSDC 3.0 Core package with Kernel 8 Ready, which can utilize platform crypto implementation. The core applet 108 can include a VSDC (Visa Smart Debit Card) 3.0 Core fully certified independent package and can be reused for different platforms.

[0041] The API interface 110 can include exposed functions of the core applet 108. The API interface 110 can include functions that are callable by other software stored in the memory 106. The API interface 110 can allow the core applet 108 to call functions in the customized software package 112.

[0042] The customized software package 112 can include software configured to perform one or more specific operations. The API interface 110 can expose the functions of the customized software package 112 to the core applet 108. The customized software package 112 can communicate with the core applet via the API interface. In some embodiments, the customized software package 112 can implement Blinded Diffie-PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01Hellman cryptographic operations. The customized software package 112 can be created by a manufacturer of the user device 102, and can integrate the core applet 108, the API interface 110, and the customized software package 112 in the user device 102.

[0043] The input / output elements 114 can include elements that allow the user device 102 to send data to and receive data from external devices, such as access devices. The input / output elements 114 can include a contactless electrical connection, a Bluetooth antenna, a near field communication antenna, and / or other communication elements. The input / output elements 114 may comprise a contactless interface, which may comprise an antenna and a chip coupled to the antenna. The contactless interface can allow the user device 102 to communicate with a contactless reader in an access device.

[0044] FIG. 2 shows a diagram illustrating a two package applet creation method according to embodiments. FIG. 2 includes the core applet 108. The core applet 108 can be created by operators of a payment processing network (e.g., Visa). The core applet 108 can include any functionality relating to processing transactions. The core applet 108 can also implement the JavaCard API 202 that can define functions needed to operate in a JavaCard based system.

[0045] FIG. 2 also includes the API interface 110. The API interface 110 can be created by the same entity as the core applet 108. The core applet 108 can implement functions calls to the API interface 110. The functionality of the API can be created in a separate software package that is created by a plurality of different card manufacturers that create the cards (or more broadly, user devices).

[0046] During creation of the cards, the core applet 108 can be provided to each of the plurality of card manufacturers including a card manufacturer A 210, a card manufacturer B 220, and a card manufacturer C 230. Each card manufacturer can be associated with a different JavaCard platform.

[0047] After receiving the core applet 108, each card manufacturer of the plurality of card manufacturers can create a proprietary crypto implementation that is specific to the card manufacturer. Each card manufacturer can create a different cryptoPATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 implementation (e.g., an implementation that creates functionality for blinded Diffie- Hellman cryptographic operations). The proprietary crypto implementation can include methods that implement functionality of the API interface 110.

[0048] For example, the card manufacturer A 210 can create a first proprietary crypto implementation 212. The card manufacturer B 220 can create a second proprietary crypto implementation 222. The card manufacturer C 230 can create a third proprietary crypto implementation 232.

[0049] In some embodiments, the API interface 110 can indicate methods other than blinded Diffie-Hellman related functions. For example, the API interface 110 can indicate methods related to loyalty points, transit processing, data storage, etc.

[0050] In some embodiments, the API interface 110 can provide an interface that can be referred to as VisaBDHKeyAgreementlnterface, or an equivalent interface. The card manufacturer can implement its BDH package (e.g., customized software package 112) based on this API interface. The core applet 108 can call the API interface 110, which will be processed and / or handled by the individual BDH packages.

[0051] After creating the proprietary crypto implementations, each card manufacturer can package the proprietary crypto implementation into a customized software package. For example, the card manufacturer A 210 can create the first customized software package 214, the card manufacturer B 220 can create the second customized software package, and the card manufacturer C 230 can create the third customized software package.

[0052] After packaging the proprietary crypto implementations into a customized software package, each card manufacturer can create cards (e.g., user devices) that include a memory comprising: the core applet 108, the API interface 110, and the customized software package of the card manufacturer. The card manufacturer may load the core applet 108, the API interface 110, and the customized software package into the card. Before or after loading it, the card manufacturer may then personalize the card with information about the user. This may include loading credentials (e.g., primary accountPATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 numbers) and other data onto the card, and then embossing and / or printing information on the card.

[0053] FIG. 3 shows an access card 300, which can include a substrate 302, a chip 308 on the substrate 302, and a magnetic stripe 304 on the substrate. The substrate 302 can also have personalized information 306 such as a name and the credential (e.g., an account number) associated with the access card 300 printed and / or embossed on the access card 300. The chip 308 may include many of the components in the user device 100 shown in FIG. 1.

[0054] FIG. 4 shows a flow diagram of interaction processing between an access device and a user device according to embodiments. In embodiments, a user may obtain a user device 102 as described above and interact it with an access device 104 as described below with respect to FIG. 4. The user of the user device 102 may wish to obtain a resource (e.g., a good or service) offered by a merchant operating the access device 104. Many of the operations of some embodiments of the core applet described above can be found in the description with respect to FIG. 4. The communications shown in FIG. 4 can be protected using encryption using keys. The keys may have been created using the BDH crypto process programmed in the customized software package as described above. Stated differently, certain communications between the user device 102 and the access device 104 may be encrypted with the keys produced by the BDH crypto process.

[0055] At step 401 , a contactless reader of the access device 104 may be configured to identify the presence of a user device 102 within communication range. For example, a contactless interface of the user device 102 may ping or otherwise attempt to find suitable devices to communicate with periodically. When the access device 104 detects the presence of user device 102 in proximity to a contactless reader of the access device 104, for example, an application selection module of the access device 104 may initiate an interaction (e.g., a transaction) by sending a request for available account applets to the user device 102. The request for available applets is sent in order to obtain information regarding which mobile applications and corresponding account applets (e.g.,PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 a list of account applet identifiers) may be available on the user device 102. In some embodiments, the request for available applets 201 may be in the form of a “select proximity payment system environment (PPSE)” command. In such embodiments, the request for available applets 201 may include a payment environment identifier (e.g., a PPSE name such as “2PAY.SYS.DDF01”) to identify the payment environment supported by the access device 104.

[0056] At step 402, upon receiving the available applications request 401 , the user device 102 may identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available applications response 402 back to access device 104. For example, the available applications response 402 may include a list of available account applet identifiers (AIDs), a wallet identifier associated with a mobile application, application configuration options associated with the available AIDs, and / or may include the proximity payment environment identifier (e.g., PPSE name) as the dedicated file name.

[0057] In some embodiments, the available applications response 402 may be in the form of a “select PPSE” response and may include PPSE file control information (FCI). For example, the available applications response 402 may include a directory entry for each available AID on the user device 102 with a wallet identifier associated with each available AID. Each directory entry may include information such as the AID, an application label associated with the AID (e.g., a mnemonic associated with the AID), a wallet identifier (WID) associated with the mobile application, an application priority indicator indicating the priority of the AID, a kernel identifier indicating the application's kernel preference, and / or additional information relating to the particular AID. The available applications response 402 may also include other data such as FCI issuer discretionary data or any other relevant information.

[0058] At step 403, the access device 104 may determine a supported account applet based on the received available applet identifiers and may send an “application selection” command 403 including the selected AID to the user device 102.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0059] Additionally, in some embodiments, upon receiving the application selection message 403, at step 404, the user device 102 may send a terminal transaction data request 404 to request transaction data from access device 104 which may be needed to execute the transaction using the selected application associated with the selected AID. In some embodiments, the terminal transaction data request 404 may be in the form of a “Select AID Response” and may include applet identifier (AID) file control information (FCI) with the selected AID as the dedicated file name. The terminal transaction data request may include a list of transaction data identifiers to request the appropriate data from the access device 104, and the list of transaction data identifiers can be in the form of a processing options data object list (PDOL).

[0060] The transaction data requested by, for example, the mobile application for the transaction may include an entity identifier associated with the access device 104 (e.g., a merchant identifier (MID)), terminal processing options (TPO), authorized amount, other amount, terminal country code, terminal verification results, transaction currency code, transaction data, transaction type, and / or an unpredictable number. The terminal transaction data request may also include other data such as FCI issuer discretionary data, application program identifier, and language preference. In other embodiments, the transaction information may be provided as part of the application selection message 403 and / or as part of the available applications request message 201.

[0061] At step 405, after receiving the terminal transaction data request 404, the access device 104 may send to the user device 102, the terminal transaction data in 405 requested by the mobile application. In some embodiments, the terminal transaction data in 405 may be sent in the form of a get processing options (GPO) command, and may include the requested terminal transaction data in 405 in a processing options data object list (PDOL). In some embodiments, the terminal transaction data in 405 (e.g., Transaction Processing Options (TPO)) may include a TPO indicator that indicates which transaction data types the access device 104 supports.

[0062] At step 406, once the selected applet of the user device 102 receives the terminal transaction data in 405, the user device 102 obtains the relevant accountPATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 credentials from the selected applet as well as any other relevant payment information and may send a set of transaction processing information in 406 including the account credentials and any other relevant transaction processing information to the access device 104. In some embodiments, the transaction processing information in 406 can be sent in the form of a “get processing options” (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used as file addresses by access device 104 to read account data stored on the user device 102, and an application interchange profile (AIP) that can be used to indicate the capabilities of the payment application.

[0063] For example, the transaction processing information may include any credentials for the transaction including a transaction cryptogram generated using transaction information, Track-2 equivalent data, and additional data. The transaction processing information may include issuer application data (IAD), a form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), an application transaction counter (ATC), and / or an application PAN sequence number (PSN). In some embodiments, the issuer application data (IAD) may include a length indicator indicating the length of the IAD, cryptogram version number (CVN) indicating the version of the transaction cryptogram, a derived key indicator (DKI) that can be used to identify a master key (e.g. a master key associated with the issuer), and / or card verification results (CVR).

[0064] It should be understood that in some embodiments, the transaction processing information in 406 being sent from user device 102 to access device 104 may include some or all of the information described above, and in some embodiments, may include additional information not specifically described.

[0065] At step 407, after the access device 104 receives the transaction processing information in 406, the access device 104 may send an account data request 407 to the user device 102 to read additional account data in 408 that may be stored on the user device 102. In some embodiments, the account data request 407 may be in the form of a “read record” command, and may include an application file locator (AFL) indicating the location of the account data that access device 104 is attempting to read. The AFLPATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 included in the account data request 407 may correspond to an AFL in the transaction processing information in 406 that was provided to access device 104 from user device 102.

[0066] At step 408, in response to receiving the account data request 407 from the access device 104, the user device 102 may send the account data in 408 stored at the location indicated by the AFL to access device 104. In some embodiments, the account data in 408 may be sent in the form of a “read record” response. The account data 408 may include, for example, application usage control that indicates the issuer's restrictions on the usage and services allowed for the application, the cardholder's name, customer exclusive data, issuer country code, and / or other account related data that is accessible at the AFL location and is stored in the user device 102.

[0067] It should be understood that in some embodiments, the account data in 408 being sent from user device 102 to access device 104 may include some or all of the information describe above, and in some embodiments, may include additional information not specifically described. Further, any and all of this information may be provided in response to receiving a selection message and / or obtaining payment credentials.

[0068] In some embodiments, after 408, the access device 104 can generate an authorization request message and then provide the authorization request message to a resource provider computer associated with the access device 104. The resource provider computer can provide the authorization request message to a transport computer that can provide the authorization request message to a network processing computer. The network processing computer can provide the authorization request message to an authorizing entity computer. The authorizing entity computer can determine whether or not to authorize the interaction between, for example, the user of the user device 102 and a resource provider of the resource provider computer associated with the access device 104. The authorizing entity computer can generate an authorization response message comprising an indication of whether or not the interaction is authorized.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01

[0069] The authorizing entity computer can provide the authorization response message to the resource provider computer via the network processing computer and the transport computer. In some embodiments, the resource provider computer can provide the authorization response message to the access device which can provide the user device with the indication of whether or not the interaction is authorized. In other embodiments, the resource provider computer can provide the indication of whether or not the interaction is authorized to the user of the user device and / or the user device 102 itself.

[0070] At the end of the day or any other suitable period of time, a clearing and / or settlement process between the relevant parties can take place.

[0071] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention.

[0072] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object- oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0073] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program codePATENTAttorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0074] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0075] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0076] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

PATENTAttorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01WHAT IS CLAIMED IS:

1. A user device comprising: a processor; and a memory comprising: a core applet, an API interface, and a customized software package, wherein the customized software package communicates with the core applet via the API interface.

2. The user device of claim 1 , wherein the user device is a card.

3. The user device of claim 2, wherein the core applet is a Java core applet.

4. The user device of claim 1 , wherein the customized software package is programmed to cause the user device to perform a blinded Diffie-Hellman key exchange protocol.

5. The user device of claim 1 , further comprising a data store coupled to the processor, the data store storing credentials or tokens that allow access to resources.

6. The user device of claim 1 , further comprising: a contactless interface coupled to the processor, the contactless interface configured to allow the user device to communicate with a contactless reader in an access device.

7. The user device of claim 1 , wherein the core applet is programmed to provide functions including user authentication, data authentication, and transaction processing.

8. The user device of claim 1 , wherein the user device further comprises a magnetic stripe and printed information regarding a user of the user device.PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO019. The user device of claim 1 , wherein the core applet is programmed to provide functions including verifying an access device identifier associated with an access device that provides access to a secure location.

10. A method comprising: obtaining a user device comprising a processor, and a memory comprising a core applet, an API interface, and a customized software package, wherein the customized software package communicates with the core applet via the API interface; and interacting the user device with an access device.

11. The method of claim 10, wherein the access device provides access to a resource.

12. The method of claim 10, wherein the customized software package comprises programming to secure communications between the access device and the user device.

13. The method of claim 12, wherein programming includes programing to cause the user device to perform a blinded Diffie-Hellman key exchange protocol.

14. The method of claim 10, wherein the user device is in the form of a card.

15. The method of claim 10, wherein the user device further comprises a contactless interface coupled to the processor, the contactless interface configured to allow the user device to communicate with a contactless reader in the access device.

16. The method of claim 15, wherein the access device and the user device communicate via NFC (near field communications).

17. A method comprising:PATENT Attorney Docket No.: 079900-1507071 Client Reference No.: 9627WO01 loading, by a computer, a core applet, an API interface, and a customized software package into a memory of a user device, the user device also comprising a processor coupled to the memory; and personalizing, by the computer, the user device with information relating to a user.

18. The method of claim 17, wherein the information about relating to the user comprises a credential.

19. The method of claim 17, wherein the user device further comprises a contactless interface coupled to the processor.

20. The method of claim 17, wherein the user device is in the form of a card.

Images