DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following is a Non-Final Office Action in response to communications received 02/09/2026. Claim(s) 19-20 have been canceled. Claim(s) 1 has been amended. New claims 21-22 have been added. Therefore, claims 1-18 and 21-22 are pending and addressed below.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17 (e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission has been entered.
Priority
Application No. 18225265 filed 07/24/2023.
Applicant Name/Assignee: Mastercard Asia/Pacific PTE. LTD.
Inventor(s): Cheng, Karl; Long Le, Phuoc Hoang; Ganapathi, Putu Arie
Information Disclosure Statement
The IDS submitted 02/09/2026 has been reviewed and considered.
Response to Arguments/Amendments
Claim Rejections - 35 USC § 101
Applicant's arguments filed 08/01/202 have been fully considered but they are not persuasive.
In the remarks applicant points to the Alice decision, MPEP 2106, MPEP 206.04(II)(A), 2106.04(a) and MPEP 2106.04, arguing that the current application under step 2A prong one when viewed as a whole is directed toward a particular sequence of cryptographic operations distributed across distinct system components and the “methods of organizing human activity”. Applicant recited claim 1 limitations emphasizing the limitations “generating, by an access server, cryptographic input for use in cryptographic hash function”, “providing the …input to an asset verifier terminal…the hashed identifier is generated at the asset verifier terminal by applying the cryptographic hash functions, to a PAN/EAI associated with a card…in combination with the cryptographic input provided by the access server”, ”causing…mapping service contract…deployed on blockchain to store…association between the hashed identifier and …wallet account address”, “receiving by the access server…a query request…” and “determining …via the mapping service contract whether the …identifier is associated with the …assets”, arguing the limitations are not directed toward any of the enumerated abstract sub-categories under methods of organizing human activity. Rather the claim limitations define how the hashed identifier is generated and where the cryptographic operations occur including the technical role of the access server in controlling the cryptographic input and the terminal-side generation of the hashed identifier. Therefore, the claim recites specific technical implementation preventing exposure/duplication of sensitive credential data while enabling on-chain asset verification. Applicant’s argument is not persuasive. The claim limitations do not define how as a technical process the hash identifiers are generated. Rather the limitation is recited at a high level lacking any technical details with an expected result. This is equally the case with respect to the access server in controlling the cryptographic input, the limitation lacks technical details. Applicant’s arguments admit that the focus of the limitations as a whole is to preventing exposure/duplication of sensitive credential data while enabling on-chain asset verification, which is risk mitigation and commercial activity. As a whole the claimed subject matter is directed toward a business process of associating between an identifier received and a wallet account address according to a contract and determining via the contract upon receiving a request to determine whether assets recorded are associated with a received identifier which is a commercial activity. The rejection is maintained.
In the remarks applicant argues that the claimed cryptographic architecture cannot be performed mentally and does not recite generic data correlation scheme or merely automate long standing commercial practices. Applicant argues the limitations are rooted on computer security and distributed ledger technology and addresses technical problems arising in blockchain identity linked asset verification systems. Accordingly the amended independent claim 1 and new claim(s) 21-22 and the corresponding dependent claims of claim 1 are patent eligible. Applicant’s argument is not persuasive. First the rejection does not recite that limitations are directed toward the abstract category of mental concepts. Applicant is arguing a rejection not applied. Second, applicant has not identified the ” technical problems arising in blockchain identity linked asset verification systems”. The encryption of data inputted into blockchain ledger, is an establish process in blockchain and not an innovative concept of the applicant. The examiner provides as evidence that encryption in blockchain is established (e.g. Cryptography: How is it Related to Blockchain? By Majumber (2022); History of Blockchain by Wilson (2021); Blockchain 1.0 to Blockchain 4.0 by Mukherjee et al (2021)). In addition the focus of the claimed subject matter is not encryption or blockchain technology but rather the verification if identifiers received from a request and stored associated assets. The rejection is maintained.
In the remarks applicant argues that under step 2A prong 2, pointing to MPEP 2016.04, the claimed subject matter integrates any alleged abstract idea into a practical application. Applicant argues the amended limitations recite specific distributed cryptographic architecture that constrains how identifiers are generated, transmitted, stored and verified across distinct computing components. The claimed limitations improve the functioning of computer security systems and blockchain based verification infrastructure. Applicant’s argument is not persuasive. The claimed limitations recite the infrastructure to include an “access server” as amended is applied to generate cryptographic input for use in cryptographic hash function without any technical details. The “generating …cryptographic inpput” step as amended performed by the “access server” and “determining via the mapping service contract, whether the …identifier is associated with …assets” are recited at a high level lacking technical details with an expected outcome.
The recited “access server” as amended is further applied to perform the operations “providing…cryptographic input…”, and “receiving….a hashed identifier”, at a high level lacking technical disclosure with an expected outcome.
The recited “access server” is applied to perform the operations “causing…a mapping service contract ….to store…an association between the …identifier and a …wallet account address and perform the operation and applied to perform the operation “receiving…a query request…to request corresponding to a request to determine whether the …assets recorded …are associated with the …identifier”
According to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The claim limitations (providing…cryptographic input…”, “receiving….a hashed identifier”, causing…a mapping service contract ….to store…an association between the …identifier and a …wallet account address” and “receiving…a query request…to request corresponding to a request to determine whether the …assets recorded …are associated with the …identifier”) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The recited distributed architecture does not perform any operations recited in the claim and no more than a storage component as a field of use in the storing of an “association between…the identifier and …asset” and therefore is not as argued “specific distributed cryptographic architecture that constrains how identifiers are generated, transmitted, stored and verified across distinct computing components.” Applicant is arguing limitations not claimed.
In the remarks applicant argues the operations performed by the access server “generating”, “providing”, “receiving” and “causing” provides details on how and where cryptographic operations occur and how trust is distributed across system components. These limitations constrain the location and sequencing of crypto graphic operations requiring cooperation between the access server and verifier terminal and blockchain contract. Applicant’s argument is not persuasive. The only limitations that can be considered a cryptographic operation is the limitation “generating cryptographic input” and “hash identifier is generated…by applying the cryptographic hash function to a PAN/EAI” which does not provide any details as to how the cryptographic input is generated or the “hash identifier is generate”. Applicant is arguing limitations not claimed. The applicant does not point out what limitations “constrain the location and sequencing of crypto graphic operations requiring cooperation between the access server and verifier terminal and blockchain contract”. The “hashed identifier” generated of the “receiving hashed identifier” step does not provide any steps directed toward the hashing of the identifier, instead the limitation merely states the identifier is “generated at the asset verifier terminal by applying a cryptographic hash function to a PAN/EAI” without technical details which is so broad as to encompass any known means. The application of the hash function is performed at the verifier terminal. Being performed at the verifier terminal is not necessarily being performed by the verifier terminal. The rejection is maintained.
In the remarks applicant points to MPEP 2106.04(d), MPEP 2016.04(d)(1), arguing that the claim limitations comply by providing improvement to another technical field. Applicant argues the sequence of cryptographic input is centrally controlled by the access server while the has generate is performed at the verifier terminal. This architecture improves the security system by preventing independent/duplication of hash identifiers outside the system. The generation of the hash identifier generated at the verifier terminal using the cryptographic input prevents the access server from receiving raw PAN/EAI data, reducing exposure of sensitive credentials improving system security. Because the hashed identifier is generated in combination with the cryptographic input a compromised terminal cannot independent generate hash identifiers. This improves resistance to replay attacks/unauthorized credential reuse. The association between the hashed identifier and address stored via the smart contract improves reliability and integrity of the verification. By verifying asset associations using hashed identifiers stored on-chain the system enables secure verification across disparate asset verifier terminal without sharing sensitive data, improving the functioning of distributed systems. Applicant points to the specification for support in the paragraphs below, however, thee specification does not disclose a particular technical process or a process to improve any underlying technology. Rather the specification focuses on processes to mitigate fraud or identify theft.
[0029] Advantageously, certain inventive aspects, as described herein, incorporate emerging technologies such as smart contracts, blockchains, non-fungible tokens (NFTs), semi-fungible tokens (SFTs), cryptocurrency and/or digital wallets, and digital assets and/or tokens with inventive identity, payment, and access services. Accordingly, inventive systems and methods allow for safe and secure verification of transactions and proving entitlements utilizing smart contracts.
[0031] Advantageously, asset verification can be decoupled from asset issuance, and, hence, allows for better integration of the process flow (e.g., a gantry would not need to belong to a particular ticket issuer, and would necessitate only minimal configurations to verify tickets from different sellers).
[0034] The present system provides end-to-end implementations for identity 110, loyalty programs 115 and access 120 using the EMV standard 105 via, for example, contactless cards, tokens, mobile device digital wallet, wearable devices coupled to mobile devices. Examples related to identity 110 include passports 135, student identification 130 and user identification 125. Examples related to loyalty 115 include earning points 140 and redeeming points 145. Examples related to access include office building and/or wework systems 150, hotels and other types of rental properties 155, and attractions 160, e.g., tourism, sports or other activities. The present system brings an end to-
end, seamless touchless experience by unlocking hidden potential in existing contactless cards/tokens. Additionally, the present system, in one example, provides seamless and secure ticket or voucher verification that would discourage scalping and counterfeiting.
[0039] In one implementation, a hashed PAN or digital account number (DAN) is generated using the following method. 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 passphrase. Salts are used to safeguard PANs/DANs. A new salt is randomly generated for each PAN/DAN. In one 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., output hash value, (but not the original PAN/DAN) can be stored in a local memory or sent to access server 330. Hashing allows for later authentication without keeping and therefore risking exposure of the PAN/DAN if the authentication data store is compromised. In one implementation, the PAN/DAN read by terminal 320 can be 13 to 19 digits. In one implementation, the hashed PAN (PANISAL T) or hashed DAN
(DANISAL T) can be generated by a SHA256 hash function. For the sake of simplicity, wherever the present disclosure describes implementations related to a PAN, the same methods described herein can be applied to DANs and/or tokens presented by mobile and/or wearable devices.
[0040] FIG. 4 illustrates a diagram of an assets discovery system 400 allowing for mapping and coupling of digital assets in accordance with implementations of various techniques herein. As may be appreciated, instead of using a proprietary booking system, tickets/entitlements may be represented as non-fungible tokens (NFTs), whereby such NFTs may be sold on a marketplace 416 (e.g., an NFT platform or with a basic web3 enabled website). For example, a mapping contract securely accessible (as well controllable and usable) by an access server 41 0 (i.e., access system) (e.g., Mastercard EZaccess) would be configured to represent such tickets as NFTs. In certain
implementations, the access server 410 may be the access server 220 or 330 (with reference to FIGS. 2 and 3).
[0042] In such a scenario, advantageously, the utilization of smart contracts (e.g., based on using a standard ERG 721 contract for merchant tickets) for mapping services by the access server 410 provides flexibility to a merchant system 420. In various implementations, smart contracts correspond to a program or transaction protocol written into a blockchain that can be configured to execute, control, or document events and actions according to terms of a contract or an agreement. As an advantage, in certain instances, the system 400 would provide flexibility to a merchant by using the standard ERG 721 contract for tickets, and hence, allowing for more gantry querying separate blockchains directly or to use an interface of the system 400 (e.g., that can be configured for less integration). Advantageously, by using such a smart contract protocol, a merchant system 420 is able to create a gantry smart contract (i.e., an asset contract, a digital asset) 418 that conforms to the mapping service contract (e.g., EZaccess NFT protocol as accessed, utilized, and/or controlled by access server 410 and stored on the public blockchain 414) with the capacity for additional functionalities, as described herein. Hence, interoperability can be improved for the merchant 420 or any other involved entity.
[0072] Fig. 13 is a diagram of a system 1300 for providing transit system access. In certain implementations, system 1300 may be used in combination (including with replaced elements) with system 400 (as described with reference to FIGS. 4-6). System 1300 includes a transportation key card 1305, gantry/terminal 1310 coupled to one or more fleet terminals 1355 and access kernel 1350, a terminal backend 1315 of a transit system provider that includes a local server 1320, a cloud server 1325 and PL/SOL Server Pages (PSP), an access server 1335, a payment network 1340, and an issuer 1345.
With respect to the argument that the “the hashed identifier is generated in combination with the cryptographic input”, applicant is arguing limitations that do not provide any technical details as to how the cryptographic input is applied in combination with the hashing function. The hashed identifier generated in combination with the cryptographic input is stated without technical details . Hashing identifiers and encrypting inputs received in a request does not change or improve upon the capability of the claimed asset server or the verifier terminal is merely protects the data using establish technology at a high level. The rejection is maintained.
In the remarks applicant argues the claimed limitations impose meaningful limits tied to technology. The amended claims require specific technical architecture in which the “generating …cryptographic input for use” and “providing…the cryptographic input to an asset verifier terminal” which constrains how the cryptographic material is created and distributed. The “receiving… a hashed identifier …generated …in combination with the cryptographic input provided” enforces the terminal side hash generation using server-controlled cryptographic input rather than server-side hashing or generic identifier correlations. Applicant’s is arguing limitations not claimed. The limitations recite an “access server” applied to perform the “generating”, “providing” and “receiving” operations. The claimed “access server” is not a specific technical architecture and does not as claimed perform any specific operations beyond generic ordinary operations performed by conventional technology. The claimed limitations lack technical details and fail to provide any specificity as to how the cryptographic material is created and distributed other than an expected outcome. The rejection is maintained.
In the remarks, Applicant further argues the limitation “causing …a mapping service contract … to store, on the blockchain an association between the …identifier and blockchain account address” and “determining via the mapping service contract…whether the …identifier is associated with the …assets”, require on-chain storage and verification via a smart contract execution and cannot be implemented using conventional off-chain databases or generalized data correlation techniques. Applicant’s argument is not persuasive. Blockchain database technology has been established since 2009-2010 and is not considered generic technology without significantly more than its basic functionality. Storing data in a blockchain database without significantly more, merely limits the storage to a particular field of use. The application of smart contracts to determine whether an identifier is associated with the …assets limitation does no more than automate a common transaction activity with assets are part of a contractual process. The rejection is maintained.
In the remarks applicant argues the combination of the limitations of arguments 7 and 6 integrate the alleged abstract idea into particular technological implementation improving the functions of distributed systems by enabling secure decentralized credential verification without transmitting sensitive data eliminating reliance on issuer databases and enforcing cryptographic separation between servers and verifier terminals pointing the specification (¶ 0029, ¶0031, ¶0034, ¶0039-0040, ¶0042 and ¶0072). Accordingly the limitations integrate any alleged abstract idea. Applicants argument is not persuasive. Looking back to the response of arguments 5-7, the limitations do not improve distributed databases, the capability or functional operations of the either the claimed asset server or verifier terminal. The limitations merely as a sequence of events generate encrypted data which is then received for use in the generation of hash identifiers that are stored in a database and then analyzed according to contractual mapping as to determine whether the identifiers are associated with wallet account addresses and assets. The receiving and storing of data does not improve upon any underlying technology. The generation of encrypted data or hashing of identifiers using hashing functions are equally non-impactful to any of the underlying technology. The rejection is maintained.
In the remarks applicant argues that under step 2B, the claimed subject matter provides significantly more that the identified abstract idea. Applicant points to MPEP 2106.05(I), MPEP 2106.05(I)(A), arguing the amended independent claim(s) recites specific improvement to computer security. Applicant recites the limitations arguing the combination of the cryptographic input provided and the distributed architecture improves how computer systems securely generate and verify identifiers by separating cryptographic input generation from terminal side hash generation reducing exposures to sensitive identifiers and preventing exposure/duplication of hashes across terminal. Applicant argues the limitations improve distributed ledger technology by causing a mapping service contract to store an association between the identifier and wallet account address and determining whether the hashed identifier is associated with digital assets. This improves blockchain system by enabling on-chain asset verification. Applicant is repeating arguments above. See response above, the rejection is maintained.
In the remarks applicant points to MPEP 2106.05(d) arguing the claim limitations recite limitations that are not well understood routine technical activities. The sequence of cryptographic operations distributed across multiple system components as claimed is unconventional reciting the claimed operations. Applicant argues the limitations are not a routing credential matching process but a coordinated cryptographic and distributed ledger architecture that constrains how and where identifiers are processed. Applicant’s argument is not persuasive. As discussed above the generation of cryptographic input is high level lacking any technical details. The “providing…input”, “receiving…identifiers” “store…an association” are insignificant extra solution activity as the limitations also lack technical details as to implementation, merely recited high level functions with expected results. The rejection is maintained.
Claim Rejections - 35 USC § 103
Applicant's arguments are moot in light of the new ground of rejection that was necessitated by Applicant's amendments. Based on an updated search of the art, a new reference was used in the rejection below
Claim Interpretation
In light of the specification, the examiner is interpreting the “generated cryptographic input” to be analogous to SALT
[0039] In one implementation, a hashed PAN or digital account number (DAN) is
generated using the following method. 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 passphrase. Salts are used to safeguard PANs/DANs. A new salt is randomly
generated for each PAN/DAN. In one 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., output hash value, (but not the original PAN/DAN) can be stored
in a local memory or sent to access server 330. Hashing allows for later authentication
without keeping and therefore risking exposure of the PAN/DAN if the authentication data
store is compromised. In one implementation, the PAN/DAN read by terminal 320 can be
13 to 19 digits. In one implementation, the hashed PAN (PANISAL T) or hashed DAN
(DANISAL T) can be generated by a SHA256 hash function. For the sake of simplicity,
wherever the present disclosure describes implementations related to a PAN, the same
methods described herein can be applied to DANs and/or tokens presented by mobile
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 and 21-22 are rejected under 35 U.S.C. § 101 because the instant application is directed to non-patentable subject matter. Specifically, the claims are directed toward at least one judicial exception without reciting additional elements that amount to significantly more than the judicial exception. The rationale for this determination is in accordance with the guidelines of USPTO, applies to all statutory categories, and is explained in detail below.
In reference to Claims 1-18:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 1 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 1 recites method step (1) generating cryptographic input (2) providing …input (3) receiving …hashed identifier….(4) causing a smart contract to store an association between an identifier and blockchain account address (5) receiving query request (6) determining whether wallet address is associated with assets. The claimed limitations which under its broadest reasonable interpretation, covers a commercial interaction.
The Specification is titled “Access Server System and Methods for Mapping and Coupling of Digital Assets,” and discloses, in the summary, utilizing smart contracts and crypto wallets so that a wallet account address may be mapped by a server to an account number. The Specification describes that the focus of the invention is to apply incorporate/apply technologies such as smart contracts, blockchains, non-fungible tokens (NFTs), semi-fungible tokens (SFTs), cryptocurrency and/or digital wallets, and digital assets and/or tokens with inventive identity, payment, and access services to allow for safe and secure verification of transactions and proving entitlements utilizing smart contracts (spec 0029). The specification discloses the advantages of using token technologies in a plurality of industries (spec 0034) to provide access using standard contactless cards, tokens, wallets coupled to devices. According, in light of the specification, when considered as a whole the claimed subject matter is directed toward for a business process correlating data between sources. Such concepts can be found in the abstract category of commercial interactions. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include an access server, asset verifier terminal, smart contract, blockchain.
The recited “access server” as amended is further applied to perform the operations “providing…cryptographic input…”, and “receiving….a hashed identifier”, at a high level lacking technical disclosure with an expected outcome.
The recited “access server” is applied to perform the operations “causing…a mapping service contract ….to store…an association between the …identifier and a …wallet account address and perform the operation and applied to perform the operation “receiving…a query request…to request corresponding to a request to determine whether the …assets recorded …are associated with the …identifier”
According to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The claim limitations (providing…cryptographic input…”, “receiving….a hashed identifier”, causing…a mapping service contract ….to store…an association between the …identifier and a …wallet account address” and “receiving…a query request…to request corresponding to a request to determine whether the …assets recorded …are associated with the …identifier”) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional limitation “access server” is further applied to perform at a high level the operation “generating…cryptographic input”, “determining…via the mapping service contract, whether the …identifier is associated with the …assets”, which is not directed toward improving upon or providing a solution to a problem rooted in hash functions, asset servers, verifier terminals or blockchain. The blockchain is merely the environment in which data is stored and does not perform any steps in the method. This is also true with respect to the verifier terminal as the terminal merely is the source of the query received by the asset server. The mapping service contract amounts to no more than instructions to store an “association”.
Taking the claimed step as performed by the method is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations “generate …cryptographic input”, “providing…input”, “receiving identifier”, “map a card and a wallet account” and “receiving query request” as the claimed limitations do not provide any technical details as to how the server performs the claimed operations. The specification (spec 0030) describes the mapping step as being the coupling of a card with a digital wallet without any details as to the technical implementation. The claimed process is so high level that any means of storing association of data could be applied and performed by any known means. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When considered as a combination the combination of limitations (1)-(3) are directed toward storing associated identifier (PAN) and account address data of a smart contract, receiving a request with account identifier data and determining whether the wallet account address associated with assets is not directed toward technology where the technology is improved or a solution to a problem rooted in technology, but rather a transaction activity where technology is applied for use in storing an association between an account identifier and wallet account address related to a smart contract and receiving a query respect for assets in order to determine whether the identifier is associated with the assets which as a combination is directed toward a commercial activity.
There is no indication in the claim language that the causing step is directed toward any technology in an attempt to improve upon it or changed the operation of technology in any way. The specification and claims with respect to the “causing” step fail to provide any indications of integration into a practical application under the guidance of 2106.04. The claim provides no technical details regarding how the “causing” operation is performed. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a technology is integrated into the mapping step. “Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v. Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)). Accordingly the claimed step does not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of mapping a card to a wallet account address which is a process directed toward a business practice.
The integration of elements do not improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to map a card to a wallet account address and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The claimed additional elements recited in the claim beyond the abstract idea include “by an access server” to perform the generating, providing, causing to store, receiving and determining steps. The wherein clause does not further limit the causing step but instead limits the data acted upon.
Taking the claim elements separately, the function performed by the access server at each step of the process is purely conventional. Using a access server to map a card to a wallet and receive data ----are some of the most basic functions of a server. When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of the server functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) Absent a possible narrower construction of the terms “mapping” and “receiving' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses:
[0083] FIG. 19 is a block diagram of a hardware configuration 1900 operable as a device in an identity, payment and access system 100 as well as the asset discovery system 400. Hardware configuration 1900 may be utilized to implement one or more of elements as described with reference to FIGS 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, for example, be interconnected 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.
[0072] Fig. 13 is a diagram of a system 1300 for providing transit system access. In certain implementations, system 1300 may be used in combination (including with replaced elements) with system 400 (as described with reference to FIGS. 4-6). System 1300 includes a transportation key card 1305, gantry/terminal 1310 coupled to one or
more fleet terminals 1355 and access kernel 1350, a terminal backend 1315 of a transit system provider that includes a local server 1320, a cloud server 1325 and PL/SOL Server Pages (PSP), an access server 1335, a payment network 1340, and an issuer 1345.
[0079] Fig. 17 is a diagram of a system 1700 for providing employee onboarding and employee access. In certain implementations, system 1700 may be used in combination (including with replaced elements) with system 400 (as described with reference to FIGS. 4-6). System 1700 includes an EMV card 1705, gantry/terminal 1710 having a gantry 1715 and one or more terminals 17 45, a gantry backoffice 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.
With respect to the generating “cryptographic input”, as set forth above in the claim interpretation such inputs are analogous to SALT applied in hashing in light of the specification. As evidence that the application of SALT in hashing is well known and understood the examiner provides: “Introduction to the Hash Function as a Personal Data Pseudonymisation Technique” by AEPD (2019); What is a Salt and How does it Boost Security? By Loginradius (2021); In hashing does it matter how random a Salt is? By Information Security (2012)
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 2-18 these dependent claim have also been reviewed with the same analysis as independent claim 1. Dependent claim 2 is directed toward storing the association of the identifier and account address before a transaction- directed toward a business practice. Dependent claim 3 is directed toward determining whether the identifier is associated with digital assets, invoking a function of the contract to receive the identifier and account address and write the association on the blockchain – which is directed toward a contractual process of a transaction. Dependent claim 4 is directed toward assets are associated with contracts generated by a merchant system- commercial action with legal obligations. Dependent claim 5 is directed toward asset tokens- well known understood technology. Dependent claim 6 is directed toward assets are associated with contracts on the blockchain listed by system – directed toward business practice. Dependent claim 7 is directed toward the identifier associated with the card corresponding to the consumer is associated with the wallet coupled with an issuer system-a business process. Dependent claim 8 is directed toward association between the identifier and wallet address stored is performed concurrent to asset transaction – business practice. Dependent claim 9 is directed toward the identifier associated with the card corresponding to the consumer is mapped to a merchant system- a transaction process. Dependent claim 10 is directed toward coupling the card to an asset verifier terminal- a business process. Dependent claim 11 is directed toward processing the account number or application of the card and generating a hashed PAN and generating an identifier hash- transaction process and security of data. Dependent claim 12 is directed toward requesting the mapping service for assets associated with the PAN- transaction process. Dependent claim 13 is directed toward determining whether the identifier is associated with the digital assets, invoking the contract function to perform the operations receive identifier as input, retrieve the account address associated with the identifier, query the contract to determine whether the wallet account address is associated with digital assets - business process. Dependent claim 14 is directed toward generating a response to a request and providing the response to the verifier- business/transaction practice. Dependent claim 15 is directed toward token- well understood technology. Dependent claim 16 is directed toward assets comprise NFT or SFT corresponding to a loyalty profile- business practice. Dependent claim 17 is directed toward card corresponding to EUROPAY, mastercard or visa card- business practice. Dependent claim 18 is directed toward the card presented via mobile device, wearable device or emv card- well known technology.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 1. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 2-18 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claim 21:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 21. Such system fall under the statutory category of "machine." Therefore, the claim is directed to a statutory eligibility category.
STEP 2A Prong 1. The functions of system claim 21 corresponds to steps of methoc claim 1. Therefore, claim 21 has been analyzed and rejected as being directed toward an abstract idea of the categories of concepts directed toward methods of organizing human activity previously discussed with respect to claim 1.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a system comprising an access server comprising one or more processors, one or more first memory comprising program instructions executed by the processors, additional elements include asset verifier terminal, smart contract, blockchain.
The operations of the one or more processors of the asset server to perform functions that corresponds to steps of method claim 1. Therefore, claim 21 has been analyzed and rejected as failing to provide limitations that are indicative of integration into a practical application, as previously discussed with respect to claim 1.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements beyond the abstract idea include a system comprising an access server comprising one or more processors, one or more first memory comprising program instructions executed by the processors, additional elements include asset verifier terminal, smart contract, blockchain. The one or more processors of the asset server to perform the operations “generate …cryptographic input”, “provide …input”, “receiving …identifier…the hashed identifier generated by applying a hash function” to identifiers, “cause mapping service contract to store an association”, “receive …a query” and “determine …whether …identifier is associated with…assets”–is purely functional and generic. Nearly every server for implementing a method will include one or more “processor” capable of performing the basic computer functions -of “generate cryptographic input”, “provide…input”, “receive…identifier”, “cause…to store an association”, “apply hash function”, “receive …a query”, and “determine …identifier associated with …assets” - As a result, none of the hardware recited by the system claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
The operations of system 21 corresponds to the steps of method claim 1. Therefore, claim 21 has been analyzed and rejected as failing to provide additional elements that amount to an inventive concept –i.e. significantly more than the recited judicial exception. Furthermore, as previously discussed with respect to claim 1, the limitations when considered individually, as a combination of parts or as a whole fail to provide any indication that the elements recited are unconventional or otherwise more than what is well understood, conventional, routine activity in the field.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
[0082] The present system provides a variety of advantages. QR codes, bar codes and vendor cards can easily be duplicated. In certain instances, the present disclosure provides a system that can read PAN and serial number from physical and digital EMV cards. The hardware of the present disclosure is low-cost and uses existing gantries and/or USB NFC devices. Implementations of the present disclosure are built on top of existing highly secure and proven EMV payment standards, provides a unified digital-first experience for consumers across different domains, and provides more data points for merchants.
[0083] FIG. 19 is a block diagram of a hardware configuration 1900 operable as a device in an identity, payment and access system 100 as well as the asset discovery system 400. Hardware configuration 1900 may be utilized to implement one or more of elements as described with reference to FIGS 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, for example, be
interconnected 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.
[0087] As mentioned above, Category 5 terminal is provided for simple access. The credential type 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 (GOA) is not necessary. Further, the terminal (e.g., terminal 320, asset verifier terminal 412, gantry 412) reads the access ID or PAR from the EMV card, mobile device or wearable device and provides access. In one implementation, the access ID can be read using a third party data and the PAR can be read via an EMV card or token. In another implementation, 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 upon verification by a remote access server, e.g., access server 330. The terminal can be provided using a software data kit (SOK), no application transaction counter (ATC) update is required, and the certification requirements for the terminal are low. The terminal SOK can be implemented on a computer operating system or implemented on a mobile device operating system, e.g., for a phone, tablet or similar mobile device.
[0088] As mentioned above, Category 6 terminal is provided for secure access systems. Secure access systems can be directed to access and/or identification systems. The credential for this type of system is a hashed PAN and GOA. In this implementation, the terminal, e.g., terminal 320, performs a zero dollar ($0) authorization GOA transaction. The vendor's terminal SOK is an EMV terminal implementing a full EMV access kernel according to access terminal specifications. The full terminal SOK can be based on a
contactless reader SOK 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 certification requirements are medium.
[0093] 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
interconnected by a communication network.
[0094] The processes and logic flows described in this specification are 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 tying the process to a particular machine (e.g., a 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).
The specification nominally mentions a cryptographic operation without techncial details:
[0039] In one implementation, a hashed PAN or digital account number (DAN) is
generated using the following method. 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 passphrase. Salts are used to safeguard PANs/DANs. A new salt is randomly
generated for each PAN/DAN. In one 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., output hash value, (but not the original PAN/DAN) can be stored
in a local memory or sent to access server 330. Hashing allows for later authentication
without keeping and therefore risking exposure of the PAN/DAN if the authentication data
store is compromised. In one implementation, the PAN/DAN read by terminal 320 can be
13 to 19 digits. In one implementation, the hashed PAN (PANISAL T) or hashed DAN
(DANISAL T) can be generated by a SHA256 hash function. For the sake of simplicity,
wherever the present disclosure describes implementations related to a PAN, the same
methods described herein can be applied to DANs and/or tokens presented by mobile
and/or wearable devices.
With respect to the generating “cryptographic input”, as set forth above in the claim interpretation such inputs are analogous to SALT applied in hashing in light of the specification. As evidence that the application of SALT in hashing is well known and understood the examiner provides: “Introduction to the Hash Function as a Personal Data Pseudonymisation Technique” by AEPD (2019); What is a Salt and How does it Boost Security? By Loginradius (2021); In hashing does it matter how random a Salt is? By Information Security (2012)
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
In reference to Claim 22:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a non-transitory computer readable storage medium, as in independent Claim 22. Such medium fall under the statutory category of "manufacture." Therefore, the claim is directed to a statutory eligibility category.
STEP 2A Prong 1. The instructions executed by the processor of medium claim 22 corresponds to steps of method claim 1. Therefore, claim 22 has been analyzed and rejected as being directed toward an abstract idea of the categories of concepts directed toward methods of organizing human activity previously discussed with respect to claim 1.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a non-transitory computer readable storage medium having instructions executable by at least one processor, additional elements include asset verifier terminal, smart contract, blockchain.
The operations of the processors to perform functions that corresponds to steps of method claim 1. Therefore, claim 21 has been analyzed and rejected as failing to provide limitations that are indicative of integration into a practical application, as previously discussed with respect to claim 1.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements beyond the abstract idea include a non-transitory computer readable storage medium having instructions executable by at least one processor, additional elements include asset verifier terminal, smart contract, blockchain. The one or more processors of the asset server to perform the operations “generate …cryptographic input”, “provide …input”, “receiving …identifier…the hashed identifier generated by applying a hash function” to identifiers, “cause mapping service contract to store an association”, “receive …a query” and “determine …whether …identifier is associated with…assets”–is purely functional and generic. Nearly every server for implementing a method will include one or more “processor” capable of performing the basic computer functions -of “generate cryptographic input”, “provide…input”, “receive…identifier”, “cause…to store an association”, “apply hash function”, “receive …a query”, and “determine …identifier associated with …assets” - As a result, none of the hardware recited by the medium claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers. tThe claim is not "truly drawn to a specific" computer readable medium, but rather is directed toward the method of claim 1. The "incidental use" of a processor did not allow the claim to meet the Alice 2A or 2B requirements
The operations of system 22 corresponds to the steps of method claim 1. Therefore, claim 22 has been analyzed and rejected as failing to provide additional elements that amount to an inventive concept –i.e. significantly more than the recited judicial exception. Furthermore, as previously discussed with respect to claim 1, the limitations when considered individually, as a combination of parts or as a whole fail to provide any indication that the elements recited are unconventional or otherwise more than what is well understood, conventional, routine activity in the field.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
[0085] 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, for example, include a hard disk device/drive, an optical disk device, 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.
[0087] As mentioned above, Category 5 terminal is provided for simple access. The credential type 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 (GOA) is not necessary. Further, the terminal (e.g., terminal 320, asset verifier terminal 412, gantry 412) reads the access ID or PAR from the EMV card, mobile device or wearable device and provides access. In one implementation, the access ID can be read using a third party data and the PAR can be read via an EMV card or token. In another implementation, 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 upon verification by a remote access server, e.g., access server 330. The terminal can be provided using a software data kit (SOK), no application transaction counter (ATC) update is required, and the certification requirements for the terminal are low. The terminal SOK can be implemented on a computer operating system or implemented on a mobile device operating system, e.g., for a phone, tablet or similar mobile device.
[0093] 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
interconnected by a communication network.
[0094] The processes and logic flows described in this specification are 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 tying the process to a particular machine (e.g., a 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).
[0095] 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.
The specification nominally mentions a cryptographic operation without techncial details:
[0039] In one implementation, a hashed PAN or digital account number (DAN) is
generated using the following method. 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 passphrase. Salts are used to safeguard PANs/DANs. A new salt is randomly
generated for each PAN/DAN. In one 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., output hash value, (but not the original PAN/DAN) can be stored
in a local memory or sent to access server 330. Hashing allows for later authentication
without keeping and therefore risking exposure of the PAN/DAN if the authentication data
store is compromised. In one implementation, the PAN/DAN read by terminal 320 can be
13 to 19 digits. In one implementation, the hashed PAN (PANISAL T) or hashed DAN
(DANISAL T) can be generated by a SHA256 hash function. For the sake of simplicity,
wherever the present disclosure describes implementations related to a PAN, the same
methods described herein can be applied to DANs and/or tokens presented by mobile
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses:
[0083] FIG. 19 is a block diagram of a hardware configuration 1900 operable as a device in an identity, payment and access system 100 as well as the asset discovery system 400. Hardware configuration 1900 may be utilized to implement one or more of elements as described with reference to FIGS 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, for example, be interconnected 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.
[0072] Fig. 13 is a diagram of a system 1300 for providing transit system access. In certain implementations, system 1300 may be used in combination (including with replaced elements) with system 400 (as described with reference to FIGS. 4-6). System 1300 includes a transportation key card 1305, gantry/terminal 1310 coupled to one or
more fleet terminals 1355 and access kernel 1350, a terminal backend 1315 of a transit system provider that includes a local server 1320, a cloud server 1325 and PL/SOL Server Pages (PSP), an access server 1335, a payment network 1340, and an issuer 1345.
[0079] Fig. 17 is a diagram of a system 1700 for providing employee onboarding and employee access. In certain implementations, system 1700 may be used in combination (including with replaced elements) with system 400 (as described with reference to FIGS. 4-6). System 1700 includes an EMV card 1705, gantry/terminal 1710 having a gantry 1715 and one or more terminals 17 45, a gantry backoffice 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.
With respect to cryptographical inputs and hashing operations the specification nominally mentions the application.
[0039] In one implementation, a hashed PAN or digital account number (DAN) is
generated using the following method. 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 passphrase. Salts are used to safeguard PANs/DANs. A new salt is randomly
generated for each PAN/DAN. In one 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., output hash value, (but not the original PAN/DAN) can be stored
in a local memory or sent to access server 330. Hashing allows for later authentication
without keeping and therefore risking exposure of the PAN/DAN if the authentication data
store is compromised. In one implementation, the PAN/DAN read by terminal 320 can be
13 to 19 digits. In one implementation, the hashed PAN (PANISAL T) or hashed DAN
(DANISAL T) can be generated by a SHA256 hash function. For the sake of simplicity,
wherever the present disclosure describes implementations related to a PAN, the same
methods described herein can be applied to DANs and/or tokens presented by mobile
With respect to the generating “cryptographic input”, as set forth above in the claim interpretation such inputs are analogous to SALT applied in hashing in light of the specification. As evidence that the application of SALT in hashing is well known and understood the examiner provides: “Introduction to the Hash Function as a Personal Data Pseudonymisation Technique” by AEPD (2019); What is a Salt and How does it Boost Security? By Loginradius (2021); In hashing does it matter how random a Salt is? By Information Security (2012)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 5, 8-13, 15 and 17-18; Claim(s) 21 and Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2022/0172198 A1 by Gaur et al (Gaur) in view of “PBKDF2 for identifier hashing (not password) in NetCore” by Overstack (Overstack) and further in view of US Pub No. 2023/0401574 A1 by Smith et al. (Smith).
In reference to Claim 1:
Gaur teaches:
(Currently Amended) A method ((Gaur) in at least para 0025) comprising: …
providing, by the access server, the ….[hashed] input to an asset verifier terminal ((Guar) in at least para 0049-0050, para 0070)
receiving, by the access server, a hashed identifier, wherein the hashed identifier is generated at the asset verifier terminal by applying the cryptographic hash function to a personal account number (PAN) or electronic application identifier associated with a card corresponding to a consumer … provided by the access server ((Gaur) in at least para 0029-0033, para 0037, para 0049, para 0063, para 0066, para 0111, para 0116-0121, para 0137)
Causing, by the access server, a mapping service contract comprising a smart contract deployed on a blockchain to store, on the blockchain, …hashed identifier …,. ((Gaur) in at least FIG. 6A-C; Abstract; para 0002-0004, para 0029-0030, para 0033-0035 wherein the prior art teaches payment card values with tokens with mapping between tokens and teaches transitions from chaincode/contract invocations submitted, underlying payment values stored in token vault (wallet) and teaches the ledger representing chain transaction log where the chaincode/contract invocations execute transactions against current state data of ledger where the chaincode key values are stored in a state database that is an indexed view into the chains transaction log which can be regenerated from the chain at any time; para 0035, para 0037, para 0041, para 0050, para 0055, para 0058-0060, para 0063, para 0085, para 0089-0090, para 0110 wherein the prior art teaches digital content may be stored in storage memory address in association with the hash value of the original file where the storage area may be the blockchain)
receiving, by the access server from theasset verifier terminal, a query request comprising the hashed identifier, the query request corresponding to a request to determine whether one or more digital assets recorded on the blockchain are associated with the hashed identifier, ((Gaur) in at least Abstract; para 0002-0003, para 0035-0036 wherein the prior art teaches applying tokenization in payment card processing where the toke service provide substitutes PAN with tokens using the mapping between the token and underlying payment data values including (payment account number, PAN, expiry etc) where the token service based on mapped data stored in token vault (wallet) returns the PAN to enable the account to be verified , para 0037-0038 wherein the prior art teaches tokenization is the encryption/hashing of the card data which includes the PAN where the token is stored in the wallet of mobile device and used to perform transaction when user swipes/request for payment in transactions, para 0045 wherein the token transfer causes movement of assets from a first user account to a second user account, para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance); and
determining, by the access server, via the mapping service contract, whether the hashed identifier is associated with the one or more digital assets.((Gaur) in at least para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance)
Gaur suggest but does not explicitly teach:
an association between a hashed identifier and a blockchain wallet account address…((Gaur) in at least para Abstract wherein the prior art teaches data mapped to data stored within token vault; para 0033-0035 wherein the prior art teaches mapping between the token and payment data values stored in the token vault the data type including PAN data; para 0048,para 0050, para 0052, para 0080 wherein the prior art teaches mobile wallet include tokenized payment data where the service provider store the token ID as well as other data within token vault, para 0074-0075, para 0079)
Although the prior art Gaur does not explicitly teaches associating the hashed identifier (token) and wallet account address, the prior art does teach mapping the token to wallet payment account identifiers stored within the blockchain token vault and ledger. In blockchain technology each ledger must have its own unique address in the chain, which provides some teaching or motivation that would have led one of ordinary skill in the art to modify the prior art with a reasonable expectation of success as the teaching of the mapping includes mapping the wallet payment account data to the token identifier.
Gaur does not explicitly teach:
generating, by an access server, cryptographic input for use in a cryptographic hash function;
…wherein the hashed identifier is generated ….in combination with the cryptographic input provided by the access server
Overstack teaches:
generating, by an access server, cryptographic input for use in a cryptographic hash function ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function);
providing, by the access server, the cryptographic input to … terminal ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function);
receiving, by the access server, a hashed identifier, wherein the hashed identifier is generated at the … by applying the cryptographic hash function to a … identifier associated …. in combination with the cryptographic input provided by the …[computer] ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function)
Both Gaur and Overstack are directed toward hashing identifiers associated with data that is stored in a database. Overstack teaches the motivation of salting that are hashed again upon receipt (generating cryptographic input) before storing in database, for increased security. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the hashing of identifiers of Gaur to include generating a salt for each identifier value before hashing as taught by Overstack since Overstack teaches the motivation of salting that are hashed again upon receipt (generating cryptographic input) before storing in database, for increased security.
Smith teaches:
causing …contract …to store, on the blockchain, an association between a hashed identifier and a blockchain wallet account address ((Smith) in at least para 0017-0019, para 0021-0022, para 0024, para 0026, para 0028, para 0039, para 0047, para 0052; claim 1, Claim 15)
Both Gaur and Smith are directed toward blockchain transfer of digital assets. Smith teaches the motivation of in a banking regime compliance in global economics to provide a solution that links unregulated accounts for use of blockchain into a regulated environment that it is needed to link unregulated wallet accounts into regulated wallet accounts with the solution being associating the wallet addresses and identifiers. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the association of blockchain asset information of Gaur to include associating the wallet address and identifiers of the wallet accounts as taught by Smith since Smith teaches the motivation of in a banking regime compliance in global economics to provide a solution that links unregulated accounts for use of blockchain into a regulated environment that it is needed to link unregulated wallet accounts into regulated wallet accounts with the solution being associating the wallet addresses and identifiers.
In reference to Claim 2:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 2
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), wherein
the association between the hashed identifier and the blockchain wallet account address is stored on the blockchain prior to a digital asset transaction. ((Guar) in at least para 0035, para 0038, para 0050)
In reference to Claim 3:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 2. Gaur further discloses the limitations of dependent claim 3
(Previously Presented) The method of claim 1, wherein determining, by the access server, via the mapping service contract (see rejection of claim 1 above), whether the hashed identifier is associated with the one or more digital assets includes:
invoking, by the access server, a function of the mapping service contract, the function being configured to receive the hashed identifier and the blockchain wallet account address as inputs and write the association on the blockchain ((Gaur) in at least para 0068, para 0080; Claim 1, Claim 8)
In reference to Claim 5:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 1. Gaur further discloses the limitations of dependent claim 5
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), wherein the one or more digital assets comprise:
non- fungible tokens (NFTs), semi-fungible tokens (SFTs), or tokens ((Gaur) in at least Abstract; para 0035, para 0050).
In reference to Claim 8:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 8
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
wherein the association between the hashed identifier and the blockchain wallet account address is stored on the blockchain is performed concurrent to a digital asset transaction. ((Gaur) in at least para 0028, para 0041-0042, para 0047, para 0054-0055, para 0088-0089)
In reference to Claim 9:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 8. Gaur further discloses the limitations of dependent claim 9
(Previously Presented) The method of claim 8 (see rejection of claim 8 above),
Wherein the PAN or the electronic identifier associated with the card corresponding to the consumer is mapped to a merchant computer system. ((Gaur) in at least para 0035, para 0083, para 0087)
In reference to Claim 10:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 8. Gaur further discloses the limitations of dependent claim 10
(Previously Presented) The method of claim 8 (see rejection of claim 8 above), wherein
the card is coupled to the asset verifier terminal. ((Gaur) in at least para 0035-0036, para 0045-0046, para 0055, para 0059),
In reference to Claim 11:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 10. Gaur further discloses the limitations of dependent claim 11
(Previously Presented) The method of claim 10 (see rejection of claim 10 above), further comprising:
processing, by the asset verifier terminal, the PAN or the electronic application identifier (eaid) associated with the card((Gaur) in at least para 0035, para 0063, para 0109, para 0111, para 0113, para 0117-0121; Table 1-2); and
generating, by the asset verifier terminal, the hashed identifier based on the PAN or the electronic application identifier ((Gaur) in at least para 0035 wherein the prior art teaches tokenizing the PAN, para 0037, para 0041, para 0050, para 0055-0056, para 0063, para 0080-0081, para 0097-0098, para 0103-0106, para 0109-0113)
In reference to Claim 12:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 11. Gaur further discloses the limitations of dependent claim 12
(Previously Presented) The method of claim 11 (see rejection of claim 11 above), further comprising:
requesting, by the asset verifier terminal, the mapping service contract stored on the access server for the one or more digital assets ((Gaur) in at least Abstract; para 0002-0004, para 0035).
In reference to Claim 13:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 13
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), wherein determining, by the access server, via the mapping service contract, whether the hashed identifier is associated with the one or more digital assets .((Gaur) in at least para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance) includes
invoking, by the access server, a function of the mapping service contract ((Guar) in at least para 0049), the function being configured to:
receive the hashed identifier as input ((Guar) in at least para 0049-0050, para 0070);
retrieve, from the blockchain, the blockchain wallet account address associated with the hashed identifier ((Gaur) in at least para 0051-0053, para 0060, para 0063, para 0074); and
query an asset contract using the blockchain wallet account address to determine whether the blockchain wallet account address is associated with the one or more digital assets ((Gaur) in at least para 0060-0061, para 0063, para 0071, para 0073, para 0110, ).
Smith teaches:
wallet account address…((Smith) in at least para 0015, para 0020, para 0040, para 0048, para 0053, para 0060-0063)
Both Gaur and Smith are directed toward blockchain wallet transactions. Smith teaches the motivation of query a wallet address associated with a contract in order to verify the unregulated wallet on the ledger. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the association of blockchain asset information of Gaur to include contract using a blockchain address as taught by Smith since Smith teaches the motivation of query a wallet address associated with a contract in order to verify the unregulated wallet on the ledger.
In reference to Claim 15:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 15
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), wherein the one or more digital assets comprise:
non- fungible tokens (NFTs), semi-fungible tokens (SFTs), or tokens. ((Gaur) in at least Abstract; para 0035, para 0050).
In reference to Claim 17:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 17:
(Original) The method of claim 1 (see rejection of claim 1 above),
wherein the card is a chip card corresponding to a Europay, Mastercard, Visa (EMV) card. ((Gaur) in at least para 0037)
In reference to Claim 18:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 18:
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
wherein the card is configured for presentation via a mobile device, a wearable device, or a contactless Europay, Mastercard, Visa (EMV) card. ((Gaur) in at least para 0037-0038)
In reference to Claim 21:
Gaur teaches:
(New) A system((Gaur) in at least Abstract) comprising:
an access server, comprising: one or more first processors ((Gaur) in at least FIG. 6A-C; para 0090); and
one or more first memory comprising a plurality of first program instructions which, when executed by the one or more first processors ((Gaur) in at least FIG. 6A-C; para 0090-0092), cause the one or more first processors to:…
provide the ….[hashed] input to an asset verifier terminal ((Guar) in at least para 0049-0050, para 0070)
receive a hashed identifier, wherein the hashed identifier is generated at the asset verifier terminal by applying the cryptographic hash function to a personal account number (PAN) or electronic application identifier associated with a card corresponding to a consumer … provided by the access server ((Gaur) in at least para 0029-0033, para 0035, para 0037, para 0049-0050, para 0063, para 0066, para 0111, para 0116-0121, para 0137)
Cause a mapping service contract comprising a smart contract deployed on a blockchain to store, on the blockchain, …hashed identifier …,. ((Gaur) in at least FIG. 6A-C; Abstract; para 0002-0004, para 0029-0030, para 0033-0035 wherein the prior art teaches payment card values with tokens with mapping between tokens and teaches transitions from chaincode/contract invocations submitted, underlying payment values stored in token vault (wallet) and teaches the ledger representing chain transaction log where the chaincode/contract invocations execute transactions against current state data of ledger where the chaincode key values are stored in a state database that is an indexed view into the chains transaction log which can be regenerated from the chain at any time; para 0035, para 0037, para 0041, para 0050, para 0055, para 0058-0060, para 0063, para 0085, para 0089-0090, para 0110 wherein the prior art teaches digital content may be stored in storage memory address in association with the hash value of the original file where the storage area may be the blockchain)
receive from the asset verifier terminal, a query request comprising the hashed identifier, the query request corresponding to a request to determine whether one or more digital assets recorded on the blockchain are associated with the hashed identifier, ((Gaur) in at least Abstract; para 0002-0003, para 0035-0036 wherein the prior art teaches applying tokenization in payment card processing where the toke service provide substitutes PAN with tokens using the mapping between the token and underlying payment data values including (payment account number, PAN, expiry etc) where the token service based on mapped data stored in token vault (wallet) returns the PAN to enable the account to be verified , para 0037-0038 wherein the prior art teaches tokenization is the encryption/hashing of the card data which includes the PAN where the token is stored in the wallet of mobile device and used to perform transaction when user swipes/request for payment in transactions, para 0045 wherein the token transfer causes movement of assets from a first user account to a second user account, para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance); and
determine via the mapping service contract, whether the hashed identifier is associated with the one or more digital assets.((Gaur) in at least para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance)
Gaur suggest but does not explicitly teach:
an association between a hashed identifier and a blockchain wallet account address…((Gaur) in at least para Abstract wherein the prior art teaches data mapped to data stored within token vault; para 0033-0035 wherein the prior art teaches mapping between the token and payment data values stored in the token vault the data type including PAN data; para 0048,para 0050, para 0052, para 0080 wherein the prior art teaches mobile wallet include tokenized payment data where the service provider store the token ID as well as other data within token vault, para 0074-0075, para 0079)
Although the prior art Gaur does not explicitly teaches associating the hashed identifier (token) and wallet account address, the prior art does teach mapping the token to wallet payment account identifiers stored within the blockchain token vault and ledger. In blockchain technology each ledger must have its own unique address in the chain, which provides some teaching or motivation that would have led one of ordinary skill in the art to modify the prior art with a reasonable expectation of success as the teaching of the mapping includes mapping the wallet payment account data to the token identifier.
Gaur does not explicitly teach:
Generate cryptographic input for use in a cryptographic hash function;
…wherein the hashed identifier is generated ….in combination with the cryptographic input provided by the access server
Overstack teaches:
Generate cryptographic input for use in a cryptographic hash function ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function);
Provide the cryptographic input to … terminal ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function);
receive a hashed identifier, wherein the hashed identifier is generated at the … by applying the cryptographic hash function to a … identifier associated …. in combination with the cryptographic input provided by the …[computer] ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function)
Both Gaur and Overstack are directed toward hashing identifiers associated with data that is stored in a database. Overstack teaches the motivation of salting that are hashed again upon receipt (generating cryptographic input) before storing in database, for increased security. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the hashing of identifiers of Gaur to include generating a salt for each identifier value before hashing as taught by Overstack since Overstack teaches the motivation of salting that are hashed again upon receipt (generating cryptographic input) before storing in database, for increased security.
Smith teaches:
cause …contract …to store, on the blockchain, an association between a hashed identifier and a blockchain wallet account address ((Smith) in at least para 0017-0019, para 0021-0022, para 0024, para 0026, para 0028, para 0039, para 0047, para 0052; claim 1, Claim 15)
Both Gaur and Smith are directed toward blockchain transfer of digital assets. Smith teaches the motivation of in a banking regime compliance in global economics to provide a solution that links unregulated accounts for use of blockchain into a regulated environment that it is needed to link unregulated wallet accounts into regulated wallet accounts with the solution being associating the wallet addresses and identifiers. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the association of blockchain asset information of Gaur to include associating the wallet address and identifiers of the wallet accounts as taught by Smith since Smith teaches the motivation of in a banking regime compliance in global economics to provide a solution that links unregulated accounts for use of blockchain into a regulated environment that it is needed to link unregulated wallet accounts into regulated wallet accounts with the solution being associating the wallet addresses and identifiers.
In reference to Claim 22:
Gaur teaches:
(New) At least one non-transitory computer-readable storage medium having computer-executable instructions stored thereon, wherein, when executed by at least one processor ((Gaur) in at least para 0025, para 0028, para 0094) the computer-executable instructions cause the at least one processor to: …
provide the ….[hashed] input to an asset verifier terminal ((Guar) in at least para 0049-0050, para 0070)
receive a hashed identifier, wherein the hashed identifier is generated at the asset verifier terminal by applying the cryptographic hash function to a personal account number (PAN) or electronic application identifier associated with a card corresponding to a consumer … provided by the access server ((Gaur) in at least para 0029-0033, para 0035, para 0037, para 0049-0050, para 0063, para 0066, para 0111, para 0116-0121, para 0137)
Cause a mapping service contract comprising a smart contract deployed on a blockchain to store, on the blockchain, …hashed identifier …,. ((Gaur) in at least FIG. 6A-C; Abstract; para 0002-0004, para 0029-0030, para 0033-0035 wherein the prior art teaches payment card values with tokens with mapping between tokens and teaches transitions from chaincode/contract invocations submitted, underlying payment values stored in token vault (wallet) and teaches the ledger representing chain transaction log where the chaincode/contract invocations execute transactions against current state data of ledger where the chaincode key values are stored in a state database that is an indexed view into the chains transaction log which can be regenerated from the chain at any time; para 0035, para 0037, para 0041, para 0050, para 0055, para 0058-0060, para 0063, para 0085, para 0089-0090, para 0110 wherein the prior art teaches digital content may be stored in storage memory address in association with the hash value of the original file where the storage area may be the blockchain)
receive from the asset verifier terminal, a query request comprising the hashed identifier, the query request corresponding to a request to determine whether one or more digital assets recorded on the blockchain are associated with the hashed identifier, ((Gaur) in at least Abstract; para 0002-0003, para 0035-0036 wherein the prior art teaches applying tokenization in payment card processing where the toke service provide substitutes PAN with tokens using the mapping between the token and underlying payment data values including (payment account number, PAN, expiry etc) where the token service based on mapped data stored in token vault (wallet) returns the PAN to enable the account to be verified , para 0037-0038 wherein the prior art teaches tokenization is the encryption/hashing of the card data which includes the PAN where the token is stored in the wallet of mobile device and used to perform transaction when user swipes/request for payment in transactions, para 0045 wherein the token transfer causes movement of assets from a first user account to a second user account, para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance); and
determine via the mapping service contract, whether the hashed identifier is associated with the one or more digital assets.((Gaur) in at least para 0050 wherein the prior art teaches the token including PAN issued that has been mapped, para 0052-0053 wherein the prior art teaches token server for payment transaction on a blockchain network creates a settlement token submitted where both issuer and acquirer are participants in blockchain, para 0055, para 0059-0060, para 0063, para 0075, para 0080-0081, para 0086, para 0142 wherein the prior art teaches assets can be any type of asset (machine, equipment, oil, gas, boats, stocks, digital coins, insurance)
Gaur suggest but does not explicitly teach:
an association between a hashed identifier and a blockchain wallet account address…((Gaur) in at least para Abstract wherein the prior art teaches data mapped to data stored within token vault; para 0033-0035 wherein the prior art teaches mapping between the token and payment data values stored in the token vault the data type including PAN data; para 0048,para 0050, para 0052, para 0080 wherein the prior art teaches mobile wallet include tokenized payment data where the service provider store the token ID as well as other data within token vault, para 0074-0075, para 0079)
Although the prior art Gaur does not explicitly teaches associating the hashed identifier (token) and wallet account address, the prior art does teach mapping the token to wallet payment account identifiers stored within the blockchain token vault and ledger. In blockchain technology each ledger must have its own unique address in the chain, which provides some teaching or motivation that would have led one of ordinary skill in the art to modify the prior art with a reasonable expectation of success as the teaching of the mapping includes mapping the wallet payment account data to the token identifier.
Gaur does not explicitly teach:
Generate cryptographic input for use in a cryptographic hash function;
…wherein the hashed identifier is generated ….in combination with the cryptographic input provided by the access server
Overstack teaches:
Generate cryptographic input for use in a cryptographic hash function ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function);
Provide the cryptographic input to … terminal ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function);
receive a hashed identifier, wherein the hashed identifier is generated at the … by applying the cryptographic hash function to a … identifier associated …. in combination with the cryptographic input provided by the …[computer] ((Overstack) in at least page 1, wherein the prior art teaches hashing identifiers before storing in a database an adding a salt to each value before hashing using a hash function)
Both Gaur and Overstack are directed toward hashing identifiers associated with data that is stored in a database. Overstack teaches the motivation of salting that are hashed again upon receipt (generating cryptographic input) before storing in database, for increased security. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the hashing of identifiers of Gaur to include generating a salt for each identifier value before hashing as taught by Overstack since Overstack teaches the motivation of salting that are hashed again upon receipt (generating cryptographic input) before storing in database, for increased security.
Smith teaches:
cause …contract …to store, on the blockchain, an association between a hashed identifier and a blockchain wallet account address ((Smith) in at least para 0017-0019, para 0021-0022, para 0024, para 0026, para 0028, para 0039, para 0047, para 0052; claim 1, Claim 15)
Both Gaur and Smith are directed toward blockchain transfer of digital assets. Smith teaches the motivation of in a banking regime compliance in global economics to provide a solution that links unregulated accounts for use of blockchain into a regulated environment that it is needed to link unregulated wallet accounts into regulated wallet accounts with the solution being associating the wallet addresses and identifiers. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the association of blockchain asset information of Gaur to include associating the wallet address and identifiers of the wallet accounts as taught by Smith since Smith teaches the motivation of in a banking regime compliance in global economics to provide a solution that links unregulated accounts for use of blockchain into a regulated environment that it is needed to link unregulated wallet accounts into regulated wallet accounts with the solution being associating the wallet addresses and identifiers.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2022/0172198 A1 by Gaur et al (Gaur) in view of “PBKDF2 for identifier hashing (not password) in NetCore” by Overstack (Overstack) in view of US Pub No. 2023/0401574 A1 by Smith et al. (Smith) as applied to claim 1 above, and further in view of US Patent No. 11,790,418 B1 by Jay et al. (Jay)
In reference to Claim 4:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 4:
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), wherein the one or more assets are associated with
Gaur does not explicitly teach:
one or more asset contracts generated by a merchant computer system
Jay teaches:
one or more asset contracts generated by a merchant computer system. ((Jay) in at least Col 2 lines 5-21, Col 4 lines 10-15, Col 49 lines 34-53)
Both Gaur and Jay are directed toward transactions applying smart contracts. Jay teaches the motivation of creating a purchase mechanism (smart contract) to incentivize a buyer when the buyer executes a purchase action as defined in the smart contract. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the details of smart contract application of transactions of Gaur to include merchants creating smart contracts of Jay since Jay teaches the motivation of creating a purchase mechanism (smart contract) to incentivize a buyer when the buyer executes a purchase action as defined in the smart contract.
Claim(s) 6-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2022/0172198 A1 by Gaur et al (Gaur) in view of “PBKDF2 for identifier hashing (not password) in NetCore” by Overstack (Overstack) in view of US Pub No. 2023/0401574 A1 by Smith et al. (Smith) as applied to claim 1 above, and further in view of US Pub No. 2023/0419303 A1 by Araki et al. (Araki)
In reference to Claim 6:
The combination of Gaur, Overstack and Smith discloses the limitations of independent claim 1. Gaur further discloses the limitations of dependent claim 6
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Gaur does not explicitly teach:
wherein the one or more digital assets are associated with one or more asset contracts on the blockchain listed by a merchant computer system on a digital marketplace
Araki teaches:
wherein the one or more digital assets are associated with one or more asset contracts on the blockchain listed by a merchant computer system on a digital marketplace. ((Araki) in at least FIG. 9, FIG. 14, FIG. 21; para 0121, para 0135, para 0178, para 0239-0241, para 0243)
Both Gaur and Araki are directed toward transaction with wallets for NFT transactions. Araki teaches the motivation of creating a list of user assets own to be presented in order to provide to the user information on all or some of the assets owned and to identify the assets owned. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the details of the asset tokens stored on the wallet of Gaur to include a list of assets owned as taught by Araki since Araki teaches the motivation of creating a list of user assets own to be presented in order to provide to the user information on all or some of the assets owned and to identify the assets owned.
In reference to Claim 7:
The combination of Gaur, Overstack, Smith and Araki discloses the limitations of dependent claim 6. Gaur further discloses the limitations of dependent claim 7
(Previously Presented) The method of claim 6 (see rejection of claim 6 above),
wherein the PAN or the electronic application identifier associated with the card corresponding to the consumer is associated with a digital wallet coupled with an issuer computer system ((Gaur) in at least para 0035-0039, para 0050, para 0056, para 0058, para 0060, para 0075, para 0080-0081, para 0085, para 0087, para 0092, para 0142), and wherein the one or more digital assets are configured to be stored on the digital wallet ((Gaur) in at least para 0038, para 0043, para 0045-0046).
Araki provides additional support:
acquiring, by the consumer via the consumer device, the one or more asset contracts, wherein the one or more digital assets are configured to be stored on the digital wallet ((Araki) in at least Abstract; para 0006, para 0079, para 0082-0084, para 0121, para 0135, para 0178, para 0239-0241, para 0243)
Both Gaur and Araki are directed toward transaction with wallets for NFT transactions. Araki teaches the motivation of acquiring smart contracts based on NFT transaction data of tokenized assets where NFT issued to the address of a wallet so contract can be executed based on the exchange in rate and to the tokens exchanged. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the details of the contracts with respect to NFT tokens of Gaur to include additional support of contracts acquired related to tokens stored as taught by Araki since Araki teaches the motivation of acquiring smart contracts based on NFT transaction data of tokenized assets where NFT issued to the address of a wallet so contract can be executed based on the exchange in rate and to the tokens exchanged..
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2022/0172198 A1 by Gaur et al (Gaur) in view of “PBKDF2 for identifier hashing (not password) in NetCore” by Overstack (Overstack) in view of US Pub No. 2023/0401574 A1 by Smith et al. (Smith) as applied to claim 13 above, and further in view of US Pub No. 2023/0334492 A1 by Tai et al (Tai)
In reference to Claim 14:
The combination of Gaur, Overstack, and Smith discloses the limitations of dependent claim 13. Gaur further discloses the limitations of dependent claim 14
(Previously Presented) The method of claim 13 (see rejection of claim 13 above), further comprising:
Gaur does not explicitly teach:
generating, by the access server, a response to the query request based on determining that the blockchain wallet account address is associated with the one or more digital assets, wherein the response identifies the one or more digital assets and at least one digital asset of the one or more digital assets is configured to represent an entitlement; and
providing, by the access server, the response to the asset verifier terminal.
Tai teaches:
generating, by the access server, a response to the query request based on determining that the hashed identifier is associated with the one or more digital assets, wherein the response identifies the one or more digital assets and at least one digital asset of the one or more digital assets is configured to represent an entitlement ((Tai) in at least para 0051-0052, para 0064-0065, para 0182, para 0184-0185, para 0197); and
providing, by the access server, the response to the asset verifier terminal. ((Tai) in at least para 0101-0102, para 0197, para 0214)
Both Gaur and Tai are directed toward wallet transaction that apply NFT representing assets. Tai teaches the motivation of issuing tickets as NFT’s associated with smart contracts that can be transferred via wallet transactions where the smart contracts provide instructions on the transfer of ownership and can cause different portions of the value of the token to be transferred to designated parties and providing verification of the redemption of the ticket by a user account holding the ticket. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the details with respect to wallet NFT process of Gaur to include the digital assets representing entitlement/tickets as taught by Tai since Tai teaches the motivation of issuing tickets as NFT’s associated with smart contracts that can be transferred via wallet transactions where the smart contracts provide instructions on the transfer of ownership and can cause different portions of the value of the token to be transferred to designated parties and providing verification of the redemption of the ticket by a user account holding the ticket.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2022/0172198 A1 by Gaur et al (Gaur) in view of “PBKDF2 for identifier hashing (not password) in NetCore” by Overstack (Overstack) in view of US Pub No. 2023/0401574 A1 by Smith et al. (Smith) as applied to claim 15 above, and further in view of US Patent No. 12,093,948 B2 by Ferenczi et al. (Ferenczi)
In reference to Claim 16:
The combination of Gaur, Overstack and Smith discloses the limitations of dependent claim 15. Gaur further discloses the limitations of dependent claim 16
(Original) The method of claim 15 (see rejection of claim 15 above), wherein the one or more digital assets comprise
Gaur does not explicitly teach:
an NFT or SFT corresponding to a loyalty profile.
Ferenczi teaches:
an NFT or SFT corresponding to a loyalty profile. ((Ferenczi) in at least Col 11 lines 40-65, Col 13 lines 18-35),
Both Gaur and Ferenczi are directed toward transactions applying smart contracts. Ferenczi teaches the motivation of generating different payment types for which token keys are generated in order to increase security. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the details of smart contract application of transactions of Gaur to include different payment types as taught by Ferenczi since Ferenczi teaches the motivation of generating different payment types for which token keys are generated in order to increase security.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US Pub No. 2022/0311597 A1 by Goel wherein the prior art teaches in distributed ledger environment creating an encrypted key to be applied to a token and salt (Abstract; para 0008 wherein the prior art teaches salt cryptology is known in the art; para 0032); US Pub No. 2020/0067701 A1 by Abadir et al- abstract; para 0006; US Pub No. 2018/0357434 A1 by Roy – para 0111; NPL articles Adding Salt to Hashing: A Better Way to Store Passwords” by Aries (2018); Generate SHA512 Hash by Ramdommer (2020): Blockchain 1.0 to Blockchain 4.0—The Evolutionary Transformation of Blockchain Technology; Cryptography: How is it Related to Blockchain? by Majumder
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Behncke can be reached at 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARY M GREGG/Examiner, Art Unit 3695
Prosecution Insights