DETAILED ACTION
This action is responsive to the application filed on November 08, 2024, which is a National Stage entry of PCT/US2023/066668, filed on May 23, 2023.
The application claims foreign priority to 10202204876V, filed on May 10, 2022.
The preliminary amendments filed on November 08, 2024 have been acknowledged and considered.
Claims 1, 8, 13, 17 and 20 have been amended. Claims 10-11 and 18 have been canceled. Claims 21-22 have been newly added.
Claims 1-9, 12-17 and 19-22 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The drawings filed on November 08, 2024 are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated November 08, 2024 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Specification
The disclosure is objected to because of the following informalities:
(a) Paragraph [0032] recites “the input string, the object structure, and the byte sequence program represent a workflow is an ordered sequence”. The word “is” appears to be a typographical error for “in”. Correction is required, particularly because claim 17 as amended now recites “represent a workflow in an ordered sequence”, and the specification should be conformed.
(b) Paragraph [00103] recites “The encoding module 308 transforms the byte sequence program into executable smart contract representation 312”. The encoding module is identified throughout the disclosure as element 310; element 308 is the interpreting module. (c) Paragraph [00122] recites “the encoding module 308 may restrict byte sequence representation 560”. The same reference-numeral error identified in item (b) appears here. (d) Paragraph [00120] recites “may map to a native SolidityTM function 526 for mediating blockchain execution”. The native Solidity function is identified elsewhere in the same paragraph as element 562. The numeral 526 appears to be a transposition error. (e) Paragraph [00136] recites “Hardcoding the conditions 602 off-chain then deploying the conditions 603 to a blockchain”. The numeral 603 does not correspond to any element in the drawings and appears to be a typographical error for 602. (f) Paragraph [00161] recites “relies on example input strings 402, 404, 406, 408, 410, and 410”. The numeral 410 is recited twice; the second occurrence appears to be a typographical error for 412.
Appropriate correction is required.
Claim Objections
Claims 6, 13-14 and 20 are objected to because of the following informalities: Claim 6 is objected to under 37 CFR 1.75(c) as being in improper dependent form. Claim 6 recites “The compiler method of claim 21”. Pursuant to 35 U.S.C. § 112 and 37 CFR 1.75(c), a claim in dependent form must refer only to a claim or claims previously set forth. Claim 6 refers to a numerically following claim. See MPEP § 608.01(n). Applicant is required to cancel the improper dependent claim, to rewrite it in independent form, or to renumber the claims so that claim 6 refers to a preceding claim. See Ex parte Porter, 25 USPQ2d 1144, 1147 (Bd. Pat. App. & Inter. 1992). Claim 6 has nevertheless been treated on the merits below on the assumption that Applicant intends dependency from the claim reciting the object structure.
Claim 13 is objected to because of the following informality. Claim 13 recites “wherein the receiving the second input string, and the determining the second byte sequence program is performed by a master smart contract”. The compound subject does not agree with the singular verb “is”, and the comma preceding “and” is superfluous now that the parsing step has been deleted from the claim. Appropriate correction is required.
Claim 14 is objected to because of the following informality. Claim 14 recites “wherein the updating of the byte sequence program is updated exclusive of any other segments and any other agreement conditions”. The subject “the updating” cannot itself be “updated”. Appropriate correction is required.
Claim 20 is objected to because of the following informality. Claim 20 recites instructions that “cause a smart contract of the processor deployed on a blockchain to” perform the recited acts. The prepositional phrase “of the processor” does not correspond to any relationship described in the specification, in which the smart contract is deployed on nodes of the blockchain rather than owned by a processor. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1–9, 12–17, and 19–22 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.
(A) Claim 1 recites “a second input string for updating a segment of at least one of the agreement conditions”. There is insufficient antecedent basis for the plural limitation “the agreement conditions” in the claim. Claim 1 earlier recites only “at least one agreement condition” in the singular. It is unclear whether the claim requires a plurality of agreement conditions, or whether the plural recitation is intended to refer back to the single “at least one agreement condition” previously recited. Claim 20 recites the same limitation and is rejected for the same reason. Claims 2–9, 12–17, 19, 21, and 22 are rejected as depending from a rejected base claim.
(B) Claim 1 recites “sending, to the computing device or another computing device, confirmation of execution of the at least one smart contract representation”. There is insufficient antecedent basis for “the at least one smart contract representation” in the claim. The antecedent recited earlier in claim 1 is “at least one executable smart contract representation”. It is unclear whether “the at least one smart contract representation” is intended to be the same element as the previously recited executable smart contract representation, or a different element. Claim 20 recites the same limitation and is rejected for the same reason.
(C) Claims 15 and 16 each recite “the second string input”. There is insufficient antecedent basis for this limitation in the claims. Claim 1 recites “a second input string”. It is unclear whether “the second string input” of claims 15 and 16 is intended to refer to the “second input string” of claim 1 or to a separate element.
(D) Claim 15 recites “an amount of at least one of the actions”. There is insufficient antecedent basis for the plural limitation “the actions” in the claim. Claim 1 recites only “at least one action” in the singular.
For purposes of applying prior art below, the above limitations have been interpreted in accordance with the antecedents actually recited in claim 1, that is, “the agreement conditions” is read as the previously recited “at least one agreement condition”, “the at least one smart contract representation” is read as the previously recited “at least one executable smart contract representation”, “the second string input” is read as the previously recited “second input string”, and “the actions” is read as the previously recited “at least one action”.
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–9, 12–17, and 19–22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–17 of U.S. Patent No. 12,008,348 B2 (Dubrofsky et al., issued June 11, 2024). Although the claims at issue are not identical, they are not patentably distinct from each other for the reasons set forth below.
U.S. Patent No. 12,008,348 B2 issued from an application claiming the benefit of priority to the same Singapore Patent Application Serial No. 10202204876V filed May 10, 2022 that is relied upon in the present application, names the same first inventor, and is stated on its face to be owned by The Pairwyse Foundation. Common ownership with the present application is therefore apparent from the record and is presumed for purposes of 37 CFR 1.321(c).
Instant claim 1 recites every step of patented claim 1 except the two parsing steps, and substitutes “for the input string” for “for the object structure”. Instant claim 1 is therefore broader than, and wholly encompasses, patented claim 1. A claim that omits a limitation of a patented claim, and thereby broadens it, is not patentably distinct from that patented claim. Instant claims 21 and 22 restore the two omitted parsing steps, so that instant claim 22 recites substantially the entire subject matter of patented claim 1. Instant claim 20 stands in the same relationship to patented claim 17. The remaining instant dependent claims recite limitations that correspond one-for-one to the patented dependent claims as set out in the table below, in most instances word for word.
The scope of the instant claims and the scope of the patented claims are therefore substantially the same. The instant claims define an invention that is either anticipated by, or an obvious variation of, the invention defined by the patented claims, differing only by the omission of an element and its function or by immaterial changes in wording. Allowance of the instant claims would improperly extend the term of the exclusive right already granted by U.S. Patent No. 12,008,348 B2.
Instant Application 18/864,292
U.S. Patent No. 12,008,348 B2
Claim 1. A compiler method for a smart contract, the method comprising: by the smart contract deployed on a blockchain: receiving an input string having at least one agreement condition and at least one action; accepting the input string;
[no parsing step]
determining a byte sequence program for the input string, wherein the byte sequence program is an ordered sequence of bytecodes for executing the at least one agreement condition and the at least one action; mapping the byte sequence program into at least one executable smart contract representation of the input string executable by the blockchain, wherein the at least one executable smart contract representation implements at least one function of a programming language, wherein in response to receiving a request for executing the at least one function of the programming language, the at least one executable smart contract representation for the at least one function is executed and the at least one action is performed; receiving, from a computing device, a second input string for updating a segment of at least one of the agreement conditions;
[no parsing step]
determining a second byte sequence program for the second input string; updating the byte sequence program with the second byte sequence program; evaluating the at least one executable smart contract representation in response to the at least one agreement condition being satisfied; and sending, to the computing device or another computing device, confirmation of execution of the at least one smart contract representation.
Claim 1. A compiler method for a smart contract, the method comprising: by the smart contract deployed on a blockchain: receiving an input string having at least one agreement condition and at least one action; accepting the input string;
parsing, using a parser, the input string into an object structure, wherein the object structure is in a string format;
determining a byte sequence program for the object structure, wherein the byte sequence program is an ordered sequence of bytecodes for executing the at least one agreement condition and the at least one action; mapping the byte sequence program into at least one executable smart contract representation of the object structure executable by the blockchain, wherein the at least one executable smart contract representation implements at least one function of a programming language, wherein in response to receiving a request for executing the at least one function of the programming language, the at least one executable smart contract representation for the at least one function is executed and the at least one action is performed; receiving, from a computing device, a second input string for updating a segment of at least one of the agreement conditions;
parsing, using the parser, the second input string into a second object structure comprising the segment;
determining a second byte sequence program for the second object structure; updating the byte sequence program with the second byte sequence program; evaluating the at least one executable smart contract representation in response to the at least one agreement condition being satisfied; and sending, to the computing device or another computing device, confirmation of execution of the at least one smart contract representation.
Claim 20. A computer-readable medium having tangibly stored thereon computer-executable instructions that, in response to execution by a processor, cause a smart contract of the processor deployed on a blockchain to: receive an input string having at least one agreement condition and at least one action; accept the input string;
[no parsing step]
determine a byte sequence program for the input string; map the byte sequence program into at least one executable smart contract representation of the input string executable by the blockchain; receive, from a computing device, a second input string for updating a segment of at least one of the agreement conditions;
[no parsing step]
determine a second byte sequence program for the second input string; update the byte sequence program with the second byte sequence program; evaluate the at least one executable smart contract representation in response to the at least one agreement condition being satisfied; and send confirmation of execution.
Claim 17. A computer-readable medium having tangibly stored thereon computer-executable instructions that, in response to execution by a processor, cause a smart contract of the processor deployed on a blockchain to: receive an input string having at least one agreement condition and at least one action; accept the input string;
parse, using a parser, the input string into an object structure, wherein the object structure is in a string format;
determine a byte sequence program for the object structure; map the byte sequence program into at least one executable smart contract representation of the object structure executable by the blockchain; receive, from a computing device, a second input string for updating a segment of at least one of the agreement conditions;
parse, using the parser, the second input string into a second object structure comprising the segment;
determine a second byte sequence program for the second object structure; update the byte sequence program with the second byte sequence program; evaluate the at least one executable smart contract representation in response to the at least one agreement condition being satisfied; and send confirmation of execution.
Claim 2
Claim 2
Claim 3
Claim 3
Claim 4
Claim 4
Claim 5
Claim 5
Claim 6
Claim 6
Claim 7
Claim 7
Claim 8
Claim 8
Claim 9
Claim 9
Claim 12
Claim 10
Claim 13
Claim 11
Claim 14
Claim 12
Claim 15
Claim 13
Claim 16
Claim 14
Claim 17
Claim 15
Claim 19
Claim 16
Claim 21
Claim 1
Claim 22
Claim 1
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.
The factual inquiries 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–6, 12–17, and 19–22 are rejected under 35 U.S.C. 103 as being unpatentable over Tao Li et al. (“ATOM: Architectural Support and Optimization Mechanism for Smart Contract Fast Update and Execution in Blockchain-Based IoT”, hereinafter “Li” – IDS 11/08/2024) in view of Rosinzonsky et al. (US Pub. No. 2020/0065763, hereinafter “Rosinzonsky”).
With respect to claim 1 (Currently Amended), Li teaches A compiler method for a smart contract, the method comprising: [[by the smart contract deployed on a blockchain:]] (Li is directed to a smart contract architecture in which executable bytecode is constructed for a smart contract and then updated. Section III-B states that “Bytecode construction has two steps: 1) template selection and 2) assembling”, and Section V-B1 states that “In ATOM, parsing refers to construct executable bytecode from XACML directly”. The resulting bytecode is executed on a blockchain; Section V-A states that “EVM (version 1.9.20) is the smart contract execution environment” and that “Smart contracts are coded in Solidity”.)
receiving an input string having at least one agreement condition and at least one action (Section V-A states “We utilize XACML to implement the access control policy and the XML Reader” to parse the policy. The XACML policy is a markup text string that specifies the access-control rule to be satisfied, which is the agreement condition, and the consequence of that rule, which is the action. Section II-B formulates the relationship as o = Θ(Td, p) with “A is an action based on output o”, and explains for the role-based access control model that “o is FALSE or TRUE, and the corresponding A is DENY and ALLOW”. Section III-B further states that “The template assembling needs two inputs: 1) the selected template and 2) application data”, which includes the parameter p and the action A drawn from the received policy.) accepting the input string (Section III-A describes a permission instruction used “to manage whether to allow a contract updating or not”, which on receipt of a request will “compare the update request information with the predefined update rules”, whereupon “an agreement or rejection to the update request is returned”. A received input string is thus accepted only after this validation.) determining a byte sequence program for the input string, wherein the byte sequence program is an ordered sequence of bytecodes for executing the at least one agreement condition and the at least one action (Section III-B states that “the template-based bytecode construction constructs an executable bytecode by selecting a bytecode template from bytecode template set according to an application function, and assembles the selected template with other application data”, and Section V-B1 confirms that in Li “parsing refers to construct executable bytecode from XACML directly”. That the construct is an ordered sequence of bytecodes is established by Section III-A, which states that the bytecode is stored in the code segment as a byte array in which “each byte represents an instruction identifier number or instruction operand”, and by Section II-B, which states that execution “follows four steps: 1) instruction retrieving; 2) storage place validation; 3) instruction dispatching; and 4) instruction execution” and that “the program counter retrieves each instruction from Storage” in sequence.) mapping the byte sequence program into at least one executable smart contract representation of the input string executable by the blockchain, wherein the at least one executable smart contract representation implements at least one function of a programming language, wherein in response to receiving a request for executing the at least one function of the programming language, the at least one executable smart contract representation for the at least one function is executed and the at least one action is performed (Section III-B states that after assembling “the specific application is constructed into an executable bytecode”. Section IV states that “This executable bytecode instance will then be deployed in the access control system” and that “After deployment, the executable has a unique address, which is used for invoking”. That the executable representation implements functions of a programming language is established by Section V-B4, in which Li provides three application instructions that respectively encapsulate “an IF statement to perform string comparison”, “a FOR statement to perform repeated execution of IF statement”, and “a recursive function to retrieve string from Storage”, the underlying contracts being written in Solidity per Section V-A. Section II-B establishes execution on request and performance of the action: a smart contract function “can be invoked by a transaction”, the invocation produces output o, and “A is an action based on output o”.) receiving, [[from a computing device,]] a second input string for updating a segment of at least one of the agreement conditions (Section IV states “we first send an update request (step 1 ), which contains contract address, update type, and update data”. Section III-A states that “Update instruction is used for performing contract update” and that “Update instructions are designed to support different types of updating”. Section IV confirms that the update request changes the access-control rule, that is, the agreement condition: “A contract update request can be either changing from SAC to RBAC and vice versa or changing the parameters of SAC and RBAC”.) determining a second byte sequence program for the second input string (Section IV states that on receipt of the update request “ATOM first checks whether RBAC template exists in the template set or not and then conducts the data update and code update through update instructions”. The template corresponding to the newly specified policy is thus selected and assembled in the manner described in Section III-B to produce the replacement bytecode.) updating the byte sequence program with the second byte sequence program (Section III states “Essentially, smart contract update is bytecode update” and adopts as its first design guideline that “The deployed bytecode should be modified directly to conduct the contract updating”. Section III-A states that “code update is achieved by modifying the byte value in the byte array”. Section IV gives the worked example: “For code update, ωSAC is updated to ωRBAC”.) evaluating the at least one executable smart contract representation in response to the at least one agreement condition being satisfied (Section IV states that “The RBAC contract checks whether the role of the requester is inside the accessible role list”. Section II-B establishes that the outcome of that evaluation determines the action performed, because “o is FALSE or TRUE, and the corresponding A is DENY and ALLOW”.) sending, to the computing device or another computing device, confirmation of execution of the at least one smart contract representation (Section III-A states that following evaluation of a request against the stored rules “an agreement or rejection to the update request is returned” to the requester. Section IV likewise states that where the access evaluation fails “the request to access certain resource should be blocked”, the result of the contract’s execution thereby being returned to the requesting entity.) Li is silent to disclose by the smart contract deployed on a blockchain: and from a computing device; however, in an analogous art, Rosinzonsky teaches: by the smart contract deployed on a blockchain: (Paragraph [0005] states that the smart contract corresponding to the template “may be implemented by a smart contract interpreter, which may itself be a separate smart contract executing on a consensus network or blockchain”, and that this interpreter is one “that interprets the template and thereafter performs actions corresponding to the terms and/or requirements of the smart contract as specified by the template”. Paragraph [0059] confirms that the interpreting entity resides on-chain: smart contract module 255A of node 240A, “which may be stored within or part of ledger data store 252A”, “interprets and/or analyzes template data 256A and identifies one or more operations” that are to be performed.) from a computing device (Paragraph [0078] states that “Client device 102 outputs, over network 105, template 101”, which is thereafter detected and processed by node 240A of the consensus network. The description of the smart contract is thus supplied to the on-chain interpreter from a client computing device separate from the blockchain node.) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the bytecode construction and update architecture of Li so that the receiving of the input string, the determination of the byte sequence program, and the mapping and updating of that program are carried out by the smart contract deployed on the blockchain, and so that the second input string is received from a computing device, as taught by Rosinzonsky. One of ordinary skill would have been motivated to make this modification because Rosinzonsky states that placing interpretation of a client-supplied contract description in an on-chain smart contract makes “development or implementation of some smart contracts accessible to non-programmers” and yields “a portable smart contract application that can be moved from one blockchain platform to another in a simplified process that does not require writing any new code” (paragraph [0016]). The modification further advances a design objective that Li itself expressly adopts, namely that “Contract recompilation should be removed as much as possible to reduce contract update time” (Section III). One of ordinary skill would have had a reasonable expectation of success because Li already performs its update instructions on the deployed contract, at a fixed contract address, “Before and after the update, the address of contract is not changed” (Section IV), so relocating the remaining construction step on-chain requires no change in the underlying execution environment. The combination is no more than the use of a known technique to improve a similar device in the same way. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(C) and (D). With respect to claim 2 (Original), Li teaches wherein the segment is a segment of a function (Section III-A states that “Contract updating can be either the data update of parameter p” or the code update of the function and the action, and that “code update is achieved by modifying the byte value in the byte array” in which the function is stored. Section IV shows the update applied to a single position within that function: “the instruction identity number of the corresponding position is modified from 0x1a to 0x4f”.) With respect to claim 3 (Original), Li teaches wherein the at least one executable smart contract representation implements native functions or native operations (Section III-A begins by “Extending the EVM native instruction set”, and Section III-B states that “A bytecode template consists of two types of instructions”, the application-oriented instructions and the EVM native instructions, both of which are assembled into the deployed executable bytecode.) With respect to claim 4 (Original), Li teaches wherein the native functions or the native operations include: one or more binary comparators including at least one of equal, not equal, greater than or less than; one or more set operations including at least one of logical AND, logical OR, COUNT, or SUM; one or more compositional operators including at least one of plus, minus, multiplication, or division; or one or more loops including while-loops, for-loops, counters, if-statements, switch statements (The claim recites four alternatives joined by “or”, so disclosure of any one alternative meets the limitation. Li discloses at least two. As to binary comparators, Section III-C describes the EQ instruction used to test equality of two operands: “When EQ instruction executes, the two strings need to be popped from Stack and be compared”. As to loops and if-statements, Section V-B4 states that Li provides application instructions encapsulating “an IF statement to perform string comparison” and “a FOR statement to perform repeated execution of IF statement”.) With respect to claim 5 (Original), Li teaches wherein the at least one executable smart contract representation implements a data source function including at least one of logical TRUE, logical FALSE, or a read-only variable (Section II-B states that the output of the deployed checking function is a logical value and that the action follows from it: “o is FALSE or TRUE, and the corresponding A is DENY and ALLOW”.) With respect to claim 6 (Currently Amended), Li is silent to disclose; however, in an analogous art, Rosinzonsky teaches wherein the object structure is a nested tree, each leaf of the nested tree being another object structure (Paragraph [0076] states that the data model of the template comprises “dictionaries indexed by a hash, consisting of name, counter, and list of signatures”, and that “A signature may be a dictionary consisting of name, date and pgp string”. An entry of the dictionary is therefore itself a dictionary, so that the object structure is a nested hierarchy in which a leaf of the structure is another object structure of the same kind.) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to structure the object structure produced from the input string in Li in view of Rosinzonsky as the nested dictionary hierarchy taught by Rosinzonsky. One of ordinary skill would have been motivated to do so because a nested representation permits a contract description of arbitrary depth to be expressed and processed without extending the instruction set, which supports Rosinzonsky’s stated aim of a description that is “accessible to non-programmers” (paragraph [0016]) while remaining machine-processable. The result is the predictable use of a well-known data organization to represent hierarchically structured contract terms. With respect to claim 12 (Original), Li teaches wherein the at least one executable smart contract representation is executable by an Ethereum Virtual Machine (EVM) of the blockchain (Section V-A states that “EVM (version 1.9.20) is the smart contract execution environment” in which the constructed and updated bytecode is executed.) With respect to claim 13 (Original), Li teaches wherein the receiving the second input string, and the determining the second byte sequence program is performed by a master smart contract which is the smart contract deployed on the blockchain (Section IV states that the update request “contains contract address, update type, and update data” and is directed to the deployed contract at that address, and that on receipt “ATOM first checks whether RBAC template exists in the template set or not and then conducts the data update and code update through update instructions”. That the receiving and determining entity is the deployed contract itself, rather than any separate contract, is confirmed by the statement that “Before and after the update, the address of contract is not changed”.) With respect to claim 14 (Original), Li teaches wherein the updating of the byte sequence program is updated exclusive of any other segments and any other agreement conditions (Section IV states that the code update is confined to a single location in the deployed byte array: “the instruction identity number of the corresponding position is modified from 0x1a to 0x4f”. Section III-A confirms the granularity of the operation: “code update is achieved by modifying the byte value in the byte array”. No other position in the array, and therefore no other segment or condition, is altered.) With respect to claim 15 (Original), Li teaches wherein the second string input is for further updating an amount of at least one of the actions (Section IV describes the simple access control contract as one “comparing access interval with a preset threshold” to determine whether the access request is allowed or blocked, and states that “Once a SAC contract is deployed, the threshold is fixed”. Section IV then states that “A contract update request can be either changing from SAC to RBAC and vice versa or changing the parameters of SAC and RBAC”. The second input string therefore updates the numerical threshold amount that governs whether the deny action issues, which Section III-A characterizes as “the data update of parameter p”.) With respect to claim 16 (Original), Li teaches wherein the second string input is for further updating one or more further segments of at least one of the agreement conditions (Section IV states that a single update request produces changes in more than one location: “we need to update both the code and the data considering RBAC has different parameters from SAC”. It further specifies each, stating that “for data update, the threshold is updated to the RBAC parameters (e.g., filename) in trie” in addition to the code-segment modification of the instruction identity number.) With respect to claim 17 (Currently Amended), Li teaches wherein the input string and the byte sequence program represent a workflow in an ordered sequence (As to the byte sequence program, Section II-B states that execution “follows four steps: 1) instruction retrieving; 2) storage place validation; 3) instruction dispatching; and 4) instruction execution” and that “the program counter retrieves each instruction from Storage” in the order in which the instructions are laid down. Section III-B specifies the order in which the constituents of the input are assembled into that program: “ATOM stores p first and Td second”. As to the input string, the XACML policy correspondingly specifies the ordered access-control sequence of receiving a request, checking it against the rule, and allowing or denying it, as set out in Section IV.) With respect to claim 19 (Original), Li teaches wherein the receiving the second input string is performed after the mapping (Section IV states that the constructed bytecode “will then be deployed in the access control system” and that only afterwards is the update request made: “Later, we update the access control policy to be RBAC”.) With respect to claim 20, claim 20 is a computer-readable medium claim reciting instructions that cause a smart contract deployed on a blockchain to perform acts that mirror, step for step, the method steps of claim 1. Claim 20 is therefore rejected over Li in view of Rosinzonsky for the reasons given above with respect to claim 1, which are incorporated here by reference. Li further teaches the recited medium storing the instructions: Section II-B states that “Storage is the online persistent storage” from which the program counter retrieves each instruction, and Section III-A states that the bytecode of the contract is stored in the code segment as a byte array in which “each byte represents an instruction identifier number or instruction operand”. With respect to claim 21 (New), Li teaches further comprising parsing, using a parser, the input string into an object structure, [[wherein the object structure is in a string format]] (Section V-A states “We utilize XACML to implement the access control policy and the XML Reader” to parse the policy, the XML Reader being the recited parser. Section III-B states that the template-based method “only needs source code parsing, but not complex morpheme or syntax analysis”, and Section V-B1 states that “Each policy will be parsed into a smart contract”. The parsing operation thus resolves the received policy string into its constituent policy objects, which are the parameter p, the transaction data Td, and the action A that Section III-B identifies as the application data supplied to the assembling step.) Li is silent to disclose; however, in an analogous art, Rosinzonsky teaches wherein the object structure is in a string format (Paragraph [0074] states that “the template is written in YAML” in one example and that “the template 390B of FIG. 3B is written in JSON (JavaScript Object Notation)” in another. Paragraph [0075] states that the template listing comprises “a data model that defines the attributes associated with the notary application executing as a smart contract” together with a series of methods, and that “a method is defined as a list of actions in the format “action : destination””. The object structure that the node stores and interprets is therefore expressed in a textual, that is, string, notation rather than in a compiled binary form.) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to express the object structure parsed from the input string in Li in the textual object notation taught by Rosinzonsky. One of ordinary skill would have been motivated to do so because Rosinzonsky teaches that a textual description of this kind renders smart contract implementation “accessible to non-programmers” and portable “from one blockchain platform to another in a simplified process that does not require writing any new code” (paragraph [0016]), and because Li already operates on a textual markup policy parsed by an XML Reader, so that substituting or expressing the parsed structure in an equivalent textual object notation is the substitution of one known textual representation for another to obtain predictable results. See MPEP § 2143(I)(B). With respect to claim 22 (New), Li teaches further comprising parsing, using the parser, the second input string into a second object structure comprising the segment (Section V-B1 states that “Each policy will be parsed into a smart contract” and that in the update evaluation “the originally generated SAC smart contract will be updated to RBAC contracts and vice versa”, so the replacement policy is parsed by the same XML Reader identified in Section V-A. Section IV establishes that the resulting structure contains the segment to be changed, because the update request “contains contract address, update type, and update data” and, on the basis of that parsed update data, “ATOM first checks whether RBAC template exists in the template set or not and then conducts the data update and code update through update instructions”, the code update being applied to the identified segment where “the instruction identity number of the corresponding position is modified from 0x1a to 0x4f”.)
Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Tao Li et al. (“ATOM: Architectural Support and Optimization Mechanism for Smart Contract Fast Update and Execution in Blockchain-Based IoT”, hereinafter “Li” – IDS 11/08/2024) in view of Rosinzonsky et al. (US Pub. No. 2020/0065763, hereinafter “Rosinzonsky”) and further in view of Alex Biryukov et al. (“Findel: Secure Derivative Contracts for Ethereum”, hereinafter “Biryukov”). With respect to claim 7 (Original), Li in view of Rosinzonsky is silent to disclose; however, in an analogous art, Biryukov teaches wherein the input string is in a recursive data structure (Biryukov describes a contract description built from a fixed set of composable primitives in which a primitive takes further contracts as its arguments, so that the description is a structure defined in terms of itself. Section 1 states that “new indefinitely complex derivatives can be defined based on existing ones” and that “Due to their nested structure, contracts in this DSL are well-suited for automated processing”.) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to express the input string received by the on-chain smart contract of Li in view of Rosinzonsky as the recursive structure taught by Biryukov. One of ordinary skill would have been motivated to do so because Biryukov teaches that a recursively composable description permits arbitrarily complex agreements to be expressed from a small fixed primitive set, and that such descriptions are for that reason “well-suited for automated processing”. This directly serves the objective of Li in view of Rosinzonsky, in which a fixed and deliberately compact instruction set must express the operations of the received policy, and in which Rosinzonsky seeks a description “accessible to non-programmers” (paragraph [0016]). One of ordinary skill would have had a reasonable expectation of success because Biryukov demonstrates the recursive description being received and evaluated by an Ethereum smart contract, which is the same execution environment used by Li. With respect to claim 8 (Currently Amended), Li teaches wherein the accepting of the input string is based on the computing device or a user providing the input string having permission to provide the input string (Section III-A states that a “Permission instruction specifies which kind of roles can do contract update”, for example the owner or the caller, and that during contract deployment “the updatable roles and type information are written into a fixed place in Storage”. On receipt of a request, the permission instructions “compare the update request information with the predefined update rules”, whereupon “an agreement or rejection to the update request is returned”. Acceptance of the received string is therefore conditioned on the requesting entity holding the requisite permission.) With respect to claim 9 (Original), Biryukov further teaches wherein the recursive data structure is a domain-specific language (The Abstract introduces “a purely declarative financial domain-specific language (DSL)” in which the contract clauses are expressed, and states that the authors “implement an Ethereum smart contract that acts as a marketplace for Findel contracts”, that is, an on-chain contract that receives and executes descriptions written in that domain-specific language. The recursive data structure credited to Biryukov with respect to claim 7 is thus the domain-specific language recited in claim 9, and the motivation to combine set out for claim 7 applies equally here.)
Conclusion
The following prior art is made of record and is not relied upon, but is considered pertinent to Applicant’s disclosure:
T. Tateishi et al., (“Automatic Smart Contract Generation using Controlled Natural Language and Template” - IDS) discloses generating an executable smart contract from a human-understandable contract document created using a document template and a controlled natural language. Li (US Pub. No. 2020/0301846 - IDS) discloses encoding input parameters into a memory segment and providing the memory location to a decoding function. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM. 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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights