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 .
This is the initial office action based on the application filed on August 20th, 2024, which claims 1-20 are presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, claim 9 and 17 are in independent form.
Priority
4. This application has a priority CHINA 202210179833.3 02/25/2022. This application is a CON of PCT/CN2023/075175 02/09/2023.
Information Disclosure Statement
5. Information disclosure statement filed on 08/20/2024, 06/04/2025 and 02/20/2026, have been reviewed and considered by Examiner.
The Office's Note:
6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
7. Claim 8 and claim 16 recite the limitation "the first time" on line 4 and the limitation "the second time" on line 7. There are insufficient antecedent basis for these limitations in the claim.
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.
8. Claims 1-2, 6-10 and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Fourer (“AMPL: A Modeling Language for Mathematical Programming – hereinafter Fourer – IDS of records) and further in view of Proctor (US 20170139680 – hereinafter Proctor).
Claim 1 is rejected, Fourer teaches a data modeling method, comprising (Fourer, p. xviii, 2nd par. "AMPL offers an interactive command environment for setting up and solving mathematical programming problems"):
acquiring a model file and a data file(Fourer, p. 206 "A model command reads
declarations from a file and adds them to the current model; a data command reads data statements from a file to supply values for components already in the current model". P.201, model diet.mod, data diet2a.dat.),
the model file comprising code for modeling a to-be-solved problem corresponding to a target application system (Fourer, p. 206 "If a model declares more than one objective function, AMPL by default passes all of them to the solver")),
the code comprising a plurality of parameters (Fourer, p.7 "From now on, we assume models are given in the algebraic form. As always, reality is rarely so simple, so most models will have more sets, parameters and variables, and more complicated objectives and constraints"), and
the data file comprising parameter values corresponding to part of the parameters (Fourer, p. 143 "how AMPL' s data command is used, in conjunction with data statements, to read data values from files such as those whose names end in .dat throughout our examples");
generating a model instance corresponding to the target segment of the code according to the parameter values corresponding to the unassigned parameters inputted and parameter values corresponding to assigned parameters in the target segment of the code (Fourer, Sec. 11 .2 Setting up and solving models and data, p. 206 "The solve command causes a description of the optimization problem to be sent to a solver").
Fourer does not explicitly teach
in response to a running operation triggered for a target segment of the code in the model file and a determination that the target segment of the code comprising unassigned parameters, displaying prompt information corresponding to the unassigned parameters for prompting input of parameter values corresponding to the unassigned parameters; and
However, Proctor teaches
in response to a running operation triggered for a target segment of the code in the model file and a determination that the target segment of the code comprising unassigned parameters, displaying prompt information corresponding to the unassigned parameters for prompting input of parameter values corresponding to the unassigned parameters(Proctor, US 20170139680, fig. 4 and fig. 5 and para [0042-0043], At 410, the computing device receives input selecting a task. At 420, the task is analyzed to determine whether one or more endpoints are required for the task to interact with another computing device. If the task requires one or more endpoints, then at 430 the task is checked for endpoints (e.g., it is determined whether one or more endpoints are specified). If the task (or file) does not include (or is missing) an endpoint, then the user may be prompted to provide one or more endpoints, wherein one or more endpoints are received at 440. At 450, one or more endpoints may be checked for validity (e.g., it is determined whether endpoint should be modified). If, for example, an endpoint has a path or an operating system that is not compatible with a target system to which the endpoint is referring, then modification may be required. At 460, the computing device may then prompt a user to provide a modification to the endpoint and/or one or more modified/updated endpoints or, alternatively, the computing device may dynamically update the endpoints based upon the current path and/or operating system information (for example) which may be utilized to determine the endpoint. FIG. 5 is a flowchart of an embodiment of a method 500 of task creation in a computing device (for example, a server, client, mobile device, etc.). At 510, the computing device receives a task creation request. At 520, the computing device receives a task type. At 530, a determination is made as to whether the task is a remote task. If the task is determined to be a remote task, then the computing device may prompt a user to provide endpoints, and receive an endpoint at 540. At 550, it is checked to determine whether there is another endpoint not yet considered. If it is determined that there is another endpoint, the endpoint is received at 540. This process may be repeated until each endpoint has been received. If the task is a local task (e.g., a task that is not associated with an endpoint), or once the endpoints have been received, then the computing device determines if the task has one or more parameters at 560.); and
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Proctor into Fourer to receive an instruction to define a configurable automation task based on structured data. One or more parameter definitions associated with the task is received. A first user interface is generated based on the one or more parameter definitions. One or more parameter definition values are received. A script in accordance with the parameters is generated based on the instruction, parameter definitions and values. A second user interface configured to integrate the generated script with one or more remote execution capabilities is utilized as suggested by Proctor (See abstract and summary).
The Office notes that Proctor also teaches
generating a model instance corresponding to the target segment of the code according to the parameter values corresponding to the unassigned parameters inputted and parameter values corresponding to assigned parameters in the target segment of the code(Proctor, fig. 4 and fig. 5, para [0042], At 530, a determination is made as to whether the task is a remote task. If the task is determined to be a remote task, then the computing device may prompt a user to provide endpoints, and receive an endpoint at 540. At 550, it is checked to determine whether there is another endpoint not yet considered. If it is determined that there is another endpoint, the endpoint is received at 540. This process may be repeated until each endpoint has been received. If the task is a local task (e.g., a task that is not associated with an endpoint), or once the endpoints have been received, then the computing device determines if the task has one or more parameters at 560. Para [0043], The computing system receives one or more parameter properties at 570. For example, the computing system may receive a parameter name/id (such as $1), a parameter description (such as descriptive text), a parameter type (such as a drop-down list), and/or a template value (such as multiple-choice selection options). At 580, once the parameter properties have been received, it is determined if there are additional tasks not yet considered. If it is determined that there are more tasks at 580, then at 520 another task is received. At 584, once the tasks have been processed, a user interface is generated. At 588, the user interface may receive input specifying parameter values. The parameter values may be received from a user, which may be different from the user providing the parameter definitions. At 590 a script may be generated based upon the received parameter values.)
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Fourer and Proctor teach the method according to claim 1, further comprising: calling a solver corresponding to the model instance to solve variables of the model instance (Fourer, Sec. 11 .2 Setting up and solving models and data, p. 206 "The solve command causes a description of the optimization problem to be sent to a solver").
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Fourer and Proctor teach method according to claim 1, further comprising: storing the unassigned parameters and the parameter values corresponding to the unassigned parameters in a target storage space (Proctor, para [0042-0043], The computing system receives one or more parameter properties at 570. For example, the computing system may receive a parameter name/id (such as $1), a parameter description (such as descriptive text), a parameter type (such as a drop-down list), and/or a template value (such as multiple-choice selection options). At 580, once the parameter properties have been received, it is determined if there are additional tasks not yet considered. If it is determined that there are more tasks at 580, then at 520 another task is received. At 584, once the tasks have been processed, a user interface is generated. At 588, the user interface may receive input specifying parameter values. The parameter values may be received from a user, which may be different from the user providing the parameter definitions. At 590 a script may be generated based upon the received parameter values.).
Claim 7 is rejected for the reasons set forth hereinabove for claim 6, Fourer and Proctor teach method according to claim 6, wherein the assigned parameters comprise parameters having values that are directly given or parameters for which corresponding parameter value reading paths in the data file are given(Fourer, Sec. 11 .2 Setting up and solving models and data, p. 206 "The solve command causes a description of the optimization problem to be sent to a solver". Fourer, Sec. 9.5 (p. 163), "In its simplest form, read specifies a list of parameters and a file from which their values are to be read"); and
generating the model instance corresponding to the target segment of the code comprises:
in response to a confirmation of completion of an assignment operation of the unassigned parameters triggered, in a process of executing the target segment of the code for the second time:
for the unassigned parameters, loading the parameter values corresponding to the unassigned parameters from the target storage space(Proctor, fig. 4 and fig. 5, para [0042], At 530, a determination is made as to whether the task is a remote task. If the task is determined to be a remote task, then the computing device may prompt a user to provide endpoints, and receive an endpoint at 540. At 550, it is checked to determine whether there is another endpoint not yet considered. If it is determined that there is another endpoint, the endpoint is received at 540. This process may be repeated until each endpoint has been received. If the task is a local task (e.g., a task that is not associated with an endpoint), or once the endpoints have been received, then the computing device determines if the task has one or more parameters at 560. Para [0043], The computing system receives one or more parameter properties at 570. For example, the computing system may receive a parameter name/id (such as $1), a parameter description (such as descriptive text), a parameter type (such as a drop-down list), and/or a template value (such as multiple-choice selection options). At 580, once the parameter properties have been received, it is determined if there are additional tasks not yet considered. If it is determined that there are more tasks at 580, then at 520 another task is received. At 584, once the tasks have been processed, a user interface is generated. At 588, the user interface may receive input specifying parameter values. The parameter values may be received from a user, which may be different from the user providing the parameter definitions. At 590 a script may be generated based upon the received parameter values.);
for the parameters for which corresponding parameter value reading paths in the data file are given, loading the corresponding parameter values from the data file according to the parameter value reading paths(Fourer, Sec. 11 .2 Setting up and solving models and data, p. 206 "The solve command causes a description of the optimization problem to be sent to a solver"); and
generating the model instance corresponding to the target segment of the code according to the loaded parameter values corresponding to the unassigned parameters and parameter values corresponding to the assigned parameters(Fourer, Sec. 11 .2 Setting up and solving models and data, p. 206 "The solve command causes a description of the optimization problem to be sent to a solver").
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Fourer and Proctor teach method according to claim 1, further comprising: in response to the running operation triggered for the target segment of the code and a determination that the target segment of the code not comprising the unassigned parameters in a process of executing the target segment of the code for the first time, generating the model instance corresponding to the target segment of the code based on an obtained parameter values corresponding to the assigned parameters in the target segment of the code in a process of executing the target segment of the code for the second time(Proctor, para [0042-0043], The computing system receives one or more parameter properties at 570. For example, the computing system may receive a parameter name/id (such as $1), a parameter description (such as descriptive text), a parameter type (such as a drop-down list), and/or a template value (such as multiple-choice selection options). At 580, once the parameter properties have been received, it is determined if there are additional tasks not yet considered. If it is determined that there are more tasks at 580, then at 520 another task is received. At 584, once the tasks have been processed, a user interface is generated. At 588, the user interface may receive input specifying parameter values. The parameter values may be received from a user, which may be different from the user providing the parameter definitions. At 590 a script may be generated based upon the received parameter values.).
As per claim 9, this is the apparatus claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 10, this is the apparatus claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the apparatus claim to method claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the apparatus claim to method claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the apparatus claim to method claim 8. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above.
9. Claims 3-5, 11-13 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fourer (“AMPL: A Modeling Language for Mathematical Programming – hereinafter Fourer – IDS of records), in view of Proctor (US 20170139680 – hereinafter Proctor) and further in view of McCourtney (US 20180246738 – hereinafter McCourtney).
With respect to claim 3, Fourer and Proctor do not teach all limitation of claim 3.
However, McCourtney teaches
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Fourer, Proctor and McCourtney teach method according to claim 1, wherein displaying the prompt information corresponding to the unassigned parameters comprises (Proctor, fig. 4 and fig. 5 and para [0042-0043]):
in a process of executing the target segment of the code for the first time, determining whether a row of the code comprises the unassigned parameters in a row by row manner (McCourtney, US 20180246738, para [0026], Using the domain-specific programming language described herein, references to external entities (not in memory) as variables may be used. For example, by defining mything=this-instance, this-instance would be resolved to a URL or other identifier of a running virtual computer, as opposed to an address in memory.);
in response to a determining that the unassigned parameters are comprised in the row, marking the unassigned parameters with a set character (McCourtney, para [0026]. Para [0069-0072], In an exemplary operation of programs in runtime environment 20, a user may compile and execute program 152A, which may include a variable that references an entity and causes the entity to be created. For example, the created entity may include, without limitation, a compute instance at cloud service provider 160. In other words, using the domain-specific language described herein, instantiation of a variable may refer to, and cause to be created, a corresponding compute instance. In an implementation, the source code for program 152A may specify/define the cloud instance to which the variable is referenced or the cloud instance may be defined by a configurable parameter setting. Upon compilation, SIS 120 may store the variable, its reference, its state, how the compute instance may be used, and/or other state information using entity state information database 130.);
in a response to a determination that the target segment of the code is completely executed, acquiring all the unassigned parameters comprised in the target segment of the code according to the marking character (Proctor, fig. 4 and fig. 5 and para [0042-0043], At 410, the computing device receives input selecting a task. At 420, the task is analyzed to determine whether one or more endpoints are required for the task to interact with another computing device. If the task requires one or more endpoints, then at 430 the task is checked for endpoints (e.g., it is determined whether one or more endpoints are specified). If the task (or file) does not include (or is missing) an endpoint, then the user may be prompted to provide one or more endpoints, wherein one or more endpoints are received at 440. At 450, one or more endpoints may be checked for validity (e.g., it is determined whether endpoint should be modified). If, for example, an endpoint has a path or an operating system that is not compatible with a target system to which the endpoint is referring, then modification may be required. At 460, the computing device may then prompt a user to provide a modification to the endpoint and/or one or more modified/updated endpoints or, alternatively, the computing device may dynamically update the endpoints based upon the current path and/or operating system information (for example) which may be utilized to determine the endpoint. FIG. 5 is a flowchart of an embodiment of a method 500 of task creation in a computing device (for example, a server, client, mobile device, etc.). At 510, the computing device receives a task creation request. At 520, the computing device receives a task type. At 530, a determination is made as to whether the task is a remote task. If the task is determined to be a remote task, then the computing device may prompt a user to provide endpoints, and receive an endpoint at 540. At 550, it is checked to determine whether there is another endpoint not yet considered. If it is determined that there is another endpoint, the endpoint is received at 540. This process may be repeated until each endpoint has been received. If the task is a local task (e.g., a task that is not associated with an endpoint), or once the endpoints have been received, then the computing device determines if the task has one or more parameters at 560.); and
displaying the prompt information corresponding to all the unassigned parameters(Proctor, fig. 4 and fig. 5, para [0042], At 530, a determination is made as to whether the task is a remote task. If the task is determined to be a remote task, then the computing device may prompt a user to provide endpoints, and receive an endpoint at 540. At 550, it is checked to determine whether there is another endpoint not yet considered. If it is determined that there is another endpoint, the endpoint is received at 540. This process may be repeated until each endpoint has been received. If the task is a local task (e.g., a task that is not associated with an endpoint), or once the endpoints have been received, then the computing device determines if the task has one or more parameters at 560.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate McCourtney into Fourer and Proctor to facilitate compilation, type checking and debugging while authoring programs against external entities as opposed to requiring testing to be performed to find errors and bugs. Ensures that code being executed on its cloud computing system meets various computing policies and that the code is not being sent to the system for malicious purpose or intent by compiling the user-generated code on the cloud operating system as suggested by McCourtney (See abstract and summary).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Fourer, Proctor and McCourtney teach method according to claim 3, wherein the assigned parameters comprise parameters having values that are directly given or parameters for which corresponding parameter value reading paths in the data file are given; and in the process of executing the target segment of the code for the first time, an operation of loading the corresponding parameter values according to the parameter value reading paths is not executed(Proctor, para [0042-0043], The computing system receives one or more parameter properties at 570. For example, the computing system may receive a parameter name/id (such as $1), a parameter description (such as descriptive text), a parameter type (such as a drop-down list), and/or a template value (such as multiple-choice selection options). At 580, once the parameter properties have been received, it is determined if there are additional tasks not yet considered. If it is determined that there are more tasks at 580, then at 520 another task is received. At 584, once the tasks have been processed, a user interface is generated. At 588, the user interface may receive input specifying parameter values. The parameter values may be received from a user, which may be different from the user providing the parameter definitions. At 590 a script may be generated based upon the received parameter values. Fourer, Sec. 9.5 (p. 163), "In its simplest form, read specifies a list of parameters and a file from which their values are to be read").
Claim 5 is rejected for the reasons set forth hereinabove for claim 3, Fourer, Proctor and McCourtney teach method according to claim 3, further comprising: displaying prompt information corresponding to the assigned parameters (Proctor, para [0042-0043], The computing system receives one or more parameter properties at 570. For example, the computing system may receive a parameter name/id (such as $1), a parameter description (such as descriptive text), a parameter type (such as a drop-down list), and/or a template value (such as multiple-choice selection options). At 580, once the parameter properties have been received, it is determined if there are additional tasks not yet considered. If it is determined that there are more tasks at 580, then at 520 another task is received. At 584, once the tasks have been processed, a user interface is generated. At 588, the user interface may receive input specifying parameter values. The parameter values may be received from a user, which may be different from the user providing the parameter definitions. At 590 a script may be generated based upon the received parameter values.).
As per claim 11, this is the apparatus claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the apparatus claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the apparatus claim to method claim 5. Therefore, it is
As per claim 19, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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 5712723759. 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.
/DUY KHUONG T NGUYEN/Primary Examiner, Art Unit 2199
Prosecution Insights