CTNF 19/040,557 CTNF 73112 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This application has been examined. Claims 1-20 are pending. The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175. Specification 06-11 AIA The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. Claim Rejections - 35 USC § 112 07-30-02 The following is a quotation of the second paragraph of 35 U.S.C. 112: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 35 U.S.C. §112(b) requires claims to particularly point out and distinctly claim the subject matter of the invention with reasonable certainty when read in light of the specification and prosecution history. See Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898 (2014). Functional language that fails to define the metes and bounds of the claimed structure, and claim terms without adequate definition in the specification, render claims indefinite. See MPEP §2173. Claims 1, 9, 17 recite the limitation "persistent flow context” that functional/indefinite scope. Claims 1, 9, and 17 each recite “constructing a persistent flow context” and “dynamically and automatically integrating the disparate systems based on executing the tokens and the persistent flow context”. The term 'persistent flow context' is used as a term of art but is not defined in the claim and may not be defined with sufficient precision in the specification to establish the metes and bounds with reasonable certainty under Nautilus. The claim does not specify what data the persistent flow context stores, its structure, duration of persistence, or how it interacts with the token execution beyond “based on executing”. Claims 1, 9, 17 recite the limitation “integration patterns” that is undefined technical term. Claims 1, 9, and 17 recite “defines how the configurable and reusable components are interconnected utilizing integration patterns” and “by applying the integration patterns”. The term “integration patterns” has a recognized meaning in enterprise integration but is used broadly in the claims without specifying which patterns or what properties they have. The scope of “integration patterns” is indefinite and does it encompass any software pattern, or only patterns from a defined set? Claim 4 recites “rules for validating responses” that is functional language. Claim 4 recites “setting rules for validating responses received from the representational state transfer service”. The term “rules for validating” is broadly functional as it covers any rule that validates any aspect of any response. However, the term is used in a well-understood context (API response validation) and the specification likely provides adequate support. Claim 5 recites “custom domain-specific language” that is scope of “custom”. Claim 5 adds that the custom script is “defined in custom domain-specific language”. The qualifier “custom” before “domain-specific language” is ambiguous as does it mean user-defined DSL or any DSL (all DSLs are “custom” to their domain?). Claim 6 then recites the DSL “includes one or more of: OOP language, XML, static/dynamic language, and human-readable data serialization language” which these are extremely broad categories covering essentially any programming or data language. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 4. 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. 5. Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more Step 1: Claims 1-8 recite a method. Claims 9-16 recite a system. Claims 17-20 recite a non-transitory computer readable medium. Therefore, claims 1-8 are directed to a process, claims 9-16 are directed to a machine, and claims 17-20 are directed to a manufacture. With respect to claims 1, 9 and 17: 2A Prong 1: the claim recites a judicial exception. • creating configurable and reusable components designed to adapt to diverse integration needs of the disparate systems within an integration process; (mental process - evaluation or judgement; certain methods of organizing human activity). • generating a custom script corresponding to each component that defines how the configurable and reusable components are interconnected utilizing integration patterns; (mental process - evaluation or judgement; certain methods of organizing human activity). • implementing a dynamic flow executor within an integration framework that translates the custom script into actionable integration process components corresponding to the configurable and reusable components by applying the integration patterns and constructing a persistent flow context; (mental process - evaluation or judgement). • generating tokens to orchestrate execution of the actionable integration process components, wherein the tokens indicate a precise order of execution of the actionable integration process components as defined by the custom script; (mental process - evaluation or judgement; mathematical concepts - mathematical calculations). • dynamically and automatically integrating the disparate systems based on executing the tokens and the persistent flow context (mental process - evaluation or judgement; certain methods of organizing human activity). 2A Prong 2: This judicial exception is not integrated into a practical application. • (claim 1) one or more processors along with allocated memory ; (claim 9) a processor; a plurality of disparate systems; and a memory operatively connected to the processor and the disparate systems via a communication interface ; (claim 17) a non-transitory computer readable medium configured to store instructions (mere instructions to apply an exception - see MPEP 2106.05(g); the additional elements do not improve the functioning of the computer itself - the dynamic flow executor, token mechanism, and persistent flow context are recited in functional terms and describe improvements to system integration outcomes, not to computer processing, memory, or execution - see MPEP 2106.05(a); see also Customedia Techs. v. Dish Network , 951 F.3d 1359, 1365 (Fed. Cir. 2020); Two-Way Media v. Comcast , 874 F.3d 1329, 1338 (Fed. Cir. 2017)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • (claim 1) one or more processors along with allocated memory ; (claim 9) a processor; a memory operatively connected to the processor and the disparate systems via a communication interface ; (claim 17) a non-transitory computer readable medium configured to store instructions (mere instructions to apply an exception - see MPEP 2106.05(g); and WURC: generic processor executing instructions and generic memory storing data - see MPEP 2106.05(d)(II)(i)). With respect to claims 2, 10 and 18: 2A Prong 1: the claim recites a judicial exception. • wherein the configurable and reusable components correspond to integration blocks for integrating the disparate systems by exposing the integration process as configuration-as-code (mental process - evaluation or judgement; certain methods of organizing human activity - abstract software organizational methodology). 2A Prong 2: This judicial exception is not integrated into a practical application. • integration blocks exposing integration process as configuration-as-code (mere instructions to apply an exception - see MPEP 2106.05(g); does not improve the functioning of the computer itself - organizational methodology that does not alter computer processing or execution - see MPEP 2106.05(a)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • integration blocks exposing integration process as configuration-as-code (insignificant extra-solution activity - see MPEP 2106.05(f); and WURC: organizing software components as reusable configuration-defined blocks is well-understood, routine, and conventional - see MPEP 2106.05(d)(II)(i)). With respect to claims 3, 11 and 19: 2A Prong 1: the claim recites a judicial exception. • wherein one of the configurable and reusable components is a representational state transfer integration component within the integration process that exposes one or more configuration options (mental process - evaluation or judgement; certain methods of organizing human activity - abstract software architectural pattern). 2A Prong 2: This judicial exception is not integrated into a practical application. • a representational state transfer integration component exposing configuration options (mere instructions to apply an exception - see MPEP 2106.05(g); does not improve the functioning of the computer itself - REST is an abstract architectural style; specifying its use does not improve computer processing speed, memory, or performance - see MPEP 2106.05(a); see also Affinity Labs v. DirecTV , 838 F.3d 1253, 1262 (Fed. Cir. 2016)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • a representational state transfer integration component (insignificant extra-solution activity - see MPEP 2106.05(f); and WURC: REST architecture has been well-understood, routine, and conventional since Fielding (2000) - see MPEP 2106.05(d)(II)(i)). With respect to claims 4, 12 and 20: 2A Prong 1: the claim recites a judicial exception. • exposing an endpoint specifying a universal resource locator of a representational state transfer service to connect with (mental process - evaluation or judgement; mathematical concepts - abstract logical identifier). • defining a type of hypertext transport protocol request to be used; (mental process - evaluation or judgement; certain methods of organizing human activity - abstract protocol selection). • configuring a type of authentication needed to integrate the disparate systems; (mental process - evaluation or judgement). • setting rules for validating responses received from the representational state transfer service (mental process - evaluation or judgement; mathematical concepts - abstract logical conditions). 2A Prong 2: This judicial exception is not integrated into a practical application. • URL endpoint; HTTP request type; authentication type; response validation rules (mere instructions to apply an exception - see MPEP 2106.05(g); does not improve the functioning of the computer itself - standard REST API configuration parameters do not alter how the computer processes requests or improves computer performance - see MPEP 2106.05(a)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • URL endpoint; HTTP request type; authentication type; response validation rules (insignificant extra-solution activity - see MPEP 2106.05(f), mere parameter specification; and WURC: URL (RFC 3986), HTTP request types (RFC 2616), authentication (RFC 6749), and response validation are well-understood, routine, and conventional standard API configuration parameters - see MPEP 2106.05(d)(II)(i)). With respect to claims 5 and 13: 2A Prong 1: the claim recites a judicial exception. • defining the integration process in custom domain-specific language (mental process - evaluation or judgement; mathematical concepts - abstract formal notation system). 2A Prong 2: This judicial exception is not integrated into a practical application. • defining integration process in custom domain-specific language (mere instructions to apply an exception - see MPEP 2106.05(g); does not improve the functioning of the computer itself - a computer executes the same operations regardless of the notation used to express them - see MPEP 2106.05(a)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • defining integration process in custom domain-specific language (insignificant extra-solution activity - see MPEP 2106.05(f); and WURC: domain-specific languages for integration and workflow processes (BPEL, WSDL, Apache Camel DSL) have been well-understood, routine, and conventional since at least 2001-2007 - see MPEP 2106.05(d)(II)(i)). With respect to claims 6 and 14: 2A Prong 1: the claim recites a judicial exception. • wherein the custom domain-specific language includes one or more of the following: object-oriented programming language, extensible markup language, static and dynamic language, and human-readable data serialization language (mental process - evaluation or judgement; mathematical concepts - abstract categories of formal language systems). 2A Prong 2: This judicial exception is not integrated into a practical application. • OOP language, XML, static/dynamic language, human-readable data serialization language (mere instructions to apply an exception - see MPEP 2106.05(g); does not improve the functioning of the computer itself - naming conventional language categories adds no specific technical architecture that improves computer performance - see MPEP 2106.05(a)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • object-oriented programming language, extensible markup language, static and dynamic language, and human-readable data serialization language (insignificant extra-solution activity - see MPEP 2106.05(f); and WURC: OOP languages (Java/C++/Python), XML (W3C 1996), static/dynamic languages, and serialization languages (JSON RFC 4627/YAML) represent the most foundational and universally used software technologies - see MPEP 2106.05(d)(II)(i)). With respect to claims 7 and 15: 2A Prong 1: the claim recites a judicial exception. • tracking each step of the integration process in real time by utilizing a user interface (mental process - observation; collecting, analyzing, and displaying information in real time is an abstract idea - see Electric Power Group v. Alstom, 830 F.3d 1350 (Fed. Cir. 2016)). 2A Prong 2: This judicial exception is not integrated into a practical application. • tracking each step in real time via a user interface (insignificant extra-solution activity - see MPEP 2106.05(f), post-solution display activity; does not improve the functioning of the computer itself - displaying information on a generic user interface does not improve computer processing or execution - see MPEP 2106.05(a); see also Interval Licensing v. AOL , 896 F.3d 1335 (Fed. Cir. 2018)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • tracking each step in real time by utilizing a user interface (insignificant extra-solution activity - see MPEP 2106.05(f), post-solution display activity; and WURC: real-time monitoring dashboards are well-understood, routine, and conventional in integration platforms - see MPEP 2106.05(d)(II)(i)). With respect to claims 8 and 16: 2A Prong 1: the claim recites a judicial exception. • wherein the persistent flow context represents a durable blueprint of the integration process (mental process - evaluation or judgement; abstract data concept). • detecting errors in the integration process; (mental process - evaluation or judgement; mathematical concepts - abstract conditional evaluation). • automatically notifying a user of the dynamic flow executor the detected errors; (mental process - evaluation or judgement; certain methods of organizing human activity - abstract notification concept). • executing automatic retries to resolve the detected errors (mental process - evaluation or judgement; mathematical concepts - abstract iterative loop). 2A Prong 2: This judicial exception is not integrated into a practical application. • durable blueprint (persistent execution state); detecting errors; automatically notifying a user; executing automatic retries (mere instructions to apply an exception - see MPEP 2106.05(g); does not improve the functioning of the computer itself - error detection, notification, and retry are functional descriptions of what the computer achieves, not how the computer itself is technically improved; result-oriented functional language without a specific technical mechanism does not satisfy MPEP 2106.05(a); see Two-Way Media v. Comcast , 874 F.3d 1329, 1338 (Fed. Cir. 2017)). 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. • durable blueprint; detecting errors; automatically notifying a user; executing automatic retries (insignificant extra-solution activity - see MPEP 2106.05(f), post-solution activity; and WURC: error detection (exception handling), automatic notification, and automatic retry logic are well-understood, routine, and conventional software resilience patterns - see MPEP 2106.05(d)(II)(i); see Tanenbaum & Van Steen, Distributed Systems (2002); Hohpe & Woolf, Enterprise Integration Patterns (2003)). Claim Rejections - 35 USC § 103 07-20-aia AIA 6. 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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 7. Claims 1-20 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Perkins et al. (“Perkins”) (US Pub No. 2002/0038309) in view of Thalangara et al. (“Thalangara”) (US Pub No. 2003/0195785). In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art. The examiner relies on the entire teachings of Perkins and Thalangara references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position. In regard to claim 1, Perkins discloses a method for integrating disparate systems by utilizing one or more processors along with allocated memory, the method comprising: creating configurable and reusable components designed to adapt to diverse integration needs of the disparate systems within an integration process (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Perkins discloses ¶ [0007]-[0008]: “Argon is a collection of pre-built software components that can be used to dramatically reduce the amount of effort required to develop, deploy, and maintain contact center solutions”. ¶ [0056]: “Adapter objects are responsible for communicating with systems that are external to Argon” which the multiple external systems are “disparate systems”. ¶ [0062]-[0065]: The CTI client application integrates a telephony server (first disparate system) and a web browser (second disparate system) via the Argon framework. Fig. 1: General engine-adapter model with multiple external systems. ¶ [0007]-[0008]: Argon is “a collection of pre-built software components”. ¶ [0056]: “Each adapter object translates between the Argon messaging protocol (AMP) and whatever protocols or interfaces are supported by the associated external system” thus the adapters ARE the configurable and reusable components, each designed to adapt to the diverse needs of different external (disparate) systems. ¶ [0072]-[0076]: Adapters are deployed and reused across different system configurations. Fig. 1 (engine-adapter model): multiple adapter components shown as reusable elements around a central engine. Fig. 8: custom adapter server class diagram showing how adapters are customized and reused); PNG media_image1.png 450 673 media_image1.png Greyscale generating a custom script corresponding to each component that defines how the configurable and reusable components are interconnected utilizing integration patterns (in Perkins, ¶ [0057]-[0060]: “When the engine is created it is given the URL of a server-side script that produces the configuration. The configuration object connects to the URL and receives a stream of XML. Contained within the XML are the rules that define how the engine distributes messages among the associated adapters”. Thus the server-side script is the custom script; the XML rules define how adapter components are interconnected. ¶ [0043]: “The task of creating the server-side script that displays business content in the Argon web client can be given to a web developer”. ¶ [0015]: “an IVR script is written that defines the behavior of the IVR” which is custom scripts per component. Fig. 2: configuration object receiving XML script from server-side script that defines interconnection rules (i.e. integration patterns); implementing a dynamic flow executor within an integration framework that translates the custom script into actionable integration process components corresponding to the configurable and reusable components by applying the integration patterns and constructing a persistent flow context (in Perkins, ¶ [0055]-[0059]: The Argon engine is the dynamic flow executor within the integration framework. “The purpose of the engine is to distribute Argon messages among adapter objects according to the rules that are specified in the engine's configuration” which the engine translates the XML script/rules into actionable adapter interactions. ¶ [0058]-[0060]: Engine creates a configuration object, connects to the XML-producing script, and parses the XML rules to configure adapters which this is translating the custom script into actionable integration process components. ¶ [0074]: The Argon runtime environment maintains state across operations thus the runtime environment is the persistent flow context. Fig. 1: engine (flow executor) with adapters (actionable components). Fig. 2: configuration/translation mechanism); generating tokens [unique transaction ID] to orchestrate execution of the actionable integration process components, wherein the tokens indicate a precise order of execution of the actionable integration process components as defined by the custom script (in Perkins, uses unique transaction IDs on request messages (¶ [0087]-[0088]: “A request message generates a unique transaction identifier that is used to match the request with the associated response”; and dynamically and automatically integrating the disparate systems based on executing the tokens and the persistent flow context (in Perkins, ¶ [0041]: “any changes that you make using the Argon Administration Client will take effect when the next contact center agent logs in to a web client” (i.e. dynamic automatic reconfiguration). ¶ [0056]: The engine automatically distributes messages among adapters (disparate systems) based on rules (i.e. dynamic and automatic integration). ¶ [0074]-[0076]: Automatic load balancing and dynamic deployment of adapters for disparate system integration. The engine's execution of the XML-configuration rules (i.e. executing the flow context) automatically integrates the disparate systems). But Perkins does not specifically disclose the technique of generating token to orchestrate execution of the actionable integration process components, wherein the tokens indicate a precise order of execution of the actionable integration process components as defined by the custom script. The same field of endeavor, Thalangara primarily discloses the technique of generating token to orchestrate execution of the actionable integration process components, wherein the tokens indicate a precise order of execution of the actionable integration process components as defined by the custom script (as shown in Fig. 12, which is reproduced below for ease of reference and convenience, Thalangara discloses ¶ [0002]: “A workflow management system utilizes tokens associated with work flowing through paths of activities or tasks under control of constructs”. ¶ [0124]: The workflow system is implemented on a computer system with a processor and memory (Fig. 13, element 2120: processor; element 2125: memory). The workflow integrates multiple disparate activities/systems in a defined process. ¶ [0030]-[0031]: “The functions described herein are implemented in software…the embodiments described are merely examples. Multiple functions are performed in one or more modules as desired”. Activities and constructs (splits/joins) are reusable components designed for different workflow needs. The token management modules are configurable and reusable across diverse workflow processes. Furthermore, Thalangara is directed to token-based execution ordering. “Tokens are given attributes for activities and constructs, such as token value and construct IDs. Rules are defined for activities and constructs to use when receiving, modifying and passing on the tokens. The tokens provide the ability to control flow of the work, such as sequencing, paralleling, iterating and synchronizing activities”. Also ¶ [0012]-[0013]. ¶ [0057]-[0063]: Token generation at each node (split, join, activity) with incrementing TokenValue thus tokens carry precise execution order. ¶ [0064]: 'With the token the state of a process is identifiable at a given point of time”. Fig. 13: workflow engine with processor + memory executing token algorithm. Fig. 14-15 + Tables 1-2: explicit token-by-token execution sequencing tables showing precise order of execution). PNG media_image2.png 512 459 media_image2.png Greyscale It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to a person having ordinary skill in the art to incorporating a token-based control flow mechanism as taught by Thalangara into Perkins’ integration framework that would provide significant improvements, including better handling of complex, branching, and condition integration patterns; more reliable dynamic execution of integration processes; and improved state persistence across distributed or long-running integrations. In regard to claim 2, Perkins discloses wherein the configurable and reusable components correspond to integration blocks for integrating the disparate systems by exposing the integration process as configuration-as-code (in Perkins, ¶ [0007]-[0008] + Fig. 1, 8: Argon adapter components are pre-built software “integration blocks” that each adapter exposes the external system's integration interface as configurable parameters. ¶ [0057]-[0060]: Configuration is specified entirely via XML script (configuration-as-code) that the integration process is defined and exposed through a configuration script rather than hard-coded logic. ¶ [0043]: Script-based configuration allowing non-CTI developers to define integration behavior = configuration-as-code pattern). In regard to claim 3, Perkins discloses wherein one of the configurable and reusable components is a representational state transfer integration component within the integration process that exposes one or more configuration options (in Perkins, ¶ [0039]-[0041]: The Argon Web Client is accessed via URL navigation (i.e. implementing REST (REpresentational State Transfer)) architecture. ¶ [0065]: Portal adapter “translates between calls to the browser interface and Argon messages” which the portal adapter is a REST-style integration component. The Argon Administration Client exposes configuration options (what URL to load, what data to pass) = exposing configuration options for the REST component. Fig. 3: CTI client application with portal adapter showing URL-based (REST) integration component with configurable options). In regard to claim 4, Perkins discloses wherein in exposing one or more configuration options, the method further comprising: exposing an endpoint specifying a universal resource locator of a representational state transfer service to connect with corresponding to the representational state transfer integration component (in Perkins, ¶ [0039]-[0041]: “The agent simply navigates their browser to the designated universal resource locator (URL) and logs in” that (a) endpoint URL specified); defining a type of hypertext transport protocol request to be used (in Perkins, ¶ [0014]-[0018]: IVR script, routing script configure HTTP-based request behavior which (b) HTTP request type configured); configuring a type of authentication needed to integrate the disparate systems (in Perkins, ¶ [0014]-[0018]: IVR script, routing script configure HTTP-based request behavior which (b) HTTP request type configured. ¶ [0039]: “logs in” as (c) authentication configured. ¶ [0024]-[0027]: Interaction reports validate responses from integrated systems (i.e. response validation rules)); and setting rules for validating responses received from the representational state transfer service (in Perkins, ¶ [0060]: “The server-side script generates the XML by querying the Argon configuration database” as database stores endpoint, auth, validation rules as configuration. Fig. 2: configuration object storing all integration parameters including URL endpoint, auth credentials, and response rules). In regard to claim 5, Perkins discloses wherein in generating the custom script, the method further comprising: defining the integration process in custom domain-specific language (in Perkins, ¶ [0058]-[0060]: “The configuration object connects to the URL and receives a stream of XML. Contained within the XML are the rules that define how the engine distributes messages among the associated adapters”. The XML configuration is a custom domain-specific language (DSL) defining the integration process. ¶ [0043]: The XML script is a purpose-built language for defining integration behavior that it is domain-specific to the integration framework. But Perkins does not specifically disclose custom domain-specific language. In the same field of endeavor, Thalangara discloses custom domain-specific language (¶ [0032]: “A first part describes constructs such as splits and joins” that is the workflow definition language using splits, joins, activities, and token rules is a domain-specific language for workflow integration). It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to a person having ordinary skill in the art to incorporating a custom domain-specific language (or script approach), as taught by Thalangara into Perkins’ integration framework that would provide suitable for defining workflow logic, control flow, and execution rules in a dynamic environment. In regard to claim 6, Perkins discloses wherein the custom domain-specific language includes one or more of the following: object-oriented programming language, extensible markup language, static and dynamic language, and human-readable data serialization language (in Perkins, ¶ [0058]: XML used for configuration = XML (extensible markup language) and human-readable data serialization. ¶ [0073]: “Argon is written in Java” (i.e. OOP language)). ¶ [0021]: “custom written in Microsoft Visual Basic, Java, or C++” (i.e. OOP and static/dynamic languages). Fig. 7-8: UML class diagrams for Java implementation (i.e. OOP)). In regard to claim 1, Perkins discloses further: tracking each step of the integration process in real time by utilizing a user interface (in Perkins, ¶ [0023]-[0027]: Interaction reports track performance of each step of the integration process in real time that includes queue lengths, wait times, agent handling times). ¶ [0024]-[0025]: Wrap-up codes track outcomes of each interaction step. ¶ [0040]-[0041]: The Argon Web Client UI displays real-time integration process state. ¶ [0041]: Administration Client provides real-time UI for monitoring and modifying the integration process. Fig. 3: portal adapter/web client UI tracks and displays each step of the integration process in real time. In regard to claim 8, Perkins discloses wherein the persistent flow context represents a durable blueprint of the integration process, and the method further comprising: detecting errors in the integration process (in Perkins, ¶ [0074]-[0076]: The Argon runtime environment is the persistent/durable blueprint as it maintains configuration state durably across all integration operations. ¶ [0056]: The engine enforces rules and detects message distribution failures (i.e. error detection). ¶ [0079]-[0082]: ODBC database server stores configuration information persistently); automatically notifying a user of the dynamic flow executor the detected errors (in Perkins, ¶ [0018]: “the call waits in a call queue” that implicit retry mechanism for failed routing. ¶ [0079]-[0082]: ODBC database server stores configuration information persistently). But Perkins does not teach executing automatic retries to resolve the detected errors. In the same field of endeavor, Thalangara expressly teaches executing automatic retries to resolve the detected errors (in Thalangara, ¶ [0013]-[0014]: Tokens maintain persistent state of the workflow execution, providing the durable blueprint. ¶ [0056]-[0063]: Token management inherently detects flow anomalies (incorrect join synchronization) and corrects them (i.e. automated error handling). It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to a person having ordinary skill in the art to incorporating the error handling and retry features, as taught by Thalangara, into Perkins’ integration framework that would increase resilience and reliability of long-running integration processes that rely on a durable/persistent flow context (as taught in both references); furthermore to reduce manual intervention by automatically detecting errors and retries when appropriate). Claims 9 through 16 (system claims) and claims 17 through 20 (non-transitory computer readable medium claims) are rejected under 35 U.S.C. §103 for the same reasons as claims 1-8. Claims 9 and 17 are independent system and CRM claims that are structurally parallel to method claim 1, reciting the same elements in system and CRM form respectively. Claims 10-16 and 18-20 mirror dependent claims 2-8. The element-by-element mapping for claims 1-8 applies with equal force to claims 9-16 and 17-20, with the processor/memory of claim 9 corresponding to the computer system of Thalangara (¶ [0124], Fig. 13) and the processor+memory+communication interface of claim 9 corresponding to the Argon runtime environment of Perkins (¶ [0073]-[0076]). Examiner's note : Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner. Conclusion 8. All claims are rejected. 07-96 9. The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. Klemm et al. (US No. 7,124,413) disclose a framework and method for integrating disparate legacy and new systems on a computing network; application integration layer allows applications using different messaging formats to communicate; network integration layer provides disparate network protocol integration. Shukla et al. (US No. 8,170,901) disclose an Extensible framework with reusable components for workflow design; designer component translating workflow into user-designated language; reusable components with cross-cutting behaviors applied declaratively; validation component; framework executing selected workflow portions. Pujol et al. (US No. 7,574,511) disclose a service integration framework with back-end connectivity framework, utility framework services, and business integration framework; exposes common services to business services; structural model of BIF interaction with Integration Framework. Shukla et al. (US No. 11,645,055) disclose a design microservice with UI framework and components in domain-specific language; runtime worker container with ESB framework and components; custom flow step development kit; automatically creating new UI and runtime ESB components from custom flow step build logic; deploying new components to design service and runtime container. Van Wyk et al. (US Pub No. 2008/0155518) disclose the tokenizing workflow process objects to create variable/configurable business process templates. Users create business processes with variable components; tokens are generated representing variable process elements deployable in different environments. Wunderlich et al. (US Pub No. 2014/0223408) disclose the SOA integration projects creating reusable components for diverse integration scenarios; BPEL projects/scopes saved as templates for reuse in later projects; build reusable components to combat technical debt. 10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300. Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [ raymond.phan@uspto.gov ]. 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, Andrew Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100. /RAYMOND N PHAN/ Primary Examiner, Art Unit 2175 Application/Control Number: 19/040,557 Page 2 Art Unit: 2175 Application/Control Number: 19/040,557 Page 3 Art Unit: 2175 Application/Control Number: 19/040,557 Page 4 Art Unit: 2175 Application/Control Number: 19/040,557 Page 5 Art Unit: 2175 Application/Control Number: 19/040,557 Page 6 Art Unit: 2175 Application/Control Number: 19/040,557 Page 7 Art Unit: 2175 Application/Control Number: 19/040,557 Page 8 Art Unit: 2175 Application/Control Number: 19/040,557 Page 9 Art Unit: 2175 Application/Control Number: 19/040,557 Page 10 Art Unit: 2175 Application/Control Number: 19/040,557 Page 11 Art Unit: 2175 Application/Control Number: 19/040,557 Page 12 Art Unit: 2175 Application/Control Number: 19/040,557 Page 13 Art Unit: 2175 Application/Control Number: 19/040,557 Page 14 Art Unit: 2175 Application/Control Number: 19/040,557 Page 15 Art Unit: 2175 Application/Control Number: 19/040,557 Page 16 Art Unit: 2175 Application/Control Number: 19/040,557 Page 17 Art Unit: 2175 Application/Control Number: 19/040,557 Page 18 Art Unit: 2175 Application/Control Number: 19/040,557 Page 19 Art Unit: 2175 Application/Control Number: 19/040,557 Page 20 Art Unit: 2175 Application/Control Number: 19/040,557 Page 21 Art Unit: 2175 Application/Control Number: 19/040,557 Page 22 Art Unit: 2175 Application/Control Number: 19/040,557 Page 23 Art Unit: 2175
Prosecution Insights