DETAILED ACTION
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119 as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 17/095,783 (“783”), fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. For example, looking to claims 1 and 11, 783 fails to disclose the determination of root causes and performance of operations to attain a predefined level of resiliency based on the loss of connectivity and the root causes.
Double Patenting
A telephone call was made to James Cameron on 12/18/2025 to request a terminal disclaimer be filed, but Applicant indicated that a written double patenting rejection was requested.
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 4, 8, 11, 14 and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 11,632,333 (“333”) in view of Ravichandran, et al. (US Pre Gant Publication No. 2020/0186411).
Claim 1 of Present Application
Claims 1, 2, 5, 6, 10 and 11 of 11,632,333 (all citations to claim 1 unless otherwise noted)
data obtaining module configured to obtain a flow configuration file of a predefined format associated with one or more runtime nodes of a distributed data flow model from a controller, wherein the flow configuration file comprises a JavaScript Object Notation (JSON) file format comprising data flow configuration information,
create a flow configuration file of a predefined format for the at least one runtime upon registration of the at least one runtime
the predefined format of the flow configuration file comprises a JavaScript object notation file format comprising the data flow configuration information (claim 5)
wherein the data flow configuration information comprises flow design of the one or more runtime nodes, one or more node configurations, one or more interconnecting wires, and one or more runtime node configurations
wherein the distributed data flow deployment subsystem is configured to deploy one or more nodes and one or more interconnecting wires of the at least one runtime based on one or more identified portions of the distributed data flow framework from the flow configuration file created
the data flow configuration information comprises at least one of a flow design of the one or more nodes, one or more node configurations, one or more interconnecting wires, one or more runtime configurations or a combination thereof (claim 6)
wherein the one or more runtime nodes are one or more compute nodes equipped with a predetermined functionality for execution of a distributed data flow
wherein the at least one runtime comprises one or more compute nodes equipped with a predetermined functionality for execution of distributed data flow (claim 2)
bridge wire identification module configured to identify one or more socket roles and a unique identification number corresponding to each of one or more flow neighbors based on the obtained flow configuration file; a connection establishing module configured to: establish a Transmission Control Protocol (TCP) connection of the one or more runtime nodes with each of the one or more flow neighbors based on the identified one or more socket roles and the identified unique identification number,
a bridge wire identification subsystem operatively coupled to the flow neighbor identification subsystem, wherein the bridge wire identification subsystem is configured to: identify one or more socket roles and a unique identification number corresponding to each of the one or more flow neighbors from the flow configuration file upon determination of the publisher and the subscriber service information; enable the at least one runtime to establish a transmission control protocol connection with each of the one or more flow neighbors based on an identification of corresponding one or more socket roles and the unique identification number
(note bridge wire identification subsystem can map the bridge wire identification module, connection establishing module is the inherent transmitter necessary to establish the TCP connection)
wherein the TCP connection enables TCP keepalives for preventing deactivation of the established TCP connection, and
the transmission control protocol connection is configured to enable transmission control protocol keepalives for preventing deactivation of the established transmission control protocol connection (claim 10)
wherein a single TCP connection is established between each pair of flow neighbors from each of the one or more runtime nodes;
enable the at least one runtime to establish a transmission control protocol connection with each of the one or more flow neighbors based on an identification of corresponding one or more socket roles and the unique identification number
(Noting that only one/a single connection is established between the neighbors)
establish a publisher-subscriber relationship of the one or more runtime nodes with each of the one or more flow neighbors for forwarding flow messages based on the established TCP connection
enable the at least one runtime to establish a publisher-subscriber relationship for forwarding flow messages based on the transmission control protocol connection established between the at least one run-time and the one or more flow neighbors;
wherein the publisher-subscriber relationship comprises a relationship between a peer-to-peer publisher on a message originating runtime node and a peer-to-peer subscriber on a message receiving runtime node
the publisher-subscriber relationship comprises a relationship between a peer to peer publisher on a message originating runtime and a subscriber on a message receiving runtime (claim 11)
implement one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors for implementation of the distributed data flow model based on the established publisher-subscriber relationship
implement one or more bridge wires with the at least one runtime and the one or more flow neighbors for implementation of the distributed data flow-based framework based on the publisher-subscriber relationship established
wherein the one or more nodes comprise one or more compute nodes
the at least one runtime comprises one or more compute nodes equipped with a predetermined functionality for execution of distributed data flow (claim 2)
333 fails to explicitly disclose that all the elements of dependent claims 1, 2, 5, 6, 10 and 11, cited above, are utilized at the same time in a single embodiment, as each of the dependent claims is separately claimed. However, it would have been obvious to a person of ordinary skill in the art at the time of the invention to use the elements of claims 1, 2, 5, 6, 10 and 11 together, such that the system of claim 1 of 333 has compute nodes with predefined functionally (claim 2), the predetermined file type is JSON (claim 5), the flow configuration includes node configurations and interconnecting wires (claim 6), the predefined format of claim 1 of 333 is JSON with one or more compute nodes (claim 5), the TCP protocol uses keepalives (claim 10) and the publisher subscriber relationship is peer-to-peer (claim 11). The motive to combine is to allow easy deployment with predefined functions for node interchangeability and re-use (claim 2), use the common format of JSON for compatibility and re-use (claim 5), include configuration and configuration information in the flow configuration file to allow direct configuration of the nodes and wires for improved portability and exact specification of connections (claim 6), use TCP keepalives to reduce overhead and delay associated with re-established the TCP connections if they timeout (claim 10) and to allow peer-to-peer communication without a central routing for efficiency (claim 11).
333 fails to disclose a data failure detection module configured to detect a loss of connectivity of one or more networks, and an operational failure of one or more nodes and the one or more runtime nodes deployed in the distributed dataflow model based on implementation of the one or more bridge wires, a cause determination module configured to determine one or more root causes of the detected loss of connectivity and an operation performing module configured to perform one or more operations to attain a predefined level of resiliency of the distributed data flow model over the one or more bridge wires based on the detected loss of connectivity and the determined one or more root causes or a computing system for implementing and managing a distributed data flow model, the computing system comprising one or more hardware processors and a memory coupled to the one or more hardware processors, wherein the memory comprises a plurality of modules in the form of programmable instructions executable by the one or more hardware processors to implement the recited modules. In the same field of endeavor, Ravichandran discloses data failure detection module configured to detect a loss of connectivity of one or more networks, and an operational failure of one or more nodes and the one or more runtime nodes deployed in the distributed dataflow model based on implementation of the one or more bridge wires, a cause determination module configured to determine one or more root causes of the detected loss of connectivity and an operation performing module configured to perform one or more operations to attain a predefined level of resiliency of the distributed data flow model over the one or more bridge wires based on the detected loss of connectivity and the determined one or more root causes and a computing system for implementing and managing a distributed data flow model, the computing system comprising: one or more hardware processors; and a memory coupled to the one or more hardware processors, wherein the memory comprises a plurality of modules in the form of programmable instructions executable by the one or more hardware processors to implement the recited modules (Ravichandran discloses a software defined networking system in which multiple runtime nodes/network elements form a network slice for performing a particular overarching function [paragraph 0025-0026]. Part of the management of the SDN comprises a root-cause analysis of potential network faults and issues, with the root cause including node/network element failures and link/bridge wires failures [paragraphs 0158-0171, 0177, in particular 0158, 0177]. Upon detecting a fault, corrective action is taken to restore proper function of the network [paragraphs 0182-0188- showing corrective actions to restore proper function based on policies; 0039, 0114, 0003 – policies include established levels of resiliency, such as 1+1 redundancy, geo-location redundance]. The system may be implemented using a processor and memory executing modules [paragraph 0032].)
Therefore, since Ravichandran discloses failure root cause analysis and response, it would have been oblivious to a person of ordinary skill in the art before the effective filing date of the invention to combine the analysis of Ravichandran with the system of 333 by further tracking the performance of each node and bridge wire and performing corrective actions to maintain network policy, such as a required level of redundancy/resilience, based on a determine root cause including fault in one of the nodes or bridge wires and performing a corrective action to restore the level of resiliency required by the network policy and implementing the recited modules using a processor and memory. The motive to combine is to improve network function and uptime by allowing a correction in response to a fault to maintain required levels of resiliency at all times, including during a fault and to further use the low-cost microprocessor for easy implementation and reduced costs.
Regarding claim 4, claims 1, 2, 5, 6, 10 and 11 of 333 fail to disclose but claims 13-15 of 333 disclose the connection establishing module is configured to: implement the one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors in a private network in absence of a firewall implement the one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors in a hybrid network of a public-private network in presence of a firewall; and implement the one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors in a hierarchy of networks protected by one or more firewalls. Therefore, it would have been obvious to a person of ordinary skill in the art to implement the network in a private network, a public network and a hierarchal network. The motive to combine is to allow use of the system in multiple types of networks for greater flexibility.
Regarding claim 8, claims 1, 2, 5, 6, 10 and 11 of 333 fail to disclose but claims 13-15 of 333 disclose the one or more networks comprise private network, a public network and a hybrid network. Therefore, it would have been obvious to a person of ordinary skill in the art to implement the network in a private network, a public network and a hierarchal network. The motive to combine is to allow use of the system in multiple types of networks for greater flexibility.
Claim 11 of Present Application
Claims 1, 2, 5, 6, 10 and 11 of 11,632,333 (all citations to claim 1 unless otherwise noted)
A method for implementing and managing a distributed data flow model, comprising obtaining a flow configuration file of a predefined format associated with one or more runtime nodes of a distributed data flow model from a controller, wherein the flow configuration file comprises a JavaScript Object Notation (JSON) file format comprising data flow configuration information
create a flow configuration file of a predefined format for the at least one runtime upon registration of the at least one runtime
the predefined format of the flow configuration file comprises a JavaScript object notation file format comprising the data flow configuration information (claim 5)
wherein the data flow configuration information comprises flow design of the one or more runtime nodes, one or more node configurations, one or more interconnecting wires, and one or more runtime node configurations
wherein the distributed data flow deployment subsystem is configured to deploy one or more nodes and one or more interconnecting wires of the at least one runtime based on one or more identified portions of the distributed data flow framework from the flow configuration file created
the data flow configuration information comprises at least one of a flow design of the one or more nodes, one or more node configurations, one or more interconnecting wires, one or more runtime configurations or a combination thereof (claim 6)
wherein the one or more runtime nodes are one or more compute nodes equipped with a predetermined functionality for execution of a distributed data flow
wherein the at least one runtime comprises one or more compute nodes equipped with a predetermined functionality for execution of distributed data flow (claim 2)
identifying, by the one or more hardware processors, one or more socket roles and a unique identification number corresponding to each of one or more flow neighbors based on the obtained flow configuration file; establishing, by the one or more hardware processors, a Transmission Control Protocol (TCP) connection of the one or more runtime nodes with each of the one or more flow neighbors based on the identified one or more socket roles and the identified unique identification number
a bridge wire identification subsystem operatively coupled to the flow neighbor identification subsystem, wherein the bridge wire identification subsystem is configured to: identify one or more socket roles and a unique identification number corresponding to each of the one or more flow neighbors from the flow configuration file upon determination of the publisher and the subscriber service information; enable the at least one runtime to establish a transmission control protocol connection with each of the one or more flow neighbors based on an identification of corresponding one or more socket roles and the unique identification number
(note bridge wire identification subsystem can map the bridge wire identification module, connection establishing module is the inherent transmitter necessary to establish the TCP connection)
wherein the TCP connection enables TCP keepalives for preventing deactivation of the established TCP connection
the transmission control protocol connection is configured to enable transmission control protocol keepalives for preventing deactivation of the established transmission control protocol connection (claim 10)
wherein a single TCP connection is established between each pair of flow neighbors from each of the one or more runtime nodes;
enable the at least one runtime to establish a transmission control protocol connection with each of the one or more flow neighbors based on an identification of corresponding one or more socket roles and the unique identification number
(Noting that only one/a single connection is established between the neighbors)
establish a publisher-subscriber relationship of the one or more runtime nodes with each of the one or more flow neighbors for forwarding flow messages based on the established TCP connection
enable the at least one runtime to establish a publisher-subscriber relationship for forwarding flow messages based on the transmission control protocol connection established between the at least one run-time and the one or more flow neighbors;
wherein the publisher-subscriber relationship comprises a relationship between a peer-to-peer publisher on a message originating runtime node and a peer-to-peer subscriber on a message receiving runtime node
the publisher-subscriber relationship comprises a relationship between a peer to peer publisher on a message originating runtime and a subscriber on a message receiving runtime (claim 11)
implement one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors for implementation of the distributed data flow model based on the established publisher-subscriber relationship
implement one or more bridge wires with the at least one runtime and the one or more flow neighbors for implementation of the distributed data flow-based framework based on the publisher-subscriber relationship established
wherein the one or more nodes comprise one or more compute nodes
the at least one runtime comprises one or more compute nodes equipped with a predetermined functionality for execution of distributed data flow (claim 2)
333 fails to explicitly disclose that all the elements of dependent claims 1, 2, 5, 6, 10 and 11, cited above, are utilized at the same time in a single embodiment, as each of the dependent claims is separately claimed. However, it would have been obvious to a person of ordinary skill in the art at the time of the invention to use the elements of claims 1, 2, 5, 6, 10 and 11 together, such that the system of claim 1 of 333 has compute nodes with predefined functionally (claim 2), the predetermined file type is JSON (claim 5), the flow configuration includes node configurations and interconnecting wires (claim 6), the predefined format of claim 1 of 333 is JSON with one or more compute nodes (claim 5), the TCP protocol uses keepalives (claim 10) and the publisher subscriber relationship is peer-to-peer (claim 11). The motive to combine is to allow easy deployment with predefined functions for node interchangeability and re-use (claim 2), use the common format of JSON for compatibility and re-use (claim 5), include configuration and configuration information in the flow configuration file to allow direct configuration of the nodes and wires for improved portability and exact specification of connections (claim 6), use TCP keepalives to reduce overhead and delay associated with re-established the TCP connections if they timeout (claim 10) and to allow peer-to-peer communication without a central routing for efficiency (claim 11).
333 fails to disclose an AI-based method or performing the functions using one or more processors comprising detecting, by one or more hardware processors, a loss of connectivity of one or more networks, and an operational failure of one or more nodes and the one or more runtime nodes deployed in the distributed dataflow model based on implementation of the one or more bridge wires, determining, by one or more hardware processors, one or more root causes of the detected loss of connectivity; and performing, by the one or more hardware processors, one or more operations to attain a predefined level of resiliency of the distributed data flow model over the one or more bridge wires based on the detected loss of connectivity and the determined one or more root causes. In the same field of endeavor, Ravichandran discloses an AI-based method or performing the functions using one or more processors comprising detecting, by one or more hardware processors, a loss of connectivity of one or more networks, and an operational failure of one or more nodes and the one or more runtime nodes deployed in the distributed dataflow model based on implementation of the one or more bridge wires, determining, by one or more hardware processors, one or more root causes of the detected loss of connectivity; and performing, by the one or more hardware processors, one or more operations to attain a predefined level of resiliency of the distributed data flow model over the one or more bridge wires based on the detected loss of connectivity and the determined one or more root causes (Ravichandran discloses a software defined networking system in which multiple runtime nodes/network elements form a network slice for performing a particular overarching function [paragraph 0025-0026]. Part of the management of the SDN comprises a root-cause analysis of potential network faults and issues, with the root cause including node/network element failures and link/bridge wires failures [paragraphs 0158-0171, 0177, in particular 0158, 0177]. Upon detecting a fault, corrective action is taken to restore proper function of the network [paragraphs 0182-0188- showing corrective actions to restore proper function based on policies; 0039, 0114, 0003 – policies include established levels of resiliency, such as 1+1 redundancy, geo-location redundance]. The system may be implemented using a processor and memory executing modules and uses AI [paragraph 0032, 0176].)
Therefore, since Ravichandran discloses failure root cause analysis and response, it would have been oblivious to a person of ordinary skill in the art before the effective filing date of the invention to combine the analysis of Ravichandran with the system of 333 by further tracking the performance of each node and bridge wire and performing corrective actions to maintain network policy using AI, such as a required level of redundancy/resilience, based on a determine root cause including fault in one of the nodes or bridge wires and performing a corrective action to restore the level of resiliency required by the network policy and implementing the recited modules using a processor and memory. The motive to combine is to improve network function and uptime by allowing a correction in response to a fault to maintain required levels of resiliency at all times, including during a fault and to further use the low-cost microprocessor for easy implementation and reduced costs.
Regarding claim 14, claims 1, 2, 5, 6, 10 and 11 of 333 fail to disclose but claims 13-15 of 333 disclose the connection establishing module is configured to: implement the one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors in a private network in absence of a firewall implement the one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors in a hybrid network of a public-private network in presence of a firewall; and implement the one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors in a hierarchy of networks protected by one or more firewalls. Therefore, it would have been obvious to a person of ordinary skill in the art to implement the network in a private network, a public network and a hierarchal network. The motive to combine is to allow use of the system in multiple types of networks for greater flexibility.
Regarding claim 18, claims 1, 2, 5, 6, 10 and 11 of 333 fail to disclose but claims 13-15 of 333 disclose the one or more networks comprise private network, a public network and a hybrid network. Therefore, it would have been obvious to a person of ordinary skill in the art to implement the network in a private network, a public network and a hierarchal network. The motive to combine is to allow use of the system in multiple types of networks for greater flexability.
Claims 5 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 11 of U.S. Patent No. 11,632,333 (“333”) in view of Ravichandran, et al. (US Pre Gant Publication No. 2020/0186411) as applied to claims 1 and 11 and further in view of Gunasekran, et al. (US Pre Grant Publication No. 2022/0321668).
Regarding claims 5 and 15, 333 as modified by Ravichandran fails to disclose the one or more root causes of the detected loss of connectivity comprise a data channel security keys of the one or more runtime nodes are expired. In the same field of endeavor, Gunasekran discloses the one or more root causes of the detected loss of connectivity comprise a data channel security keys of the one or more runtime nodes are expired. (Gunasekran discloses that a tunnel between devices will fail when the key expires [paragraph 0009].)
Therefore, since Gunasekran suggests tunnel/wire failure based on a key expiration, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the key failure of Gunasekran with the system of 333 as modified by Ravichandran by detecting a failure of the wire/tunnel when a key expires. The motive to combine is to allow detection of failure events related to key expiration for improved failure detection.
Allowable Subject Matter
Claims 2, 3, 6, 7, 9, 10, 12, 13, 16, 17, 19 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 1, 4, 5, 8, 11, 14, 15 and 18 are rejected under non-statutory double patenting but would be allowable upon the timely filing of a terminal disclaimer
The following is an examiner’s statement of reasons for allowance:
Regarding claims 1 and 11, the claims generally recite
obtaining a flow configuration file of a predefined format associated with one or more runtime nodes of a distributed data flow model from a controller, wherein the flow configuration file comprises a JavaScript Object Notation (JSON) file format comprising data flow configuration information, wherein the data flow configuration information comprises flow design of the one or more runtime nodes, one or more node configurations, one or more interconnecting wires, and one or more runtime node configurations, and wherein the one or more runtime nodes are one or more compute nodes equipped with a predetermined functionality for execution of a distributed data flow;
identify one or more socket roles and a unique identification number corresponding to each of one or more flow neighbors based on the obtained flow configuration file;
establish a Transmission Control Protocol (TCP) connection of the one or more runtime nodes with each of the one or more flow neighbors based on the identified one or more socket roles and the identified unique identification number, wherein the TCP connection enables TCP keepalives for preventing deactivation of the established TCP connection, and wherein a single TCP connection is established between each pair of flow neighbors from each of the one or more runtime nodes;
establish a publisher-subscriber relationship of the one or more runtime nodes with each of the one or more flow neighbors for forwarding flow messages based on the established TCP connection, wherein the publisher-subscriber relationship comprises a relationship between a peer-to-peer publisher on a message originating runtime node and a peer-to-peer subscriber on a message receiving runtime node; and
implement one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors for implementation of the distributed data flow model based on the established publisher-subscriber relationship;
detect a loss of connectivity of one or more networks, and an operational failure of one or more nodes and the one or more runtime nodes deployed in the distributed dataflow model based on implementation of the one or more bridge wires, wherein the one or more nodes comprise one of: one or more compute nodes and one or more battery powered sensing nodes;
a cause determination module configured to determine one or more root causes of the detected loss of connectivity; and an
operation performing module configured to perform one or more operations to attain a predefined level of resiliency of the distributed data flow model over the one or more bridge wires based on the detected loss of connectivity and the determined one or more root causes.
obtaining a flow configuration file of a predefined format associated with one or more runtime nodes of a distributed data flow model from a controller, wherein the flow configuration file comprises a JavaScript Object Notation (JSON) file format comprising data flow configuration information, wherein the data flow configuration information comprises flow design of the one or more runtime nodes, one or more node configurations, one or more interconnecting wires, and one or more runtime node configurations, and wherein the one or more runtime nodes are one or more compute nodes equipped with a predetermined functionality for execution of a distributed data flow;
identify one or more socket roles and a unique identification number corresponding to each of one or more flow neighbors based on the obtained flow configuration file;
establish a Transmission Control Protocol (TCP) connection of the one or more runtime nodes with each of the one or more flow neighbors based on the identified one or more socket roles and the identified unique identification number, wherein the TCP connection enables TCP keepalives for preventing deactivation of the established TCP connection, and wherein a single TCP connection is established between each pair of flow neighbors from each of the one or more runtime nodes;
establish a publisher-subscriber relationship of the one or more runtime nodes with each of the one or more flow neighbors for forwarding flow messages based on the established TCP connection, wherein the publisher-subscriber relationship comprises a relationship between a peer-to-peer publisher on a message originating runtime node and a peer-to-peer subscriber on a message receiving runtime node; and
These claims are allowable for two main reasons.
First, no art teaching specifically the elements of obtaining a flow configuration…comprising data flow configuration information, wherein the data flow configuration information comprises flow design of the one or more runtime nodes…one or more interconnecting wires…wherein the one or more runtime nodes are one or more compute nodes equipped with a predetermined functionality for execution of a distributed data flow…identify one or more socket roles and a unique identification number corresponding to each of one or more flow neighbors based on the obtained flow configuration file…establish a Transmission Control Protocol (TCP) connection of the one or more runtime nodes with each of the one or more flow neighbors based on the identified one or more socket roles and the identified unique identification number… wherein a single TCP connection is established between each pair of flow neighbors from each of the one or more runtime nodes and establish a publisher-subscriber relationship of the one or more runtime nodes with each of the one or more flow neighbors for forwarding flow messages based on the established TCP connection, wherein the publisher-subscriber relationship comprises a relationship between a peer-to-peer publisher on a message originating runtime node and a peer-to-peer subscriber on a message receiving runtime node and implement one or more bridge wires with the one or more runtime nodes and the one or more flow neighbors for implementation of the distributed data flow model based on the established publisher-subscriber relationship.
These limitations require that the JSON file establishing the flow configuration indicates with a flow model which identifies the socket roles of each of the flow neighbors of each of the runtime nodes and then for each flow neighbor establishes a single TCP connection and each established TCP connection establishes a publisher-subscriber relationship for message processing and further a bridge wire. From these limitations (and applicant’s specification. PGPUB No. 2023/0026245 A1, see fig. 5 and paragraph 0065-0090) it can be seen that a “flow” as claimed here is not merely a data flow in the sense of a particular IP address and port combination, as it is commonly referred to in the art, but rather is a flow of data in accordance with the established flow and publisher-subscriber relationship that serially connects the runtime nodes to perform the required publish and subscribe actions. That is, the flow neighbors are not established in accordance with traditional IP networking principles, but are rather established exclusively for the purpose of carrying the required series of publisher-subscriber relationships in the network.
Viewing the claims in this light, Zhang represents the closest prior art of record. The system of Zhang (Kaiwen Zhang and Hans-Arno Jacobsen, SDN-like: The Next Generation of Pub/Sub, pages 1-17, 21 July 2013) discloses combining software defined networking with content-based publish-subscribe models [page 4, section 2.1] the SDN controller establishes an overlay network linking multiple publishers of information, brokers for aggregating and further supplying the published information and subscribers for consuming the information [see page 5, in particular fig.1]. However, Zhang is lacking with respect to details of the claimed JSON file establishing the flow relationships in the manner claimed. Other art, such as Wang (Yali Wang, Yang Zhang, and Junliang Chen, SDNPS: A Load-Balanced Topic-Based Publish/Subscribe System in Software-Defined Networking, pages 1-21, 2016) discloses a publish-subscribe model in IoT data gathering applications (page 1, Abstract) discloses a similar overlay for exchanging gathered sensor data for IoT uses, but once again lacks the specify of the claimed JSON file.
Second, even if the highlighted claim elements of the first reasons for allowance were present in the prior art, the claims present such a large volume of disparate claim limitations scattered across various pieces of prior art, the number and type of combinations required to reject the claimed subject matter would become so large as to amount to hindsight reconstruction of the invention. For example, the claimed TCP keepalives, socket role and associated unique identifier for identifying neighbor nodes, determination of a failure, root cause of a failure and remediation as well as attaining a desires predefined level of resiliency all represent element that are not present in any single prior art of record, requiring multiple complex combinations to arrive at the claimed invention.
Regarding claims 2, 3, 6, 7, 9, 10, 12, 13, 16, 17, 19 and 20, with respect to these claims non-inclusion in the double patenting rejection, given the number and type of combinations already made to reject claims 1 and 11 in view of 303 and Ravichandran, it was deemed that the further modification of these claims with additional art directed to the elements of these claims would amount to hindsight reconstruction of the invention.
Therefore, the prior art fails to teach, suggest or disclose all elements of the claimed invention.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
SImosa, et al. (J Simosa, A Publish-Subscribe Implementation of Network Management, pages 1-77, 2013) – disclosing another publish subscribe overlay.
Dong, et al. (Xinshu Dong, Hui Lin, Rui Tan, Ravishankar K. Iyer, Zbigniew Kalbarczyk, Software-Defined Networking for Smart Grid Resilience: Opportunities and Challenges, pages 1-8, 2015) – disclosing a SDN network with souce and sink nodes for SCADA operating systems
Mariappan, et al. (US Pre Grant Publication No. 2022/0278927) – disclosing JSON for orchestrating SDN network architecture
Csar, et al. (US Pre Grant Publication No. 2023/0251909) – disclosing publisher subscriber networking using, at least in part, JSON to describe network architecture
Ross, et al. (US Pre Grant Publication No. 2022/0201024) – disclosing a topic based overlay for message exchange, with links identified in JSON (paragraphs 0006, 0019, 0026)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER M CRUTCHFIELD whose telephone number is (571)270-3989. The examiner can normally be reached 9am-5pm M-F.
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, Faruk Hamza can be reached at (571) 272-7969. 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.
/CHRISTOPHER M CRUTCHFIELD/Primary Examiner, Art Unit 2466