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 .
DETAILED ACTION
This communication is a Non-Final Office Action rejection on the merits. Claims 1-20 are currently pending and have been addressed 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20, are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20, 22-24 and 26-29 of U.S. Patent No. 11,928,438 (Arijit Das). The claims at issue are not patentably distinct from each other as shown in bold in the table below.
Patent. No 11,928,438
Present Application:
19/442,296
Examiner’s Notes
1, 17 and 26. A system, comprising :a computing instance programmed to: host a large language model (LLM) trained to (i) read a bytecode capable of being executed on a distributed ledger, (ii) determine whether the bytecode enables a smart contract on the distributed ledger, and (iii) take a first action based on the bytecode being determined to enable the smart contract and a second action based on the bytecode being determined to not enable the smart contract, wherein the bytecode enables the smart contract by expressing (1) an offeror identifier associated with an offeror network address on the distributed ledger, (2) an offeree identifier associated with an offeree network address on the distributed ledger, (3) an offer expression associated with the offeror identifier, (4) an acceptance expression associated with the offeree identifier, and (5) a consideration expression associated with the offeror identifier and the offeree identifier, wherein the first action includes (a) identifying the offer expression, the acceptance expression, and the consideration expression, (b) generating a human-readable content describing the offer expression, the acceptance expression, and the consideration expression, and (c) outputting the human-readable content for consumption on a computing terminal, wherein the second action includes outputting a notice for consumption on the computing terminal, wherein the notice indicates the bytecode being determined to not enable the smart contract; and host a logic programmed to (i) receive the offeror network address from the computing terminal and the offeree network address from the computing terminal, (ii) locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address, (iii) form a copy of the bytecode, and (iv) prompt the LLM with the copy such that the LLM (a) determines whether the copy enables the smart contract and (b) takes the first action based on the copy being determined to enable the smart contract and the second action based on the copy being determined to not enable the smart contract., wherein the computing instance is a physical server or a set of physical servers.
2. wherein the human-readable content includes an unstructured text describing the offer expression, the acceptance expression, and the consideration expression.
3. wherein the human-readable content includes an image describing the offer expression, the acceptance expression, and the consideration expression.
4. wherein the human-readable content includes a sound describing the offer expression, the acceptance expression, and the consideration expression.
5. wherein the first action includes identifying a potential defense statement to the offer expression, the acceptance expression, or the consideration expression, generating the human-readable content including the potential defense statement, and outputting the human-readable content including the potential defense statement for consumption on the computing terminal.
6. wherein the bytecode includes a jurisdictional identifier associated with the offer expression, the acceptance expression, and the consideration expression, wherein the first action includes identifying the jurisdictional identifier, determining whether the potential defense statement is applicable to the jurisdictional identifier, and taking a third action based on the potential defense statement being determined to be applicable to the jurisdictional identifier and a fourth action based on the potential defense statement being determined to not be applicable to the jurisdictional identifier.
7. wherein the third action includes generating the human-readable content including the potential defense statement and outputting the human-readable content including the potential defense statement for consumption on the computing terminal.
8. wherein the fourth action includes outputting an alert indicating the potential defense statement being determined to not be applicable to the jurisdictional identifier for consumption on the computing terminal.
9. wherein the LLM is prompted from the computing terminal at a location, wherein the computing instance is programmed to determine the location such that the third action or the fourth action involves determining whether the location is covered by the jurisdictional identifier and outputting a first message based the location being determined to be covered by the jurisdictional identifier for consumption on the computing terminal and a second message based the location being determined to not be covered by the jurisdictional identifier for consumption on the computing terminal.
10. wherein the first action includes determining whether the offeror identifier, the offeror network address, the offeree identifier, the offeree network address, the offer expression, the acceptance expression, or the consideration expression include or relate to an entity identifier listed in a list and outputting a message indicating the entity identifier being listed in the list for consumption on the computing terminal.
11. wherein the first action includes determining whether the offeror identifier, the offeror network address, the offeree identifier, the offeree network address, the offer expression, the acceptance expression, or the consideration expression include or relate to an entity identifier not listed in a list and outputting a message indicating the entity identifier not being listed in the list for consumption on the computing terminal.
12. wherein the distributed ledger includes a distributed virtual machine which the logic accesses to locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address.
13. wherein the logic is user interactable from the computing terminal.
14. wherein the LLM and the logic are separate and distinct from each other.
15. wherein the LLM is trained to (i) read the bytecode capable of being executed on the distributed ledger, (ii) determine whether the bytecode enables the smart contract on the distributed ledger, and (iii) take the first action based on the bytecode being determined to enable the smart contract and the second action based on the bytecode being determined to not enable the smart contract, via a supervised learning technique.
16. wherein the LLM is trained to (i) read the bytecode capable of being executed on the distributed ledger, (ii) determine whether the bytecode enables the smart contract on the distributed ledger, and (iii) take the first action based on the bytecode being determined to enable the smart contract and the second action based on the bytecode being determined to not enable the smart contract, via a non- supervised learning technique.
18, 22 and 27. wherein the computing instance is the physical server.
19, 23 and 28. wherein the computing instance is the set of physical servers.
20, 24 and 29. wherein the set of physical servers is a server farm.
1 and 20, A system, comprising: a processor programmed to:
access a large language model (LLM) trained to (i) read a bytecode executable on a distributed ledger, (ii) determine whether the bytecode enables a smart contract on the distributed ledger, and (iii) take a first action based on the bytecode being determined to enable the smart contract and a second action based on the bytecode being determined to not enable the smart contract, wherein the bytecode enables the smart contract by expressing (1) an offeror identifier associated with an offeror network address on the distributed ledger, (2) an offeree identifier associated with an offeree network address on the distributed ledger, (3) an offer expression associated with the offeror identifier, (4) an acceptance expression associated with the offeree identifier, and (5) a consideration expression associated with the offeror identifier and the offeree identifier, wherein the first action includes (a) identifying the offer expression, the acceptance expression, and the consideration expression, (b) generating a human- readable content describing the offer expression, the acceptance expression, and the consideration expression, and (c) outputting the human-readable content, wherein the second action includes outputting a notice indicating the bytecode being determined to not enable the smart contract; and
access a logic programmed to (i) access the offeror network address and the offeree network address, (ii) locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address, (iii) form a copy of the bytecode, and (iv) prompt the LLM with the copy such that the LLM (a) determines whether the copy enables the smart contract and (b) takes the first action based on the copy being determined to enable the smart contract and the second action based on the copy being determined to not enable the smart contract.
2. wherein the human-readable content includes an unstructured text describing the offer expression, the acceptance expression, and the consideration expression.
3. wherein the human-readable content includes an image describing the offer expression, the acceptance expression, and the consideration expression.
4. wherein the human-readable content includes a sound describing the offer expression, the acceptance expression, and the consideration expression.
5. wherein the first action includes identifying a potential defense statement to the offer expression, the acceptance expression, or the consideration expression, generating the human-readable content including the potential defense statement, and outputting the human-readable content including the potential defense statement.
6. wherein the bytecode includes a jurisdictional identifier associated with the offer expression, the acceptance expression, and the consideration expression, wherein the first action includes identifying the jurisdictional identifier, determining whether the potential defense statement is applicable to the jurisdictional identifier, and taking a third action based on the potential defense statement being determined to be applicable to the jurisdictional identifier and a fourth action based on the potential defense statement being determined to not be applicable to the jurisdictional identifier.
7. wherein the third action includes generating the human- readable content including the potential defense statement and outputting the human- readable content including the potential defense statement.
8. wherein the fourth action includes outputting an alert indicating the potential defense statement being determined to not be applicable to the jurisdictional identifier.
9. wherein the processor is programmed to determine a location from which the LLM is prompted such that the third action or the fourth action involves determining whether the location is covered by the jurisdictional identifier and outputting a first message based the location being determined to be covered by the jurisdictional identifier and a second message based the location being determined to not be covered by the jurisdictional identifier.
10. wherein the first action includes determining whether the offeror identifier, the offeror network address, the offeree identifier, the offeree network address, the offer expression, the acceptance expression, or the consideration expression include or relate to an entity identifier listed in a list and outputting a message indicating the entity identifier being listed in the list.
11. wherein the first action includes determining whether the offeror identifier, the offeror network address, the offeree identifier, the offeree network address, the offer expression, the acceptance expression, or the consideration expression include or relate to an entity identifier not listed in a list and outputting a message indicating the entity identifier not being listed in the list.
12. wherein the distributed ledger includes a distributed virtual machine which the logic is able to access to locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address.
13. wherein the logic is human-user interactable.
14. wherein the LLM and the logic are separate and distinct from each other.
15. wherein the LLM is trained to (i) read the bytecode executable on the distributed ledger, (ii) determine whether the bytecode enables the smart contract on the distributed ledger, and (iii) take the first action based on the bytecode being determined to enable the smart contract and the second action based on the bytecode being determined to not enable the smart contract, via a supervised learning technique.
16. wherein the LLM is trained to (i) read the bytecode executable on the distributed ledger, (ii) determine whether the bytecode enables the smart contract on the distributed ledger, and (iii) take the first action based on the bytecode being determined to enable the smart contract and the second action based on the bytecode being determined to not enable the smart contract, via a non-supervised learning technique.
17. wherein the processor is a server.
18. wherein the processor is a plurality of physical servers.
19. wherein the plurality of physical servers enables a server farm.
This preamble is essentially the same.
This limitation is essentially the same,
This limitation is essentially the same,
This limitation is essentially the same
This limitation is the same
This limitation is the same
This limitation is the same
This limitation is essentially the same
This limitation is the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
Prior Art Analysis
The instant application recites subject matter that was identified as allowable in application 18,219,383 with Patent. No 11,928,438.
Examiner is unable to find prior art for the following limitation:
“…wherein the bytecode enables the smart contract by expressing (1) an offeror identifier associated with an offeror network address on the distributed ledger, (2) an offeree identifier associated with an offeree network address on the distributed ledger, (3) an offer expression associated with the offeror identifier, (4) an acceptance expression associated with the offeree identifier, and (5) a consideration expression associated with the offeror identifier and the offeree identifier, wherein the first action includes (a) identifying the offer expression, the acceptance expression, and the consideration expression, (b) generating a human- readable content describing the offer expression, the acceptance expression, and the consideration expression, and (c) outputting the human-readable content, wherein the second action includes outputting a notice indicating the bytecode being determined to not enable the smart contract;”
Therefore, with the filing of a Terminal Disclaimer, as there is no other rejection in the application, claims 1-20 will be Allowed.
Conclusion
The prior art made of record and not relied upon are all listed in form 892 attached.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights