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 Final Office Action in response to communications received August 27, 2026. Claim(s) 19-20 have been canceled. Claim(s) 1-2 and 21-22 have been amended. New claims 21-22 have been added. Therefore, claims 1-18 and 21-22 are pending and addressed below.
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 08/27/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 Alice and MPEP 2106, MPEP 2106.04(II)(A), MPEP 2106.04(a) discussing the step 2 analysis and requirements for patent eligibility. Applicant argues that step 2A prong 1, the claimed limitations are not directed toward a business process that correlates data between sources failing in the category of commercial interactions. The claimed limitations as a whole is directed toward cryptographic credential verification architecture that governs how a hash identifier is generated, what information if available to each system component and what information is intentionally withheld from each system component. The recited specific technological mechanism for securely generating and verifying a cryptographically-derived identifier while preventing disclosure of underlying credential information reciting the amended limitations which as a whole does not recite a commercial interaction, economic practice or other methods of organizing human activity. Applicant argues the recited limitations define a specific cryptographic architecture in which credential information and inputs are intentionally separated across distinct computing components. The access server possesses the server generated salt value without receiving the PAN or EAI. The asset verifier terminal possesses the PAN or EAI but can only generate a valid hash identifier with the server provisioned salt value. This process results in generation of hashed identifier requires coordinated operation between the access server and asset verifier terminal. Applicant’s argument is not persuasive. The specification (para 0030) discloses the focus of the invention is directed toward performing transactions between a merchant and a customer wallet where the wallet coupled to a blockchain address stores assets used to purchase goods from the merchant. The specification discloses applying asset verifier to verify ownership of assets identified by contracts and other identifiers to verify ownership by reading a hashed identifier representing a PAN or EAI. The specification describes querying a mapping contract stored on an accessible blockchain to retrieve the asset for use in the transaction- which is explicitly describing a transaction process (e.g. commercial activity). The specification further discloses hashing PAN or DAN or EAI identifier using a provisions salt (e.g. random data fed as an input to a one-way function that hashes data used to mitigate risk/fraud attacks). The specification discloses salt provisioned as being used to safeguard PANs/DAN/EAI fed to a cryptographic hash function (for example generic SHA256) allowing for later authentication without risk of exposure of sensitive information. (para 0039, para 0070). The specification makes clear that the application of the salt provision for input to hash identifier is to mitigate risk for use in transactions. The claimed limitations which considered as a whole are directed toward “generating” a hash value representing a PAN or EAI where the generated hashed identifier is received which is applied to cause a mapping service contract (smart contract) deployed on a blockchain to store an association between the hashed identifier and a wallet account address. An asset terminal receives a query request comprising the hashed identifier to determine whether one or more digital assets recorded on the blockchain associated with the hashed identifier and determining whether the hashed identifier associated with the one or more assets. In light of the specification these limitations are applying generic technology to mitigate risk and for use in processing a transaction. The rejection is maintained.
In the remarks applicant argues that the claimed limitations under step 2A prong 2 provides a practical application. Applicant argues that under step 2A prong 2, the amended claim integrates any alleged abstract idea into a practical application under step 2A, prong two by the recitation of a specific technical architecture not a results oriented concept. The “generating…as salt value…randomly generating associated with …identifier”, “provisioning…salt value …to …terminal via …interface”, “a hashed identifier is generated by…concatenating the salt value with the …identifier and applying the …hash function to the concatenated value”, “asset verifier terminal can only generate valid hashed identifier with the …salt value”, “server receives the hashed identifier without receiving the PAN or EAI identifier”. The imposed specific technological requirements on the claimed system by requiring “generation of …salt value”, “provisioning …salt value”, “generation of …salt value at …terminal using …salt value and …credential data”, “preventing …terminal from generating…hashed identifier without salt value” and “receipt of hashed identifier…” which integrates any alleged abstract idea into a practical application. Applicant’s argument is not persuasive. A salt value generated for input into a hashing function representing identifiers in order to protect data merely applies technology to mitigate risk. The limitations with respect to the salt and hashing steps/operations are not directed toward improvement to random number generation technology or hashing function technology, instead applying generic technology to protect identifiers for use in transactions between a user wallet and merchant terminal. The limitations “causing…mapping service contract…to store an associated between the hashed identifier and blockchain wallet account address”, “receiving …query request…” and “determining …whether hashed identifier is associated with …assets” is not directed toward improvement to any of the underlying technology or technical processes for hashing data. The limitations are not directed toward providing a solution to a problem rooted or caused by technology itself. Instead the limitations merely apply technology to perform the identified abstract idea. The rejection is maintained.
In the remarks applicant points to specification (para 0029, 0031, 0034, 0039-0040, 0042, 0072), MPEP 2106.04(d) and MPEP 2106.04(d)(1), arguing the amended limitations improve computer security and credential verification technology. The technical improvement recited in the claim arises from a credential verification architecture that distributes cryptographic operations across computing components reducing exposure to sensitive credential information. Applicant emphasizes the limitations “generating…a salt value …randomly generated and …associated with a …(PAN) or EAI for use as cryptographic input in a cryptographic hash function”, “”provisioning…the salt value to a…terminal via …interface such that the terminal can only generate …hashed identifier with the salt value”, “hashed identifier …generated at the …terminal by the concatenating the salt value with the PAN or EAI and applying the hash function to the concatenated value”, “the hashed identifier…generated at …terminal using locally available PAN or EAI data …server receives the hashed identifier without receiving the PAN or EAI identifier”…., arguing these limitations define a particular technological process governing generation, distribution and use of cryptographic material across computing components. The amended limitations specifies how the cryptographic material generate and distributed and how a hashed identifier is generated and how operation of the terminal is constrained. Applicant’s argument is not persuasive. The limitations directed toward the salt value randomly generated as claimed is high level, there is not technical details that goes beyond generic high level functions of “randomly generated and …associated with a PAN/EAI identifier” associated with a card which is recited explicitly in the claim limitations for use in a hash function for use where the salt value is provided as an input to “generate a hash identifier” which is then received for use in a query request to determine assets mapped to a smart contract which is explicitly a commercial and legal activity. Applicant admits in the argument the purpose of this process is to “reducing exposure to sensitive credential information” which is not a improvement to technology or technical field. The rejection is maintained.
In the remarks applicant argues that the claimed architecture introduces coordinated cryptographic control between distributed computing components. The claimed can only generate a hashed identifier with the salt value provisioned by the access server, generation of valid credential derived identifiers depends upon cooperation between the access server and the …verifier terminal. The amended claim establishes a controlled cryptographic verification architecture rather than permitting arbitrary identifier generation by independent devices. Applicant’s argument is not persuasive. The architecture claimed recites a generic access server applied to generate a salt value whose function for generating the salt value is not dependent upon cooperation between access server and the verifier terminal. The provisioning of the salt value operation of the access server to the verifier terminal via an interface is merely applying technology to perform insignificant extra solution activity of transmitting data from the access server to the verifier terminal. The receiving “hashed identifier” by the access server generated by the verifier terminal or the limitation “receiving …a query request” by the access server are directed toward insignificant extra solution activity applying an interface for transmitting the data. The wherein clause does not further limit the receiving function instead further limits the hashed identifier data received which has no impact upon the receiving of the hashed identifier. The access server is further recited to perform at a high level the operation “causing…a mapping service contract comprising a smart contract to store an association between the hashed identifier and wallet blockchain address without any details on how the mapping service contract stores an association between identifiers and address that goes beyond any known generic means. The limitation “determining” by the access server via mapping service contract whether hashed identifier is associated with …assets” does not introduce coordinated cryptographic control between distributed computing components. With respect to the claimed architecture and limitations when considered as a combination of the limitations when considered under step 2A prong 2, the additional elements beyond the abstract idea include an access server and asset verifier terminal, where the access servers’ operations are recited at a high level directed toward a randomly generated salt value associated with a financial account identifier that is inputted/provisioned into a generic hash function for use in a query request to determine whether assets recorded are associated with the hashed identifier an in the determination as to whether the hashed identifier is associated with assets according to a service contract. The access verifier terminal does not perform any of the recited operation, instead is merely the technology applied to generate the hashed identifier received by the access server. The combination of operations of the access server is not directed toward the improvement of technology but instead used to manipulate data to prevent fraud when considered in light of the specification using generic technology for use in a commercial activity of determining whether a hashed identifier is associated with one or more digital assets according to a service contract. The rejection is maintained.
In the remarks applicant argues the amended limitations improve integrity of credential verification with the generation of hashed identifiers using locally available credential information and server provisioned salt value information maintained at different system components. The architecture improves resistance to unauthorized identifier creation and enables reliable verification of credential associations without exposing credential information. The improved distributed credential verification infrastructure by enabling asset verification through a hashed identifier stored and evaluated via blockchain based mapping service contract cooperate to perform the verification improves computer security. Applicant points to MPEP 2106.04(d) and MPEP 2106.04(d)(1), arguing the limitations recite specific technological operations performed by specific system components and therefore, the additional elements are not merely field of use limitations. Therefore, the claimed amended limitations recite additional elements that integrate the alleged abstract idea into a practical application. Applicant’s argument is not persuasive. Applying generic computer server used to generate a salt value randomly generated associated with account identifiers (PAN/EAI) that is provided to a generic asset verifier terminal which applies the salt to a hash function used to hash the identifier. The generation of the salt value and the hashing of the identifiers using the salt value/seed using generic technology has been determined by the courts as a field of use limitation. Accordingly, the hashing function as claimed with lacks details of technical implementation is considered mere data manipulation. The additional element “access server” applied to generate the “salt value” and the “access verifier terminal” applied to convert data to a hashed identifier is recited at a high level with an expected outcome of mere data manipulation. For data, mere “manipulation” of basic mathematical constructs [i.e.,] the paradigmatic ‘abstract idea,’" has not been deemed a transformation. CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011) (quoting /n re Warmerdam, 33 F.3d 1354, 1355, 1360 (Fed. Cir. 1994). Whether the transformation is extra-solution activity or a field-of-use (i.e., the extent to which (or how) the transformation imposes meaningful limits on the execution of the claimed method steps). A transformation that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not provide significantly more (or integrate a judicial exception into a practical application). Mayo, 566 U.S. at 76, 101 USPQ2d at 1967. The Supreme Court disagreed, finding that this step was only a field-of-use limitation and did not provide significantly more than the judicial exception. /d. See MPEP § 2106.05(g) & (h). The specification makes clear that the purpose of the hashing of identifiers using generic hash function is to protect sensitive data, not to improve the security of the computer technology itself. Applicant admits in the argument that the architecture claimed is to improve resistance to unauthorized identifier creation and enables reliable verification of credential associations without exposing credential information, which is directed toward mitigation of risk rather to improve upon the technology itself. The rejection is maintained.
In the remarks applicant argues that based on arguments above, independent claims 1, 21 and 22 are patent eligible and the corresponding dependent claims 2-18 are also patent eligible. The examiner respectfully disagrees see response above. The rejection is maintained.
In the remarks applicant argues that the claimed limitations under step 2B provides significantly more than any alleged abstract idea. Applicant argues the amended limitations recite an inventive concept pointing to MPEP 2106.05(I), MPEP 2106.05(I) (A). Specifically, applicant argues the claimed limitations as discussed above improve technology or technical field with the improvement of computer security or credential verification technology. The asset verifier terminal generates the hashed identifier using locally available PAN/EAI and salt value, while the access server receives hashed identifier without receiving the underlying PAN/EAI. The claimed asset verifier terminal can only generate a valid hashed identifier with the provisioned salt value, generating of credential derived identifiers requiring coordinated operation between access server and asset verifier terminal, providing concrete technological improvement to computer security and credential verification technology, satisfying step 2B. Applicant’s argument is not persuasive. The generation of the salt/seed value for use in a hashing function is not directed toward improving technology but rather to apply a known data manipulation process for encrypting/hashing data used to mitigate risk. The specification and claim limitations fail to provide any technical process for provision and generating the salt/seed value that is used to generate a hash value using a generic hash function. The purpose of the hash identifier that is determined as to whether the identifier is associate with an asset is to mitigate risk not to improve technology. Accordingly the combination of the generation of the salt value applied to a hash function to generate a hashed identifier used to perform the commercial activity of determining whether the identifier is associated with an asset in order to protect sensitive data to prevent fraud. The claimed additional elements “access server”, “access verifier terminal” or “hash function” are generic and the operations performed by these elements are high level lacking technical details and the combination of the operations performed by the access server which merely provides and receives data using interface technology to and from the access verifier terminal a hashed identifier used to perform the abstract idea and does not provide significantly more than a field of use to implement the abstract idea. The rejection is maintained.
In the remarks applicant points to MPEP 2106.05(d), arguing that the claimed limitations provides “an inventive concept” performs operations that are not well understood and routing activity in the field. Applicant recites the limitations of the claim, arguing the coordinated sequence of the cryptographic operations distributed across multiple computing components that constrains where the cryptographic material generated, how the material is distributed and the system components generate and verified credential derived identifiers which is not generic generated data processing, credential matching or conventional use of cryptographic tools, reciting specific technological architecture governs generation and verification of credential derived identifiers while reducing exposure of underlying credential information. Applicants’ argument is not persuasive. The cryptographic operations claimed recite well understood generation of salt/seed values that are inputted into generic hash function. The previous Office action provided evidence that generation of “salt value” for use in a hash function to generate hash identifier is well known encryption mechanism known in the art. The hashing of the identifier using a hash function as claimed and as described in the specification is generic and using hash functions prevalently applied in encryption of data. The operations of the claimed technology is to perform basic computer functions of provision/transmitting data, receiving data which has been determined to be well understood (MPEP 2016.05(d) (II) (i)). The claimed limitations merely applies technology to encrypt data using generic encryption processes that are well known and prevalent in encryption of data, transmit and receive data for encryption that is then analyzed to determine whether an identifier is associated with an asset for a commercial activity using generic hardware and processes. The rejection is maintained.
In the remarks applicant argues that based on the analysis above independent claims 1, 21 and 22 and corresponding dependent claims are patent eligible. The examiner respectfully disagrees. See response above, 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 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 …a salt value (2) provisioning …salt value (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 and hash function.
The recited “access server” as amended is further applied to perform the operations “provisioning…salt value” for input, “receiving….a hashed identifier”, “receiving …query request” at a high level lacking technical disclosure with an expected outcome.
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…salt value”, “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 wherein clause “the hashed identifier is generated at the asset verifier terminal by concatenating the salt value with the PAN or electronic application identifier and applying the cryptographic hash function to the concatenated value, wherein the hashed identifier is generated at the asset verifier terminal using locally available PAN or electronic application identifier data such that the access server receives the hashed identifier without receiving the PAN or electronic application identifier”, does not further limit the receiving of the hashed identifier operation of the access server, rather the wherein clause limits the data received. The wherein clause does not positively claim the “concatenating …salt value with the PAN” or positively recite “applying the cryptographic hash function to the concatenated value”. The wherein clause merely limits that the data that is received by the access server is generated by the asset verifier terminal.
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 hashed identifier received and 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 …salt value”, “provisioning …salt value”, “receiving hashed identifier”, “mapping a smart contract on blockchain and a wallet account blockchain address” 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)-(2) and (3) are directed toward generating and provisioning a salt value and receiving a hashed identifier that has been generated using the provisioned salt value which is mere data manipulation. The additional element “access server” is applied to generate a salt value that is used as in input for data encryption using generic encryption/hash function (data manipulation) where the encrypted data is received by the “access server” for use in the commercial activity. For data, mere “manipulation” of basic mathematical constructs [i.e.,] the paradigmatic ‘abstract idea,’" has not been deemed a transformation. CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011) (quoting /n re Warmerdam, 33 F.3d 1354, 1355, 1360 (Fed. Cir. 1994). Whether the transformation is extra-solution activity or a field-of-use (/.e., the extent to which (or how) the transformation imposes meaningful limits on the execution of the claimed method steps). A transformation that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not provide significantly more (or integrate a judicial exception into a practical application). Mayo, 566 U.S. at 76, 101 USPQ2d at 1967. The Supreme Court disagreed, finding that this step was only a field-of-use limitation and did not provide significantly more than the judicial exception. /d. See MPEP § 2106.05(g) & (h).
The combination of limitations (4)-(5) is directed toward receiving a query request to determine whether assets are associated with an identifier and the identifier is associated with assets using the hashed identifier received in limitations (1)-(3), which as a combination is directed toward commercial activity.
There is no indication in the claim language that the claimed combination are 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 claimed combination of operations 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 “salt value” is generated or the “hashed identifier” using the hash function” 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)). The additional limitations as a combination merely apply the hashed identifier to determine whether the identifier is associated with assets.
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 some of the most basic operations of basic computer technology including “generating, provisioning, receiving, causing a mapping service contract comprising a smart contract to store association between an identifier and a wallet account address, receiving query and determining whether hashed identifier is associated with the one or more digital assets steps. The wherein clause does not further limit the receiving step but instead limits the data received for use in a commercial interaction.
Taking the claim elements separately, the function performed by the access server at each step of the process is purely conventional.
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 is directed toward encrypting identifiers for use in a commercial interaction determining whether an identifier is associated with an asset. 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:
Specification
[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.
[0076] FIG. 14 is a diagram of a hardware architecture of a system 1400 for providing
identity payment and access services. In certain implementations, system 1400 may be
used in combination (including with replaced elements) with system 400 (as described
with reference to FIGS. 4-6). A card or token 1405 (via mobile and/or wearable device)
is presented to a terminal 1410. Terminal 1410 can store 1 MB of 100 hashed PANs as a
whitelist. In addition, terminal 1410 can send application protocol data unit (APDU)
commands over any NFC to read card data. A SHA256 algorithm can be applied to the
card data to determine the hashed PAN. The determined hashed PAN can be compared
against the whitelist. Terminal 1410 can store card and entry details. In one
implementation, terminal 1410 includes a central processing unit (CPU) memory having
at least 128MB random access memory (RAM) and 256MB flash memory. In one
implementation, removable micro secure digital (μSD) memory is supported. Item 1415
shows the hardware integration of terminal 1410 with a gantry. In this particular
implementation, a sticker can be provided on the gantry to indicate that only compatible
key cards can be tapped. A speaker can be provided to give feedback to passengers on
approval or denial of entry. A display can also be provided to give feedback on approval
or denial of entry.
“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 the salt value of claim 1 provisioned to the asset verification terminal as a parameter via a server controlled software development kit- directed toward insignificant extra solution activity. 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 and hash function.
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 technical details:
Specification
[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.
[0076] FIG. 14 is a diagram of a hardware architecture of a system 1400 for providing
identity payment and access services. In certain implementations, system 1400 may be
used in combination (including with replaced elements) with system 400 (as described
with reference to FIGS. 4-6). A card or token 1405 (via mobile and/or wearable device)
is presented to a terminal 1410. Terminal 1410 can store 1 MB of 100 hashed PANs as a
whitelist. In addition, terminal 1410 can send application protocol data unit (APDU)
commands over any NFC to read card data. A SHA256 algorithm can be applied to the
card data to determine the hashed PAN. The determined hashed PAN can be compared
against the whitelist. Terminal 1410 can store card and entry details. In one
implementation, terminal 1410 includes a central processing unit (CPU) memory having
at least 128MB random access memory (RAM) and 256MB flash memory. In one
implementation, removable micro secure digital (μSD) memory is supported. Item 1415
shows the hardware integration of terminal 1410 with a gantry. In this particular
implementation, a sticker can be provided on the gantry to indicate that only compatible
key cards can be tapped. A speaker can be provided to give feedback to passengers on
approval or denial of entry. A display can also be provided to give feedback on approval
or denial of entry.
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 …salt value”, “provision…salt value”, “receive …identifier…the hashed identifier generated by applying a hash function with salt value” 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. The 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 technical details:
Specification
[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.
[0076] FIG. 14 is a diagram of a hardware architecture of a system 1400 for providing
identity payment and access services. In certain implementations, system 1400 may be
used in combination (including with replaced elements) with system 400 (as described
with reference to FIGS. 4-6). A card or token 1405 (via mobile and/or wearable device)
is presented to a terminal 1410. Terminal 1410 can store 1 MB of 100 hashed PANs as a
whitelist. In addition, terminal 1410 can send application protocol data unit (APDU)
commands over any NFC to read card data. A SHA256 algorithm can be applied to the
card data to determine the hashed PAN. The determined hashed PAN can be compared
against the whitelist. Terminal 1410 can store card and entry details. In one
implementation, terminal 1410 includes a central processing unit (CPU) memory having
at least 128MB random access memory (RAM) and 256MB flash memory. In one
implementation, removable micro secure digital (μSD) memory is supported. Item 1415
shows the hardware integration of terminal 1410 with a gantry. In this particular
implementation, a sticker can be provided on the gantry to indicate that only compatible
key cards can be tapped. A speaker can be provided to give feedback to passengers on
approval or denial of entry. A display can also be provided to give feedback on approval
or denial of entry.
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 salt value inputs and hashing operations the specification nominally mentions the application.
Specification
[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.
[0076] FIG. 14 is a diagram of a hardware architecture of a system 1400 for providing
identity payment and access services. In certain implementations, system 1400 may be
used in combination (including with replaced elements) with system 400 (as described
with reference to FIGS. 4-6). A card or token 1405 (via mobile and/or wearable device)
is presented to a terminal 1410. Terminal 1410 can store 1 MB of 100 hashed PANs as a
whitelist. In addition, terminal 1410 can send application protocol data unit (APDU)
commands over any NFC to read card data. A SHA256 algorithm can be applied to the
card data to determine the hashed PAN. The determined hashed PAN can be compared
against the whitelist. Terminal 1410 can store card and entry details. In one
implementation, terminal 1410 includes a central processing unit (CPU) memory having
at least 128MB random access memory (RAM) and 256MB flash memory. In one
implementation, removable micro secure digital (μSD) memory is supported. Item 1415
shows the hardware integration of terminal 1410 with a gantry. In this particular
implementation, a sticker can be provided on the gantry to indicate that only compatible
key cards can be tapped. A speaker can be provided to give feedback to passengers on
approval or denial of entry. A display can also be provided to give feedback on approval
or denial of entry.
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 Interpretation
With respect to the limitation “software development kit”, in light of the specification specifically drawing 11 as the written description only nominally mentions the term, the examiner is interpreting the limitation “software development kit” to be type of interface.
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, 10-13 and 15; Claim(s) 21 and Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2024220070 A1 by Jurss et al. (Jurss) and further in view of US Pub No. 2024/0267209 A1 by Liang et al (Liang)
In reference to Claim 1:
Jurss teaches:
(Currently Amended) A method comprising: …
receiving, by the access server, a hashed identifier, …and applying the cryptographic hash function to the concatenated value, wherein the hashed identifier is generated at the asset verifier terminal using locally available PAN or electronic application identifier data such that the access server receives the hashed identifier without receiving the PAN or electronic application identifier ((Jurss) in at least para 0033-0034, para 0056, para 0058, para 0069, para 0079, para 0104)
causing, by the access server, a mapping service contract comprising a smart contract deployed on a blockchain to store, on the blockchain, an association between the hashed identifier and a blockchain wallet account address ((Jurss) in at least para 0008-0009, para 0041, para 0051, para 0058, para 0060, para 0077-0078);
receiving, by the access server 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 ((Jurss) in at least para 0007-0009, para 0033, para 0045, para 0051, para 0055-0056, para 0058); and
determining, by the access server, via the mapping service contract, whether the hashed identifier is associated with the one or more digital assets ((Jurss) in at least para 0033-0034, para 0057, para 0083, para 0089, para 0101).
Jurss does not explicitly teach:
generating, by an access server, a salt value that is randomly generated and uniquely associated with a personal account number (PAN) or electronic application identifier for use as cryptographic input in a cryptographic hash function, the PAN or electronic application identifier associated with a card corresponding to a consumer
provisioning, by the access server, the salt value to an asset verifier terminal via a configuration interface such that the asset verifier terminal can only generate a valid hashed identifier with the salt value’
…wherein the hashed identifier is generated at the asset verifier terminal by concatenating the salt value with the PAN or electronic application identifier
Liang teaches:
generating, by an access server, a salt value that is randomly generated and uniquely associated with a personal … identifier for use as cryptographic input in a cryptographic hash function, …((Liang) in at least Abstract; para 0005, para 0018, para 0050, para 0060, para 0063)
provisioning, by the access server, the salt value to an asset verifier terminal via a configuration interface such that the asset verifier terminal can only generate a valid hashed identifier with the salt value …((Liang) in at least para 0050, para 0060, para 0063, para 0069, para 0073 )
receiving, by the access server, a hashed identifier, wherein the hashed identifier is generated at the asset verifier terminal by concatenating the salt value with the … identifier and applying the cryptographic hash function to the concatenated value, wherein the hashed identifier is generated at the asset verifier terminal using locally available … identifier data such that the access server receives the hashed identifier without receiving the … identifier …((Liang) in at least para 0050, para 0060, para 0063, para 0069, para 0073, para 0075 )…
Both Jurss and Liang are directed toward generating hashed/tokenized identifiers associated with assets. Liang teaches the motivation providing salted identifier protection for authenticating an entity to access a protected resource, where the encrypted salt value is generated by a secure database for later retrieval and then sent to security system to combine the salt value the identifier and generate a hashed valued for use to retrieve account information. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the process for encrypting PAN/account identifiers for use in accessing assets of Jurss to include generating a salt/seed value combined with the identifier in different computer architecture as taught by Liang since Liang teaches the motivation providing salted identifier protection for authenticating an entity to access a protected resource, where the encrypted salt value is generated by a secure database for later retrieval and then sent to security system to combine the salt value the identifier and generate a hashed valued for use to retrieve account information.
In reference to Claim 3:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss 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, whether the hashed identifier is associated with the one or more digital assets (see rejection of claim 1 above) 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. ((Jurss) in at least para 0008-0009, para 0041, para 0051, para 0058, para 0060, para 0077-0078)
In reference to Claim 5:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss 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 ((Jurss) in at least para 0074, para 0083, para 0124).
In reference to Claim 8:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss 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 ((Jurss) in at least para 0008-0009, para 0041, para 0051, para 0058, para 0060, para 0064-0065, para 0075, para 0077-0078).
In reference to Claim 10:
The combination of Jurss and Liang discloses the limitations of dependent claim 8. Jurss 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. ((Jurss) in at least para 0022, para 0033-0034, para 0036, para 0041, para 0051, para 0056, para 0058, para 0060, para 0064, para 0069, para 0078-0079, para 0104)
In reference to Claim 11:
The combination of Jurss and Liang discloses the limitations of dependent claim 10. Jurss 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 associated with the card ((Jurss) in at least para 0022, para 0033-0034, para 0036, para 0041, para 0051, para 0056, para 0058, para 0060, para 0064, para 0069, para 0078-0079, para 0104); and
generating, by the asset verifier terminal, the hashed identifier based on the PAN or the electronic application identifier ((Jurss) in at least para 0033-0034, para 0056, para 0058, para 0069, para 0079, para 0104)
In reference to Claim 12:
The combination of Jurss and Liang discloses the limitations of dependent claim 11. Jurss 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. ((Jurss) in at least para 0033-0034, para 0056, para 0058, para 0069, para 0079, para 0104)
In reference to Claim 13:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss further discloses the limitations of dependent claim 13
(Previously Presented) The method of claim 1, wherein determining, by the access server, via the mapping service contract, whether the hashed identifier is associated with the one or more digital assets (see rejection of claim 1 above) includes
invoking, by the access server, a function of the mapping service contract ((Jurss) in at least para 0033-0034, para 0056, para 0058, para 0069, para 0079, para 0104), the function being configured to:
receive the hashed identifier as input ((Jurss) in at least para 0035, para 0080, para 0082-0083, para 0100, para 0109);
retrieve, from the blockchain, the blockchain wallet account address associated with the hashed identifier ((Jurss) in at least para 0083, para 0086, para 0100, para 0107); 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 ((Jurss) in at least para 0077-0078, para 0087, para 0108, para 0117).
In reference to Claim 14:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss further discloses the limitations of dependent claim 14.
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), further comprising:
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 ((Jurss) in at least para 0074-0078); and
providing, by the access server, the response to the asset verifier terminal ((Jurss) in at least para 0091-0092).
In reference to Claim 15:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss 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 ((Jurss) in at least para 0074, para 0083, para 0124).
In reference to Claim 21:
The combination of Jurss and Liang discloses the limitations of independent claim 21.
The system claim 21 functional processes correspond to the method steps of method claim 1. The additional limitations recited in claim 21 that go beyond the limitations of claim 1 include: a system ((Jurss) in at least FIG. 6) comprising “one or more first processors” ((Jurss) in at least FIG. 6; para 0038, para 0040, para 0108-0109), “one or more first memory comprising a plurality of first program instructions” ((Jurss) in at least FIG. 6; para 0039, para 0108-0109, para 0115-0116, para 0118, para 0126) where the “one or more first processor” performing the operation corresponding to claim 1
Therefore, claim 21 has been analyzed and rejected as previously discussed with respect to claim 1
In reference to Claim 22:
The combination of Jurss and Liang discloses the limitations of independent claim 22.
The non-transitory computer readable storage medium of claim 22 executed instructions correspond to the method steps of method claim 1. The additional limitations recited in claim 22 that go beyond the limitations of claim 1 include:
At least one non-transitory computer-readable storage medium having computer-executable instructions stored thereon ((Jurss) in at least para 0025, para 0028, para 0161), wherein, when executed by at least one processor, the computer-executable instructions cause the at least one processor ((Jurss) in at least para 0094-0095, para 0159, para 0161, para 0164-0165) performing the operation corresponding to claim 1
Therefore, claim 22 has been analyzed and rejected as previously discussed with respect to claim 1
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2024220070 A1 by Jurss et al. (Jurss) in view of US Pub No. 2024/0267209 A1 by Liang et al (Liang) as applied to Claim 1 above, and further in view of SDK vs API: What’s the Difference?” by Wickramasinghe (Wick)
In reference to Claim 2:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss further discloses the limitations of dependent claim 2
(Currently Amended) The method of claim 1 (see rejection of claim 1 above),
Jurss does not explicitly teach:
wherein the salt value is provisioned to the asset verifier terminal as a configuration parameter via a server- controlled software development kit
Liang teaches:
wherein the salt value is provisioned to the asset verifier terminal as a configuration parameter via a server- …[client interface] ((Liang) in at least para 0049-0050, para 0052)
Both Jurss and Liang are directed toward generating hashed/tokenized identifiers associated with assets where request and data applied for generating hashed values applied interfaces for communication between devices. Liang teaches the motivation of providing salt value data to the security/asset terminal as a parameter for hashing values using an interface in order to communicate the generated salted value to the security/asset verifier terminal. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the process for encrypting PAN/account identifiers for use in accessing assets of Jurss to include providing the salt value via an interface as taught by Liang since Liang teaches the motivation of providing salt value data to the security/asset terminal as a parameter for hashing values using an interface in order to communicate the generated salted value to the security/asset verifier terminal.
Wick teaches:
wherein the …[data] is provisioned to the … terminal … via a server- controlled software development kit ((Wick) in at least article)
According to KSR, simple substitution of one known element for another to obtain predictable results. The prior art Jurss contained an interface for communicating data which differed from the claimed architecture by the substitution of some interface components with other interface components. The prior art Wick provides evidence that the substituted interface and their functions where known in the art. Accordingly one of ordinary skill in the art could have substituted one known element for another and the results of the substation would have been predictable.
Both Jurss and Wick teach communicating data between devices using an interface. Wick teaches the motivation that it is essential for all modern application to facilitate services through your application with the motivation of applying software development kits to create APIs that enable external parties to interface to interface with the application of the receiving the device in order to provide the benefits of direct access to the functioning of the SDK platform and the ability to use then within application, efficient resourcing cost, great support for application. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the interface for communicating between devices with explicit functionality of Jurss to include SDK of Wick since Wick teaches the motivation that it is essential for all modern application to facilitate services through your application with the motivation of applying software development kits to create APIs that enable external parties to interface to interface with the application of the receiving the device in order to provide the benefits of direct access to the functioning of the SDK platform and the ability to use then within application, efficient resourcing cost, great support for application.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2024220070 A1 by Jurss et al. (Jurss) in view of US Pub No. 2024/0267209 A1 by Liang et al (Liang) 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 Jurss and Liang discloses the limitations of independent claim 1. Jurss further discloses the limitations of dependent claim 4
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Jurss does not explicitly teach:
wherein the one or more digital assets are associated with one or more asset contracts generated by a merchant computer system.
Jay teaches:
wherein the one or more digital assets are associated with 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 Jurss 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 Jurss 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 WO 2024220070 A1 by Jurss et al. (Jurss) in view of US Pub No. 2024/0267209 A1 by Liang et al (Liang) 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 Jurss and Liang discloses the limitations of independent claim 1. Jurss further discloses the limitations of dependent claim 6.
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Jurss 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 Jurss and Liang discloses the limitations of dependent claim 6. Jurss 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, and wherein the one or more digital assets are configured to be stored on the digital wallet. ((Jurss) in at least para 0022 wherein the prior art teaches accounts include cardholder accounts, para 0033-0034, para 0036 wherein the prior art teaches assets associated with issuer payment card used for transaction and identification of the card, para 0041, para 0051, para 0056, para 0058, para 0060, para 0064, para 0069, para 0078-0079, para 0104)
Claim(s) 9 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2024220070 A1 by Jurss et al. (Jurss) in view of US Pub No. 2024/0267209 A1 by Liang et al (Liang) as applied to Claim 1 above, and further in view of US Pub No. 2022/0172198 1 by Gaur et al. (Gaur)
In reference to Claim 9:
The combination of Jurss and Liang discloses the limitations of dependent claim 8. Jurss further discloses the limitations of dependent claim 9
(Previously Presented) The method of claim 8 (see rejection of claim 8 above),
Jurss does not explicitly teach:
wherein the PAN or the electronic application identifier associated with the card corresponding to the consumer is mapped to a merchant computer system.
Gaur teaches:
wherein the PAN or the electronic application 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)
Both Jurss and Gaur are directed toward mapping token identifiers to account addresses stored in blockchain. Gaur teaches the motivation of applying tokens for payment authorization request from a merchant where the merchant terminal transmits transaction details to the merchant bank request detokenizing the payment token based on mapping information stored in the token vault. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify token mapping process tied to the PAN of the transaction account of Jurss to include the identifier mapped to the merchant system as taught by Gaur since Gaur teaches the motivation of applying tokens for payment authorization request from a merchant where the merchant terminal transmits transaction details to the merchant bank request detokenizing the payment token based on mapping information stored in the token vault.
In reference to Claim 17:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss 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…
Jurss does not explicitly teach:
wherein the card is a chip card corresponding to a Europay, Mastercard, Visa (EMV) card….((Jurss) in at least para 0026)
Guar teaches:
wherein the card is a chip card corresponding to a Europay, Mastercard, Visa (EMV) card. ((Guar) in at least para 0037)
According to KSR, simple substitution of one known element for another to obtain predictable results. The prior art Jurss contained smart card mechanism which differed from the claimed emv card claimed. The prior art Guar provides evidence that the substituted smart card mechanism and their functions where known in the art. Accordingly one of ordinary skill in the art could have substituted one known element for another and the results of the substation would have been predictable.
Both Jurss and Guar are directed toward applying cards for tokenized transactions. Gaur teaches the motivation that payment tokenization is emv tokenization replacing the PAN with a token. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the card payment tokenization mechanism of Jurss to include EMV cards as taught by Guar since Gaur teaches the motivation that payment tokenization is emv tokenization replacing the PAN with a token.
In reference to Claim 18:
The combination of Jurss and Liang discloses the limitations of independent claim 1. Jurss further discloses the limitations of dependent claim 18.
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Jurss does not explicitly teach:
wherein the card is configured for presentation via a mobile device, a wearable device, or a contactless Europay, Mastercard, Visa (EMV) card.
Guar teaches:
wherein the card is configured for presentation via a mobile device, a wearable device, or a contactless Europay, Mastercard, Visa (EMV) card. ((Guar) in at least para 0037-0038)
According to KSR, simple substitution of one known element for another to obtain predictable results. The prior art Jurss contained smart card mechanism which differed from the claimed emv card/device claimed. The prior art Guar provides evidence that the substituted smart card mechanisms as claimed and their functions where known in the art. Accordingly one of ordinary skill in the art could have substituted one known element for another and the results of the substation would have been predictable.
Both Jurss and Guar are directed toward applying cards for tokenized transactions of corresponding to mobile devices. Gaur teaches the motivation that payment can be stored within a mobile wallet on a mobile device to perform e-commerce. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the card payment tokenization mechanism of Jurss to include EMV cards as taught by Guar since Gaur teaches the motivation that payment tokenization is emv tokenization replacing the PAN with a token.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2024220070 A1 by Jurss et al. (Jurss) in view of US Pub No. 2024/0267209 A1 by Liang et al (Liang) as applied to Claim 1 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 Jurss and Liang discloses the limitations of dependent claim 15. Jurss further discloses the limitations of dependent claim 16.
(Original) The method of claim 15 (see rejection of claim 15 above),
Jurss does not explicitly teach:
wherein the one or more digital assets comprise an NFT or SFT corresponding to a loyalty profile.
Ferenczi teaches:
wherein the one or more digital assets comprise an NFT or SFT corresponding to a loyalty profile. ((Ferenczi) in at least Col 11 lines 40-65, Col 13 lines 18-35),
Both Jurss 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 Jurss 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. CA-3066678-C by Keselman; CA-3169394-A1 by Bowman; CA-3229177-A1 by Kumar et al; EP-3641349-B1 by Lantz; US Patent No. 11,062302 B1 by HO; US-20200084097-A1 by Marks; US-20210264444-A1 by Chen; US-20210081929-A1 by Spector; US-20220277297-A1 by Bloy
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights