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 .
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 25, 2026, has been entered.
Acknowledgment
This Action is in response to the request for continued examination and the amendment filed on March 25, 2026. Claims 1-5 and 8-21 are currently pending, from which claims 13-20 are withdrawn by Applicant’s election. Claims 6-7 have been cancelled by Applicant. Claims 1-5, 8-12 and 21 have been fully examined.
Response to Arguments
With respect to the 103 rejections, the examiner notes that the current amendment merely incorporate the subject matter of currently cancelled claim 6 and portion of currently amended claim 5, into independent claim 1.
Applicant argues, on page 7 of the remarks, that the cited prior art does not teach the amendment to claim 1: “providing a platform including a processor and a memory receiving a locking request to lock the digital asset upon issuance of a certificate, wherein the certificate is a paper token certificate or an electronic certificate.” The examiner respectfully disagrees and notes that Conley, at least in [0074]-[0078] teaches that the creator (i.e. platform) creates a bearer token or a certified token (i.e., certificate) electronically or non-electronically. Conley further in [0081] teaches that the assets associated with created tokens are locked or lockable (i.e., locked upon creating).
Applicant further argues, on page 7, that “Conley does not teach the certificate of the present Application.” The examiner respectfully disagrees and notes that the bearer token (BT) or the certified token (CT) taught by Conley are equivalent of the claimed certificate.
Applicant further argues that according to the Specification the certificate is “a legal document that certifies a legal interest in ownership of a number of shares or stock in a corporation.” The examiner respectfully notes that the statement is not claimed, but even if claimed, it merely indicates non-functional descriptive material that describes the certificate and therefore does not further limit the scope of the claim.
Applicant further argues, on page 8 of the remarks, that the claimed certificate contains information needed to unlock a protected asset or account, including an unlocking key, and that the QR code of Conley is not the same as the certificate. The examiner respectfully notes that the bearer token of Conley (and not the QR code) is equivalent of the claimed certificate, and Conley, at least in [0076]-[0078] teaches that the bearer token (certificate) includes a hash that is used for unlocking the locked account.
Applicant further argues that none of the prior art recites a method for locking a digital asset including minting an NFT corresponding to the certificate, and that The examiner respectfully disagrees and notes that Conley at least in [0083] teaches an NFT associated with the bearer token (certificate) and, at least in [0375]-[0376] teaches minting the NFT.
The examiner further notes that since Conley in newly cited portions teaches an NFT corresponding to the bearer token (certificate), the previously cited art of Sliwka is not relied on for teaching this limitation.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8-12 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Conley et al. (US Patent Application No. 2023/0259923) in view of Kumaraswamy et al. (US Patent Publication No. 2020/0074518.)
With respect to claim 1, Conley et al. teach:
providing a platform including a processor and a memory … lock the digital asset upon issuance of a certificate, wherein the certificate is a paper token certificate or an electronic certificate; (the creator (i.e. platform) creates a bearer token or a certified token (i.e., certificate) electronically or non-electronically (i.e., paper or electronic) : [0074]-[0078], the assets (i.e., digital assets) associated with created tokens are locked or lockable (i.e., locked upon creating): [0081])
the platform implementing locking logic and recording a locking record on a ledger; (hash locked account protocol (i.e., locking logic) is applied: [0056], [0074], [0077])
the platform, upon implementation of the locking logic, minting a non-fungible token (NFT) corresponding to the certificate and transferring the NFT to the digital wallet; (create NFTs: [0376], [0522], [0552]-[0553], NFTs are associated with bearer tokens or certified tokens (i.e., certificates): [0081]-[0083])
wherein the locking logic is operable to prevent execution of functions affecting the digital asset while the digital asset is locked; (hash locked account record prevents transfer of NFT: [0022], claim 1)
The examiner notes that the claim recitation “wherein the locking logic is operable to prevent…” indicates intended use of the locking logic and therefore does not further limit the scope of thew claim. The claim limitation indicates “operability” of the locking logic while does not positively recite any functions performed by the locking logic.
wherein the locking record is an entry on the ledger…([0030]
locking record includes asset identification and a wallet identification; (account record includes identification number, account number: [0136], [0148]-[0165])
The examiner notes that the claim recitation: “locking record includes asset identification and a wallet identification,” indicates non-functional descriptive material and therefore does not further limit the scope of the claim. This is because the asset identification and a wallet identification have not been used by any claimed functions and do not affect any claimed features.
the platform issuing an unlocking key for unlocking the digital asset; (generating pre-image of locking hashes or release hash digest: (i.e., unlocking keys): [0012]-[0013], [0024], [0076]-[0078], [0095]-[0100], [0262], [0335], claim 3)
the platform cryptographically hashing the unlocking key to produce a locking hash and recording the locking hash on the locking record; (generating pre-image of locking hashes or release hash digest: [0075]-[0078], [0095]-[0100])
… produce an unlocking code; (pre-images are encoded into QR codes, release hash (unlocking code) : [0075]-[0078], [0095]-[0100])
the platform delivering the unlocking code via the certificate; (the bearer or certified tokens (i.e. certificates) are encoded images such as QR codes and the QR code is provided within the tokens (i.e., via the tokens): [0062], [0075]-[0078])
the platform receiving an unlocking request to unlock the digital asset; (user creates and sends an unlock transaction (i.e., request) [0054], [0167]-[0170])
wherein the unlocking request to unlock the digital asset includes an unlocking key; (the unlock transaction includes the pre-image (i.e., unlocking key): [0167]-[0170])
the platform cryptographically hashing the unlocking key of the unlocking request to produce an unlocking hash; (new hashes are generated: [0259]-[0262])
the platform comparing the unlocking hash to the locking hash on the locking record; (the existing hash is verified against the new hash: [0272])
upon matching the unlocking hash to the locking hash, the platform unlocking the digital asset; (verifies hashes: [0272]-[0275])
wherein unlocking the digital asset causes the locking logic to allow execution of functions affecting the digital asset while the digital asset is unlocked. (unlocking allows transfer: [0332]-[0337])
The examiner notes that the claim recitation “wherein unlocking the digital asset causes the locking logic to allow …” indicates intended use of the unlocking and therefore does not further limit the scope of thew claim.
Conley et al. do not explicitly teach:
providing a platform including a processor and a memory receiving a locking request to lock the digital asset;
the platform asymmetrically encrypting the unlocking key with a public key associated with the digital wallet holding the digital asset…
wherein the unlocking code is decryptable with a private key associated with the digital wallet holding the digital asset to produce the unlocking key.
However, Kumaraswamy et al. teach:
providing a platform including a processor and a memory receiving a locking request to lock the digital asset; (digital data management system (i.e., the platform) locks digital asset based on receiving a request: [0074])
the platform asymmetrically encrypting the unlocking key with a public key associated with the digital wallet holding the digital asset… (the locked asset is digitally signed using a public key: [0079], [0087], [0089]-[0091])
wherein the unlocking code is decryptable with a private key associated with the digital wallet holding the digital asset to produce the unlocking key. (decryption using the private key: [0079], [0087], [0089]-[0091])
The examiner notes that the claim recitation “…the unlocking code is decryptable … to produce …” indicates intended use of the unlocking code and therefore does not further limit the scope of thew claim.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate encrypting data associated with a locked asset using a public key, as taught by Kumaraswamy et al., into the system of Conley et al., for locking digital assets, in order to provide data security. (Kumaraswamy et al.: Abstract, [0002])
With respect to claim 2, Conley et al. and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Kumaraswamy et al. teach:
wherein the locking logic does not affect execution of functions for additional digital assets in the digital wallet. (Multiple types of digital assets are stored: FIG. 1, [0023], locking is applied on one type of assets: [0073]-[0074] and [0078]-[0079])
The examiner notes that the claim recitation indicates non-functional descriptive material and therefore does not further limit the scope of the claim.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate storing and locking multiple types of digital assets, as taught by Kumaraswamy et al., into the system of Conley et al. for locking digital assets, in order to enable applying locking on digital assets separately. (Kumaraswamy et al.: FIG. 1)
With respect to claim 3, Conley et al. and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach:
wherein the unlocking key is included in a Quick Response (QR) code. (QR code App: [0062], [0067], bearer tokens of locked accounts can be presented in QR form: [0075], [0095]-[0097])
With respect to claim 4, Conley et al. and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach:
wherein the locking request and/or the unlocking request is received through an Application Programming Interface (API). (devices communicate via interfaces: [0052], [0054], [0517], [0553])
With respect to claim 5, Conley et al. and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach:
wherein the unlocking code is represented by a Quick Response (QR) code. (bearer tokens (i.e., certificates) are encoded using QR codes: [0062], [0075])
With respect to claim 8, Conley et al., and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Kumaraswamy et al. teach:
wherein the locking logic is enforced by a locking script, a smart contract, and/or a modified transfer function of a smart contract associated with the digital asset. (execution of a smart contract enforces locking the digital asset: [0078]-[0079], Claims 1-3)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate using smart contracts to facilitate digital asset exchange, as taught by Kumaraswamy et al., into the system of Conley et al. for locking digital assets, in order to enforce locking/unlocking of the asset using a smart contract. (Kumaraswamy et al.: Abstract)
With respect to claim 9, Conley et al., and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach:
wherein the locking record includes a locking status of the digital asset. (record status: [0148]-[0172], [0356])
With respect to claim 10, Conley et al., and Kumaraswamy et al. teach the limitations of claim 9.
Moreover, Conley et al. teach:
wherein a smart contract associated with the digital asset include a function to check the locking status of the digital asset prior to executing … functions. (checking record status (recStatus) prior to executing a function. ([0148]-[0172])
Conley et al. do not explicitly teach “smart contract function,” however, a smart contract function or a function of a smart contract can be any function that is included in a smart contract. Therefore, the functions taught by Conley et al. such as “delete record…” (in [0172]) that is executed based on checking the lock status (recStaus) reads on the claim.
In addition, Kumaraswamy et al. teach a function of checking status of a transaction: ([0082])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate using smart contracts to facilitate digital asset exchange, as taught by Kumaraswamy et al., into the system of Conley et al. for locking digital assets, in order to enforce locking/unlocking of the asset using a smart contract. (Kumaraswamy et al.: Abstract)
With respect to claim 11, Conley et al., and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach preventing functions while asset is locked (hash locked account record prevents transfer of NFT: [0022]), and if hash verification is successful, unlock transaction is executed: [(claim 1) 0272]-[0275])
Conley et al. and Kumaraswamy et al. do not explicitly teach:
preventing execution of functions affecting the digital asset upon comparing the unlocking hash to the locking hash of the locking record and not matching the unlocking hash to the locking hash. However, the claim recitation is logically equivalent of the recitations of claim 1: “the locking logic is operable to prevent execution of functions affecting the digital asset while the digital asset is locked” and “upon matching the unlocking hash to the locking hash, the platform unlocking the digital asset.”
With respect to claim 12, Conley et al., and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach:
wherein the ledger includes a Distributed Ledger Technology (DLT), public distributed ledger, a private distributed ledger, and/or a hybrid ledger. ([0045], [0049], [0055])
With respect to claim 21, Conley et al. and Kumaraswamy et al. teach the limitations of claim 1.
Moreover, Conley et al. teach:
wherein the locking record is issued as a non-fungible-token (NFT) (NFT records are minted:[0376], [0432]-[0433], [0501]) NFTs are transmitted to an operator wallet. ([0258]-[0260])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Shi (US 2020/0153632 ) teaches controlling digital assets by locking. Ingargiola (US 2021/0073913) teaches recording digital assts by applying locking/unlocking protocols.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIMA ASGARI whose telephone number is (571)272-2037. The examiner can normally be reached M-F 9am-6pm.
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, Patrick McAtee can be reached on (571)272-7575. 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.
/SIMA ASGARI/Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights