DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . 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 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.
This Office Action is in response Applicant communication filed on 2/22/2022.
Restriction/Election Acknowledgement
Applicant’s election on claims 1-10 and 15 without traverse is acknowledged.
Claims
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/2024 has been considered.
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:
“input means configured to receive a hash value…”, “storage means configured to store a link…, and “output means configured to send the secure token transaction unit identifier…” in claim 1;
“…wherein the encryption is performed by a trusted service provider unit…” and “…the encryption is performed by the secure register unit…” in claim 7;
“output means is configured to send the encrypted secure token transaction unit identifier…” in claim 8;
“first storage means hosted by a first service provider unit configured to store a link…” and “second storage means hosted by a second service provider unit configured to store a link…” in claim 9;
“first output means is configured to send the first part of the secure token transaction unit identifier…” and “second output means is configured to send the second part of the secure token transaction unit identifier…” 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. “storage means”, “first storage means”, and “second storage means” are being interpreted as a database which is recited in the specification in section [0019].
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.
Claim 7 is 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 7, the claim recites “the encryption is performed by a trusted service provider unit…”. The specification fails to disclose the adequate structure (e.g. material or acts) and algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail. 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. Similarly, claim 7 further recites “or the encryption is performed by the secure register unit…”. The specification fails to disclose the adequate structure (e.g. material or acts) structure and algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail.
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 “the encryption is performed by a trusted service provider unit…” and “the encryption is performed by the secure register unit…”. 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.
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-10 and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-10 are directed to a system and claim 15 is directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Claim 15 recites receiving a request that includes a hash value that is used to lookup an identifier and then sending the identifier back to requestor. Specifically, the claim recites “receiving… a hash value, wherein the hash value is based on a user information; storing… a links between the received hash value and a secure token transaction unit identifier of a secure token transaction unit of the user, wherein the secure token transaction unit identifier uniquely assigns the secure token transaction unit of the user within the electronic token transaction system, wherein the storage means is configured to store a plurality of the links; sending… the secure token transaction unit identifier upon request from any secure token transaction unit of the electronic token transaction system to the requesting secure token transaction unit”, which is grouped within the “mental processes” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test because the claims involve receiving a request that includes a hash value that is used to lookup an identifier and then sending the identifier back to requestor which falls under the category of concepts performed in the human mind (including an observation, evaluation, judgement, opinion). Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; MPEP § 2106.04(a)). Claim 1 is directed to a system that performs the same functions of claim 15. Therefore Claim 1 is also directed to the abstract idea of receiving a request that includes a hash value that is used to lookup an identifier and then sending the identifier back to requestor.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test, the additional element(s) of claims 1 and 15, such as the use of the secure register unit, electronic token transaction system, secure token transaction unit, input means, storage means, and output means, merely use(s) a computer as a tool to perform an abstract idea. Specifically, the secure register unit, electronic token transaction system, secure token transaction unit, input means, storage means, and output means perform(s) the steps or functions of receiving a request that includes a hash value that is used to lookup an identifier and then sending the identifier back to requestor. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP § 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP § 2106.05(b)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
Claims 1 and 15 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of using a secure register unit, electronic token transaction system, secure token transaction unit, input means, storage means, and output means to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of receiving a request that includes a hash value that is used to lookup an identifier and then sending the identifier back to requestor. As discussed above, taking the claim elements separately, the secure register unit, electronic token transaction system, secure token transaction unit, input means, storage means, and output means perform(s) the steps or functions of the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving a request that includes a hash value that is used to lookup an identifier and then sending the identifier back to requestor. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
The dependent claims 2-10 further describe the abstract idea.
Claims 2-4 further describes the data used to generate the hash value.
Claim 5 recites the abstract idea of encrypting data.
Claim 6 describes the information that is being mapped together.
Claim 7 describes the entities that are performing the encryption.
Claim 8 recites the abstract idea of sending the information to an entity to decrypt the information.
Claim 9 recites the abstract idea of having multiple storage means to store various parts of the information in separate locations.
Claim 10 recites the abstract idea of using a first part of the information to locate a second part of the information.
The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Rejections under 35 § U.S.C. 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that
form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
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 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.
Claims 1-4 and 15 are rejected under 35 U.S.C. 102(a)(1) as disclosed by US 20190340350 A1 to Campbell.
Per claims 1 and 15, Campbell discloses:
input means configured to receive a hash value, wherein the hash value is based on a user information (e.g. At step 506, user device 112 and/or electronic application 116 may send the hash to system 122. In embodiments, system 122 may store the hash which has a unique value, identifier, data, strings, etc., and/or other information. At step 508, user device 112 and/or electronic application 116 may communicate the biometric and identity information to verification server 120) (Section [0220], [0051]-[0055], and Fig. 5);
storage means configured to store a link between the received hash value and a secure token transaction unit identifier of a secure token transaction unit of the user, wherein the secure token transaction unit identifier uniquely assigns the secure token transaction unit of the user within the electronic token transaction system, wherein the storage means is configured to store a plurality of the links (e.g. 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);
output means configured to send the secure token transaction unit identifier upon request from any secure token transaction unit of the electronic token transaction system to the requesting secure token transaction unit (e.g. At step 510, user device 112 may receive an electronic communication indicating registration confirmation or non-confirmation from verification server 120. In embodiments, if verification server 120 has confirmed the user's biometric and identity information, the electronic message may include a unique identifier that may be used by the user of user device 112 and/or electronic application 116 to post and/or view electronic content on another application and/or website. In embodiments, with the user's biometric and identity information confirmed, the user may be able to conduct electronic transactions with electronic tokens or another electronic system associated with using electronic tokens to make purchases on a particular website) (Section [0020], [0055], and [0071]).
Per claim 2, Campbell discloses all the limitations of claim 1 above. Campbell further discloses:
wherein the hash value is 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]).
Per claim 3, Campbell discloses all the limitations of claim 2 above. Campbell further discloses:
wherein the additional information is a type indicator, wherein the type indicator is configured to indicate a type of user information on which the hash value is based on, wherein: a first type indicator is configured to indicate user information that is generated by a communication service provider unit; and/or a second type indicator is configured to indicate user information that is generated by a financial service provider unit, the user information; and/or a third type indicator is configured to indicate user information that is generated by a governmental service provider unit, the user information; a fourth type indicator is configured to indicate user information that is generated by a private service provider unit, the user information being a costumer reference number of the user; a fifth type indicator is configured to indicate user information that is generated by a manufacturer unit, the user information being a serial number or a hardware number; and/or a sixth type indicator is configured to indicate user information that is generated by a private company unit or 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) (Section [0074]).
Note: the limitation “wherein the additional information is a type indicator, wherein the type indicator is configured to indicate a type of user information on which the hash value is based on, wherein: a first type indicator is configured to indicate user information that is generated by a communication service provider unit; and/or a second type indicator is configured to indicate user information that is generated by a financial service provider unit, the user information; and/or a third type indicator is configured to indicate user information that is generated by a governmental service provider unit, the user information; a fourth type indicator is configured to indicate user information that is generated by a private service provider unit, the user information being a costumer reference number of the user; a fifth type indicator is configured to indicate user information that is generated by a manufacturer unit, the user information being a serial number or a hardware number; and/or a sixth type indicator is configured to indicate user information that is generated by a private company unit or 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, Campbell discloses all the limitations of claim 2 above. Campbell further discloses:
wherein the additional information is a special tag, wherein the special tag is configured to further individualize the hash value within the electronic token transaction system, wherein: the special tag is a time-tag configured to indicate a time frame in which the hash value is generated; and/or the special tag is a secret-tag configured to obfuscate the user information; the special tag is a tag configured to indicate further service specific data; the special tag is a service-provider-indicator configured to indicate the service provider; and/or the special tag is a tag known to the user of the secure token transaction unit and configured to be published to the requesting secure token transaction unit for insertion in the request to the secure register unit, wherein the special tag being a one-time-passwords, wherein the link between this hash value and the secure transaction unit identifier is deleted by the secure register unit immediately after being successfully requested by the other 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) (Section [0075]).
Note: the limitation “wherein the additional information is a special tag, wherein the special tag is configured to further individualize the hash value within the electronic token transaction system, wherein: the special tag is a time-tag configured to indicate a time frame in which the hash value is generated; and/or the special tag is a secret-tag configured to obfuscate the user information; the special tag is a tag configured to indicate further service specific data; the special tag is a service-provider-indicator configured to indicate the service provider; and/or the special tag is a tag known to the user of the secure token transaction unit and configured to be published to the requesting secure token transaction unit for insertion in the request to the secure register unit, wherein the special tag being a one-time-passwords, wherein the link between this hash value and the secure transaction unit identifier is deleted by the secure register unit immediately after being successfully requested by the other 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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Campbell, as applied to claim 1 above, in further view of US 20190260575 A1 (“Nenov”).
Per claim 5, Campbell discloses all the limitations of claim 1 above. Although Campbell discloses storing a secure token transaction unit identifier, Campbell does not specifically disclose:
wherein the secure token transaction unit identifier is encrypted prior storing and an encrypted 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 prior storing and an encrypted 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 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, Campbell/Nenov disclose all the limitations of claim 5 above. Campbell further discloses:
wherein the link as stored comprises the encrypted secure token transaction unit identifier and a trusted service provider unit identifier (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).
Per claim 7, Campbell/Nenov disclose all the limitations of claim 5 above. Nenov further discloses:
wherein the encryption is performed by a trusted service provider unit or the encryption is performed by the secure register unit upon receipt of an encryption key 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 Campbell is disclosed above with reference to claim 5.
Per claim 8, Campbell/Nenov disclose all the limitations of claim 5 above. Nenov further discloses:
wherein upon request from any secure token transaction unit of the electronic token transaction system the output means is configured to send the encrypted secure token transaction unit identifier to a trusted servicer provider unit corresponding to the trusted service provider unit identifier for decrypting the encrypted secure token transaction unit identifier (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 Campbell is disclosed above with reference to claim 5.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Campbell, as applied to claim 1 above, in further view of US 20210243256 A1 (“Checco”).
Per claim 9, Campbell discloses all the limitations of claim 1 above. Although Campbell discloses storing a link between a hash value and a secure token transaction unit identifier, Campbell does not specifically disclose:
wherein the storage means comprises at least: a first storage means hosted by a first service provider unit configured to store a link between the received hash value and a first part of the secure token transaction unit identifier, and a second storage means hosted by a second service provider unit configured to store a link between the received hash value and a second part of the secure token transaction unit identifier.
However Checco, in analogous art of storing data linked to hashes, discloses:
wherein the storage means comprises at least: a first storage means hosted by a first service provider unit configured to store a link between the received hash value and a first part of the secure token transaction unit identifier, and a second storage means hosted by a second service provider unit configured to store a link between the received hash value and a 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 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 Campbell/Checco, as applied to claim 9 above, in further view of US 20190278765 A1 (“Ying”).
Per claim 10, although Campbell/Checco discloses storing a link between a hash value and multiple parts of a secure token transaction unit identifier, Campbell/Checco does not specifically disclose:
wherein the output means comprises: a first output means hosted by the first service provider unit, and a second output means hosted by the second service provider unit, and wherein upon request from any secure token transaction unit to the first output means, the first output means is configured to send the first part of the secure token transaction unit identifier to the requesting secure token transaction unit, wherein the first part comprises address-information about the second part of the secure token transaction unit identifier;
or wherein upon request from any secure token transaction unit to the second output means, the second output means is configured to send the second part of the secure token transaction unit identifier to the requesting secure token transaction unit, wherein the second part comprises address-information about the first part of the secure token transaction unit identifier.
However Ying, in analogous art of storing data linked to hashes, discloses:
wherein the output means comprises: a first output means hosted by the first service provider unit, and a second output means hosted by the second service provider unit, and wherein upon request from any secure token transaction unit to the first output means, the first output means is configured to send the first part of the secure token transaction unit identifier to the requesting secure token transaction unit, wherein the first part comprises address-information about the second part of the secure token transaction unit identifier (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 wherein upon request from any secure token transaction unit to the second output means, the second output means is configured to send the second part of the secure token transaction unit identifier to the requesting secure token transaction unit, wherein the second part comprises address-information about the first part of the secure token transaction unit identifier (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 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
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US Publication Number 20180183587 A1 to Won teaches a system and method that allows a user to register IOT devices using their digital wallet. US Publication Number 2023/0298015 to Kiraz teaches a system and method for securely storing hashed data. US Publication Number 2022/0156744 A1 to Iliev teaches a system and method that hashes a wallet ID and if the hash is found then the wallet is activated.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/TS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698