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 The following NON-FINAL Office action is in response to application 18521518 filed 11/28/2023. Status of Claims Claims 1-20 are currently pending and have been rejected as follows. Priority Examiner noted Applicants claiming Priority from Provisional 63583972 filed 09/20/2023 . IDS The information disclosure statement filed on 07/22/2024 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 2,6,10,14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Claims 2,10 are dependent and each recite, among others: “ the one or more consumer client s comprise another consumer client ” [bolded emphasis added], rendering each of said claims vague and indefinite because it is unclear how, one [ single ] consumer client, as broadly covered by expression “ the one or more consumer clients”, would be capable to “ comprise ” another consumer client ” as recited in each of said dependent Claims 2,10. Claims 2,10 are recommended to be amended to each recite , as an example only: wherein the one or more consumer clients comprise another consumer client that comprises a data repository interface configured to - storing store the one or more event message payloads from the one or more input topic streams and the one or more transformed event message payloads from the one or more output topic streams to respective first and second staging areas associated with the input topic and the output topic in a data repository . Claims 6,14 are dependent and each recite, among others: - determine the one or more respective file locations for the outside ones of the one or more event message payloads… rendering said claims vague and indefinite because there is insufficient antecedent basis for “ the outside ones of the one or more event message payloads” Claims 6,14 are recommended to be amended to recite, among others by example only: - determine the one or more respective file locations for the outside outsized ones of the one or more event message payloads… Clarifications and/or corrections are required. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 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 C ertain M ethods of O rganizing of H uman A ctivities . 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 “ event message payloads associated with one or more messages between one or more application programming interfaces or integrator elements and one or more downstream applications” ] , selecting an ad [akin here to “ receiving ”… “ using a consumer client of the one or more consumer clients, the one or more event message payloads from the 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 one or more transformed event message payloads as an output topic to the streaming server” ] 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] “ one or more event message payloads” [is] “ associated with one or more messages between one or more application programming interfaces or integrator elements and 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, 4 th 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. 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) c ited 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. Specifically, h ere, 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 ” “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 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 one or more event message payloads as an input topic to a streaming server that is configured to provide, to one or more consumer clients, (1) one or more input topic streams that comprises the one or more event message payloads and (2) one or more output topic streams ”; “ receiving ”, “ using a consumer client ” [as another , second business entity] “ of the one or more consumer clients, the one or more event message payloads from the one or more input topic streams ”; “ generating ” “ one or more transformed event message payloads by applying one or more data transformation rules ” [akin to Fairwarning ’s ineligible compilation] “ to the one or more event message payloads received from the one or more input topic streams ”; and “ providing ” [akin to FairWarning’ s ineligible announcing] “ using the producer client ” [or the first business entity] , “ the one or more transformed” [or compiled] “ event message payloads as an output topic ” . Dependent Claims 2-8, 10-16, 18-20 further narrow the abstract concepts of independent Claims 1,9,17, with respect to consideration of abstract evaluation regarding “ outsize ” benchmarked over a “ size limit ” and associated “ references to the outsize ” “ messages ”, “ locations ” etc. This finding is important since MPEP 2106.04 I ¶3 states that narrow laws that with limited applications are still ineligible. Thus, Examiner reasons that , given the 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, s uch 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. 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 sufficient option(s) for evidence without having to rely on the well understood routine and conventional test of MPEP 2106.05(d). 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 without having to rely on the well understood routine and conventional test of MPEP 2106.05(d). Yet, 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: F ig .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 ¶ [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. All of this preponderance of legal and/or factual evidence demonstrate that the additional computer-based elements fail to provide anything significantly more. Thus 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 Claim s 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 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: Schuhart et al, US 20190013992 A1 Claims 1,9,17 Schuhart teaches “ A computer-implemented method comprising:/A computing system comprising memory and one or more processors communicatively coupled to the memory, the one or more processors configured to: / One or more non-transitory computer-readable storage media including instructions that, when executed by one or more processors” ( Schuhart Fig.4, ¶ [0010], [0043]-[0048],[0016] provide stream-based protocol-agnostic messaging. Multiple messaging protocols are supported by the disclosed messaging system so software developers can easily integrate broker-based messaging. An advantage of the disclosed messaging system is that it allows for switching between different brokers and protocols via configuration changes, rather than changes to application code) , “ cause the one or more processors to ” : - “receiving, by one or more processors, one or more event message payloads associated with one or more messages between one or more application programming interfaces or integrator elements and one or more downstream applications”; (Schuhart ¶ [0008] 1 st sentence: Disclosed embodiments provide stream-based application programming interface API, which provides flow-control and needs only basic data, e.g. payload and acknowledge callbacks, via the API. ¶ [0010] 2 nd -3 rd , 7 th sentences: configure the memory to have streams connecting generic messaging client to send messages to and/or receive messages from one or more protocol-specific messaging clients. The streams are formed by providing configuration data comprising destination definitions. In code for the generic messaging client, at least one stream object is provided specifying destination definitions and stream definitions. Schuhart ¶ [0017] Fig.1 depicts system 100 in which general messaging component 110 interfaces with a number of protocol-specific messaging components (120,130,140), i.e., messaging clients. For each supported protocol/broker, a specific component is implemented, such as, for example, MQTT [Message Queue Telemetry Transport] v3.1.1, AMQP [Advanced Message Queuing Protocol] v0.9.1, and AMQP v1.0.0. The interface used by the general component 110 (i.e., the “msg” component) allows for a messaging client (120, 130, 140) to be created via changes in configuration. As discussed in further detail below, the messaging clients (120, 130, 140) can create streams 150 for input and output. Schuhart ¶ [0018] By virtue of this configuration, an application written for a cloud environment, or other type of node-based environment, could receive messages from a broker using a particular protocol and output the messages using a different protocol. For example, the node could receive messages from an MQTT-based broker which have been delivered to the MQTT [Message Queue Telemetry Transport] broker from a number of devices. The application may consume, validate, and transform the messages in various ways and then output the messages to a queue using, e.g., a version of AMQP. This is but one of many possible configurations in which an application can make use of messaging clients having different messaging protocols. An application may receive messages, transform data, produce messages, and/or perform a database update, etc., using a combination of protocols. Each of the messaging clients provides an application program interface (API) which conforms to a particular protocol. The messaging clients communicate with a common, general messaging client which provides a common basis for stream handling between itself and the protocol-specific messaging clients. Schuhart ¶ [0020] 1 st -4 th sentences: generic messaging client 210 (msg) is a stream-based client, which owns, i.e., provides or contains, protocol-specific clients, e.g., MQTT [Message Queue Telemetry Transport] v3.1.1 protocol client 220 and an AMQP [Advanced Message Queuing Protocol] v0.9.1 client 230. The protocol-specific clients (220, 230) provide all of the protocol-specific settings and in-stream and out-stream definitions. The common, generic client 210 is a steam-based client which is exposing the streams 250 defined by the protocol-specific clients (220, 230) via an application program interface (API). This provides a simple and unified API to the application regardless of the specific protocols being employed. Schuhart ¶ [0021] messaging client 210 (msg) manage n specific clients, each having specific input and/or output streams. A client is instantiated by passing a configuration. The configuration may define n destinations (where n is an integer), each of which corresponds to a particular broker destination (e.g. host, port, broker or protocol type and a unique name). Each destination may list p input and q output streams (where p and q are integers). While the input streams correspond to messaging subscriptions at parent broker destination, the output streams correspond to publish/produce messaging targets. Each stream provides a unique name-other settings are protocol and broker-specific and may differ. Thus, for each destination, multiple inbound as well as outbound streams may be defined, providing detailed protocol-specific settings and locally unique name to identify each stream. An application may use the streams to consume or produce independently from one another or may also use stream-like processor objects that pipe a converted input stream to an output stream, as discussed in further detail below). Schuhart ¶ [0022] In disclosed embodiments, a configuration data structure, such as, a JSON string tree can be used to create protocol-specific message clients and their connections, thereby simplifying unified access and allow an application to start using the defined streams without regard to protocol. In this example, the configuration defines 2 destinations: 1 st destination is based on the AMQP [Advanced Message Queuing] protocol; and 2 nd destination is based on MQTT [Message Queue Telemetry Transport]. The AMQP connection identifies a particular host (e.g. “host”: “<host1>”) and port (e.g., “port”: 5672). Configuration elements are provided to handle user credentials (e.g. “mechanism”: “PLAIN”, “user”: “guest”, “password”: “guest”) and a logon message for Simple Authentication and Security Layer (SASL), which is a framework for authentication and data security in Internet Protocol networks. The AMQP configuration defines a vhost, i.e., a virtual host, which is used to log on to a message broker. The AMQP configuration also provides a definition for an input stream (“in1”), which is based on a particular channel (“channel”: 1), routing key (“routingKey”: “topic.test0”), and exchange (“exchange”: “amq.topic”). An application can access this input stream at runtime using the name (“in1”) of the stream. Schuhart ¶ [0024] The 2 nd destination shown above is based on MQTT [Message Queue Telemetry Transport], which has settings different from AMQP, although some parameters are similar. For example, the MQTT definition includes client ID and password. Some settings are set to default values and may not be necessary for a typical use case. The 2 nd destination, which becomes a connection at runtime, has an input stream (“in2”) and an output stream (“out2”). Schuhart ¶ [0034] 2 nd sentence: a client is created which pipes an input stream (“MyInpA”) into the converter and pipes the output to an output stream (“MyOutA”). - “providing, by the one or more processors and using a producer client, the one or more event message payloads as an input topic to a streaming server that is configured to provide, to one or more consumer clients, (1) one or more input topic streams that comprises the one or more event message payloads and (2) one or more output topic streams”; (Schuhart ¶ [0003] 4 th -5 th , 9 th sentences: In a topic-based system, messages are published to “topics,” which are named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive same messages. Some systems support a hybrid of the two, i.e., publishers post messages to topics while subscribers register content-based subscriptions to one or more topics Schuhart ¶ [0022] last 2 sentences: The AMQP [Advanced Message Queuing Protocol] configuration also provides a definition for an input stream (“in1”), which is based on a particular channel (channel: 1), routing key (routingKey:topic.test0), and exchange (exchange: amq.topic). An application can access this input stream at runtime using the name (“in1”) of the stream. Schuhart ¶ [0025] 3 rd -4 th sentences: a message broker may act as central point of exchange, to forward message from message producers (310) to message consumers (305). A number of applications may be interacting with the message brokers, each application acting as a message consumer, message producer, or both. Schuhart mid-¶ [0028] application 305 with a generic messaging client may be a consumer of messages sent by message broker 315. The messages received from broker 315 as a protocol -specific messaging stream which is exposed to application 305 via API as a generic messaging input stream 335. The messaging input stream is produced by arrangement of generic messaging client (210) and one or more protocol-specific messaging clients (220, 230) (Fig.2). An application 310 with a generic messaging client may also be a producer of messages sent to a message broker 320. The messages are output by application 310 via API as a generic messaging output stream 340, sent to the broker 320 as a protocol-specific messaging stream. The messaging output stream 340 is transformed into the protocol-specific messaging stream by an arrangement of a generic messaging client and one or more protocol-specific messaging clients, in Fig.2). Schuhart ¶ [0034] 2 nd -5 th sentences: a client is created which pipes input stream (MyInpA) into the converter and pipes the output to an output stream (MyOutA). Conventional approaches to messaging require flow control to adjust processing speeds to the speed of the network. In the disclosed embodiments, messages are streamed, which means that the processing speed depends on network speed and the message processing rate of the message broker(s). Thus, the disclosed embodiments provide flow control without requiring application code developed specifically for that purpose. The following is an example, using Node.js, of a stream conversion: Schuhart ¶ [0036] The following example is code which could be used in a generic messaging client of an application to produce data streamed to a protocol-specific client. In this example, the protocol is MQTT and the data is output via an output stream named MyOutA. - “receiving, by the one or more processors and using a consumer client of the one or more consumer clients, the one or more event message payloads from the one or more input topic streams”; (Schuhart ¶ [0011] 5 th -6 th sentences: providing, in the code for the messaging client, a stream converter which pipes a converted input stream to an output stream. The stream converter may perform a mathematical operation on values in the input stream to produce corresponding converted values in the output stream. ¶ [0025] 3 rd -4 th sentences: a message broker act as central point of exchange, to forward message from message producers (310) to message consumers (305). A number of applications may be interacting with the message brokers, each application acting as a message consumer, message producer, or both. Schuhart mid-¶ [0028]: an application 305 with a messaging client may be a consumer of messages sent by a message broker 315. The messages are received from broker 315 as protocol-specific messaging stream exposed to application 305 via API as messaging input stream 335. The messaging input stream is produced by an arrangement of generic messaging client (210) and protocol-specific messaging clients (220, 230) (Fig.2). An application 310 with a generic messaging client may also be a producer of messages sent to a message broker 320). - “generating, by the one or more processors, one or more transformed event message payloads by applying one or more data transformation rules to the one or more event message payloads received from the one or more input topic streams” (Schuhart ¶ [0018] 3 rd sentence: transform the messages in various ways and then output the messages to a queue using, e.g., a version of AMQP [Advanced Message Queuing Protocol] Schuhart ¶ [0019] 3 rd sentence, ¶ [0043] 2 nd sentence: communication device 420 facilitate communication with external devices, i.e network, server, or message broker. For example, Schuhart ¶ [0028] last 2 sentences: The messages are output by application 310 via an API as a generic messaging output stream 340, sent to broker 320 as a protocol-specific messaging stream. The messaging output stream 340 is transformed into the protocol-specific messaging stream by an arrangement of a generic messaging client and protocol-specific messaging clients, depicted in Fig.2. ¶ [0029] 1 st sentence: a transform stream 345 perform a particular transformation of message stream received from 1 st message 325 broker and send transformed stream to 2 nd message broker 330) “ and” - “providing, by the one or more processors and using the producer client, the one or more transformed event message payloads as an output topic to the streaming server” . (Schuhart ¶ [0043] 2 nd sentence: communication device 420 facilitate communication with external devices, i.e. network, server, or message broker. For example, at ¶ [0029] 2 nd sentence: transform stream conversion node receives and transmits the transformed streams as generic messaging input streams 350 and generic messaging output streams 355, as described above) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- R ejections 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. Claim s 2,10 are rejected under 35 U.S.C. 103 as being unpatentable over : Schuhart as applied to claim s 1,9 , in view of Slik; David US 20150331621 A1 hereinafter Silk . As per, Claims 2,10 Schuhart teaches all the limitations in claims 1,9 above. Schuhart does not recite: “ wherein the one or more consumer clients comprise another consumer client that comprises a data repository interface configured to” - “store the one or more event message payloads from the one or more input topic streams and the one or more transformed event message payloads from the one or more output topic streams to respective first and second staging areas associated with the input topic and the output topic in a data repository” as explicitly claimed. Silk however in analogous data transmission across multiple devices teaches/suggest s: “ wherein the one or more consumer clients comprise another consumer client that comprises a data repository interface configured to” - “store the one or more event message payloads from the one or more input topic streams and the one or more transformed event message payloads from the one or more output topic streams to respective first and second staging areas associated with the input topic and the output topic in a data repository” (Silk ¶ [0053] 1 st -2 nd 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] 1 st 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] 2 nd 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] 1 st 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 Schuhart ’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] 3 rd 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 Schuhart 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: Schuhart as applied to claims 1,9,17 in view of Yasuhiro Kitamura US 20190286589 A1 hereinafter Kitamura . As per, Claims 3,11 ,18 Schuhart teaches all the limitations in claims 1,9 ,17 above. Schuhart does not explicitly recite: “ further comprising” - “identifying one or more potential data transmission failures associated with outsize ones of the one or more event message payloads or the one or more transformed event message payloads 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 outsize ones of the one or more event message payloads or the one or more transformed event message payloads that exceed a data size limit” (Kitamura ¶ [0005] to transfer payloads with long [or oversize] 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 oversize] 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] 2 nd -4 th 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] 2 nd -3 rd 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 Schuhart ’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 Schuhart 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 Schuhart / Kitamura teaches all the limitations in claims 3,11 ,18 . Schuhart does not explicitly recite: “performing exception handling of the one or more potential data transmission failures by” : - “ storing the outsize ones of the one or more event message payloads or the one or more transformed event message payloads to a data storage file system ”; - “ providing one or more payload reference event messages associated with the outsize ones of the one or more event message payloads or the one or more transformed event message payloads to the input topic or the output topic, respectively, wherein the one or more payload reference event messages comprise one or more file references to the outsize ones of the one or more event message payloads or the one or more transformed event message payloads 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 outsize ones of the one or more event message payloads or the one or more transformed event message payloads 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 oversize] amount of packets. Storing a large [or oversized] 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 the outsize ones of the one or more event message payloads or the one or more transformed event message payloads to the input topic or the output topic, respectively, wherein the one or more payload reference event messages comprise one or more file references to the outsize ones of the one or more event message payloads or the one or more transformed event message payloads in the data storage file system ” (Kitamura ¶ [0005] 1 st 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] 1 st sentence: When data having a long message length is transferred by DMA, existing data transfer by DMA is desirable. ¶ [0051] 3 rd sentence… the size of the payload is greater than 8 bytes. ¶ [0053] 3 rd -6 th 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 1 st 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 Schuhart / Kitamura are above and reincorporated. Claims 5,13 ,20 Schuhart / Kitamura teaches all the limitations in claims 4,12, 19 above. Schuhart does not recite “the one or more file references are indicative of one or more respective file locations for the outsize ones of the one or more event message payloads or the one or more transformed event message payloads from the data storage file system” 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 outsize ones of the one or more event message payloads or the one or more transformed event message payloads from the data storage file system” (Kitamura ¶ [0005] 1 st sentence:…to transfer payloads with long [or oversize] message lengths…a receive buffer for storing large [or oversized] amount of payloads is… implemented… Kitamura ¶ [0006] 2 nd - 3 rd sentences:… DMA controller uses a high-density receive buffer, such as SRAM, to store a large [or oversized] amount of packets. Storing a large [or oversized] 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 oversized] 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 1 st 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 oversized] 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 great