DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the reply filed on 01/05/2026.
Claims 1-7 are elected.
Claim 8-20 are withdrawn
Claims 1-3 and 6-7 are currently amended.
Claims 1-7 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 01/05/2026 have been fully considered but they are not persuasive.
Applicant argues that the claims are integrated into a practice application on pages 9-12. Specifically, applicant argues “The improvement achieved by the claimed process is an improvement in a technical field. Claim 1 recites a technical process for interacting with various computing systems (e.g., a first computer device, a computer system, a transaction server, a first cryptographic wallet, a second cryptographic wallet, etc.) to generate an identity verification token, and validate the identity verification token to authorize a transaction. These features are for a technical process that improves cryptographic techniques for transactions linked to cryptographic wallets. (response at 12)
Examiner respectfully disagrees, the argues improvements amount to mere instruction to apply the exception to a computer environment as the claim amount to “The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it".” (MPEP 2106.05(f)(1))
Applicant further argues the clams are analogues to Example 42.
Examiner respectfully disagrees, the current claims do not standardize a format, automatically generate a message, or transmit a message to all users. Instead the instant claims performs a transaction by using verification of cryptographic tokens to verify the parties of the transaction. Therefore, Example 42 does not apply.
Applicant further argues Step 2b Starting on page 13 off the response.
Applicant cites the claimed language and argues that “At least these steps cannot reasonably be said to be performed in the human mind or with pen and paper. Accordingly, these are additional features provide an inventive concept that render the claims patent eligible under step 2B.” (response at 14).
Examiner respectfully disagrees, the claims considered abstract as fundamental economic practice as the claims includes a transaction.
For at least the reasons stated above applicant’s arguments are not persuasive.
Applicant’s arguments, filed 01/05/2026, with respect to the 35 U.S.C. § 103 rejection is not persuasive as the amendments require further search. Examiner asserts that the claims are obvious over Laiben et al. (US 2018/0276626 A1) as outlined in the rejection below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In the instant case, claims 1, are directed to a system.
Claim 1 recites “cryptographic transaction” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). Claim 1 recites
A computer system for cryptographic security, the computer system comprising: at least one hardware processor; and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the computer system to:
receive, from a first computer device associated with a first cryptographic wallet, a verification request including identification information identifying a first entity associated with the first cryptographic wallet;
in response to receiving the verification request, generate, using an identity verification standard and based on the identification information, a first identity verification token verifying the first entity associated with the first cryptographic wallet, and transmit the first identity verification token to the computer device;
receive, from a transaction server, a validation request associated with a cryptographic transaction wherein the validation requests includes the first identity verification token and a second identity verification token, wherein the second identity verification token is associated with identifying a second entity associated with a second cryptographic wallet, wherein the cryptographic transaction is linked to the first cryptographic wallet and the second cryptographic wallet using the first identity verification token and the second identity verification token; and
in response to receiving the validation request, validate, using the identity verification standard, the identity verification token to generate validation information for the entity associated with the cryptographic wallet; and transmit the validation information to the transaction server for performing the cryptographic transaction linked to the cryptographic wallet.
The additional elements of claim 1 such as “A computer system for cryptographic security, the computer system comprising: at least one hardware processor; and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the computer system to:”, “from a first computer device associated with a first cryptographic wallet”, “wherein the cryptographic transaction is linked to the first cryptographic wallet and the second cryptographic wallet”, represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. And, as the additional element does no more than provide a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use, it does computer functionality or improve another technology or technical field.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of fundamental economic practice.
Hence, claim 1 is not patent eligible.
Claim 2 recites “wherein the …transaction is stored in a block of a …, and wherein the block includes the first identity verification token, an identifier of the first… wallet, an amount of …currency processed by the … transaction, and/or a date and time of the … transaction.” However, this does no more than describe the abstract idea. The additional elements of “…cryptographic… block chain… cryptographic…crypto… cryptographic… cryptographic” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 3 recites “wherein the block includes an address of the first cryptographic wallet, a username of the first cryptographic wallet, a screenname of the first cryptographic wallet, a barcode of the first cryptographic wallet, and/or a quick response (QR) code of the first cryptographic wallet.” However, this does no more than describe the abstract idea.
Claim 4 recites “wherein the identity verification standard is a Know Your Customer (KYC) or an eKYC standard.” However, this does no more than describe the abstract idea.
Claim 5 recites the additional elements of “wherein the transaction server is part of the computer system.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 6 recites “wherein the first… wallet is a … wallet or a hardware wallet” However, this does no more than describe the abstract idea. The additional elements of “…cryptographic … software …hardware…” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 7 recites the additional elements of “wherein the first identity verification token is a onetime password, a disconnected token, a connected token, a contactless token, a single sign-on software token, or a programmable token.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect an improvement to another technology or technical field, the claims do not amount to an improvement to the functioning of a computer system itself, and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Laiben et al. (US 2018/0276626 A1) in view of Pala et al. (US 2019/0295069 A1).
Regarding Claim 1
Laiben teaches:
A computer system for cryptographic security, the computer system comprising: at least one hardware processor; and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the computer system to: (See at least Laiben [0052] As used herein, the term “computer” describes hardware which generally implements functionality provided by digital computing technology, particularly computing functionality associated with microprocessors. The term “computer” is not intended to be limited to any specific type of computing device)
receive, from a transaction server, a validation request associated with a cryptographic transaction wherein the validation requests includes the first identity verification token and a second identity verification token, (See at least Laiben [0025] providing a first public key identifying a first account on the blockchain network, the first public key being associated with the first computer, providing a second public key identifying a second account on the blockchain network, the second public key being associated with the second computer;)
wherein the second identity verification token is associated with identifying a second entity associated with a second cryptographic wallet, (See at least Laiben [0025] providing a second public key identifying a second account on the blockchain network, the second public key being associated with the second computer;)
wherein the cryptographic transaction is linked to the first cryptographic wallet and the second cryptographic wallet using the first identity verification token and the second identity verification token; and (See at least Laiben [0025] receiving, at the second computer, a request for the resource; receiving, at the first computer from the second computer, transaction data for a transaction to access to the content, the transaction data including the second public key; receiving, at the central authority server from the first computer, the first public key and a transaction request including the transaction data and the second public key;)
in response to receiving the validation request, validate, using the identity verification standard, the first identity verification token and the second identity verification token to generate validation information for the first entity associated with the cryptographic wallet and the second entity associated with the cryptographic wallet; and (See at least Laiben [0025] the central authority server verifying, based on the received transaction request, the first public key, and the second public key that the transaction is valid on the blockchain network according to the ruleset;)
transmit the validation information to the transaction server for authorizing the cryptographic transaction linked to the first cryptographic wallet and the second cryptographic wallet. (See at least Laiben [0025] receiving, at the first computer from the central authority server, the authentication token; receiving, at the second computer from the first computer, the authentication token; and the first computer accessing the resource hosted by the second computer.)
However Di Lorio does not specifically teach “receive, from a first computer device associated with a first cryptographic wallet, a verification request including identification information identifying a first entity associated with the first cryptographic wallet; in response to receiving the verification request, generate, using an a identity verification standard and based on the identification information, a first identity verification token verifying the first entity associated with the first cryptographic wallet, and transmit the first identity verification token to the first computer device;
However Pala teaches:
receive, from a computer device associated with a cryptographic wallet, a verification request including identification information identifying an entity associated with the cryptographic wallet; (See at least Pela [0050] In exemplary operation, process 200 begins at step S205, in which the owner 103 requests a certificate for one or more wallets. In step S210, the wallet authority responds by generating a nonce. A nonce is an arbitrary/random number that can be used just once in a cryptographic communication. In step S215, the wallet authority 104 transmits the nonce to the owner 103. In step S220, for each wallet address that the owner desires to include in the digital certificate, the owner 103 encrypts the nonce using the private key associated with that wallet address. The encrypted nonce is provided as proof of possession of the wallet address. In some embodiments, a single nonce is provided and encrypted. In other embodiments, multiple nonces are provided, one per wallet address. In these embodiments, the owner 103 encrypts each nonce with the private key associated with the corresponding wallet address, such as in a one to one basis.)
in response to receiving the verification request, generate, using an identity verification standard and based on the identification information, an identity verification token verifying the entity associated with the cryptographic wallet, and transmit the identity verification token to the computer device; (See at least Pela [0051]-[0052]: [0051] In step S225, the owner 103 then generates the certificate request. In the exemplary embodiment, the certificate request includes the wallet address, public key, and the private key encrypted nonce. In some embodiments, the certificate request may include multiple sets of data, such as for multiple wallet addresses. [0052] In step S230, the owner 103 transmits S230 the certificate request to the wallet authority 104. In step S235, the wallet authority 104 verifies the proof of possession by decrypting the nonce using the public key for each of the wallet addresses. In step S240, if the nonce is properly decrypted, the wallet authority 104 generates the enhanced digital certificate based on the information in the certificate request. In an embodiment of step S240, the wallet authority 104 generates the enhanced digital certificate internally. In other embodiments of step S240, the wallet authority 104 transmits the information in the certificate request to CA 108 (shown in FIG. 1) to generate the enhanced digital certificate. In step S245, the wallet authority 104 transmits the enhanced digital certificate to the owner 103. In step S250, the owner 103 verifies the information in the enhanced digital certificate.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the Blockchain method of Laiben in view of with Method for integrating cryptocurrency wallet identifiers with digital certificates as taught by Pala in order to increase the security of information/transactions over networks. (Pala [0033])
Regarding Claim 2
Di Iorio teaches:
The computer system of claim 1, wherein the cryptographic transaction is stored in a block of a block chain, and wherein the block first includes the identity verification token, an identifier of the cryptographic wallet, an amount of cryptocurrency processed by the cryptographic transaction, and/or a date and time of the cryptographic transaction. (See at least Laiben [0080] The blockchain technology underlying most cryptocurrencies is relatively simple in principle, but the technical details can be difficult to understand. It may be simplest to understand the blockchain technology by comparing a conventional online transaction to a cryptocurrency transaction. An example of such a transaction is set forth in FIG. 1A. In the depicted FIG. 1A, a user 109A who will be referred to herein as “Alice” for convenience, is using the Internet 103 via a personal computing device 111A. If Alice 109A desires to transfer money to a third party, such as Bob 109B. Charla 109C, or David 109D, Alice 109A arranges the transaction through her bank 105 over the internet 103. The bank 105 keeps track of an authoritative master ledger 107 of the account balances of its members. Thus, if Alice 109A, who only has $100.00 in the bank 105, attempts to transfer $125.00 to Bob 109B, the bank 105 can determine quickly that Alice does not have sufficient funds to do so, and reject the transaction. Additionally, the bank 105 can use authentication techniques to determine with a high degree of confidence that the requested transaction does indeed originate from Alice 109A, and is not a fraudulent transaction instituted by Bob 109B, for example. This is done through login tokens, passwords, and other forms of user authentication common in the art.)
Regarding Claim 3
Di Iorio teaches:
The computer system of claim 2, wherein the block includes an address of the first cryptographic wallet, a username of the first cryptographic wallet, a screenname of the first cryptographic wallet, a barcode of the first cryptographic wallet, and/or a quick response (QR) code of the first cryptographic wallet. (See at least Laiben [0117] The server 203, in response to registration attempt or successful registration, creates 403 a public address and private key associated with the account for use in the blockchain 205. This information is generally stored in the database 301.)
Regarding Claim 5
Di Iorio teaches:
wherein the transaction server is part of the computer system. (See at least Laiben [0075] It will be understood by one of ordinary skill in the art that common parlance in the computing industry refers to a “user” accessing a “site.” This usage is intended to represent technical access to an online server by a user via a user computer. That is, the reference to a “user” accessing a “server” refers to the user manipulating or otherwise causing client software to communicate over a telecommunications network with server software. This also typically means that the user's client software is running on a client computer system and accessing the server computer system remotely. Although it is possible that a user may directly access and use the server via the server hardware, and without use of a client system, this is not the typical use case in a client/server architecture.)
Regarding Claim 6
Di Iorio teaches:
wherein the cryptographic wallet is a software wallet or a hardware wallet. (See at least Laiben [0085] This technology is also used to confirm the origin of cryptocurrency transactions. Cryptocurrency users have a computer file called a “wallet,” which is essentially a program that allows the user to store and spend cryptocurrency by submitting a transaction to the cryptocurrency's ledger. )
Regarding Claim 7
Di Iorio teaches:
wherein the identity verification token is a onetime password, a disconnected token, a connected token, a contactless token, a single sign-on software token, or a programmable token. (See at least Laiben [0123] Each participant may have its own unique credentials 503 with respect to the server 203, such as, without limitation, an encrypted access token (such as, but not necessarily limited to, a public address), in the same manner as a regular user.)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Laiben et al. (US 2018/0276626 A1) in view of Pala et al. (US 2019/0295069 A1) and further in view of Ow et al. (US 2022/0393881 A1).
Regarding Claim 4
Laiben teaches: Does not specifically teach: wherein the identity verification standard is a Know Your Customer (KYC) or an eKYC standard.
However Ow teaches
wherein the identity verification standard is a Know Your Customer (KYC) or an eKYC standard. (See at least Ow [0020] AXEL can also incorporate mechanisms to comply with identification and anti-corruption due diligence requirements, such as regulations directed at money laundering activities. For example, to comply with current regulations AXEL may include an “anti-money laundering” (AML) and “know your customer” (KYC) mechanism to ensure positive identity of the participants on the AXEL blockchain. At account creation, users will disclose information about themselves during the sign up process, as well as information about the devices they are utilizing to connect to the AXEL blockchain.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the Blockchain method of Laiben and Pala in view of with autonomous exchange via entrusted ledger digital signature management as taught by Ow in order to ensure the privacy and security of the content being stored as the keys required to access and execute the stored content resides with the user who owns the content. (Ow [0018])
Prior Art of Record Not Currently Relied Upon
Kim et al. (US 2022/010326 A1) Teaches Method for cybersecurity
Spector et al. (US 2019/0066095 A1) Teaches: Methods for mobile wallet payments.
Di Iorio et al (US 2019/0354963 A1) Teaches: Cryptographic transactions
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 concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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, Ryan Donlon can be reached at 571-270-3602. 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 June 26, 2026
Prosecution Insights