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 .
Priority
Applicant’s claim for the benefit of U.S. provisional patent application 63/623,572 filed January 22, 2024 under 35 U.S.C. 119(e) is acknowledged.
Claim Objections
Claims 17, 19 and 20 are objected to because of the following informalities: The preamble of claim 17 recites “The non-transitory computer readable storage medium of The non-transitory computer readable storage medium”. Claims 19 and 20 contain the same recitation in the preamble. Claim 17 would likely be dependent upon claim 16 and claims 19 and 20 would likely be dependent upon claim 15 however no dependency is explicitly stated in the claims and the repeating of the language “The non-transitory computer readable storage medium” is an obvious error. Furthermore only the beginning of a claim should begin with a capital letter (MPEP § 608.01(m)). Appropriate correction is required. For purposes of claim interpretation Examiner is treating claim 17 as being dependent upon claim 16 and claims 19-20 as being dependent upon claim 15.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites a method and therefore meets Eligibility Step 1 of the Patent Subject Matter Eligibility Guidance (MPEP § 2106.03 (I) and (II)).
The analysis then proceeds to Eligibility Step 2A of the Patent Subject Matter Eligibility Guidance. Step 2A is a two-prong inquiry, in which examiners determine in Prong One whether a claim recites a judicial exception, and if so, then determine in Prong Two if the recited judicial exception is integrated into a practical application of that exception. The analysis begins with Prong One of Step 2A. Claim 1 recites creating… a user operation for a transaction based on an intention received from a user, receiving… the user operation with a verifiable credential for the user, validating… the user operation, determining… that there is a paymaster to sponsor the transaction, determining… that the transaction should be sponsored based on the verifiable credential for the user, executing…the transaction and invoking… a post-operation. The written disclosure at paragraph 0073 describes creating a user operation as part of step 210 where “…An example of an intention may be "I want to mint a XYZ NFT because I'm a verified customer of XYZ merchant." XYZ merchant will allow the user to mint this NFT only if the user can show a proof of verified customer verifiable credential that the merchant has issued to the end user” and paragraph 0074 recites “The application may collect all the data from different services that its linked to in order to create the user operation. For example, the application may retrieve the proof of verified customer verifiable credential from the user's identity wallet and may create on-chain verifiable presentations. It may check eligibility with the paymaster service to see if there is a sponsor for this user intent”. In addition to the language from paragraph 0073 the operation of receiving the user operation with a verified credential for the user is described at paragraph 0074 “…For example, the application may retrieve the proof of verified customer verifiable credential from the user's identity wallet and may create on-chain verifiable presentations”. The verifiable credential is described in paragraph 0038 as follows: “Identity wallet 126 may allow a user to claim the user's verifiable credentials, which can include identity attributes, certifications, or other attestations, from a variety of issuers, such as institutions, merchants, identity providers, and other trusted entities, and work with signer service 128 and/or other microservices to produce on-chain representations of verifiable presentations”. Validating the user operation is described at paragraph 0080 as “As a part of the validation function on the smart contract wallet, the smart contract wallet may pass the user operation to an authorization module smart contract, which may verify the user's signature and may check the rules of authorization. Because a verifiable presentation is shared with this module, it may check the validity of the verifiable credential using the on-chain verifier”. Paragraph 0081 goes on to describe that “An on-chain verifier may also check the validity of the verifiable credentials by checking them against the verifiable data registry and may interact with other smart contracts on-chain”. Determining that the transaction should be sponsored is described at paragraph 0082 as follows: “If, in step 230, there is a paymaster willing to sponsor the transaction, in step 235, the entry point contract may provide the user operation through a paymaster contract for the paymaster”. Determining that the transaction should be sponsored based on the verifiable credential for the user is described at paragraph 0083 as follows: “In step 240, the paymaster contract may check the validity of the verifiable credential with the on-chain verifier and may determine if the transaction should be paid for or sponsored based on the verifiable credentials provided by the user via the application as a part of the user operation”. Executing the transaction is described in paragraphs 0084 which restates the claim language “…in step 250, the entry point contract may execute the user operation by calling the arbitrary execution function on the smart contract wallet” and paragraph 0085 which recites “For example, the smart contract wallet may break the user operation into its components, such as user's intent, paymaster data, signature, and any other information required to make a transaction on the blockchain, understands the users intent (e.g., "Mint a XYZ NFT" from the callData field), and communicates (e.g., calls the mint function specifically and pass the verifiable credential data) with the end contract such as the VC gated NFT Smart Contract”. Invoking a post-operation is described at paragraph 0088 “In step 255, after the smart contract is finished executing, the entry point contract may invoke the post operation function on the paymaster. This may carry out post-operation logic, including for example, logging, notifications, or other cleanup operations”. When interpreted in light of the specification the claimed operations involve receiving an indication that a user intends to engage in an operation for a transaction and collecting data needed for the transaction, receiving the indication along with a credential, validation of the user operation which given the lack of specificity can be interpreted as ensuring that the operation meets any requirements, determining that there is a willing sponsor in the form of a paymaster, determining that the transaction should be sponsored based on the verifiable credential, executing the transaction and posting the transaction. The operations of creating a user operation for a transaction, determining that there is a paymaster to sponsor the transaction, determining that the transaction should be sponsored, executing the transaction and invoking a post-operation are similar to those recited in MPEP § 2106.04(a)(2)(II)(B) regarding using advertising as an exchange or currency where in the claim 1 instead of advertising being used as an exchange or currency a verifiable credential is used for the same purpose. Therefore these operations are merely part of a commercial interaction and therefore under Prong One of Step 2A claim 1 is deemed as being directed towards ineligible subject matter.
The analysis then proceeds to Prong Two of Step 2A where the claim is evaluated in order to determine whether additional elements are present sufficient to form a practical application of the abstract idea. The operations of receiving, by an entry point contract in an on-chain environment, the user operation with a verifiable credential for the user and invoking, by the entry point contract, a post-operation that performs post operation logic can be viewed as insignificant extra-solution activity (MPEP § 2106.05(g)) as the receiving of the user operation with a verifiable credential is nothing more than data gathering and the invoking of a post-operation is merely data outputting. The recitations regarding the entry point contract in an on-chain environment in the receiving step and the entry point contract that performs post operation logic also merely tie the operations to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. The operation of creating a user operation for a transaction based on an intention received from a user only recites the idea of a solution or outcome with reciting any details as to how the solution to a problem is accomplished and can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)) and the language that the creating operation is performed by an application executed by a user electronic device in an off-chain environment only tie the exception to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. The operation of validating the user operation using a validating function in a smart contract wallet only recites the idea of a solution or outcome with reciting any details as to how the solution to a problem is accomplished and can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)) and the language that the validating is performed using the entry point contract and the recitation of the smart contract wallet merely tie the exception to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. The operations of determining that there is a paymaster to sponsor the transaction and determining that the transaction should be sponsored based on the verifiable credential for the user can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)). The operation of executing the transaction using an arbitrary execution function in the smart contract wallet only recites the idea of a solution or outcome with reciting any details as to how the solution to a problem is accomplished and can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)) where the recitations regarding the entry point contract and the smart contract wallet merely tie the claim to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. Therefore under Prong Two of Step 2A claim 1 is deemed as being directed towards ineligible subject matter.
The analysis then proceeds to Step 2B in which the claim is evaluated in order to determine whether the claim contains additional elements that amount to significantly more than the abstract idea itself (also referred to as an inventive concept) (MPEP § 2106.05). The recitations regarding the entry point contract in an on-chain environment in the receiving step and the entry point contract that performs post operation logic also merely tie the operations to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. The operation of creating a user operation for a transaction based on an intention received from a user only recites the idea of a solution or outcome with reciting any details as to how the solution to a problem is accomplished and can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)) and the language that the creating operation is performed by an application executed by a user electronic device in an off-chain environment only tie the exception to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. The operation of validating the user operation using a validating function in a smart contract wallet only recites the idea of a solution or outcome with reciting any details as to how the solution to a problem is accomplished and can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)) and the language that the validating is performed using the entry point contract and the recitation of the smart contract wallet merely tie the exception to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. The operations of determining that there is a paymaster to sponsor the transaction and determining that the transaction should be sponsored based on the verifiable credential for the user can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)). The operation of executing the transaction using an arbitrary execution function in the smart contract wallet only recites the idea of a solution or outcome with reciting any details as to how the solution to a problem is accomplished and can be viewed as mere instructions to apply an exception (MPEP § 2106.05(f)) where the recitations regarding the entry point contract and the smart contract wallet merely tie the claim to a particular technological environment (MPEP § 2106.05(h)) and therefore do not contribute to eligibility. These operations are mere instructions to apply an exception (MPEP § 2106.05(f)) and only contain recitations that merely tie the exception to a particular technological environment (MPEP § 2106.05(h)) and therefore do not form an inventive concept. With regard to the operations of receiving, by an entry point contract in an on-chain environment, the user operation with a verifiable credential for the user and invoking, by the entry point contract, a post-operation that performs post operation logic these operations are recited at a high level of generality (MPEP § 2106.05(d)(II) and therefore also do not form an inventive concept. Therefore under Step 2B claim 1 is deemed as being directed towards ineligible subject matter.
Claim 2 recites “signing, by a signer service in the off-chain environment, the user operation”. Paragraph 0040 recites “…For example, signer service 128 may use EIP-712 (Ethereum typed structured data hashing and signing) to present readable and securely signed messages. Signer service 128 may sign regular Ethereum transactions, may sign Ethereum typed data, and may digitally and cryptographically sign messages. It supports various types of cryptographic functionality related to signing, including different types of cryptographic curves (e.g., passkeys).” The claim does nothing more than amount to link the abstract idea a particular technological environment, namely the off-chain environment (MPEP § 2106.05(h)) as signing a transaction is a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A)) and the recitation regarding the off-chain environment merely recites where the abstract idea is being practiced.. Therefore claim 2 is held as being directed towards ineligible subject matter.
Claim 3 recites “…creating, by the signer service, an on-chain verifiable presentation for the verifiable credential, wherein the verifiable credential is received from an identity digital wallet for the user in the off-chain environment”. The claim does nothing more than amount to link the abstract idea a particular technological environment, namely the off-chain environment (MPEP § 2106.05(h)) as signing a transaction and providing credentials is a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A)) and the recitation regarding the off-chain environment and on-chain environment merely recite where the abstract idea is being practiced.. Therefore claim 3 is held as being directed towards ineligible subject matter.
Claim 4 recites “…wherein the user operation comprises a blockchain address for the user, a unique identifier, initialization code for setting up a new contact for the transaction, and a gas limit for execution and verification of the transaction”. The claim recites the nature of the necessary data that is being gathered and outputted and therefore amounts to insignificant extra-solution activity (MPEP § 2106.05(g)). Therefore claim 4 is held as being directed towards ineligible subject matter
Claim 5 recites “…bundling, by a bundler in the off-chain environment, the user operation with a plurality of user operations”. Bundling operations is a form of processing information in a business setting in order to achieve scale that reduces costs and therefore constitutes a portion of a commercial interaction (MPEP § 2106.04(a)(2)(II)(B)). Therefore the recitation involves mere instructions to apply an exception (MPEP § 2106.05(f)) and as such claim 5 is held as being directed towards ineligible subject matter.
Claim 6 recites “…wherein the entry point contract further validates the user operation using an authorization module smart contract”. Validating a user operation is a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A)). Therefore the recitation involves mere instructions to apply an exception (MPEP § 2106.05(f)) and as such claim 6 is held as being directed towards ineligible subject matter.
Claim 7 recites “…wherein the paymaster sponsors a gas fee for the transaction”. Sponsoring a transaction by either reducing a portion or all of the cost is a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A)). Therefore the recitation involves mere instructions to apply an exception (MPEP § 2106.05(f)) and as such claim 7 is held as being directed towards ineligible subject matter.
Claims 8-14 and 15-20 are nearly identical to claims 1-7 but add the operations of passing, by the paymaster service, the user operation and a verifiable presentation to a merchant paymaster service; and verifying, by the merchant paymaster service and using an off-chain verification service, the user operation. Claim 15 also recites a non-transitory computer readable storage medium, including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform the operations of claim 15. The operations of passing, by the paymaster service, the user operation and a verifiable presentation to a merchant paymaster service; and verifying, by the merchant paymaster service and using an off-chain verification service, the user operation do nothing more than amount to link the abstract idea a particular technological environment, namely the merchant paymaster service (MPEP § 2106.05(h)). The non-transitory computer readable storage medium, including instructions stored thereon, which are read and executed by one or more computer processors also does nothing more than link the abstract idea to a particular technological environment (MPEP § 2106.05(h)). Therefore claims 8-14 and 15-20 are also held as being directed towards an abstract idea without a practical application or any inventive concept.
Claim Rejections - 35 USC § 112
Claims 1-20 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.
Claim 1 recites “…creating, by an application executed by a user electronic device in an off- chain environment, a user operation for a transaction based on an intention received from a user”. Claims 8 and 15 contain similar language. The written disclosure at paragraphs 0073-0075 which encompass language regarding the user operation and are as follows:
[0073] In step 210, the application may create a user operation. In one embodiment, after the user logs in, the user may create an intention. An example of an intention may be "I want to mint a XYZ NFT because I'm a verified customer of XYZ merchant." XYZ merchant will allow the user to mint this NFT only if the user can show a proof of verified customer verifiable credential that the merchant has issued to the end user (verification rules set by the merchant on the VC Gated NFT Smart contract).
[0074] The application may collect all the data from different services that its linked to in order to create the user operation. For example, the application may retrieve the proof of verified customer verifiable credential from the user's identity wallet and may create on-chain verifiable presentations. It may check eligibility with the paymaster service to see if there is a sponsor for this user intent. For example, paymaster services, which may be run by different entities such as merchants, the application owner, etc. may offer to sponsor transactions. The paymaster services may decide if a transaction is eligible for sponsorship based on verifiable credentials presented by the user, which prove the user's identity or meet certain criteria.
[0075] A user operation may include, for example, the sender's blockchain address, a unique number to keep operations in order, any necessary initialization code for setting up a new contract, the specific action the user wants to perform, maximum gas limits for execution and verification, the maximum fees the user is willing to pay for gas, information about potential fee sponsorship, and a digital signature to confirm the operation's authenticity.
Paragraph 0073 recites the creation of a user operation but then recites the creation of a user intention along with language defining what an intention is after which a statement is provided that describes what can be described as a rule “…XYZ merchant will allow the user to mint this NFT only if the user can show a proof of verified customer verifiable credential that the merchant has issued to the end user (verification rules set by the merchant on the VC Gated NFT Smart contract).” Paragraph 0074 describes the collection of data necessary to create the user operation and the checks and decisions made in order to allow the creation of a user operation. Paragraph 0075 recites the data that may be present in a user operation. None of the language in paragraphs 0073-0075 actually teach what action or actions a computer would perform in creating a user operation. MPEP § 2161.01 recites that “…original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed.” In the present case the written disclosure describes what the user needs to do to initiate the creation of a user operation, what rules will guide the operation, what actions may take place in order to create the user operation and what data will be included in the user operation but noticeably absent is an actual description of the steps a programmed computer will perform in order to do what the claim requires which is create a user operation. No algorithm is disclosed for creating a user operation. MPEP § 2161.01 provides instructions regarding the examination of computer-implemented functional claims “When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted).” In the present case no algorithm has been presented, nor is there any contextual description sufficient to inform those of ordinary skill how to interpret the written disclosure in a manner that would clearly indicate what the inventor deemed to be the operation of creating a user operation. Therefore claims 1, 8 and 15 are held as failing to establish possession under the written description requirement for a computer implemented functional claim limitation.
Claim 1 recites “executing, by the entry point contract, the transaction using an arbitrary execution function in the smart contract wallet”. Claims 8 and 15 contain similar recitations. The written disclosure at paragraphs 0005, 0012, 0019, 0084 and 0090 merely repeat the recitation from the claim with similar language. The only description of the operation is at paragraph 0085 which recites “For example, the smart contract wallet may break the user operation into its components, such as user's intent, paymaster data, signature, and any other information required to make a transaction on the blockchain, understands the users intent (e.g., "Mint a XYZ NFT" from the callData field), and communicates (e.g., calls the mint function specifically and pass the verifiable credential data) with the end contract such as the VC gated NFT Smart Contract”. The recitation provides only an example result but does not describe how the result is achieved, nor does it even describe in a clear manner what constitutes an arbitrary execution function. No algorithm is disclosed for executing a transaction using an arbitrary execution function. MPEP § 2161.01 provides instructions regarding the examination of computer-implemented functional claims “When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted).” In the present case no algorithm has been presented, nor is there any contextual description sufficient to inform those of ordinary skill how to interpret the written disclosure in a manner that would clearly indicate what the inventor deemed to be the operation of executing a transaction using an arbitrary execution function. Therefore claims 1, 8 and 15 are held as failing to establish possession under the written description requirement for a computer implemented functional claim limitation.
Claim 1 recites “invoking, by the entry point contract, a post-operation that performs post-operation logic”. Claims 8 and 15 contain similar language. Paragraphs 0005, 0012 and 0019 repeat the language of the claim. The lone recitation in the detailed description at paragraph 0088 recites “In step 255, after the smart contract is finished executing, the entry point contract may invoke the post operation function on the paymaster. This may carry out post-operation logic, including for example, logging, notifications, or other cleanup operations”. The recitation provides only an example result but does not describe how the result is achieved, nor does it even describe in a clear manner what constitutes an post-operation logic. No structural description or algorithm is disclosed for invoking a post-operation that performs post-operation logic. MPEP § 2161.01 provides instructions regarding the examination of computer-implemented functional claims “When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted).” In the present case no algorithm has been presented, nor is there any contextual description sufficient to inform those of ordinary skill how to interpret the written disclosure in a manner that would clearly indicate what the inventor deemed to be the operation of invoking a post-operation that performs post-operation logic. Therefore claims 1, 8 and 15 are held as failing to establish possession under the written description requirement for a computer implemented functional claim limitation.
Claims 2-7 are also rejected as being dependent upon claim 1.
Claims 9-14 are also rejected as being dependent upon claim 8.
Claims 16-20 are also rejected as being dependent upon claim 15.
Claim Rejections - 35 USC § 102
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 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 4-7 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Buterin et al. “Account Abstraction Using Alt Mempool” (Also referred to as ERC-4337 or EIP4337), EIPs Insights, September 29, 2021, 21 pages, hereinafter referred to as Buterin).
As per claim 1
Buterin discloses creating, by an application executed by a user electronic device in an off-chain environment, a user operation for a transaction based on an intention received from a user (Abstract “An account abstraction proposal which completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actor called bundlers package up a set of these objects into a transaction making a handleOps call to a special contract, and that transaction then gets included in a block.”, Page 3 “UserOperation - a structure that describes a transaction to be sent on behalf of a user. To avoid confusion, it is not named "transaction". Like a transaction, it contains to, calldata, maxFeePerGas, maxPriorityFeePerGas, nonce, signature. Unlike a transaction, it contains several other fields, described below. Notably, the signature field usage is not defined by the protocol, but by the Smart Contract Account implementation.”, page 13 “Similar to an Ethereum transaction, the offchain flow of a UserOperation can be described as follows: 1. Client sends a UserOperation to the bundler through an RPC call eth_sendUserOperation. 2. Before including the UserOperation in the mempool, the bundler runs the first validation of the newly received UserOperation. If the UserOperation fails validation, the bundler drops it and returns an error in response to eth_sendUserOperation. 3. Later, once building a bundle, the bundler takes UserOperations from the mempool and runs the second validation of a single UserOperation on each of them. If it succeeds, it is scheduled for inclusion in the next bundle, and dropped otherwise. 4. Before submitting the new bundle onchain, the bundler performs the third validation of the entire UserOperations bundle. If any of the UserOperations fail validation, the bundler drops them. The bundler should keep track of the peers' reputation. The full design of such a reputation system is outside the scope of this proposal”)
Buterin discloses receiving, by an entry point contract in an on-chain environment, the user operation with a verifiable credential for the user (page 3 “EntryPoint - a singleton contract to execute bundles of UserOperations. Bundlers should whitelist the supported EntryPoint.”, pages 3 and 4 “The UserOperation structure… Sender - the Smart Contract Account sending a UserOperation…signature…Data passed into the sender to verify authorization”, also “paymaster data” described as “Data for paymaster (only if paymaster exists)”, also page 6 “The userOpHash is a hash over the userOp (except signature), entryPoint and chainId.”)
Buterin discloses validating, by the entry point contract, the user operation using a validation function in a smart contract wallet (page 6
“interface IAccount {
function validateUserOp
(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
external returns (uint256 validationData);
}
The userOpHash is a hash over the userOp (except signature), entryPoint and chainId. The Smart Contract Account: MUST validate the caller is a trusted EntryPoint… MUST validate that the signature is a valid signature of the userOpHash, and SHOULD return SIG_VALIDATION_FAILED (1) without reverting on signature mismatch. Any other error MUST revert”)
Buterin discloses determining, by the entry point contract, that there is a paymaster to sponsor the transaction (Page 4 “paymaster… Address of paymaster contract, (or empty, if the sender pays for gas by itself””, page 11 “…call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation”)
Buterin discloses determining, by a paymaster contract for the paymaster, that the transaction should be sponsored based on the verifiable credential for the user (page 11 “During the verification loop, in addition to calling validateUserOp, the handleOps execution also must check that the paymaster has enough ETH deposited with the EntryPoint to pay for the UserOperation, and then call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation”
page 12
“function validatePaymasterUserOp
(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost)
external returns (bytes memory context, uint256 validationData);”
Buterin discloses executing, by the entry point contract, the transaction using an arbitrary execution function in the smart contract wallet (page 2 “Achieve the key goal of Account Abstraction: allow users to use Smart Contract Accounts containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs, as required by both status quo Smart Contract Accounts and EIP-7702.”)
Buterin discloses invoking, by the entry point contract, a post-operation that performs post-operation logic (page 12
“function postOp
(PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas)
external;
enum PostOpMode {
opSucceeded, // UserOperation succeeded
opReverted // UserOperation reverted. paymaster still has to pay for gas.
}”)
As per claim 4
Buterin discloses wherein the user operation comprises a blockchain address for the user, a unique identifier, initialization code for setting up a new contact for the transaction, and a gas limit for execution and verification of the transaction (page 3 recites “The UserOperation structure” as a header for the section which continues onto page 4 where the user operation structure is defined.
“blockchain address for the user” equates to page 4 “sender, address, The Account making the UserOperation”;
“a unique identifier” equates to page 4 “nonce, uint256, Anti-replay parameter”;
“initialization code for setting up a new contact for the transaction” equates to page 8 “Create the sender Smart Contract Account if it does not yet exist, using the initcode provided in the UserOperation”; and
“a gas limit for execution and verification of the transaction” equates to page 4 “callGaslimit, uint256, The amount of gas to allocate to the main function call” and “verificationGaslimit, uint 256, The amount of gas to allocate to the verification step”)
As per claim 5
Buterin discloses bundling, by a bundler in the off-chain environment, the user operation with a plurality of user operations (page 13
“Bundler behavior upon receiving a UserOperation[AltContent: rect]
Similar to an Ethereum transaction, the offchain flow of a UserOperation can be described as follows:
Client sends a UserOperation to the bundler through an RPC call eth_sendUserOperation.
Before including the UserOperation in the mempool, the bundler runs the first validation of the newly received UserOperation. If the UserOperation fails validation, the bundler drops it and returns an error in response to eth_sendUserOperation.
Later, once building a bundle, the bundler takes UserOperations from the mempool and runs the second validation of a single UserOperation on each of them. If it succeeds, it is scheduled for inclusion in the next bundle, and dropped otherwise.
Before submitting the new bundle onchain, the bundler performs the third validation of the entire UserOperations bundle. If any of the UserOperations fail validation, the bundler drops them. The bundler should keep track of the peers' reputation. The full design of such a reputation system is outside the scope of this proposal”)
As per claim 6
Buterin discloses wherein the entry point contract further validates the user operation using an authorization module smart contract (Page 3 “Aggregator - also known as "authorizer contract" - a contract that enables multiple UserOperations to share a single validation. The full design of such contracts is outside the scope of this proposal.”, Page 6 “All aggregator contracts MUST check that all calls to the validateSignatures() function originates from the EntryPoint.”)
As per claim 7
Buterin wherein the paymaster sponsors a gas fee for the transaction (Page 3 “Paymaster - a helper contract that agrees to pay for the transaction, instead of the sender itself.”, Page 11 “We extend the EntryPoint logic to support paymasters that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with [ERC-20] tokens and many other use cases.”)
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 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Buterin as applied to claim 1 above, and further in view of Decentralized identity, retrieved from https://ethereum.org/en/decentralized-identity/, June 29, 2023, 14 pages, hereinafter referred to as DI.
As per claim 2
Buterin, while disclosing the limitations of claim 1, does not explicitly disclose signing, by a signer service in the off-chain environment, the user operation. DI teaches signing, by a signer service in the off-chain environment, the user operation (pages 5-6, “Off-chain attestations One concern with storing attestations on-chain is that they might contain information individuals want to keep private. The public nature of the Ethereum blockchain makes it unattractive to store such attestations. The solution is to issue attestations, held by users off-chain in digital wallets, but signed with the issuer's DID stored on-chain. These attestations are encoded as JSON Web Tokens and contain the issuer's digital signature—which allows for easy verification of off-chain claims.↗
Here's an hypothetical scenario to explain off-chain attestations:
A university (the issuer) generates an attestation (a digital academic certificate), signs with its keys, and issues it to Bob (the identity owner).
Bob applies for a job and wants to prove his academic qualifications to an employer, so he shares the attestation from his mobile wallet. The company (the verifier) can then confirm the validity of the attestation by checking the issuer's DID (i.e., its public key on Ethereum).”
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Alt Mempool of Buterin further with the Decentralized Identity of DI for the purpose of allowing individuals to manage their identity-related information (page 2).
As per claim 3
DI teaches creating, by the signer service, an on-chain verifiable presentation for the verifiable credential, wherein the verifiable credential is received from an identity digital wallet for the user in the off-chain environment (page 6 “On-chain attestations are held in smart contracts on the Ethereum blockchain. The smart contract (acting as a registry) will map an attestation to a corresponding on-chain decentralized identifier (a public key), page 7 “Soulbound tokens (non-transferable NFTs) could be used to collect information unique to a specific wallet. This effectively creates a unique on-chain identity bound to a particular Ethereum address that could include tokens representing achievements (e.g. finishing some specific online course or passing a threshold score in a game) or community participation.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Alt Mempool of Buterin further with the Decentralized Identity of DI for the purpose of allowing individuals to manage their identity-related information (page 2).
Claims 8-20 are rejected under 35 U.S.C. 103 as being unpatentable over Buterin in view of DI and in view of Ozbay et al. (WIPO Publication WO/038873 A1, hereinafter referred to as Ozbay).
As per claims 8 and 15
Buterin discloses creating, by an application executed by a user electronic device in an off-chain environment, a user operation for a transaction based on an intention received from a user (Abstract “An account abstraction proposal which completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actor called bundlers package up a set of these objects into a transaction making a handleOps call to a special contract, and that transaction then gets included in a block.”, Page 3 “UserOperation - a structure that describes a transaction to be sent on behalf of a user. To avoid confusion, it is not named "transaction". Like a transaction, it contains to, calldata, maxFeePerGas, maxPriorityFeePerGas, nonce, signature. Unlike a transaction, it contains several other fields, described below. Notably, the signature field usage is not defined by the protocol, but by the Smart Contract Account implementation.”, page 13 “Similar to an Ethereum transaction, the offchain flow of a UserOperation can be described as follows: 1. Client sends a UserOperation to the bundler through an RPC call eth_sendUserOperation. 2. Before including the UserOperation in the mempool, the bundler runs the first validation of the newly received UserOperation. If the UserOperation fails validation, the bundler drops it and returns an error in response to eth_sendUserOperation. 3. Later, once building a bundle, the bundler takes UserOperations from the mempool and runs the second validation of a single UserOperation on each of them. If it succeeds, it is scheduled for inclusion in the next bundle, and dropped otherwise. 4. Before submitting the new bundle onchain, the bundler performs the third validation of the entire UserOperations bundle. If any of the UserOperations fail validation, the bundler drops them. The bundler should keep track of the peers' reputation. The full design of such a reputation system is outside the scope of this proposal”)
Buterin discloses receiving, using a paymaster service in the off-chain environment, the user operation (Page 4 “paymaster… Address of paymaster contract, (or empty, if the sender pays for gas by itself””, page 11 “…call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation”)
Buterin discloses determining, using the paymaster service, that the transaction is eligible for sponsoring (page 11 “During the verification loop, in addition to calling validateUserOp, the handleOps execution also must check that the paymaster has enough ETH deposited with the EntryPoint to pay for the UserOperation, and then call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation”
page 12
“function validatePaymasterUserOp
(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost)
external returns (bytes memory context, uint256 validationData);”
Buterin discloses receiving, by an entry point contract in an on-chain environment, the user operation with a verifiable credential for the user (page 3 “EntryPoint - a singleton contract to execute bundles of UserOperations. Bundlers should whitelist the supported EntryPoint.”, pages 3 and 4 “The UserOperation structure… Sender - the Smart Contract Account sending a UserOperation…signature…Data passed into the sender to verify authorization”, also “paymaster data” described as “Data for paymaster (only if paymaster exists)”, also page 6 “The userOpHash is a hash over the userOp (except signature), entryPoint and chainId.”)
Buterin discloses validating, by the entry point contract, the user operation using a validation function in a smart contract wallet (page 6
“interface IAccount {
function validateUserOp
(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
external returns (uint256 validationData);
}
The userOpHash is a hash over the userOp (except signature), entryPoint and chainId. The Smart Contract Account: MUST validate the caller is a trusted EntryPoint… MUST validate that the signature is a valid signature of the userOpHash, and SHOULD return SIG_VALIDATION_FAILED (1) without reverting on signature mismatch. Any other error MUST revert”)
Buterin discloses determining, by the entry point contract, that there is a paymaster to sponsor the transaction (Page 4 “paymaster… Address of paymaster contract, (or empty, if the sender pays for gas by itself””, page 11 “…call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation”)
Buterin discloses determining, by a paymaster contract for the paymaster, that the transaction should be sponsored based on the verifiable credential for the user (page 11 “During the verification loop, in addition to calling validateUserOp, the handleOps execution also must check that the paymaster has enough ETH deposited with the EntryPoint to pay for the UserOperation, and then call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation”
page 12
“function validatePaymasterUserOp
(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost)
external returns (bytes memory context, uint256 validationData);”
Buterin discloses executing, by the entry point contract, the transaction using an arbitrary execution function in the smart contract wallet (page 2 “Achieve the key goal of Account Abstraction: allow users to use Smart Contract Accounts containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs, as required by both status quo Smart Contract Accounts and EIP-7702.”)
Buterin discloses invoking, by the entry point contract, a post-operation that performs post-operation logic (page 12
“function postOp
(PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas)
external;
enum PostOpMode {
opSucceeded, // UserOperation succeeded
opReverted // UserOperation reverted. paymaster still has to pay for gas.
}”)
Buterin discloses receiving the user operation with a verifiable credential (page 3 “EntryPoint - a singleton contract to execute bundles of UserOperations. Bundlers should whitelist the supported EntryPoint.”, pages 3 and 4 “The UserOperation structure… Sender - the Smart Contract Account sending a UserOperation…signature…Data passed into the sender to verify authorization”, also “paymaster data” described as “Data for paymaster (only if paymaster exists)”, also page 6 “The userOpHash is a hash over the userOp (except signature), entryPoint and chainId.”), however Buterin does not explicitly disclose a verifiable presentation comprising a verifiable credential for the user from a user identity wallet, wherein the verifiable presentation is signed by a signer service. DI teaches a verifiable presentation comprising a verifiable credential for the user from a user identity wallet, wherein the verifiable presentation is signed by a signer service (page 6 “On-chain attestations are held in smart contracts on the Ethereum blockchain. The smart contract (acting as a registry) will map an attestation to a corresponding on-chain decentralized identifier (a public key), page 7 “Soulbound tokens (non-transferable NFTs) could be used to collect information unique to a specific wallet. This effectively creates a unique on-chain identity bound to a particular Ethereum address that could include tokens representing achievements (e.g. finishing some specific online course or passing a threshold score in a game) or community participation.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Alt Mempool of Buterin with the Decentralized Identity of DI for the purpose of allowing individuals to manage their identity-related information (page 2).
Neither Buterin nor DI explicitly disclose passing, by the paymaster service, the user operation and the verifiable presentation to a merchant paymaster service. Ozbay teaches passing, by the paymaster service, the user operation and the verifiable presentation to a merchant paymaster service (0055 “A master computer and a master smart contract offers users an alternative way to pay transaction amounts. The recent ERC-4337 upgrade to the Ethereum network allows users to delegate blockchain transaction payments to a third party through the help of a class of smart contracts. Embodiments of the invention allow users to pay blockchain transaction amounts in fiat currency off-chain using a credit card or other payment device. A master service provider that operates a master service provider computer and accepts the off-chain card payment. The corresponding master smart contract covers the transaction amount on-chain on behalf of the user. Thus, the need for a blockchain user to hold any amount of a native blockchain currency (e.g., Ether for Ethereum) to be able to send transactions is obviated”, 0056 “The off-chain payment capability can involve a first smart contract, which can be master smart contract associated with a master computer. The master smart contract can delegate all necessary checks and sourcing of information to an off-chain component such as an off-chain master computer. The on-chain master smart contract can then use the data and approval provided by the off-chain component to authorize and pay for the transaction amount”)
Ozbay teaches verifying, by the merchant paymaster service and using an off-chain verification service, the user operation (0055 “A master computer and a master smart contract offers users an alternative way to pay transaction amounts. The recent ERC-4337 upgrade to the Ethereum network allows users to delegate blockchain transaction payments to a third party through the help of a class of smart contracts. Embodiments of the invention allow users to pay blockchain transaction amounts in fiat currency off-chain using a credit card or other payment device. A master service provider that operates a master service provider computer and accepts the off-chain card payment. The corresponding master smart contract covers the transaction amount on-chain on behalf of the user. Thus, the need for a blockchain user to hold any amount of a native blockchain currency (e.g., Ether for Ethereum) to be able to send transactions is obviated”, 0056 “The off-chain payment capability can involve a first smart contract, which can be master smart contract associated with a master computer. The master smart contract can delegate all necessary checks and sourcing of information to an off-chain component such as an off-chain master computer. The on-chain master smart contract can then use the data and approval provided by the off-chain component to authorize and pay for the transaction amount”)
With regard to claim 15 Ozbay teaches a non-transitory computer readable medium (0097-0098) and a processor (0097)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Alt Mempool of Buterin with the Decentralized Identity of DI with the Off-Chain Interaction of Ozbay for the purpose of allowing users to pay blockchain transaction amounts in fiat currency off-chain using a credit card or other payment device (0055) and for improving the overall processing speed of the blockchain network because fewer transactions need to be processed as off-chain payment card authorization to pay for a transaction can take just a few seconds compared to the 1-10 minutes for an Ethereum transaction (0057).
As per claims 9 and 16
Buterin, while disclosing the limitations of claim 1, does not explicitly disclose signing, by a signer service in the off-chain environment, the user operation. DI teaches signing, by a signer service in the off-chain environment, the user operation (pages 5-6, “Off-chain attestations One concern with storing attestations on-chain is that they might contain information individuals want to keep private. The public nature of the Ethereum blockchain makes it unattractive to store such attestations. The solution is to issue attestations, held by users off-chain in digital wallets, but signed with the issuer's DID stored on-chain. These attestations are encoded as JSON Web Tokens and contain the issuer's digital signature—which allows for easy verification of off-chain claims.↗
Here's an hypothetical scenario to explain off-chain attestations:
A university (the issuer) generates an attestation (a digital academic certificate), signs with its keys, and issues it to Bob (the identity owner).
Bob applies for a job and wants to prove his academic qualifications to an employer, so he shares the attestation from his mobile wallet. The company (the verifier) can then confirm the validity of the attestation by checking the issuer's DID (i.e., its public key on Ethereum).”
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Alt Mempool of Buterin further with the Decentralized Identity of DI for the purpose of allowing individuals to manage their identity-related information (page 2).
As per claims 10 and 17
DI teaches creating, by the signer service, an on-chain verifiable presentation for the verifiable credential, wherein the verifiable credential is received from an identity digital wallet for the user in the off-chain environment (page 6 “On-chain attestations are held in smart contracts on the Ethereum blockchain. The smart contract (acting as a registry) will map an attestation to a corresponding on-chain decentralized identifier (a public key), page 7 “Soulbound tokens (non-transferable NFTs) could be used to collect information unique to a specific wallet. This effectively creates a unique on-chain identity bound to a particular Ethereum address that could include tokens representing achievements (e.g. finishing some specific online course or passing a threshold score in a game) or community participation.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Alt Mempool of Buterin further with the Decentralized Identity of DI for the purpose of allowing individuals to manage their identity-related information (page 2).
As per claims 11 and 18
Buterin discloses wherein the user operation comprises a blockchain address for the user, a unique identifier, initialization code for setting up a new contact for the transaction, and a gas limit for execution and verification of the transaction (page 3 recites “The UserOperation structure” as a header for the section which continues onto page 4 where the user operation structure is defined.
“blockchain address for the user” equates to page 4 “sender, address, The Account making the UserOperation”;
“a unique identifier” equates to page 4 “nonce, uint256, Anti-replay parameter”;
“initialization code for setting up a new contact for the transaction” equates to page 8 “Create the sender Smart Contract Account if it does not yet exist, using the initcode provided in the UserOperation”; and
“a gas limit for execution and verification of the transaction” equates to page 4 “callGaslimit, uint256, The amount of gas to allocate to the main function call” and “verificationGaslimit, uint 256, The amount of gas to allocate to the verification step”)
As per claim 12 and 19
Buterin discloses bundling, by a bundler in the off-chain environment, the user operation with a plurality of user operations (page 13
“Bundler behavior upon receiving a UserOperation[AltContent: rect]
Similar to an Ethereum transaction, the offchain flow of a UserOperation can be described as follows:
Client sends a UserOperation to the bundler through an RPC call eth_sendUserOperation.
Before including the UserOperation in the mempool, the bundler runs the first validation of the newly received UserOperation. If the UserOperation fails validation, the bundler drops it and returns an error in response to eth_sendUserOperation.
Later, once building a bundle, the bundler takes UserOperations from the mempool and runs the second validation of a single UserOperation on each of them. If it succeeds, it is scheduled for inclusion in the next bundle, and dropped otherwise.
Before submitting the new bundle onchain, the bundler performs the third validation of the entire UserOperations bundle. If any of the UserOperations fail validation, the bundler drops them. The bundler should keep track of the peers' reputation. The full design of such a reputation system is outside the scope of this proposal”)
As per claims 13 and 20
Buterin discloses wherein the entry point contract further validates the user operation using an authorization module smart contract (Page 3 “Aggregator - also known as "authorizer contract" - a contract that enables multiple UserOperations to share a single validation. The full design of such contracts is outside the scope of this proposal.”, Page 6 “All aggregator contracts MUST check that all calls to the validateSignatures() function originates from the EntryPoint.”)
As per claim 14
Buterin wherein the paymaster sponsors a gas fee for the transaction (Page 3 “Paymaster - a helper contract that agrees to pay for the transaction, instead of the sender itself.”, Page 11 “We extend the EntryPoint logic to support paymasters that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with [ERC-20] tokens and many other use cases.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang et al. “Account Abstraction, Analysed”, 2023 International Conference on Blockchain, presented December 17-21, 2023 and published January 19, 2024 , pp. 323-331, discloses account abstractions in general, describes security issues and indicates opportunities.
Singh et al. “Account Abstraction via Singleton Entrypoint contract and Verifying Paymaster”, Proceedings of the Second International Conference on Edge Computing and Applications (ICECAA 2023), August 14, 2023, pp. 1598-1605 discloses account abstraction including EIP4337, the benefits of being able to interact with smart contracts using smart contract wallets instead of externally owned accounts, and the allowing of third-party paymaster accounts with the wallet that can pay gas fees on behalf of the user and allow use of off-chain payment methods such as credit cards or PayPal.
Reed et al. “Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes”, https://www.w3.org/2019/08/did-20190828/, August 10, 2019, 56 pages, is the document produced by the W3C community describing the nature of the decentralized identifiers, the documents produced (DID documents) and the operations involved in producing and using DIDs (which the document describes as being part of the Verifiable Credentials ecosystem)
Reed et al. “Decentralized Identifiers (DIDs) v1.0, Core Architecture, data model and representations, W3C Working Draft 13 July 2020”, July 13, 2020, 113 pages is another document produced by the W3C community regarding Decentralized Identifiers and describes terminology used in the Verifiable Credentials ecosystem and also provides guidance on how to use DIDs.
Microsoft Security “Decentralized identity and verifiable credentials: Ownership, control, and trust for a digital world”, June 16, 2023, 11 pages provides an overview of decentralized identities and provides a sample scenario using verifiable credentials on page 9.
Lobban et al. “Digital identity – Assessing Web3’s identity building blocks”, 9 pages, date uncertain, describes the use of identity attributes including proof of humanity (PoH), Soulbound Tokens (SBT) and verifiable credentials (VCs). Shown as The document is published by the assignee “Kinexys by J.P. Morgan” and lists one of the named inventors in the instant application (George Kassis). The document shows a copyright of 2023 and document properties list a creation date of April 26, 2023 but Examiner is unable to find a clear indication as to when the document was actually available to the public.
Ozbay et al. “Paying Blockchain Gas Fees with Card: Bring the ease and convenience of traditional payments to the world of crypto”, August 10, 2023, 15 pages discloses the use of an off-chain paymaster. Figure 6 discloses the code snippet for use in verifying a paymaster digital signature and Figure 5 discloses the payment of gas fees with a Visa Card via Paymaster.
Beams et al. “Auto Payments for Self-Custodial Wallets”, December 19, 2022, 12 pages discloses a means for using account abstraction for making auto payments on the Ethereum blockchain.
Bedawala et al. “What is Ethereum’s Staking Model?: Understanding the role of cryptoeconomics”, May 4, 2023, 19 pages discloses Ethereum’s monetary policy, how validators in the network are incentivized for optimal behavior and punished for malicious behavior and explores Ethereum’s staking model.
Ozbay et al., WIPO Publication WO 2025/006875 A1, filed June 28, 2024 and claiming priority to Indian application 202341043888, June 30, 2023 hereinafter referred to as Ozbay, discloses off-chain interaction for on-chain processing and discloses similar subject matter to the Ozbay reference cited in this Office Action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 6:00 to 9:45 and 10:30 to 2:45.
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 Patel can be reached at (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.
/JAMES D NIGH/Senior Examiner, Art Unit 3699