Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-6, 9-16 and 19-20 is/are rejected under 35 U.S.C. 102 (a)(1) as being anticipate by Jesept Poon et al., “The bitcoin Lightning network Scalable Off-Chain Instant Payment”, January 13, 2016.
With respect to claims 1, 10 and 16, Josept Poon et al. discloses a computer-implemented method comprising:
identifying a transaction script for modifying a resource stored within a user account of an authenticated data structure maintained by at least one computer node of a distributed digital ledger transaction network (i.e., “This creates a great possibility that entities will end up trusting centralized parties. Having privileged, trusted parties creates a social trap whereby the central party will not act in the interest of an individual (principal agent problem)” (page 2, fourth paragraph) and “By creating timeframes where certain states can be broadcast and later invalidated, it is possible to create complex contracts using bitcoin transaction scripts…Paths can be routed using a BGP like system, and the sender may designate a particular path to the recipient. The output scripts are encumbered by a hash, which is generated by the recipient.”(page 7, first, second paragraph) and invalidated is modifying a resource as claimed invention), wherein:
the resource comprises smart contract data that defines an implementation of a module utilized to generate the resource, the module comprising smart contract code that defines procedures used in implementing the module and that is stored separately from the smart contract data and “By creating timeframes where certain states can be broadcast and later invalidated, it is possible to create complex contracts using bitcoin transaction scripts…Paths can be routed using a BGP like system, and the sender may designate a particular path to the recipient. The output scripts are encumbered by a hash, which is generated by the recipient.”(page 7, first, second paragraph) which hash is code as claimed invention and is generated by the recipient is stored separately from the smart contract data such as complex contracts are refence ),
the transaction script comprises an access path for the resource stored within the user account (i.e., “By creating timeframes where certain states can be broadcast and later invalidated, it is possible to create complex contracts using bitcoin transaction scripts…Paths can be routed using a BGP like system, and the sender may designate a particular path to the recipient. The output scripts are encumbered by a hash, which is generated by the recipient.”(page 7, first, second paragraph) and invalidated is modifying a resource as claimed invention), and
the access path reflects a resource identifier corresponding to the resource, the module utilized to generate the resource, and a particular user account storing the module (i.e., “By creating timeframes where certain states can be broadcast and later invalidated, it is possible to create complex contracts using bitcoin transaction scripts…By chaining together multiple micropayment channels, it is possible to create a network of transaction paths. Paths can be routed using a BGP like system, and the sender may designate a particular path to the recipient. The output scripts are encumbered by a hash, which is generated by the recipient.”(page 7, first, second paragraph) and the output script are encumbered a hash and generate the timeframes for contract for bitcoin user (sender or recipient user)); and
based on the access path, executing the transaction script by modifying the resource in accordance with the procedures defined by the module (i.e., “Paths can be routed using a BGP like system, and the sender may designate a particular path to the recipient. The output scripts are encumbered by a hash, which is generated by the recipient. By disclosing the input to that hash, the recipient’s counterparty will be able to pull funds along the route.”(.”(page 7, first, second paragraph) and the input to that hash, the recipient’s counterparty will be able to pull fuds along the route ).
With respect to claims 2,11, and 20, Josept Poon et al. discloses further comprising storing the module at an additional user account of the authenticated data structure maintained by the at least one computer node of the distributed digital ledger transaction network that is different from the user account storing the resource (i.e., “Having privileged, trusted parties creates a social trap whereby the central party will not act in the interest of an individual (principal agent problem), e.g. rentierism by charging higher fees to mitigate the incentive to act dishonestly”(page 2, last paragraph)).
With respect to claim 3, and 12, Josept Poon et al. discloses the computer-implemented method of claim 2, wherein identifying the transaction script that includes the access path that reflects the particular user account storing the module comprises identifying the transaction script that includes the access path that reflects an address of the additional user account within the authenticated data structure (i.e., “By chaining together multiple micropayment channels, it is possible to create a network of transaction paths. Paths can be routed using a BGP like system, and the sender may designate a particular path to the recipient. The output scripts are encumbered by a hash, which is generated by the recipient. By disclosing the input to that hash, the recipient’s counterparty will be able to pull funds along the route.”(page 7, second paragraph) and transaction paths are transaction script that including access path and sender may designate a particular path for particular receipt (address of the attritional user account within the authenticated data structure).
With respect to claims 4 and 13, Josept Poon et al. discloses further comprising storing the module at the user account of the authenticated data structure that is storing the resource (i.e., “This centralization would then defeat aspects of network decentralization that make Bitcoin secure, as the ability for entities to validate the chain is what allows Bitcoin to ensure ledger accuracy and security”(page 2, third paragraph) and user account (entities) and security as resource of claimed invention).
With respect to claims 5 and 14, Josept Poon et al. discloses further comprising: storing the module at the particular user account of the authenticated data structure of the distributed digital ledger transaction network (i.e., “This creates a great possibility that entities will end up trusting centralized parties. Having privileged, trusted parties creates a social trap whereby the central party will not act in the interest of an individual (principal agent problem)” (page 2, fourth paragraph)); storing an additional module at the particular user account; and determining a first module namespace for uniquely identifying the module within transaction scripts and a second module namespace for uniquely identifying the additional module within one or more transaction scripts (i.e., “A Revocable Transaction spends from a unique output where the transaction has a unique type of output script. This parent’s output has two redemption paths where the first can be redeemed immediately, and the second can only be redeemed if the child has a minimum number of confirmations between transactions”(page 14, third paragraph)).
With respect to claims 6 and 15, Josept Poon et al. discloses the computer-implemented method of claim 5 or 14, further comprising determining an extended module namespace for identifying the resource using the first module namespace for the module, wherein the access path comprises the extended module namespace (i.e., “A Revocable Transaction spends from a unique output where the transaction has a unique type of output script. This parent’s output has two redemption paths where the first can be redeemed immediately, and the second can only be redeemed if the child has a minimum number of confirmations between transactions”(page 14, third paragraph) and Examiner assert that child is extended module namespace as claimed invention)..
With respect to claims 9 and 19, Josept Poon et al. discloses wherein the module utilized to generate the resource comprises bytecode that declares a resource type for the resource and the procedures for modifying the resource (i.e., “For full SPV compatibility (Simple Payment Verification; lightweight clients), it is desirable for this to be within the 80 byte block header instead of in the coinbase. There are two places which may be a good place to put in this flag in the block header: in the block time and in the block version” (page 17, third paragraph)).
Allowable Subject Matter
Claims 7 and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, since the prior art of record and considered pertinent to the applicant’s disclosure does not teach or suggest the claimed wherein identifying the transaction script for modifying the resource stored within the user account of the authenticated data structure maintained by the at least one computer node of the distributed digital ledger transaction network comprises identifying the transaction script for modifying the resource that includes a record that binds name fields to values in accordance with a resource type for the resource defined by the module.
Claims 8 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, since the prior art of record and considered pertinent to the applicant’s disclosure does not teach or suggest the claimed further comprising: storing the resource within the user account of the authenticated data structure of the distributed digital ledger transaction network, the resource having a first resource type defined by the module; and storing an additional resource within the user account, the additional resource having a second resource type defined by an additional module.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUNG T VY whose telephone number is (571)272-1954. The examiner can normally be reached M-F 8-5.
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, Tony Mahmoudi can be reached at (571)272-4078. 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.
/HUNG T VY/Primary Examiner, Art Unit 2163 March 29, 2026