Access server system and method for mapping and coupling of digital assets

Abstract

Disclosed herein are various embodiments for establishing rights and interests using smart contracts and digital wallets. In one implementation, a card corresponding to a consumer and a blockchain wallet account address may be mapped by an access server, where the access server is configured to access a mapping service contract, and where the card includes at least one of an associated personal account (PAN) and an electronic application identifier (eaid) of the consumer.

Description

BACKGROUND

[0001] This section is intended to provide background information to facilitate a better understanding of various technologies described herein. As the title of this section suggests, it is a discussion of technology that is related to the technology described herein. Such technology is related, but it is by no means disclaimed. The related technology can or can not be prior art. It should therefore be understood that statements in this section should be read in this light, and should not be accepted as admissions that the technology described is prior art.

[0002] The global pandemic has required a reevaluation of the way people interact and conduct business. Touchless experiences will be the new normal in the post-COVID world. Current solutions are not fully end-to-end and use separate tools for identity, payment, and access.

[0003] For example, current ticket verification processes utilize manual inspection of images or QR code scans. However, such ticket verification processes are often error prone and can be counterfeited. Thus, there is a need in the art for a system that can provide seamless and secure ticket or voucher verification that will deter ticket scalping and will be “copy proof.” SUMMARY

[0004] Various implementations are described herein for establishing entitlements utilizing smart contracts and digital wallets (e.g., crypto wallets). In one implementation, a card (e.g., EMV card or chip card) corresponding to a consumer and a blockchain wallet account address can be mapped by an access server (i.e., access system) (e.g., Mastercard EZaccess), where the access server is configured to securely access a mapping service contract (i.e., mapping service contract, smart contract protocol) (e.g., Mastercard EZaccess NFT protocol), and where the card includes at least one of a consumer’s (associated) personal account number (PAN) (e.g., payment card number) and an electronic application identifier (eaid) (e.g., Mastercard EzAccess Id).

[0005] In one implementation, a digital wallet can be coupled to an issuer computer system by a consumer device associated with a consumer, where the coupling of the digital wallet includes associating the consumer’s personal account number (PAN) or electronic application identifier (eaid) (e.g., Mastercard EzAccess Id) to the digital wallet.

[0006] In one implementation, a blockchain wallet account address can be provided by a consumer device associated with a consumer to a merchant computer system to map at least one of a personal account number (PAN) and an electronic application identifier (eaid) (e.g., Mastercard EzAccess Id) of the consumer to the merchant computer system.

[0007] The above cited SUMMARY is provided to introduce some aspects of the subject matter described herein in a simplified form that is not intended to be limiting. Additional concepts and various embodiments are described in further detail in the DETAILED DESCRIPTION. This SUMMARY is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter, nor is it intended to be used to limit the number of embodiments described in this document. Furthermore, the claimed subject matter is not limited to implementations that solve any or all of the problems noted in any part of this disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0008] Implementations of the various techniques described herein will be described with reference to the following figures. It should be appreciated that the figures are merely schematic and are not intended to limit the scope of the subject technology.

[0009] Figure 1 A system for providing identity, payment, and access services is illustrated in accordance with implementations of the various technologies described herein.

[0010] Figure 2 A diagram of a system with a service provider and an identifier provider is illustrated in accordance with implementations of the various technologies described herein.

[0011] Figure 3 A diagram of a system for generating hashed primary account numbers (PANs) is illustrated in accordance with implementations of the various technologies described herein.

[0012] Figure 4 A diagram of a system for mapping and coupling of digital assets is illustrated in accordance with implementations of the various technologies described herein.

[0013] Figure 5 An example method that can be implemented with system 400 is illustrated in accordance with implementations of the various technologies described herein.

[0014] Figure 6 An example method that can be implemented with system 400 is illustrated in accordance with implementations of the various technologies described herein.

[0015] Figure 7 A diagram illustrating categories of terminal attestation describing terminals operating within an identity, payment, and access system is illustrated in accordance with implementations of the various technologies described herein.

[0016] Figure 8 FIG. illustrates a diagram of a method for providing identity, payment, and access services according to an embodiment of the various techniques described herein.

[0017] Figure 9 FIG. illustrates a diagram of a method for providing identity, payment, and access services according to an embodiment of the various techniques described herein.

[0018] Figure 10 FIG. illustrates a diagram of a system for providing access to an event according to an embodiment of the various techniques described herein.

[0019] Figure 11 FIG. illustrates an example software package according to an embodiment of the various techniques described herein.

[0020] Figure 12 FIG. illustrates an example object for reading the outcome of an EMV card event according to an embodiment of the various techniques described herein.

[0021] Figure 13 FIG. illustrates a diagram of a system for providing transportation system access according to an embodiment of the various techniques described herein.

[0022] Figure 14 FIG. illustrates a diagram of a hardware architecture of a system for providing identity, payment, and access services according to an embodiment of the various techniques described herein.

[0023] Figure 15 FIG. illustrates a diagram of an employee check-in system using office cubicles according to an embodiment of the various techniques described herein.

[0024] Figure 16 FIG. illustrates a diagram of an employee check-in method using a user's near field chip (NFC) enabled mobile device according to an embodiment of the various techniques described herein.

[0025] Figure 17 FIG. illustrates a diagram of a system for providing employee check-in and employee access according to an embodiment of the various techniques described herein.

[0026] Figure 18 FIG. illustrates a diagram of a high-level view of an identity, payment, and access system according to an embodiment of the various techniques described herein.

[0027] Figure 19 FIG. illustrates a computing system according to an embodiment of the various techniques described herein.

[0028] Figure 20 FIG. illustrates a diagram describing categories of terminal attestation for terminals operating within an identity, payment, and access system according to an embodiment of the various techniques described herein. DETAILED DESCRIPTION

[0029] Advantageously, as described herein, certain inventive aspects incorporate emerging technologies such as smart contracts, blockchains, non-fungible tokens (NFTs), semi-fungible tokens (SFTs), cryptocurrencies, and / or digital wallets, along with digital assets and / or tokens having inventive identity, payment, and access services. Accordingly, inventive systems and methods allow for secure and reliable verification of transactions and validation of entitlements with smart contracts.

[0030] In various aspects, inventive methods provide for entitlements to allow merchants to establish ticketing and / or access to a reservation system, while utilizing a decentralized public blockchain (i.e., blockchain). According to certain embodiments, with reference to Figures 1-4 , an inventive asset discovery system (i.e., access system, access server) 400 is based on a mapping (e.g., coupling) of a consumer’s card (e.g., 105, 305, 310, 315, 404 (as described herein)) to a digital wallet 406 address (e.g., cryptocurrency wallet 406 address). In certain embodiments, the digital wallet 406 can store any number of digital assets 408 and can also include: a token (e.g., loyalty points), a non-fungible token (NFT) (e.g., a ticket and / or voucher), or a semi-fungible token (SFT) (e.g., a loyalty profile with a voucher and loyalty points). In such embodiments, a merchant 420 (i.e., merchant computer system, computer server 420) can issue assets 418 on a public blockchain 414 and list such assets 418 for sale on a marketplace 416. Once purchased, the digital assets will be stored in the consumer’s digital wallet. Moreover, an asset verifier (e.g., a gate or merchant partner that can process loyalty rewards, etc.) will be configured to verify a particular type of asset identified by the blockchain, contract, and / or type identifier. The asset verifier will verify ownership of the address by reading a hashed personal account number (PAN) and / or electronic application identifier (eaid) (e.g., Mastercard EzAccess Id) from the consumer’s card and querying a mapping contract (e.g., smart contract) stored on the public blockchain and securely accessible by the access server 410 (e.g., Mastercard EZaccess). In one operation, the access server (via secure access, control, and / or utilization of the mapping contract) will contact the particular contract to retrieve the existence of the asset from the merchant in the cardholder’s (i.e., consumer’s) account address.

[0031] Advantageously, asset verification can be decoupled from asset issuance, thus allowing for better integration of the processing flow (e.g., a gate will not need to belong to a particular ticket issuer and will only need minimal configuration to verify tickets from different sellers).

[0032] Figure 1 A system 100 for providing identity, payment, and access services is illustrated. Europay, Mastercard, Visa (EMV) is a payment technology standard for providing secure transactions. An EMV card or chip card is a device that includes an embedded secure integrated circuit, which can either be a secure microcontroller with internal memory or an equivalent intelligent device, or a secure memory chip only. The card connects to a reader through direct physical contact or a remote contactless radio frequency interface (e.g., near field communication (NFC)). With the embedded microcontroller, the chip card has the unique ability to securely store large amounts of data, perform its own on-card functions (e.g., encryption and mutual authentication), and interact intelligently with the card reader. All EMV cards are chip cards. Chip cards can be plastic or metal cards with an embedded chip that transmits information to a payment or automated teller machine (ATM) terminal. Chip cards provide increased security.

[0033] The system 100 includes an implementation designed to enable cardholders to easily access value-added services (such as identity, loyalty, and access) in various use cases such as retail, smart cities, travel, and hospitality industries using any EMV contactless card or token.

[0034] The present system provides end-to-end implementation of identity 110, loyalty program 115, and access 120 using EMV standard 105 via, for example, contactless cards, tokens, mobile device digital wallets, wearable devices coupled to mobile devices. Examples related to identity 110 include passports 135, student IDs 130, and user identification 125. Examples related to loyalty 115 include earning points 140 and redeeming points 145. Examples related to access include office buildings and / or co-working space (wework) systems 150, hotels and other types of rental properties 155, and attractions 160 (e.g., travel, sports, or other events). The present system brings an end-to-end, seamless contactless experience by unlocking the hidden potential in existing contactless cards / tokens. Furthermore, in one example, the present system provides seamless and secure ticket or voucher verification, which will deter ticket scalping and counterfeiting.

[0035] Figure 2A diagram illustrating a system 200 with a service provider and an identifier provider. A consumer 205 (e.g., a consumer device) identifies to a service provider 210 or enrolls with an identifier provider 215. In certain embodiments, an access server 220 (i.e., Mastercard EZaccess) provides the service provider 210 with the ability to implement services, such as access control 225, attraction entry 230, and merchant services 235. The access control 225 system provider can include office buildings, hotels, door locks. The attraction 230 can include museums, theaters, zoos, or any other type of attraction. The merchant services 235 can include loyalty and analytics programs. The access server 220 enables the identifier provider 215 to provide student ID 240, ticketing 245, and loyalty identification 250 services.

[0036] In certain embodiments, when a consumer uses an EMV card, fob, or digital wallet with an associated payment card number or primary account number (PAN), the access server 220 is configured to match the consumer’s loyalty program identifier with the consumer’s PAN. In other words, the access server maps / binds the loyalty program identifier to the consumer’s PAN. In other embodiments, as described in the following paragraphs, with reference to Figures 4-6 , the access server 220 matches the consumer’s blockchain wallet account address with the consumer’s PAN or electronic application identifier (eaid) (e.g., Mastercard EzAccess Id).

[0037] Figure 3 A diagram illustrating a system 300 for generating a hashed PAN. Payment card information can be presented in three ways: via a mobile device 305, a wearable device 310, or a contactless EMV card 315. In certain embodiments, as described with reference to Figures 4-6 , the payment card information (as described with reference to Figure 3 ) is presented as a card 404.

[0038] With reference to Figure 3The mobile device 305 can include near field communication (NFC) circuitry and digital wallet software. A digital wallet is a software-based system that securely stores a user's payment information and passwords for various payment methods and websites. By using a digital wallet, a user can easily and quickly complete a purchase, for example, with near field communication technology. The wearable device 310 can also include NFC circuitry and digital wallet software. In an implementation, the terminal 320 reads EMV card information from the EMV card 315 or via the digital wallet of the mobile device 305 or the wearable device 310. The terminal 320 determines the PAN from the EMV card or receives the PAN from the digital wallet of the mobile device or the wearable device. In an implementation, the terminal 320 verifies the authenticity of the card. The terminal 320 generates a hashed PAN and sends the hashed PAN to the access server 330.

[0039] In an implementation, a hashed PAN or digital account number (DAN) is generated using the following method. A salt (Salt) is provisioned to the terminal 320 by the access server 330. The PAN / DAN is read from the EMV card or token. A salt is random data that is used as an additional input to a one-way function that hashes data, a password, or a pass phrase. The salt is used to protect the PAN / DAN. A new salt is randomly generated for each PAN / DAN. In an implementation, the salt and the PAN / DAN (or a version of the PAN / DAN) are concatenated and fed to a cryptographic hash function. The hashed PAN / DAN, e.g., an output hash value (rather than the original PAN / DAN) can be stored in local memory or sent to the access server 330. If the authentication data repository is compromised, the hash allows for later authentication without the need to keep the PAN / DAN and thus without the risk of exposing the PAN / DAN. In an implementation, the PAN / DAN read by the terminal 320 can be 13 to 19 bits. In an implementation, the hashed PAN (PAN | SALT) or the hashed DAN (DAN | SALT) can be generated by a SHA256 hash function. For simplicity, wherever the disclosure describes an implementation related to a PAN, the same method described herein can be applied to a DAN and / or token presented by a mobile and / or wearable device.

[0040] Figure 4A diagram illustrating an asset discovery system 400 that allows for mapping and coupling of digital assets in accordance with embodiments of the various technologies herein. As can be appreciated, instead of using proprietary reservation systems, tickets / entitlements can be represented as non-fungible tokens (NFTs), whereby such NFTs can be sold on a marketplace 416 (e.g., an NFT platform or a basic web3-enabled website). For example, a mapping contract that is securely accessible (and controllable and usable) by an access server 410 (i.e., an access system) (e.g., Mastercard EZaccess) would be configured to represent such tickets as NFTs. In certain embodiments, the access server 410 can be the access server 220 or 330 (refer to Figure 2 and Figure 3 ).

[0041] In one operation, a consumer (via a consumer device 402) would first associate their card 404 (e.g., including a personal account number (PAN) and / or an electronic application identifier (eaid)) (e.g., Mastercard EzAccess Id) with a digital wallet 406 (e.g., a crypto wallet) account address. Next, the consumer would “tap” their card 404 on a verifier terminal 412 (i.e., an asset verifier, gate reader, gate terminal) so that the access server 410 can query the blockchain wallet account address (i.e., the wallet address). In certain embodiments, the gate reader / gate terminal 412 can be the terminal 320 (refer to Figure 3 ). Upon doing so, the access server 410 (e.g., via the accessed smart contract) can search the public blockchain 414 for whether the searched wallet address includes an NFT representing a particular ticket (i.e., entitlement). For example, in certain embodiments, while the mapping contract(s) and associated data can be stored in the public blockchain 414, the access server 410 is configured to invoke functions of the mapping contract on the blockchain 414 to facilitate the lookup.

[0042] In this scenario, advantageously, the mapping service by the access server 410 utilizing a smart contract (e.g., based on using the standard ERC721 contract for merchant passes) provides flexibility for the merchant system 420. In various implementations, a smart contract corresponds to a program or transaction protocol written to a blockchain, which can be configured to execute, control, or record events and actions according to the terms of the contract or agreement. As an advantage, in certain instances, the system 400 will provide flexibility for merchants by using the standard ERC 721 contract for passes, allowing more gateways to directly query the separate blockchain or use the interface of the system 400 (e.g., which can be configured for less integration). Advantageously, by using such a smart contract protocol, the merchant system 420 is able to create a gateways smart contract (i.e., asset contract, digital asset) 418 that is compliant with the mapping service contract (e.g., EZaccess NFT protocol accessed, utilized, and / or controlled by the access server 410 and stored on the public blockchain 414) with the ability for additional functionality, as described herein. As a result, interoperability of the merchant 420 or any other involved entity can be improved.

[0043] In a second example, with reference to a loyalty implementation, by using an NFT as a representation of a loyalty profile, the access server 410 can generate a mapping between an electronic application identifier (eaid) (e.g., Mastercard EzAccess Id) 404 and a loyalty profile (e.g., as described with reference to Figure 1 For example, when the mapped card 404 is “swiped” to a loyalty terminal (e.g., asset verifier 412), the loyalty terminal 412 can query the user’s wallet 406 address to determine if the user owns the loyalty profile NFT. In some implementations, such a loyalty terminal 412 can be the terminal 320 (referenced Figure 3 ). Moreover, in certain instances, a semi-fungible token (SFT) can be utilized instead of an NFT as the loyalty profile representation 418 (e.g., digital asset, asset contract), and with the ability to also hold a loyalty points balance. In one implementation, an SFT as defined in the ERC-1155 multi-token standard allows each token ID to represent a new configurable token type that can have its own metadata, supply, and other attributes. In doing so, the smart contract (i.e., asset contract) 418 will be enabled to accept the fungible portion (e.g., loyalty profile points balance) and non-fungible portion (e.g., loyalty profile identifier) of the loyalty profile representation.

[0044] Figure 5An example method 600 of the asset discovery system 400 is illustrated in accordance with a first embodiment. In one operation, the mapping of asset contracts 418 (e.g., tokens, NFTs, SFTs) by the system 400 is performed prior to purchase. Referring to Figure 4 and Figure 5 At step 510 (S510), at the consumer device 402 (e.g., consumer computer, mobile phone, wearable device), the digital wallet 406 (e.g., crypto wallet, digital asset wallet) can be coupled (connected) to a portal of the issuer 503 (i.e., issuer computer system, issuer server) (e.g., issuer bank portal (website / app) owned by the issuing bank) by which a primary account number (PAN) can be associated to the digital wallet 406. At step 520 (S520), the issuer 503 (i.e., issuer computer system, issuer server) associates the card 404 (e.g., 105) with a blockchain wallet account address (i.e., blockchain address) by accessing (and controlling and using) a mapping service contract (e.g., Mastercard NFT / SFT smart contract) accessible via the access server 410 (e.g., Mastercard EZaccess).

[0045] In this embodiment, in accordance with additional steps, at step 530 (S530), the merchant 420 (i.e., merchant computer system, merchant computer) can generate (e.g., issue) one or more of the asset contracts 418 (i.e., assets, smart contracts) (e.g., tokens, NFTs, SFTs) on the public blockchain 414 (i.e., blockchain). At step 540 (S540), the merchant 420 can set up a marketplace (i.e., digital marketplace 416) on the blockchain 414 to list, sell, and / or transfer the one or more asset contracts 418. Further, at step 550 (S550), at the consumer device 402 (e.g., consumer computer, mobile phone, wearable device), the consumer can acquire (e.g., purchase) the one or more asset contracts 418 and store the asset contract(s) 418 in the digital wallet 406 account (via the blockchain 414).

[0046] Figure 6 An example method 600 of the asset discovery system 400 is illustrated in accordance with a second embodiment. In one operation, the mapping of asset contracts 418 (e.g., tokens, NFTs, SFTs) by the system 400 is performed at asset acquisition. Referring to Figure 4 and Figure 6At step 610 (S610), at a consumer device 402 (e.g., consumer computer, mobile phone, wearable device), the consumer can provide a blockchain wallet account address (i.e., blockchain address) to a merchant 420 (i.e., merchant server, merchant computer system) to map a PAN (personal account number) or eaid (electronic application identifier) (e.g., Mastercard EzAccess Id). At step 620 (S620), the merchant 420 can associate the card 404 (or eaid) with the blockchain address via the mapping service contract 410 (i.e., as accessed (and controlled and used) by the access server) (e.g., Mastercard EZaccess).

[0047] In this implementation, according to additional steps, at step 630 (S630), the consumer 402 can "swipe" (i.e., couple) their card 404 on (or near) a verifier terminal 412 (i.e., asset verifier / authenticator system) (e.g., a kiosk, a reference Figure 3 terminal system 320, a merchant partner that processes loyalty points). By doing so, the verifier terminal 412 will be configured to verify / authenticate the asset or asset type (e.g., as identified by the blockchain 414, contract, and / or type id). Such configuration includes one or more of the following steps: 1) at step 640 (S640), the asset verifier 412 can "read" (e.g., scan, track, process, compute) the PAN (personal account number) or eaid (electronic application identifier) (e.g., Mastercard EzAccess Id) from the card 404; 2) at step 650 (S650), the asset verifier 412 can query (e.g., request, "call") the mapping contract on the access server 410 (e.g., Mastercard EZaccess) with the hashed PAN (e.g., as generated as referenced in the Figure 3 hashed PAN 325) or eaid from the card 404 to the digital asset 408, 418; 3) at step 660 (S660), the mapping contract stored on the access server 410 (e.g., Mastercard EZaccess) can query (e.g., search) the asset contract 418 or asset 408 using the digital wallet account address associated with the PAN or eaid (e.g., Mastercard EzAccess Id); and 4) upon doing so, at step 670 (S670), the asset contract 418 or asset 408 will be verified for the consumer 402 by the mapping contract on the access server 410. In certain implementations, the steps described in the method 600 in reference to Figure 6 may be implemented with the system 300 in reference to Figure 3 .

[0048] In other variations and combinations of the embodiment of the asset discovery system 400, the association of the digital assets 408, 418 to the card 404 involving the access server 410 (i.e., including the accessible mapping contract (i.e., Mastercard NFT smart contract)) would involve the following initial steps: 1) the consumer associates their card 404 (i.e., hashed PAN / eaid) with a digital account 406 (i.e., crypto account) through the smart contract 410 (e.g., Mastercard NFT smart contract); 2) the consumer purchases one or more tickets (i.e., NFTs) as digital assets 418 from a merchant 420 (i.e., smart contract from merchant); 3) the card 404 is coupled (e.g., “swiped”) on a gate 412 (e.g., asset verification terminal).

[0049] However, in a first variation / combination, the additional steps are as follows: 4) the gate 412 would request (e.g., access, control, and / or utilize the Mastercard NFT smart contract) mapping to the NFT ticket of the swiped card 404 by providing the hashed PAN and ticket contract address to the access server 410; 5) the access server 410 (e.g., access, control, and / or utilize the Mastercard NFT smart contract) would “call” (e.g., connect to) the NFT contract 418 (i.e., smart contract from merchant) to find the ticket(s) owned by the wallet address (i.e., blockchain wallet address); and 6) the access server 410 (e.g., access, control, and / or utilize the Mastercard NFT smart contract) would return to the gate 412 a list of tickets owned by the cardholder, and the gate 412 would “check” (i.e., confirm, verify) the tickets and allow entry.

[0050] In a second variation / combination, the additional steps are as follows: 4) the gate 412 would request the ticket service contract 418 (i.e., smart contract from merchant) of the NFT ticket by providing the hashed PAN; 5) the ticket service contract 418 of the NFT ticket would “call” (e.g., connect to) the access server 410 (i.e., via the Mastercard NFT smart contract) with the hashed PAN to find the mapped wallet address; and 6) the access server 410 (e.g., access, control, and / or utilize the Mastercard NFT smart contract) would then find the NFTs owned by the wallet address returned in step 5 and return a list of tickets owned by the cardholder. Upon doing so, the gate 412 would “check” (i.e., confirm, verify) the tickets and allow entry.

[0051] In a third variation / combination, the additional steps are as follows: 4) the gate 412 will "call" (i.e., request) the access server 410 (e.g., via the Mastercard NFT smart contract) with the hashed PAN to find the mapped wallet address(s), and 5) the gate 412 will request the ticket contract 418 of the NFT ticket owned by the wallet address. After doing so, the gate 412 will "check" (i.e., confirm, verify) the ticket and allow entry.

[0052] According to some embodiments, the interface of the contract of the system integrated with the access server 410 (e.g., Mastercard EZaccess) can include:

[0053] pragma solidity ^0.8.17;

[0054] interface MastercardAssetMappingContract {

[0055] / / Asset verifier registers to register verifiers to our Mastercard contract.

[0056] / / This verifier will verify asset tokens.

[0057] function registerVerifier(string memory verifierName) external returns (uint256 verifierIdentifier);

[0058] / / Card-to-account mapping happens when a user registers their card to this program.

[0059] / / This contract will automatically create a mapping to the user's account address on the respective blockchain where the asset resides.

[0060] function mapCardToAccount(string memory hashedPan, address userAccountAddress) external;

[0061] / / Asset retrieval.

[0062] / / Verifiers (gates or any point-of-sale terminals) can directly send requests to this contract to retrieve a list of tokens based on a user's hashed PAN.

[0063] function retrieveAvailableAssets(string memory hashedPan, address assetContract, uint256 chainId) external

[0064] view returns (uint256[] memory tokenIds);

[0065] }

[0066] / / Merchant SFT extension of ERC1155

[0067] interface MerchantSFT is ERC1155 {

[0068] function getTokensOwnedBy(address userAccountAddress) public view returns (uint256[] memory tokenList);

[0069] }

[0070] Figure 7 Figure 7 illustrates a diagram 700 describing four categories of terminal certification for terminals (e.g., terminals 320, asset verification terminals 412, gate 412) operating within the identity, payment, and access system 100 and the asset discovery system 400. Terminals are categorized according to the type of transaction, the type of credential, the type of solution provided, the deployment model version, whether ATC updates are performed, and the type of certification performed. Category 1 terminals provide simple access. Category 2 terminals can be used in a free transportation system. Category 3 terminals can be used to provide secure access, and Category 4 terminals can be used to provide a loyalty program.

[0071] Class 1 terminals provide for simple access. The credential type for this type of system is a hashed PAN. In this implementation, combined dynamic data authentication-application cryptogram generation (CDA) is not required. In this implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) reads the PAN and / or user identifier (UID) from an EMV card, mobile device, or wearable device and provides access. Access can be provided by matching the hashed PAN locally or after verification by a remote access server (e.g., access server 330, 410). Terminals can be provided using a software development kit (SDK), do not require application transaction counter (ATC) updates, and have low certification requirements for the terminal. The ATC is a counter maintained by an EMV card or digital wallet application that provides a sequential reference for each transaction. The ATC is a sequential counter managed by a contactless card or token that is used to ensure that all cryptograms generated are unique. A repeated ATC, a reduction in ATC, or a large jump in ATC values can indicate data duplication or other fraud to the issuer.

[0072] Class 2 terminals provide for access and / or transit systems. The credential for this type of system is a hashed PAN and CDA. Also known as CDA with data authentication, CDA involves including card decisions in data signed by the card’s RSA key (public key or asymmetric key algorithm). In this implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) performs a zero dollar ($0) authorization CDA transaction. The vendor’s terminal is an EMV terminal that implements a full EMV access kernel according to the access terminal specification. In this implementation, ATC updates can be deferred and certification requirements are moderate.

[0073] Class 3 terminals provide for secure access systems. Secure access systems can be for access and / or identification systems. The credential for this type of system is a hashed PAN and CDA. In this implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) performs a zero dollar ($0) authorization CDA transaction. The vendor’s terminal SDK can be one of two types. The first terminal type for this implementation is an EMV terminal that implements a full EMV access kernel according to the access terminal specification. The second terminal type is an SDK that communicates with an EMV access kernel implemented in a cloud point of sale (POS) server. In this implementation, ATC updates can be deferred or provided in real-time and certification requirements are moderate.

[0074] Category 4 terminals provide for loyalty systems. The loyalty systems can be for merchant retail stores and / or payments. The credentials for this type of system are hashed PAN and CDA. In this implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) performs a full EMV transaction from the terminal and / or cloud POS SDK. The vendor's terminal can include a terminal SDK or be hosted by a cloud POS server. In this implementation, the ATC update is provided in real-time and requires full attestation.

[0075] In one implementation, the terminal reads the PAN number by using SELECT PPSE and READ RECORD commands, e.g., for category 1 transactions. In this implementation, the get processing options (GPO) command is not issued. This implementation, while easier to implement, is less secure and susceptible to card cloning or skimming.

[0076] In one implementation, the terminal performs CDA with the GPO command, which will increase the ATC. In this implementation, the access server sends the ATC update to the issuer. This implementation is more secure and ensures that the card / token is authentic.

[0077] In one implementation, the cloud POS server can be leveraged to implement EMV / EA kernel for some use cases to reduce terminal upgrade efforts.

[0078] In one implementation, the NFC data exchange performed by the terminal can be modified to perform READ RECORD followed by GPO. This implementation enables a single click hashed PAN read mode for loyalty systems.

[0079] Figure 8 A diagram of a method 800 for providing identity, payment, and access services is illustrated. The method 800 can be implemented in conjunction with various steps of the system 400 (as referenced in FIG. 4). The method 800 can be implemented by a terminal, such as the terminal 320, the asset verification terminal 412, or the gate 412. Figures 4-6The PAN and / or UID can be read from a contactless card or via a token provided by a digital wallet present on a mobile device (or accessible via a wearable device communicatively coupled to the mobile device). At block 810, if the PAN is read, the terminal generates a hashed PAN. At block 815, the terminal determines a transaction result based on the hashed PAN. In one implementation, the transaction result is determined locally. In one implementation, the transaction result is based on a decision made by an access server (e.g., access server 330, 410). In one implementation, the transaction result is determined by performing an offline match of the hashed PAN and / or UID against a locally stored whitelist. In one implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) sends the hashed PAN and / or UID to a backend server, e.g., access server 330, 410, between the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) and the server, for determination and provision of a decision by the backend server upon matching the received hashed PAN against a whitelist. In one implementation, a service provider, e.g., a provider of identity, payment, and / or access services, can optionally upload transaction data (including UID, hashed PAN, and / or other relevant data) from the terminal to the access server in real-time or as soon as possible (e.g., via the backend server).

[0080] For example, a select proximity payment system environment (PPSE) command can be used to read the card PAN to ensure that the PAN / token from a specific payment processor is read. Once the presentation of the PAN / token from the specific payment processor is verified, a read record command is given to read the PAN / token. The following are example select PPSE and read record commands:

[0081] SELECT PPSE COMMAND: 00B2011400

[0082] READ RECORD COMMAND: 00A4040007A0000000041010

[0083] Proof of the terminal providing method 800 includes testing that the terminal can interact with an EMV card or device (mobile or wearable). Proof also includes testing to verify that the terminal can determine that an EMV card is enabled and that information flow can be shared. Further, proof includes determining that the terminal and access server can implement the transactions and data handling described in method 800.

[0084] Figure 9A diagram illustrating a method 900 for providing identity, payment, and access services is shown. At block 905, a $0 transaction is initiated with an EMV card or token. The EMV card can be a contactless card. Initiating the $0 transaction involves receiving a PAN and other data from the card or token. At block 910, the PAN is determined from the information received via the $0 transaction. At block 915, the card / token is authenticated. In one implementation, the card / token is authenticated using CDA. CDA provides a fast and secure offline card / token authentication protocol and is supported by all contactless cards and tokens. If CDA is successful, a hashed PAN is generated at block 920. At block 925, a transaction result is determined. In one implementation, the transaction result is determined locally. In this implementation, the transaction result is determined by performing an offline match of the hashed PAN against a locally stored whitelist. In another implementation, the transaction result is based on a decision made by a backend server. In this implementation, the hashed PAN is sent to the backend server for a decision about the transaction to be made by the backend server by matching the received hashed PAN against a whitelist. In one implementation, the terminal reads ATC data from the EMV card / token and provides this ATC data to the access server.

[0085] The service provider (e.g., via the backend server) uploads transaction data (including the UID, hashed PAN, and / or other relevant data) from the terminal to the access server in real-time or as quickly as possible. The access server sends an ATC update message to the issuer based on the transaction data received from all service providers. Sending the ATC update message to the issuer notifies the issuer that the ATC has incremented beyond the normal level. Informing the issuer via the ATC update message avoids situations that can result in payment transactions being unexpectedly declined.

[0086] Proof of the terminal providing the method 900 includes testing that the terminal can interact with an EMV card or device (mobile or wearable). Proof also includes testing to verify that the terminal can determine that the EMV card is enabled and that information flow can be shared. Further, proof includes determining whether the terminal and access server can implement the transactions and data handling described in the method 900. In one implementation, an access kernel is provided. In this implementation, proof includes testing to determine whether the access kernel and card / token can communicate the correct information to allow data sharing and allow decisions to be made at the terminal regarding processing.

[0087] Figure 10 is a diagram of a system 1000 for providing access to an event. In certain implementations, the system 1000 can be used with the system 400 (as referenced in FIG. 4) and / or the system 800 (as referenced in FIG. 8). The system 1000 includes a terminal 1002, an access server 1004, and an issuer server 1006. The terminal 1002 can be a point-of-sale terminal, a kiosk, a mobile device, a wearable device, or any other device that can be used to initiate a transaction. The terminal 1002 can be used to initiate a transaction with an EMV card or token. The terminal 1002 can be used to determine a PAN from the EMV card or token. The terminal 1002 can be used to authenticate the EMV card or token. The terminal 1002 can be used to determine a transaction result. The terminal 1002 can be used to provide ATC data to the access server 1004. The terminal 1002 can be used to receive an ATC update message from the access server 1004. The terminal 1002 can be used to provide the ATC update message to the issuer server 1006. Figures 4-6The described) in combination (including replaced elements). The system 1000 includes an EMV card or pass 1005, a gate 1010 including an access kernel 1015 and a gate terminal 1030, a back-end server of a service provider (e.g., a ticketing server 1020), and an access server 1025. At item 1, a visitor purchases a ticket from the ticketing server 1020 via a web-based or app-based transaction. At item 2, after purchasing the ticket, the visitor is presented with the option to use their EMV card or pass 1005 to gain access to the event. After selecting the option to use the EMV card or pass 1005 for access to the event, the user opts-in to the access service and notifies the access server 1025. In one implementation, the transaction details and transaction ID are sent to the user’s email and the transaction ID is embedded into the link to opt-in to the access service. When the link is clicked, the webpage loads along with the transaction ID and the user can enter additional card details, e.g., either from a physical card or from the user’s digital wallet. These hashed PANs and transaction IDs are then sent to the access server 1025. At item 3, the ticketing server 1020 downloads a whitelist (e.g., a list of eligible hashed PANs associated with valid ticket reservation references) to the ticketing server 1020. At item 4, the whitelist is downloaded to the gate 1010. At item 5, when the visitor presents the EMV card / pass at the gate 1010, the PAN / pass is read by the access kernel 1015. The access kernel 1015 generates a hashed PAN and compares the hashed PAN to the downloaded whitelist.

[0088] Figure 11An example SDK 1100 is shown. In particular, the SDK 1100 can be used to implement the terminal 320, 412, etc. and the methods 500, 600, 700. Item 1105 describes an application programming interface (API) that can be exposed for controlling reading of EMV cards. In particular, item 805 describes the following APIs: EzaSDK.init(Context context), EzaSDK.onNewIntent(Activity activity, Intent intent), EzaSDK.onResume(Activity activity, EzaTransactionListener listener), and EzaSDK.stop(). The EzaSDK.init(Context context) API reads relevant configuration data from a default JavaScript Object Notation (JSON) file named AppConfig.ison in the assets resource folder. The EzaSDK.onNewIntent(Activity activity, Intent intent) API specifies that when an Android Intent event occurs, such as when a native NFC card is detected or removed, the SDK will start processing EMV cards. The EzaSDK.onResume(Activity activity, EzaTransactionListener listener) API specifies that when an Android application is started from the background and becomes active, the SDK activates the NFC module. The EzaSDK.stop() API allows the terminal to stop listening for NFC events on the Android device.

[0089] Item 1110 describes the supported configuration fields in AppConfig.json. The fields in item 1110 describe the options available for access control using the SDK. In one implementation, hashedPanSalt is a random string with a suitable length. The salt value is appended to the PAN and hashed to generate a unique EMV card value across different terminals. The terminalMode field can be one of three values: hashedPan, auth, or fullTransaction. When hashedPan is used, the SDK returns the hashed PAN from reading an EMV card. When auth is used, the SDK returns the hashed PAN and transaction data from a $0 authorization. When fullTransaction is used, the SDK requests the transaction amount, performs a full EMV transaction, and returns the outcome of the transaction. The nfcMode field can have an internal or external value. When the internal value is set, the SDK uses the internal NFC module of the host Android device. When the external value is set, the SDK uses an external Universal Serial Bus (USB) NFC driver.

[0090] Figure 12 An example object 1200 for reading the outcome of an EMV card event is illustrated. The outcome of an EMV card event can be achieved by using EzaTransactionListener according to both success or failure methods. All transaction information, whether successful or failed, can be retrieved from the TransactionOutcome object.

[0091] Figure 13 is a diagram of a system 1300 for providing transportation system access. In certain implementations, system 1300 can be used in conjunction with system 400 (as described with reference to Figures 4-6 System 1300 includes a transit key card 1305, a gate / terminal 1310 coupled to one or more fleet terminals 1355 and an access kernel 1350, a terminal backend 1315 of a transportation system provider including a local server 1320, a cloud server 1325, and a PL / SQL server page (PSP), an access server 1335, a payment network 1340, and an issuer 1345.

[0092] At item 1, the issuer 1345 enrolls the key card as a hashed PAN to the access server 1335. At item 2, the vendor (e.g., terminal backend 1315) downloads a list of eligible hashed PANs, e.g., a whitelist, from the access server 1035. The terminal backend 1315 also uploads transaction records to the access server 1335. At item 3, when a passenger presents a transit key card at a transit terminal (e.g., gate terminal 1310 or fleet terminal 1355), the entry details are stored in the memory of the gate / terminal 1310, 1355. The gate / terminal 1310, 1355 supports internal and external expandable storage capability, e.g., SD card. A hashed PAN is generated for the transit key card and CDA authentication is performed to ensure that the card is authentic. In this implementation, the ATC counter is incremented. At item 4, the hashed PAN is synchronized to the fleet and historical transaction data is uploaded. At item 5, the access server 1335 sends an ATC update to the issuer 1345 via the payment network 1040.

[0093] Figure 13 Implementations of the system 1400 describe a closed loop platform where the transit system access provider can migrate to an open loop platform. In a closed loop transit, the fare is purchased upfront and stored on a non-EMV card. The fare transactions are synchronized with a local server, e.g., at the end of the day. Migration to an open loop transit with EMV-enabled gate terminals allows the gate terminals to connect to a cloud server, which connects to a payment service provider (PSP) to allow near real-time payment (or end-of-day) transactions. The local server 1320 supports the gate terminals in a closed loop transit, and the cloud server 1325 supports an open loop transit.

[0094] In one implementation, certain hashed PANs are allowed for free transit. These hashed PANs are stored in a whitelist. The whitelist is communicated from the access server 1335 and stored in the gate terminal 1350. During card swipe at the gate, the card transaction data is stored in the gate terminal, but at the end of the day reconciliation, the card transaction data is synchronized to the backend 1315 and forwarded to the access server 1334.

[0095] Figure 14 is a diagram of a hardware architecture of a system 1400 for providing identity payment and access services. In certain implementations, the system 1400 can be used in conjunction with the system 400 (as referenced in FIG. 4) and the system 1300 (as referenced in FIG. 13). The system 1400 can be used in conjunction with the system 1300 (as referenced in FIG. 13) and the system 400 (as referenced in FIG. 4). Figures 4-6The described) in combination (including replaced elements). The card or pass 1405 (via a mobile and / or wearable device) is presented to the terminal 1410. The terminal 1410 can store 100 hashed PANs as a whitelist of 1 MB. Additionally, the terminal 1410 can send application protocol data unit (APDU) commands through any NFC to read card data. The SHA256 algorithm can be applied to the card data to determine a hashed PAN. The determined hashed PAN can be compared to the whitelist. The terminal 1410 can store card and entry details. In one implementation, the terminal 1410 includes a central processing unit (CPU) memory with at least 128 MB random access memory (RAM) and 256 MB flash memory. In one implementation, removable micro secure digital (μSD) memory is supported. Item 1415 illustrates the hardware integration of the terminal 1410 with a gate. In this particular implementation, a sticker can be provided on the gate to indicate that only compatible key cards can be swiped. A speaker can be provided to provide feedback to the passenger regarding approval or denial of entry. A display can also be provided to provide feedback regarding approval or denial of entry.

