DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response Applicant communication filed on 8/7/2026.
Claims
Claims 1-10 and 15 have been amended.
Claims 11-14 have been withdrawn from consideration as being directed to non-elected subject matter.
Claims 1-15 are currently pending in the application.
Information Disclosure Statements
The Information Disclosure Statement (IDS) that was filed on 7/2/2026 has been considered.
Response to Arguments
112(f) Interpretation
The applicant argues that the current claims have been amended to remove the challenged means formulations from the elected claims and to identify electronic components and processing relationships that perform the recited operations (see page 11 of applicant’s arguments/remarks).
However the examiner respectfully disagrees. Claims 7, 8, and 10 still invoke 112(f). Please see below for updated claim interpretation.
112
The applicant argues that the specification provides adequate structure or algorithm for encryption by the trusted service provider unit or by the secure register unit.
However the examiner respectfully disagrees. Amended claim 7 still invokes 112(f) by reciting “wherein the encrypted secure token transaction unit identifier is generated by a trusted service provider unit that encrypts the secure token transaction unit identifier…”. Although the specification discloses the algorithm to perform this function in sections [0043] and [0145]-[0149], the specification fails to disclose the corresponding structure for the trusted service provider unit. Therefore claim 7 fails to disclose the adequate structure (or material or acts) for the trusted service provider unit that is performing the recited function.
101
The examiner agrees with the applicant’s arguments regarding the 101 rejection. The claim as a whole provides a technical improvement to token transaction systems. By storing a one-way cryptographic representation of the user information, mapping that representation to a transaction-unit identifier, and returning the identifier to a requesting secure transaction unit for use as addressing data in a direct token exchange, it prevents a potential attacker from being able to steal user information that is conventionally stored in a directory service. This technical problem and technical solution is captured in the specification in sections [0005], [0007]-[0009], [0011]-[0016], [0019]-[0023], and [0062]. Therefore the claims integrate the abstract idea into a practical application..
103
In Applicant’s arguments with respect to claim 1 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Such claim limitation(s) is/are:
“wherein the encrypted secure token transaction unit identifier is generated by a trusted service provider unit that encrypts the secure token transaction unit identifier…” in claim 7;
“…the trusted service provider unit is configured to send the decrypted secure token transaction unit identifier to the requesting secure token transaction unit” in claim 8;
“…the first service provider unit is configured to send the first part of the secure token transaction unit identifier to the requesting secure token transaction unit…” and “…the second service provider unit is configured to send the second part of the secure token transaction unit identifier to the requesting secure token transaction unit…” in claim 10.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claim 1, the claim has been amended to recite “a secure register unit within an electronic token transaction system, the secure register unit comprising a processor and a non-transitory computer-readable memory, and being configured to:…” (emphasis added). The specification fails to disclose that the secure register unit comprises a processor and a non-transitory computer-readable memory.
Per claim 7, the claim recites “wherein the encrypted secure token transaction unit identifier is generated by a trusted service provider unit that encrypts the secure token transaction unit identifier…” but the subject matter is not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor, at the time the application was filed, had possession of the claimed invention. When the disclosed structure is a computer programmed to carry out an algorithm, the disclosed structure is not the general purpose computer, but rather the special purpose computer programmed to perform the disclosed algorithm. In cases involving a special purpose computer-implemented means-plus-function limitation, the Federal Circuit has consistently required that the structure be more than simply a general purpose computer or microprocessor and that the specification must disclose an algorithm for performing the claimed function. Consideration of the understanding of one skilled in the art in no way relieves the patentee of adequately disclosing sufficient structure in the specification. The specification must explicitly disclose the algorithm for performing the claimed function, and simply reciting the claimed function in the specification will not be sufficient disclosure for an algorithm which, by definition, must contain a sequence of steps. Please see MPEP 2181 II B. The specification discloses the algorithm used to generate an encrypted secure token transaction unit identifier in sections [0043], [0080], and [0145]-[0149]. Here the specification discloses how the trusted service provider unit encrypts the secure token transaction unit identifier but the specification fails to disclose the physical structure that makes up the trusted service provider unit or the physical structure that executes the algorithm for performing the claimed functions. Therefore the specification fails to convey that the inventor, at the time the application was filed, had possession of the claimed invention.
Furthermore, claims 2-6 and 8-10 are rejected as being dependent on the claims above.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 7 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. In this instant case,
Claim 7 recites “wherein the encrypted secure token transaction unit identifier is generated by a trusted service provider unit that encrypts the secure token transaction unit identifier…”. The claim limitation invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the claim(s) fail to disclose the corresponding structure, material, or acts for the claimed function.
Applicant may:
Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph; or
Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the claimed function, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP 608.01(o) and 2181.
Rejections under 35 § U.S.C. 103
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 of this title, 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.
Claims 1-4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20240273524 A1 (“Fang”) and US 20190340350 A1 (“Campbell”).
Per claims 1 and 15, Fang discloses:
receive, from a requesting secure token transaction unit of the electronic token transaction system, a request comprising a cryptographic hash value generated based on user information associated with a user of another secure token transaction unit (e.g. The analytics server 602 can transmit a message 618 for the subscription to the computer 612. The message 618 can include the parameters for the subscription and/or an identifier of the decentralized wallet 614 (e.g., an anonymized identifier for the decentralized wallet 614 or the address or key for the decentralized wallet 614) in the message 618) and (e.g. To modify a subscription, the computer 612 can use the identifier of the decentralized wallet 614 in a look-up technique to identify a previously created record of a subscription for the decentralized wallet 614. The computer 612 can then change or replace the parameters for the subscription according to the parameters included in the message 618) (Sections [0103], [0104] and [0106]);
…a secure token transaction unit identifier that uniquely identifies the respective secure token transaction unit of the electronic token transaction system (e.g. In some cases, the analytics server can transmit a generated identifier of the decentralized wallet to the computer or server of the service provider. For example, the analytics server can generate (e.g., pseudo-randomly generate) an anonymized identifier for the decentralized wallet. The analytics server can generate the anonymized identifiers for each of the decentralized wallets upon detecting a first request to generate a subscription for the decentralized wallet. The analytics server can generate the anonymized identifiers by using a random number generator or by performing a calculation (e.g., a hash algorithm) on the identifiers of the decentralized wallets. The analytics server can generate the identifier and store the generated identifier in a table (e.g., a look-up table that can contain a mapping of anonymized identifiers to identifiers of decentralized wallets).with a stored association with the identifier of the decentralized wallet of the user. The analytics server can transmit the anonymized identifier to the computer or servers of service provider to create or modify the subscription instead of the identifiers of the decentralized wallet) (Section [0049]);
identify, using the cryptographic hash value of the request, the secure token transaction unit identifier linked to the cryptographic hash value (e.g. The analytics server 110a can configure the electronic transaction protocols to do so responsive to the conditions of the electronic transaction protocols being satisfied. The electronic transaction protocols can identify the identifiers or addresses of the decentralized wallets associated with a subscription, and interact with the decentralized wallets associated with the identifiers or addresses to cause the decentralized wallets to pay in accordance with the subscriptions of the decentralized wallets) and (e.g. The analytics server 110a can generate anonymized identifiers for the decentralized wallets of subscribers. For example, upon transmitting a message to the computer 120 and/or the server 140 to create subscription for a decentralized wallet, the analytics server 110a can generate an anonymized identifier for the decentralized wallet. The server 140 can do so using a random number generator or by executing a function (e.g., a hashing function or any other function) on the identifier of the decentralized wallet. The analytics server 110a can store a link (e.g., a stored association) between the anonymized identifier and the actual identifier for the decentralized wallet. The analytics server 110a can transmit the anonymized identifier to the server of the service provider of the subscription with the message to create the subscription without transmitting the actual identifier of the decentralized wallet to the server to create and maintain the subscription) (Section [0031], [0032], [0104], and [0106]);
send the identified secure token transaction unit identifier to the requesting secure token transaction unit as addressing data for a direct exchange of one or more electronic tokens between the requesting secure token transaction unit and the other secure token transaction unit (e.g. The analytics server can generate the anonymized identifiers by using a random number generator or by performing a calculation (e.g., a hash algorithm) on the identifiers of the decentralized wallets. The analytics server can generate the identifier and store the generated identifier in a table (e.g., a look-up table that can contain a mapping of anonymized identifiers to identifiers of decentralized wallets).with a stored association with the identifier of the decentralized wallet of the user. The analytics server can transmit the anonymized identifier to the computer or servers of service provider to create or modify the subscription instead of the identifiers of the decentralized wallet. The analytics server can transmit such anonymized identifiers instead of the identifiers (e.g., addresses or public keys) of decentralized wallets to computers or server of service providers. In this way, the analytics server can reduce the amount of personal information that is transmitted over a network or to different computers (e.g., the service providers may only receive the anonymized identifier of the decentralized wallet, not any other PII)) and (e.g. Upon detecting the end of the payment interval, the computers storing the electronic transaction protocol can execute the electronic transaction protocol and extract a payment from the decentralized wallet. In doing so, the electronic transaction protocol can remove one or more tokens or other unit of currency from the decentralized wallet of the subscriber. The electronic transaction protocol can identify a decentralized wallet of the service provider associated with the subscription from an identifier of the service provider's decentralized wallet in the electronic transaction protocol or a block instance associated with the electronic transaction protocol. The electronic transaction protocol can insert the one or more tokens or other unit of currency into a decentralized wallet of the service provider associated with the subscription) (Section [0031], [0049], and [0057]).
Although Fang discloses the use of hashes to look-up decentralized wallets and provide the hash to service providers to create token subscription payments from the decentralized wallet, Fang does not specifically disclose:
store, in the computer-readable memory and without storing the user information in plaintext, a plurality of links, each link associating the respective cryptographic hash value with a secure token transaction unit identifier….
However Campbell, in analogous art of storing user information and its associated hash, discloses:
store, in the computer-readable memory and without storing the user information in plaintext, a plurality of links, each link associating the respective cryptographic hash value with a secure token transaction unit identifier… (e.g. In embodiments, Hash 1008 may be a generated encrypted value based on the information stored by Document 1002, Biometric 1004, and/or Device ID 1006. In embodiment, Hash 1008 may store one or more hashes associated with Document 1002, Biometric 1004, and/or Device ID 1006. For example, document A2C, biometric facial information, and device ID 1211121 are used to generate one hash—458454. Also, as shown in FIG. 10, document K8Y and fingerprint information are used to generate two hashes—6XBBDFD22 and IUGD99, one hash being for the document and the other hash being for the biometric information. Thus, different one or more hashes may be generated for one or more different types of information) and (e.g. In embodiments, the biometric and/or identity information may be encrypted (e.g., with public keys, private keys, hashes, codes, etc.) while stored on the user device to prevent other computing devices from accessing the biometric and/or identity information. In embodiments, the biometric and/or identity information, once sent either in encrypted or non-encrypted format, may be received by a system (e.g., a blockchain, one or more computing devices, cellular systems, wireless system, etc.)) (Section [0018], [0073]-[0075] and Fig. 10).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the linked wallet and hash information of Fang to include the storage of various user information and the respective hashes in encrypted form, as taught by Campbell, in order to achieve the predictable result of increasing the security of the data by protecting it from potential attackers.
Per claim 2, Fang/Campbell discloses all the limitations of claim 1 above. Campbell further discloses:
wherein the cryptographic hash value is generated based on the user information and additional information (e.g. In embodiments, Hash 1008 may be a generated encrypted value based on the information stored by Document 1002, Biometric 1004, and/or Device ID 1006. In embodiment, Hash 1008 may store one or more hashes associated with Document 1002, Biometric 1004, and/or Device ID 1006) (Section [0073]-[0075]).
The motivation to combine Campbell with Fang is disclosed above with reference to claims 1 and 15.
Per claim 3, Fang/Campbell discloses all the limitations of claim 2 above. Campbell further discloses:
wherein the additional information comprises a type indicator that is concatenated with the user information as an input to a cryptographic hash function and indicates a source type of the user information wherein the type indicator comprises at least one of: a first type indicator indicating user information generated by a communication service provider unit; a second type indicator indicating user information generated by a financial service provider unit; a third type indicator indicating user information generated by a governmental service provider unit; a fourth type indicator indicating user information generated by a private service provider unit, the user information being a customer reference number of the user; a fifth type indicator indicating user information generated by a manufacturer unit, the user information being a serial number or a hardware number; and a sixth type indicator indicating user information generated by a private company unit, an enterprise unit, or a social club unit (e.g. For example, in a non-limiting way, “A2C” may be for a driver's license, a passport, a work permit, and/or any other document that includes a person's biometric information (e.g., facial image, fingerprint information, etc.), address information, gender information, age information, and/or any other information that describes a person) and (e.g. In embodiments, Hash 1008 may be a generated encrypted value based on the information stored by Document 1002, Biometric 1004, and/or Device ID 1006. In embodiment, Hash 1008 may store one or more hashes associated with Document 1002, Biometric 1004, and/or Device ID 1006. For example, document A2C, biometric facial information, and device ID 1211121 are used to generate one hash—458454. Also, as shown in FIG. 10, document K8Y and fingerprint information are used to generate two hashes—6XBBDFD22 and IUGD99, one hash being for the document and the other hash being for the biometric information. Thus, different one or more hashes may be generated for one or more different types of information) (Section [0074] and [0075]).
The motivation to combine Campbell with Fang is disclosed above with reference to claims 1 and 15.
Note: the limitation “wherein the additional information comprises a type indicator that is concatenated with the user information as an input to a cryptographic hash function and indicates a source type of the user information wherein the type indicator comprises at least one of: a first type indicator indicating user information generated by a communication service provider unit; a second type indicator indicating user information generated by a financial service provider unit; a third type indicator indicating user information generated by a governmental service provider unit; a fourth type indicator indicating user information generated by a private service provider unit, the user information being a customer reference number of the user; a fifth type indicator indicating user information generated by a manufacturer unit, the user information being a serial number or a hardware number; and a sixth type indicator indicating user information generated by a private company unit, an enterprise unit, or a social club unit” does not distinguish over the prior art as written because it is non-functional and is describing the data that the hash value is based on. This does not affect the steps/functions of the claim in a manipulative sense.
Per claim 4, Fang/Campbell discloses all the limitations of claim 2 above. Campbell further discloses:
wherein the additional information comprises a special tag, that is concatenated with the user information or with a first-level hash value as an input to a cryptographic hash function to further individualize the cryptographic hash value within the electronic token transaction system, wherein the special tag comprises at least one of: a time-tag indicating a time frame in which the cryptographic hash value is generated; a secret-tag stored in the secure register unit and configured to obfuscate the user information; a tag indicating service specific data; a service-provider-indicator indicating a service provider; a user-known tag provided to the requesting secure token transaction unit for insertion in the request, wherein the user-known tag is a one-time identification and the secure register unit deletes the link immediately after the link is successfully requested by the requesting secure token transaction unit (e.g. In embodiments, example data structure 1000 may include other types of hashes associated with other types of values. In embodiments, example data structure 1000 may include hashes for bank information, credit card information, and/or other types of information) and (e.g. In embodiments, Hash 1008 may be a generated encrypted value based on the information stored by Document 1002, Biometric 1004, and/or Device ID 1006. In embodiment, Hash 1008 may store one or more hashes associated with Document 1002, Biometric 1004, and/or Device ID 1006. For example, document A2C, biometric facial information, and device ID 1211121 are used to generate one hash—458454. Also, as shown in FIG. 10, document K8Y and fingerprint information are used to generate two hashes—6XBBDFD22 and IUGD99, one hash being for the document and the other hash being for the biometric information. Thus, different one or more hashes may be generated for one or more different types of information) and (e.g. At a later time, Verification Server may delete information associated with the biometric and ID information. In either embodiment, Verification Server may analyze the biometric and ID information and verify that the biometric and ID information is valid) (Sections [0022], [0074] and [0075]).
The motivation to combine Campbell with Fang is disclosed above with reference to claims 1 and 15.
Note: the limitation “wherein the additional information comprises a special tag, that is concatenated with the user information or with a first-level hash value as an input to a cryptographic hash function to further individualize the cryptographic hash value within the electronic token transaction system, wherein the special tag comprises at least one of: a time-tag indicating a time frame in which the cryptographic hash value is generated; a secret-tag stored in the secure register unit and configured to obfuscate the user information; a tag indicating service specific data; a service-provider-indicator indicating a service provider; a user-known tag provided to the requesting secure token transaction unit for insertion in the request, wherein the user-known tag is a one-time identification and the secure register unit deletes the link immediately after the link is successfully requested by the requesting secure token transaction unit” does not distinguish over the prior art as written because it is non-functional and is describing the data that the hash value is based on. This does not affect the steps/functions of the claim in a manipulative sense.
Claims 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Fang/Campbell, as applied to claim 1 above, in further view of US 20190260575 A1 (“Nenov”).
Per claim 5, Fang/Campbell discloses all the limitations of claim 1 above. Although Fang/Campbell discloses storing a secure token transaction unit identifier, Fang/Campbell does not specifically disclose:
wherein the secure token transaction unit identifier is encrypted before storage, and the encrypted secure token transaction unit identifier is stored in the secure register unit.
However Nenov, in analogous art of storing user wallet information, discloses:
wherein the secure token transaction unit identifier is encrypted before storage, and the encrypted secure token transaction unit identifier is stored in the secure register unit (e.g. User data 150, which may comprise any type and form of data, such as configuration files, personal data, applications, system files, or any other data, may be retrieved by a source device 100 and stored, e.g. via a transaction written to a smart contract 160 of a distributed ledger 170. The data may be encrypted and stored in association with an access key 155, which may be used as an address (e.g. a wallet, an identifier, an account name, or any other similar identifiers) by the smart contract 160 for storing and retrieving the data) (Section [0031]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the storing of the secure token transaction unit identifier of Fang/Campbell to use encryption when storing the data, as taught by Nenov, in order to achieve the predictable result of increasing the security of the system by protecting the data from potential threats.
Per claim 6, Fang/Campbell/Nenov disclose all the limitations of claim 5 above. Campbell further discloses:
wherein a stored link comprises the encrypted secure token transaction unit identifier and a trusted service provider unit identifier identifying a trusted service provider unit (e.g. FIG. 10 describes an example data structure 1000 that stores biometric and identity information. In embodiments, data structure 1000 may include a collection of fields such as Document 1002, Biometric 1004, Device ID 1006, and Hash 1008. Although FIG. 10 shows example fields 1002-1008, in other embodiments, data structure 1000 may include fewer fields, different fields, additional fields, and/or differently arranged fields than depicted in FIG. 10. In embodiments, user device 112 and/or electronic application 116 may store some or all of data structure 1000. Additionally, or alternatively, verification server 120 and/or system 122 may store some or all of data structure 1000) (Section [0073], [0075], and Fig. 10).
The motivation to combine Campbell with Fang/Nenov is disclosed above with reference to claim 5.
Per claim 7, Fang/Campbell/Nenov disclose all the limitations of claim 5 above. Nenov further discloses:
wherein the encrypted secure token transaction unit identifier is generated by a trusted service provider unit that encrypts the secure token transaction unit identifier or by the secure register unit using an encryption key received from the trusted service provider unit (e.g. In some implementations, a source device 100 or accessing device 102 may have an encryption module 214. Encryption module 214, sometimes referred to as an encryption co-processor, a cryptographic accelerator, a secure cryptoprocessor, or a trusted platform module (TPM), may comprise hardware for efficiently performing encryption and decryption or calculation of cryptographic hash results) (Section [0031] and [0040]).
The motivation to combine Nenov with Fang/Campbell is disclosed above with reference to claim 5.
Per claim 8, Fang/Campbell/Nenov disclose all the limitations of claim 6 above. Nenov further discloses:
wherein, in response to the request, the secure register unit is configured to send the encrypted secure token transaction unit identifier for decryption, and the trusted service provider unit is configured to send the decrypted secure token transaction unit identifier to the requesting secure token transaction unit (e.g. As shown, the access key 155 may be provided to an accessing device 102 (which may be the same as source device 100 or a different device). The accessing device 102 may authenticate with the smart contract 160 via the access key 155 (e.g. as a source address or wallet or similar identifier), and may retrieve the encrypted data in the ledger. The access key 155 may be a random number or string, or may be generated based on device identifiers, user names, public keys of key pairs used to encrypt data, etc. In one such implementation, the access key 155 may be a public key, and a private key may be similarly privately distributed or provided to accessing device 102. The accessing device 102 may retrieve the encrypted data using the public key as an address or authentication identifier, and may decrypt the data using the private key) (Section [0031]).
The motivation to combine Nenov with Fang/Campbell is disclosed above with reference to claim 5.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Fang/Campbell, as applied to claim 1 above, in further view of US 20210243256 A1 (“Checco”).
Per claim 9, Fang/Campbell discloses all the limitations of claim 1 above. Although Fang/Campbell discloses storing a link between a hash value and a secure token transaction unit identifier, Fang/Campbell does not specifically disclose:
wherein the secure token transaction unit identifier linked to the cryptographic hash value is divided into at least first and second parts, and the computer-readable memory comprises: a first database hosted by a first service provider unit and configured to store a first entry linking the cryptographic hash value to the first part of the secure token transaction unit identifier, and a second database hosted by a second service provider unit and configured to store a first entry linking the cryptographic hash value to the second part of the secure token transaction unit identifier.
However Checco, in analogous art of storing data linked to hashes, discloses:
wherein the secure token transaction unit identifier linked to the cryptographic hash value is divided into at least first and second parts, and the computer-readable memory comprises: a first database hosted by a first service provider unit and configured to store a first entry linking the cryptographic hash value to the first part of the secure token transaction unit identifier, and a second database hosted by a second service provider unit and configured to store a first entry linking the cryptographic hash value to the second part of the secure token transaction unit identifier (e.g. In some embodiments, hash-based sharding may be performed. For example, data sharding computing platform 110 may generate a hash value from a shard key's value. The hash value may be utilized to allocate data to the various shards. The hash value may then be utilized later to recombine the shards to reconfigure the dataset. In some embodiments, range-based sharding may be performed. For example, data sharding computing platform 110 may partition a range of data values and allocate data to a shard based on an allocated range of data values. Additional, and/or alternative sharding techniques may be utilized to shard the data) (Section [0040]-[0043]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the storing of the secure token transaction unit identifier of Fang/Campbell to include the use of data sharding, as taught by Checco, in order to achieve the predictable result of improving efficiency and load balancing of the data retrieval (See Checco Paragraph 40).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Fang/Campbell/Checco, as applied to claim 9 above, in further view of US 20190278765 A1 (“Ying”).
Per claim 10, although Fang/Campbell/Checco discloses storing a link between a hash value and multiple parts of a secure token transaction unit identifier, Fang/Campbell/Checco does not specifically disclose:
wherein upon receiving the request, the first service provider unit is configured to send the first part of the secure token transaction unit identifier to the requesting secure token transaction unit, the first part comprising address-information identifying a location form which the second part of the secure token transaction unit identifier is retrievable;
or upon receiving the request, the second service provider unit, is configured to send the second part of the secure token transaction unit identifier to the requesting secure token transaction unit, the second part comprising address-information identifying a location form which the first part of the secure token transaction unit identifier is retrievable.
However Ying, in analogous art of storing data linked to hashes, discloses:
wherein upon receiving the request, the first service provider unit is configured to send the first part of the secure token transaction unit identifier to the requesting secure token transaction unit, the first part comprising address-information identifying a location form which the second part of the secure token transaction unit identifier is retrievable (e.g. dividing the data item into a plurality of data partitions; assigning each data partition to a different node in the blockchain network, wherein each node stores the assigned data partition in a privately-maintained distributed hash table; and storing information associated with each data partition in a blockchain maintained by the blockchain network, the information including a storage location of each data partition; receiving a request to retrieve the stored data item, and in response: retrieving each stored data partition from the assigned nodes based on the information including the location of each data partition stored in the blockchain; reconstructing the stored data item from the stored data partitions; and sending a response to the request to retrieve the stored data item, wherein the response includes the reconstructed data item) (Section [0024]);
or upon receiving the request, the second service provider unit, is configured to send the second part of the secure token transaction unit identifier to the requesting secure token transaction unit, the second part comprising address-information identifying a location form which the first part of the secure token transaction unit identifier is retrievable (e.g. dividing the data item into a plurality of data partitions; assigning each data partition to a different node in the blockchain network, wherein each node stores the assigned data partition in a privately-maintained distributed hash table; and storing information associated with each data partition in a blockchain maintained by the blockchain network, the information including a storage location of each data partition; receiving a request to retrieve the stored data item, and in response: retrieving each stored data partition from the assigned nodes based on the information including the location of each data partition stored in the blockchain; reconstructing the stored data item from the stored data partitions; and sending a response to the request to retrieve the stored data item, wherein the response includes the reconstructed data item) (Section [0024]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the retrieval of the secure token transaction unit identifier of Fang/Campbell/Checco to include location information to determine where the parts are stored, as taught by Ying, in order to achieve the predictable result of improving efficiency and decreasing the time it takes to locate specific records.
Conclusion
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
