Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This is the initial Office action based on the application filed on June 25, 2024.
Claims 1-20 are presently pending in the application have been examined below, of which, claims 1, 10, and 19 are presented in independent form.
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 of this title, 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11,789,770 (hereinafter "Tallman”), in view of US 10552180 (hereinafter “Baneva”), in view of US 2022/0343250 (hereinafter “Tremblay”), in view of CN 202210764897 (hereinafter “Shang”), and further in view of US 11,748,686 (hereinafter “Kwan”).
In the following claim analysis, Applicant’s claim limitations are presented in bold text, the Examiner’s explanations, notes, and remarks are enclosed in square brackets; and emphasized portions are underlined.
As to claim 1, Tallman discloses A system (Tallman, Abstract, A system for creating surrogate models) for improving data processing efficiency in dynamic workflow systems by enabling codeless enrichment of a platform's workflow elements library by third-party vendors, the system comprising:
an elements database configured to store a plurality of workflow elements (Tallman, Fig. 1-2, col. 5, ln. 24-27, a user may be able to search database 106, … to search database 106 for applications to use to complete a workflow);
a workflow platform communicatively coupled to the elements database and comprising a memory and at least one processor configured to implement (Tallman, Fig. 1-2, col. 4, ln. 32-47, an example surrogate model computing (SMC) system 100 for storing applications, accumulating data regarding application usage … SMC system 100 includes a server 102, including at least one SMC device 104 and a database server 108. SMC device 104 is in communication with at least one database 106, at least one user computing device 110, and at least one external computing device 112, 114, 116 … user computing device 110 (e.g., a smartphone, tablet, laptop, etc.); Fig. 3, col. 8, ln. 37-47, a user system 300 … user system 300 includes a processor 304 for executing instructions … executable instructions are stored in a memory area 306):
an interface engine configured to:
provide a graphical user interface (GUI) (Tallman, Fig. 3, col. 9, ln. 13-23, providing a user interface to user 302 … A user interface may include, among other possibilities, a web browser and client application. Web browsers enable users, such as user 302, to display and interact with media),
a workflow engine configured to:
generate a workflow incorporating the custom event (Tallman, Fig. 2, col. 5, ln. 12-14, the generation and execution of a workflow; col. 7, ln. 24-45, new meta-data is generated regarding the workflow, and stored in the workflow. For example, new meta-data may include data indicating where the application was run (i.e., which external computing device 112-116 was used to run the application), which user requested the application or workflow using the application, how long it took to run the application, which configuration changes were made to the respective external computing device 112-116 to run the application, and which setup or settings files were used to run the application. The new meta-data is stored in the workflow, and SMC device 104 is configured to extract the new meta-data (i.e., new application meta-data 224) from final workflow output 222. … a user may be able to modify new application meta-data 224. For example a user may enter meta-data indicating their user experience with the applications or workflow; Fig. 5, generating 512, by the processor, based on execution of the workflow request, new meta-data associated with the at least one application).
Tallman does not explicitly disclose
receive, via the GUI:
a custom event comprising an event identity, an event name, and an event schema, wherein the event schema includes an association between the custom event and one of the plurality of workflow elements,
receive event data associated with the event schema,
an event engine configured to:
receive, from the workflow engine, a subscription request associated with the custom event.
However, Baneva teaches
receive, via the GUI:
a custom event comprising an event identity, an event name, and an event schema, wherein the event schema includes an association between the custom event and one of the plurality of workflow elements (Baneva, Fig. 6, col. 23, ln. 47-67, at block 610, the workflow subscription GUI 470 generates a display having event topics. At block 620, the workflow subscription GUI 470 responds to user-selection of an event topic by causing a corresponding event schema to be displayed … the event schema includes a set of fields. … GUI 470 responds to user-selection of one of the fields of the event schema by collecting (from user-input) a threshold value. … the selected field of the event schema. … GUI 470 responds to the entry of the threshold value by supplying an event topic identifier identifying the selected event topic, a field identifier identifying the selected field and the threshold value),
receive event data associated with the event schema (Baneva, Fig. 6, col. 23, ln. 47-67, GUI 470 responds to user-selection of one of the fields of the event schema by collecting (from user-input) a threshold value. … the selected field of the event schema. … GUI 470 responds to the entry of the threshold value by supplying an event topic identifier identifying the selected event topic, a field identifier identifying the selected field and the threshold value),
an event engine configured to:
receive, from the workflow engine, a subscription request associated with the custom event (Baneva, col. 5, ln. 47-55, the graphical user interface generates a display including a list of workflows, and a list of event topics and the graphical user interface collects a workflow identifier corresponding to a user-selected one of the workflows and collects an event topic identifier corresponding to the user-selected event topic. The subscription manager subscribes to an event broker to receive the event notification corresponding to the event topic).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Tallman with the teaching of Baneva. The modification would be obvious because one of ordinary skill in the art would be motivated to enable workflow execution to be triggered and coordinated through standardized events. Doing so would improve interoperability among workflow components, facilitate integration with external systems, provide a structured mechanism for defining and processing event, and allow workflows to respond dynamically to event occurrences, yielding the predictable result of a more flexible and scalable workflow automation platform.
Tallman as modified does not appear to explicitly disclose: a custom action, wherein the custom action comprises a callback, a callback schema, an action, and an association between the custom action and one of the plurality of workflow elements, receive event data via a public API; generate an action request comprising an indication to perform the action based on the callback, wherein the action request includes data according to the callback schema.
However, Tremblay teaches: a custom action, wherein the custom action comprises a callback, a callback schema, an action, and an association between the custom action and one of the plurality of workflow elements (Tremblay, Fig. 79B, ¶ 595, the custom workflows actions system 564 allows for the creation of custom code actions for a workflow. For example, users may write and execute programming language (e.g., JavaScript) within a custom action in workflows … the custom code actions may each have a callback function; Fig. 82, ¶ 602, FIG. 82 shows a screenshot of a graphical user interface (GUI) 8200 for displaying an example custom code action … the code may specify what kind of data may be expected to output this custom code action. The reason for specifying this output may be so that the downstream actions may know and anticipate what to expect [It is noted that Fig. 82 and ¶ 602 teach specifying the data expected to be output by a callback, including defining output fields and associated data types (e.g., output field ‘phone’ of type String). Such definitions constitute a callback schema because they define the structure and format of callback data that downstream workflow actions consume. It is further noted that Tremblay teaches that a custom code action is added to a workflow and selected from a list of workflow actions (e.g., ¶ 595). Therefore, the custom code action is associated with a workflow element because it forms one of the execution workflow components with the workflow definition.]), receive event data via a public API (Tremblay, ¶ 596, the custom workflow actions process (e.g., using the custom workflow actions system 564) may execute API calls out to other systems or into the internal API to get other data); generate an action request comprising an indication to perform the action based on the callback (Tremblay, ¶ 595, the custom code actions may each have a callback function (e.g., “callback( )”) that may be used to pass data back to the workflow (e.g., the callback function may be called [an action request] in the “exports” main function); ¶ 608, the callback may be a type of handle that may allow for passing of data. … the custom code action request may ask to obtain an object from an API), wherein the action request includes data (Tremblay, ¶ 595, there may be an event object in JSON such as an example payload that includes reference to a portal ID, custom action definition ID, type of CRM object that may be enrolled in workflow, and a unique ID for execution; ¶ 608, the callback may be a type of handle that may allow for passing of data) according to the callback schema (Tremblay, Fig. 82, ¶ 602).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Tallman as modified with the teaching of Tremblay. The modification would be obvious because one of ordinary skill in the art would be motivated to provide a standardized mechanism for invoking workflow related actions, processing event data received through public APIs, and improving interoperability between workflow components and external systems.
Tallman does not appear to explicitly disclose an API callback gateway (ACGW); send, via the ACGW, the action request; receive, via the ACGW, an action response associated with the action request.
However, Shang teaches an API callback gateway (ACGW) (Shang, pg. 3, para. 3 from the last para., a method based on API gateway, the workflow information comprises the calling step, the corresponding to the API service workflow information is arranged; pg. 4, para. 4, a method data aggregation on API gateway, wherein the working flow information comprises a return data format corresponding to each interface in the aggregate interface and a template for data processing the return data of each interface, the working flow information corresponding to the API service is arranged); send, via the ACGW, the action request (Shang, pg. 9, para. 2 from the bottom of the page, the invention arranges the workflow information corresponding to the API service, which can realize the service arrangement to the API gateway to correspond to a plurality of back end service, the request parameter of each back end service can be the parameter transmitted by the front end, It is also possible to be self-defined (write static parameters or from return data) obtain the arrangement. and can perform data processing (filtering, deleting, renaming, unpacking and packet operation) to the return result of each service); receive, via the ACGW, an action response associated with the action request (Shang, pg. 9, para. 2 from the bottom of the page, the invention arranges the workflow information corresponding to the API service, which can realize the service arrangement to the API gateway to correspond to a plurality of back end service, the request parameter of each back end service can be the parameter transmitted by the front end, It is also possible to be self-defined (write static parameters or from return data) obtain the arrangement. and can perform data processing (filtering, deleting, renaming, unpacking and packet operation) to the return result of each service, finally integrating into a large result to return, as the result feedback of the calling party of the service).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Tallman as modified with the teaching of Shang. The modification would be obvious because one of ordinary skill in the art would be motivated to employ Shang’s gateway for handling communications. Doing so would provide a centralized interface for receiving callback requests and event related data from external system, improving interoperability among distributed components, and facilitate management of callback traffic using known API gateway techniques, thereby achieving the predictable result of a more flexible and scalable workflow platform.
Tallman as modified does not appear to explicitly disclose: determine that the action response is valid; and send, based on the subscription request and the determination that the action response is valid, an indication that the custom event occurred to the workflow engine, wherein the workflow engine is configured to execute a portion of the workflow based on the indication that the custom event occurred.
However, Kwan teaches determine that the action response is valid (Kwan, col. 2, ln. 44-49, the API to be submitted for integration into the dynamic proxy server and validated via end-to-end testing within the one or more service environments such that functionality of the API is verified; col. 11, ln. 47-52, the API call responses (e.g., the API test call response 220) that are generated by the service within the service environment in response to one or more API calls (e.g., API test call 218, API calls of the subscription workflow, etc.) can be logged); and send, based on the subscription request and the determination that the action response is valid, an indication that the custom event occurred to the workflow engine (Kwan. col. 12, ln. 54-61, the API test call response 220 can indicate that the modified operation transmitting one or more operation exceptions that prevent and/or alter the generation of the one or more output variables [It is noted that Kwan teaches that API test reasons is received, the API test response indicates operation completed, which is an indication that the custom event occurred.]), wherein the workflow engine is configured to execute a portion of the workflow based on the indication that the custom event occurred (Kwan, col. 12, ln. 66-col. 13, ln. 4, the API test call response 220 may include an indication that the operation has been completed by the service. In response, the content validation server 206 can be configured to access the operation endpoint to obtain the one or more output variables generated by the modified operation [It is noted that upon receiving the indication that the operation has completed, Kwan’s workflow proceeds to subsequent workflow processing, thereby teaching execution of at least a portion of a workflow responsive to the event indication.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Tallman as modified with the teaching of Kwan. The modification would be obvious because one of ordinary skill in the art would be motivated to allow workflow elements to receive event information only for events of interest, thereby reducing unnecessary communication and improving the efficiency of event driven workflow execution.
As to claim 2, the rejection of claim 1 is incorporated. Tallman as modified further discloses The system of claim 1, wherein the workflow is generated based on a software recipe defining a trigger based on the custom event and an action based on the custom action (Tremblay, ¶ 237, the client configuration system 1602 may allow a user to create new and/or update workflows by defining different service-related workflow actions and conditions that trigger those actions; ¶ 383, When the user goes into automation and defined workflows, the user may request that they want a workflow from scratch [based on a software recipe], e.g., a service-based workflow. For the triggers and the actions on this service-based workflow, the user may have access to all these properties [based on the custom event and an action based on the custom action] that may have been previously defined; ¶ 435, the user may define the associations that give rise to the event or other actions that occur that may trigger the event; ¶ 528, events may be used to trigger workflows or prompts; ¶ 529, post-processing the transcript 6908 may include triggering one or more actions (e.g., trigger actions 6938), where the actions may be an initial action in a workflow), and wherein the software recipe includes a condition for event validation and a condition for action execution based on the custom event (Kwan, col. 2, ln. 44-49, the API to be submitted for integration into the dynamic proxy server and validated via end-to-end testing within the one or more service environments such that functionality of the API is verified) and the callback schema (Tremblay, Fig. 82, ¶ 602). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 3, the rejection of claim 2 is incorporated. Tallman as modified further discloses The system of claim 2, wherein the workflow comprises the trigger, and wherein the determination of whether the event data is valid is further based on the condition for event validation (Baneva, col. 16, ln. 31-52, the tenant administrator can use the template to select one (or more) of the fields in the event schema and to indicate a desired value against which a value stored in the field is to be evaluated … when the value stored in the selected field evaluates to (is equal to, greater than, less than, etc.) the desired value (e.g., True, False, a numerical value, etc.), the workflow is triggered. Thus, the field and the desired value together form a condition to be met and/or satisfied before the selected workflow is triggered. In some examples, the user-selectable conditions (in addition to including the event schema fields) also includes conditions that are more-generally related to the event topic (e.g., an event type, an event timestamp, a user name) and that are to be evaluated to determine whether the workflow will be triggered. Thus, the tenant administrator uses the template generated by the template generator 502 to identify the features/characteristics of the subscription (e.g., the workflow to be performed, an event topic upon which the operation of the workflow is to be predicated/based, and a condition and associated value to be met and/or satisfied before the workflow will be triggered/executed) [It is noted that Baneva teaches evaluating received event data using fields devind by the event schema and determining whether the event data satisfies criteria associated with those schema fields before triggering a workflow. Accordingly, Baneva teaches determining the validity of event data based on comparison of the event data to information defined by the event schema.]). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 4, the rejection of claim 1 is incorporated. Tallman as modified further discloses The system of claim 1, wherein the event engine is further configured to configure a third-party cloud service to send an action response associated with the action request (Baneva, col. 5, ln. 25-32, an example virtual appliance in a cloud computing environment that includes a graphical user interface that responds to a user-selected event topic by causing a corresponding event schema to be displayed) to the ACGW (Shang, pg. 9, para. 2 from the bottom of the page, the API service, which can realize the service arrangement to the API gateway to correspond to a plurality of back end service, the request parameter of each back end service can be the parameter transmitted by the front end) based on the custom event or a predefined condition (Baneva, col. 5, ln. 25-32, an example virtual appliance in a cloud computing environment that includes a graphical user interface that responds to a user-selected event topic by causing a corresponding event schema to be displayed, and that also includes a subscription manager to trigger a workflow based on an event notification corresponding to the event topic and based on a condition corresponding to the event schema being satisfied). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 5, the rejection of claim 1 is incorporated. Tallman as modified further discloses The system of claim 1, wherein the at least one processor is further configured to implement: a suggestion engine configured to generate a recommended workflow element based on at least one of the custom event or the custom action (Tremblay, ¶ 100, a suggestion generator 134 may generate one or more suggested topics 138, which may be presented in a user interface 152 of a content development management application 150), wherein an indication of the recommended workflow element is displayed via the GUI (Tremblay, ¶ 126, the methods and systems may further include a user interface 152 of the application 150 that presents a suggestion, wherein the generated suggestion is presented with an indicator of the similarity 154 of the suggested topic 138 to a topic in the content clusters 130). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 6, the rejection of claim 5 is incorporated. Tallman as modified further discloses The system of claim 5, wherein the recommended workflow element is further based on historical data associated with user interactions with the workflow platform (Tremblay. ¶ 138, system 158 may produce appropriate topics within the historical context of the customer and the customer's engagement with the enterprise. … while seeing suggested topics 138, indicators of relevance or similarity 154 and the like). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 7, the rejection of claim 6 is incorporated. Tallman as modified further discloses The system of claim 6, wherein the recommended workflow element is associated with a justification, and wherein the justification is displayed via the GUI (Baneva, col. 5, ln. 25-32, a graphical user interface that responds to a user-selected event topic by causing a corresponding event schema to be displayed, … to trigger a workflow based on an event notification corresponding to the event topic and based on a condition corresponding to the event schema being satisfied). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 8, the rejection of claim 1 is incorporated. Tallman as modified further discloses The system of claim 1, wherein the workflow engine is further configured to store the custom event and the custom action as workflow elements in the elements database (Tallman, col. 4, ln.66-col. 5, ln. 1, Database server 108 may be in communication with database 106. Database 106 is configured to store information on a variety of matters; col. 8, ln. 10-16, a workflow may be stored in database 106 with meta-data associated therewith. Thus, instead of requesting, receiving, and configuring external computing devices 112-116 for specific applications within a workflow, SMC device 104 may request, receive, and configure external computing devices 112-116 to execute a workflow as a whole). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 9, the rejection of claim 1 is incorporated. Tallman as modified further discloses The system of claim 1, wherein the custom event and the custom action are received using declarative programming (Baneva, Fig. 6, col. 23, ln. 47-67, at block 610, the workflow subscription GUI 470 generates a display having event topics. At block 620, the workflow subscription GUI 470 responds to user-selection of an event topic by causing a corresponding event schema to be displayed … the event schema includes a set of fields. … GUI 470 responds to user-selection of one of the fields of the event schema by collecting (from user-input) a threshold value. … the selected field of the event schema. … GUI 470 responds to the entry of the threshold value by supplying an event topic identifier identifying the selected event topic, a field identifier identifying the selected field and the threshold value [Thus, Baneva suggests that the custom event and custom action are received using declaration programming because Baneva’s configuration allows the user to declare what event/action relationship is to be used in the workflow, rather than requiring the user to write procedural program logic. Therefore, Baneva’s GUI based configuration of custom workflow elements teaches or at least renders obvious receiving the custom event and custom action using declarative programming).
As to claim 10, Tallman as modified discloses A method for managing a workflow using custom workflow elements (Tallman, Abstract, A system for creating surrogate models), the method comprising:
receiving, via a graphical user interface (GUI) (Tallman, Fig. 3, col. 9, ln. 13-23, providing a user interface to user 302 … A user interface may include, among other possibilities, a web browser and client application. Web browsers enable users, such as user 302, to display and interact with media):
a custom event comprising an event identity, an event name, and an event schema, wherein the event schema includes an association between the custom event and one of a plurality of predefined workflow elements (Baneva, Fig. 6, col. 23, ln. 47-67, at block 610, the workflow subscription GUI 470 generates a display having event topics. At block 620, the workflow subscription GUI 470 responds to user-selection of an event topic by causing a corresponding event schema to be displayed … the event schema includes a set of fields. … GUI 470 responds to user-selection of one of the fields of the event schema by collecting (from user-input) a threshold value. … the selected field of the event schema. … GUI 470 responds to the entry of the threshold value by supplying an event topic identifier identifying the selected event topic, a field identifier identifying the selected field and the threshold value), and
a custom action, wherein the custom action comprises a callback, a callback schema, an action, and an association between the custom action and one of the plurality of predefined workflow elements (Tremblay, Fig. 79B, ¶ 595, the custom code actions may each have a callback function; Fig. 82, ¶ 602, FIG. 82 shows a screenshot of a graphical user interface (GUI) 8200 for displaying an example custom code action … the code may specify what kind of data may be expected to output this custom code action. The reason for specifying this output may be so that the downstream actions may know and anticipate what to expect [It is noted that Fig. 82 and ¶ 602 teach specifying the data expected to be output by a callback, including defining output fields and associated data types (e.g., output field ‘phone’ of type String). Such definitions constitute a callback schema because they define the structure and format of callback data that downstream workflow actions consume. It is further noted that Tremblay teaches that a custom code action is added to a workflow and selected from a list of workflow actions (e.g., ¶ 595). Therefore, the custom code action is associated with a workflow element because it forms one of the execution workflow components with the workflow definition.]);
generating a workflow incorporating the custom event (Tallman, Fig. 2, col. 5, ln. 12-14, the generation and execution of a workflow; col. 7, ln. 24-45, new meta-data is generated regarding the workflow, and stored in the workflow. For example, new meta-data may include data indicating where the application was run (i.e., which external computing device 112-116 was used to run the application), which user requested the application or workflow using the application, how long it took to run the application, which configuration changes were made to the respective external computing device 112-116 to run the application, and which setup or settings files were used to run the application. The new meta-data is stored in the workflow, and SMC device 104 is configured to extract the new meta-data (i.e., new application meta-data 224) from final workflow output 222. … a user may be able to modify new application meta-data 224. For example a user may enter meta-data indicating their user experience with the applications or workflow; Fig. 5, generating 512, by the processor, based on execution of the workflow request, new meta-data associated with the at least one application) and/or the custom action (Tremblay, Fig. 79B, ¶ 595, the custom workflows actions system 564 allows for the creation of custom code actions for a workflow. For example, users may write and execute programming language (e.g., JavaScript) within a custom action in workflows);
generating an action request comprising an indication to perform the action based on the callback (Tremblay, ¶ 595, the custom code actions may each have a callback function (e.g., “callback( )”) that may be used to pass data back to the workflow (e.g., the callback function may be called [an action request] in the “exports” main function); ¶ 608, the callback may be a type of handle that may allow for passing of data. … the custom code action request may ask to obtain an object from an API), wherein the action request includes data (Tremblay, ¶ 595, there may be an event object in JSON such as an example payload that includes reference to a portal ID, custom action definition ID, type of CRM object that may be enrolled in workflow, and a unique ID for execution; ¶ 608, the callback may be a type of handle that may allow for passing of data) according to the callback schema (Tremblay, Fig. 82, ¶ 602);
receiving, via a public API, event data (Tremblay, ¶ 596, the custom workflow actions process (e.g., using the custom workflow actions system 564) may execute API calls out to other systems or into the internal API to get other data) associated with the event schema (Baneva, Fig. 6, col. 23, ln. 47-67, GUI 470 responds to user-selection of one of the fields of the event schema by collecting (from user-input) a threshold value. … the selected field of the event schema. … GUI 470 responds to the entry of the threshold value by supplying an event topic identifier identifying the selected event topic, a field identifier identifying the selected field and the threshold value);
determining the event data is valid based on a comparison of the event data to the event schema (Baneva, col. 16, ln. 31-52, the tenant administrator can use the template to select one (or more) of the fields in the event schema and to indicate a desired value against which a value stored in the field is to be evaluated … when the value stored in the selected field evaluates to (is equal to, greater than, less than, etc.) the desired value (e.g., True, False, a numerical value, etc.), the workflow is triggered. Thus, the field and the desired value together form a condition to be met and/or satisfied before the selected workflow is triggered. In some examples, the user-selectable conditions (in addition to including the event schema fields) also includes conditions that are more-generally related to the event topic (e.g., an event type, an event timestamp, a user name) and that are to be evaluated to determine whether the workflow will be triggered. Thus, the tenant administrator uses the template generated by the template generator 502 to identify the features/characteristics of the subscription (e.g., the workflow to be performed, an event topic upon which the operation of the workflow is to be predicated/based, and a condition and associated value to be met and/or satisfied before the workflow will be triggered/executed) [It is noted that Baneva teaches evaluating received event data using fields defined by the event schema and determining whether the event data satisfies criteria associated with those schema fields before triggering a workflow. Accordingly, Baneva teaches determining the validity of event data based on comparison of the event data to information defined by the event schema.]);
determining the custom event is associated with an active workflow subscription status (Kwan, col. 11, ln. 47-52, the API call responses (e.g., the API test call response 220) that are generated by the service within the service environment in response to one or more API calls (e.g., API test call 218, API calls of the subscription workflow, etc.) can be logged; col. 12, ln. 66-col. 13, ln. 4, the API test call response 220 may include an indication that the operation has been completed [an active workflow subscription status] by the service. In response, the content validation server 206 can be configured to access the operation endpoint to obtain the one or more output variables generated by the modified operation);
and sending, via an API callback gateway (ACGW), the action request (Shang, pg. 9, para. 2 from the bottom of the page, the invention arranges the workflow information corresponding to the API service, which can realize the service arrangement to the API gateway to correspond to a plurality of back end service, the request parameter of each back end service can be the parameter transmitted by the front end, It is also possible to be self-defined (write static parameters or from return data) obtain the arrangement. and can perform data processing (filtering, deleting, renaming, unpacking and packet operation) to the return result of each service).
The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 11, the rejection of claim 10 is incorporated. Tallman as modified further discloses The method of claim 10, wherein the action response includes an indication that the action was performed and a context (Kwan, col. 12, ln. 66-col. 13, ln. 4, the API test call response 220 may include an indication that the operation has been completed by the service. In response, the content validation server 206 can be configured to access the operation endpoint to obtain the one or more output variables generated by the modified operation). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claims 12-17, the claims are method claims corresponding to system claims 2-7. Therefore, they are rejected under the same rational set forth in the rejections of claims 2-7.
As to claim 18, the rejection of claim 10 is incorporated. Tallman as modified further discloses The method of claim 10, further comprising storing the custom event and the custom action as predefined workflow elements (Tremblay, ¶ 28, a content cluster data store for storing clusters of topics and a content development and management application having a user interface for developing content [Thus, one of ordinary skill in the art would readily comprehend that the custom event and the custom action as predefined workflow elements taught by Tremblay are also stored in the data store]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Tallman as modified with the teaching of Tremblay. The modification would be obvious because one of ordinary skill in the art would be motivated to store the custom event and the custom action as predefined workflow elements so that they may be reused across multiple workflows, reduce redundant configuration, improve consistency, and increase efficiency in workflow creation and management.
As to claims 19-20, the claims are corresponding to system claims 1 and 5. Therefore, they are rejected under the same rational set forth in the rejections of claims 1 and 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm).
If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/DAXIN WU/
Primary Examiner, Art Unit 2191
Prosecution Insights