DETAILED ACTION
This office action is in response to applicant’s submission filed on March 5, 2026. Claims 1-18 are pending and rejected.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 20, 2026 has been entered.
Response to Amendment
This communication is in response to the amendment filed on March 5, 2026. The Examiner has acknowledged the amended claims 1, 4, 7, 10, 12, 13 and 16. Claims 1-18 are pending and are rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed March 5, 2026 have been fully considered, but are moot.
Applicant’s arguments with respect to the amendments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Until the Terminal Disclaimer is filed, the Double Patenting rejection stands. See also Double Patenting rejection below.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 4, 7, 10, 13, and 16 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 4, 6, 8, 9, 11, 13, 15, 16, and 20 of U.S. Patent No. 18/535,552. Although the claims at issue are not identical, they are not patentably distinct from each other.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered
by the patent since the patent and the application are claiming the common subject matter. With respect to the claims 1, 4, 7, 10, 13, and 16 of the instant application, please refer to the following table, which illustrates the obvious and anticipatory relationship of the claim limitations at issue:
Instant application
US Pat. Application No. 18/535,552
1. A system comprising: a memory storing executable program code; and at least one processing unit to execute the program code to cause the system to: receive interactions from an administrator of a tenant at a Web server to create a Web3 asset on a Web3 database, the Web3 asset associated with metadata of one or more attributes, at least one of the one or more attributes describing a benefit comprising a physical product or access to a real-world event; a call specifying a transaction to create the Web3 asset on the Web3 database; determine an identifier associated with the tenant; determine a custodial tenant wallet identifier stored in association with the identifier associated with the tenant, the custodial tenant wallet identifier identifying a cryptographic key-pair; transmit the call and the custodial tenant wallet identifier to a Web3 interface to encrypt the transaction with a private key of the cryptographic keypair and transmit the encrypted operation to the Web3 database; receive an instruction at the Web server to assign the Web3 asset to a user; in response to the instruction, store a user identifier of the user in association with an identifier of the Web3 asset and the metadata; receive, at the Web server, a user request to claim the benefit; in response to the user request, determine at the Web server that the user is associated with the Web3 asset based on the stored user identifier; and in response to the determination that the user is associated with Web3 asset, provide the benefit to the user without accessing the Web3 database.
1. A system comprising: a memory storing executable program code; and at least one processing unit to execute the program code to cause the system to: receive a request at a Web server to create a Web3 asset on a Web3 database, the Web3 asset associated with metadata and data; and in response to the received request: store an identifier of the Web3 asset in association with the metadata and a second identifier; store the data associated with the Web3 asset in a blob store; generate an encrypted operation to create the Web3 asset on the Web3 database, the encrypted operation encrypted by a private key associated with the second identifier; transmit the encrypted operation to the Web3 database; and transmit the data and the metadata to a Web3 decentralized storage system.
2. The system according to Claim 1, the at least one processing unit to execute the program code to cause the system to: receive a second request from a user at the Web server to claim the Web3 asset; and in response to the second request, store an identifier of the user in association with the identifier of the Web3 asset, the metadata and the second identifier.
6. The system according to Claim 1, the at least one processing unit to execute the program code to cause the system to: receive an instruction at the Web server to assign the Web3 asset to a user; and in response to the instruction, store an identifier of the user in association with the identifier of the Web3 asset, the metadata and the second identifier.
4. The system according to Claim 1, wherein the user identifier of the user is stored in association with an identifier of the Web3 asset, the metadata and the custodial tenant wallet identifier
2. The system according to Claim 1, the at least one processing unit to execute the program code to cause the system to: receive a second request from a user at the Web server to claim the Web3 asset; and in response to the second request, store an identifier of the user in association with the identifier of the Web3 asset, the metadata and the second identifier.
4. The system according to Claim 2, the at least one processing unit to execute the program code to cause the system to: receive an instruction from the user at the Web server to transfer the Web3 asset to a third identifier; and in response to the instruction: store the third identifier in association with the identifier of the user, the identifier of the Web3 asset and the metadata; generate a second encrypted operation to transfer the Web3 asset to the third identifier, the second encrypted operation encrypted by the private key associated with the second identifier; and transmit the second encrypted operation to the Web3 database.
7. A method comprising: receiving interactions from an administrator of a tenant a call specifying a transaction determining an identifier associated with the tenant; determining a custodial tenant wallet identifier stored in association with the identifier associated with the tenant, the custodial tenant wallet identifier identifying a cryptographic key-pair; transmitting the call and the custodial tenant wallet identifier to a Web3 interface to encrypt the transaction with a private key of the cryptographic keypair and transmit the encrypted operation to the Web3 database; receiving an instruction at the Web server to assign the Web3 asset to a user; in response to the instruction, storing a user identifier of the user in association with an identifier of the Web3 asset and the metadata; receiving, at the Web server, a user request to claim the benefit; in response to the user request, determining at the Web server that the user is associated with the Web3 asset based on the stored user identifier; and in response to the determination that the user is associated with the Web3 asset, providing the benefit to the user without accessing the Web3 database.
8. A method comprising: receiving a request at a Web server to create a Web3 asset on a Web3 database, the request identifying metadata and data associated with the Web3 asset; and in response to the received request: storing an identifier of the Web3 asset in a database table in association with the metadata and an identifier of a tenant; storing the data associated with the Web3 asset in a blob store; generating an encrypted operation to create the Web3 asset on the Web3 database, the encrypted operation encrypted by a private key associated with the identifier of the tenant; and transmitting the encrypted operation to the Web3 database.
9. The method according to Claim 8, further comprising: receiving a second request from a user at the Web server to claim the Web3 asset; and in response to the second request, storing an identifier of the user in association with the stored identifier of the Web3 asset, metadata and the identifier of the tenant.
13. The method according to Claim 8, further comprising: receiving an instruction at the Web server to assign the Web3 asset to a user; and in response to the instruction, storing an identifier of the user in the database table in association with the identifier of the Web3 asset, the metadata and the tenant identifier.
10. The method according to Claim 7, wherein the user identifier of the user is stored in association with an identifier of the Web3 asset, the metadata and the custodial tenant wallet identifier
9. The method according to Claim 8, further comprising: receiving a second request from a user at the Web server to claim the Web3 asset; and in response to the second request, storing an identifier of the user in association with the stored identifier of the Web3 asset, metadata and the identifier of the tenant.
11. The method according to Claim 9, further comprising: receiving an instruction from the user at the Web server to transfer the Web3 asset to a second identifier; and in response to the instruction: storing the second identifier in the database table in association with the identifier of the user, the identifier of the Web3 asset and the metadata; generating a second encrypted operation to transfer the Web3 asset to the second identifier, the second encrypted operation encrypted by the private key associated with the identifier of the tenant; and transmitting the second encrypted operation to the Web3 database.
13. A non-transitory medium storing program code executable by at least one processing unit of a computing system to cause the computing system to: receive interactions from an administrator of a tenant at a Web server to create a Web3 asset on a Web3 database, the Web3 asset associated with metadata of one or more attributes, at least one of the one or more attributes describing a benefit comprising a physical product or access to a real-world event; a call specifying a transaction to create the Web3 asset on the Web3 database; determine an identifier associated with the tenant; determine a custodial tenant wallet identifier stored in association with the identifier associated with the tenant, the custodial tenant wallet identifier identifying a cryptographic keypair; transmit the call and the custodial tenant wallet identifier to a Web3 interface to encrypt the transaction with a private key of the cryptographic keypair and transmit the encrypted operation to the Web3 database; receive an instruction at the Web server to assign the Web3 asset to a user; in response to the instruction, store a user identifier of the user in association with an identifier of the Web3 asset and the metadata; receive, at the Web server, a user request to claim the benefit; in response to the user request, determine at the Web server that the user is associated with the Web3 asset based on the stored user identifier; and in response to the determination that the user is associated with Web3 asset, provide the benefit to the user without accessing the Web3 database.
15. A non-transitory medium storing program code executable by at least one processing unit of a computing system to cause the computing system to: receive a request at a Web server to create a Web3 asset on a Web3 database, the request identifying metadata and data associated with the Web3 asset; and in response to the received request: store an identifier of the Web3 asset in a database table in association with the metadata and an identifier of a tenant; store the data associated with the Web3 asset in a blob store; generate an encrypted operation to create the Web3 asset on the Web3 database, the encrypted operation encrypted by a private key associated with the identifier of the tenant; and transmit the encrypted operation to the Web3 database.
16. The medium according to Claim 15, the program code executable by at least one processing unit of a computing system to cause the computing system to: receive a second request from a user at the Web server to claim the Web3 asset; and in response to the second request, store an identifier of the user in association with the stored identifier of the Web3 asset, metadata and the identifier of the tenant.
20. The medium according to Claim 15, the program code executable by at least one processing unit of a computing system to cause the computing system to: receive an instruction at the Web server to assign the Web3 asset to a user; in response to the instruction, store an identifier of the user in the database table in association with the identifier of the Web3 asset, the metadata and the tenant identifier; transmit from the Web server an e-mail to the user including a link associated with the Web3 asset; receive an HTTP request from the user including the link; and in response to the HTTP request: retrieve the stored metadata of the Web3 asset based on the link; retrieve the data of the Web3 asset from the blob store; and present the data and the metadata of the Web3 asset to the user.
16. The medium according to Claim 13, wherein the user identifier of the user is stored in association with an identifier of the Web3 asset, the metadata and the custodial tenant wallet identifier
16. The medium according to Claim 15, the program code executable by at least one processing unit of a computing system to cause the computing system to: receive a second request from a user at the Web server to claim the Web3 asset; and in response to the second request, store an identifier of the user in association with the stored identifier of the Web3 asset, metadata and the identifier of the tenant.
19. The medium according to Claim 15, the program code executable by at least one processing unit of a computing system to cause the computing system to: receive an instruction from a user at the Web server to transfer the Web3 asset to a second wallet identifier; and in response to the instruction: store the second identifier in the database table in association with the identifier of the Web3 asset and the metadata; generate a second encrypted operation to transfer the Web3 asset to the second identifier, the second encrypted operation encrypted by the private key associated with the identifier of the tenant; and transmit the second encrypted operation to the Web3 database.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0358784 A1 to Khaund in view of US 2023/0396445 A1 to Padmanabhan et al. (hereinafter, “Padmanabhan”).
Regarding claim 1, Khaund discloses: A system comprising:
a memory storing executable program code (“software codes can be stored in a memory” [0265]); and
at least one processing unit to execute the program code to cause the system to (“The system may include one or more data processors; and a non-transitory computer-readable storage medium containing instructions which, when executed on the one or more data processors, cause the one or more data processors to perform operations including the method(s) described above and herein” [0008]):
receive interactions from an administrator of a tenant at a Web server to create a Web3 asset on a Web3 database (“Each of primary access assignment system 214 and secondary access assignment system 216 can include a web server 218 that processes and responds to HTTP requests. Web server 218 can retrieve and deliver web-page data to a user device 210 that, for example, identify a resource, identify a characteristic of each of one or more access rights for the resource, include an invitation to request assignment of an access right, facilitate establishment or updating of a profile, and/or identify characteristics of one or more assigned access rights. Web server 218 can be configured to support server-side scripting and/or receive data from user devices 210, such as data from forms or file uploads” [0053]; “Primary load management system 1140 may be a Blockchain-based system that uses Blockchain nodes to manage the generation, ownership, and transfer of secure digital assets (e.g., smart contracts) that represent electronic access rights to resources” [0217] [Examiner notes that this text shows a system that has a web server that receives a request from a user device and the system processed that request. The blockchain-based system handles the creation of a web3 asset. This creation is then stored or handled via blockchain nodes (web3 database). Examiner also wants to note that the web server in the text is clearly a web2, and it is acting as the gateway between the user and the web3 system]),
the Web3 asset associated with metadata of one or more attributes (“FIG. 14 is a block diagram illustrating network environment 1400 that enables the generation of smart contracts to serve as access rights for resources. While FIGS. 12-13 describe the reordering of smart contracts based on the metadata associated with the smart contracts, FIG. 14 describes how smart contracts are generated to represent secure access rights to resources. In some implementations, network environment 1400 may include access right generation system 1170, which communicates with Blockchain system 1150 to generate a smart contract with one or more attributes, functions, and/or policies that mimic or represent a digital access right to a resource. The generated smart contract can then be stored on the Blockchain system 1150” [0242] [Examiner notes that this text directly describes the creation of a smart contract. The attributes, functions, and policies serve the same purpose as metadata as stated – they define the behavior and nature of the asset. It also mentions storage on the blockchain, which solidifies it as a web3 asset]),
at least one of the one or more attributes describing a benefit comprising a physical product or access to a real-world event (“Verification of an access-enabling code can indicate that access to a resource is to be granted. Conversely, determining that a code is not verified can indicate that access to a resource is to be limited or prevented. In some instances, a presentation is generated (e.g., and presented) that indicates whether access is to be granted and/or a result of a verification analysis. In some instances, access granting and/or limiting is automatically affected. For example, upon a code verification, a user device and/or user may be automatically permitted to access a particular resource. Accessing a resource may include, for example, using a computational resource, possessing an item, receiving a service, entering a geographical area, and/or attending an event (e.g., generally or at a particular location)” [0136] [Examiner notes that possessing an item aligns with a physical product and attending an event aligns with access to a real-world event]);
a call specifying a transaction to create the Web3 asset on the Web3 database; and transmit the encrypted operation to the Web3 database (“Recently, however, Blockchain technology has gained popularity for the enhanced security the technology provides to various applications. Blockchain provides a decentralized approach to verifying the authenticity of information, including data representing transactions. Certain embodiments of the present disclosure relate to systems and methods that convert access rights into secure digital assets protected by cryptographic public/private keys. As only a non-limiting example, a secure digital asset may be a smart contract. The converted access rights (i.e., the secure digital assets) can then be published on a Blockchain (e.g., posted to a public ledger on a Blockchain, such as an Ethereum Blockchain). Advantageously, creating a public ledger enables the primary load management system to track the ownership of an access right throughout the lifecycle of the access right. Further, by structuring access rights as secure digital assets, such as smart contracts, the systems and methods can serve as a self-policing escrow, while simultaneously allowing the primary load management system greater control over the access right after the access right has been initially sold to a user. Certain embodiments of the present disclosure enable the primary load management system to manage and control the reassignment transactions of access rights, regardless of which platform facilitates the reassignment of the access right” [0007] [Examiner notes that this text describes the conversion of access rights into cryptographically secured digital assets (i.e. smart contracts) that are then published to a blockchain – which directly reflects the idea of generating a secure, encrypted operation to create a Web3 asset on a Web3 database. It then also transmits the encrypted operation to the Web3 database by publishing it to a decentralized blockchain]);
receive an instruction at the Web server to assign the Web3 asset to a user (“The assignment of access rights to resources is often managed by a centralized server hosted by a primary load management system. Each access right corresponds to a unique access code that grants access to the resource during a defined time period. The unique access codes are typically stored at the centralized server. When the primary load management system assigns an access right to a user, the centralized server can store features characterizing the user” [0006]);
in response to the instruction, store a user identifier of the user in association with an identifier of the Web3 asset and the metadata (“In some implementations, once the secure digital assets for a specific resource are created, the secure digital assets can be made available for assignment by the access right issuer as electronic access rights to the resource. The access right issuer may provide a digital queue for storing the electronic access right requests received from the users. Each access right request may be associated with metadata that describes certain information about the access right or access right requestor. The access right issuer can provide a triage queueing system that processes the metadata to reorder the digital queue, so that the most urgent (or important) access right requests are processed by the Blockchain first before less urgent access right requests. As will be described in greater detail herein, the triage queuing system can, for example, filter, reorder, delegate, and/or batch access right requests to optimize throughput and reduce processing latency of access right processing using the Blockchain” [0030]; “A management server 222 can interact with web server 218 to provide indications as to which access rights' are available for assignment, characteristics of access rights and/or what data is needed to assign an access right. When requisite information is received (e.g., about a user and/or user device, identifying a final request for one or more access rights, including payment information, and so on), management server 222 can coordinate an assignment of the one or more access rights. The coordination can include updating an access-right data store to change a status of the one or more access rights (e.g., to assigned); to associate each of the one or more access rights with a user and/or user device; to generate or identify one or more access-enabling codes for the one or more access rights; and/or to facilitate transmission reflecting the assignment (e.g., and including the one or more access-enabling codes) to a user device” [0055] [Examiner notes both of these texts shows that metadata is being generated, associated with access right requests. This implies that this metadata is linked to specific users, since it is used to prioritize their requests. It also supports that a user ID is stored in association with a Web3 asset and explicitly includes a system receiving instructions and storing data as part of that response]);
receive, at the Web server, a user request to claim the benefit; in response to the user request, determine at the Web server that the user is associated with the Web3 asset based on the stored user identifier; and in response to the determination that the user is associated with Web3 asset, provide the benefit to the user without accessing the Web3 database (“Resource status data store 428 can store status data reflecting which resources are available (or unavailable), thereby indicating which resources have one or more open assignments. In some instances, the status data can include schedule information about when a resource is available. Status data can include information identifying an entity who requested, automatically and/or tentatively assigned or was assigned a resource. In some instances, status information can indicate that a resource is being held or automatically and/or tentatively assigned and may identify an entity associated with the hold and/or a time at which the hold or reservation will be enabled to be queried. Access-enabling code data store 430 can store access-enabling code data that includes one or more codes and/or other information that can be used to indicate that an entity is authorized to use, have or receive a resource. An access-enabling code can include, for example, a numeric string, an alphanumeric string, a text string, a 1-dimensional code, a 2-dimensional code, a barcode, a quick response (QR) code, an image, a static code and/or a temporally dynamic code. An access-enabling code can be, for example, unique across all instances, resource types and/or entities. For example, access-enabling codes provided in association for access rights to a particular resource can be unique relative to each other. In some instances, at least part of a code identifies a resource or specification of a resource” [0110-0111]; “Verification of an access-enabling code can indicate that access to a resource is to be granted. Conversely, determining that a code is not verified can indicate that access to a resource is to be limited or prevented. In some instances, a presentation is generated (e.g., and presented) that indicates whether access is to be granted and/or a result of a verification analysis. In some instances, access granting and/or limiting is automatically affected. For example, upon a code verification, a user device and/or user may be automatically permitted to access a particular resource. Accessing a resource may include, for example, using a computational resource, possessing an item, receiving a service, entering a geographical area, and/or attending an event (e.g., generally or at a particular location)” [0136] [Examiner notes that these texts describe stored information about which resources are available, who has been assigned a resource, and what access-enabling codes are used to authorize use of those resources. The user request to claim a benefit is reflected here in the form of a code or identifier that is then used to initiate or validate access to a resource. It provides background and data structure support for the user request that will later be received by the web server. It gives the foundation for what the benefit is and how it will be authenticated. It also directly addressed what happens when a user tries to claim a benefit (code is submitted via a user request, code is verified, and if valid, access is granted. This supports the step of receiving the request because it discusses what the system does in response to that user-initiated action. After receiving the request, the server uses stored data to confirm that the user is linked to that resource or asset (Web3 asset). The benefit is provided to the user because the text shows a response to determination (once the code is verified, confirming the link) and the provision of the benefit (access is automatically granted). Examiner also notes that there is off-chain access control when providing the benefits even though there is a blockchain existing somewhere in the system. Access is granted to the person on verification of an access-enabling code, without requiring access to or verification via a blockchain]).
Khaund does not disclose: determine an identifier associated with the tenant; determine a custodial tenant wallet identifier stored in association with the identifier associated with the tenant, the custodial tenant wallet identifier identifying a cryptographic key-pair; transmit the call and the custodial tenant wallet identifier to a Web3 interface to encrypt the transaction with a private key of the cryptographic keypair and
However, Padmanabhan discloses: determine an identifier associated with the tenant (“Such an entry may also include one or more identifiers associated with an org 316, a user 318, and/or an account 320. An org 316 may represent a database system account associated with an entity to which the database system provides on-demand computing services” [0061]);
determine a custodial tenant wallet identifier stored in association with the identifier associated with the tenant (“According to various embodiments, the wallet table 306 may include entries that uniquely identify wallets in a public trust ledger. For example, an entry in the wallet table 360 may include a wallet ID associated with the database system and/or an account ID associated with an account in a public trust ledger such as a blockchain. Such an entry may also include one or more identifiers associated with an org 316, a user 318, and/or an account 320” [0061]),
the custodial tenant wallet identifier identifying a cryptographic key-pair (“In particular embodiments, the public trust ledger synthetic party keys 1508 may be stored within a public trust ledger wallet, which in turn may be stored in the database system” [0210]; “The database system may maintain, for instance, a private key associated with an account within a blockchain” [0192]; “According to various embodiments, communication with the smart contract 500 may be secured via the public key 502 and the private key 504” [0090]);
transmit the call and the custodial tenant wallet identifier to a Web3 interface to encrypt the transaction with a private key of the cryptographic keypair (“According to various embodiments, a crypto transaction envelope 356 may be submitted to one or more document recipients 352 for signing. A document recipient may be identified by, for instance, a wallet identifier or a user identifier. The document recipient may sign the crypto transaction envelope with a private key at 348. The signature may be recorded in the document recipient object 346 along with the envelope identifier. Information related to signatures may be recorded in the service report 360 and/or the document envelope 358, which collectively with the crypto envelope 356 form a signed document 354” [0075]; “According to various embodiments, communication with the smart contract 500 may be secured via the public key 502 and the private key 504. The public key 502 is publicly available to anyone with access to the public trust ledger, while the private key 504 is private to the smart contract 502. Any system may employ the public key 502 to encrypt a message that can only be decrypted by the smart contract's private key. Similarly, the smart contrast 500 may encrypt a message using the private key 504” [0090]) and
It would have been obvious to one of ordinary skill in the art before the priority date to modify Khaund with the added structure of Padmanabhan for the purpose of the system being able to determine whose wallet to use when a transaction or a signing request arrives.
Claim 7 recites substantially the same limitation as claim 1, in the form of a method for implementing the corresponding system, therefore it is rejected under the same rationale.
Claim 13 recites substantially the same limitation as claim 1, in the form of a non-transitory computer readable medium comprising computer readable program code for implementing the corresponding system, therefore it is rejected under the same rationale.
Regarding claims 2, 8, and 14, Khaund discloses: receive, at the Web server, a second user request to claim a second benefit of a second one of the one or more attributes; in response to the second user request, determine at the Web server that the user is associated with the Web3 asset based on the stored user identifier; and in response to the determination in response to the second request that the user is associated with the Web3 asset, provide the second benefit to the user (“For the second action, unlike the above action with a single user submitting multiple different access right requests (e.g., for different resources or seats) sequentially, sequential requests for a single access right can create dependencies that will fail” [0229]; “First site controller 712 a may communicate with primary load management system 1014 to verify the data, in a manner similar to that described herein. Upon detecting that the first access code data has been verified, first site controller 712 a can transmit second access code data to user device 1026. The second access code data have a precision of association that associates the data with one or more particular access characteristics…User device 1026 may then transmit the second access code data (e.g., when user device 1026 detects that it has crossed a geofence corresponding to the location and/or when user device 1026 receives input or a site-controller request indicating that access data is to be transmitted to a nearby site controller) to second site controller 712 b. Second site controller 712 b can determine whether the code is verified (e.g., valid, has not been previously used, and/or corresponds to the user device 1026 and/or location). The determination can include (for example) transmitting the second access code data to another device (e.g., primary load management system 1014, a local server, or another site controller, such as first site controller 712 a) and receiving second verification data that indicates whether the second access code data is verified. The determination can, alternatively or additionally, include a local determination, which may be based (for example) on comparing the second access code data to data in a local access-code data store to determine whether there is a match and/or whether the second access code data (or corresponding access code data that is associated with same one or more particular characteristics) has been previously verified. The local access-code data store may be populated by second site controller 712 b, for example, in response to communications from one or more other site controllers and/or primary load management system 1014 that identify second access code data that have been issued” [0214-0215] [Examiner notes that these texts show a second request made by the user. The user device receives a second access code data (new entitlement tied to a different benefit). That second code is associated with distinct access characteristics. This aligns with claiming a second benefit tied to a second attribute. The system verifies whether the second code is valid and associated with the user (a form of user-to-asset association) via the access code data. If verified, the system provides access (providing the second benefit). Examiner wants to note that multiple users can make multiple requests and therefore no novelty is added by the claim language]).
Regarding claims 3, 9, and 15, Khaund discloses: receive, at the Web server, a second user request from a second user to claim the benefit of the one of the one or more attributes; in response to the second user request, determine at the Web server that the second user is associated with the Web3 asset based on the stored second user identifier; and in response to the determination that the second user is associated with the Web3 asset, provide the benefit to the second user (“For the second action, unlike the above action with a single user submitting multiple different access right requests (e.g., for different resources or seats) sequentially, sequential requests for a single access right can create dependencies that will fail” [0229]; “First site controller 712 a may communicate with primary load management system 1014 to verify the data, in a manner similar to that described herein. Upon detecting that the first access code data has been verified, first site controller 712 a can transmit second access code data to user device 1026. The second access code data have a precision of association that associates the data with one or more particular access characteristics…User device 1026 may then transmit the second access code data (e.g., when user device 1026 detects that it has crossed a geofence corresponding to the location and/or when user device 1026 receives input or a site-controller request indicating that access data is to be transmitted to a nearby site controller) to second site controller 712 b. Second site controller 712 b can determine whether the code is verified (e.g., valid, has not been previously used, and/or corresponds to the user device 1026 and/or location). The determination can include (for example) transmitting the second access code data to another device (e.g., primary load management system 1014, a local server, or another site controller, such as first site controller 712 a) and receiving second verification data that indicates whether the second access code data is verified. The determination can, alternatively or additionally, include a local determination, which may be based (for example) on comparing the second access code data to data in a local access-code data store to determine whether there is a match and/or whether the second access code data (or corresponding access code data that is associated with same one or more particular characteristics) has been previously verified. The local access-code data store may be populated by second site controller 712 b, for example, in response to communications from one or more other site controllers and/or primary load management system 1014 that identify second access code data that have been issued” [0214-0215] [Examiner notes that these texts show a second request made by the user. The user device receives a second access code data (new entitlement tied to a different benefit). That second code is associated with distinct access characteristics. This aligns with claiming a second benefit tied to a second attribute. The system verifies whether the second code is valid and associated with the user (a form of user-to-asset association) via the access code data. If verified, the system provides access (providing the second benefit). Examiner wants to note that multiple users can make multiple requests and therefore no novelty is added by the claim language]).
Regarding claims 4, 10, and 16, Khaund discloses: wherein the user identifier of the user is stored in association with an identifier of the Web3 asset, the metadata and In some implementations, once the secure digital assets for a specific resource are created, the secure digital assets can be made available for assignment by the access right issuer as electronic access rights to the resource. The access right issuer may provide a digital queue for storing the electronic access right requests received from the users. Each access right request may be associated with metadata that describes certain information about the access right or access right requestor. The access right issuer can provide a triage queueing system that processes the metadata to reorder the digital queue, so that the most urgent (or important) access right requests are processed by the Blockchain first before less urgent access right requests. As will be described in greater detail herein, the triage queuing system can, for example, filter, reorder, delegate, and/or batch access right requests to optimize throughput and reduce processing latency of access right processing using the Blockchain” [0030]; “A management server 222 can interact with web server 218 to provide indications as to which access rights' are available for assignment, characteristics of access rights and/or what data is needed to assign an access right. When requisite information is received (e.g., about a user and/or user device, identifying a final request for one or more access rights, including payment information, and so on), management server 222 can coordinate an assignment of the one or more access rights. The coordination can include updating an access-right data store to change a status of the one or more access rights (e.g., to assigned); to associate each of the one or more access rights with a user and/or user device; to generate or identify one or more access-enabling codes for the one or more access rights; and/or to facilitate transmission reflecting the assignment (e.g., and including the one or more access-enabling codes) to a user device” [0055] [Examiner notes both of these texts shows that metadata is being generated, associated with access right requests. This implies that this metadata is linked to specific users, since it is used to prioritize their requests. It also supports that a user ID is stored in association with a Web3 asset and explicitly includes a system receiving instructions and storing data as part of that response. Examiner also notes that these texts show an access right (Web3 asset), metadata explicitly mentioned as being associated with the access right request, and suggests that the system stores and/or uses that metadata in connection with the access right which shows the identifier of the Web3 asset and the metadata. The user identifier (user and user device), Web3 asset identifiers (one or more access rights), access enabling codes which is functionally equivalent to key identifiers are stored in a data store showing association between the user ID, asset ID, and key]), and
wherein the encrypted operation is encrypted using a private key associated with the key identifier (“Recently, however, Blockchain technology has gained popularity for the enhanced security the technology provides to various applications. Blockchain provides a decentralized approach to verifying the authenticity of information, including data representing transactions. Certain embodiments of the present disclosure relate to systems and methods that convert access rights into secure digital assets protected by cryptographic public/private keys. As only a non-limiting example, a secure digital asset may be a smart contract” [0007]; “The coordination can include updating an access-right data store to change a status of the one or more access rights (e.g., to assigned); to associate each of the one or more access rights with a user and/or user device; to generate or identify one or more access-enabling codes for the one or more access rights; and/or to facilitate transmission reflecting the assignment (e.g., and including the one or more access-enabling codes) to a user device” [0055] [Examiner notes that this text describes the conversion of access rights into cryptographically secured digital assets (i.e. smart contracts) that are then published to a blockchain – which directly reflects the idea of generating a secure, encrypted operation to create a Web3 asset on a Web3 database. It then also transmits the encrypted operation to the Web3 database by publishing it to a decentralized blockchain. Examiner also notes that a code is generated per access right (which is already a cryptographically protected digital asset), thus the access-enabling code is associated with the same resource that is protected by a private key. The code is used by the system or device (issued to user to enable or unlock the right) to recognize or decrypt the right to access the protected asset which suggests that the code is tied to the key (identifies or is mapped to the key), used to identify the correct private key, and can even function as a key identifier directly]).
Khaund does not disclose: the custodial tenant wallet identifier.
However, Padmanabhan discloses: the custodial tenant wallet identifier (“For example, an entry in the wallet table 360 may include a wallet ID associated with the database system and/or an account ID associated with an account in a public trust ledger such as a blockchain” [0061]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Khaund with the added structure of Padmanabhan in order to link the user ID with the custodial tenant wallet ID.
Regarding claims 5, 11, and 17, Khaund discloses: receive a request at the Web server from the user to transfer the Web3 asset to a second key identifier associated with the user (“Primary assignment management system 214 can be configured to coordinate and/or control initial assignment of access rights. Secondary assignment management system 216 can be configured to coordinate and/or control reassignment and/or transfer of access rights (e.g., from one user or user device to another or from an intermediate agent to a user or user device). Secondary assignment management system 216 may also manage transfer offers (e.g., to allow a first user to identify a price at which a transfer request would be granted and to detect if a valid request is received” [0052]); and
in response to the received request to transfer the Web3 asset to the user: generate a second encrypted operation to transfer the Web3 asset to the user on the Web3 database, where the encrypted second operation is encrypted using the private key; transmit the second encrypted operation to the Web3 database (“Primary load management system 1140 may be a Blockchain-based system that uses Blockchain nodes to manage the generation, ownership, and transfer of secure digital assets (e.g., smart contracts) that represent electronic access rights to resources” [0217]; “Certain embodiments of the present disclosure relate to systems and methods that convert access rights into secure digital assets protected by cryptographic public/private keys” [0007] [Examiner notes that the digital assets can be cryptographically encrypted during any operation especially when the Web3 backend finalizes the transaction after protecting the transfer operation]); and
store the second key identifier in association with the user identifier, the identifier of the Web3 asset and the metadata (“Access-enabling code data store 430 can store access-enabling code data that includes one or more codes and/or other information that can be used to indicate that an entity is authorized to use, have or receive a resource. An access-enabling code can include, for example, a numeric string, an alphanumeric string, a text string, a 1-dimensional code, a 2-dimensional code, a barcode, a quick response (QR) code, an image, a static code and/or a temporally dynamic code. An access-enabling code can be, for example, unique across all instances, resource types and/or entities. For example, access-enabling codes provided in association for access rights to a particular resource can be unique relative to each other. In some instances, at least part of a code identifies a resource or specification of a resource” [0111] [Examiner notes that the user ID association comes from the code stored to indicate that the entity (user) is authorized, the Web3 asset association comes from the code includes part that identifies a resource, and the metadata association can be either the other information that can be used to indicate that an entity is authorized to use, have, or receive a resource or the part of a code that identifies a resource or specification of a resource (metadata indicating the identity or scope of the resource – the asset itself)]).
Regarding claims 6, 12, and 18, Khaund discloses: receive a request at the Web server from the user to transfer the Web3 asset to a second key identifier associated with the user (“Primary assignment management system 214 can be configured to coordinate and/or control initial assignment of access rights. Secondary assignment management system 216 can be configured to coordinate and/or control reassignment and/or transfer of access rights (e.g., from one user or user device to another or from an intermediate agent to a user or user device). Secondary assignment management system 216 may also manage transfer offers (e.g., to allow a first user to identify a price at which a transfer request would be granted and to detect if a valid request is received” [0052]); and
in response to the received request to transfer the Web3 asset to the user: generate a second encrypted operation to transfer the Web3 asset to the user on the Web3 database; transmit the second encrypted operation to the Web3 database (“Primary load management system 1140 may be a Blockchain-based system that uses Blockchain nodes to manage the generation, ownership, and transfer of secure digital assets (e.g., smart contracts) that represent electronic access rights to resources” [0217]; “Certain embodiments of the present disclosure relate to systems and methods that convert access rights into secure digital assets protected by cryptographic public/private keys” [0007] [Examiner notes that the digital assets can be cryptographically encrypted during any operation especially when the Web3 backend finalizes the transaction after protecting the transfer operation]); and
store the second key identifier in association with the user identifier, the identifier of the Web3 asset and the metadata (“Access-enabling code data store 430 can store access-enabling code data that includes one or more codes and/or other information that can be used to indicate that an entity is authorized to use, have or receive a resource. An access-enabling code can include, for example, a numeric string, an alphanumeric string, a text string, a 1-dimensional code, a 2-dimensional code, a barcode, a quick response (QR) code, an image, a static code and/or a temporally dynamic code. An access-enabling code can be, for example, unique across all instances, resource types and/or entities. For example, access-enabling codes provided in association for access rights to a particular resource can be unique relative to each other. In some instances, at least part of a code identifies a resource or specification of a resource” [0111] [Examiner notes that the user ID association comes from the code stored to indicate that the entity (user) is authorized, the Web3 asset association comes from the code includes part that identifies a resource, and the metadata association can be either the other information that can be used to indicate that an entity is authorized to use, have, or receive a resource or the part of a code that identifies a resource or specification of a resource (metadata indicating the identity or scope of the resource – the asset itself)]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Bernardi (US 2024/0185191 A1) teaches a Web3 Decentralized Blockchain Based NFT Framework for Buyers and Sellers Who Require Privacy, Security and Confidentiality Interworking with Zero Trust Security, Digital Rights Management (DRM), Self-Sovereign Identity Management, Ricardian Contracts, NFT Ownership and Copyright Validation, IPFS Decentralized Storage, WebRTC-QUIC Real Time Communications, Cross-Chain Interoperability and Tokenization of Illiquid Digital Assets such as Patents and University Research Papers using Blockchain NFTs and Artificial Intelligence (AI) Applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The examiner can normally be reached Monday - Friday, 9:30 am - 6:30pm.
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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights