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 .
Response to Arguments
Objections to the Drawings
The applicant’s amendments are sufficient to overcome the previous objections which are consequently withdrawn.
35 U.S.C. §103 rejections
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 6, 9, 11, 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0021769 to Buckley et al. (Buckley) in view of US 2025/0085131 to Dasher et al. (Dasher) in view of US 2021/0357194 to Guo et al. (Guo).
Claims 1 and 11: Buckley discloses a computer-implemented method comprising:
in response to a query received from a client device, generating, utilizing a context engine to interact with a large language model, computer code executable for responding to the query (par. [0069] “transmit a prompt 114-1 requesting that the language model 152 generate JavaScript expressions(s)”);
executing the computer code utilizing an interpreter integrated with the context engine (par. [0067] “the interpreter 154 executing the source code”); and
generating, as part of executing the computer code utilizing the interpreter, a first context engine output by implementing the interpreter to interpret the computer code from the context engine to a first executor (par. [0068] “the interpreter 154 is configured to … compile the executable instructions 156”, par. [0039] “parse the machine-readable instruction into executable instructions”).
Buckley does not disclose:
dissecting, utilizing a context engine, the query from the client device into a set of individual sub-prompts;
generating, as part of executing the computer code utilizing the interpreter, a first context engine output that corresponds with a sub-prompt of the set of individual sub-prompts; and
generating, a second context engine output that corresponds with an additional sub-prompt of the set of individual sub-prompts
generate, as part of executing the computer code utilizing the interpreter, a first context engine output that corresponds with a sub-prompt of the set of individual sub-prompts.
Dasher teaches:
dissect, utilizing a context engine, the query from the client device into a set of individual sub-prompts (par. [0078] “generate … one or more portions of the prompt or query 101A, … such as a weather context sub-prompt”);
generating, a second context engine output that corresponds with an additional sub-prompt of the set of individual sub-prompts (par. [0078] “or more portions of the prompt or query”);
generate, as part of executing the computer code utilizing the interpreter, a first context engine output that corresponds with a sub-prompt of the set of individual sub-prompts (par. [0097] “processes the detailed prompt”).
It would have been obvious before the effective filing date of the claimed invention to dissect the query into a set of individual sub-prompts, and generate outputs corresponding to the sub-prompts. Those of ordinary skill in the art would have been motivated to do so “to improve the automatic content generation” (Dasher abstract).
Buckley and Dasher do not explicitly teach:
the context engine and comprising swappable logic that is interchangeable across multiple executors; and
generating, as part of executing the computer code utilizing the interpreter, a second context engine output by implementing the interpreter to interpret the computer code from the context engine to a second executor.
Guo teaches:
the interpreter comprising swappable logic that is interchangeable across multiple executors (e.g. par. [0081] “using modules of generic compiler … generate machine executable code for GPP … using modules of the domain-specific compiler … generate machine executable code for network processor”); and
generating, as part of executing the computer code utilizing the interpreter, a second context engine output by implementing the interpreter to interpret the computer code from the context engine to a second executor (par. [0081] “using modules of generic compiler … generate machine executable code for GPP … using modules of the domain-specific compiler … generate machine executable code for network processor”, par. [0048] “compiled to generate unified code 110 to be executed by one or more GPPs and … target hardware specific code 112 to be executed by one or more network processors”).
It would have been obvious at the time of filing to use swappable logic to generated first and second outputs. Those of ordinary skill in the art would have been motivated to do so to provides flexibility and programmability (see e.g. Guo par. [0019]).
Claim 2: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, wherein the interpreter comprises explicitly defined types that define attributes and functions of code expressions (e.g. Buckley par. [0128] attributes that describe the element (e.g., label like “button”, “text”, “link” … “, par. [0137] “the device data includes … a custom data type”).
Claim 6: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, further comprising:
in response to a first interaction from the client device, generating, utilizing the interpreter, an intermediate context engine output (Buckley par. [0060] “e.g., “identifying my gaming tab””);
receiving a second interaction from the client device (Buckley par. [0060] “display a textual response … visually identify the gaming tab”); and
based on the second interaction, generating, utilizing the large language model, a modified context engine output from the intermediate context engine output (Buckley par. [0060] “delete the browser tab 162 and display a textual response”).
Claim 9: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, further comprising:
in response to a first interaction from the client device, generating, utilizing the interpreter, a first output (Buckley par. [0060] “display a textual response … visually identify the gaming tab”);
persisting a state of the interpreter corresponding to the first output (Buckley par. [0060] “a history of textual data submitted by the user and textual responses provide by the task assistant 110”); and
in response to a second interaction from the client device, generating a second output based on persisting the state of interpreter corresponding to the first output (Buckley par. [0060] “delete the browser tab 162 and display a textual response”).
Claim 16: Buckley discloses a non-transitory computer-readable medium storing executable instructions which, when executed by at least one processor, cause the at least one processor to:
in response to a query received from a client device, generate, utilizing a context engine to interact with a large language model, computer code executable for responding to the query (par. [0069] “transmit a prompt 114-1 requesting that the language model 152 generate JavaScript expressions(s)”);
execute the computer code utilizing an interpreter integrated with the context engine and comprising explicitly defined types that define attributes and functions of code expressions (par. [0067] “the interpreter 154 executing the source code”, e.g. par. [0128] “tasks 1222 may include performing an action on a node … each node may contain attributes that describe the element”, par. [0126] “functions 140”);
generate, as part of executing the computer code utilizing the interpreter, a first context engine output by implementing the interpreter to interpret the computer code from the context engine to a first executor (par. [0068] “the interpreter 154 is configured to … compile the executable instructions 156”, par. [0039] “parse the machine-readable instruction into executable instructions”).
Buckley does not disclose:
dissecting, utilizing a context engine, the query from the client device into a set of individual sub-prompts;
generating, as part of executing the computer code utilizing the interpreter, a first context engine output that corresponds with a sub-prompt of the set of individual sub-prompts; and
generating, a second context engine output that corresponds with an additional sub-prompt of the set of individual sub-prompts
generate, as part of executing the computer code utilizing the interpreter, a first context engine output that corresponds with a sub-prompt of the set of individual sub-prompts.
Dasher teaches:
dissect, utilizing a context engine, the query from the client device into a set of individual sub-prompts (par. [0078] “generate … one or more portions of the prompt or query 101A, … such as a weather context sub-prompt”);
generating, a second context engine output that corresponds with an additional sub-prompt of the set of individual sub-prompts (par. [0078] “or more portions of the prompt or query”);
generate, as part of executing the computer code utilizing the interpreter, a first context engine output that corresponds with a sub-prompt of the set of individual sub-prompts (par. [0097] “processes the detailed prompt”).
It would have been obvious before the effective filing date of the claimed invention to dissect the query into a set of individual sub-prompts, and generate outputs corresponding to the sub-prompts. Those of ordinary skill in the art would have been motivated to do so “to improve the automatic content generation” (Dasher abstract).
Buckley and Dasher do not explicitly teach:
the interpreter comprising swappable logic that is interchangeable across multiple executors; and
generating, as part of executing the computer code utilizing the interpreter, a second context engine output by implementing the interpreter to interpret the computer code from the context engine to a second executor.
Guo teaches:
swappable logic that is interchangeable across multiple executors (e.g. par. [0081] “using modules of generic compiler … generate machine executable code for GPP … using modules of the domain-specific compiler … generate machine executable code for network processor”); and
generating a second output by implementing the interpreter to interpret the computer code from the context engine to a second executor (par. [0081] “using modules of generic compiler … generate machine executable code for GPP … using modules of the domain-specific compiler … generate machine executable code for network processor”, par. [0048] “compiled to generate unified code 110 to be executed by one or more GPPs and … target hardware specific code 112 to be executed by one or more network processors”).
It would have been obvious at the time of filing to use swappable logic to generated first and second outputs. Those of ordinary skill in the art would have been motivated to do so to provides flexibility and programmability (see e.g. Guo par. [0019]).
Claim 20: Buckley, Dasher and Guo teach the non-transitory computer-readable medium of claim 16, further storing instructions which, when executed by the at least one processor, cause the at least one processor to:
in response to a first interaction from the client device, generate, utilizing the interpreter, a first output (Buckley par. [0060] “e.g., “identifying my gaming tab””);
persist a state of the interpreter corresponding to the first output (Buckley par. [0060] “a history of textual data submitted by the user and textual responses provide by the task assistant 110”); and
generate, utilizing the large language model, a second output based on the first output indicated by persisting the state of the interpreter (Buckley par. [0060] “delete the browser tab 162 and display a textual response”).
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0021769 to Buckley et al. (Buckley) in view of US 2025/0085131 to Dasher et al. (Dasher) in view of US 2021/0357194 to Guo et al. (Guo) in view of US 2007/0282951 to Selimis et al. (Selimis).
Claim 3: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, but do not explicitly teach preventing the computer code from causing the interpreter to perform file system operations to read, write, or delete data stored for a user account.
Selimis teaches:
preventing computer code from performing file system operations to read, write, or delete data stored for a user account (par. [0126]-[0129] “prevent the following events: Reading form unspecified host-based files … Writing to any host-based file … Deleting any unauthorized host-based files”).
It would have been obvious at the time of filing to prevent the computer code from performing read, write or delete operations. Those of ordinary skill in the art would have been motivated to do so as a known means of enforcing a security policy which would have produced only the expected results (see e.g. Selimis par. [0125]).
Claim 13: Buckley, Dasher and Guo teach the system of claim 11, but do not teach storing instructions which, when executed by the at least one processor, cause the system to utilize the interpreter to prevent a downstream model from one or more of performing network operations, determining contextual environment data of the first executor and the second executor, or creating new subprocesses.
Selimis teaches:
preventing a downstream model from one or more of performing network operations, determining contextual environment data of the first executor and the second executor, or creating new subprocesses (par. [0130] Accessing or modifying system properties … Opening connections to a specified set of Guard addresses and port numbers … Creating new processes”)
It would have been obvious at the time of filing to prevent a downstream model from performing network operations, determining contextual environment data, or creating new subprocesses Those of ordinary skill in the art would have been motivated to do so as a known means of enforcing a security policy which would have produced only the expected results (see e.g. Selimis par. [0125]).
Claim(s) 4, 12, 14 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0021769 to Buckley et al. (Buckley) in view of US 2025/0085131 to Dasher et al. (Dasher) in view of US 2021/0357194 to Guo et al. (Guo) in view of US 2008/0282238 to Meijer et al. (Meijer).
Claim 4: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, but do not disclose executing the computer code utilizing the interpreter further comprises dynamically exposing types defined within the interpreter that correspond with the computer code for responding to the set of individual sub-prompts.
Meijer teaches:
utilizing an interpreter comprises dynamically exposing types defined within the interpreter that correspond with the computer code (par. [0040] “bind types to programmatic elements”).
It would have been obvious at the time of filing to expose types as claimed. Those of ordinary skill in the art would have been motivated to do so to, e.g., provide a “level of programmatic flexibility” (see e.g. Meijer par. [0005]-[0006]).
Claim 12: Buckley, Dasher and Guo teach the system of claim 11, but do not explicitly teach the interpreter cannot process code expressions outside of explicitly defined types that define attributes and functions of code expressions.
Meijer teaches:
an interpreter cannot process code expressions outside of explicitly defined types that define attributes and functions of code expressions (see e.g. par. [0025] “type check the code … to thwart compilation”).
It would have been obvious at the time of filing to prevent execution of code expressions outside of defined types. Those of ordinary skill in the art would have been motivated to do so to provide a level of security (see e.g. Meijer par. [0005]-[0006]).
Claim 14: Buckley, Dasher and Guo teach the system of claim 11, but do not teach instructions, which when executed by the at least one processor cause the system to dynamically expose a type defined within the interpreter by:
exposing called data corresponding to the type as part of executing a function of the computer code that refers to the called data; and
not exposing uncalled data corresponding to the type as part of executing the function of the computer code.
Meijer teaches dynamically exposing types by:
exposing called data corresponding to the type as part of executing a function of the computer code that refers to the called data (par. [0040] “the late binder component 410 can be invoked … bind the type to a method”); and
not exposing uncalled data corresponding to the type as part of executing the function of the computer code (par. [0040] If no such member exists … a runtime exception can be thrown”).
It would have been obvious at the time of filing to expose called data corresponding to a type and not expose uncalled data. Those of ordinary skill in the art would have been motivated to do so to provide a level of security (see e.g. Meijer par. [0005]-[0006]).
Claim 17: Buckley, Dasher and Guo teach the non-transitory computer-readable medium of claim 16, but do not teach storing instructions which, when executed by the at least one processor, cause the at least one processor to:
perform a first type checking process before runtime for executing the computer code to prevent the interpreter from accessing data outside of the explicitly defined types; and
perform a second type checking process at runtime for executing the computer code to prevent the interpreter from accessing data outside of the explicitly defined types.
Meijer teaches:
performing a first type checking process before runtime for executing the computer code to prevent the interpreter from accessing data outside of the explicitly defined types (par. [0025] “the static type check component 120”); and
performing a second type checking process at runtime for executing the computer code to prevent the interpreter from accessing data outside of the explicitly defined types (par. [0041] “The dynamic type check component 420”).
It would have been obvious at the time of filing to expose called data corresponding to a type and not expose uncalled data. Those of ordinary skill in the art would have been motivated to do so to provide a level of security (see e.g. Meijer par. [0005]-[0006]).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0021769 to Buckley et al. (Buckley) in view of US 2025/0085131 to Dasher et al. (Dasher) in view of US 2021/0357194 to Guo et al. (Guo) in view of US 12,360,748 to Zhang et al. (Zhang)
Claim 5: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, wherein the swappable logic of the interpreter facilitates:
utilizing the interpreter to execute the computer code that corresponds with the sub-prompt at a first executor (e.g. par. [0081] “generate machine executable code for GPP”); and
utilizing the interpreter to execute the computer code that corresponds with the additional sub-prompt at a second executor without retooling the interpreter (e.g. par. [0081] “using modules of the domain-specific compiler … generate machine executable code for network processor”).
Buckley, Dasher and Guo do not explicitly teach:
a first executor for testing; and
a second executor for validation.
Zhang teaches:
a first executor for testing (col. 7, lines 39-65 “validation engine 210”; and
a second executor for validation (col. 7, lines 39-65 “test environment 216”).
It would have been obvious at the time of filing to execute the code at validation and test executors. Those of ordinary skill in the art would have been motivated to do so as a known development/testing environment which would have produced only the expected results.
Claim(s) 7-8, 15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0021769 to Buckley et al. (Buckley) in view of US 2025/0085131 to Dasher et al. (Dasher) in view of US 2021/0357194 to Guo et al. (Guo) in view of US 2013/0151791 to Diestelhorst et al. (Diestelhorst).
Claims 7, and 15 and 18: Buckley, Dasher and Guo teach claims 1, 11 and 16, but do not teach persisting a state of the interpreter by:
storing, in a database during execution of the computer code, memory registry data associated with performing a function via the interpreter;
storing, in the database, a call stack comprising data defining a computer environment of an executor from among the multiple executors; and
in response to a state persisting event, storing, in the database, an instruction pointer indicating a segment of the computer code being executed by the interpreter.
Diestelhorst teaches:
storing, in a database during execution of the computer code, memory registry data associated with performing a function via the interpreter (par. [0036] “a rIP register value … a rAX register value … a rFLAGS register value … a rDX register value”);
storing, in the database, a call stack comprising data defining a computer environment of an executor from among the multiple executors (par. [0036] “call stack 500”); and
in response to a state persisting event, storing, in the database, an instruction pointer indicating a segment of the computer code being executed by the interpreter (par. [0036] “rIP … an instruction pointer”).
It would have been obvious to store state information as claimed. Those of ordinary skill in the art would have been motivated to do so as a known means of dealing with conflicting transactions which would have produced only the expected results.
Claim 8: Berkley, Guo and Diestelhorst teach the computer-implemented method of claim 7, further comprising resuming execution of the computer code after persisting the state by:
obtaining, from the database, the memory registry data, the call stack, and the instruction pointer (Diestelhorst par. [0040] “based on the continuation state stored in the call stack”); and
resuming execution of the computer code at the segment indicated by the instruction pointer (Diestelhorst par. [0040] “restore the transaction”).
Claim(s) 10 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0021769 to Buckley et al. (Buckley) in view of US 2025/0085131 to Dasher et al. (Dasher) in view of US 2021/0357194 to Guo et al. (Guo) in view of US 7,370,318 to Howe et al. (Howe).
Claims 10: Buckley, Dasher and Guo teach the computer-implemented method of claim 1, but do not explicitly teach performing an in-function garbage collection process as part of executing the computer code.
Howe teaches:
an in-function garbage collection process as part of executing the computer code (col. 10, lines 19-20 “a runtime environment that includes … garbage collection”).
It would have been obvious at the time of filing to perform in-function garbage collection. Those of ordinary skill in the art would have been motivated to do so as a known means of freeing up memory which would have produced only the expected results.
Claim 19: Buckley, Dasher and Guo teach the non-transitory computer-readable medium of claim 16, but do not explicitly disclose instructions which, when executed by the at least one processor, cause the at least one processor to perform an in-function garbage collection process as part of executing the computer code.
Howe teaches in-function garbage collection process as part of executing the computer code ((col. 10, lines 19-20 “a runtime environment that includes … garbage collection”).
It would have been obvious at the time of filing to perform in-function garbage collection. Those of ordinary skill in the art would have been motivated to do so as a known means of freeing up memory which would have produced only the expected results.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199
Prosecution Insights