Prosecution Insights
Last updated: October 02, 2026
Application No. 18/623,521

SYSTEMS AND METHODS FOR FACILITATING DECOUPLED DISTRIBUTION FROM A MAINFRAME TO DISTRIBUTED PLATFORMS

Non-Final OA §101§103
Filed
Apr 01, 2024
Priority
Apr 05, 2023 — provisional 63/494,302
Examiner
ALAM, SHIHAB
Art Unit
Tech Center
Assignee
The Bank of New York Mellon
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-60.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
15 currently pending
Career history
13
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§101 §103
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This Office Action is in response to claims filed 04/01/2024. Claims 1-20 are pending. 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 recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below. Step 1: Claims 1-7 are directed to methods and fall within the statutory category of processes; Claims 8-14 are directed to a system and falls within the statutory category of machines; Claims 15-20 are directed to a non-transitory, machine-readable medium and falls within the statutory category of manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes. In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application. Step 2A Prong 1: Claims 1, 8 and 15 : The limitations “curating, by a processor, a data feed from the mainframe;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can arrange for a resource to provide information. Therefore, yes, Claims 1, 8 and 15 recite judicial exceptions. The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception. Step 2A Prong 2: Claims 1, 8 and 15: The judicial exceptions are not integrated into practical applications. In particular, the claims recite the following additional elements – “facilitating decoupled distribution from a mainframe to one or more distributed platforms”, “reading” … “the data feed;”, “generate/generating” … “an input file for distribution to an event platform topic representing the data feed, wherein the event platform topic is hosted on an event platform;”, “writing” … “the input file to the event platform topic;”, “providing” … “the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer”, merely recite insignificant extra-solution data gathering, data transmission, and data storage which do not integrate the judicial exception into a practical application. See MPEP § 2106.05(g). Further, “one or more code sets stored in the data file and executing in the processor”, “the instructions when executed by a processor being configured to perform operations”, is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)). Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that the Claims 1, 8 and 15 not only recite a judicial exception but that the claims are directed to a judicial exception as a judicial exception has not been integrated into a practical application Step 2B: Claims 1, 8 and 15: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra-solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra-solution activity is Well-Understood, Routine, and Conventional. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network … iv. Storing and retrieving information in memory”. See MPEP § 2106.05(d)(II). Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception. Having concluded analysis within the provided framework, Claims 1, 8 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claims 2, 9 and 16: “a given data feed is curated based on one or more predefined parameters”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can arrange for a resource to provide information. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 2, 9 and 16 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 2, 9 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claims 3, 6, 10, 13 and 17: “the data feed is a batch data feed”, “the data feed is a repeating data feed”, and “ the data feed is at least one of a batch data feed or a repeating data feed”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can arrange for a resource to provide information. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 3, 6, 10, 13 and 17 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 3, 6, 10, 13 and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claims 4, 11 and 18: “a payload of the input file is one of text, JSON, or Avro”, reciting insignificant extra-solution data transmission and storage activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 4, 11 and 18 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network … iv. Storing and retrieving information in memory”. See MPEP § 2106.05(d)(II). Therefore, Claims 4, 11 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claims 5, 12 and 19: “the request is triggered by a subscription to the event platform topic”, reciting insignificant extra-solution data gathering/transmission activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 5, 12 and 19 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network”. See MPEP § 2106.05(d)(II). Therefore, Claims 5, 12 and 19 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claims 7, 14 and 20: “receiving, by the processor, from the event platform topic, client-generated data read from a given event platform topic of the event platform; and storing, by the processor, the client-generated data in the mainframe” reciting insignificant extra-solution data transmission and storage activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 7, 14 and 20 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network … iv. Storing and retrieving information in memory”. See MPEP § 2106.05(d)(II). Therefore, Claims 7, 14 and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-4, 7-11, 14-16, 18 and 20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bishop et al. ( US 20170046361 A1 ) (hereinafter Bishop), in view Bowman et al. ( US 20230028620 A1 ) (hereinafter Bowman), in further view of Hamburger et al. ( US 20170257282 A1 ) (hereinafter Hamburger). Regarding Claim 1, Bishop teaches: A method for facilitating decoupled distribution from a mainframe to one or more distributed platforms, “The disclosed system may comprise a mainframe computing resource, a data library, a data processing appliance, and a distributed system” … “The distributed system may be further configured to process the data based on a workflow from the mainframe computing system", (Bishop: Abstract), “a method of sharing data between a mainframe computing resource and a distributed system is provided”, (Bishop: ¶3), “For example, distributed system 140 may be a real-time data processing system that is configured to receive real-time data from mainframe computing resource 110 via data processing appliance 120. In this regard, distributed system 140 may be able to stream data from mainframe computing resource 110 via data processing appliance 120 removing the typical data transfer and copy step via an FTP protocol”, (Bishop: ¶25). comprising: curating, by a processor, a data feed from the mainframe; “computing systems including a processor for processing digital data;”, (Bishop: ¶64), “The data processing appliance may be configured to transform, share, protect, stream, and/or otherwise process enterprise data stored on the mainframe system”, (Bishop: ¶22), “data processing appliance 120 may be configured to perform in-line processing including, for example, data transformation” … “, masking (e.g., especially format-preserving), filtering (e.g., based on keywords, errors, sensitive data, and/or the like), and/or the like”, (Bishop: ¶29), “Method 400 may further comprise removing, by data processing appliance 320, mainframe tape information from the data (Step 409). In this regard, data processing appliance 320 may preprocess the data to make the data suitable conversion and/or processing by distributed system 340”, (Bishop: ¶45), “the integration service may normalize the files created by mainframe computing resource 210, on the back up device, so they appear as normal distributed files to distributed system 240”, (Bishop: ¶37). reading, by the processor, the data feed; “data processing appliance 220 and/or data library 230 may be detected and/or viewed as a tape backup device. In this regard, data processing appliance 220 and/or data library 230 can be written and read by both mainframe computing resource 210 and distributed system 240”, (Bishop: ¶37), “method 400 may further comprise reading, by data processing appliance 320, the data from the data library 330 (Step 407)”, (Bishop: ¶45). Further regarding Claim 1, Bishop fails to teach: generating, by the processor, an input file for distribution to an event platform topic representing the data feed, However, Bowman teaches: “The input document streams include one or more document messages including one or more documents (e.g., a file or other data object that can be electronically transmitted and stored)…”, (Bowman: ¶38), “In an embodiment, the file generation module 445 generates asset files, stream data files, and static rendered files. In an embodiment, the asset files can be denoted by an “assets” property of a configuration file (e.g., a JSON file). The asset files may be copied verbatim from the artifact to a module for provisioning to the user system” … “the file generation module 445 queues files to be used in the deploy onto a “topic” (e.g., an Apache Kafka topic) which is then read by another microservice or system that is responsible for storing the files in the cloud for serving to the end-user (e.g., the customer)”, (Bowman: ¶54), “the stream data files based on the stream data and are kept up to date with the data as long as the pipeline remains active. The file generation module 445 loads all of the documents for each of the streams the user system website depends on from the stream data structure and queues them onto the topic”, (Bowman: ¶55), “the file generation module 445 looks at the static file template entrypoints defined in the configuration and for each of these, queues an empty document with some additional tagging denoting which content and URL templates to use. In an embodiment, the static rendered files may then be processed like the stream data files”, (Bowman: ¶56). wherein the event platform topic is hosted on an event platform; However, Bowman teaches: “, the messaging system 113 can be configured to interact with a publish-subscribe based messaging system configured to exchange data between processes, application, and servers (e.g., the Apache Kafka® distributed streaming platform)” … “the messaging system 113 is configured to receive document input streams from one or more clusters of servers of the messaging system” … “the messaging system is configured to store streams of document messages organized or grouped according to a parameter (e.g., a topic), where each document message is associated with identifying information (e.g., a key, a value, and a timestamp)” … “A topic can include a category used to organize messages, where each topic has a name that is unique across a cluster” … “where producers write data to topics, and consumers read data from topics”, (Bowman: ¶39). Examiner notes: Apache Kafka is being interpreted as an event platform and the organized streams is being interpreted as event platform topic. writing, by the processor, the input file to the event platform topic; However, Bowman teaches: “Messages can be sent to and read from specific topics, where producers write data to topics, and consumers read data from topics”, (Bowman: ¶39), “the file generation module 445 queues files to be used in the deploy onto a “topic” (e.g., an Apache Kafka topic) which is then read by another microservice or system that is responsible for storing the files in the cloud for serving to the end-user (e.g., the customer)”, (Bowman: ¶54), “the rendered files are queued on the topic and tagged with one or more of the activity identifier, instance identifier, and path identifier”, (Bowman: ¶65), “asset files, when written to the topic by file generation module 445, may also have a corresponding event log with an imaginary document key and the URL for each file”, (Bowman: ¶58). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine generating, by the processor, an input file for distribution to an event platform topic representing the data feed wherein the event platform topic is hosted on an event platform; writing, by the processor, the input file to the event platform topic; of Bowman with the methods and systems of Bishop resulting in a system that can distribute generated files based on data received from a feed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “decoupling these phases, the streaming static web page generation system provides processing environments that are uniquely optimized for distinct responsibilities of each phase, yielding an overall faster performance, compared with comparable technologies”, (Bowman: ¶13). Further regarding Claim 1, Bishop in view of Bowman fails to teach and providing, by the processor, the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer. However, Hamburger teaches: “In broadcast mode, a client application sends a message to one or more client applications without expecting a response. The broadcast message indicates a topic to which the client application is publishing the message. The messaging system delivers the broadcast message to client applications subscribed to the topic…”, (Hamburger: ¶23), “the messaging system receives a message, stores the message, identifies one or more client applications to receive the message, and sends the message to the identified client applications” … “Typically, the messaging system retains the message in storage only until the messaging system verifies delivery of the message to the identified client applications.”, (Hamburger: ¶21), “the message router 240 determines recipient client applications 205 that are subscribed to a topic indicated by a topic identifier in the message header” … “The message router 240 sends those connection managers 230 routing instructions to send the message to the recipient client applications 205 using the determined connections 217”, (Hamburger: ¶42), “The client application 205 generates a message for the messaging system, and sends the message to a messaging server 120. From the standpoint of the messaging system 120, the message is raw data that is not interpreted by the messaging system itself. This data could represent anything, such as raw text, structured data, a serialized Java object or a structured document in JavaScript Object Notation (JSON) or Extensible Markup Language (XML)”, (Hamburger: ¶30), “In a fanout request mode, a client application sends request messages to all client applications listening on a particular topic and expects to receive response messages from all of them”, (Hamburger: ¶24). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine and providing, by the processor, the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer of Hamburger with the methods and systems of Bishop in view of Bowman resulting in a system allows consumer to request data feeds from multiple distributed resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The messaging system includes independent component programs performing different functions of the messaging system to improve messaging system reliability and flexibility”, (Hamburger: ¶4). Regarding Claim 2, Bishop teaches: a given data feed is curated based on one or more predefined parameters. “The data set annotation may also be used for other types of status information as well as various other purposes. For example, the data set annotation may include security information establishing access levels. The access levels may, for example, be configured to permit only certain individuals, levels of employees, companies, or other entities to access data sets, or to permit access to specific data sets based on the transaction, merchant, issuer, user or the like” … “other access restriction parameters may also be used allowing various entities to access a data set with various permission levels as appropriate”, (Bishop: ¶77). Examiner notes: the feed is curated based on a restriction parameter that hides certain data based on security level. Regarding Claim 3, Bishop teaches: the data feed is a batch data feed. “receive and process mainframe data in real time and/or in a batch configuration depending on the processing requests and programming of data processing appliance 120” … “Given the logic gate architecture of data processing appliance 120, real-time and/or batch processing of mainframe data from mainframe computing resource 110 may be possible with data processing appliance 120 that would otherwise not be possible with traditional legacy mainframe computing systems”, (Bishop: ¶28). Regarding Claim 4, Bishop in view of Hamburger fails to teach: a payload of the input file is one of text, JSON, or Avro. However, Bowman teaches: “the file generation module 445 generates asset files, stream data files, and static rendered files. In an embodiment, the asset files can be denoted by an “assets” property of a configuration file (e.g., a JSON file)”, (Bowman: ¶54). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a payload of the input file is one of text, JSON, or Avro of Bowman with the methods and systems of Bishop in view of Hamburger resulting in a system that can receive data in JSON or Avro. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “decoupling these phases, the streaming static web page generation system provides processing environments that are uniquely optimized for distinct responsibilities of each phase, yielding an overall faster performance, compared with comparable technologies”, (Bowman: ¶13). Regarding Claim 7, Bishop teaches: and storing, by the processor, the client-generated data in the mainframe. “data may originate from and/or be created in distributed system 340 which may then be transmitted to mainframe computing resource 310 through data processing appliance 320 and/or data library 330”, (Bishop: ¶47), “Data processing appliance 320 may also write to a range of tape numbers that are a dedicated storage location for data created and/or processed by data processing appliance 320 and/or distributed system 340”, (Bishop: ¶48), “Method 500 may further comprise writing, by the data processing appliance and contemporaneously with the converting, the processed data to at least one of a data library or the mainframe computing resource (Step 513)”, (Bishop: ¶56). Further regarding Claim 7, Bishop in view of Bowman fails to teach: receiving, by the processor, from the event platform topic, client-generated data read from a given event platform topic of the event platform; However, Hamburger teaches: “The client application 205 generates a message for the messaging system, and sends the message to a messaging server 120” … “This data could represent anything, such as raw text, structured data, a serialized Java object or a structured document in JavaScript Object Notation (JSON) or Extensible Markup Language (XML)”, (Hamburger: ¶30), “The broadcast message indicates a topic to which the client application is publishing the message. The messaging system delivers the broadcast message to client applications subscribed to the topic”, (Hamburger: ¶23), “The message router 240 identifies client applications 205 subscribed to the topic corresponding to the topic identifier included in the message header”, (Hamburger: ¶55), “the message to one or more recipient client applications based on the topic identified by the message header”, (Hamburger: ¶40). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine receiving, by the processor, from the event platform topic, client-generated data read from a given event platform topic of the event platform of Hamburger with the methods and systems of Bishop in view of Bowman resulting in a system that gathers data from resources that its subscribed to. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The messaging system includes independent component programs performing different functions of the messaging system to improve messaging system reliability and flexibility”, (Hamburger: ¶4). Regarding Claim 8, Bishop teaches: A system for facilitating decoupled distribution from a mainframe to one or more distributed platforms, “The disclosed system may comprise a mainframe computing resource, a data library, a data processing appliance, and a distributed system” … “The distributed system may be further configured to process the data based on a workflow from the mainframe computing system", (Bishop: Abstract), “a method of sharing data between a mainframe computing resource and a distributed system is provided”, (Bishop: ¶3), “For example, distributed system 140 may be a real-time data processing system that is configured to receive real-time data from mainframe computing resource 110 via data processing appliance 120. In this regard, distributed system 140 may be able to stream data from mainframe computing resource 110 via data processing appliance 120 removing the typical data transfer and copy step via an FTP protocol”, (Bishop: ¶25). comprising: a processor; a data file connected to the processor; and one or more code sets stored in the data file and executing in the processor, “a host server or other computing systems including a processor for processing digital data; a memory coupled to the processor for storing digital data; an input digitizer coupled to the processor for inputting digital data; an application program stored in the memory and accessible by the processor for directing processing of digital data by the processor;”, (Bishop: ¶64), “Computer programs (also referred to as computer control logic) are stored in main memory and/or secondary memory” … “the computer programs, when executed, enable the processor to perform the features”, (Bishop: ¶70), “These computer program instructions may be loaded onto a special purpose computer…”, (Bishop: ¶83), “a computer usable storage medium having stored therein computer software and/or data”, (Bishop: ¶67), “The control logic (software), when executed by the processor, causes the processor to perform the function”, (Bishop: ¶71). which, when executed configure the system to: curate a data feed from the mainframe; “computing systems including a processor for processing digital data;”, (Bishop: ¶64), “The data processing appliance may be configured to transform, share, protect, stream, and/or otherwise process enterprise data stored on the mainframe system”, (Bishop: ¶22), “data processing appliance 120 may be configured to perform in-line processing including, for example, data transformation” … “, masking (e.g., especially format-preserving), filtering (e.g., based on keywords, errors, sensitive data, and/or the like), and/or the like”, (Bishop: ¶29), “Method 400 may further comprise removing, by data processing appliance 320, mainframe tape information from the data (Step 409). In this regard, data processing appliance 320 may preprocess the data to make the data suitable conversion and/or processing by distributed system 340”, (Bishop: ¶45), “the integration service may normalize the files created by mainframe computing resource 210, on the back up device, so they appear as normal distributed files to distributed system 240”, (Bishop: ¶37). read the data feed; “data processing appliance 220 and/or data library 230 may be detected and/or viewed as a tape backup device. In this regard, data processing appliance 220 and/or data library 230 can be written and read by both mainframe computing resource 210 and distributed system 240”, (Bishop: ¶37), “method 400 may further comprise reading, by data processing appliance 320, the data from the data library 330 (Step 407)”, (Bishop: ¶45). Further regarding Claim 8, Bishop fails to teach: generate an input file for distribution to an event platform topic representing the data feed, However, Bowman teaches: “The input document streams include one or more document messages including one or more documents (e.g., a file or other data object that can be electronically transmitted and stored)…”, (Bowman: ¶38), “In an embodiment, the file generation module 445 generates asset files, stream data files, and static rendered files. In an embodiment, the asset files can be denoted by an “assets” property of a configuration file (e.g., a JSON file). The asset files may be copied verbatim from the artifact to a module for provisioning to the user system” … “the file generation module 445 queues files to be used in the deploy onto a “topic” (e.g., an Apache Kafka topic) which is then read by another microservice or system that is responsible for storing the files in the cloud for serving to the end-user (e.g., the customer)”, (Bowman: ¶54), “the stream data files based on the stream data and are kept up to date with the data as long as the pipeline remains active. The file generation module 445 loads all of the documents for each of the streams the user system website depends on from the stream data structure and queues them onto the topic”, (Bowman: ¶55), “the file generation module 445 looks at the static file template entrypoints defined in the configuration and for each of these, queues an empty document with some additional tagging denoting which content and URL templates to use. In an embodiment, the static rendered files may then be processed like the stream data files”, (Bowman: ¶56). wherein the event platform topic is hosted on an event platform; However, Bowman teaches: “, the messaging system 113 can be configured to interact with a publish-subscribe based messaging system configured to exchange data between processes, application, and servers (e.g., the Apache Kafka® distributed streaming platform)” … “the messaging system 113 is configured to receive document input streams from one or more clusters of servers of the messaging system” … “the messaging system is configured to store streams of document messages organized or grouped according to a parameter (e.g., a topic), where each document message is associated with identifying information (e.g., a key, a value, and a timestamp)” … “A topic can include a category used to organize messages, where each topic has a name that is unique across a cluster” … “where producers write data to topics, and consumers read data from topics”, (Bowman: ¶39). Examiner notes: Apache Kafka is being interpreted as an event platform and the organized streams is being interpreted as event platform topic. write the input file to the event platform topic; However, Bowman teaches: “Messages can be sent to and read from specific topics, where producers write data to topics, and consumers read data from topics”, (Bowman: ¶39), “the file generation module 445 queues files to be used in the deploy onto a “topic” (e.g., an Apache Kafka topic) which is then read by another microservice or system that is responsible for storing the files in the cloud for serving to the end-user (e.g., the customer)”, (Bowman: ¶54), “the rendered files are queued on the topic and tagged with one or more of the activity identifier, instance identifier, and path identifier”, (Bowman: ¶65), “asset files, when written to the topic by file generation module 445, may also have a corresponding event log with an imaginary document key and the URL for each file”, (Bowman: ¶58). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine generate an input file for distribution to an event platform topic representing the data feed, wherein the event platform topic is hosted on an event platform; write the input file to the event platform topic of Bowman with the methods and systems of Bishop resulting in a system that can distribute generated files based on data received from a feed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “decoupling these phases, the streaming static web page generation system provides processing environments that are uniquely optimized for distinct responsibilities of each phase, yielding an overall faster performance, compared with comparable technologies”, (Bowman: ¶13). Further regarding Claim 8, Bishop in view of Bowman fails to teach: and provide the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer. However, Hamburger teaches: “In broadcast mode, a client application sends a message to one or more client applications without expecting a response. The broadcast message indicates a topic to which the client application is publishing the message. The messaging system delivers the broadcast message to client applications subscribed to the topic…”, (Hamburger: ¶23), “the messaging system receives a message, stores the message, identifies one or more client applications to receive the message, and sends the message to the identified client applications” … “Typically, the messaging system retains the message in storage only until the messaging system verifies delivery of the message to the identified client applications.”, (Hamburger: ¶21), “the message router 240 determines recipient client applications 205 that are subscribed to a topic indicated by a topic identifier in the message header” … “The message router 240 sends those connection managers 230 routing instructions to send the message to the recipient client applications 205 using the determined connections 217”, (Hamburger: ¶42), “The client application 205 generates a message for the messaging system, and sends the message to a messaging server 120. From the standpoint of the messaging system 120, the message is raw data that is not interpreted by the messaging system itself. This data could represent anything, such as raw text, structured data, a serialized Java object or a structured document in JavaScript Object Notation (JSON) or Extensible Markup Language (XML)”, (Hamburger: ¶30), “In a fanout request mode, a client application sends request messages to all client applications listening on a particular topic and expects to receive response messages from all of them”, (Hamburger: ¶24). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine and provide the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer of Hamburger with the methods and systems of Bishop in view of Bowman resulting in a system allows consumer to request data feeds from multiple distributed resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The messaging system includes independent component programs performing different functions of the messaging system to improve messaging system reliability and flexibility”, (Hamburger: ¶4). Regarding Claim 9, Bishop teaches: a given data feed is curated based on one or more predefined parameters. “The data set annotation may also be used for other types of status information as well as various other purposes. For example, the data set annotation may include security information establishing access levels. The access levels may, for example, be configured to permit only certain individuals, levels of employees, companies, or other entities to access data sets, or to permit access to specific data sets based on the transaction, merchant, issuer, user or the like” … “other access restriction parameters may also be used allowing various entities to access a data set with various permission levels as appropriate”, (Bishop: ¶77). Examiner notes: the feed is curated based on a restriction parameter that hides certain data based on security level. Regarding Claim 10, Bishop teaches: the data feed is a batch data feed. “receive and process mainframe data in real time and/or in a batch configuration depending on the processing requests and programming of data processing appliance 120” … “Given the logic gate architecture of data processing appliance 120, real-time and/or batch processing of mainframe data from mainframe computing resource 110 may be possible with data processing appliance 120 that would otherwise not be possible with traditional legacy mainframe computing systems”, (Bishop: ¶28). Regarding Claim 11, Bishop in view of Hamburger fails to teach: a payload of the input file is one of text, JSON, or Avro. However, Bowman teaches: “the file generation module 445 generates asset files, stream data files, and static rendered files. In an embodiment, the asset files can be denoted by an “assets” property of a configuration file (e.g., a JSON file)”, (Bowman: ¶54). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a payload of the input file is one of text, JSON, or Avro of Bowman with the methods and systems of Bishop in view of Hamburger resulting in a system that can receive data in JSON or Avro. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “decoupling these phases, the streaming static web page generation system provides processing environments that are uniquely optimized for distinct responsibilities of each phase, yielding an overall faster performance, compared with comparable technologies”, (Bowman: ¶13). Regarding Claim 14, teaches: and store the client-generated data in the mainframe. ““data may originate from and/or be created in distributed system 340 which may then be transmitted to mainframe computing resource 310 through data processing appliance 320 and/or data library 330”, (Bishop: ¶47), “Data processing appliance 320 may also write to a range of tape numbers that are a dedicated storage location for data created and/or processed by data processing appliance 320 and/or distributed system 340”, (Bishop: ¶48), “Method 500 may further comprise writing, by the data processing appliance and contemporaneously with the converting, the processed data to at least one of a data library or the mainframe computing resource (Step 513)”, (Bishop: ¶56). Further regarding Claim 14, Bishop in view of Bowman fails to teach: receive, from the event platform topic, client-generated data read from a given event platform topic of the event platform; However, Hamburger teaches: “The client application 205 generates a message for the messaging system, and sends the message to a messaging server 120” … “This data could represent anything, such as raw text, structured data, a serialized Java object or a structured document in JavaScript Object Notation (JSON) or Extensible Markup Language (XML)”, (Hamburger: ¶30), “The broadcast message indicates a topic to which the client application is publishing the message. The messaging system delivers the broadcast message to client applications subscribed to the topic”, (Hamburger: ¶23), “The message router 240 identifies client applications 205 subscribed to the topic corresponding to the topic identifier included in the message header”, (Hamburger: ¶55), “the message to one or more recipient client applications based on the topic identified by the message header”, (Hamburger: ¶40). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine receive, from the event platform topic, client-generated data read from a given event platform topic of the event platform of Hamburger with the methods and systems of Bishop in view of Bowman resulting in a system that gathers data from resources that its subscribed to. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The messaging system includes independent component programs performing different functions of the messaging system to improve messaging system reliability and flexibility”, (Hamburger: ¶4). Regarding Claim 15, Bishop teaches: A non-transitory, machine-readable medium having instructions for facilitating decoupled distribution from a mainframe to one or more distributed platforms thereon, “The disclosed system may comprise a mainframe computing resource, a data library, a data processing appliance, and a distributed system” … “The distributed system may be further configured to process the data based on a workflow from the mainframe computing system", (Bishop: Abstract), “a method of sharing data between a mainframe computing resource and a distributed system is provided”, (Bishop: ¶3), “For example, distributed system 140 may be a real-time data processing system that is configured to receive real-time data from mainframe computing resource 110 via data processing appliance 120. In this regard, distributed system 140 may be able to stream data from mainframe computing resource 110 via data processing appliance 120 removing the typical data transfer and copy step via an FTP protocol”, (Bishop: ¶25). the instructions when executed by a processor being configured to perform operations comprising, comprising: curating a data feed from the mainframe; “a computer usable storage medium having stored therein computer software and/or data”, (Bishop: ¶67), “The control logic (software), when executed by the processor, causes the processor to perform the function”, (Bishop: ¶71) “computing systems including a processor for processing digital data;”, (Bishop: ¶64), “The data processing appliance may be configured to transform, share, protect, stream, and/or otherwise process enterprise data stored on the mainframe system”, (Bishop: ¶22), “data processing appliance 120 may be configured to perform in-line processing including, for example, data transformation” … “, masking (e.g., especially format-preserving), filtering (e.g., based on keywords, errors, sensitive data, and/or the like), and/or the like”, (Bishop: ¶29), “Method 400 may further comprise removing, by data processing appliance 320, mainframe tape information from the data (Step 409). In this regard, data processing appliance 320 may preprocess the data to make the data suitable conversion and/or processing by distributed system 340”, (Bishop: ¶45), “the integration service may normalize the files created by mainframe computing resource 210, on the back up device, so they appear as normal distributed files to distributed system 240”, (Bishop: ¶37). reading the data feed; “data processing appliance 220 and/or data library 230 may be detected and/or viewed as a tape backup device. In this regard, data processing appliance 220 and/or data library 230 can be written and read by both mainframe computing resource 210 and distributed system 240”, (Bishop: ¶37), “method 400 may further comprise reading, by data processing appliance 320, the data from the data library 330 (Step 407)”, (Bishop: ¶45). Further regarding Claim 15, Bishop fails to teach: generating an input file for distribution to an event platform topic representing the data feed, However, Bowman teaches: “The input document streams include one or more document messages including one or more documents (e.g., a file or other data object that can be electronically transmitted and stored)…”, (Bowman: ¶38), “In an embodiment, the file generation module 445 generates asset files, stream data files, and static rendered files. In an embodiment, the asset files can be denoted by an “assets” property of a configuration file (e.g., a JSON file). The asset files may be copied verbatim from the artifact to a module for provisioning to the user system” … “the file generation module 445 queues files to be used in the deploy onto a “topic” (e.g., an Apache Kafka topic) which is then read by another microservice or system that is responsible for storing the files in the cloud for serving to the end-user (e.g., the customer)”, (Bowman: ¶54), “the stream data files based on the stream data and are kept up to date with the data as long as the pipeline remains active. The file generation module 445 loads all of the documents for each of the streams the user system website depends on from the stream data structure and queues them onto the topic”, (Bowman: ¶55), “the file generation module 445 looks at the static file template entrypoints defined in the configuration and for each of these, queues an empty document with some additional tagging denoting which content and URL templates to use. In an embodiment, the static rendered files may then be processed like the stream data files”, (Bowman: ¶56). wherein the event platform topic is hosted on an event platform; However, Bowman teaches: “, the messaging system 113 can be configured to interact with a publish-subscribe based messaging system configured to exchange data between processes, application, and servers (e.g., the Apache Kafka® distributed streaming platform)” … “the messaging system 113 is configured to receive document input streams from one or more clusters of servers of the messaging system” … “the messaging system is configured to store streams of document messages organized or grouped according to a parameter (e.g., a topic), where each document message is associated with identifying information (e.g., a key, a value, and a timestamp)” … “A topic can include a category used to organize messages, where each topic has a name that is unique across a cluster” … “where producers write data to topics, and consumers read data from topics”, (Bowman: ¶39). Examiner notes: Apache Kafka is being interpreted as an event platform and the organized streams is being interpreted as event platform topic. writing the input file to the event platform topic; However, Bowman teaches: “Messages can be sent to and read from specific topics, where producers write data to topics, and consumers read data from topics”, (Bowman: ¶39), “the file generation module 445 queues files to be used in the deploy onto a “topic” (e.g., an Apache Kafka topic) which is then read by another microservice or system that is responsible for storing the files in the cloud for serving to the end-user (e.g., the customer)”, (Bowman: ¶54), “the rendered files are queued on the topic and tagged with one or more of the activity identifier, instance identifier, and path identifier”, (Bowman: ¶65), “asset files, when written to the topic by file generation module 445, may also have a corresponding event log with an imaginary document key and the URL for each file”, (Bowman: ¶58). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine generating an input file for distribution to an event platform topic representing the data feed, wherein the event platform topic is hosted on an event platform; writing the input file to the event platform topic of Bowman with the methods and systems of Bishop resulting in a system that can distribute generated files based on data received from a feed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “decoupling these phases, the streaming static web page generation system provides processing environments that are uniquely optimized for distinct responsibilities of each phase, yielding an overall faster performance, compared with comparable technologies”, (Bowman: ¶13). Further regarding Claim 8, Bishop in view of Bowman fails to teach: and providing the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer. However, Hamburger teaches: “In broadcast mode, a client application sends a message to one or more client applications without expecting a response. The broadcast message indicates a topic to which the client application is publishing the message. The messaging system delivers the broadcast message to client applications subscribed to the topic…”, (Hamburger: ¶23), “the messaging system receives a message, stores the message, identifies one or more client applications to receive the message, and sends the message to the identified client applications” … “Typically, the messaging system retains the message in storage only until the messaging system verifies delivery of the message to the identified client applications.”, (Hamburger: ¶21), “the message router 240 determines recipient client applications 205 that are subscribed to a topic indicated by a topic identifier in the message header” … “The message router 240 sends those connection managers 230 routing instructions to send the message to the recipient client applications 205 using the determined connections 217”, (Hamburger: ¶42), “The client application 205 generates a message for the messaging system, and sends the message to a messaging server 120. From the standpoint of the messaging system 120, the message is raw data that is not interpreted by the messaging system itself. This data could represent anything, such as raw text, structured data, a serialized Java object or a structured document in JavaScript Object Notation (JSON) or Extensible Markup Language (XML)”, (Hamburger: ¶30), “In a fanout request mode, a client application sends request messages to all client applications listening on a particular topic and expects to receive response messages from all of them”, (Hamburger: ¶24). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine and provide the data feed to the event platform for broadcasting to one or more distributed consumers upon request from a given distributed consumer of Hamburger with the methods and systems of Bishop in view of Bowman resulting in a system allows consumer to request data feeds from multiple distributed resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The messaging system includes independent component programs performing different functions of the messaging system to improve messaging system reliability and flexibility”, (Hamburger: ¶4). Regarding Claim 16, Bishop teaches: a given data feed is curated based on one or more predefined parameters. “The data set annotation may also be used for other types of status information as well as various other purposes. For example, the data set annotation may include security information establishing access levels. The access levels may, for example, be configured to permit only certain individuals, levels of employees, companies, or other entities to access data sets, or to permit access to specific data sets based on the transaction, merchant, issuer, user or the like” … “other access restriction parameters may also be used allowing various entities to access a data set with various permission levels as appropriate”, (Bishop: ¶77). Examiner notes: the feed is curated based on a restriction parameter that hides certain data based on security level. Regarding Claim 18, Bishop in view of Hamburger fails to teach: a payload of the input file is one of text, JSON, or Avro. However, Bowman teaches: “the file generation module 445 generates asset files, stream data files, and static rendered files. In an embodiment, the asset files can be denoted by an “assets” property of a configuration file (e.g., a JSON file)”, (Bowman: ¶54). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a payload of the input file is one of text, JSON, or Avro of Bowman with the methods and systems of Bishop in view of Hamburger resulting in a system that can receive data in JSON or Avro. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “decoupling these phases, the streaming static web page generation system provides processing environments that are uniquely optimized for distinct responsibilities of each phase, yielding an overall faster performance, compared with comparable technologies”, (Bowman: ¶13). Regarding Claim 20, Bishop teaches: and Storing the client-generated data in the mainframe. “data may originate from and/or be created in distributed system 340 which may then be transmitted to mainframe computing resource 310 through data processing appliance 320 and/or data library 330”, (Bishop: ¶47), “Data processing appliance 320 may also write to a range of tape numbers that are a dedicated storage location for data created and/or processed by data processing appliance 320 and/or distributed system 340”, (Bishop: ¶48), “Method 500 may further comprise writing, by the data processing appliance and contemporaneously with the converting, the processed data to at least one of a data library or the mainframe computing resource (Step 513)”, (Bishop: ¶56). Further regarding Claim 20, Bishop in view of Bowman fails to teach: Receiving from the event platform topic, client-generated data read from a given event platform topic of the event platform; However, Hamburger teaches: “The client application 205 generates a message for the messaging system, and sends the message to a messaging server 120” … “This data could represent anything, such as raw text, structured data, a serialized Java object or a structured document in JavaScript Object Notation (JSON) or Extensible Markup Language (XML)”, (Hamburger: ¶30), “The broadcast message indicates a topic to which the client application is publishing the message. The messaging system delivers the broadcast message to client applications subscribed to the topic”, (Hamburger: ¶23), “The message router 240 identifies client applications 205 subscribed to the topic corresponding to the topic identifier included in the message header”, (Hamburger: ¶55), “the message to one or more recipient client applications based on the topic identified by the message header”, (Hamburger: ¶40). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine receiving from the event platform topic, client-generated data read from a given event platform topic of the event platform of Hamburger with the methods and systems of Bishop in view of Bowman resulting in a system that gathers data from resources that its subscribed to. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The messaging system includes independent component programs performing different functions of the messaging system to improve messaging system reliability and flexibility”, (Hamburger: ¶4). Claims 5-6, 12-13, 17 and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bishop in view of Bowman and Hamburger, in further view of Botticelli et al. ( US 20160050269 A1 ) (hereinafter Botticelli). Regarding Claim 5, Bishop in view of Bowman and Hamburger fails to teach: the request is triggered by a subscription to the event platform topic. However, Botticelli teaches: “A subscription request is received from the client corresponding to a selected topic of the set of publication topics” … “Second sequential data is sent to the client responsive to the subscription request, the second sequential data being based on the first sequential data”, (Botticelli: ¶2), “A client publish/subscribe component 206 publishes topics available to the client 128, and allows the client 128 to subscribe to topics and receive data included with the topics, e.g., data streams, sequentially transmitted messages, etc.”, (Botticelli: ¶28), “Other entities can subscribe to these new topics and receive data feeds in response”, (Botticelli: ¶35). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the request is triggered by a subscription to the event platform topic of Botticelli with the methods and systems of Bishop in view of Bowman and Hamburger resulting in a system where subscriptions act as requests for data. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the publish/subscribe component 124, either automatically or with minimal configuration, can handle new types of sensor data (or new transformations and combinations of existing sensor data) by adding a new topic” … “The client 128 can discover and use these newly published data sources with minimal end-to-end configuration effort”, (Botticelli: ¶24). Regarding Claim 6, Bishop in view of Bowman and Hamburger fails to teach: the data feed is a repeating data feed. However, Botticelli teaches: “a “stream” or “feed” of data refers to a sequence of data messages on a related subject. As such, the stream/feed may not require a continuous connection or other continuity associated” … “as long as a received message can be correlated associated with other messages received at a different time, these messages may be collectively referred to as a stream or feed”, (Botticelli: ¶15), “the refresh rate of data from the mobile gateway 302 is set here as once every 15 seconds, whereas option 314 requests a refresh rate of 1 minute”, (Botticelli: ¶38), “the mobile gateway sends out location updates 318-322 until one minute has passed, and then the update 322 is copied as an update message 323 sent to the client 306” … “the cloud gateway 304 may be configured to increase a rate of updates in some cases”, (Botticelli: ¶39), “send second sequential data to the client responsive to the subscription request”, (Botticelli: Claim 1), “the options comprise a refresh rate of the second sequential data.”, (Botticelli: Claim 4). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the data feed is a repeating data feed of Botticelli with the methods and systems of Bishop in view of Bowman and Hamburger resulting in a system the receives data in intervals as well as continuously. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the publish/subscribe component 124, either automatically or with minimal configuration, can handle new types of sensor data (or new transformations and combinations of existing sensor data) by adding a new topic” … “The client 128 can discover and use these newly published data sources with minimal end-to-end configuration effort”, (Botticelli: ¶24). Regarding Claim 12, Bishop in view of Bowman and Hamburger fails to teach: the request is triggered by a subscription to the event platform topic. However, Botticelli teaches: “A subscription request is received from the client corresponding to a selected topic of the set of publication topics” … “Second sequential data is sent to the client responsive to the subscription request, the second sequential data being based on the first sequential data”, (Botticelli: ¶2), “A client publish/subscribe component 206 publishes topics available to the client 128, and allows the client 128 to subscribe to topics and receive data included with the topics, e.g., data streams, sequentially transmitted messages, etc.”, (Botticelli: ¶28), “Other entities can subscribe to these new topics and receive data feeds in response”, (Botticelli: ¶35). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the request is triggered by a subscription to the event platform topic of Botticelli with the methods and systems of Bishop in view of Bowman and Hamburger resulting in a system where subscriptions act as requests for data. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the publish/subscribe component 124, either automatically or with minimal configuration, can handle new types of sensor data (or new transformations and combinations of existing sensor data) by adding a new topic” … “The client 128 can discover and use these newly published data sources with minimal end-to-end configuration effort”, (Botticelli: ¶24). Regarding Claim 6, Bishop in view of Bowman and Hamburger fails to teach: the data feed is a repeating data feed. However, Botticelli teaches: “a “stream” or “feed” of data refers to a sequence of data messages on a related subject. As such, the stream/feed may not require a continuous connection or other continuity associated” … “as long as a received message can be correlated associated with other messages received at a different time, these messages may be collectively referred to as a stream or feed”, (Botticelli: ¶15), “the refresh rate of data from the mobile gateway 302 is set here as once every 15 seconds, whereas option 314 requests a refresh rate of 1 minute”, (Botticelli: ¶38), “the mobile gateway sends out location updates 318-322 until one minute has passed, and then the update 322 is copied as an update message 323 sent to the client 306” … “the cloud gateway 304 may be configured to increase a rate of updates in some cases”, (Botticelli: ¶39), “send second sequential data to the client responsive to the subscription request”, (Botticelli: Claim 1), “the options comprise a refresh rate of the second sequential data.”, (Botticelli: Claim 4). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the data feed is a repeating data feed of Botticelli with the methods and systems of Bishop in view of Bowman and Hamburger resulting in a system the receives data in intervals as well as continuously. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the publish/subscribe component 124, either automatically or with minimal configuration, can handle new types of sensor data (or new transformations and combinations of existing sensor data) by adding a new topic” … “The client 128 can discover and use these newly published data sources with minimal end-to-end configuration effort”, (Botticelli: ¶24). Regarding Claim 17, Bishop teaches: the data feed is at least one of a batch data feed or a repeating data feed. ““receive and process mainframe data in real time and/or in a batch configuration depending on the processing requests and programming of data processing appliance 120” … “Given the logic gate architecture of data processing appliance 120, real-time and/or batch processing of mainframe data from mainframe computing resource 110 may be possible with data processing appliance 120 that would otherwise not be possible with traditional legacy mainframe computing systems”, (Bishop: ¶28). Further regarding Claim 17, Bishop in view of Bowman and Hamburger fails to teach: the data feed is at least one of a batch data feed or a repeating data feed. However, Botticelli teaches: “a “stream” or “feed” of data refers to a sequence of data messages on a related subject. As such, the stream/feed may not require a continuous connection or other continuity associated” … “as long as a received message can be correlated associated with other messages received at a different time, these messages may be collectively referred to as a stream or feed”, (Botticelli: ¶15), “the refresh rate of data from the mobile gateway 302 is set here as once every 15 seconds, whereas option 314 requests a refresh rate of 1 minute”, (Botticelli: ¶38), “the mobile gateway sends out location updates 318-322 until one minute has passed, and then the update 322 is copied as an update message 323 sent to the client 306” … “the cloud gateway 304 may be configured to increase a rate of updates in some cases”, (Botticelli: ¶39), “send second sequential data to the client responsive to the subscription request”, (Botticelli: Claim 1), “the options comprise a refresh rate of the second sequential data.”, (Botticelli: Claim 4). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a repeating data feed of Botticelli with the methods and systems of Bishop in view of Bowman and Hamburger resulting in a system the receives data in intervals as well as continuously. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the publish/subscribe component 124, either automatically or with minimal configuration, can handle new types of sensor data (or new transformations and combinations of existing sensor data) by adding a new topic” … “The client 128 can discover and use these newly published data sources with minimal end-to-end configuration effort”, (Botticelli: ¶24). Regarding Claim 19, Bishop in view of Bowman and Hamburger fails to teach: the request is triggered by a subscription to the event platform topic. However, Botticelli teaches: “A subscription request is received from the client corresponding to a selected topic of the set of publication topics” … “Second sequential data is sent to the client responsive to the subscription request, the second sequential data being based on the first sequential data”, (Botticelli: ¶2), “A client publish/subscribe component 206 publishes topics available to the client 128, and allows the client 128 to subscribe to topics and receive data included with the topics, e.g., data streams, sequentially transmitted messages, etc.”, (Botticelli: ¶28), “Other entities can subscribe to these new topics and receive data feeds in response”, (Botticelli: ¶35). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the request is triggered by a subscription to the event platform topic of Botticelli with the methods and systems of Bishop in view of Bowman and Hamburger resulting in a system where subscriptions act as requests for data. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the publish/subscribe component 124, either automatically or with minimal configuration, can handle new types of sensor data (or new transformations and combinations of existing sensor data) by adding a new topic” … “The client 128 can discover and use these newly published data sources with minimal end-to-end configuration effort”, (Botticelli: ¶24). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is (571)272-8705. The examiner can normally be reached Mon - Fri 7:30am-5pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /S.A./Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Read full office action

Prosecution Timeline

Apr 01, 2024
Application Filed
Aug 13, 2026
Non-Final Rejection mailed — §101, §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month