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 . 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 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.
DETAILED ACTION
This Final Office Action is in response Applicant communication filled 05/29/2026.
Status of Claims
Claims 1-6, 8-14, 16-20 have been amended by Applicant.
Claims 1-20 are currently pending and have been rejected as follows.
Response to Amendments / Arguments
Applicant’s 05/29/2026 amendment necessitated new grounds of rejection in this action.
A. Response to Applicant’s rebuttal of Rejections Under 35 U.S.C. § 112(b)
112(b) rejections in the previous act are withdrawn in view of Applicant’s amendment.
B. Response to Applicant’s rebuttal of Rejections Under 35 U.S.C. § 101
Step 2A prong one: Remarks 05/29/2026 p.12 highlights in bold limitations to argue at Id. p.13 ¶1 that claim 1 is non-abstract as directed to event message interceptor capturing message payloads from integration services application layer interface, a producer client providing the message payloads to a streaming server as input topics, the streaming server providing input & output topic streams to consumer clients, consumer client applying transformation rules to generate transformed payloads, and producer client providing transformed payloads as output topics to the streaming server. Remarks 05/29/2026 p.13 ¶2 then cites Original Specification ¶ [0075],¶ [0087],¶ [0090],¶ [0107] to argue claim 1 describes technical solution for asynchronous data processing that decouples data analysis workflows from production application traffic, with the producer and consumer clients argued not directed to business entities because the producer client is argued to provide, (publish or write) data to a streaming server, while the consumer client is argued to read (and/or receive) message data from one or more topics on a streaming server.
Examiner fully considered the Applicant’s argument Step 2A prong one but respectfully disagrees finding it unpersuasive.
-> i. First, with respect to the Applicant’s reliance on the Original Specification, the Examiner reminds Applicant that the “101 inquiry must focus on language of Asserted Claims themselves” as in “Synopsys, Inc. v Mentor Graphics Corp, U.S. Court of Appeals Federal Circuit, No 2015-1599, October 17 2016 2016 BL 344522 839 F3d 1138” citing “Accenture Global Servs., GmbH
PNG
media_image1.png
1
1
media_image1.png
Greyscale
v
PNG
media_image1.png
1
1
media_image1.png
Greyscale
. Guidewire Software, Inc. 728
PNG
media_image1.png
1
1
media_image1.png
Greyscale
F.3d
PNG
media_image1.png
1
1
media_image1.png
Greyscale
1336, 1345 108 USPQ2d 1173 Fed Cir. 2013: admonishing that the important inquiry for a 101 analysis is to look to the claim”, citing “Content Extraction & Transmission LLC
PNG
media_image1.png
1
1
media_image1.png
Greyscale
v.
PNG
media_image1.png
1
1
media_image1.png
Greyscale
Wells Fargo Bank Nat’l Ass’n 776
PNG
media_image1.png
1
1
media_image1.png
Greyscale
F3d
PNG
media_image1.png
1
1
media_image1.png
Greyscale
1343, 1346 113 USPQ2d 1354 (Fed. Cir. 2014): We focus here on whether the claims of the asserted patents fall within the excluded category of abstract ideas”, cert. denied, 136 S Ct 119, 193 L. Ed. 2d 208 2015). This is consistent with MPEP 2103 I.C stating that “claims define the property rights provided by patent, thus require careful scrutiny. The goal of claim analysis is to identify boundaries of protection sought by applicant and to understand how claims relate to and define what applicant indicated is the invention. USPTO personnel must first determine the scope of a claim by thoroughly analyzing the language of claim before determining if claim complies with each statutory requirement for patentability”. Simply said “[T]he name of the game is the claim”.
-> ii. Second, Examiner points to Applicant’s admission at Remarks 05/29/2026 p.13 ¶2 that the producer client provides or publish data to a streaming server, while the consumer client reads (and/or receive) message data from one or more topics on a streaming server. As articulated by Non-Final Act 03/04/2026 p.3-p.4 these represent examples of abstract business or commercial interactions, which as tested per MPEP 2106.04 (a) (2) II B and/or C, fall within the broad grouping of Certain Methods of Organizing of Human Activities. For example MPEP 2106.04(a)(2) II B cites Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 714-15, 112 USPQ2d 1750, 1753-54 (Fed. Cir. 2014), where the Federal Circuit found that eleven-step method for displaying an advertisement (ad) [akin here to an “output topic”] in exchange for access to copyrighted media [akin here to an “input topic”, and “input topic streams”], comprising the steps of receiving copyrighted media [akin here to “a set of one or more event message payloads associated with one or more messages between one or more application programming interfaces or integrator elements and a set of one or more downstream applications”], selecting an ad [akin here to “receiving”… “using a consumer client of the set of one or more consumer clients, an event message payload of the set of one or more event message payloads from an input topic stream of the set of one or more input topic streams”], offering the media in exchange for watching the selected ad, displaying the ad, allowing the consumer access to the media [akin here to “providing” “using the producer client, the transformed event message payloads as an output topic to the streaming server, wherein the output topic corresponds an output topic stream of the set of one or more output topic streams”] fell within the abstract commercial interactions of Certain Methods of Organizing of Human Activities. According to the claim mapping to Ultramercial’s case law above, the Examiner makes a similar case for the current claims setting forth the abstract exception. This finding is corroborated by MPEP 2106.04(a)(2) II ¶6, 4th sentence which states that the abstract sub-groupings of Certain Methods of Organizing of Human Activities encompass activity that involves multiple people (such as a commercial interaction), and activity between such persons and a computer. It then follows that here, analogous activities between “producer client” and “consumer client” such as “providing” “the set of one or more event message payloads as a set of one or more input topics to a streaming server” and “receiving”, “using a consumer client of the set of one or more consumer clients, an event message payload of the set of one or more event message payloads from an input topic stream of the set of one or more input topic streams”; and finally “providing”, “using the producer client, the one or more” “event message payload as an output topic to the streaming server, wherein the output topic corresponds an output topic stream of the set of one or more output topic streams” do not preclude the claims to recite or at least describe or set forth the abstract “Certain Methods of Organizing of Human Activities” grouping.
-> iii. Third, as per the transformed payloads as output topics to streaming server, and as per the asynchronous data processing that decouples data analysis workflows from application traffic, the Examiner reincorporates the findings and rationales at Non-Final Act 03/04/2026 p.4-p.5 ¶1, revealing that when tested per MPEP 2106.04(A)(2) III C #2, such level of computerization, given the claim breath and claim construction under MPEP 2111, can be argued to represent a computer environment upon which the abstract distribution of information or content as “payload messages” or “topic streams” is being performed. For example, in FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed Cir. 2016) cited by MPEP 2106.04(A)(2) III C #2, the Federal Circuit found storing, accessing, compiling and combining of information from disparate information sources based on rules, to generate a full picture of activity, identity, frequency of activity, and the like in such computer environment, still set forth the abstract selecting of information, by content or source, for collection, analysis, and announcement. Specifically, the claims in FairWaning referred to use of such storing, accessing, compiling and combining of information from disparate information sources in a healthcare-based system in a manner not meaningfully different than what is exemplified here at Original Specification
¶ [0003], and later expended to banking, education and retail etc. in light of Original Specification ¶ [0025] last sentence. Here, given the breadth of the independent Claims 1,8,17, the “generating” [of] “transformed event message payload by applying one or more data transformation rules” can be argued as such an abstract example of rule-based compiling of information as in FairWaning supra, while the “integrator” corresponds to such abstract Example of rule-based combining as in Fairwarning, and the “one or more input topic streams” “decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications” corresponds to the disparate information sources of FairWarning.
Next, in an abundance of caution, the Examiner will more granularly test the transformed payloads as output topics to streaming server and the asynchronous data processing to decouple data analysis workflows at the subsequent steps to find that, even when considered as additional computer-based elements, such features do not save the claims from patent ineligibility.
** Specifically, the recitation “transformed event message payload by applying one or more data transformation rules” (independent Claims 1,9,17), argued at Remarks 05/29/2026 p.13 ¶1, is tested on MPEP 2106.04(a)(2) I A, and interpreted as rule based mathematical relationship(s) expressed in words with MPEP 2106.05(c)1 further explaining that manipulation of basic mathematical constructs [akin here to “transformation rules”] or the paradigmatic ‘abstract idea has not been deemed a transformation capable to render the claims patent eligible. Indeed, right from the onset, MPEP 2106.04(a)(2) I A iv. explained that organizing information and manipulating information through mathematical correlations by generating first and second data by taking existing information, manipulating the data using mathematical functions, and organizing this information into a new form remain abstract. These are set forth here by “transformed event message payload by applying one or more data transformation rules” (independent Claims 1,9,17), without providing a patent eligible transformation as necessitated by MPEP 2106.05(c).
** As per the recitation of “(ii) the set of one or more input topic streams is provided to the set of one or more consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications”, at independent Claims 1,9,17 and also argued by Applicant at Remarks 05/29/2026 p.13 ¶1, the Examiner notes that the phrase “in a manner that is decoupled” at paragraph (ii), within the parent “wherein” limitation can perhaps be argued as an expression of intended use or intended result with limited patentable weight2. A similar argument can be made with respect to the limited patentable weight of an wherein limitation, tested per MPEP 2111.04, and relevant here to the general recitation of “wherein the set of one or more event message payloads is asynchronously captured from an integration services application layer interface” at Claims 1,9,17.
In any event, the Examiner submits that, even if full patentable weight is given for the asynchronous data decoupling, it would still not render the claims 1,9,17 patent eligible because, when tested per MPEP 2106.05(g), it would represent an extra solution activity with respect to the fundamental and/or commercial process of organizing human activities between the consumer and producer clients, as previously identified above. Examiner follows MPEP 2106.05(g) ¶3, 2nd sentence to submit that: evaluation of well-understood, routine, conventional consideration (see MPEP 2106.05(d)), and the field of use and technological environment consideration (see MPEP 2106.05(h)) may assist examiners in making a determination of whether an element (or combination of elements) is insignificant extra-solution activity. This leads the analysis to MPEP 2106.05(d) I 2 (c), with the Examiner pointing to the following citations of the following publications that demonstrate, by preponderance of evidence, that the asynchronous data decoupling is well-understood, routine or conventional:
- US 20050210109 A1 ¶ [0003] 1st sentence: At its core, the conventional messaging system permits separate, uncoupled applications to reliably communicate in an asynchronous manner
- What are asynchronous integrations, sharelogic, waybackmachine, Dec 1, 2023 defining at its first page, first paragraph: Asynchronous integrations as critical mechanism in modern software architecture that enable exchange of data and information between different systems or components without requiring immediate or synchronous response with Decoupling defines at the first page, 5th bullet point as: Asynchronous integrations decouple systems, reducing interdependencies and allowing for greater flexibility in system design and maintenance
- Hu et al, Type-Safe Eventful Sessions in Java, ECOOP 2010,LNCS 6183,p329-p353, Springer, 2010 disclosing at its first page under the Introduction chapter: Asynchronous event-driven programming is characterised by a reactive flow of control driven by the occurrence of computation events. It is one of the major paradigms in concurrent and communication-based programming, where events are typically detected by the arrival of messages on asynchronous channels. Primary motivations for asynchronous event programming include performance and scalability, particularly for high-concurrency applications such as Web servers. Then again disclosing at its 3rd sentence under Chapter 2: Event-Driven Session Programming: “The performance and scalability of event-based systems come from the asynchronous decoupling of event handlers from the event source (e.g. the network interface) through the event loop, which enables many concurrent sessions to be serviced as a fine-grain sequential interleaving of actions within a single thread or a thread pool”.
- What is Event Driven Integration, solace, archives org, archives org, January 2025, defining at its first and third pages: event driven integration as an integration pattern in which independent IT components communicate in a decoupled manner by publishing and subscribing to events. Also, Asynchronous event-driven communication is defined to decouple applications and devices so they can both send and receive information without any sort of active connection with the system at the other end. Indeed recipients can even receive information that was ben sent while they were offline or unable to keep up with the flow of information, without impacting the source or other target systems.
- Introduction to Decoupling Techniques, technebo, wayback machine, July 21, 2024, defining at its first page: “Asynchronous decoupling allows components to communicate without waiting for each other. Messages are sent to a queue or topic, and the receiving component processes them independently”
- Decouple Processing, SAP, wayback machine, Jan 21, 2024, defining at it page 1: Asynchronous decoupling as processing of an integration scenario that is decoupled asynchronously between the sender and the integration flow
- Rachel Richardson, Understanding asynchronous messaging for microservices, AWS webapages, Nov 22, 2019 defining at its first page Asynchronous messaging is a fundamental approach for integrating independent systems, or building up a set of loosely coupled systems that can operate, scale, and evolve independently and flexibly. As our colleague Tim Bray said, “If your application is cloud-native, or large-scale, or distributed, and doesn’t include a messaging component, that’s probably a bug.” In this blog post, we will outline some fundamental benefits of asynchronous messaging for the communications between microservices.
- Simon Emmanuel Rivas, Building synchronous APIs on asynchronous event bus using Azure Service Bus, middleway pages, July 2020 explain at its first page that decoupling is as basic best practice, with time decoupling defined as using an asynchronous event/message bus, and with Azure Service Bus, being asynchronous in nature
- Lutz Huhnken Blog, What Kind of Asynchronous is Right For You, June 15, 2023, disclosing Asynchronous Option 3: Event-driven Communication as real runtime decoupling,
- Rafael Gonzaga, Communication between microservices Asynchronous, Dec 3, 2023, disclosing in detail examples with code of asynchronous communication between microservices ranging from low decoupling to no dependency
- How can Microservices be isolated and communicate at the same time, reddit, July 5th, 2021 disclosing implementation of message queue for asynchronous services through Kafka when one of the surcribing services are down. next time they’re up the system works as intended
- Half Sync Half Async Pattern in Java, Enhancing System Performance with Dual Processing, javadesignpatterns pages, Jan 25,2022 disclosing the system perform tasks in response to external events that occur asynchronously, like hardware interruptions in OS
- Wittig Andreas, Integrate SQS and Lambda serverless architecture for asynchronous workloads, cloudonaut, May 19, 2017 dislosing at its first and second pages: SQS queue for asynchronous decoupling: sending out massive amounts of emails, transcoding video files after upload, or analyzing user behavior.
- Romain, Why Asynchronous Event-Driven Frameworks Are Critical for Real-Time Data Processing, medium webpages, Feb 24,2023 disclosing that Asynchronous event-driven frameworks use an event loop to handle incoming events and messages. The event loop processes events as they arrive, triggering the appropriate code to handle each event. These architectures enable the decoupling of rule-based services to microservices that consume and share data based on events. Thus, systems are not dependent on a specific message…
By decoupling the components of the system, developers can add or remove event producers and consumers dynamically, without affecting the other services. This allows for different services to be implemented in different languages or technologies, and enables the use of different encoding formats like JSON, XML, or Avro... The use of an event-driven architecture provides a resilient system due to the decoupling of its components
- Mezzalira et al, Creating an Asynchronous Ingestion Pattern Following Mia-Platform Fast Data Architecture, awx webpages, Oct 24, 2022, disclosing at its first page: an asynchronous pattern for ingesting data from legacy systems, collecting it into projections, and aggregating it into single views. The purpose of this solution is to decouple the source systems where data is stored from the external channels that request data. This ensures both offloading of source systems and makes data available to channels 24/7 and in near real-time.
- Self-contained Systems SCS, scs architecture org, wayback machine, October 3, 2023, disclosing at its second page: Asynchronous dependencies
- Decoupling When to use a broker like SAP Event Mesh, integration-excellence pages, wayback machine, Oct 2, 2023 disclosing at its first page: decoupling to remove dependencies between systems, with runtime dependencies solved with asynchronous messaging, where the sender (system) can submit a message to the middleware and this is independent from the availability of the receiver.
Accordingly, the argument is found unpersuasive because there is a preponderance of both legal and factual evidence showing the claims still recite, describe or set forth the abstract exception with the computerized environment or tools incapable to save the claims from patent ineligibility because even when subsequently testing the argued computerization, it merely represents an extra solution activity with features that remains conventional.
Step 2A prong two: Remarks 05/29/2026 p.14-p.16 ¶2 points to Original Specification ¶ [0004], [0017], and [0027] to argue the same limitations raised the previous step now describe a specific technical solution (e.g. providing input topic streams to consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application) that allegedly improve handling of data for streaming and downstream analytics processing by decoupling data analysis workflow from an applications traffic data pipeline of a production computing system.
Examiner fully considered Step 2A prong two argument but respectfully disagrees reincorporating herein all findings and rationales above. Specifically, the Examiner resubmits that decoupling data analysis workflow from an applications traffic data pipeline of a production computing system, when tested per MPEP 2106.05(g), represent an extra solution activity with respect to the fundamental and/or commercial process of organizing human activities between the consumer and producer clients, as identified above. Specifically, Examiner follows MPEP 2106.05(g) ¶3, 2nd sentence to submit that: evaluation of well-understood, routine, conventional consideration (see MPEP 2106.05(d)), and the field of use and technological environment consideration (see MPEP 2106.05(h)) may assist examiners in making a determination of whether an element (or combination of elements) is insignificant extra-solution activity. Accordingly, Examiner follows MPEP 2106.05(d) I 2 (c) and points to the following citations to the following publication that demonstrate, by preponderance of evidence, that the asynchronous data decoupling is well-understood, routine or conventional:
- US 20050210109 A1 ¶ [0003] 1st sentence: At its core, the conventional messaging system permits separate, uncoupled applications to reliably communicate in an asynchronous manner
- What are asynchronous integrations, sharelogic, waybackmachine, Dec 1, 2023 defining at its first page, first paragraph: Asynchronous integrations as critical mechanism in modern software architecture that enable exchange of data and information between different systems or components without requiring immediate or synchronous response with Decoupling defines at the first page, 5th bullet point as: Asynchronous integrations decouple systems, reducing interdependencies and allowing for greater flexibility in system design and maintenance
- Hu et al, Type-Safe Eventful Sessions in Java, ECOOP 2010,LNCS 6183,p329-p353, Springer, 2010 disclosing at its first page under the Introduction chapter: Asynchronous event-driven programming is characterised by a reactive flow of control driven by the occurrence of computation events. It is one of the major paradigms in concurrent and communication-based programming, where events are typically detected by the arrival of messages on asynchronous channels. Primary motivations for asynchronous event programming include performance and scalability, particularly for high-concurrency applications such as Web servers. Then again disclosing at its 3rd sentence under Chapter 2: Event-Driven Session Programming: “The performance and scalability of event-based systems come from the asynchronous decoupling of event handlers from the event source (e.g. the network interface) through the event loop, which enables many concurrent sessions to be serviced as a fine-grain sequential interleaving of actions within a single thread or a thread pool”.
- What is Event Driven Integration, solace, archives org, archives org, January 2025, defining at its first and third pages: event driven integration as an integration pattern in which independent IT components communicate in a decoupled manner by publishing and subscribing to events. Also, Asynchronous event-driven communication is defined to decouple applications and devices so they can both send and receive information without any sort of active connection with the system at the other end. Indeed recipients can even receive information that was ben sent while they were offline or unable to keep up with the flow of information, without impacting the source or other target systems.
- Introduction to Decoupling Techniques, technebo, wayback machine, July 21, 2024, defining at its first page: “Asynchronous decoupling allows components to communicate without waiting for each other. Messages are sent to a queue or topic, and the receiving component processes them independently”
- Decouple Processing, SAP, wayback machine, Jan 21, 2024, defining at it page 1: Asynchronous decoupling as processing of an integration scenario that is decoupled asynchronously between the sender and the integration flow
- Rachel Richardson, Understanding asynchronous messaging for microservices, AWS webapages, Nov 22, 2019 defining at its first page Asynchronous messaging is a fundamental approach for integrating independent systems, or building up a set of loosely coupled systems that can operate, scale, and evolve independently and flexibly. As our colleague Tim Bray said, “If your application is cloud-native, or large-scale, or distributed, and doesn’t include a messaging component, that’s probably a bug.” In this blog post, we will outline some fundamental benefits of asynchronous messaging for the communications between microservices.
- Simon Emmanuel Rivas, Building synchronous APIs on asynchronous event bus using Azure Service Bus, middleway pages, July 2020 explain at its first page that decoupling is as basic best practice, with time decoupling defined as using an asynchronous event/message bus, and with Azure Service Bus, being asynchronous in nature
- Lutz Huhnken Blog, What Kind of Asynchronous is Right For You, June 15, 2023, disclosing Asynchronous Option 3: Event-driven Communication as real runtime decoupling,
- Rafael Gonzaga, Communication between microservices Asynchronous, Dec 3, 2023, disclosing in detail examples with code of asynchronous communication between microservices ranging from low decoupling to no dependency
- How can Microservices be isolated and communicate at the same time, reddit, July 5th, 2021 disclosing implementation of message queue for asynchronous services through Kafka when one of the surcribing services are down. next time they’re up the system works as intended
- Half Sync Half Async Pattern in Java, Enhancing System Performance with Dual Processing, javadesignpatterns pages, Jan 25,2022 disclosing the system perform tasks in response to external events that occur asynchronously, like hardware interruptions in OS
- Wittig Andreas, Integrate SQS and Lambda serverless architecture for asynchronous workloads, cloudonaut, May 19, 2017 dislosing at its first and second pages: SQS queue for asynchronous decoupling: sending out massive amounts of emails, transcoding video files after upload, or analyzing user behavior.
- Romain, Why Asynchronous Event-Driven Frameworks Are Critical for Real-Time Data Processing, medium webpages, Feb 24,2023 disclosing that Asynchronous event-driven frameworks use an event loop to handle incoming events and messages. The event loop processes events as they arrive, triggering the appropriate code to handle each event. These architectures enable the decoupling of rule-based services to microservices that consume and share data based on events. Thus, systems are not dependent on a specific message…
By decoupling the components of the system, developers can add or remove event producers and consumers dynamically, without affecting the other services. This allows for different services to be implemented in different languages or technologies, and enables the use of different encoding formats like JSON, XML, or Avro... The use of an event-driven architecture provides a resilient system due to the decoupling of its components
- Mezzalira et al, Creating an Asynchronous Ingestion Pattern Following Mia-Platform Fast Data Architecture, awx webpages, Oct 24, 2022, disclosing at its first page: an asynchronous pattern for ingesting data from legacy systems, collecting it into projections, and aggregating it into single views. The purpose of this solution is to decouple the source systems where data is stored from the external channels that request data. This ensures both offloading of source systems and makes data available to channels 24/7 and in near real-time.
- Self-contained Systems SCS, scs architecture org, wayback machine, October 3, 2023, disclosing at its second page: Asynchronous dependencies
- Decoupling When to use a broker like SAP Event Mesh, integration-excellence pages, wayback machine, Oct 2, 2023 disclosing at its first page: decoupling to remove dependencies between systems, with runtime dependencies solved with asynchronous messaging, where the sender (system) can submit a message to the middleware and this is independent from the availability of the receiver.
Accordingly, the argument is found unpersuasive because there is a preponderance of both legal and factual evidence showing the claims still recite, describe or set forth the abstract exception with the computerized environment or tools incapable to save the claims from patent ineligibility because even when subsequently testing the argued computerization, it merely represents an extra solution activity with features that remains conventional.
Step 2B: Remarks 05/29/2026 p.16 ¶4 submits that the added limitations cannot be considered to be well-understood, routine, or known within the industry at least because they do not appear to be taught by the prior art of record.
Examiner fully considered Step 2B argument but respectfully disagrees reincorporating herein all findings and rationales above. To be clear, novelty (35 USC 102) and non-obviousness (35 USC 103) still pertain to features that are abstract, or incapable to integrate the abstract idea or provide significantly more, which do not render the claims patent eligible (35 USC 101). See for example MPEP 2106.04 I ¶5, 3rd sentence citing Mayo, 566 U.S. 71, 101 USPQ2d at 1965); Flook, 437 U.S. at 591-92, 198 USPQ2d at 198 "the novelty of the mathematical algorithm is not a determining factor at all”. Examiner also resubmits that when tested per MPEP 2106.04(a)(2) II, the argued features of the producer client providing or publishing data, while the consumer client reading (receiving) message data from one or more topics, still set forth the commercial of fundamental practices, with MPEP 2106.04(a)(2) II A ¶2 clarifying that the term "fundamental" is not used in the sense of necessarily being "old" or "well-known" but rather as building blocks of modern economy. Here the topic stream interactions between consumer and producer clients, represents such building blocks of modern economy no matter of their level of computerization.
Indeed, as stressed by MPEP 2106.05(a) II ¶2, an improvement in the abstract exception itself is not improvement in technology. Here, as demonstrated above, the alleged improvement is at best entrepreneurial and abstract for a business practice of distribution of information or content as “payload messages” or “topic streams” between “producer” (publishing) and “consumer” (reading or consuming) messages or content as identified above at the prior steps and recognized by
Applicant at Remarks 05/29/2026 p.13 ¶2. Such entrepreneurial or fundamental practice of distribution of information or content as “payload messages” or “topic streams” between “producer” (publishing) and “consumer” (reading or consuming) messages or content remains abstract. It is not an improvement in actual technology. This finding is especially important since MPEP 2106.04 I ¶3 cited Mayo, 566 U.S. at 79-80, 86-87, 101 USPQ2d at 1968-69, 1971 states that narrow laws that have limited applications were still held ineligible. Specifically in Myriad, 569 US at 591,106 USPQ2d at 1979, the Court found situations where even a groundbreaking, innovative, or even brilliant discovery does not by itself satisfy the §101 inquiry". This finding was corroborated by Versata Dev Grp, Inc v SAP Am, Inc 115 USPQ2d 1681 Fed Cir 2015 again undelaying the difference between improvement to an entrepreneurial goal or objective versus improvement to actual technology, and by SAP Am, Inc v InvestPic, LLC, No 2017-2081, 2018 BL 275354 (Fed. Cir.Aug.02, 2018) which disclosed a comparable solution that “utilizes resampled statistical methods for the analysis of financial data, which do not assume a normal probability distribution”, further narrowed to a cross validation at the dependent claims. Yet, the Court ruled that: “even if one assumes that the techniques claimed are groundbreaking, innovative, or even brilliant, those features are not enough for eligibility because their innovation is innovation in ineligible subject matter”. “An advance of that nature is ineligible for patenting”.
Here, analogous to Mayo, Versata, SAP the alleged advance is in the abstract practice of distribution of information or content as “payload messages” or “topic streams” between “producer” (publishing) and “consumer” (reading or consuming) messages or content. Thus, the examiner reasons that it is also ineligible for patenting.
As per the asynchronous processing that decouples data, as previously argued above and now reconsidered for Step 2B of the analysis, the Examiner tests this feature per MPEP 2106.05(g), and finds it to represent an extra solution activity with respect to the fundamental and/or commercial process of organizing human activities between the consumer and producer clients, as identified above. Specifically, Examiner follows MPEP 2106.05(g) ¶3, 2nd sentence to submit that: evaluation of well-understood, routine, conventional consideration (see MPEP 2106.05(d)), and the field of use and technological environment consideration (see MPEP 2106.05(h)) may assist examiners in making a determination of whether an element (or combination of elements) is insignificant extra-solution activity. Accordingly, Examiner follows MPEP 2106.05(d) I 2 (c) and points to the following citations to the following publication that demonstrate, by preponderance of evidence, that the asynchronous data decoupling is well-understood, routine or conventional:
- US 20050210109 A1 ¶ [0003] 1st sentence: At its core, the conventional messaging system permits separate, uncoupled applications to reliably communicate in an asynchronous manner
- What are asynchronous integrations, sharelogic, waybackmachine, Dec 1, 2023 defining at its first page, first paragraph: Asynchronous integrations as critical mechanism in modern software architecture that enable exchange of data and information between different systems or components without requiring immediate or synchronous response with Decoupling defines at the first page, 5th bullet point as: Asynchronous integrations decouple systems, reducing interdependencies and allowing for greater flexibility in system design and maintenance
- Hu et al, Type-Safe Eventful Sessions in Java, ECOOP 2010,LNCS 6183,p329-p353, Springer, 2010 disclosing at its first page under the Introduction chapter: Asynchronous event-driven programming is characterised by a reactive flow of control driven by the occurrence of computation events. It is one of the major paradigms in concurrent and communication-based programming, where events are typically detected by the arrival of messages on asynchronous channels. Primary motivations for asynchronous event programming include performance and scalability, particularly for high-concurrency applications such as Web servers. Then again disclosing at its 3rd sentence under Chapter 2: Event-Driven Session Programming: “The performance and scalability of event-based systems come from the asynchronous decoupling of event handlers from the event source (e.g. the network interface) through the event loop, which enables many concurrent sessions to be serviced as a fine-grain sequential interleaving of actions within a single thread or a thread pool”.
- What is Event Driven Integration, solace, archives org, archives org, January 2025, defining at its first and third pages: event driven integration as an integration pattern in which independent IT components communicate in a decoupled manner by publishing and subscribing to events. Also, Asynchronous event-driven communication is defined to decouple applications and devices so they can both send and receive information without any sort of active connection with the system at the other end. Indeed recipients can even receive information that was ben sent while they were offline or unable to keep up with the flow of information, without impacting the source or other target systems.
- Introduction to Decoupling Techniques, technebo, wayback machine, July 21, 2024, defining at its first page: “Asynchronous decoupling allows components to communicate without waiting for each other. Messages are sent to a queue or topic, and the receiving component processes them independently”
- Decouple Processing, SAP, wayback machine, Jan 21, 2024, defining at it page 1: Asynchronous decoupling as processing of an integration scenario that is decoupled asynchronously between the sender and the integration flow
- Rachel Richardson, Understanding asynchronous messaging for microservices, AWS webapages, Nov 22, 2019 defining at its first page Asynchronous messaging is a fundamental approach for integrating independent systems, or building up a set of loosely coupled systems that can operate, scale, and evolve independently and flexibly. As our colleague Tim Bray said, “If your application is cloud-native, or large-scale, or distributed, and doesn’t include a messaging component, that’s probably a bug.” In this blog post, we will outline some fundamental benefits of asynchronous messaging for the communications between microservices.
- Simon Emmanuel Rivas, Building synchronous APIs on asynchronous event bus using Azure Service Bus, middleway pages, July 2020 explain at its first page that decoupling is as basic best practice, with time decoupling defined as using an asynchronous event/message bus, and with Azure Service Bus, being asynchronous in nature
- Lutz Huhnken Blog, What Kind of Asynchronous is Right For You, June 15, 2023, disclosing Asynchronous Option 3: Event-driven Communication as real runtime decoupling,
- Rafael Gonzaga, Communication between microservices Asynchronous, Dec 3, 2023, disclosing in detail examples with code of asynchronous communication between microservices ranging from low decoupling to no dependency
- How can Microservices be isolated and communicate at the same time, reddit, July 5th, 2021 disclosing implementation of message queue for asynchronous services through Kafka when one of the surcribing services are down. next time they’re up the system works as intended
- Half Sync Half Async Pattern in Java, Enhancing System Performance with Dual Processing, javadesignpatterns pages, Jan 25,2022 disclosing the system perform tasks in response to external events that occur asynchronously, like hardware interruptions in OS
- Wittig Andreas, Integrate SQS and Lambda serverless architecture for asynchronous workloads, cloudonaut, May 19, 2017 dislosing at its first and second pages: SQS queue for asynchronous decoupling: sending out massive amounts of emails, transcoding video files after upload, or analyzing user behavior.
- Romain, Why Asynchronous Event-Driven Frameworks Are Critical for Real-Time Data Processing, medium webpages, Feb 24,2023 disclosing that Asynchronous event-driven frameworks use an event loop to handle incoming events and messages. The event loop processes events as they arrive, triggering the appropriate code to handle each event. These architectures enable the decoupling of rule-based services to microservices that consume and share data based on events. Thus, systems are not dependent on a specific message…
By decoupling the components of the system, developers can add or remove event producers and consumers dynamically, without affecting the other services. This allows for different services to be implemented in different languages or technologies, and enables the use of different encoding formats like JSON, XML, or Avro... The use of an event-driven architecture provides a resilient system due to the decoupling of its components
- Mezzalira et al, Creating an Asynchronous Ingestion Pattern Following Mia-Platform Fast Data Architecture, awx webpages, Oct 24, 2022, disclosing at its first page: an asynchronous pattern for ingesting data from legacy systems, collecting it into projections, and aggregating it into single views. The purpose of this solution is to decouple the source systems where data is stored from the external channels that request data. This ensures both offloading of source systems and makes data available to channels 24/7 and in near real-time.
- Self-contained Systems SCS, scs architecture org, wayback machine, October 3, 2023, disclosing at its second page: Asynchronous dependencies
- Decoupling When to use a broker like SAP Event Mesh, integration-excellence pages, wayback machine, Oct 2, 2023 disclosing at its first page: decoupling to remove dependencies between systems, with runtime dependencies solved with asynchronous messaging, where the sender (system) can submit a message to the middleware and this is independent from the availability of the receiver.
Accordingly, the argument is found unpersuasive because there is a preponderance of both legal and factual evidence showing the claims still recite, describe or set forth the abstract exception with the computerized environment or tools incapable to save the claims from patent ineligibility because even when subsequently testing the argued computerization, it merely represents an extra solution activity with features that remains conventional.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
C. Response to Applicant’s rebuttal of Rejections Under 35 U.S.C. § 102 and 103
Remarks 05/29/2026 p.18 ¶ 4, p.19 ¶2 argues Schuhart does not disclose, teach or suggest
... “wherein the set of one or more event message payloads is asynchronously captured from an integration services application layer interface”
... “the set of one or more input topic streams is provided to the set of one or more consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications” as newly amended.
Applicant’s argument C was considered but is moot in view of new grounds of rejection as necessitated by amendment. Kerth et al US 20120096112 A1 is now relied by Examiner to teach
... “wherein the set of one or more event message payloads is asynchronously captured from an integration services application layer interface”
(Kerth ¶ [0027] 2nd, 6th sentence: message producers 110,120 communicate asynchronously with message consumer 140 over network 130 which facilitate communication between message producers 110 and 120 and message consumer 140 of system 100. Details at ¶ [0034]-¶ [0044].
Kerth ¶ [0041] discloses an example where system 100 communicate asynchronously using queues, such as inbound queue 140-6. Fig.3 depicts an exemplary asynchronous communication 300 using queues. in Fig.3, module 301 may send a message 302 to a queue 303. Then, module 304 may consume message 302. After consuming the message 302, the module 304 may acknowledge the consumption of message 302 to module 301. Message 301 may be a point-to-point message, that is, message 301 may have exactly one consumer. Furthermore, module 301 and module 304 may be located on different computers (not shown) connected over a network (not shown). The messaging infrastructure may support various Qualities of Service for message delivery, such as guaranteed-at-least-once or guaranteed-exactly-once-in-order delivery. Such Qualities of Service isolate certain network transmission errors in the transport layer and thereby increase the transparency of remote communication from the perspective of the module layer.
Kerth ¶ [0042] 1st-5th sentences: System 100 may communicate asynchronously using topics. A topic is a construct the messages meeting certain criteria may be published to. Fig.4 depicts an exemplary asynchronous communication 400 using topics. As shown in Fig.4, module 401 may publish message 402 to topic 403. Modules 404 and 405 may subscribe to topic 403. That is, modules 404 and 405 may indicate that they wish to receive messages published to topic 403. Then, topic 403 may deliver message 402 to modules 404 and 405.
Kerth ¶ [0043] 1st-4th sentences states the invention may use asynchronous communication to decouple different modules that execute in system 100. In all such embodiments, asynchronous communication may be embedded into system 100 so that its use remains transparent to the participating modules. Asynchronous communication may, but does not have to, take place for any message between the coarse grained modules depicted, or between different modules defining the content of system 100. Using synchronous communication for inter module communication may increase the degree of coupling between modules);
... “the set of one or more input topic streams is provided to the set of one or more consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications”
(Kerth Figs. 2-6 ¶ [0036] 1st sentence, ¶ [0040] Fig.2 illustrates exemplary system for transparently decoupling modules using scopes, consistent with the present invention. In S201, Module A, which may be located on one of message producers 110 and 120, invokes method on object instance of Module B, which may be located on message consumer 140. From the perspective of Module A, this is a local method invocation on an object instance in a local address space of Module A which represents an object instance of Module B. The message producers 110 or 120 may then queue the request message and detach the corresponding thread (e.g., threads 110-2 and 120-2) from the task of executing the method invocation in Module A (S202). This thread may then be used for other processing in local address space of Module A. The detachment causes execution of Module A to be paused for the duration of the method invocation (S203). Message provider 110 or 120 may then transfer the request message to Module B (S204). System 100 may also implicitly copy any relevant scope contexts over to the local address space of Module B (S205). There are three ways to do this: message attachment and proactive or reactive (on demand) out-of-band-replication (as discussed in section Context Replication). Steps S204 and S205 may occur in parallel. System 100 then delivers the request message to the target object instance of the method invocation in the local address space of Module B (S206). Message consumer 140 executes the method, referencing the replicated scope contexts as necessary (S207). For example, if the method invocation made use of parameters then these parameters can be accessed from the replicated scope contexts. Message consumer 140 may then convert a result of the method execution into a response message and queue it in the local address space of Module B (S208). System 100 then transfer the response message to the local address space of Module A (S209). System 100 may implicitly replicate any changes made to the relevant scope contexts during the method execution in Module B back to local address space of Module A, using one of the three replication mechanisms detailed below (S210). Again, steps S209 and S210 may occur in parallel. Message producer 110 or 120 then dequeue the response message by a thread (e.g., threads 110-2 and 120-2) in the address space of Module A and execution of Module A is resumed (S211). The thread dequeing the message may not be the same thread which launched the method invocation but it may have the same thread context as that original thread. During further execution of Module A, any relevant scope contexts may be accessed by Module A. Any changes made to resources allocated to such a context during the method invocation on Module B are visible to Module A. ¶ [0045] 3rd-10th sentences: In hierarchy 500, scope instance 510 may have context 511 that includes resources 512 and 513 allocated to scope instance 510. Scope instance 510 serve as a parent to child scope instances 520 and 530. Child scope instance 520 have context 521 that includes resources 522 and 523 allocated to child scope instance 520. Similarly, child scope instance 530 may have a context 531 that includes resources 532 and 533 allocated to child scope instance 530. Child scope instance 530 may also be a child of parent scope instance 540 having its own context 541 and allocated resources 542 and 543. Child scope instance 530 may also serve as a parent to child scope instance 550 having its own context 551 and allocated resources 552 and 553. The hierarchy may be navigable from parent to child and from child to parent, relying the respective identities of the participating scope instances);
Thus, Kerth teaches the contested features and thus the argument is found unpersuasive.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract content of a body (or “payload”) of a “message” associated with “topic streams” vis-a-vis “producer” and “consumer clients” (Claims 1,2,6,9,10,14,17) as examples of abstract business or commercial interactions, tested per MPEP 2106.04 (a) (2) II B and/or C, as being within the broad abstract grouping of Certain Methods of Organizing of Human Activities. For example, MPEP 2106.04(a)(2) II B cites Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 714-15, 112 USPQ2d 1750, 1753-54 (Fed. Cir. 2014), where the Federal Circuit found that eleven-step method for displaying an advertisement (ad) [akin here to an “output topic”] in exchange for access to copyrighted media [akin here to an “input topic”, and “input topic streams”], comprising the steps of receiving copyrighted media [akin here to “a set of one or more event message payloads associated with one or more messages between one or more application programming interfaces or integrator elements and a set of one or more downstream applications”], selecting an ad [akin here to “receiving”… “using a consumer client of the set of one or more consumer clients, an event message payload of the set of one or more event message payloads from an input topic stream of the set of one or more input topic streams”], offering the media in exchange for watching the selected ad, displaying the ad, allowing the consumer access to the media [akin here to “providing” “using the producer client, the transformed event message payloads as an output topic to the streaming server, wherein the output topic corresponds an output topic stream of the set of one or more output topic streams”] fell within the abstract commercial interactions of Certain Methods of Organizing of Human Activities. By the claim mapping to Ultramercial case law above, the Examiner makes a similar case for the current claims setting forth the abstract exception.
The fact that such “receiving” [of] “ a set of one or more event message payloads” [is] “associated with one or more messages between one or more application programming interfaces or integrator elements and a set of one or more downstream applications” (independent Claims 1,9,17) does not render the claims less abstract and eligible, because, according to MPEP 2106.04(a)(2) II ¶6, 4th sentence the abstract sub-groupings encompass activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer may still fall within the abstract certain methods of organizing human activity grouping. It then follows that here, the analogous activity between “producer” and “consumer” clients such as “providing” “the set of one or more event message payloads as a set of one or more input topics to a streaming server” and “receiving”, “using a consumer client of the set of one or more consumer clients, an event message payload of the set of one or more event message payloads from an input topic stream of the set of one or more input topic streams”; and “providing”, “using the producer client, the one or more” “event message payload as an output topic to the streaming server, wherein the output topic corresponds an output topic stream of the set of one or more output topic streams” does not preclude the claims to recite or at least describe or set forth the abstract “Certain Methods of Organizing of Human Activities”.
Additionally, or alternatively, when tested per MPEP 2106.04(A)(2) III C #2, such level of computerization can be argued to represent a computer environment upon which the abstract rule-based distribution of information, or content, “payload messages” or “topic streams” is being performed. For example, in FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed Cir. 2016) cited by MPEP 2106.04(A)(2) III C #2, the Federal Circuit found storing, accessing, compiling and combining of information from disparate information sources, to generate a full picture of activity, identity, frequency of activity, and the like in such computer environment, still set forth the abstract selecting of information, by content or source, for collection, analysis, and announcement. The claims in FairWaning referred to use of such storing, accessing, compiling and combining of information from disparate information sources in a healthcare-based system in a manner not meaningfully different than what is exemplified here at Original Specification ¶ [0003], and later expended to banking, education and retail etc. at Original Specification ¶ [0025] last sentence. Here, given the breadth of the independent Claims 1,8,17, the “generating” [of] “transformed event message payload by applying one or more data transformation rules” can be argued as such an abstract example of rule-based compiling of information as in FairWaning supra, while the “integrator” corresponds to such abstract Example of rule-based combining as in Fairwarning, and the “one or more input topic streams” “decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications” corresponds to the disparate information sources of FairWarning.
Further here, such storing, accessing, compiling and combining of information, from disparate information sources [here to “downstream applications”], is set forth at independent Claims 1,9,17 as between market participants, namely, “consumer” and “producer” “clients” including “receiving” “a set of one or more event message payloads associated with one or more messages between one or more application programming interfaces or integrator elements” [akin to Fairwarning’s ineligible combination] “and a set of one or more downstream applications” [akin to Fairwarning’s ineligible disparate information sources], “providing”, “using a producer client” [as the first abstract business entity], “the set of one or more event message payloads as a set of one or more input topics to a streaming server” “configured to provide, to a set of one or more consumer clients, (1) a set of one or more input topic streams that comprise the set of one or more event message payloads and (b) corresponds to the set of one or more input topics, and (2) a set of one or more output topic streams”; “receiving”, “using a consumer client” [as another, second business entity] “of the one or more consumer clients, the set of one or more event message payloads, an event message payload of the set of one or more event message payloads from an input topic stream of the set of one or more input topic streams”; “generating” “using the consumer client s transformed event message payload by applying one or more data transformation rules” [akin to Fairwarning’s ineligible compilation] “to the event message payload received from the input topic stream”; and “providing” [akin to FairWarning’s ineligible announcing] “using the producer client” [or the first business entity], “the transformed” [or compiled] “event message payload as an output topic to the streaming server, wherein the output topic corresponds an output topic stream of the set of one or more output topic streams”. Dependent Claims 2-8, 10-16, 18-20 further narrow the abstract concepts of independent Claims 1,9,17, by considering abstract evaluation regarding “outsize” benchmarked over a “size limit” and associated “references to the outsize” “messages”, “locations” etc. in a manner not meaningfully different to the threshold-based and volume-based rules of FairWarning supra. This finding is important since MPEP 2106.04 I ¶3 states that narrow laws with limited applications remain ineligible. Thus, Examiner reasons that given preponderance of legal evidence above, the claims recite, describe or set forth the abstract exception.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This judicial exception is not integrated into a practical application because per Step 2A prong two, the individual or combination of additional, computer-based elements such as: “one or more processors” (Claims 1, 9,11,12,17, 18,19), “repository interface”, (dependent Claims 2,10), “data storage file system” (dependent Claims 4,,5,12,13,19,20), “single message transform plugin” (dependent Claims 6,14), “parsing logics based on a natural language-based template definition language” (dependent Claims 7,15) and possibly the “flat reportable object data structures” (dependent Claims 8,16) etc. are/is found to merely apply the already identified abstract exception, which when further tested per MPEP 2106.05(f), do not integrate the abstract exception into a practical application. For example, when tested, per MPEP 2106.05(f)(2) ¶1, such additional, computer-based elements represent mere invocation of computers or other machinery to perform economic tasks or other tasks to receive, store, or transmit data. Here such data corresponds to the associated “message payloads”, “topic”, “streams” etc. as recited throughout Claims 1-6, 8-14, 16-20. Also, as tested per MPEP 2106.05(f)(2)(iii) such additional elements can be argued to merely monitor audit log data [akin here to “message payloads”, “topic” “streams” etc.] executed on a computer. Additionally and/or alternatively, such level of automation recited throughout Claims 1-20, when equally tested per MPEP 2106.05(h) vi., can also be argued as an example of narrowing the abstract exception to a field of use or technological environment such as narrowing the combination of collecting information, analyzing it, and displaying certain results of collection and analysis, to data related to a computerized environment as identified above.
** As per “transformed event message payload by applying one or more data transformation rules” (independent Claims 1,9,17), Examiner relies on MPEP 2106.04(a)(2) I A, to interpret the rules as mathematical relationships expressed in words with MPEP 2106.05(c)3 further explaining that manipulation of basic mathematical constructs [akin here to “rules”] or the paradigmatic ‘abstract idea has not been deemed a transformation capable to render the claims patent eligible. Indeed, as initially explained by MPEP 2106.04(a)(2) I A iv. organizing information and manipulating information through mathematical correlations by generating first and second data by taking existing information, manipulating the data using mathematical functions, and organizing this information into a new form remains abstract. These are set forth here by “transformed event message payload by applying one or more data transformation rules” (independent Claims 1,9,17), without providing a patent eligible transformation as necessitated by MPEP 2106.05(c).
** As per the recitation of “wherein the set of one or more event message payloads is asynchronously captured from an integration services application layer interface”, Examiner first points to the limited patentable weight of a wherein limitation, as tested per MPEP 2111.04.
** As per the recitation of “(ii) the set of one or more input topic streams is provided to the set of one or more consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications”, at independent Claims 1,9,17, Examiner notes that the phrase “in a manner that is decoupled” at paragraph (ii), within the parent “wherein” limitation can perhaps be argued as an expression of intended use or intended result with limited patentable weight4.
Even if given full patentable weight the asynchronous data decoupling at the two limitations just above, when tested per MPEP 2106.05(g), would represent an extra solution activity with respect to the fundamental and/or commercial process of organizing human activities between the consumer and producer clients, as identified and mapped as abstract above.
Thus, Examiner provided a preponderance of legal evidence showing that the automation or computerization above does not integrate the abstract exception into a practical application.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because Examiner follows MPEP 2106.05(d) II guidelines and carries over the above findings at MPEP 2106.05 (f) and/or (h) to submit that as shown above, the additional elements, merely apply the already recited abstract idea [MPEP 2106.05(f)] and/or narrow it to a field of use or technological environment [MPEP 2106.05(h)]. For these same reasons, said computer-based additional elements also do not provide significantly more than the abstract idea itself, in light of MPEP 2106.05(f) and/or (h) as t option(s) for evidence. Based on such legal evidence conferred by the MPEP 2106.05(f),(h) tests above, the Examiner submits that the additional computer-based elements do not provide significantly more.
Assuming arguendo, that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, the Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In such case, Examiner would rely on the Original Specification as follows:
- Original Specification ¶ [0032] reciting at high level: Fig.2 provides an example data analysis computing entity 106 in accordance with some embodiments of the present disclosure. In general, the terms computing entity, computer, entity, device, system, and/or similar words used herein interchangeably may refer to, for example, one or more computers, computing entities, desktops, mobile phones, tablets, phablets, notebooks, laptops, distributed systems, kiosks, input terminals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, relays, routers, network access points, base stations, the like, and/or any combination of devices or entities adapted to perform the functions, operations, and/or processes described herein. Such functions, operations, and/or processes may include, for example, transmitting, receiving, operating on, processing, displaying, storing, determining, creating/generating, monitoring, evaluating, comparing, and/or similar terms used herein interchangeably. In some embodiments, these functions, operations, and/or processes may be performed on data, content, information, and/or similar terms used herein interchangeably.
- Original Specification ¶ [0040] 2nd sentence noting asynchronous transfer mode (ATM) generally recited as one of several options: “Such communication may be executed using a wired data transmission protocol, such as fiber distributed data interface (FDDI), digital subscriber line (DSL), Ethernet, asynchronous transfer mode (ATM), frame relay, data over cable service interface specification (DOCSIS), or any other wired transmission protocol”.
- Original Specification ¶ [0042] reciting at high level of generality: Fig.3 provides an example client computing entity in accordance with some embodiments of the present disclosure. In general, the terms device, system, computing entity, entity, and/or similar words used herein interchangeably may refer to, for example, one or more computers, computing entities, desktops, mobile phones, tablets, phablets, notebooks, laptops, distributed systems, kiosks, input terminals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, relays, routers, network access points, base stations, the like, and/or any combination of devices or entities adapted to perform the functions, operations, and/or processes described herein. Client computing entities 102 may be operated by various parties. As shown in FIG. 3, the client computing entity 102 may include an antenna 312, a transmitter 304 (e.g., radio), a receiver 306 (e.g., radio), and a processing element 308 (e.g., CPLDs, microprocessors, multi-core processors, coprocessing entities, ASIPs, microcontrollers, and/or controllers) that provides signals to and receives signals from the transmitter 304 and receiver 306, correspondingly.
- Original Specification ¶ [0118] reciting at high level of generality: any modifications and other embodiments will come to mind to one skilled in the art to which this disclosure pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the disclosure is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Assuming , in the arguendo that further evidence would be required for the recitation of “wherein the set of one or more event message payloads is asynchronously captured from an integration services application layer interface”; and “(ii) the set of one or more input topic streams is provided to the set of one or more consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications”, the Examiner would reincorporate the extra-solution activity articulated at the prior step and further follows MPEP 2106.05(g) ¶3, 2nd sentence to submit that: evaluation of well-understood, routine, conventional consideration (see MPEP 2106.05(d)), and the field of use and technological environment consideration (see MPEP 2106.05(h)) may assist examiners in making a determination of whether an element (or combination of elements) is insignificant extra-solution activity. Accordingly, in addition to Original Specification ¶ [0040] 2nd sentence above, as necessitated by MPEP 2106.05(d) I 2 (a), the Examiner would also rely on MPEP 2106.05(d) I 2 (c) to point to citations of the following publications that demonstrate, by preponderance of evidence, that the asynchronous data decoupling is well-understood, routine or conventional:
- US 20050210109 A1 ¶ [0003] 1st sentence: At its core, the conventional messaging system permits separate, uncoupled applications to reliably communicate in an asynchronous manner
- What are asynchronous integrations, sharelogic, waybackmachine, Dec 1, 2023 defining at its first page, first paragraph: Asynchronous integrations as critical mechanism in modern software architecture that enable exchange of data and information between different systems or components without requiring immediate or synchronous response with Decoupling defines at the first page, 5th bullet point as: Asynchronous integrations decouple systems, reducing interdependencies and allowing for greater flexibility in system design and maintenance
- Hu et al, Type-Safe Eventful Sessions in Java, ECOOP 2010,LNCS 6183,p329-p353, Springer, 2010 disclosing at its first page under the Introduction chapter: Asynchronous event-driven programming is characterised by a reactive flow of control driven by the occurrence of computation events. It is one of the major paradigms in concurrent and communication-based programming, where events are typically detected by the arrival of messages on asynchronous channels. Primary motivations for asynchronous event programming include performance and scalability, particularly for high-concurrency applications such as Web servers. Then again disclosing at its 3rd sentence under Chapter 2: Event-Driven Session Programming: “The performance and scalability of event-based systems come from the asynchronous decoupling of event handlers from the event source (e.g. the network interface) through the event loop, which enables many concurrent sessions to be serviced as a fine-grain sequential interleaving of actions within a single thread or a thread pool”.
- What is Event Driven Integration, solace, archives org, archives org, January 2025, defining at its first and third pages: event driven integration as an integration pattern in which independent IT components communicate in a decoupled manner by publishing and subscribing to events. Also, Asynchronous event-driven communication is defined to decouple applications and devices so they can both send and receive information without any sort of active connection with the system at the other end. Indeed recipients can even receive information that was ben sent while they were offline or unable to keep up with the flow of information, without impacting the source or other target systems.
- Introduction to Decoupling Techniques, technebo, wayback machine, July 21, 2024, defining at its first page: “Asynchronous decoupling allows components to communicate without waiting for each other. Messages are sent to a queue or topic, and the receiving component processes them independently”
- Decouple Processing, SAP, wayback machine, Jan 21, 2024, defining at it page 1: Asynchronous decoupling as processing of an integration scenario that is decoupled asynchronously between the sender and the integration flow
- Rachel Richardson, Understanding asynchronous messaging for microservices, AWS webapages, Nov 22, 2019 defining at its first page Asynchronous messaging is a fundamental approach for integrating independent systems, or building up a set of loosely coupled systems that can operate, scale, and evolve independently and flexibly. As our colleague Tim Bray said, “If your application is cloud-native, or large-scale, or distributed, and doesn’t include a messaging component, that’s probably a bug.” In this blog post, we will outline some fundamental benefits of asynchronous messaging for the communications between microservices.
- Simon Emmanuel Rivas, Building synchronous APIs on asynchronous event bus using Azure Service Bus, middleway pages, July 2020 explain at its first page that decoupling is as basic best practice, with time decoupling defined as using an asynchronous event/message bus, and with Azure Service Bus, being asynchronous in nature
- Lutz Huhnken Blog, What Kind of Asynchronous is Right For You, June 15, 2023, disclosing Asynchronous Option 3: Event-driven Communication as real runtime decoupling,
- Rafael Gonzaga, Communication between microservices Asynchronous, Dec 3, 2023, disclosing in detail examples with code of asynchronous communication between microservices ranging from low decoupling to no dependency
- How can Microservices be isolated and communicate at the same time, reddit, July 5th, 2021 disclosing implementation of message queue for asynchronous services through Kafka when one of the surcribing services are down. next time they’re up the system works as intended
- Half Sync Half Async Pattern in Java, Enhancing System Performance with Dual Processing, javadesignpatterns pages, Jan 25,2022 disclosing the system perform tasks in response to external events that occur asynchronously, like hardware interruptions in OS
- Wittig Andreas, Integrate SQS and Lambda serverless architecture for asynchronous workloads, cloudonaut, May 19, 2017 dislosing at its first and second pages: SQS queue for asynchronous decoupling: sending out massive amounts of emails, transcoding video files after upload, or analyzing user behavior.
- Romain, Why Asynchronous Event-Driven Frameworks Are Critical for Real-Time Data Processing, medium webpages, Feb 24,2023 disclosing that Asynchronous event-driven frameworks use an event loop to handle incoming events and messages. The event loop processes events as they arrive, triggering the appropriate code to handle each event. These architectures enable the decoupling of rule-based services to microservices that consume and share data based on events. Thus, systems are not dependent on a specific message…
By decoupling the components of the system, developers can add or remove event producers and consumers dynamically, without affecting the other services. This allows for different services to be implemented in different languages or technologies, and enables the use of different encoding formats like JSON, XML, or Avro... The use of an event-driven architecture provides a resilient system due to the decoupling of its components
- Mezzalira et al, Creating an Asynchronous Ingestion Pattern Following Mia-Platform Fast Data Architecture, awx webpages, Oct 24, 2022, disclosing at its first page: an asynchronous pattern for ingesting data from legacy systems, collecting it into projections, and aggregating it into single views. The purpose of this solution is to decouple the source systems where data is stored from the external channels that request data. This ensures both offloading of source systems and makes data available to channels 24/7 and in near real-time.
- Self-contained Systems SCS, scs architecture org, wayback machine, October 3, 2023, disclosing at its second page: Asynchronous dependencies
- Decoupling When to use a broker like SAP Event Mesh, integration-excellence pages, wayback machine, Oct 2, 2023 disclosing at its first page: decoupling to remove dependencies between systems, with runtime dependencies solved with asynchronous messaging, where the sender (system) can submit a message to the middleware and this is independent from the availability of the receiver.
All of this preponderance of legal and/or factual evidence demonstrate that the additional computer-based elements fail to provide anything significantly more than what was already identified as part of the abstract exception above. Therefore, Claims 1-20, although directed to statutory categories (here “method” or process at Claims 1-8, “system” or machine at Claims 9-16, “non-transitory medium” or computer product at Claims 17-20), they still recite, or at least describe or set forth the abstract idea (Step 2A prong one), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong two) or providing significantly more than abstract idea (Step 2B). Thus Claims 1-20 are patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1,9,17 are rejected under 35 U.S.C. 102(a)(1) based upon a public use or sale or other public availability of the invention as disclosed by Kerth et al US 20120096112 A1 hereinafter Kerth.
Claims 1,9,17 Kerth teaches “A computer-implemented method comprising: / system comprising one or more processors and one or more non-transitory computer readable media storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: / One or more non-transitory computer-readable storage media including instructions that, when executed by one or more processors to perform operations comprising, cause the one or more processors to” (Kerth [0008]-[0009],[0068])
- “receiving, by one or more processors, a set of one or more event message payloads associated with one or more messages between one or more application programming interfaces or integrator elements and a set of one or more downstream applications”
(Kerth ¶ [0054] 2nd-3rd sentences: message producers 110 or 120 or message consumer 140 allow the developer to request explicit resource deallocation prior to end-of-life of this scope instance. This may be achieved by means of API exposed on the corresponding scope type, e.g. on the client or on the application scope type. ¶ [0018] Fig.6A illustrates a request message, consistent with the present invention. Specifically, per ¶ [0057] 2nd-3rd, 5th sentences: Fig.6A depicts exemplary message 600 for transparently sharing context data between message producers 110 and 120 and message consumer 140. Message 600 include a message header 610 and message payload 620. The message payload 620 that includes target object ID 621, a target method name 622, and/or a set of method invocation parameters 623. For example, at
¶ [0064] 3rd sentence: load balancer receive request from client S801 and determine appropriate message producer 110 or 710 to dispatch incoming request to S802),
“wherein the set of one or more event message payloads is asynchronously captured from an integration services application layer”
(Kerth ¶ [0027] 2nd,6th sentence: message producers 110,120 communicate asynchronously with message consumer 140 over network 130 which facilitate communication between message producers 110 and 120 and message consumer 140 of system 100. Additional details at ¶ [0034] -¶ [0044]. For example, ¶ [0041] discloses system 100 communicate asynchronously using queues, such as inbound queue 140-6. Fig.3 depicts an exemplary asynchronous communication 300 using queues. in Fig.3, module 301 may send a message 302 to a queue 303. Then, module 304 consume message 302. After consuming message 302, the module 304 may acknowledge the consumption of message 302 to module 301. Message 301 may be a point-to-point message, that is, message 301 may have exactly one consumer. Furthermore, module 301 and module 304 may be located on different computers (not shown) connected over a network (not shown). The messaging infrastructure may support various Qualities of Service for message delivery, such as guaranteed-at-least-once or guaranteed-exactly-once-in-order delivery. Such Qualities of Service isolate certain network transmission errors in the transport layer and thereby increase the transparency of remote communication from the perspective of the module layer. ¶ [0042] 1st-5th sentences: System 100 may communicate asynchronously using topics. A topic is a construct the messages meeting certain criteria may be published to. Fig.4 depicts an exemplary asynchronous communication 400 using topics. As shown in Fig.4, module 401 may publish message 402 to topic 403. Modules 404 and 405 may subscribe to topic 403. That is, modules 404 and 405 may indicate that they wish to receive messages published to topic 403. Then, topic 403 may deliver message 402 to modules 404 and 405. ¶ [0043] 1st-4th sentences states the invention may use asynchronous communication to decouple different modules that execute in system 100. In all such embodiments, asynchronous communication may be embedded into system 100 so that its use remains transparent to the participating modules. Asynchronous communication may, but does not have to, take place for any message between the coarse grained modules depicted, or between different modules defining the content of system 100. Using synchronous communication for inter module communication may increase the degree of coupling between modules);
- “providing, by the one or more processors and using a producer client, the set of one or more event message payloads as a set of one or more input topics to a streaming server”
(Kerth ¶ [0005] 1st -2nd sentences: server receive and process requests from clients and other servers as computers of various entities located in different regions and/or countries. For example, at ¶ [0026] 2nd-3rd sentences: system 100 depicts message producers 110 and 120 connected, by communication network 130, to message consumer 140. For example, message producers 110 and 120 and message consumer 140 may be business computer systems. ¶ [0030] 9th-10th sentences: Message producers 110 and 120 and message consumer 140 instantiate a scope type at runtime to create a scope instance. A scope instance include logical ID for identifying this instance during runtime. ¶ [0031] 9th sentence: resource management modules 110-5,120-5,140-5 use scope instances to distribute locally-allocated objects in a network of collaborating nodes, such as message producers 110, 120 and message consumer 140, to increase transparency of remote communication. ¶ [0032] 4th-5th sentences: in Fig.1A, memory 110-3 of message producer 110 contains a context of 1st scope instance 110-6. Similarly, memory 120-3 of the message producer 120 contains a context of a 2nd scope instance 120-6. ¶ [0033] 1st sentence: Scope instances may migrate between message producer 110 and 120 and message consumer 140 by having one context in each of message producers 110 and 120 and message consumer 140. ¶ [0042] 1st-4th sentences: system 100 communicate asynchronously using topics. A topic is a construct the messages meeting a certain criteria published to. Fig.4 depicts an exemplary asynchronous communication 400 using topics. in Fig.4, module 401 may publish message 402 to topic 403. ¶ [0057] 3rd-5th sentences: Message 600 include message header 610 and message payload 620. The message header 610 include, for example, correlation ID 611 and other headers 612. The message payload 620 may include, for example, a target object ID 621, a target method name 622, and/or a set of method invocation parameters 623. ¶ [0058] 4th sentence: message payload 640 may include method invocation results 641), “wherein”
“(i) the streaming server is configured to provide, to a set of one or more consumer clients, (1) a set of one or more input topic streams” (Kerth ¶ [0042] 1st-4th sentences: system 100 may communicate asynchronously using topics. A topic is a construct the messages meeting a certain criteria may be published to. Fig.4 depicts an exemplary asynchronous communication 400 using topics. As shown in Fig.4, module 401 may publish message 402 to topic 403) “that (a) comprises the set of one or more event message payloads and (b) corresponds to the set of one or more input topics” (Kerth ¶ [0042] 4th sentence: publish message 402 to topic 403 with ¶ [0057] 3rd sentence stating that message 600 include message header 610 and message payload 620 and
¶ [0034] 7th disclosing inbound queue 140-6) “and (2) a set of one or more output topic streams” (Kerth ¶ [0042] 5th-6th sentence: modules 404 and 405 subscribe to topic 403 to indicate that they wish to receive messages published to topic 403. Then, topic 403 may deliver message 402 to modules 404 and 405. ¶ [0034] 2nd sentence: Outbound queues 110-9 and 120-9 contain outbound messages 110-10 and 120-10, respectively); “and”
“(ii) the set of one or more input topic streams is provided to the set of one or more consumer clients in a manner that is decoupled from an application traffic data pipeline of a downstream application of the set of one or more downstream applications” (Kerth ¶ [0040] Fig.2 illustrates exemplary system for transparently decoupling modules using scopes, consistent with the present invention. In S201, Module A, which may be located on one of message producers 110 and 120, invokes method on object instance of Module B, which may be located on message consumer 140. From the perspective of Module A, this is a local method invocation on an object instance in a local address space of Module A which represents an object instance of Module B. message producers 110 or 120 then queue the request message and detach the corresponding thread (e.g. threads 110-2 and 120-2) from the task of executing the method invocation in Module A (S202). This thread may then be used for other processing in local address space of Module A. The detachment causes execution of Module A to be paused for the duration of the method invocation (S203). Message provider 110 or 120 then transfer the request message to Module B (S204). System 100 may also implicitly copy any relevant scope contexts over to the local address space of Module B (S205). There are three ways to do this: message attachment and proactive or reactive (on demand) out-of-band-replication (as discussed in section Context Replication). Steps S204 and S205 may occur in parallel. System 100 then delivers the request message to the target object instance of the method invocation in the local address space of Module B (S206). Message consumer 140 executes the method, referencing the replicated scope contexts as necessary (S207). For example, if the method invocation made use of parameters then these parameters can be accessed from the replicated scope contexts. Message consumer 140 may then convert a result of the method execution into a response message and queue it in the local address space of Module B (S208). System 100 then transfer the response message to the local address space of Module A (S209). System 100 may implicitly replicate any changes made to the relevant scope contexts during the method execution in Module B back to local address space of Module A, using one of 3 replication mechanisms detailed below (S210). Again, steps S209 and S210 may occur in parallel. Message producer 110 or 120 then dequeue the response message by a thread (e.g. 110-2 and 120-2) in the address space of Module A and execution of Module A is resumed (S211). The thread dequeing the message may not be the same thread which launched the method invocation but it may have the same thread context as that original thread. During further execution of Module A, any relevant scope contexts may be accessed by Module A. Any changes made to resources allocated to such a context during the method invocation on Module B are visible to Module A. ¶ [0045] 3rd-10th sentences: In hierarchy 500, scope instance 510 may have context 511 that includes resources 512 and 513 allocated to scope instance 510. Scope instance 510 serve as a parent to child scope instances 520 and 530. Child scope instance 520 have context 521 that includes resources 522 and 523 allocated to child scope instance 520. Similarly, child scope instance 530 may have a context 531 that includes resources 532 and 533 allocated to child scope instance 530. Child scope instance 530 may also be a child of parent scope instance 540 having its own context 541 and allocated resources 542 and 543. Child scope instance 530 may also serve as a parent to child scope instance 550 having its own context 551 and allocated resources 552 and 553. The hierarchy may be navigable from parent to child and from child to parent, relying the respective identities of the participating scope instances);
- “receiving, by the one or more processors and using a consumer client of the set of one or more consumer clients, an event message payload of the set of one or more event message payloads from an input topic stream of the set of one or more input topic streams”;
(Kerth ¶ [0057] 1st-3rd sentences: resource management modules 110-5,120-5,140-5 go beyond managing resources inside a given instance of their respective infrastructures, and use scope contexts to transparently share related groups of data between message producers 110 and 120 and message consumer 140. Fig.6A depicts exemplary message 600 for transparently sharing context data between message producers 110 and 120 and message consumer 140. Message 600 may include message header 610 and message payload 620. Specifically per
Kerth ¶ [0042] System 100 may communicate asynchronously using topics as messages constructs meeting a certain criteria may be published to. Fig. 4 depicts exemplary asynchronous communication 400 using topics. in Fig.4, module 401 may publish message 402 to topic 403. Modules 404 and 405 subscribe to topic 403. That is, modules 404 and 405 may indicate that they wish to receive messages published to topic 403. Then, topic 403 may deliver message 402 to modules 404 and 405. In some embodiments consistent with asynchronous communication 400, modules 404 and 405 do not acknowledge consumption of message 402)
- “generating, by the one or more processors and using the consumer client, a transformed event message payload by applying one or more data transformation rules to the event message payload received from the input topic stream” (Kerth ¶ [0057] 5th sentence: message payload 620 include, target object ID 621, target method name 622, and/or set of method invocation parameters 623. Then, at ¶ [0058] 4th sentence: message payload 640 include method invocation results 641. ¶ [0036] 3rd-4th sentences: This method invocation may be performed on thread 110-2. The invoked resource then transform the method invocation into message 110-10, and thread 110-2 may put the message 110-10 on the outbound queue 110-9. Also Fig.8 and ¶ [0064] 7th sentence: the details of performing method invocations follow the steps outlined in Fig.2
Kerth ¶ [0040] 3rd-6th, 13th-18th sentences: noting another example where, from the perspective of Module A, this is a local method invocation on an object instance in a local address space of Module A which represents object instance of Module B. message producers 110 or 120 then queue the request message and detach the corresponding thread (e.g. threads 110-2 and 120-2) from the task of executing the method invocation in Module A (S202). This thread may then be used for other processing in the local address space of Module A. The detachment causes the execution of Module A to be paused for the duration of the method invocation (S203). Message consumer 140 executes the method, referencing the replicated scope contexts as necessary (S207). For example, if the method invocation made use of parameters then these parameters can be accessed from the replicated scope contexts. Message consumer 140 may then convert a result of the method execution into a response message and queue it in the local address space of Module B (S208). System 100 may then transfer the response message to the local address space of Module A (S209). System 100 may implicitly replicate any changes made to the relevant scope contexts during the method execution in Module B back to the local address space of Module A, using one of the three replication mechanisms detailed below (S210) ) “and”
- “providing, by the one or more processors and using the producer client, the transformed event message payload as an output topic to the streaming server, wherein the output topic corresponds an output topic stream of the set of one or more output topic streams”.
(Kerth ¶ [0042] 6th-7th sentences: modules 404 and 405 indicate that they wish to receive messages published to topic 403. Then, topic 403 deliver message 402 to modules 404 and 405.
Kerth ¶ [0036] 3rd-4th sentences: This method invocation may be performed on thread 110-2. The invoked resource then transform the method invocation into message 110-10, and thread 110-2 may put the message 110-10 on the outbound queue 110-9. Also Fig.8 and ¶ [0064] 7th sentence: the details of performing method invocations follow the steps outlined in Fig.2
Kerth ¶ [0040] 7th -20th senetnce: Message provider 110 or 120 may then transfer the request message to Module B (S204). System 100 may also implicitly copy any relevant scope contexts over to the local address space of Module B (S205). There are three ways to do this: message attachment and proactive or reactive (i.e., on demand) out-of-band-replication (as discussed below in the section on Context Replication). Steps S204 and S205 may occur in parallel. System 100 then delivers the request message to the target object instance of the method invocation in the local address space of Module B (S206). Message consumer 140 executes the method, referencing the replicated scope contexts as necessary (S207). For example, if the method invocation made use of parameters then these parameters can be accessed from the replicated scope contexts. Message consumer 140 may then convert a result of the method execution into a response message and queue it in the local address space of Module B (S208). System 100 may then transfer the response message to the local address space of Module A (S209). System 100 may implicitly replicate any changes made to the relevant scope contexts during the method execution in Module B back to the local address space of Module A, using one of the three replication mechanisms detailed below (S210). Again, steps S209 and S210 may occur in parallel. Message producer 110 or 120 may then dequeue the response message by a thread (e.g., threads 110-2 and 120-2) in the address space of Module A and execution of Module A is resumed (S211). The thread dequeing the message may not be the same thread which launched the method invocation but it may have the same thread context as that original thread. During further execution of Module A, any relevant scope contexts may be accessed by Module A. Any changes made to resources allocated to such a context during the method invocation on Module B are visible to Module A.
Kerth ¶ [0064] 7th-10th sentences: details of performing these method invocations follow the steps outlined in Fig.2, thereby guaranteeing a high degree of network transparency even when invoking remote modules. For example, message producer 110 or 710 may take advantage of this capability to shift some load to other systems which it itself cannot currently handle, or to enforce certain security constraints which limit critical processes to dedicated system instances in the network other than message producers 110 or 710. During the request processing, the message producer 110 or 710 may also choose to refresh implementation of module 110-4 or 710-4 (S805), following the steps outlined and in Fig.10. After completing processing of the request, the response is returned to the load balancer (S806) and from there to the client (S807)).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Rejections under 35 § U.S.C. 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2,10 are rejected under 35 U.S.C. 103 as being unpatentable over:
Kerth as applied to claims 1,9, in view of
Slik; David US 20150331621 A1 hereinafter Silk. As per,
Claims 2,10 Kerth teaches all the limitations in claims 1,9 above.
Kerth does not explicitly recite: “wherein another consumer client of the set of one or more consumer clients comprise a data repository interface configured to”
- “store the event message payload from the one or more input topic stream and the transformed event message payload from the output topic stream to respective first and second staging areas corresponding to an input topic of the set of one or more input topics and the output topic in a data repository” as explicitly claimed.
Silk however in analogous data transmission across multiple devices teaches/suggests:
“wherein the one or more consumer clients comprise another consumer client that comprises a data repository interface configured to”
- “store the event message payload from the one or more input topic stream and the transformed event message payload from the output topic stream to respective first and second staging areas corresponding to an input topic of the set of one or more input topics and the output topic in a data repository” (Silk ¶ [0053] 1st-2nd sentences: front-end subsystem 402 implemented as distributed computing network including multiple computing nodes (servers). Each computing node include an instance of staging area 408. ¶ [0054] 1st sentence: staging area 408 [interpreted as first staging area] can also serve as temporary cache to process payload data from a write request received at the protocol interfaces module 406. ¶ [0060] 2nd sentence: The payload of the write request can be stored in a file object staging area 510 (e.g. staging area 408 of Fig. 4).
Silk ¶ [0062] 1st sentence: after processing the payload data in accordance with the chosen transformation recipe, storage preprocessor subsystem 514 deposits the processed fragments into a fragment staging area 526 [interpreted as second staging area]).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Kerth’s method/system to have included Silk’s teachings or suggestions in order to have more effectively determined what types of storage efficiency processes to perform on the payload data (Silk ¶ [0054] 3rd sentence in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad skills of one of ordinary skills in the art as articulated by Silk ¶ [0017], ¶ [0174].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar data transmission field of endeavor. In such combination, each element merely would have performed same retrieval, processing and transfer function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Kerth in view of Silk, the to be combined elements would have fitted together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 3-5,11-13 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over:
Kerth as applied to claims 1,9,17 in view of
Yasuhiro Kitamura US 20190286589 A1 hereinafter Kitamura. As per,
Claims 3,11,18 Kerth teaches all the limitations in claims 1,9,17 above.
Kerth ¶ [0062] discloses: If message producer 110 dies unexpectedly, the client may continue its work on the standby message producer 710 by accessing the replicated context 710-6 from a new client scope instance which has been created on message producer 710 during failover processing. The new client scope instance can also load the content of the failed context on message producer 110 by accessing the replicated context 720-1 of database 720.
Kerth however does not explicitly recite: “further comprising”
- “identifying one or more potential data transmission failures associated with one or more outsized event message payloads of the set of one or more event message payloads or the transformed event message payload that exceed a data size limit” as claimed.
Kitamura in analogous art of data transfer teaches or at least suggests:
- “identifying one or more potential data transmission failures associated with one or more outsized event message payloads of the set of one or more event message payloads or the transformed event message payload that exceed a data size limit”
(Kitamura ¶ [0005] to transfer payloads with long [interpreted as outsized] message lengths at high throughput by DMA, a receive buffer for storing a large amount of payloads is implemented, which leads to resources increase in an information processing apparatus. Such increase in resources leads to suppressing [or failing] space saving and increase [or other failure] in manufacturing costs of the information processing apparatus. Accordingly, at
Kitamura ¶ [0006] to suppress increase in resources while improving throughput, a high-density buffer, such as SRAM, is often used as a receive buffer of DMA controller. For the purpose of improving the throughput of data transfer by DMA, the DMA controller uses high-density receive buffer, such as SRAM, to store a large [or outsized] amount of packets. Storing a large amount of packets in a receive buffer enables the DMA controller to reduce waiting for transmission of packets at the transmitter end, and successively writing data retained in the receive buffer to a memory improves the throughput of data transfer. However, typically, access to SRAM has a long latency [as other failure example] as compared with access to a usual receive buffer of flip-flops and the like. ¶ [0062] 2nd-4th sentences: Lengthening [or oversizing] the payload start portion may reduce the number of accesses to the packet buffer 142 and improve reduction in latency, as described below. However, if the start portion of a payload is lengthened, it takes longer time [as another example of failure] to read start data 202 and store start data 202 in header buffer 146. Accordingly, it is desirable to determine the length of a payload start portion in accordance with operations in consideration of balance between improvement in probability of latency reduction and the delay in the time taken to read and write the start data 202. ¶ [0100] 2nd-3rd sentences: noting an example where the payload length is longer [or oversized] than the payload start portion)
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Kerth’s method/system to have included Kitamura’s teachings or suggestions to have more effectively transfer data applicable is situations of variable length packets and fixed-length packets (Kitamura ¶ [0007] in view of MPEP 2143 C,D, or G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar data transfer field of endeavor. In such combination each element would have merely performed same identifying, processing and transfer function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Kerth in view of Kitamura, the to be combined elements would have fitted together like puzzle pieces in logical, complementary, technologically feasible and/or econocmailly desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claims 4,12,19 Kerth / Kitamura teaches all the limitations in claims 3,11,18.
Kerth does not explicitly recite: “performing exception handling of the one or more potential data transmission failures by”:
- “storing the one or more outsized event message payloads or the transformed event message payload to a data storage file system”;
- “providing one or more payload reference event messages associated with one or more outsized event message payloads or the transformed event message payload to an input topic
of the set of one or more input topics or the output topic, respectively, wherein the one or more payload reference event messages comprise one or more file references to the one or more outsized event message payloads transformed event message payload in the data storage file system” as claimed.
Kitamura however in analogous art of data transfer teaches or at least suggests:
performing exception handling of the one or more potential data transmission failures by:
- “storing the one or more outsized event message payloads or the transformed event message payload to a data storage file system”;
(Kitamura ¶ [0006] to suppress increase in resources while improving throughput, a high-density buffer, such as SRAM, is often used as a receive buffer of a DMA controller. For the purpose of improving the throughput of data transfer by DMA, the DMA controller uses a high-density receive buffer, such as SRAM, to store a large [or outsized] amount of packets. Storing a large [or outsized] amount of packets in a receive buffer enables DMA controller to reduce waiting for transmission of packets at transmitter end, and successively writing data retained in the receive buffer to a memory improves the throughput of data transfer) “and”
- “providing one or more payload reference event messages associated with one or more outsized event message payloads or the transformed event message payload to an input topic of the set of one or more input topics or the output topic, respectively, wherein the one or more payload reference event messages comprise one or more file references to the one or more outsized event message payloads transformed event message payload in the data storage file system” (Kitamura ¶ [0005] 1st sentence to transfer payloads with long [oversize] message lengths at high throughput by DMA, a receive buffer for storing a large amount of payloads is to be implemented. ¶ [0030] 1st sentence: When data having a long message length is transferred by DMA, existing data transfer by DMA is desirable. ¶ [0051] 3rd sentence… the size of the payload is greater than 8 bytes. ¶ [0053] 3rd-6th sentences: packet buffer 142 has address corresponding [or referencing] to each storage area. Data is stored in each storage area having an address. For example, in Fig.5, in a storage area with an address of zero, a header A of data A, which includes header A and payload A, is stored. In areas with addresses of 1 to 8 of packet buffer 142, payload A of data A is stored. write control unit 141 possesses a write address that corresponds [or refers] to 1st address of addresses to which a received packet is to be written. ¶ [0059] Thereafter, the header transfer unit 143 outputs start data 202 illustrated in Fig.7 including the read header and the read payload start portion, which is the first 8 bytes of the payload, to the header control unit 145. ¶ [0075] If the size of data transferred by DMA is greater [or oversized] than the size of payload start portion, the payload transfer unit 147 receives the payload transfer instruction 203 from header control unit 145. The payload transfer unit 147 acquires the payload read address and the length of a payload stored in the packet buffer 142 from the payload transfer instruction 203. ¶ [0080] If the size of data to be transferred by DMA is greater than the size of payload start portion, the DMA control unit 148 receives the command bus block 204 and data bus block 205 from the payload transfer unit 147. DMA control unit 148 receives command bus block 204 and data bus block 205 in each memory access unit until reading of all payloads is complete. DMA control unit 148 instructs the memory controller 13 to write the payload transmitted by using the data bus block 205 to a memory address contained in the command bus block 204 by using a byte mask contained in the command bus block 204).
Rationales to have modified/combined Kerth / Kitamura are above and reincorporated.
Claims 5,13,20 Kerth / Kitamura teaches all the limitations in claims 4,12,19 above.
Kerth does not recite “the one or more file references are indicative of one or more respective file locations for the one or more outsized event message payloads or the transformed event message payload from the data storage file system” as explicitly claimed.
Kitamura however in analogous art of data transfer teaches or at least suggests: “wherein the one or more file references are indicative of one or more respective file locations for the one or more outsized event message payloads or the transformed event message payload from the data storage file system”.
(Kitamura ¶ [0005] 1st sentence:…to transfer payloads with long [or outsize] message lengths…a receive buffer for storing large [or outsized] amount of payloads is… implemented…
Kitamura ¶ [0006] 2nd- 3rd sentences: …DMA controller uses a high-density receive buffer, such as SRAM, to store a large [or outsized] amount of packets. Storing a large [or outsized] amount of packets in a receive buffer enables the DMA controller to reduce waiting for transmission of packets at the transmitter end, and successively writing data retained in the receive buffer to a memory improves the throughput of data transfer.
Kitamura ¶ [0067] If size of data to be transferred by DMA is greater [or outsized] than the size of payload start portion, the header control unit 145 outputs payload transfer instruction 203…to transfer the payload in Fig.9 to payload transfer unit 147. Fig.9 is diagram … of a format of a payload transfer instruction. In payload transfer instruction 203, in Fig.9, a memory address, buffer address, and payload length are contained. The buffer address corresponds to 1st address [or location] of addresses for reading a payload from the packet buffer 142, and a payload read address is stored as the buffer address. ¶ [0068] Thereafter, header control unit 145 receives notification of completion of memory access from memory controller 13. The header control unit 145 then outputs a header release instruction to the header transfer unit 143. The header control unit 145 also outputs notification of completion of data transfer by DMA to CPU core 11. Similar
Kitamura ¶ [0075] If size of data to be transferred by DMA is greater [or outsized] than size of payload start portion, payload transfer unit 147 receives payload transfer instruction 203 from header control unit 145. payload transfer unit 147 acquires payload read address [or location] and the length of payload stored in packet buffer 142 from payload transfer instruction 203.
Kitamura ¶ [0076] payload transfer unit 147 calculates a byte mask in the packet buffer 142 from acquired payload read address [or location] and the payload length and generates the command bus block 204. The payload transfer unit 147 then outputs the generated command bus block 204 to DMA control unit 148. ¶ [0077] Thereafter, payload transfer unit 147 reads a payload, generates the data bus block 205, and outputs the data bus block 205 to the DMA control unit 148. For example, if a payload greater [or outsized] than or equal to data corresponding to a memory access unit remains without being transferred to DMA control unit 148, payload transfer unit 147 reads the payload in an amount corresponding to memory access unit. Upon completion of reading the payload in the amount corresponding to the memory access unit, the payload transfer unit 147 generates data bus block 205 by using the read payload corresponding to the memory access unit and outputs the generated data bus block 205 to the DMA control unit 148.
Kitamura ¶ [0100] 2nd-3rd sentences: If the payload length is longer [or outsized] than the payload start portion (step S305: No), the header control unit 145 issues the payload transfer instruction 203 including a payload read address [or location] to payload transfer unit 147 (step S306). A description of the payload transfer process is provided below with respect to Fig.15. ¶ [0105] Next, the header control unit 145 adds the payload length to the payload read address to calculate the read address [or location] of the next header (step S311). ¶ [0112] Next, the payload transfer unit 147 calculates a final address [or location] in which the payload length is added to the specified payload read address [or location]. payload transfer unit 147 determines whether the final address [or location] is equal to the read address [or location] (step S406). ¶ [0114] Meanwhile, if the final address [or location] is equal to the read address [or location] (step S406: Yes), the payload transfer unit 147 completes the payload transfer process).
Rationales to have modified/combined Kerth / Kitamura are above and reincorporated.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 6,14 are rejected under 35 U.S.C. 103 as being unpatentable over:
Kerth / Kitamura as applied to claims 5,13, in view of
Matta Chirs, How to Use Single Message Transforms in Kafka Connect, confluent io webpages, Nov 7, 2019. As per,
Claims 6,14 Kerth / Kitamura teaches all the limitations in claims 5,13, above.
Kerth does not recite “wherein another consumer client of the set of one or more consumer clients comprises a single message transform plugin”
- “determine the one or more respective file locations for the one or more outsized event message payloads by scanning the one or more payload reference event messages for the one or more file references”;
- “receive the one or more outsized event message payloads or the transformed event message payload from the data storage file system based on the one or more respective file locations” as claimed.
Kitamura however in analogous art of data transfer teaches or at least suggests:
- “receive the one or more outsized event message payloads or the transformed event message payload from the data storage file system based on the one or more respective file locations” (Kitamura ¶ [0075] If the size of data to be transferred by DMA is greater than the size of payload start portion, the payload transfer unit 147 receives the payload transfer instruction 203 from header control unit 145. The payload transfer unit 147 acquires the payload read address and the length of a payload stored in the packet buffer 142 from the payload transfer instruction 203. ¶ [0076] The payload transfer unit 147 calculates a byte mask in the packet buffer 142 from the acquired payload read address and the payload length and generates the command bus block 204. The payload transfer unit 147 then outputs the generated command bus block 204 to the DMA control unit 148. ¶ [0077] Thereafter, the payload transfer unit 147 reads a payload, generates the data bus block 205, and outputs the data bus block 205 to the DMA control unit 148. For example, if a payload greater than or equal to data corresponding to a memory access unit remains without being transferred to the DMA control unit 148, the payload transfer unit 147 reads the payload in an amount corresponding to the memory access unit. Upon completion of reading the payload in the amount corresponding to the memory access unit, the payload transfer unit 147 generates the data bus block 205 by using the read payload corresponding to the memory access unit and outputs the generated data bus block 205 to the DMA control unit 148. ¶ [0080] If the size of data to be transferred by DMA is greater than the size of the payload start portion, the DMA control unit 148 receives the command bus block 204 and the data bus block 205 from the payload transfer unit 147. The DMA control unit 148 receives the command bus block 204 and the data bus block 205 in each memory access unit until reading of all the payloads is complete. The DMA control unit 148 instructs the memory controller 13 to write the payload transmitted by using the data bus block 205 to a memory address contained in the command bus block 204 by using a byte mask contained in the command bus block 204).
Rationales to have modified/combined Kerth / Kitamura are above and reincorporated
Kerth / Kitamura as combination however does not recite: “wherein another consumer client of the set of one or more consumer clients comprises a single message transform plugin”
- “determine the one or more respective file locations for the one or more outsized event message payloads by scanning the one or more payload reference event messages for the one or more file references”; as claimed.
Matta in an analogous art of data processing and transfer including receiving a connect record and returning a connect record [i.e. destination topic, destination partition, supra] (Matta p.5) as pertinent to the last limitation, teaches or at least suggests:
wherein another consumer client of the set of one or more consumer clients comprises a single message transform plugin” (Matta p.3 section entitled deep dive on single message transforms emphasis on p.3 last ¶: Transformations are compiled as JARs and are made available to Kafka Connect via the plugin.path specified in the Connect worker's properties file Once installed, the transforms can be configured in the connector properties) “configured to”:
- “determine the one or more respective file locations for the one or more outsized event message payloads by scanning the one or more payload reference event messages for the one or more file references”; (Matta p.4 Section entitled: How do you write a single message transform? To build a simple transformation that inserts a UUID into each record, let’s walk through the steps below. The code is also available on GitHub. Apply functions are the core of transformations. This transform supports data with and without a schema, so there’s one transform for each. The main apply() method routes the data appropriately:
@Override public R apply(R record) { if (operatingSchema(record) == null) { return applySchemaless(record); } else { return applyWithSchema(record); } } private R applySchemaless(R record) { final Map<String, Object> value = requireMap(operatingValue(record), PURPOSE); final Map<String, Object> updatedValue = new HashMap<>(value); updatedValue.put(fieldName, getRandomUuid()); return newRecord(record, null, updatedValue); } private R applyWithSchema(R record) { final Struct value = requireStruct(operatingValue(record), PURPOSE); Schema updatedSchema = schemaUpdateCache.get(value.schema()); if(updatedSchema == null) { updatedSchema = makeUpdatedSchema(value.schema()); schemaUpdateCache.put(value.schema(), updatedSchema); } final Struct updatedValue = new Struct(updatedSchema); for (Field field : value.schema().fields()) { updatedValue.put(field.name(), value.get(field));
} updatedValue.put(fieldName, getRandomUuid()); return newRecord(record, updatedSchema, updatedValue); }
public static class Key<R extends ConnectRecord<R>> extends InsertUuid<R> { @Override protected Schema operatingSchema(R record) { return record.keySchema(); } @Override protected Object operatingValue(R record) { return record.key(); } @Override protected R newRecord(R record, Schema updatedSchema, Object updatedValue) { return record.newRecord(record.topic(), record.kafkaPartition(), updatedSchema, updatedValue, record.valueSchema(), record.value(), record.timestamp()); }} public static class Value<R extends ConnectRecord<R>> extends InsertUuid<R> { @Override protected Schema operatingSchema(R record) { return record.valueSchema(); } @Override protected Object operatingValue(R record) { return record.value(); } @Override protected R newRecord(R record, Schema updatedSchema, Object updatedValue) { return record.newRecord(record.topic(), record.kafkaPartition(), record.keySchema(), record.key(), updatedSchema, updatedValue, record.timestamp()); }}
This transform only changes the schema and value, but notice that we can manipulate all parts of the ConnectRecord:… destination topic, destination partition, and timestamp)
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Kerth / Kitamura’s method/system to have included Matta’s teachings to have provided a reliable, scalable and distributed streaming integration and have also provided a simple interface for manipulating records as they flow through both the source and sink nodes of the data pipeline (Matta pp.1-2, in view of MPEP 2143 C, D and/or G)
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar data processing and transfer field of endeavor. In such combination each element merely would have performed the same analytical, processing, and transfer function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Kerth / Kitamura in further view of
Matta the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the combination results would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 7,15 are rejected under 35 U.S.C. 103 as being unpatentable over:
Kerth as applied to claims 1,9 in view of
Noam Bar-On US 20210406836 A1 hereinafter Noam. As per,
Claims 7,15 Kerth teaches all the limitations in claims 1,9 above.
Kerth does not explicitly recite:
- “wherein the one or more data transformation rules comprise one or more parsing logics based on a natural language-based template definition language” as claimed.
Noam in analogous data transfer between two or more client devices teaches/suggests:
- “wherein the one or more data transformation rules comprise one or more parsing logics based on a natural language-based template definition language”
(Noam ¶ [0213]: 6th-11th sentences: any suitable information extracted by any suitable number of parsers to be displayed in task list 328. For example, a task can be created by a parser receiving as input an email containing a phrase like “can you have this done by Friday?” In such an example, a parser may be configured to identify a due date. Another parser can be configured to leverage a natural language processing module to determine that, contextually, an earlier message in a thread containing the processed message referenced “fix floor six network switch.” These two extracted data items can be used to create a task item that can be presented in the task list 328. In some cases, another parser can be configured to detect whether a statement indicating that a particular task is complete has been made; if so, a completion mark 330 can be rendered alongside the associated task in the task list 328. This may be particularly useful for managers tracking work of a number of individual employees).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Kerth’s method/system to have included Noam’s teaching or suggestions in order to have increased efficiency with which information is exchanged between senders and recipients, while at the same time having improved the functionality of internetworked computing networks, enhanced privacy (Noam ¶ [0036]-¶ [0037], ¶ [0088] in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Noam ¶ [0295]-¶ [0296], ¶ [0322].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar information or data transfer field of endeavor. In such combination each element would have merely performed the same analytical, processing and transfer function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Kerth in view of Noam, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 8,16 are rejected under 35 U.S.C. 103 as being unpatentable over:
Kerth as applied to claims 1,9, in view of
Patel et al, US 20080025230 A1 hereinafter Patel. As per,
Claims 8,16 Kerth teaches all the limitations in claims 1,9 above.
Kerth teaches “wherein the transformed event message payload comprises one or more ” (Kerth ¶ [0057] 5th sentence: message payload 620 may include, for example, a target object ID 621, a target method name 622, and/or a set of method invocation parameters 623. ¶ [0058] 4th sentence: That is, the message payload 640 may include method invocation results 641).
Kerth does not recite “wherein the transformed event message payload comprises one or more flat reportable object data structures” [bolded emphasis added]. Yet,
Patel in analogous of transition of application associated messages teaches/suggests:
“wherein the one or more transformed event message payloads comprise one or more flat reportable object data structures” (Patel ¶ [0154] 2nd sentence: a network element can receive an application-layer message that contains a flat file payload, convert the flat file payload to a relational database table [as example of data structures], and forward the table to RDBMS server).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Kerth’s method/system to have included Patel’s teachings in order to have more effectively allowed the transfer hop of data packets among different clients (Patel ¶ [0015]-¶ [0020] in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Patel ¶ [0064].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor dealing with transition of application associated messages. In such combination each element merely would have performed same analytical, processing, and transfer function as separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements evidenced by Kerth in view of Patel, the to be combined elements would have fitted together like puzzle pieces in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the combination results would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant's disclosure:
- Akanbi et al, A Distributed Stream Processing Middleware Framework for Real Time Analysis of Heterogeneous Data on Big Data Platform, Case of Environmental Monitoring, Sensors 20,11, p3166, Jun 3, 2020
- WO2007001941A2 teaching the network infrastructure performing brokering network identity and credential information
- US 20180373661 A1 teaching Asynchronous channel based bus architecture enabling decoupled services as summarized in its Title and detailed in its disclosure
- US 20230379310 A1 ¶ [0060] Fig.2 shows a flow diagram illustrating the neutral application programing interface (API) mechanism carrying a data array as an inner payload inside an outer payload, in accordance with an embodiment of the present disclosure. FIG. 2 illustrates the neutrality of the API mechanism where all request and response outer payloads adhere to the same data structure pattern. In other words, all request and response outer payload adhere to a common definition, which has the same consistent structure, fields, etc. This “same-pattern” preparation, delivery and parsing framework allows for a very flexible, dynamic abstraction of unlimited API actions which can be carried by the mechanism. This approach may also offer the opportunity to secure the data payload wrapped in one or more layers of security. An added benefit is that the API itself becomes the delivery system for its own structural definitions and new functionality can be added to its actions matrix through the publishing of API actions and related scripts, data structure definition and other relevant information via the API itself.
- US 20210279239 A1 describing at its Abstract: A trihybrid data movement, data governance and data provenance system may include a distribute module, a publisher and a plurality of subscribers. The distribute module may include a user interface. The user interface may receive a publication registration from the publisher. The publication registration may register a publication. The user interface may receive a subscription registration from each of the plurality of subscribers. The subscription registration may subscribe to the publication. The publication registration and/or subscription registration may include metadata relating to the publication and/or subscription. A metadata store, included in the distribute module, may store the publication registration and/or the subscription registration. The publication may be published by transmitting a unique identifier from the publisher to an application programming interface within the distribute module. The distribute module may transmit, based on the stored publication registration and subscription registration, a customized publication to each of the plurality of subscribers.
- US 20190013992 A1 ¶ [0008] 1st sentence: Disclosed embodiments provide a stream-based application programming interface API, which provides flow-control and needs only basic data, e.g., the payload and acknowledge callbacks, via the API.
- US 20210334132 A1 Data set subscription tracking and termination system, emphasis on Figs.4-8 and associated text
- US 20210099411 A1 emphasis on Figs. 2A-D and associated text
- US 20210406836 A1 Classification engine instance informing parsing of emails received by an email client instance executed by a mobile device
- US 11044298 B1 column 21-29 the API format for the remote graph query provider 146, and transmit the generated message to the remote graph query provider 146. The remote graph query provider 146 executes the API payload of the message to cause the changes to be applied to the server-side copy of the example row object in the data store 165. Note that the change object may be used universally as a format for local storage and for submission to the data providers.
- US 20170192832 A1 Providing an application interface programming exception in an upper management layer teaching sending the payload from upper to lower management
- US 20240004736 A1 teaching Point-to-point data integration methods and systems may include receiving a source payload, generating an entity relationship diagram based on the source payload, generating structured data based on the source payload, generating a representational state transfer application programming interface based on the structured data, and publishing an application programming interface endpoint configured to receive a call to the representational state transfer application programming interface from a third-party application via an internet connection.
- US 20210182809 A1 ¶ [0015] Clause 7: The method of any of clauses 1-6, wherein the payment transaction message comprises a payload, and wherein modifying the one or more API fields of the payment transaction message comprises: modifying the one or more API fields of the payment transaction message independent of modifying the payload of the payment transaction message.
- US 10592302 B1 teaching specifying API authorization policies and parameters
- US 20200327137 A1 ¶ [0004] input APIs: (i) receive inputs associated with the digital data object from a plurality of data source systems, wherein one or more of the data source systems are different and (ii) extract metadata and the data payloads from the inputs. Further, the plurality of blockchain REST APIs may be configured to: (i) generate at least one blockchain data object based on the extracted metadata and data payloads or modify at least one blockchain data object existing within the blockchain and (ii) load the at least one blockchain data object onto the blockchain. According to an embodiment, the system may also include an artificial intelligence (AI) module configured to modify at least one blockchain data object in the blockchain based at least in part on a user-identified goal and a machine learning engine.
- US 11228656 B1 teaching Resilient communication protocols and interfaces among subscribers and publishers
- US 8135926 B1 Cache-based control of atomic operations in conjunction with an external ALU block reciting at column 15 lines 20-25: As described above in conjunction with Fig.4A, the atomic command buffer 412 is a [first in first out] FIFO buffer where different atomic commands are output in the order in which the atomic commands are received. At step 606, the associated atomic data payload is temporarily stored in the atomic data buffer 404. Column 13 lines 60-63: As described above in conjunction with FIG. 4B, the atomic command is temporarily stored in the crossbar command buffer 422 and the associated atomic data payload is temporarily stored in the crossbar data buffer 418.
US 20140059170 A1 ¶ [0091] In some examples, the first device may also include a memory coupled to the one or more processor circuits. The memory may be arranged to at least temporarily store data payloads received at the first media access controller from the network communication channel in one or more data frames or configured to at least temporarily store data payloads received at the second media access controller from the host computing device in one or more data frames. The memory may include volatile memory. ¶ [0050] 1st sentence: Proceeding to process 5.5 (Transmit Second Data Frame), data manager 105 at MAC 130 may include logic and/or features to receive the packet processed data payload from processor 110 (e.g., via receive feature 312) and to transmit this processed data payload in a second data frame to network 160 (e.g., via transmit feature 316).
US 20230051122 A1 mid-¶ [0055] As illustrated, configuration instruction 520 includes a first payload which can be at least a portion of a pre-staged instruction for storage in instruction register 509, and configuration instruction 530 includes a second payload which can be at least a portion of a second pre-staged instruction for storage in instruction register 510.
US 20240089042 A1 ¶ [0058] 1st sentence MHU [message handling unit] provides uni-directional communication from upstream to downstream devices using sending circuitry associated with the upstream device and receiving circuitry associated with the downstream device. ¶ [0042] receiving circuitry 210 comprises interface circuitry 450 to handle interfaces 212, 214 in Fig.2; storage circuitry 460 to provide temporary [or stagging] storage of data being forwarded to downstream devices…
US 20210218802 A1 teaching synchronizing data between hub and spoke environments
US 20060117238 A1 ¶ [0051] 4th sentence: two or more converted payload messages may be stored in the staging database 535.
US 20110055510 A1 ¶ [0056] 3rd sentence: PORT-0 receives a first data packet via a receive link layer 406 and temporarily stores the payload of the first data packet into a payload buffer 408 via an input 410. ¶ [0058] 1st sentence: Similarly, PORT-1 receives a second data packet via a link layer (not shown) and temporarily stores the payload of the second data packet into payload buffer 408 via an input 418
- US 20070156882 A1 ¶ [0134] Frag and MMP allow the user of the software architecture 10 flexibility in designing the application messaging strategy. If a developer chooses to use very large messages, Frag can be used so that messages larger than the payload 28A (i.e., 13 bytes within the exemplary application packet structure 28 shown herein) can be sent by sending the original large data set as multiple smaller data sets within multiple packets of structure 28.
¶ [0423] Frag, bit 6 of Byte 2 in the software architecture 10 header, enables the software architecture protocol to send payloads greater than that of the underlying protocol (i.e. that of the internal communication network 14). When Frag is set, the receiver should realize that the current message will be fragmented into multiple packets or fragments. ¶ [0424] In the message-fragment id model, the first fragment of a fragmented message uses the standard packet structure as described in FIG. 4. This initial fragment provides the message's API, Op Code, and Cmd/Fb flag. All subsequent fragments of the message will preferably assume the fragmented message structure described in FIG. 24. In this structure, the Frag flag still exists (along with the MMP flag) to reinforce the data. However, Byte 2 now contains the more fragments pending flag (MFP) in bit 5, message id (MID) in bits 3-4, and fragment id (FID) in bits 0-2. ¶ [0425] The MFP flag informs the receiver that at least one more fragment of the current message should be expected. The transition of MFP from 1 to 0 informs the receiver that the current packet is the final packet of the current message. MID provides a 2-bit identifier for each message. Thus, each fragmented message (group of fragments) will be assigned a MID, and this MID will then increment for each subsequent fragmented message (group of fragments). The MID will increment to 3 and then rollover back to 0. FID provides a 3-bit identifier for each fragment within a message. Thus, for a particular message, the first fragment will always be assigned and FID of 0. For each subsequent fragment of that message, the FID will be incremented. The FID will increment to 7 and then rollover back to 0. ¶ [0426] The fragmentation protocol provided by this invention allows the receiver to check the integrity of a fragmented message. By monitoring the Frag and MFP flag, the receiver can ensure no erroneous halts to a fragmented message. By checking that the MID does not change within reception of a single fragmented message, the receiver can ensure that two separate fragmented messages do not become merged (perhaps due to a lost fragment). By checking that the FID correcting increments per fragment, the receiver can ensure that not fragment is lost within a message (or received out of order). See FIG. 25 for an example of the message-fragment id model.
- US 20220021629 A1 Fig.5 step 116, ¶ [0067] Note that in some applications, to send a large message over the communication network, the source of the packets needs to break the message into multiple payloads to be transmitted within multiple packets so as to meet an MTU limitation of the network. Using the coalescing mechanism described above, the network adapter at the receiving side, reproduces the large message (or part thereof) by storing the relevant payloads contiguously in a chunk, as described above. ¶ [0086] 2nd – 3rd sentences:
At a chunk occupancy checking step 116, the network adapter checks whether the remaining storage space in the current chunk is large enough for storing the payload of the received packet (possibly including a nonzero gap). If so, and if the gap value is zero, network adapter 38 contiguously scatters the entire payload of the received packet in the current chunk subsequently to already stored payloads, if any, at a full payload storing step 120.
- US 20220035365 A1 ¶ [0032] second sentence to last sentence: For example, a V2X wireless message includes a payload whose file size is too big to be transmitted using the bandwidth available to any one vehicle and so the payload is broken into segments and transmitted at the same time (or contemporaneously) via multiple wireless messages by multiple micro cloud members. In some embodiments, the data communication task is broken down into sub-tasks whose completion is equivalent to completion of the data storage task. In this way, the processors of a plurality of micro cloud members are assigned different sub-tasks configured to complete the data storage task; the micro cloud members take steps to complete the sub-tasks in parallel and share the result of the completion of the sub-task with one another via V2X wireless communication. In this way, the plurality of micro cloud members work together collaboratively to complete the data storage task. For example, a sub-task for a data communication task includes transmitting a portion of a payload for a V2X message to a designated endpoint; other micro cloud members are assigned sub-tasks to transmit the remaining portions of payload using their available bandwidth so that collectively the entire payload is transmitted
- US 10901819 B1 column 7 lines 49-67: Kafka has been widely used as a messaging service due to its reliability (i.e., guarantees delivery) and overall speed. However, Kafka is subject to potential end-to-end latency issues when large messages (e.g., over 1 KB), which are often produced by producer applications, are involved. Additionally, Kafka operates in a persistent manner which introduces disk input/output operations (e.g., reading or writing to a disk), and which may cause additional latency. With potentially several hundred million events being generated daily, Kafka is susceptible to latency issues. (33) Unlike Kafka, which operates in persistent manner (i.e., Kafka saves event messages onto a disk), Redis utilizes RAM and operates similar to cache. Redis is a NoSQL, in-memory database, which makes it a prime candidate for a fast messaging backbone. Firstly, Redis is extremely fast by virtue of it not being persistent (i.e., stores in memory), and thus, does not introduce latency with large messages. Furthermore, Redis has well-maintained native libraries for many languages and thus is easy to integrate.
- US 9888034 B2 column 4 line 64-column 6 line 12: sending out messages which match the schema but with oversize elements to exhaust the resource. For SOAP messages, it includes: Oversized payloads; Oversized element names, attribute names, and processing instruction target names; Oversized attributes array per element; Elements which exceed the max nesting depth; or Oversized processing instructions, comments, single CDATA items, and attribute values. For Restful (JSON) messages, it includes: Oversized message layout; Oversized JSON element value; Oversized JSON array elements; and Oversized nesting element depth.
- US 20240188050 A1 ¶ [0281] 2nd sentence: first indication information is encapsulated in a payload of the first message outside the master information block MIB
- US 20070005801 A1 ¶ [0102] 2nd sentence: a network element can receive an application-layer message that contains a flat file payload, convert the flat file payload to a relational database table, and forward the table to an RDBMS server.
- US 20070005786 A1 XML message validation in a network infrastructure element
- US 20220121562 A1 ¶ [0050] Fig.4 shows an example root.yml file. As shown in FIG. 4, in some embodiments the root.yml file is implemented as a flat data structure having a set of key:value pairs. The key of each entry is the object, and the value initially is a staging_object.yml file created by the API reader 210 for the respective object. The flat content in the staging_object.yml needs to be converted into specific structure, in terms of operation (REST End Point), payload(inputs in the form of JSON) and validation details. In some embodiments, this is done by the API converter module 215, as discussed in greater detail below.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (571)270-5396. 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.
/Octavian Rotaru/
Primary Examiner, Art Unit 3624 A
June 17th, 2026
1 CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011) (quoting In re Warmerdam, 33 F.3d 1354, 1355, 1360, 31 USPQ2d 1754, 1755, 1759 (Fed. Cir. 1994)
2 USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04, with respect to the patentable weight of intended use or result
3 CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011) (quoting In re Warmerdam, 33 F.3d 1354, 1355, 1360, 31 USPQ2d 1754, 1755, 1759 (Fed. Cir. 1994)
4 USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04, with respect to the patentable weight of intended use or result
Prosecution Insights