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 .
Remarks
The present application having Application No. 18/473,986 filed on 9/25/2023.
Claims 1-20 are currently pending.
Examiner Notes
Examiner cites particular columns 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 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 are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description: Paragraph (0018) in the specification recites having reference sign 100 but reference sign 100 is not present in Fig. 1.. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 3, Line 1 objected to because of the following informalities: "method claim 1" should read "method of claim 1". Appropriate correction is required.
Claim 8, Line 9 objected to because of the following informalities: "mapping with a first as a key" should read "mapping with a first indicator as a key". Appropriate correction is required.
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, 11, 18, and 19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 13, 8, and 11 of copending Application No. 18/473,979 in view of Hiller et al. (US 20210103863 A1) (hereinafter Hiller).
This is a provisional nonstatutory double patenting rejection.
Claims 1, 11, 18, and 19 are compared to claims 1, 13, 8, and 11 of the reference application in view of Hiller in the following table:
Present Application
18/473,986
Co-pending US Application No:
18/473,979
Claim 1: A method for configuring a workflow to create or manage a specified environment, the method residing as instructions on a non-transitory computer-readable medium, the instructions being configured to cause a processor to perform operations including: receiving an input including a first set of parameters associated with one or more environments other than the specified environment and a second set of parameters associated with the specified environment; generating a payload based on the input; validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload.
Claim 1: A method for configuring a workflow to create or manage a specified environment, the method residing as instructions on a non-transitory computer-readable medium, the instructions being configured to cause a processor to perform operations including: configuring a first set of parameters associated with one or more environments other than the specified environment; configuring a second set of parameters associated with the specified environment; and executing an automation service based on the first and second sets of parameters.
The reference application does not expressly disclose generating a payload based on the input; validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload.
However, Hiller discloses generating a payload based on the input (e.g. Hiller: (0063) discloses when the outcomes of the workflow are defined, a workflow template is created that specifies the sequence of events (e.g., operations, decisions, etc.) that will produce the outcomes (step 404). A workflow template, as used herein, is a data object that defines the attributes of a workflow to facilitate adaptation and execution of the workflow in various distinct execution environments. (0065) discloses the workflow template will comprise various mechanisms that facilitate configurability over the environments. One such mechanism embeds variables in the data object of the workflow template to allow the values assigned to those variables to serve as environment-specific parameters.); validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload (e.g. Hiller: (0076) discloses when workflow analyzer 314 has received both user and system responses, the workflow template is validated (operation 530). The validation operation is a foundational operation of the workflow template emulation as it verifies that the workflow template, within the context of its then-current environment-specific parameter settings, is configured to run in the target execution environment. As merely examples, workflow analyzer 314 will validate the existence, status, and permissions of any users (e.g., assignees, etc.) and/or content objects (e.g., files, folders, etc.) associated with the workflow template. As earlier mentioned, any issues with run-time variables may not be detected until the workflow is executed. If validation errors are detected, an error alert is issued to user 301.sub.M (message 532). In this case, user 301.sub.M will need to repeat certain activities (e.g., operation 522 and/or message 524) to address the validation errors. When there are no validation errors remaining, workflow analyzer 314 issues a successful adaptation alert to user 301.sub.M (message 534) and activates the validated instance of the environment-specific workflow (message 536). The validated instance of the environment-specific workflow may be subsequently triggered by events that occur in content management system 104. (0058) discloses a workflow execution engine 318 can facilitate activation and ongoing execution of the resulting environment-specific instance of the subject workflow in execution environment 102.sub.M.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of validating a template as taught by Hiller into the reference application because the combined technical solution enables more efficient workflow processing and reducing computing costs. (See Hiller: (0076)).
Claim 11: A system for configuring a workflow to create or manage a specified environment, the system comprising: a memory; a processor, which when executing instructions from the memory, is configured to perform operations including: receiving an input including a first set of parameters associated with one or more environments other than the specified environment and a second set of parameters associated with the specified environment; generating a payload based on the input; validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload.
Claim 13: A system for configuring a workflow to create or manage a specified environment, the system comprising: a memory; a processor, which when executing instructions from the memory, is configured to perform operations including: configuring a first set of parameters associated with one or more environments other than the specified environment; configuring a second set of parameters associated with the specified environment; and executing an automation service based on the first and second sets of parameters.
The reference application does not expressly disclose generating a payload based on the input; validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload.
However, Hiller discloses generating a payload based on the input; validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload (e.g. Hiller: (0036) (0037) (0063) (0065) (0076). See mapping for claim 1 above.).
Claim 18: The system of claim 11, wherein the automation-as-a-service workflow is a single execution point service.
Claim 18: The system of claim 13, wherein the first set of parameters and the second set of parameters are combined as a single workflow during the executing.
The co-pending application discloses combining the first and second sets of parameters into a single workflow. This combination results in the workflow being executed as a single unit of work. This inherently implies that the single workflow is a single execution point service. Thus, claim 18 of the present application is not patently distinct from claim 18 of the co-pending application.
Claim 19: The system of claim 11, wherein the first set of parameters or the second set of parameters is formatted as a JSON file.
The co-pending application does disclose a first set of parameters and second set of parameters (See mapping for claim 13 above).
The co-pending application does not expressly disclose the first set of parameters or the second set of parameters is formatted as a JSON file.
However, Hiller discloses the first set of parameters or the second set of parameters is formatted as a JSON file (e.g. Hiller: (0027) discloses a workflow is codified in a structured form (e.g., a JSON-based template) having one or more environment-specific variables. In certain embodiments, a workflow configuration requirement is addressed by assigning a value to an environment-specific variable. In certain embodiments, a workflow configuration requirement can be addressed and resolved either with or without human interaction. (0065) discloses the data object underlying a workflow template 347.sub.1 created for workflow 106.sub.1 comprises a set of empty variables 424, a set of default variables 426, and a set of run-time variables 428. As an example, such variables may be key-value pairs in a JSON object. Empty variables 424 are variables whose values (e.g., file name, folder name, task assignee, task message, etc.) can be set at the time the workflow template 347.sub.1 is being adapted to a new execution environment.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of JSON template files as taught by Hiller into the reference application because the combined technical solution enables efficient parsing of information and performance of workflows. (See Hiller: (0055)).
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.
Claim(s) 1-3, 11-13, 18 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cardenas et al. (US 20220300340 A1) (hereinafter Cardenas) in view of Hiller et al. (US 20210103863 A1) (hereinafter Hiller).
As per claim 1 Cardenas discloses a method for configuring a workflow to create or manage a specified environment, the method residing as instructions on a non-transitory computer-readable medium, the instructions being configured to cause a processor to perform operations including (e.g. Cardenas: (0008) discloses one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform various operations. The operations in this example include receiving first data via an interface, and determining a cloud environment template based on the first data. The operations in this example further include receiving second data via the interface, and updating the cloud environment template based on the second data, to create an updated cloud environment template. Additionally, the operations in this example include receiving a command via the interface to provision a cloud-based computing environment associated with the updated cloud environment template, and in response to receiving the command, executing an application configured to deploy the cloud-based computing environment, via a cloud service provider, based on the updated cloud environment template.): receiving an input including a first set of parameters [ ] and a second set of parameters associated with the specified environment (e.g. Cardenas: (0023) discloses the non-variabilized templates stored in the template data store 112 may include placeholder variables, and the variabilized template generator 108 may use pattern matching to replace the placeholder variables with the corresponding variable data received from the environment configuration interface 106. In such cases, the placeholder variables may have specific unique patterns that identify the placeholders as variables to be replaced, and do not occur within the additional constant environment configuration data in the template. (0020) discloses a GUI 200 is shown corresponding to an environment configuration interface 106 configured to allow operators of an organization to quickly create and provision new cloud environments for the organization. In this example, the current display screen 202 of the GUI 200 includes a number of fields prompting the operator to provide the variable configuration data needed to create and deploy the new environment. As shown in this example, the display screen 202 includes relatively few fields. In this case, it may be assumed that most of the cloud infrastructure and configuration data for creating new cloud environments for this organization are non-variable, and therefore need not be included in the GUI 200. Instead, the GUI 200 may be configured to request and receive only the variable configuration data from the operator that is required to create a new and unique cloud environment for the organization. As shown in this example, the display screen 202 of the GUI 200 may include various user interface fields into which the operator may provide an account name, project name, associated email address, environment type (e.g., Research, Testing, or Production), a listing of authorized credentials and/or administrator aliases associated with the new environment, a cloud service provider for the new environment, a cloud region, a tenant identifier, a listing of network constructs (e.g., IP addresses), and a service control listing. (0022) discloses after receiving the variable data via the environment configuration interface 106, the cloud environment generator 104 may use the variabilized template generator 108 to create one or more variabilized templates. For example, the variabilized template generator 108 may retrieve a non-variabilized template from the template data store 112, and incorporate the variable data received via the interface 106 into the template, to make a variabilized template.). Cardenas discloses non-variablize templates that may include placeholder values. The template is inherently a set of parameters. Cardenas discloses an operator is able to specify fields to fit their business needs for the new environment. These fields inherently imply a set of parameters. Cardenas further discloses the fields are received and then combined with the template. Thus, Cardenas discloses a first set of parameters and a second set of parameters associated with the specified environment; and executing an automation service based on the first and second sets of parameters (e.g. Cardenas: (0022) discloses after receiving the variable data via the environment configuration interface 106, the cloud environment generator 104 may use the variabilized template generator 108 to create one or more variabilized templates. For example, the variabilized template generator 108 may retrieve a non-variabilized template from the template data store 112, and incorporate the variable data received via the interface 106 into the template, to make a variabilized template. (0044) discloses the cloud environment generator 104 may initiate a CI/CD pipeline (automation service), and at operation 514 the cloud environment generator 104 may use the CI/CD pipeline to execute the files created within the repository. Based on the execution of the files within the repository (e.g., IaC configuration files based on the variabilized templates) (based on the parameters), the cloud provisioning system 110 causes provisioning instructions to be transmitted to one or more cloud service providers in operation 516, deploying the cloud environment. As noted above, in some cases deployment of the cloud environment may correspond to merge of configuration files from the repository into a main branch of the organization within a public cloud environment. Cardenas discloses a CI/CD pipeline which inherently implies an automation service. Cardenas further discloses the pipeline executes based on the variabilized template that holds the set of parameters. Thus, Cardenas discloses executing an automation service based on the first and second set of parameters.).
Cardenas does not expressly disclose associated with one or more environments other than the specified environment. generating a payload based on the input; validating the generated payload; and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload.
However, Hiller discloses receiving an input including a first set of parameters associated with one or more environments other than the specified environment (e.g. Hiller: (0036) discloses the operation of workflow 106.sub.11 is established in execution environment 102.sub.1, enterprise 101.sub.1 publishes a sharable instance (e.g., workflow 106.sub.1) of workflow 106.sub.11 to a set of shared workflows 107 hosted in an exchange 110 managed by content management system 104 (operation 2). (0037) discloses at some later moment in time, enterprise 101.sub.2 may be seeking a workflow having characteristics that match the characteristics of workflow 106.sub.1. After browsing the shared workflows 107 hosted by exchange 110, enterprise 101.sub.2 selects the workflow 106.sub.1 to execute in execution environment 102.sub.2 (operation 3). As shown, workflow 106.sub.1 is uploaded to execution environment 102.sub.2 as an initial local instance (e.g., workflow 106.sub.12A) of the workflow. Workflow 106.sub.12A is analyzed to identify any environment-specific parameters associated with the workflow (operation 4). For example, execution of workflow 106.sub.12A can be emulated by traversing the workflow and identifying enterprise-specific parameters in the workflow that are in conflict with the local environment attributes (e.g., file and folder structures, usernames, and roles, etc.). The outcome of the foregoing analysis and/or emulation is an instance (e.g., workflow 106.sub.12B) of workflow 106.sub.1 that has some or all environment-specific parameters identified (e.g., marked, flagged, etc.) for modification. Hiller discloses a workflow is generated in one environment. Hiller further discloses the workflow is then used to create a template workflow to be uploaded to a shared exchange. Hiller further discloses the workflow can be discovered by another user and selected to execute in a new environment. This inherently implies the values in the workflow template are common to another environment other than the specified environment. Thus, Hiller parameters associated with one or more environments other than the specified environment.); generating a payload based on the input (e.g. Hiller: (0063) discloses when the outcomes of the workflow are defined, a workflow template is created that specifies the sequence of events (e.g., operations, decisions, etc.) that will produce the outcomes (step 404). A workflow template, as used herein, is a data object that defines the attributes of a workflow to facilitate adaptation and execution of the workflow in various distinct execution environments. (0065) discloses the workflow template will comprise various mechanisms that facilitate configurability over the environments. One such mechanism embeds variables in the data object of the workflow template to allow the values assigned to those variables to serve as environment-specific parameters. Under BRI, a payload is a file that contains data and/or a sequence of steps. The workflow template is a file that contains data that defines how the workflow should be executed. Thus, Hiller discloses generating a payload.); validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload (e.g. Hiller: (0076) discloses when workflow analyzer 314 has received both user and system responses, the workflow template is validated (operation 530). The validation operation is a foundational operation of the workflow template emulation as it verifies that the workflow template, within the context of its then-current environment-specific parameter settings, is configured to run in the target execution environment. As merely examples, workflow analyzer 314 will validate the existence, status, and permissions of any users (e.g., assignees, etc.) and/or content objects (e.g., files, folders, etc.) associated with the workflow template. As earlier mentioned, any issues with run-time variables may not be detected until the workflow is executed. If validation errors are detected, an error alert is issued to user 301.sub.M (message 532). In this case, user 301.sub.M will need to repeat certain activities (e.g., operation 522 and/or message 524) to address the validation errors. When there are no validation errors remaining, workflow analyzer 314 issues a successful adaptation alert to user 301.sub.M (message 534) and activates the validated instance of the environment-specific workflow (message 536). The validated instance of the environment-specific workflow may be subsequently triggered by events that occur in content management system 104. (0058) discloses a workflow execution engine 318 can facilitate activation and ongoing execution of the resulting environment-specific instance of the subject workflow in execution environment 102.sub.M. Hiller discloses a workflow analyzer will check different attributes of a workflow to validate the workflow. Hiller further discloses once the workflow is validated, it is then activated by the workflow execution engine. Thus, Hiller discloses validating the generated payload, and executing, in response to the generated payload being successfully validated, the workflow as an automation-as-a-service workflow using the validated generated payload.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of validating a template as taught by Hiller into the template configuration Cardenas because the combined technical solution enables more efficient workflow processing because it allows for pre-emptive variable checking and prevention of execution errors resulting in reduced computing costs. (See Hiller: (0076)).
As per claim 2, the combination of Cardenas and Hiller disclose the method of claim 1 (See rejection to claim 1 above), wherein the receiving further includes at least one of (i) reading arguments, (ii) setting class variables, and (iii) logging an initial state (e.g. Hiller: (0072) discloses environment-specific variables are included in workflow templates to facilitate adaptation of the workflow templates to various execution environments. The environment-specific variables are often codified in the data object as key-value pairs wherein the key is the environment-specific variable and the value is a respective environment-specific parameter. A particular workflow template can be adapted to an execution environment at least in part by setting the values associated with the environment-specific variables to environment-specific parameters that correspond to the execution environment. In some cases, workflow analyzer 314 may be provided the key names to the environment-specific variables that are included in the workflow templates to facilitate discovery of the environment-specific variables.).
As per claim 3, the method claim 1 (See rejection to claim 1 above), wherein the operations further includes creating a log upon the generated payload being unsuccessfully validated (e.g. Hiller: (0076) discloses when workflow analyzer 314 has received both user and system responses, the workflow template is validated (operation 530). The validation operation is a foundational operation of the workflow template emulation as it verifies that the workflow template, within the context of its then-current environment-specific parameter settings, is configured to run in the target execution environment. As merely examples, workflow analyzer 314 will validate the existence, status, and permissions of any users (e.g., assignees, etc.) and/or content objects (e.g., files, folders, etc.) associated with the workflow template. As earlier mentioned, any issues with run-time variables may not be detected until the workflow is executed. If validation errors are detected, an error alert is issued to user 301.sub.M (message 532). In this case, user 301.sub.M will need to repeat certain activities (e.g., operation 522 and/or message 524) to address the validation errors. When there are no validation errors remaining, workflow analyzer 314 issues a successful adaptation alert to user 301.sub.M (message 534) and activates the validated instance of the environment-specific workflow (message 536). The validated instance of the environment-specific workflow may be subsequently triggered by events that occur in content management system 104. Hiller discloses an alert is sent when the workflow analyzer finds an error within the values of a workflow template. Thus, Hiller discloses creating a log upon the generated payload being unsuccessfully validated.).
As per claim 11, the combination of Cardenas and Hiller disclose a system for configuring a workflow to create or manage a specified environment, the system comprising: a memory; a processor, which when executing instructions from the memory (e.g. Cardenas: (0008) discloses a computer system comprises one or more processors, and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform various operations. The operations in this example include receiving first data via an interface, and determining a cloud environment template based on the first data. The operations in this example further include receiving second data via the interface, and updating the cloud environment template based on the second data, to create an updated cloud environment template. Additionally, the operations in this example include receiving a command via the interface to provision a cloud-based computing environment associated with the updated cloud environment template, and in response to receiving the command, executing an application configured to deploy the cloud-based computing environment, via a cloud service provider, based on the updated cloud environment template.). The remaining limitations corresponds to the method steps recited in claim 1, which are taught by the combination of Cardenas and Hiller as discussed above in the rejection of claim 1.
As per claim(s) 12-13, these are system claims having similar limitations as cited in method claim(s) 2-3. Thus, claim(s) 12-13 are also rejected under the same rationale as cited in the rejection of rejected claim(s) 2-3.
As per claim 18, the combination of Cardenas and Hiller disclose the system of claim 11 (See rejection to claim 11 above), wherein the automation-as-a-service workflow is a single execution point service (e.g. Cardenas: (0017) discloses the cloud environment generator 104 includes an environment configuration interface 106, a variabilized template generator 108, and a cloud provisioning system 110. (0022) discloses after receiving the variable data via the environment configuration interface 106, the cloud environment generator 104 may use the variabilized template generator 108 to create one or more variabilized templates. For example, the variabilized template generator 108 may retrieve a non-variabilized template from the template data store 112, and incorporate the variable data received via the interface 106 into the template, to make a variabilized template. (0025) discloses to provision the requested cloud environment, the cloud provisioning system 110 may execute the templates in the repository, causing cloud provisioning instructions to be transmitted to the appropriate cloud service provider 116 or 118. As noted above, in some examples the templates may include executable code that can be executed directly by the cloud provisioning system 110. Cardenas discloses a cloud environment generator which includes the environment configuration interface, variablized template generator, and cloud provisioning system. Cardenas discloses the generator combines a non-variablized template with variable data provided by the interface and is then executed by the cloud provisioning system. The non-variablized template is combined with variable data into a single variablized template. Thus, Cardenas discloses the automation-as-a-service workflow is a single execution point service.).
As per claim 19, the combination of Cardenas and Hiller disclose the system of claim 11 (See rejection to claim 11 above), wherein the first set of parameters or the second set of parameters is formatted as a JSON file (e.g. Hiller: (0027) discloses a workflow is codified in a structured form (e.g., a JSON-based template) having one or more environment-specific variables. In certain embodiments, a workflow configuration requirement is addressed by assigning a value to an environment-specific variable. In certain embodiments, a workflow configuration requirement can be addressed and resolved either with or without human interaction. (0065) discloses the data object underlying a workflow template 347.sub.1 created for workflow 106.sub.1 comprises a set of empty variables 424, a set of default variables 426, and a set of run-time variables 428. As an example, such variables may be key-value pairs in a JSON object. Empty variables 424 are variables whose values (e.g., file name, folder name, task assignee, task message, etc.) can be set at the time the workflow template 347.sub.1 is being adapted to a new execution environment.).
Claim(s) 4-7, 14-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cardenas in view of Hiller and further in view of Soorya et al. (US 20210149784 A1) (hereinafter Soorya).
As per claim 4, the combination of Cardenas and Hiller disclose the method of claim 1 (See rejection to claim 1 above), but does not expressly disclose wherein the operations further include creating a log upon executing the workflow.
However, Soorya discloses wherein the operations further include creating a log upon executing the workflow (e.g. Soorya: (0055) discloses process 100 can monitor execution of the steps of the workflow. In some embodiments, process 100 can provide any suitable information regarding progress or status of steps or processes included in the workflow in any suitable manner. For example, in some embodiments, process 100 can provide updates indicating progress or status in a user interface presented on a user device that initiated execution of the workflow. As another example, in some embodiments, process 100 can update a file or multiple files that include a log associated with execution of the workflow. As still another example, in some embodiments, process 100 can be configured to alert another user device based on performance during execution of the steps of the workflow (e.g., a client device requesting execution of the workflow) in any suitable manner, such as via an API, via email, via FTP, and/or in any other suitable manner.).
It would have been obvious, under KSR, to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Cardenas and Hiller with Soorya because both are directed to methods of executing automated services in cloud computing environments and use known, complementary techniques to do so. A POSITA, seeking to improve the combination of Cardenas and Hiller’s method of executing an automated service would have been motivated to apply Soorya’s established practice of providing updates of a workflow, and would yield the predictable result of ensuring users’ awareness of automated systems and helping identify bottlenecks or problems within the system.
As per claim 5, the combination of Cardenas, Hiller, and Soorya disclose the method of claim 3 (See rejection to claim 3 above), wherein the operations further include transmitting the log to a remote device (e.g. Soorya: (0055) discloses process 100 can monitor execution of the steps of the workflow. In some embodiments, process 100 can provide any suitable information regarding progress or status of steps or processes included in the workflow in any suitable manner. For example, in some embodiments, process 100 can provide updates indicating progress or status in a user interface presented on a user device that initiated execution of the workflow. As another example, in some embodiments, process 100 can update a file or multiple files that include a log associated with execution of the workflow. As still another example, in some embodiments, process 100 can be configured to alert another user device based on performance during execution of the steps of the workflow (e.g., a client device requesting execution of the workflow) in any suitable manner, such as via an API, via email, via FTP, and/or in any other suitable manner. Soorya discloses a process can alert another user device based on performance during execution of the steps of the workflow. Thus, Soorya discloses transmitting the log to a remote device.).
As per claim 6, the combination of Cardenas, Hiller, and Soorya disclose the method of claim 4 (See rejection to claim 4 above), wherein the operations further include transmitting the log to a remote device (e.g. Soorya: (0055) discloses process 100 can monitor execution of the steps of the workflow. In some embodiments, process 100 can provide any suitable information regarding progress or status of steps or processes included in the workflow in any suitable manner. For example, in some embodiments, process 100 can provide updates indicating progress or status in a user interface presented on a user device that initiated execution of the workflow. As another example, in some embodiments, process 100 can update a file or multiple files that include a log associated with execution of the workflow. As still another example, in some embodiments, process 100 can be configured to alert another user device based on performance during execution of the steps of the workflow (e.g., a client device requesting execution of the workflow) in any suitable manner, such as via an API, via email, via FTP, and/or in any other suitable manner. Soorya discloses a process can alert another user device based on performance during execution of the steps of the workflow. Thus, Soorya discloses transmitting the log to a remote device.).
As per claim 7, the combination of Cardenas, Hiller, and Soorya disclose the method of claim 1 (See rejection to claim 1 above), wherein executing the workflow includes checking a status of execution and returning a message indicating the status of execution (e.g. Soorya: (0055) discloses process 100 can monitor execution of the steps of the workflow. In some embodiments, process 100 can provide any suitable information regarding progress or status of steps or processes included in the workflow in any suitable manner. For example, in some embodiments, process 100 can provide updates indicating progress or status in a user interface presented on a user device that initiated execution of the workflow. As another example, in some embodiments, process 100 can update a file or multiple files that include a log associated with execution of the workflow. As still another example, in some embodiments, process 100 can be configured to alert another user device based on performance during execution of the steps of the workflow (e.g., a client device requesting execution of the workflow) in any suitable manner, such as via an API, via email, via FTP, and/or in any other suitable manner.).
As per claim(s) 14-17, these are system claims having similar limitations as cited in method claim(s) 4-7. Thus, claim(s) 14-17 is/are also rejected under the same rationale as cited in the rejection of rejected claim(s) 4-7.
As per claim 20, the combination of Cardenas, Hiller, and Soorya discloses the system of claim 15 (See rejection to claim 15 above), where transmitting the log is achieved via electronic mail (e.g. Soorya: (0055) discloses process 100 can monitor execution of the steps of the workflow. In some embodiments, process 100 can provide any suitable information regarding progress or status of steps or processes included in the workflow in any suitable manner. For example, in some embodiments, process 100 can provide updates indicating progress or status in a user interface presented on a user device that initiated execution of the workflow. As another example, in some embodiments, process 100 can update a file or multiple files that include a log associated with execution of the workflow. As still another example, in some embodiments, process 100 can be configured to alert another user device based on performance during execution of the steps of the workflow (e.g., a client device requesting execution of the workflow) in any suitable manner, such as via an API, via email, via FTP, and/or in any other suitable manner.).
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cardenas in view of Hiller and further in view of Abrahams et al. (US 20130055193 A1) (hereinafter Abrahams).
As per claim 8, the combination of Cardenas and Hiller disclose a method for configuring a workflow to create or manage a specified environment, the method residing as instructions on a non-transitory computer-readable medium, the instructions being configured to cause a processor to perform operations including: receiving an input including a first set of parameters associated with one or more environments other than the specified environment and a second set of parameters associated with the specified environment; The above limitations corresponds to the method steps recited in claim 1, which are taught by the combination of Cardenas and Hiller as discussed above in the rejection of claim 1. generating a payload based on the input, the generating including: creating a loop including a mapping with a first as a key and a payload dictionary for step as a value (e.g. Hiller: (0071) discloses workflow analyzer 314 traverses the data object underlying the workflow template to identify any environment-specific variables associated with the workflow template (operation 510). Characteristics of the environment in which the workflow is to be executed are shared (e.g., via messaging protocol 511) with the workflow analyzer of the content management system. (0072) discloses environment-specific variables are included in workflow templates to facilitate adaptation of the workflow templates to various execution environments. The environment-specific variables are often codified in the data object as key-value pairs wherein the key is the environment-specific variable and the value is a respective environment-specific parameter. A particular workflow template can be adapted to an execution environment at least in part by setting the values associated with the environment-specific variables to environment-specific parameters that correspond to the execution environment. In some cases, workflow analyzer 314 may be provided the key names to the environment-specific variables that are included in the workflow templates to facilitate discovery of the environment-specific variables. Under BRI, a payload is a file that contains data and/or a sequence of steps. The workflow template is a file that contains data that defines how the workflow should be executed. Hiller further discloses a workflow analyzer traverses through the data object representing the workflow template to identify environment specific variables. Under BRI, a loop is any programmatic iteration through a data structure. The traversal is a functional equivalent to creating a loop. Hiller further discloses environment-specific variables are codified in key-value pairs wherein the key is the environment-specific variable and the value is the respective-environment specific parameter. Thus, Hiller discloses generating a payload based on the input, the generating including: creating a loop including a mapping with a first as a key and a payload dictionary for step as a value); iterating over the first indicator to payload map static parameters from the first set of parameters in the payload dictionary (e.g. Hiller: (0065) discloses the data object underlying a workflow template 347.sub.1 created for workflow 106.sub.1 comprises a set of empty variables 424, a set of default variables 426, and a set of run-time variables 428. As an example, such variables may be key-value pairs in a JSON object. Empty variables 424 are variables whose values (e.g., file name, folder name, task assignee, task message, etc.) can be set at the time the workflow template 347.sub.1 is being adapted to a new execution environment. Default variables 426 are pre-populated with values (e.g., target folder name, etc.) which may be modified (e.g., modified by a user or modified by an agent) when workflow template 34′71 is being adapted to the new execution environment. Hiller discloses default variables that are pre-populated with values when adapting the workflow template to a new environment which inherently implies the values are static. As previously discussed, the workflow template is inherently a payload. The default variables were mapped to a workflow template. Thus, Hiller discloses iterating over the first indicator to payload map static parameters from the first set of parameters in the payload dictionary); [ ] and updating dynamic parameters from the second set of parameters into the payload dictionary when the current step is a microservice (e.g. Hiller: (0065) discloses the data object underlying a workflow template 347.sub.1 created for workflow 106.sub.1 comprises a set of empty variables 424, a set of default variables 426, and a set of run-time variables 428. As an example, such variables may be key-value pairs in a JSON object. Empty variables 424 are variables whose values (e.g., file name, folder name, task assignee, task message, etc.) can be set at the time the workflow template 347.sub.1 is being adapted to a new execution environment. Default variables 426 are pre-populated with values (e.g., target folder name, etc.) which may be modified (e.g., modified by a user or modified by an agent) when workflow template 34′71 is being adapted to the new execution environment. Run-time variables 428 have values (e.g., timestamp of event completion) that are determined at run-time in the new execution environment and cannot be known prior to execution of the workflow. To test the functionality of the workflow, an instance of the workflow template is deployed to a first execution environment (step 406). For example, workflow 106.sub.11 can be derived from workflow template 347.sub.1 by assigning the environment-specific parameters 108.sub.1 to the corresponding aforementioned variables (e.g., empty variables 424 and default variables 426) and then executed. Hiller discloses empty variables can be key-value pairs in a JSON file. Hiller further discloses the empty variables can be set when the workflow template is being adapted to the new environment. The empty variables are inherently dynamic because they can be adapted to new environments. Thus, Hiller discloses updating dynamic parameters from the second set of parameters into the payload dictionary when the current step is a microservice.).
The combination of Cardenas and Hiller does not expressly disclose determining whether a current step is a microservice or a workflow, and further iterating over the first indicator when the current step is a workflow.
However, Abrahams discloses determining whether a current step is a microservice or a workflow (e.g. Abrahams: (Fig. 2A) (0025) discloses in step 208, SDOD 106 (see FIG. 1) determines whether or not the service is an atomic service. As used herein, an atomic service is defined to be a service that does not consume any other service internally to fulfill the service's intended business functionality. If SDOD 106 (see FIG. 1) determines in step 208 that the service is an atomic service, then the Yes branch of step 208 is followed and step 210 is performed. (Fig. 2B) (0035) discloses returning to step 208, if SDOD 106 (see FIG. 1) determines that the service is not an atomic service, then SDOD determines that the service is a composite service, the No branch of step 208 is followed, and step 222 in FIG. 2B is performed. As used herein, a composite service is defined as a service that aggregates atomic services and/or other composite services in a hierarchical formation. Abrahams discloses a decision block that determines if a service is atomic or composite. Under BRI, a microservice is an independent event that focuses on a single task. Under BRI, a workflow is an orchestration of steps to complete a task. Abrahams discloses the atomic service does not consume any other service to fulfill the service’s business functionality. Abrahams further discloses a composite service aggregates atomic services and/or other composite services into a hierarchical formation. The atomic and composite services Abrahams discloses are inherently microservices and workflows. Thus, Abrahams discloses determining whether a current step is a microservice or a workflow), and further iterating over the first indicator when the current step is a workflow (e.g. Abrahams: (Fig. 2B) (0046) discloses in step 238, SDOD 106 (see FIG. 1) determines whether the current service is the last service in the hierarchy of the composite service determined in step 208 (see FIG. 2A). If SDOD 106 (see FIG. 1) determines in step 238 that the current service is not the last service in the hierarchy, then the No branch of step 238 is followed and step 240 is performed. (0047) discloses in step 240, SDOD 106 (see FIG. 1) selects the next highest service in the hierarchy of the composite service determined in step 208 (see FIG. 2A) and the process loops back to step 224, where the data element input in the reiteration of steps 224-236 until the Yes branch of step 236 is taken again is a data element of the next highest service selected in step 240. (0048) discloses returning to step 238, if SDOD 106 (see FIG. 1) determines that the current service is the last service in the hierarchy of the composite service determined in step 208 (see FIG. 2A), then the Yes branch of step 238 is followed and step 242 is performed. Abrahams discloses a decision block determines whether the service in a composite service is the last service in the composite service hierarchy. Abrahams further discloses a loop that iterates through the composite service hierarchy until all services have been addressed. Thus, Abrahams discloses further iterating over the first indicator when the current step is a workflow.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of atomic and composite service determination as taught by Abrahams into the workflow templates containing environment-specific parameters of Hiller because it would predictably promote reusability of a service by providing a robust and non-rigid interface. (See Abrahams: (0012)).
As per claim 9, the combination of Cardenas, Hiller, and Abrahams disclose the method of claim 8 (See rejection to claim 8 above), wherein the operations further include creating a list containing values from the payload dictionary (e.g. Hiller: (0065) discloses the data object underlying a workflow template 347.sub.1 created for workflow 106.sub.1 comprises a set of empty variables 424, a set of default variables 426, and a set of run-time variables 428. As an example, such variables may be key-value pairs in a JSON object. Empty variables 424 are variables whose values (e.g., file name, folder name, task assignee, task message, etc.) can be set at the time the workflow template 347.sub.1 is being adapted to a new execution environment. Default variables 426 are pre-populated with values (e.g., target folder name, etc.) which may be modified (e.g., modified by a user or modified by an agent) when workflow template 34′71 is being adapted to the new execution environment. Run-time variables 428 have values (e.g., timestamp of event completion) that are determined at run-time in the new execution environment and cannot be known prior to execution of the workflow. To test the functionality of the workflow, an instance of the workflow template is deployed to a first execution environment (step 406). For example, workflow 106.sub.11 can be derived from workflow template 347.sub.1 by assigning the environment-specific parameters 108.sub.1 to the corresponding aforementioned variables (e.g., empty variables 424 and default variables 426) and then executed. (0072) discloses environment-specific variables are included in workflow templates to facilitate adaptation of the workflow templates to various execution environments. The environment-specific variables are often codified in the data object as key-value pairs wherein the key is the environment-specific variable and the value is a respective environment-specific parameter. A particular workflow template can be adapted to an execution environment at least in part by setting the values associated with the environment-specific variables to environment-specific parameters that correspond to the execution environment. In some cases, workflow analyzer 314 may be provided the key names to the environment-specific variables that are included in the workflow templates to facilitate discovery of the environment-specific variables. Hiller discloses a workflow template can be adapted using empty, default, or environment-specific variables. Hiller further discloses a workflow can be derived from a workflow template which inherently implies creating a list based on the workflow template. As previously discussed, the workflow template is inherently a payload. Thus, Hiller discloses creating a list containing values from the payload dictionary.).
As per claim 10, the combination of Cardenas, Hiller and Abrahams disclose the method of claim 8 (See rejection to claim 8 above), wherein the operations further include updating static parameters of the dictionary with parameters from the first set of parameters. (e.g. Hiller: (0065) discloses the data object underlying a workflow template 347.sub.1 created for workflow 106.sub.1 comprises a set of empty variables 424, a set of default variables 426, and a set of run-time variables 428. As an example, such variables may be key-value pairs in a JSON object. Empty variables 424 are variables whose values (e.g., file name, folder name, task assignee, task message, etc.) can be set at the time the workflow template 347.sub.1 is being adapted to a new execution environment. Default variables 426 are pre-populated with values (e.g., target folder name, etc.) which may be modified (e.g., modified by a user or modified by an agent) when workflow template 34′71 is being adapted to the new execution environment. Run-time variables 428 have values (e.g., timestamp of event completion) that are determined at run-time in the new execution environment and cannot be known prior to execution of the workflow. To test the functionality of the workflow, an instance of the workflow template is deployed to a first execution environment (step 406). For example, workflow 106.sub.11 can be derived from workflow template 347.sub.1 by assigning the environment-specific parameters 108.sub.1 to the corresponding aforementioned variables (e.g., empty variables 424 and default variables 426) and then executed. Hiller discloses default variables that are pre-populated with values when adapting the workflow template to a new environment which inherently implies the values are static. As previously discussed, the workflow template is inherently a payload. The default variables were mapped to a workflow template. Thus, Hiller discloses updating static parameters of the dictionary with parameters from the first set of parameters.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AARON ESTRELLADO whose telephone number is (571)272-9601. The examiner can normally be reached Monday-Friday 8:00am-4:00pm.
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, April Blair can be reached at (571) 270-1014. 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.
/A.M.E./Examiner, Art Unit 2196
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights