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 .
Claim Status
As of the Office Action dated January 28, 2026 claims 1-20 were pending and claims 1-20 stood rejected. Claims 1, 8 and 15 have been amended. No claims have been added or cancelled. Claims 1-20 are therefore currently pending and are presented for examination on the merits.
Response to Arguments
Applicant’s argument with regard to the objection to claims 17, 19 and 20 has been fully considered and is persuasive. A problem arose with a tool used by Examiners to convert image into text and the tool apparently removed the references to the claims upon which claims 17, 19 and 20 depended upon and inserted different text into the claim. For example in the converted text version of claim 17 the preamble of claim 17 reads “The non-transitory computer readable storage medium of The non-transitory computer readable storage medium…” and removed the reference to claim 16. Examiner cannot explain why this happened but has asked USPTO IT support to look into the matter.
Applicant’s argument with regard to the 35 U.S.C. § 101 rejection of claims 1-20 has been fully considered and is persuasive. Examiner deems that while the claims recite an abstract idea in the form of sponsorship that overall the claims are not directed towards an abstract idea and therefore satisfy Prong Two of Step 2A in forming a practical application of the abstract idea. Therefore the rejection will be withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 112 (a) rejection of claims 1-20 has been fully considered but is not persuasive. With regard to the limitation “…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” it is noted that the “intention” and how it is created is not expressed in any form that could be operated upon by a programmed computer as an intention is a human thought that would precede the performing of an action but cannot be viewed as an action upon which a programmed computer can operate upon. From the standpoint of a programmed computer some form of actionable input is required that instantiates the user intention into something that is in a form that a programmed computer may operate upon such as a keyboard input, a voice command recognized through voice recognition interface, a mouse click, etc. However the written disclosure recites no actionable operation upon which a programmed computer can recognize an intention such that the claim can be viewed as operable that would address the language of the claim that requires creation of a user operation that is based on an intention received from a user? It is this particular language “based on an intention received from a user” that is the basis for Examiner’s rejection as there is no means recited in the claim or the written disclosure for receiving an intention from a user. Therefore this rejection will be maintained.
Applicant’s argument to the 35 U.S.C. § 112 (a) rejection of claims 1-20 has been fully considered but is not persuasive. With regard to the limitation “…executing, by the entry point contract, the transaction using an arbitrary execution function in the smart contract wallet, wherein the arbitrary execution function comprises a mint function” it is noted that the recitation from paragraph 0084 “In step 245, if the transaction should be paid for, in step 250, the entry point contract may execute the user operation by calling the arbitrary execution function on the smart contract wallet”. Paragraph 0085 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.” Initially Examiner would comment that the nexus between the step 250 recited in paragraph 0084 and the operations described in paragraph 0085 is not readily apparent but even if this point is conceded the use of the word “arbitrary” in paragraph 0084 would lead to a conclusion that “any” computer operation would result in the outcomes described in paragraph 0085 which would not satisfy the require for the level of detail needed to satisfy the written description requirement for a computer implemented invention required by MPEP § 2161.01. Furthermore the particular result that is being claimed “…wherein the arbitrary execution function comprises a mint function” is one that is described in paragraph 0085 as being preconditioned on the language “understands the users intent (e.g., ‘Mint a XYZ NFT’ from the callData field)”. The written disclosure does not describe any operation that can be performed by a programmed computer that “understands the users intent” and amounts to nothing more than claiming a result without any description as to how such a result would be obtained. Furthermore the written disclosure does not describe how a function that is “arbitrary” is capable of any producing any specific result as logic would dictate that an arbitrary function would produce a result that is also arbitrary in nature. Therefore as the claim is only supported in the written disclosure by subject matter that is described in a way that only recites the obtained results without describing how the results are obtained the limitation is rejected under 35 U.S.C. § 112(a).
Applicant’s argument with regard to the limitation “invoking, by the entry point contract, a post-operation that performs post-operation logic” has been fully considered and is persuasive. Examiner initially thought that the “logic” was referring to structure that was not described in the written disclosure. However as the claim is claiming the performing of logic it is clear that the “logic” involves operations. The Cambridge Dictionary contains a definition of logic that appears to be what Applicant is describing: “actions that a computer performs, such as comparing and matching, that involve simple yes or no choices, rather than more complicated mathematics”. Under this definition operations such as logging, notifications or other cleanup operations would appear to fall within the particular definition supplied by the Cambridge Dictionary and would not present an issue under section 112. Therefore the present rejection under section 112 will be withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 102 (a)(1) rejection of claims 1 and 4-7 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) has been fully considered but is moot in view of the new grounds of rejection. However Examiner wishes to comment on the argument that relates to the unamended portion of the claims as Applicant has made multiple errors in the proffered arguments. Applicant argued:
"Claim 1 (emphasis added). Buterin does not disclose "determining, by the entry point contract, that there is a paymaster to sponsor the transaction." Instead, the Office Action cites a table describing the "UserOperation" structure. This includes a field entitled "Paymaster". According to the table, this field is an address, and identifies the "[a]ddress of paymaster contract, (or empty, if the sender pays for gas by itself)." There is, however, no disclosure that the entry point contract actually determines that there is a paymaster to sponsor the transaction. Thus, Buterin does not disclose this element. "
The actual rejection recited the following:
(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”)
The argument did not address the portion of Examiner's rejection with regard to the recitation from page 11 "...call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation". Examiner believes that the recitation from page 11 of the Buterin reference "...call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation" is sufficient to read on the limitation of determining, by the entry point contract, that there is a paymaster to sponsor the transaction" as the recitation is part of the section on page 11 that Examiner is reproducing below:
Extension: paymasters
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. When the paymasterAndData field in the UserOperation is not empty, the EntryPoint implements a different flow for that UserOperation:
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. Note that in this case, the validateUserOp is called with a missingAccountFunds of 0 to reflect that the account's deposit is not used for payment for this UserOperation.
Therefore this argument is not persuasive. The operation is clearly part of the EntryPoint logic (contract) and is described as part of a verification loop that checks that the paymaster has enough ETH and then calls the validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation by the EntryPoint logic and is sufficient to read on the claimed limitation.
Applicant then argues "Similarly, there is no disclosure of 'determining, by a paymaster contract for the paymaster, that the transaction should be sponsored based on the verifiable credential for the user. First, Buterin does not disclose a paymaster contract; regardless, there is no disclosure of any consideration of a verifiable credential for the user in making this determination. Instead, the cited portion of Buterin discloses:
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. Note that in this case, the validateUserOp is called with missingAccountFunds of 0 to reflect that the account's
deposit is not used for payment for this UserOperation.
The paymaster interface is as follows:
function validatePaymasterUserOp
(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256
maxCost)
external returns (bytes memory context, uint256 validationData);
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.
}
The EntryPoint must implement the following API to let entities like paymasters have a stake, and thus have more flexibility in their storage access.
Buterin, pages 11-12 (emphasis added). Notably, the paymaster is evaluated based on whether the paymaster is willing to pay for the UserOperation, not based on the
verifiable credential for the user. Thus, Buterin does not disclose this element."
Examiner would respectfully note that the paymaster operation is a smart contract (see definition of a paymaster at page 3 "a helper contract that agrees to pay for the transaction, instead of the sender itself" and that in Buterin's specification on pages 2 and 3 that a UserOperation is defined as "a structure that describes a transaction to be sent on behalf of a user", an EntryPoint is defined as "a singleton contract to execute bundles of UserOperations" (also on page 3) and a Sender is defined as "the Smart Contract Account sending a UserOperation" (also on page 3). Each section of Buterin builds upon the previous sections where the UserOperation is used as the basis for the Smart Contract Account Interface on pages 6 and 7 and the Required EntryPoint contract functionality on pages 8 and 9 and concluding with the Extension: paymasters section on pages 11, 12 and 13. The UserOperation structure is defined at the end of Page 3 continuing onto page 4 and is shown as including a signature defined as "Data passed into the sender to verify authorization". The UserOperation structure also includes calldata which is defined as "The data to pass to the sender during the main execution call". Notably the Required EntryPoint contract functionality is described as requiring the “Call validateUserOp on the sender contract, passing in the UserOperation, its hash and the required fee. The Smart Contract Account MUST verify the UserOperation's signature parameter, and pay the fee if the sender considers the UserOperation valid. If any validateUserOp call fails, handleOps must skip execution of at least that UserOperation, and may revert entirely.” Examiner would point out that the paymaster is an extension of the Required EntryPoint contract functionality “We extend the EntryPoint logic to support paymasters that can sponsor transactions for other users.” Therefore the paymaster is also validating the credential (hash) by calling the validateUserOp function. Examiner would also point out that the paymaster extension of the Required EntryPoint contract is inclusive of the operation recited in the final sentence of the Required EntryPoint contract section which states that “Before accepting a UserOperation, bundlers SHOULD use an RPC method to locally call the handleOps function on the EntryPoint, to verify that the signature is correct and the UserOperation actually pays fees; see the Simulation section below for details. A node/bundler MUST reject a UserOperation that fails the validation, meaning not adding it to the local mempool and not propagating it to other peers.” Therefore the paymaster contract of Buterin is bound by the Required EntryPoint contract section language and as such would verify both the hash and the signature and that both the hash and the signature constitute a “verifiable credential” recited in the claims. Therefore this portion of Applicant’s argument is clearly deficient as the argument omits consideration of all of the preceding portions of Buterin that set the context for a proper understanding of how the paymaster contract operates. Applicant has merely assembled a litany of baseless conclusory arguments that totally ignores the definitions and context of the entirety of the Buterin reference that relies on unsupportable assertions. Therefore none of these arguments can be viewed as persuasive.
Applicant’s final argument with regard to the “executing, by the entry point contract, the transaction using an arbitrary execution function in the smart contract wallet” has been fully considered but is moot in view of the amended language. Therefore this is the only language that is requiring a newly added reference.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 2 and 3 as being unpatentable over Buterin in further view of Decentralized identity, retrieved from https://ethereum.org/en/decentralized-identity/, June 29, 2023, 14 pages, (hereinafter referred to as DI) has been fully considered but is moot in view of the new grounds of rejection.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 8-20 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) has been fully considered and is moot in view of the new grounds of rejection. However Applicant repeats the same argument with regard to claims 8 and 15 that was shown to be factually inaccurate and riddled with numerous errors that were explained with regard to the argument presented in claim 1. Therefore the argument is only persuasive as it applies to the added language presented in the amendments to claims 8 and 15.
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. It is noted that the “intention” and how it is created is not expressed in any form that could be operated upon by a programmed computer as an intention is a human thought that would precede the performing of an action but cannot be viewed as an action upon which a programmed computer can operate upon. From the standpoint of a programmed computer some form of actionable input is required that instantiates the user intention into something that is in a form that a programmed computer may operate upon such as a keyboard input, a voice command recognized through voice recognition interface, a mouse click, etc. However the written disclosure recites no actionable operation upon which a programmed computer can recognize an intention such that the claim can be viewed as operable that would address the language of the claim that requires creation of a user operation that is based on an intention received from a user? It is this particular language “based on an intention received from a user” that is the basis for Examiner’s rejection as there is no means recited in the claim or the written disclosure for receiving an intention from a user. 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 based on an intention. 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, wherein the arbitrary execution function comprises a mint function”. 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, wherein the arbitrary execution function comprises a mint function. The particular result that is being claimed “…wherein the arbitrary execution function comprises a mint function” is one that is described in paragraph 0085 as being preconditioned on the language “understands the users intent (e.g., ‘Mint a XYZ NFT’ from the callData field)”. The written disclosure does not describe any operation that can be performed by a programmed computer that “understands the users intent” and amounts to nothing more than claiming a result without any description as to how such a result would be obtained. Furthermore the written disclosure does not describe how a function that is “arbitrary” is capable of any producing any specific result as logic would dictate that an arbitrary function would produce a result that is also arbitrary in nature. 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 Rejections - 35 USC § 112
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “…executing, by the entry point contract, the transaction using an arbitrary function, wherein the arbitrary execution function comprises a mint function. The written disclosure does not describe how a function that is “arbitrary” is capable of any producing any specific result as logic would dictate that an arbitrary function would produce a result that is also arbitrary in nature. Therefore it is unclear as to how an arbitrary function can result in any specific result if the function itself is truly arbitrary in nature. For purposes of claim interpretation the word “arbitrary” will be given negligible patentable weight.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 4-7 are rejected under 35 U.S.C. 103 as being unpatentable over 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) in view of Zhou “Token Minting and Burning” (Also referred to as ERC-5679 or EIP-5679, ERCs_ERCS_erc-5679, September 17, 2022, 3 pages, hereinafter referred to as Zhou.
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”) (see also the definitions on page 3 with regard to the paymaster being a contract, the section on page 8 with regard to Required EntryPoint contract functionality for the requirements of an EntryPoint contract and the complete Extensions: paymasters in pages 11-13 in order to get the complete context of the recitations cited by Examiner).
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.
}”)
(see also the definitions on page 3 with regard to the paymaster being a contract, the section on page 8 with regard to Required EntryPoint contract functionality for the requirements of an EntryPoint contract and the complete Extensions: paymasters in pages 11-13 in order to get the complete context of the recitations cited by Examiner).
Buterin does not explicitly disclose wherein the arbitrary execution function comprises a mint function. Zhou teaches wherein the arbitrary execution function comprises a mint function (Abstract “This EIP introduces a consistent way to extend token standards for minting and burning”, Specification with regard to contracts complying with EIP-20, EIP-721 and EIP-1155 tokens and code for minting tokens under each standard).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Account Abstraction of Buterin with the token minting and burning of Zhou for the purpose of establishing a consistent way to mint and burn a token to complete the basic lifecycle (Zhou in Motivation section).
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.”)
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Buterin in view of Zhou 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 and Zhou, while disclosing the limitations of claim 1, do 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 with the token minting and burning of Zhou 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 with the token minting and burning of Zhou 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 Zhou and 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.
}”)
(see also the definitions on page 3 with regard to the paymaster being a contract, the section on page 8 with regard to Required EntryPoint contract functionality for the requirements of an EntryPoint contract and the complete Extensions: paymasters in pages 11-13 in order to get the complete context of the recitations cited by Examiner).
Buterin does not explicitly disclose wherein the arbitrary execution function comprises a mint function. Zhou teaches wherein the arbitrary execution function comprises a mint function (Abstract “This EIP introduces a consistent way to extend token standards for minting and burning”, Specification with regard to contracts complying with EIP-20, EIP-721 and EIP-1155 tokens and code for minting tokens under each standard).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the Account Abstraction of Buterin with the token minting and burning of Zhou for the purpose of establishing a consistent way to mint and burn a token to complete the basic lifecycle (Zhou in Motivation section).
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 neither Buterin nor Zhou 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 token minting and burning of Zhou 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 token minting and burning of Zhou 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 with the token minting and burning of Zhou 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 with the token minting and burning of Zhou 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.”).
Pertinent Prior Art Not Cited
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.
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 JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 5 AM to 2 PM Monday through Thursday.
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
Prosecution Insights