[0096] Figure 15 is a diagram of an employee check-in system 1500 using office cubicles. In certain implementations, the system 1500 can be used in combination with the system 400 (as described with reference to Figures 4-6 The described) in combination (including replaced elements). A self-check-in cubicle can be implemented near a lobby or reception area. The worker begins the check-in process by swiping their company badge at a card reader 1505 coupled to a terminal 1515. The worker then swipes their contactless physical / digital card on a second card reader 1510 to register for access. Once check-in is complete, the employee can begin accessing the building using their EMV card, mobile device, or wearable device.

[0097] Figure 16 is a diagram of an employee check-in method 1600 using a user's NFC-enabled mobile device. In certain implementations, the method 1600 can be used in combination with the methods 500, 600 (as described with reference to Figures 5-6 The described) in combination (including replaced elements). At block 1605, the user accesses an employee check-in application on their mobile device. At block 1610, the company badge of the user is registered when placed in proximity to the NFC reader of the mobile device. When check-in is complete, a notification is provided via a success screen at item 1615. The user is now able to use their mobile device to gain access to the site at item 1620.

[0098] Figure 17 is a diagram of a system 1700 for providing employee check-in and employee access. In certain implementations, the system 1700 can be used in combination with the system 400 (as described with reference toFigures 4-6 The described) in combination (including replaced elements). The system 1700 includes an EMV card 1705, a turnstile / terminal 1710 with a turnstile 1715 and one or more terminals 1745, a turnstile backend 1430, a cloud point of sale (POS) server 1720, an access server 1725, a payment network 1735, and an issuer 1740. In one implementation, the one or more terminals 1745 include terminals 1705, 1715.

[0099] At item 1, a user enrolls a company ID badge and an EMV card to an access server 1725 as described in Figure 12 or Figure 13 At item 2, the EMV card is presented at a turnstile 1715. At item 3, the cloud POS 1720 initiates a $0 transaction over a secure network. At item 4, the cloud POS 1720 reads the hashed PAN from the EMV card and performs a lookup of access rules from the access server 1725. At item 5, the access server 1725 requests a turnstile vendor (e.g., turnstile backend 1730) to generate a turnstile access response, e.g., authorized or denied. The turnstile access response is then sent from the turnstile backend 1730 to the turnstile terminal 1710. At item 6, transaction cryptogram data is sent to the payment network 1735 to update the ATC.

[0100] Figure 18 is a diagram of a high-level view 1800 of an identity, payment, and access system. In certain implementations, the system 1800 can be used in combination with the system 400 (as described with reference to Figures 4-6 The system uses an access ID 1820 to implement various identity, loyalty, and access services. The access ID 1820 is mapped to various items, including but not limited to transaction data 1830, a hashed PAN 1810, a barcode and / or QR code 1815, program data 1840, and an ID 1835. The transaction data 1830, hashed PAN 1810, and barcode / QR code 1815 can be provided by a terminal 1805. Various data associated with the access ID 1820 can be provided to an issuer 1825. A service provider 1845 can provide benefits 1850 and benefit mappings 1855 via use of the terminal 1805. An identifier provider 1865 can provide entity IDs 1580 that map 1835 to the access ID 1820 and / or the benefits 1855.

[0101] The present system provides a variety of advantages. QR codes, barcodes, and vendor cards can be easily copied. In some instances, the present disclosure provides a system that can read PANs and serial numbers from physical and digital EMV cards. The hardware costs of the present disclosure are low and use existing gateways and / or USB NFC devices. Embodiments of the present disclosure build on existing, highly secure, and proven EMV payment standards to provide a unified, digital-first experience for consumers across different domains and provide merchants with more data points.

[0102] Figure 19 is a block diagram of a hardware configuration 1900 that can be used as a device operating in the identity, payment, and access system 100 and the asset discovery system 400. The hardware configuration 1900 can be used to implement one or more of the elements described with reference to Figures 1-18 The hardware configuration 1900 can include a processor 1910, a memory 1920, a storage device 1930, and an input / output device 1940. Each of the components 1910, 1920, 1930, and 1940 can be interconnected, for example, using a system bus 1950. The processor 1910 can be capable of processing instructions for execution within the hardware configuration 1900. In one implementation, the processor 1910 can be a single-threaded processor. In another implementation, the processor 1910 can be a multi-threaded processor. The processor 1910 can be capable of processing instructions stored in the memory 1920 or on the storage device 1930.

[0103] The memory 1920 can store information within the hardware configuration 1900. In one implementation, the memory 1920 can be a computer-readable medium. In one implementation, the memory 1920 can be a volatile memory unit. In another implementation, the memory 1920 can be a non-volatile memory unit.

[0104] In some implementations, the storage device 1930 can be capable of providing mass storage for the hardware configuration 1900. In one implementation, the storage device 1930 can be a computer-readable medium. In various different implementations, the storage device 1930 can include, for example, a hard disk device / drive, an optical disk device, a flash memory, or some other large capacity storage device. In other implementations, the storage device 1930 can be a device external to the hardware configuration 1900. The input / output device 1940 provides input / output operations for the hardware configuration 1900.

[0105] Figure 20 Figure illustrates four categories of terminal attestation describing terminals (e.g., terminal 320, asset verification terminal 412, gate 412) working within the identity, payment, and access system 100 or system 400 (in addition to Figure 7Figure 1200. The terminals are categorized according to the type of transaction, the type of credential, the type of solution provided, the deployment model version, whether ATC updates are performed, and the type of attestation performed. Category 5 terminals provide simple access. Category 6 terminals can be used to provide secure access. Category 7 terminals can be used to provide open transit and category 8 terminals can be used to provide retail innovation programs.

[0106] As mentioned above, category 5 terminals provide for simple access. The type of credential for this type of system is an access ID or a payment account reference (PAR). In this implementation, combined dynamic data authentication - application cryptogram generation (CDA) is not necessary. Additionally, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) reads the access ID or PAR from an EMV card, mobile device, or wearable device and provides access. In one implementation, the access ID can be read using third party data and the PAR can be read via an EMV card or token. In another implementation, the third party data can be provided via tag 9F6E and the PAR can be provided via tag 9F24. Access can be provided by matching the access ID or PAR locally or after verification by a remote access server (e.g., access server 330). The terminal can be provided using a software development kit (SDK), does not require application transaction counter (ATC) updates, and the attestation requirements for the terminal are low. The terminal SDK can be implemented on a computer operating system or on a mobile device operating system, e.g., for a phone, tablet, or similar mobile device.

[0107] As mentioned above, category 6 terminals provide for secure access systems. Secure access systems can be for access and / or identification systems. The credential for this type of system is a hashed PAN and CDA. In this implementation, the terminal (e.g., terminal 320) performs a zero dollar ($0) authorization CDA transaction. The vendor's terminal SDK is an EMV terminal that implements a full EMV access kernel according to the access terminal specification. The full terminal SDK can be based on a contactless reader SDK or implemented in a mobile device operating system, e.g., for a phone, tablet, or similar mobile device. In this implementation, ATC updates can be deferred or provided in real time and the attestation requirements are moderate.

[0108] As mentioned above, Category 7 terminals provide access and / or transit systems. In particular, Category 7 terminals provide open transit systems. The credentials for this type of system are hashed PAN and CDA. The CDA, also known as combined data authentication, involves including card decisions in data signed by the card's RSA key (public or asymmetric key algorithm). In this implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) performs a zero dollar ($0) authorization CDA transaction. The vendor's terminal is an EMV terminal that implements a full EMV access kernel according to the access terminal specification. In this implementation, ATC updates can be deferred and require full attestation.

[0109] As mentioned above, Category 8 terminals provide access and / or payment systems. In particular, Category 8 terminals provide retail innovation systems. Retail innovation can be for merchant retail stores and / or payments. The credentials for this type of system are hashed PAN and CDA. In this implementation, the terminal (e.g., terminal 320, asset verification terminal 412, gate 412) performs a full EMV transaction from the terminal and / or cloud POS SDK. The vendor's terminal can include a terminal SDK implemented on a mobile device running a mobile device operating system or hosted by a cloud POS server. In this implementation, ATC updates are provided in real-time and require full attestation.

[0110] The subject matter of the present disclosure and its components can be realized by instructions for one or more processing devices to perform the processes and functions described above. Such instructions can be, for example, included in firmware, software, or other instructions stored in computer-readable media, which when executed, can configure one or more processing devices to perform the processes and functionality described above.

[0111] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus.

[0112] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and are interconnected by a communication network.

[0113] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output, thereby transforming the input data into the output, which can be bound to a particular machine (e.g., the machine programmed to perform the processes described herein). The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0114] Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0115] The above discussion will be understood to be discursive in nature, addressing certain specific embodiments. It will be appreciated that the above discussion is merely meant to enable one of ordinary skill in the art to make and use any subject matter now or later defined in the patent “claims” of any patent issuing herefrom.

