DETAILED ACTION
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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 29, 2025 has been entered.
Status of Claims
Claims 1, 4-5, 7 – 8, 10, 13 – 14, 16 – 17, 19 – 20 and 21 have been amended and are hereby entered.
Claims 6 and 15 were cancelled.
Claims 1 - 5 and 7 - 14 and 16 - 22 are pending and have been examined.
This action is made NON-FINAL.
Response to Arguments
Applicant's arguments filed August 29, 2025 have been fully considered but they are not persuasive.
Regarding to Applicant's arguments against the 101 rejection of the pending claims on pages 14 - 27: Applicant’s arguments directed to the 101 analysis were considered. However, these arguments are not persuasive and the Examiner respectfully disagrees for the following reasons:
For Step 2A-Prong 1 and Prong 2 starting in p. 16: The Applicant argues that the claim limitations recited in the amended claim 1 is not directed to the abstract idea of a certain method of organizing activity identified and instead “claim 1 is directed to the computer-related field of systems providing a mechanism for automatically identifying platform specific steps for a workflow for execution on a target workflow engine and compiling instructions for execution on the target workflow engine.” However, the Examiner find this argument unpersuasive. Because the claims are “reciting” a judicial exception when the judicial exception is “set forth” or “described” in the claim. See MPEP 2106.04, subsection II. For this case, the abstract idea (e.g. judicial exception) of a certain method of organizing human activity in the form of “commercial or legal interactions” and “managing interactions between people”is recited in the claims 1, 10 and 19. Specifically, the steps recite: “generating” a “platform independent document workflow specification” for “execution” of specific steps (i.e. such as document signing, identity verification and/or configuring and presenting a form; see Figs. 5 – 6 from Applicant disclosure) to “select” a target cloud platform and “compiling” workflow specification data (e.g. computer program codes) by “mapping” the document workflow specifications to platform specific sub-steps that are being “translated” to computer program codes as instructions per operation for each step to be “determined” to execute them by “outputting” requests which execute the operations for different cloud platforms related to “a test, staging or a production environment for deployment” (see claims 3 and 12). Thus, these steps are reciting the management and handling of agreements in the form of contracts and/or marketing or sales activities through the execution a “platform independent document workflow specification” to generate and format business documents that can be distributed in different cloud platforms. Similarly, the steps describe managing interactions between people in the form of following rules or instructions to sign/approve documents driven by the document workflow specification executed as claimed (see claims 9 and 18).
For Step 2A-Prong 2 starting in p. 17: Applicant’s arguments with respect to Step Prong Two, that alleges the claimed invention is reflecting the “improvement in the technical field of managing cloud platforms and providing for a design of computer code for a platform independent document workflow specification” through compiling improvements that further improves “performance of the system” are not persuasive. Because the limitations steps and its features, individually and as a whole, are considered to be mere instructions to apply the abstract idea by simply and broadly reciting the functions claimed (see MPEP 2106.05(f)). Specifically, the functions, at least directed in part to “generating” and “compile” workflow data as well as “map” the workflow data to platform specific sub-steps and “translate” them into instructions for each platform) are not reflecting how they are performed distinctively from generic computer components and general compilation/orchestration techniques (e.g. data processing/conversion). Thus, these limitations are invoking a computer used as a tool to perform the abstract concept, which is recited in a high level of generality and merely uses the “the platform independent document workflow specification” that is compiled and executed in the computer to generate “a platform specific document workflow specification” (see MPEP 2106.04(a)(2)(III)(C) and 2106.05 (f)).Therefore, the claim limitations do not reflect or further limits how the use of the computer (e.g. lacks details of the technological discussion for system/technical field improvement) is improving “managing cloud platforms” or improving the computer performance by compiling computer codes (see pp. 20 – 21 from Applicant remarks). Rather, these limitations merely recite the functions being performed by generic computer components (e.g. clearly invoking "apply it" to a computer) to achieve the intended result in a high level of generality. Thus, in response to Remarks in p. 24 - 26 and based on the same reasons stated above, these limitations cannot integrate the abstract idea into a practical application in Step2A-Prong 2 and/or provide an inventive concept at Step 2B (see MPEP 2106.05(f) and (a)(I - II)). Thus, for these reasons, the Examiner respectfully disagrees, and maintains 35 USC § 101 rejection for these pending claims.
Regarding the applicant's arguments of rejection under 35 USC § 103 for the pending claims on pages 27 – 29: Applicant’s arguments regarding the prior art references of Shakhnovich and Barkett for the amended limitation steps of “compiling” the computer program codes, “mapping” workflow specification to specific sub-steps of a workflow engine and “translating” the computer program codes to “determine” execution and “output” requests to execute instructions for each operation per platform in the pending claims are not persuasive. Firstly, the Applicant is generally focused on arguing the prior art references based on the specific amended terms and/or features from the claims without considering the broadest reasonable interpretation (BRI) of their own claim limitations. Thus, these arguments are unpersuasive because these steps and their recitation are broad enough for these element features to still be reasonably satisfied by the prior art of Barkett as already stated in the 35 USC § 103 rejection maintained herein.
As for the “mapping” step arguments in pp. 28 – 29 from Remarks, Shakhnovich reasonably teaches an example wherein “the workflow server may be configured to execute the online editing application to automate two-way data exports between a document slate (workflow document) and a cloud storage spreadsheet, such as a Google spreadsheet” directed to a first platform that further, “workflow server” is configured to execute various steps such as “1) set a condition for pulling spreadsheet data into the workflow template and generate a document; 2) connect the user's cloud storage account to find a spreadsheet and choose a sheet to pull data from; 3) locate and match the document's field data with rows in a selected spreadsheet column”; in addition to other examples that are referenced in the 103 rejection section. Therefore, the Examiner respectfully disagrees, and maintains 35 USC § 103 rejection for these pending claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-5 and 7 - 14, 16 - 22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of independent claim 19, the most representative claim of the independent claims set 1, 10 and 19, as follows:
At Step 1: Claims 1, 10 and 19 fall under statutory categories of a process, an article of manufacture and a system, respectfully.
At Step 2A Prong 1: Claim 19 (representative of claims 1 and 10) recites an abstract idea, which is defined by the following underlined elements (e.g. functional steps) while omitting any hardware components (e.g. represented as “…”):
…generate based on user interaction data, a platform independent document workflow specification comprising a sequence of steps associated with one or more documents, the platform independent document workflow specification specifying a document workflow configured for execution…;
select…the information specifying a user account with access…to execute a step of the platform independent document workflow specification,
compile first computer program code for the platform independent document workflow specification to generate second computer program code for a platform specific document workflow specification configured for execution…wherein compiling generating for at least a step of the document workflow, a set of platform specific steps for execution on the target workflow engine executing…
map, based on one or more configuration parameters of the step of the platform independent document workflow specification, the step of the platform independent document workflow specification to a set of sub-steps that are specific…, and each sub-step of the set of sub-steps to the step of the platform independent document workflow specification…
translate, based on the mapping of the step of the platform independent document workflow specification to the set of sub-steps, the first computer program code for the step of the platform independent document workflow specification into first instructions of the second computer program code that are configured to cause the target workflow engine to execute the first operation for the first platform specific step and second instructions of the second computer program code that are configured to cause the target workflow engine to execute the second operation for the second platform specific step
determine to execute the step of the platform independent document workflow specification;
based on the determination to execute the step of the platform independent document workflow specification, and based on the mapping of the step of the platform independent document workflow specification to the set of sub-steps:
output a first request to the target workflow engine to execute the first instructions of the second computer program code that are configured to cause the target workflow engine to execute the first operation for the first platform specific step and
output a second request to the target workflow engine to execute the second instructions of the second computer program code that are configured to cause the target workflow engine to execute the second operation for the second platform specific step
Generally, these limitations describe a method and a system for document management that generates and compile specific document workflows related to execute specific steps (e.g. “document signing, identity verification and/or configuring and presenting a form”) in various cloud platforms for receiving information by compiling workflow data and connecting with different connected cloud platforms. As disclosed in the specification in ¶0020 – 21, this invention “allows users to specify document workflows using a high-level platform independent document workflow specification that does not require development expertise or knowledge of the underlying cloud platform on which the document workflow is executed” and “enables a party (e.g., individuals, organizations, etc.) to create and send documents to one or more receiving parties for negotiation, collaborative editing, electronic execution (e.g., via electronic signatures), contract fulfilment, archival, analysis, and more”. However, the abstract idea(s) of a certain method of organizing human activity (See MPEP 2106.04(a)(2), subsection II) are/is recited in claim 19 in the form of “commercial or legal interactions” and “managing interactions between people”. Specifically, the abstract idea is recited in the step of “generating” a “platform independent document workflow specification” for “execution” of specific steps (i.e. such as document signing, identity verification and/or configuring and presenting a form; see Figs. 5 – 6 from Applicant disclosure) to “select” a target cloud platform and “compiling” workflow specification data (e.g. computer program codes) by “mapping” the document workflow specifications to platform specific sub-steps that are being “translated” to computer program codes as instructions per operation for each step to be “determined” to execute them by “outputting” requests which execute the operations for different cloud platforms related to “a test, staging or a production environment for deployment” (see claims 3 and 12). Thus, these steps are reciting the management and handling of agreements in the form of contracts and/or marketing or sales activities through the execution a “platform independent document workflow specification” to generate and format business documents that can be distributed in different cloud platforms. Similarly, the steps describe managing interactions between people in the form of following rules or instructions to sign/approve documents driven by the document workflow specification executed as claimed (see claims 9 and 18).
Step 2A Prong 2: For independent claims 1, 10 and 19, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of non-transitory computer-readable storage media (from claims 10 and 19); one or more processors, a plurality of workflow engines, a distinct cloud platform, a target workflow engine, and a target cloud platform (from claims 1, 10 and 19). These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). These element features including the computer used recited at a high level of generality and are performed generally to apply the abstract idea without placing any limits on how these steps (e.g. at least for the steps of “generating” and “compile” workflow data as well as “map” the workflow data to platform specific sub-steps and “translate” them into instructions for each platform) are performed distinctively from generic computer components and general compilation (e.g. data processing/conversion) functions. Thus, these steps mentioned above are further describing and applying the abstract idea without placing any limits on how the technological components are being improved, while distinguishing in the claim language, the performing limitations from functions that generic computer components can perform.
Moreover, the steps of “compile” workflow data, “map” the workflow data to platform specific sub-steps and “translate” them into instructions for each platform, are also “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)). In this case, the orchestration techniques for managing automating tasks and workflows in documents are broadly recited and lacks details on how this compilation, including how the mapping and translation is specifically performed and simply is limited to such general compilation techniques/software that attempts to limit the use of the abstract idea to computer environments and cloud platforms (see MPEP 2106.05(h) for examples (ix) and (x)). Therefore, this is indicative of the fact that the claim set has not integrated the abstract idea into a practical application and therefore, the claims are found to be directed to the abstract idea identified by the Examiner.
As for the steps of “output” first/second requests in all claims are really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)).
Step 2B: For independent claims 1, 10 and 19, these claims do not provide an inventive concept. The recited additional elements of the claim(s) are the following: non-transitory computer-readable storage media (from claims 10 and 19); one or more processors, a plurality of workflow engines, a distinct cloud platform, a target workflow engine, and a target cloud platform (from claims 1, 10 and 19). These additional elements are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Also, the recitation of a computer to perform the claim limitations amounts to no more than mere instructions to apply the exception using a generic computer component. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 2 - 5, 7 - 9, 11- 14, 16 - 18 and 21 - 22, these claims cover or fall under the same abstract idea of a method of organizing human activity. They describe additional limitations steps of:
Claims 2 - 5, 7 - 9, 11- 14, 16 - 18 and 21 - 22: further describes the abstract idea of the method of creating document workflows and the nature and the types of “a deployment environment on which the document workflow is expected to run” and the performing functions of receiving information, creating/ establishing first and second connections, compiling and executing the workflow and specific steps (e.g. tasks) data on another/second cloud platform and between different user accounts. Also, the generation of data for presenting and selecting a template workflow associated with documents is further described. Thus, being directed to the abstract idea group of “commercial or legal interactions” and “managing interactions between people” as it encompasses the management and handling of agreements in the form of contracts and/or marketing or sales activities as well as following rules or instructions to sign/approve documents driven by the document workflow specification executed between user accounts.
Step 2A Prong 2 and Step 2B: For dependent claim 21, this claim recites the additional element(s) of: a user interface. This additional element recited is invoking a computer merely used as a tool to perform or “apply” the abstract idea(s) to the existing process of generating template workflow data for display. Thus, amounting to no more than mere instructions to “apply” the exception using a generic computer component (MPEP 2106.05(f) and (f)(2)). Accordingly, for the same reasons stated above, these additional element(s) claimed cannot provide an inventive concept at Step 2B.
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
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.
Claims 1 - 5 and 7 - 14 and 16 - 22 are rejected under 35 U.S.C. 103 as being unpatentable over Shakhnovich (U.S. Pub No. 20200151630 A1) in view of Barkett (U.S. Pub No. 20220308911 A1).
Regarding claims 1, 10 and 19:
This independent claim set is represented by claim 19
Shakhnovich teaches:
one or more processors; and non-transitory computer-readable storage media storing instructions that, when executed by the one or more processors, cause the one or more processors to (See Fig.76 (7602 and 7610): Refer to ¶0122 and ¶0125 for more details about the non-transitory CRM and processors and memory, respectively.)
generate based on user interaction data, a platform independent document workflow specification comprising a sequence of steps associated with one or more documents, the platform independent document workflow specification specifying a document workflow configured for execution on any of a plurality of workflow engines each workflow engine executing on a distinct cloud platform; (In ¶0061; Fig. 3 (304 – 310); Figs. 31 and 35; Fig. 75 (7504): teaches “At step 304, one or more documents may be received by document import module 208 of workflow server 102 for the workflow” wherein the user may access, edit and/or “review the uploaded documents by triggering a selectable user interface object, such as selectable user interface object 3502 illustrated in example GUI 3500 in FIG. 35” and the “set of documents added to a particular workflow may be generated and edited based on the workflow templates from a library of pre-built workflows (“Slate Library”)” (see ¶0064 for “step 310” details). “Each document may be created or edited by the editing application (e.g., airSlate editor in FIG. 40) provided by the automatic workflow application (e.g., airSlate in FIG. 4)”. As for the “workflow server 102”, it “may be hosted in a cloud computing environment” and it may “be provided to one or more organizations using a software-as-a-service (SaaS) distribution and/or pricing model” which is directed to executing the document workflow on any of a plurality of workflow engines each workflow engine executing on a distinct cloud platform (see ¶0035) in accordance to ¶0003 from Applicant disclosure.)
select, from the plurality of workflow engines, a target workflow engine executing on a target cloud platform to execute a step of the platform independent document workflow specification, (In ¶0037; Fig. 1 (106a – n); Figs. 61 and 64: teaches that the “computing environment 100 may provide integration with one or more third-party applications which the user can use to fill out, sign, and submit a packet” which is directed to choosing a target workflow engine executing a target cloud platform to execute a platform independent document workflow specification step. Further, in ¶0039 from this prior art, the user can configure “add-ons” that “perform automated tasks related to individual workflow packets” which are implemented within the “workflow server” (e.g. “one or more physical and/or virtual machines”; see ¶0035) or by “one or more external application services 106” (e.g. directed to selecting target workflow engines). For example, “an add-on may automatically upload filled-out documents to a designated cloud storage folder after a packet is submitted by the recipient” (see ¶0039). Refer to ¶0041 wherein the “application services 106” include “Document storage services 106 c” which has “cloud-based storage services such as Google Drive, Dropbox, Box, Amazon S3, etc.” and see ¶0098 – 99 for an example wherein the user executes “the online editing application to automate two-way data exports between a document slate (workflow document) and a cloud storage spreadsheet” via the workflow server.)
map, based on one or more configuration parameters of the step of the platform independent document workflow specification, the step of the platform independent document workflow specification to a set of sub-steps that are specific to the target workflow engine, and each sub-step of the set of sub-steps to the step of the platform independent document workflow specification, the set of sub-steps comprising a first platform specific steps for execution of a first operation at the target workflow engine and a second platform specific step for execution of a second operation at the target workflow engine; and (In ¶0098; Fig. 1 (102 and 106a-n); Fig. 3 (306 and 310); Figs. 52 and 61 – 64: teaches an example wherein “the workflow server may be configured to execute the online editing application to automate two-way data exports between a document slate (workflow document) and a cloud storage spreadsheet, such as a Google spreadsheet” directed to a first platform. Specifically, in Fig. 62, “the workflow server may be configured to generate a document pre-filled with spreadsheet data by setting up mapping conditions or values for pulling spreadsheet data into a workflow template and generating a document” wherein the “workflow server” is configured to execute various steps such as “1) set a condition for pulling spreadsheet data into the workflow template and generate a document; 2) connect the user's cloud storage account to find a spreadsheet and choose a sheet to pull data from; 3) locate and match the document's field data with rows in a selected spreadsheet column; and/or 4) connect the document's fields with the spreadsheet columns”, which are directed to mapping the step of the platform independent document workflow specification to a set of sub-steps that are specific to the target workflow engine. Similarly, “a workflow document” and its data (e.g. “document slate”; see ¶0058 and ¶0098) can be executed by the “workflow server” and exported into “other cloud storages” as disclosed on the example of automatic workflow application for an “automated onboarding process” with “onboarding documents” (see ¶0116).)
Shakhnovich teaches the creation of workflows via a “Workflow configuration module 206” at step 310 from Fig. 3 (see ¶0064; Shakhnovich) and a “slate creator app can be used to generate and configure new workflow documents and/or workflows within the system” (see ¶0069; Shakhnovich) Similarly, Shakhnovich teaches the system’s “workflow server” being “configured to execute the online editing application to automate two-way data exports between a document slate (workflow document) and a cloud storage spreadsheet” (see ¶0098; Shakhnovich) and uses a computer program that can be “written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment” (see ¶00118; Shakhnovich). However, Shakhnovich does not actively and explicitly teach the abilities of specifically compiling the platform independent document workflow specification in order to generate a second computer code for the platform specific document workflow specification configured for execution, translating first and second codes of the platform independent document workflow specification step into first and second instructions for each platform, determine to execute the step and execute the first and second instructions per platform by outputting first and second requests. However, Barkett teaches:
compile first computer program code for the platform independent document workflow specification to generate second computer program code for a platform specific document workflow specification configured for execution on the target workflow engine executing on the target cloud platform, (In ¶0027 – 28; Figs. 1 and 2; Figs. 5 – 7(S110): teaches that “a workflow compiler 120 functions to transform a workflow specification” (e.g. “data modeling and/or instructions that specify tasks to be performed, conditions of execution of the tasks, order or flow of execution be tasks; the data, documents, and/or other resources used for performing a task, and/or other aspects of a workflow” that are further directed to a set of platform independent document workflow specification steps and their first computer program code; see ¶0024 and ¶0060) into “deployment configuration” that is “a data model that defines computer infrastructure in fulfilling the workflow application” (e.g. directed to second computer program code for a platform specific document workflow specification configured for execution) and is outputted or “communicated to and saved at a workflow service directory or another computer-readable medium accessible by the cluster deployment service 130” (e.g. “workflow orchestrator”), in accordance to ¶0041 from Applicant specifications. Finally, the “workflow specification” is represented in “a graphical representation of a directed graph of connected nodes, where each node is associated with or include properties defining a task service” and this graph is made with a “low-code editor interface” of the “workflow editor” (see ¶0055) which suggests that the first computer program code is included.)
translate, based on the mapping of the step of the platform independent document workflow specification to the set of sub-steps, the first computer program code for the step of the platform independent document workflow specification into first instructions of the second computer program code that are configured to cause the target workflow engine to execute the first operation for the first platform specific step and second instructions of the second computer program code that are configured to cause the target workflow engine to execute the second operation for the second platform specific step (In ¶0027; Figs. 1 and 2; Figs. 5 – 7(S110): teaches that the “workflow compiler 120 functions to transform a workflow specification into deployment configuration” wherein such “deployment configuration is a data model that defines computer infrastructure in fulfilling the workflow application” from where the first and second instructions were received per each application (see ¶0024). See ¶0044 for more details about the “process of translating a workflow specification into a deployed cluster”.)
determine to execute the step of the platform independent document workflow specification; based on the determination to execute the step of the platform independent document workflow specification and based on the mapping of the step of the platform independent document workflow specification to the set of sub-steps: (In ¶0027 – 28; Fig. 1 (130 and 140): teaches that “the workflow compiler 120 outputs a deployment configuration” which is “a data model that defines computer infrastructure in fulfilling the workflow application” (directed to determining the execution of the platform independent document workflow specification step) and the “output of the workflow compiler 120 is communicated to and saved at a workflow service directory or another computer-readable medium accessible by the cluster deployment service 130” which functions as “workflow orchestrator that manages a computing cluster” (e.g. “virtual hosts 140”; see Fig. 1) used in “executing various workflow instances” which is directed to executing the first and second instructions per each platform.)
output a first request to the target workflow engine to execute the first instructions of the second computer program code that are configured to cause the target workflow engine to execute the first operation for the first platform specific step and output a second request to the target workflow engine to execute the second instructions of the second computer program code that are configured to cause the target workflow engine to execute the second operation for the second platform specific step (In ¶0033 – 34; Fig. 1 (130, 140 and 146): teaches that the “virtual machine host 10” (e.g. directed to the target workflow engine)and its “task service 142 is configured to receive request input from the task router 146 (of that specific task)” (directed to outputting first and second requests to execute first and second instructions), “perform an operation (usually based on the request content), and output a response to the task router 146” wherein the “specific task operations can be defined or referenced in the workflow specification” which contains the first and second instructions of the first and second computer program codes for executing the first and second operations pertaining to their first and second platform specific steps.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Shakhnovich to provide the abilities of specifically compiling the platform independent document workflow specification in order to generate a second computer code for the platform specific document workflow specification configured for execution, translating first and second codes of the platform independent document workflow specification step into first and second instructions for each platform, determine to execute the step and execute the first and second instructions per platform by outputting first and second requests, as taught by Barkett in order to “create a new and useful system and method for a scalable workflow system for distributed applications” in “the distributed computing infrastructure field” (¶0003; Barkett) and provide “a workflow network overlay that can dynamically route various workflow tasks for enhanced scalability, low latency, and security” (¶0010; Barkett).
Regarding claims 2 and 11:
The combination of Shakhnovich and Barkett, as shown in the rejection above, discloses the limitations of claims 1 and 10, respectively.
Shakhnovich further teaches:
wherein selecting the target cloud platform is based on deployment environment on which the document workflow is expected to run, wherein the platform specific document workflow specification includes steps specific with the deployment environment. (In ¶0040; Fig. 1 (102); Figs. 46 – 48 and 52: teaches the deployment environment directed to “an add-on” that “may be triggered to run for a given workflow based on a current date or time stored in server 102 or a client device 104” or based on “specific form values entered by the recipient” directed to steps specific with the deployment environment that were selected for a specific cloud platform. Moreover, in ¶0053, “workflow distribution module 210 may be configured to run one or more add-ons associated with a workflow by invoking associated callback URLs of one or more remote servers where the add-ons are hosted” and this module “may be executed to perform workflow distribution operations based on user interactions with one or more GUIs via a user interface of the client device 104”. Refer to ¶0106 and ¶0116 – 117 wherein an “automatic workflow application executed on a workflow server 102 may be used in an automated onboarding process for automated electronic document workflows”)
Regarding claims 3 and 12:
The combination of Shakhnovich and Barkett, as shown in the rejection above, discloses the limitations of claims 2 and 11, respectively.
Shakhnovich teaches a deployment environment directed to “an add-on” that “may be triggered to run for a given workflow” via a “workflow distribution module 210”, based on “specific form values entered by the recipient” (see ¶0040 and ¶0053; Shakhnovich). However, Shakhnovich does not explicitly teach a specific type of deployment environment related to at least a test, a staging, or a production environment. Thus, Barkett further teaches:
wherein the deployment environment is one of a test environment, a staging environment, or a production environment. (In ¶0022; Fig. 1; Fig. 4 (S100): teaches this descriptive matter under the broadest reasonable interpretation (BRI) directed to “a distributed microservice computing environment” that executes “an operating workflow” derived from a “workflow specification” that was transformed by the recited system. Thus, these “workflow specifications” could be run in a “a web or native application through which a workflow designer can create or edit workflow specifications” (see ¶0025) which obviously implies testing, staging and/or production environments. Also, in ¶0049 the system’s method can be applied in “industries where complex workflows must be developed and deployed with high reliability and a degree of customization for different scenarios. For example, the method may be used in development and implementation of business logic workflow applications in industries such as real-estate, insurance, legal services, financial services, operations/logistics, and many other industries” wherein “developers and potentially non-developers may be able to define and deploy scalable solutions using workflow application tools” in the environments claimed. Finally, in ¶0062 “a service may already be implemented, and a workflow editor or other mechanism may enable associating a task of the workflow with a pre-implemented service” wherein a “designer of the workflow can do this during the design phase” which is directed to a test or staging environment as well.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Shakhnovich to provide a specific type of deployment environment related to at least a test, a staging, or a production environment, as taught by Barkett in order to “create a new and useful system and method for a scalable workflow system for distributed applications” in “the distributed computing infrastructure field” (¶0003; Barkett) and provide “a workflow network overlay that can dynamically route various workflow tasks for enhanced scalability, low latency, and security” (¶0010; Barkett).
Regarding claims 4, 13 and 20:
The combination of Shakhnovich and Barkett, as shown in the rejection above, discloses the limitations of claims 1, 10 and 19, respectively.
Shakhnovich further teaches:
wherein the target workflow engine is a first target workflow engine, the target cloud platform is a first target cloud platform, the platform specific document workflow specification is a first platform specific document workflow specification, and the platform independent document workflow specification is a first instance of the platform independent document workflow specification, the computer-implemented method further comprising: selecting, by the one or more processors, for a second instance of the platform independent document workflow specification, and from the plurality of workflow engines, a second target workflow engine executing on a second target cloud platform; and (In ¶0041; Fig. 1 (102 and 106a – n): under BRI, this limitation is satisfied by teaching that document information via ““Archive Document” add-on may be configured to export completed workflow documents to a document storage service 106 c” (e.g. directed to selecting for a second instance, a second target workflow engine executing on a second target cloud platform; see ¶0039) can be received and stored as a “packet submitted” (directed to a second instance) in different “document storage services 106 c” which include “cloud-based storage services such as Google Drive, Dropbox, Box, Amazon S3, etc. Faxing and printing services 106 d can include, for example, cloud-based faxing/printing services”. The selection of a second target workflow engine on a second target cloud platform is directed to the server receiving “signed documents” that “may be automatically archived in a cloud storage, such as Google Drive, Dropbox or other assigned cloud storages” as an example for a second target cloud platform being selected by the user (see ¶0115 for more details of an example))
Shakhnovich does not actively and explicitly teach the ability of compiling the platform independent document workflow specification to generate a second platform specific document workflow specification. However, Barkett further teaches:
compiling by the one or more processors and for the second instance of the platform independent document workflow specification, the first computer program code for the platform independent document workflow specification to generate a second platform specific document workflow specification configured for execution on the second target workflow engine executing on the second target cloud platform. (In ¶0027; Fig. 1: this limitation is satisfied by teaching that “a workflow compiler 120 functions to transform a workflow specification into deployment configuration” that is “communicated to and saved at a workflow service directory or another computer-readable medium accessible by the cluster deployment service 130” directed to the second target workflow engine executing on the second target cloud platform.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Shakhnovich to provide the ability of compiling the platform independent document workflow specification to generate a second platform specific document workflow specification, as taught by Barkett in order to “create a new and useful system and method for a scalable workflow system for distributed applications” in “the distributed computing infrastructure field” (¶0003; Barkett) and provide “a workflow network overlay that can dynamically route various workflow tasks for enhanced scalability, low latency, and security” (¶0010; Barkett).
Regarding claims 5, 8, 14 and 17:
The combination of Shakhnovich and Barkett, as shown in the rejection above, discloses the limitations of claims 4, 7, 13 and 10, respectively.
Shakhnovich further teaches:
further comprising: establishing, by the one or more processors, a first connection with the first target workflow engine using a first user account for the first target cloud platform, wherein outputting the first request and outputting the second request uses the first connection; establishing, by the one or more processors, a second connection with the second target workflow engine using a second user account for the second target cloud platform; and (In ¶0098 – 99; Fig. 1 (102 and 106a-n); Figs. 52, 61 – 62 and 64; Fig. 70A: this limitation is satisfied by teaching that the “the workflow server” may be configured to “connect a user's cloud storage account (e.g., a Google account) for prefilling workflow document data from a cloud storage spreadsheet” (see ¶0098) as well as “connect to a cloud storage such as Dropbox over a network 110” (see ¶0094) which is directed to establishing a first and a second connection with the first and second workflow engines executing on the first and second target cloud platforms using the second user account. Also, in ¶0102, “Each workflow document may be configured to be edited by different teammates and/or outside users” and in “FIG. 70A illustrates an example GUI 7000A in which a user may send email invitations with a public link to teammates or outside users to invite them to edit a particular workflow document and/or multiple documents associated with the workflow” which is directed to at least a second user account.)
Shakhnovich teaches that a “computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network” (see ¶0118; Shakhnovich) that can include a second connection such as a “Dropbox” connection with a workflow as shown in Figs. 50 – 52 (see ¶0094; Shakhnovich). However, Shakhnovich does not explicitly teach the ability of executing, the second platform specific document workflow specification using the connection. Thus, Barkett further teaches:
executing, by the one or more processors, the second platform specific document workflow specification using the second connection. (In ¶0027 – 28; Fig. 1 (130 and 140): under BRI, this limitation is satisfied by teaching that “the workflow compiler 120 outputs a deployment configuration” which is “a data model that defines computer infrastructure in fulfilling the workflow application” and the “output of the workflow compiler 120 is communicated to and saved at a workflow service directory or another computer-readable medium accessible by the cluster deployment service 130” which functions as “workflow orchestrator that manages a computing cluster” (e.g. “virtual hosts 140” directed to a second platform specific document workflow specification; see Fig. 1) used in “executing various workflow instances”.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Shakhnovich to provide the ability of executing, the second platform specific document workflow specification using the connection, as taught by Barkett in order to “create a new and useful system and method for a scalable workflow system for distributed applications” in “the distributed computing infrastructure field” (¶0003; Barkett) and provide “a workflow network overlay that can dynamically route various workflow tasks for enhanced scalability, low latency, and security” (¶0010; Barkett).
Regarding claims 7 and 16:
The combination of Shakhnovich and Barkett, as shown in the rejection above, discloses the limitations of claims 1 and 10, respectively.
Shakhnovich further teaches:
wherein the target workflow engine is a first target workflow engine, the target cloud platform is a first target cloud platform, and the step is a first step, the computer-implemented method further comprising: selecting, by the one or more processors and from the plurality of workflow engines, a second target workflow engine executing on a second target cloud platform, (In ¶0041; Fig. 1 (102 and 106a – n): under BRI, this limitation is satisfied by teaching that document information via ““Archive Document” add-on may be configured to export completed workflow documents to a document storage service 106 c” (e.g. directed to selecting a second target workflow engine executed on a second target cloud platform; see ¶0039) can be received and stored as a “packet submitted” in different “document storage services 106 c” which include “cloud-based storage services such as Google Drive, Dropbox, Box, Amazon S3, etc. Faxing and printing services 106 d can include, for example, cloud-based faxing/printing services”. The selection of a second target workflow engine on a second target cloud platform is directed to the server receiving “signed documents” that “may be automatically archived in a cloud storage, such as Google Drive, Dropbox or other assigned cloud storages” as an example for a second target cloud platform being selected (see ¶0115 for more details))
Shakhnovich teaches that the system can “connect a user's cloud storage account (e.g., a Google account) for prefilling workflow document data from a cloud storage spreadsheet” (see ¶0098, Shakhnovich) as well as “connect to a cloud storage such as Dropbox over a network 110” as shown in Figs. 50 – 52 (see ¶0094, Shakhnovich) as a second target cloud platform. However, Shakhnovich does not explicitly teach the compiling the platform independent document workflow specification generates for a second set of the document workflow, a set of platform specific steps for execution on the second target workflow engine. Thus, Barkett further teaches:
wherein compiling the first computer program code for the platform independent document workflow specification generates for a second step of the document workflow, a set of platform specific steps for execution on the second target workflow engine. (In ¶0027; Fig. 1: under BRI, this limitation is satisfied by teaching that “a workflow compiler 120 functions to transform a workflow specification” (e.g. “data modeling and/or instructions that specify tasks to be performed, conditions of execution of the tasks, order or flow of execution be tasks; the data, documents, and/or other resources used for performing a task, and/or other aspects of a workflow” directed to second set of platform specific steps, see ¶0024) into “deployment configuration” that is “communicated to and saved at a workflow service directory or another computer-readable medium accessible by the cluster deployment service 130” directed to a second target cloud platform, in accordance to ¶0041 from applicant specifications.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Shakhnovich to provide the ability of compiling the platform independent document workflow specification generates for a second set of the