DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 09/29/2025.
Claims 6, 14 and 20 are cancelled.
Claims 1, 7, 9, and 15 are amended.
Claims 1-5, 7-13 and 15-19 are pending.
Claims 1-5, 7-13 and 15-19 have been examined.
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 .
Response to Arguments
Applicant's arguments filed 09/29/2025 have been fully considered but they are not persuasive.
101
Applicant argues the recited claims “Independent claims 1, 9, and 15 integrate any alleged judicial exception into a practical application for at least the reason that they include features that improve storage overhead and security within a blockchain system by providing a centralized and trusted storage for identity information in a decentralized system. eliminating the need for identity information to be individually stored at platforms.” Examiner disagrees.
First, it is unclear from the recited limitations which ones achieve this claimed improvement, the bulk of the claims recite the receipt and sending of information. Additionally, The use of a distributed ledger or blockchain does not preclude the claim from reciting an abstract idea. As recited in the claims, the blockchain is used to receive, send and store information. These are not improvements to the blockchain or the recited entities performing the limitations.
Secondly, the abstract idea is directed to certain methods of organizing human activity grouping of abstract ideas, specifically, managing interactions, for example, creating an ID for access to user information and restricting access to the user information. In order to fully embrace Applicant’s argument, the premise that protecting user information by restricting access to it is not a “nontechnical human activity," or "fundamental activity that forms the basis of our democracy," would have to be true. Applicant’s claims automate a nontechnical human and fundamental activity in the protection of user information. The claims do relate to any type of "nontechnical human activity," "fundamental activity that forms the basis of our democracy,". for which the courts relate to "methods of organizing human activity."”
Finally, the recited improvements appear to be directed at improvements to a business process, “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology.” MPEP 2106.05(a) (II)
The rejection is maintained.
103
Applicant’s arguments with respect to the claim(s) have been considered but are moot because the new ground of rejection does not rely on the combination of references applied in the prior rejection.
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-5, 7-13 and 15-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, claim 9 is directed to a machine and claim 15 is directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “receiving … request… verifying … signature… generation…token… broadcasting a message … receiving … request… and …executing… a function call….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, managing interactions, for example, creating an ID for access to user information and restricting access to the user information. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application. The use of a distributed ledger or blockchain does not preclude the claim from reciting an abstract idea as the blockchain recites functions of a generic computer component, such as storing records.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “receiving … request… verifying … request… generation…token… broadcasting a message … receiving … request… and sending… a second message” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of managing interactions as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claims 4, 5, 7, 12, 13, 18 and 19 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
Claims 2, 3, 8, 10, 11, 16 and 17 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. 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.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2-5, 7,8, 10-13 and 16-19 are also rejected.
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-5, 7-13 and 15-19 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 applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 9 and 15 recite “receiving, at the self-executing program and from a second application different from the first client application and based at least in part on the identity attestation token indicating the address of the self-executing program stored on the blockchain distributed data store, a second request to obtain the first identity information for the user, the second request including an identifier for the identity attestation token; and executing, by the self-executing program, a function call that sends, to the second application after receiving the second request and based at least in part on the identifier for the identity attestation token, a second message that includes information indicative of the off-chain data source, wherein the information allows the second application to access the first identity information in the off-chain data source”. According to the disclosure(42), “the DApp 225 may retrieve the smart contract address for the smart contract 220 that generated the token and initiate communications with the smart contract 220 to retrieve the user identity information. For example, the DApp 225 may call a function of the smart contract 220 by broadcasting a message via the blockchain network. The function call (e.g., function call 290) may include an indication of the token (e.g., a token identifier), a wallet address of the user wallet 215, a user identifier (e.g., as retrieved from the token), or a combination thereof. In response to receiving the function call 290, the smart contract 220 may return location information for the user identity information stored in the off-chain data source.” According to the disclosure, the function call is the message sent to request user identity information. The disclosure does not provide support for receiving, at the self-executing program and from a second application different from the first client application and based at least in part on the identity attestation token indicating the address of the self-executing program stored on the blockchain distributed data store, a second request to obtain the first identity information for the user, the second request including an identifier for the identity attestation token; and then executing, by the self-executing program, a function call that sends, to the second application after receiving the second request and based at least in part on the identifier for the identity attestation token, a second message that includes information indicative of the off-chain data source, wherein the information allows the second application to access the first identity information in the off-chain data source. Dependent claims 2-5, 7,8, 10-13 and 16-19 are also rejected.
Claim Rejections - 35 USC § 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, 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-5, 7-13 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Terborg et al (US 2024/0013198) (“Terborg”), in view of Padmanabhan (US20230080927) (“Padmanabhan”) and further in view of Hwang (US 12,105,789) (“Hwang”).
Regarding claims 1, 9 and 15, Terborg discloses receiving, via a blockchain network that supports a blockchain distributed data store, at a self-executing program stored on the blockchain distributed data store, and from a first client application associated with the self-executing program, a first request to mint an identity attestation token for a user, wherein the first request includes an indication of a wallet address on the blockchain distributed data store for the user (Abstract; ¶ 26-29, 33, 40-51, 58);
Terborg - the gate system 102 provides a decentralized application accessible by users. In order to create an identity token, any user who desires to do so may access the decentralized application. In this decentralized application, all the necessary information for creating the token may be uploaded…Second, when the token is stored in a wallet, the system would interpret that this wallet and its contents are tied to a user whose identity matches that of the token.. … The token ID may have one or more of the following properties. First, there is no need for a central authority to issue it, and anyone with writing access to the immutable database is able to create such a token by using the decentralized tool intended for this purpose….In some embodiments, the gate system 102 and/or the immutable database 103 are configured to include a tokenized ID (also referred to as “ID token”) system with a track record of verifications, and a process to link a tokenized ID with a wallet and provide proof of control…. (¶ 40, 41, 45)
generating, in accordance with verifying the first signature and the second signature, the identity attestation token that includes on- chain metadata stored on the blockchain distributed data store, the on-chain metadata indicative of first identity information, for the user, that is stored in an off-chain data source separate from the blockchain distributed data store, (Abstract; ¶ 26-35, 40-52, 73);
Terborg - the gate system 102 provides a decentralized application accessible by users. In order to create an identity token, any user who desires to do so may access the decentralized application. In this decentralized application, all the necessary information for creating the token may be uploaded. … A typical ID token 200 may include one or more sets of biometric data 210, and/or one or more identity documents 220….The system uploads the information (e.g., the biometric data and/or previous ID token) to the decentralized app that will then create the token and add the data from the wallet requesting the creation…after receiving the wallet address, the gate system 102 can request the ID token and the one or more access tokens contained in the wallet from the immutable database 103 (represented by arrow 122), causing the immutable database 103 to send both the ID token and the access tokens to the gate system 102 (represented by arrow 123)… he ID token contains identity data associated with the user, and the access tokens contain permission data associated with the user. Identity data includes a specific set of user information that is used to identify and/or authenticate the user. (¶ 33, 34, 42, 45, 51, 58)
broadcasting, via the blockchain network, a message that transfers the identity attestation token to the wallet address for the user, wherein broadcasting the message attributes ownership of the identity attestation token to the wallet address on the blockchain distributed data store (¶ 40-52, 58-67);
Terborg - The token will be stored in the user's wallet, which means that the user will be in control of removing them or keeping them. A verification token may contain one or more of the following data: (1) a verification entity, (2) tokens and biometrics verified at the time and score of the verification, (3) a time stamp, (4) a verified ID token, (5) a wallet address where the ID token was in… The system uploads the information (e.g., the biometric data and/or previous ID token) to the decentralized app that will then create the token and add the data from the wallet requesting the creation. (¶ 51, 58)
receiving, at the self-executing program and from a second application different from the first client application and based at least in part on the identity attestation token indicating the address of the self-executing program stored on the blockchain distributed data store, a second request to obtain the first identity information for the user, the second request including an identifier for the identity attestation token; and (Abstract; ¶ 5, 40-52, 58, 61-85);
Terborg - The gate system 102 receives 802 a request for accessing a secure resource from a client device of a user (e.g., user client device 101) of an immutable database (e.g., immutable database 103). The gate system 102 requests 804 for a wallet address associated with a wallet of the user from the client device of the user. The gate system 102 receives 806 the wallet address associated with the wallet of the user from the client device of the user… The system receives a request for accessing a secure resource from a client device of a user of an immutable database (e.g., a distributed ledger or a blockchain). Responsive to receiving the request, the system requests a wallet address associated with a wallet from the client device of the user, and requests an identifier (ID) token from the immutable database based on the wallet address…Responsive to receiving the second set of identity data of the user from the client device, the system compares the first set of identity data with the second set of identity data to determine whether there is a match. (¶ 5, 76)
executing, by the self-executing program, a function call that sends, to the second application after receiving the second request and based at least in part on the identifier for the identity attestation token, a second message that includes information indicative of the off-chain data source, wherein the information allows the second application to access the first identity information in the off-chain data source (Abstract; ¶ 5, 40-52, 58, 61-85);
Claim Interpretation – According to the disclosure(¶ 42) , “In some cases, the DApp 225 may retrieve the smart contract address for the smart contract 220 that generated the token and initiate communications with the smart contract 220 to retrieve the user identity information. For example, the DApp 225 may call a function of the smart contract 220 by broadcasting a message via the blockchain network. The function call (e.g., function call 290) may include an indication of the token (e.g., a token identifier), a wallet address of the user wallet 215, a user identifier (e.g., as retrieved from the token), or a combination thereof. In response to receiving the function call 290, the smart contract 220 may return location information for the user identity information stored in the off-chain data source. ”
Terborg - The gate system 102 receives 802 a request for accessing a secure resource from a client device of a user (e.g., user client device 101) of an immutable database (e.g., immutable database 103). The gate system 102 requests 804 for a wallet address associated with a wallet of the user from the client device of the user. The gate system 102 receives 806 the wallet address associated with the wallet of the user from the client device of the user… The system receives a request for accessing a secure resource from a client device of a user of an immutable database (e.g., a distributed ledger or a blockchain). Responsive to receiving the request, the system requests a wallet address associated with a wallet from the client device of the user, and requests an identifier (ID) token from the immutable database based on the wallet address…Responsive to receiving the second set of identity data of the user from the client device, the system compares the first set of identity data with the second set of identity data to determine whether there is a match. (¶ 5, 76)
Terborg does not explicitly disclose verifying a first signature and a second signature included in the first request, the first signature associated with an operator associated with the self-executing program and the second signature associated with a blockchain wallet of the user; wherein the identity attestation token indicates an address of the self-executing program and wherein the first identity information comprises a superset of the on-chain metadata.
Padmanabhan teaches wherein the identity attestation token indicates an address of the self-executing program and wherein the first identity information comprises a superset of the on-chain metadata (¶ 127-133, 161-188, 213-228, 251-255)
Padmanabhan - In some implementations, the smart contract 1700 is a computer program that may be included within a public trust ledger such as a blockchain… information identifying the digital assets and/or parties may be located by accessing a database table and/or a public trust ledger to retrieve information stored therein…The NFS 1496 may allow servers located in the pod 1444 to access information over a network in a manner similar to how local storage is accessed…The smart contract chain 1600 includes a root node 1602, which is an item smart contract template. The item smart contract template 1602 is a smart contract template for creating a particular type of item, such as a fungible or non-fungible token…when a request is received to identify one or more rights related to a token included in a smart contract instance such as the smart contract instance 5 1614 shown in FIG. 16 , references to other smart contracts within the chain may be navigated to identify those other smart contracts as well as the owners of those smart contracts. (¶ 161, 213, 218, 224, 228).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Terborg and Padmanabhan(¶ 59, 270), which teaches “One or more transfers of the one or more NFTs between accounts in the public trust ledger are executed at 108. According to various embodiments, the one or more transfers may be recorded by executing the one or more smart contracts created at 104… For example, a smart contract template may specify one or more transfer restrictions ” in order to provide improved techniques for the transaction management process (Padmanabhan; ¶ 4-6).
Hwang teaches verifying a first signature and a second signature included in the first request, the first signature associated with an operator associated with the self-executing program and the second signature associated with a blockchain wallet of the user (¶ 60-75; claim 3, 9)
Hwang - electronic device 200 may add its own electronic signature to the access request with the electronic signature of user 210 to generate the download request for the digital asset. After receiving the download request, database 120 may use both the device's public key and the user's public key to verify the identity of both electronic device 200 and user 210 based on their respective electronic signatures. (¶ 68, claim 3, 9).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Terborg, Padmanabhan and Hwang (¶ 5), which teaches “manage the use of digital assets, prevent copyright thefts of digital assets, and thereby demonstrate and enhance the value of digital assets” in order to provide digital assets that prevent mass replication and unauthorized reuse (Hwang; ¶ 4-6).
Regarding claims 2, 10 and 16, Padmanabhan teaches wherein the information indicative of the off- chain data source comprises an address for a second self-executing program used to request the first identity information for the user (¶ 79, 110, 128-133, 156, 224, 251-255).
Regarding claims 3, 11 and 17, Terborg discloses wherein the information indicative of the off- chain data source comprises a uniform resource locator used to request the first identity information for the user (¶ 72).
Regarding claims 4, 12 and 18, Padmanabhan teaches wherein generating the identity attestation token comprises: generating the identity attestation token with one or more parameters that restrict transfer of the identity attestation token to another wallet address (¶ 270-277, 289-293).
Regarding claims 5, 13 and 19, Terborg discloses wherein receiving the first request comprises: receiving the first request that includes an identifier for the user, wherein the generated identity attestation token includes the identifier for the user (Abstract; ¶ 26, 40-52). Padmanabhan teaches wherein the identifier restricts transfer of the identity attestation token to another user (¶ 270-277, 289-293).
Regarding claim 7, Padmanabhan teaches wherein receiving the second request to obtain the first identity information comprises: receiving the second request from the second application that is a second self- executing program stored on the blockchain distributed data store (¶ 110, 128-133, 156, 224, 251-255).
Regarding claim 8, Terborg discloses wherein the identity attestation token is further indicative of second identity information, for the user, that is stored in a second off-chain data source (Abstract; ¶ 26-29, 33, 40-51, 58).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ergen et al. (US 20240211947) teaches requesting and creating a user ID token for access and use also discusses blockchain systems.
Goal (US 11914697) teaches using the user’s ID token to access a service.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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, NEHA H PATEL can be reached on (571) 270-1492. 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699