[0116] It is specifically intended that the claimed invention not be limited to the embodiments and illustrations contained herein, but include modified forms of those embodiments including portions of the embodiments and combinations of elements of the described embodiments as falling within the scope of the following claims. It will be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions can be made to achieve the developers’ specific goals, such as compliance with system-related and business-related constraints, which can vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure. Nothing in this application is considered critical or essential to the claimed invention unless explicitly indicated as being “critical” or “essential.”

[0117] In the foregoing detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be appreciated that the disclosure can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0118] It will also be understood that, although the terms first, second, etc. can be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first object or step could be termed a second object or step, and, similarly, a second object or step could be termed a first object or step, without departing from the scope of the present disclosure. The first object or step and the second object or step are both, objects or steps, but they are not to be considered the same object or step.

[0119] The terminology used in the description of the disclosure herein solely for the purpose of providing a clear and thorough understanding of the present disclosure. As used in the description of the disclosure and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0120] As used herein, the term “if’ can altematively be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” can altematively be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context. As used herein, the terms “upper” and “lower”; “up” and “down”; “above” and “below”; “upwardly” and “downwardly”; and other like verbs or adjectives can be used in connection with the various embodiments of the various techniques described herein.

[0121] While the foregoing is directed to implementations of the various techniques described herein, other and further implementations can be devised without departing from the basic scope thereof, which can be determined by the claims that follow. While the subject matter has been described above in terms of specific embodiments, it is not intended that the subject matter be limited to the specific embodiments described. Rather, it is believed that the subject matter is best understood probably when considered in all its embodiments, including the following claims.

Claims

1. A method comprising: The access server maps cards to consumer and blockchain wallet account addresses, wherein the access server is configured as an access mapping service contract, and wherein the card includes at least one of the consumer's Personal Account (PAN) and Electronic Application Identifier (eAid).

2. The method of claim 1, wherein the card mapping is performed prior to the digital asset transaction.

3. The method of claim 2, further comprising: A digital wallet is coupled to the issuer's computer system by a consumer device associated with the consumer, wherein the coupling of the digital wallet includes linking the consumer's Personal Account (PAN) to the digital wallet.

4. The method of claim 3, further comprising: One or more asset contracts are generated by the merchant's computer system and correspond to the corresponding digital assets on the blockchain.

5. The method of claim 4, wherein the corresponding digital asset comprises: Non-fungible tokens (NFTs), semi-fungible tokens (SFTs), or tokens.

6. The method of claim 4, further comprising: The merchant's computer system lists one or more asset contracts on the blockchain in a digital marketplace.

7. The method of claim 6, further comprising: The consumer obtains one or more asset contracts via a consumer device, wherein the one or more assets are configured to be stored on a digital wallet.

8. The method of claim 1, wherein the card mapping is performed concurrently with the digital asset transaction.

9. The method of claim 8, further comprising: Consumer devices associated with consumers provide blockchain wallet account addresses to merchant computer systems to map at least one of the consumer’s Personal Account (PAN) and Electronic Application Identifier (eAid) to the merchant computer systems.

10. The method of claim 8, further comprising: Consumers couple their cards to the asset verification terminal.

11. The method of claim 10, further comprising: The asset verifier terminal processes the Personal Account Number (PAN) or Electronic Application Identifier (eAid) from the card. as well as Generate a hashed PAN.

12. The method of claim 11, further comprising: The asset verifier terminal requests one or more digital assets associated with a hashed PAN or electronic application identifier from a mapping service contract stored on the access server.

13. The method of claim 12, further comprising: The access server uses the blockchain wallet account address to search for the one or more digital assets.

14. The method of claim 13, further comprising: The access server verifies the one or more digital assets.

15. The method of claim 11, wherein the one or more digital assets comprise: Non-fungible tokens (NFTs), semi-fungible tokens (SFTs), or tokens.

16. The method of claim 15, wherein the one or more digital assets include NFTs or SFTs corresponding to loyalty profiles.

17. The method of claim 1, wherein the card is a chip card corresponding to a Europay, Mastercard, or Visa (EMV) card.

18. The method of claim 1, wherein the card is configured to be presented via a mobile device, a wearable device, or a contactless EMV card.

19. A method comprising: A digital wallet is coupled to the issuer's computer system by a consumer device associated with the consumer, wherein the coupling of the digital wallet includes associating the consumer's Personal Account (PAN) or Electronic Application Identifier (eAid) with the digital wallet.

20. A method comprising: Consumer devices associated with consumers provide blockchain wallet account addresses to merchant computer systems to map at least one of the consumer’s Personal Account (PAN) and Electronic Application Identifier (eAid) to the merchant computer systems.

Images