DETAILED ACTION
Notice of 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/23/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) was submitted on 03/23/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed 03/23/2026 have been fully considered.
Applicant argues that “the Applicant is not claiming to have invented invoking inbuilt OS-native utilities, or to have invented invoking inbuilt OS-native utilities remotely. Nor is the applicant claiming to have invented network mapping”. That it would be impermissible hindsight knowledge of the invention in order to combine these references.
In response to the argument, Examiner respectfully disagrees. Whipple teaches on the crux of this invention. Whipple teaches on invoking scripts (parser functions) on servers to collect network connection information (device representations). This information, gathered by invoking these parser functions, are used to build a topology map. Further, Whipple teaches on the servers have different operating systems and the data collected is put into a common representation. Pall is brought in to show that the scripts on the servers are easily modified to being OS native (under the definition of Affidavit filed by Applicant on 05/14/2025). Whipple is easily modified by Pall to teach on remote invocation of the parser functions. Data is retrieved/collected across the network (Whipple, Fig 6). It would have been obvious to incorporate the teachings of Pall into Whipple with expected/predictable results of remotely invoking OS-native scripts of an operating system of a particular device over network connections in order to create a network topology map. There is no impermissible hindsight.
Applicant argues that the Examiner's reasoning for modifying Whipple with Pall falls short of the articulated reasoning required by MPEP 2141. In response to the argument, Examiner respectfully disagrees. Whipple teaches on most of the limitations of the independent claims. Whipple teaches on invoking scripts (parser functions) on servers to collect network connection information. Whipple is easily modified by Pall as the parser functions of Whipple are OS utilities. The parser functions execute (are invoked) within operating systems of different servers (each which may have differing operating systems). Whipple is silent, does not explicitly teach that these OS utilities are OS native utilities as defined in the affidavit filed by Applicant on 05/14/2025. The modification of Whipple per Pall allows for remotely invoking/utilizing an OS native built-in utility of the system device. Whipple shows remote access, invoking scripts on servers (of differing operating systems) in order to collect network topology and building a network map using that collected information. The motivation to combine is to allow for easier implementation by providing further details that the parser functions of Whipple are modified by Pall as being OS native utilities. It would have been expected to incorporate the teachings of Pall of remote invoking OS native utilities into Whipple with expected results of remotely invoking OS native utilities of a particular device over network connections in order to generate a network topology. However, OS native utilities are also known to increase efficiency in processing.
Please see rejection below in view of:
Claim(s) 1, 4-5, 7-8, 11-12, 14-15, 18-19, 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 10,735,270 B1 (Whipple) in view of US 2010/0205650 Al (Pall) further in view of US 2016/0127250 A1 (McCormick).
Claim(s) 2-3, 9-10, 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 10,735,270 B1 (Whipple) in view of US 2010/0205650 Al (Pall) further in view of US 2016/0127250 A1 (McCormick) more in view of US 10,601,635 B1 (Zuberi).
Claim(s) 6, 13, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 10,735,270 B1 (Whipple) in view of US 2010/0205650 Al (Pall) further in view of US 2016/0127250 A1 (McCormick) more in view of US 2016/0191672 A1 (Perlman).
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4-5, 7-8, 11-12, 14-15, 18-19, 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 10,735,270 B1 (Whipple) in view of US 2010/0205650 Al (Pall) further in view of US 2016/0127250 A1 (McCormick).
Regarding Claim 1:
Whipple teaches A method for mapping network connections among a plurality of servers, (systems and methods for network modelling include determining a device representation of each device on a network. A normalized device representation associated with a device representation of each device is determined using a library of device representation parser functions, Abstract) the method comprising:
invoking (ie. using parser functions) a first device representation (ie. data collection using device representation) on a first one of the servers (ie. node) to identify first TCP/IP connections on the first one of the servers; and invoking (ie. using) a second device representation (ie. data collection using device representation) on a second one of the servers (ie. another node) to identify second TCP/IP connections on the second one of the servers; (Col 9 ln 62-66, The data collector 102 is in communication with the network 120 and collects, e.g., device representations for each device serving as a node, as well as information related links and states of operation associated with each device. Col 10 ln 3-6, A device representation refers to a file of commands used by the device to, e.g., determine a hostname, an internet protocol (IP) address, among other configurations for the connection to devices and routing of information. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. Col 2 ln 37-38, determining a device representation of each device of a plurality of devices on the network; Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
parsing the first TCP/IP connections and the second TCP/IP connections into a common representation format (ie. neutral); (Col 10 ln 34-41, The device representations may then be normalized into a neutral form, such as, e.g., a vendor neutral, platform neutral and/or version neutral form. In some embodiments, the normalization may be performed using parser functions for translating a device representation from a vendor, platform and/or version specific format into a modelling system format that is vendor, platform and/or version neutral. Col 11 ln 15-21, each parser function of library may translate a protocol or configuration from a particular device to the normalized or generalized form based on, e.g., the hardware, the software, the vendor, the protocol, or other characteristics.)
and using the common representation format to map dependencies in the network. (Col 11 ln 3-5, 40-54, network data, such as nodes and how those nodes are connected through physical interfaces, may be presented in a variety of ways. The data collector 102 may communicate the normalized device representations to the graph builder 104 to generate a model of an architecture or topology of the network 120. Because the device representations include details as to a respective node, each link to another node and a policy defining device connection protocols for each link, the collection of normalized configurations can be assembled into a detailed map or model of each node and each link between nodes in the network 120. Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches, in the same field of endeavor, an installer system which facilitates easy installation of software modules in a heterogeneous computing system, Abstract.
Pall also teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Pall) is silent on using the common representation format to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections and differentiating the second TCP/IP connections into second inbound TCP/IP connections and second outbound TCP/IP connections.
McCormick teaches, in the same field of endeavor, data traffic scheduling method that includes obtaining, using a network controller, a network topology for a network, generating an augmented graph based on the network topology, Abstract.
McCormick also teaches using the common representation format ([0058] received data structures) to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections (ie. ingress) and first outbound TCP/IP connections (ie. egress) and differentiating the second TCP/IP connections into second inbound TCP/IP connections (ie. ingress) and second outbound TCP/IP connections (ie. egress). ([0058]-[0060] The augmented graph is modelled by associating mapping tables to link objects (e.g., link 1104) and network node objects (e.g., the first network node 1102A and the second network node 1106A) in the network. For example, the first network node 1102A is associated with a first network node mapping (NodeMap) table 1108, the second network node 1106A is associated with a second NodeMap table 1116, and link 1104 is associated with an egress slot mapping table 1110, a slot delay mapping table 1112, and an ingress slot mapping table 1114.) See Figs 9-11.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall) by modifying Whipple per McCormick to include and using the common representation format to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections and differentiating the second TCP/IP connections into second inbound TCP/IP connections and second outbound TCP/IP connections. This would have been advantageous as discussed above, as it would allow the combined system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Regarding Claim 8:
Whipple teaches A computer program product comprising a tangible, non-transitory computer readable medium containing instructions ([0276] machine-readable non-transitory storage medium, which provides content that represents instructions that can be executed. The content may result in a computer performing various functions/operations described herein.) which, when executed by at least one processor of a data processing system ([0276] The operations and functions performed by various components described herein may be implemented by software running on a processing element, via embedded hardware.), causes the data processing system to implement a method for mapping network connections among a plurality of servers, the method comprising:
invoking (ie. using parser functions) a first device representation (ie. data collection using device representation) on a first one of the servers (ie. node) to identify first TCP/IP connections on the first one of the servers; and invoking (ie. using) a second device representation (ie. data collection using device representation) on a second one of the servers (ie. another node) to identify second TCP/IP connections on the second one of the servers; (Col 9 ln 62-66, The data collector 102 is in communication with the network 120 and collects, e.g., device representations for each device serving as a node, as well as information related links and states of operation associated with each device. Col 10 ln 3-6, A device representation refers to a file of commands used by the device to, e.g., determine a hostname, an internet protocol (IP) address, among other configurations for the connection to devices and routing of information. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. Col 2 ln 37-38, determining a device representation of each device of a plurality of devices on the network; Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
parsing the first TCP/IP connections and the second TCP/IP connections into a common representation format (ie. neutral); (Col 10 ln 34-41, The device representations may then be normalized into a neutral form, such as, e.g., a vendor neutral, platform neutral and/or version neutral form. In some embodiments, the normalization may be performed using parser functions for translating a device representation from a vendor, platform and/or version specific format into a modelling system format that is vendor, platform and/or version neutral. Col 11 ln 15-21, each parser function of library may translate a protocol or configuration from a particular device to the normalized or generalized form based on, e.g., the hardware, the software, the vendor, the protocol, or other characteristics.)
and using the common representation format to map dependencies in the network. (Col 11 ln 3-5, 40-54, network data, such as nodes and how those nodes are connected through physical interfaces, may be presented in a variety of ways. The data collector 102 may communicate the normalized device representations to the graph builder 104 to generate a model of an architecture or topology of the network 120. Because the device representations include details as to a respective node, each link to another node and a policy defining device connection protocols for each link, the collection of normalized configurations can be assembled into a detailed map or model of each node and each link between nodes in the network 120. Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Pall) is silent on using the common representation format to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections and differentiating the second TCP/IP connections into second inbound TCP/IP connections and second outbound TCP/IP connections.
McCormick teaches using the common representation format ([0058] received data structures) to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections (ie. ingress) and first outbound TCP/IP connections (ie. egress) and differentiating the second TCP/IP connections into second inbound TCP/IP connections (ie. ingress) and second outbound TCP/IP connections (ie. egress). ([0058]-[0060] The augmented graph is modelled by associating mapping tables to link objects (e.g., link 1104) and network node objects (e.g., the first network node 1102A and the second network node 1106A) in the network. For example, the first network node 1102A is associated with a first network node mapping (NodeMap) table 1108, the second network node 1106A is associated with a second NodeMap table 1116, and link 1104 is associated with an egress slot mapping table 1110, a slot delay mapping table 1112, and an ingress slot mapping table 1114.) See Figs 9-11.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall) by modifying Whipple per McCormick to include and using the common representation format to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections and differentiating the second TCP/IP connections into second inbound TCP/IP connections and second outbound TCP/IP connections. This would have been advantageous as discussed above, as it would allow the combined system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Regarding Claim 15:
Whipple teaches A data processing system comprising at least one processor and memory coupled to the at least one processor, wherein the memory stores instructions ([0276] The operations and functions performed by various components described herein may be implemented by software running on a processing element, via embedded hardware.) which, when executed by the at least one processor, cause the data processing system to implement a method for mapping network connections among a plurality of servers, the method comprising:
invoking (ie. using parser functions) a first device representation (ie. data collection using device representation) on a first one of the servers (ie. node) to identify first TCP/IP connections on the first one of the servers; and invoking (ie. using) a second device representation (ie. data collection using device representation) on a second one of the servers (ie. another node) to identify second TCP/IP connections on the second one of the servers; (Col 9 ln 62-66, The data collector 102 is in communication with the network 120 and collects, e.g., device representations for each device serving as a node, as well as information related links and states of operation associated with each device. Col 10 ln 3-6, A device representation refers to a file of commands used by the device to, e.g., determine a hostname, an internet protocol (IP) address, among other configurations for the connection to devices and routing of information. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. Col 2 ln 37-38, determining a device representation of each device of a plurality of devices on the network; Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
parsing the first TCP/IP connections and the second TCP/IP connections into a common representation format (ie. neutral); (Col 10 ln 34-41, The device representations may then be normalized into a neutral form, such as, e.g., a vendor neutral, platform neutral and/or version neutral form. In some embodiments, the normalization may be performed using parser functions for translating a device representation from a vendor, platform and/or version specific format into a modelling system format that is vendor, platform and/or version neutral. Col 11 ln 15-21, each parser function of library may translate a protocol or configuration from a particular device to the normalized or generalized form based on, e.g., the hardware, the software, the vendor, the protocol, or other characteristics.)
and using the common representation format to map dependencies in the network. (Col 11 ln 3-5, 40-54, network data, such as nodes and how those nodes are connected through physical interfaces, may be presented in a variety of ways. The data collector 102 may communicate the normalized device representations to the graph builder 104 to generate a model of an architecture or topology of the network 120. Because the device representations include details as to a respective node, each link to another node and a policy defining device connection protocols for each link, the collection of normalized configurations can be assembled into a detailed map or model of each node and each link between nodes in the network 120. Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Pall) is silent on using the common representation format to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections and differentiating the second TCP/IP connections into second inbound TCP/IP connections and second outbound TCP/IP connections.
McCormick teaches using the common representation format ([0058] received data structures) to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections (ie. ingress) and first outbound TCP/IP connections (ie. egress) and differentiating the second TCP/IP connections into second inbound TCP/IP connections (ie. ingress) and second outbound TCP/IP connections (ie. egress). ([0058]-[0060] The augmented graph is modelled by associating mapping tables to link objects (e.g., link 1104) and network node objects (e.g., the first network node 1102A and the second network node 1106A) in the network. For example, the first network node 1102A is associated with a first network node mapping (NodeMap) table 1108, the second network node 1106A is associated with a second NodeMap table 1116, and link 1104 is associated with an egress slot mapping table 1110, a slot delay mapping table 1112, and an ingress slot mapping table 1114.) See Figs 9-11.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall) by modifying Whipple per McCormick to include and using the common representation format to map dependencies in the network by differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections and differentiating the second TCP/IP connections into second inbound TCP/IP connections and second outbound TCP/IP connections. This would have been advantageous as discussed above, as it would allow the combined system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Regarding Claims 4, 11, 18:
Whipple (as modified by Pall & McCormick) teaches the inventions of claims 1, 8, 15 as described.
Whipple teaches wherein the plurality of servers (ie. nodes) comprises at least three servers, (Col 9 ln 42-44, Some or all of the devices of the network may form nodes, such as routing nodes to propagating information throughout the network.) the method further comprising:
invoking (ie. using) a third device representation (ie. data collection using device representation) on a third one of the servers (ie. other node) to identify third TCP/IP connections on the third one of the servers; (Col 9 ln 62-66, The data collector 102 is in communication with the network 120 and collects, e.g., device representations for each device serving as a node, as well as information related links and states of operation associated with each device. Col 10 ln 3-6, A device representation refers to a file of commands used by the device to, e.g., determine a hostname, an internet protocol (IP) address, among other configurations for the connection to devices and routing of information. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. Col 2 ln 37-38, determining a device representation of each device of a plurality of devices on the network; Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
and parsing the third TCP/IP connections into the common representation format; (Col 10 ln 34-41, The device representations may then be normalized into a neutral form, such as, e.g., a vendor neutral, platform neutral and/or version neutral form. In some embodiments, the normalization may be performed using parser functions for translating a device representation from a vendor, platform and/or version specific format into a modelling system format that is vendor, platform and/or version neutral. Col 11 ln 15-21, each parser function of library may translate a protocol or configuration from a particular device to the normalized or generalized form based on, e.g., the hardware, the software, the vendor, the protocol, or other characteristics.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by McCormick) by modifying Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Pall) is silent on wherein using the common representation format to map dependencies in the network further comprises differentiating the third TCP/IP connections into third inbound TCP/IP connections and third outbound TCP/IP connections.
McCormick teaches wherein using the common representation format (ie. received data structures) to map dependencies in the network further comprises differentiating the third TCP/IP connections into third inbound TCP/IP connections (ie. ingress) and third outbound TCP/IP connections (ie. egress). ([0058]-[0060] The augmented graph is modelled by associating mapping tables to link objects (e.g., link 1104) and network node objects (e.g., the first network node 1102A and the second network node 1106A) in the network. For example, the first network node 1102A is associated with a first network node mapping (NodeMap) table 1108, the second network node 1106A is associated with a second NodeMap table 1116, and link 1104 is associated with an egress slot mapping table 1110, a slot delay mapping table 1112, and an ingress slot mapping table 1114.) See Figs 9-11.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall) by modifying Whipple per McCormick to include wherein using the common representation format to map dependencies in the network further comprises differentiating the third TCP/IP connections into third inbound TCP/IP connections and third outbound TCP/IP connections. This would have been advantageous as discussed above, as it would allow the combined system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Regarding Claims 5, 12, 19:
Whipple (as modified by Pall & McCormick) teaches the inventions of claims 1, 8, 15 as described.
Whipple teaches wherein: the first device representation (Col 15 ln 24-41, The collection of routes carried by the devices may be referred to as routing information base (RIB). The RIB is advertised by each device on the network 120 to the gateway protocol server 114 across the respective routing protocol peering sessions, however the RIB may be advertised by some devices on the network 120 according to, e.g., selected subsets of devices according to, e.g., device type, location, user selection, configuration, routing policy, or other parameters for defining subsets of devices. The gateway protocol server 114 may collect the RIB for some or all of the devices on the network 120 and provide it to the fabric monitor 110 along with the status updates.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple (as modified by McCormick) does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by McCormick) by modifying Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Regarding Claims 7, 14, 21:
Whipple (as modified by Pall & McCormick) teaches the inventions of claims 1, 8, 15 as described.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). However, Whipple (as modified by Pall) is silent on wherein the mapping uses the first inbound TCP/IP connections, the first outbound TCP/IP connections, the second inbound TCP/IP connections and the second outbound TCP/IP connections to generate host dependencies based on respective directions of the first inbound TCP/IP connections, the first outbound TCP/IP connections, the second inbound TCP/IP connections and the second outbound TCP/IP connections.
McCormick teaches wherein the mapping uses the first inbound TCP/IP connections (ie. ingress), the first outbound TCP/IP connections (ie. egress), the second inbound TCP/IP connections (ie. ingress) and the second outbound TCP/IP connections (ie. egress) to generate host dependencies based on respective directions of the first inbound TCP/IP connections, the first outbound TCP/IP connections, the second inbound TCP/IP connections and the second outbound TCP/IP connections. ([0058]-[0060] The augmented graph is modelled by associating mapping tables to link objects (e.g., link 1104) and network node objects (e.g., the first network node 1102A and the second network node 1106A) in the network. For example, the first network node 1102A is associated with a first network node mapping (NodeMap) table 1108, the second network node 1106A is associated with a second NodeMap table 1116, and link 1104 is associated with an egress slot mapping table 1110, a slot delay mapping table 1112, and an ingress slot mapping table 1114.) See Figs 9-11.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall) by modifying Whipple per McCormick to include wherein the mapping uses the first inbound TCP/IP connections, the first outbound TCP/IP connections, the second inbound TCP/IP connections and the second outbound TCP/IP connections to generate host dependencies based on respective directions of the first inbound TCP/IP connections, the first outbound TCP/IP connections, the second inbound TCP/IP connections and the second outbound TCP/IP connections. This would have been advantageous as discussed above, as it would allow the modified system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Claim(s) 2-3, 9-10, 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 10,735,270 B1 (Whipple) in view of US 2010/0205650 Al (Pall) further in view of US 2016/0127250 A1 (McCormick) more in view of US 10,601,635 B1 (Zuberi).
Regarding Claims 2, 9, 16:
Whipple (as modified by Pall & McCormick) teaches the inventions of claims 1, 8, 15 as described.
Whipple teaches wherein: the first device representation (ie. using) a first device representation (ie. device representation) on the first one of the servers (ie. node); and the second device representation (ie. using) a second device representation (ie. device representation) on the second one of the servers (ie. another node); (Col 9 ln 62-66, The data collector 102 is in communication with the network 120 and collects, e.g., device representations for each device serving as a node, as well as information related links and states of operation associated with each device. Col 10 ln 3-6, A device representation refers to a file of commands used by the device to, e.g., determine a hostname, an internet protocol (IP) address, among other configurations for the connection to devices and routing of information. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. Col 2 ln 37-38, determining a device representation of each device of a plurality of devices on the network; Col 12, ln 35-36, The network 120 conforms to a Transmission Control Protocol/Internet Protocol (TCP/IP) network modality.)
parsing the first TCP/IP connections into the common representation format; and parsing the second TCP/IP connections into the common representation format. (Col 10 ln 34-41, The device representations may then be normalized into a neutral form, such as, e.g., a vendor neutral, platform neutral and/or version neutral form. In some embodiments, the normalization may be performed using parser functions for translating a device representation from a vendor, platform and/or version specific format into a modelling system format that is vendor, platform and/or version neutral. Col 11 ln 15-21, each parser function of library may translate a protocol or configuration from a particular device to the normalized or generalized form based on, e.g., the hardware, the software, the vendor, the protocol, or other characteristics.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple (as modified by McCormick) does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by McCormick) by modifying Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Whipple teaches on parsing the first and second connections into a common representation format (Col 10 ln 34-41). However, Whipple (as modified by Pall & McCormick) is silent on parsing the first TCP/IP connections into the common representation format occurs on the first server; and parsing the second TCP/IP connections into the common representation format occurs on the second server.
Zuberi teaches, in the same field of endeavor, a method which provides remote management of a distributed computer system through a wireless communication link, Abstract.
Zuberi also teaches parsing the first management information into the common representation format occurs on the first server; and parsing the second management information into the common representation format occurs on the second server. (Col 12 ln 23-30, Claim 1. … sending, by the wireless server, the parsed information to the transformation engine; determining, at the transformation engine, the type of network management request based on parameters in the request, wherein the transformation engine uses an Application Programming Interface (API) exposed by the system interface engine to generate a request data object based on network management parameters extracted from the network management information; transforming, by the transformation engine, the parsed management information to a format for use by a management server at the distributed computer network system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall & McCormick) by modifying Whipple per Zuberi to include parsing the first TCP/IP connections into the common representation format occurs on the first server; and parsing the second TCP/IP connections into the common representation format occurs on the second server. This would have been advantageous as discussed above, as it would allow the combined system to provide nodes with processing capabilities, allowing for independently processing data into a neutral format prior to sending it the data collector.
Regarding Claims 3, 10, 17:
Whipple (as modified by Pall & McCormick & Zuberi) teaches the inventions of claims 2, 9, 16 as described.
Whipple teaches wherein: the first one of the servers runs a first operating system and the second one of the servers runs a second operating system; the first operating system is different from the second operating system; (Col 10 ln 13-25, The network 120 may include devices from multiple different vendors, or the network modelling system 100 may be collecting data from multiple networks 120 provisioned by multiple different vendors. In fact, the network 120 may include devices that vary by more than just vendor. Rather, the network 120 may include devices with varying software versions, platforms, hardware configurations, hardware capabilities, and any other device differences. Thus, in some embodiments, the data collector 102 may normalize the collected data to facilitate interoperability and compatibility with devices having varying vendors, platforms, operating systems, software versions, hardware configurations, hardware capabilities among other differences.)
the first device representation device representation (Col 10 ln 3-6, A device representation refers to a file of commands used by the device to, e.g., determine a hostname, an internet protocol (IP) address, among other configurations for the connection to devices and routing of information. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. Col 10 ln 29-37, The data collector 102 may then communicate with each node device to retrieve device representations. The data collector 102 may receive a representation of device operation, including the device representations and state information, from the network 120 according to network protocols for communicating on the network. The device representations may then be normalized into a neutral form, such as, e.g., a vendor neutral, platform neutral and/or version neutral form.)
Whipple teaches on a device representation that when executed/invoked provides device connections (Col 9 ln 62-66, Col 10 ln 3-6), remote network connections (Fig 6) and on examples of software (Col 5 ln 62-65, Col 6 ln 1-9, 44-67). However, Whipple (as modified by McCormick) does not explicitly teach on the device representation being a script/utility that is OS native, ie. within the operating system software. Whipple does not explicitly teach on remotely invoking an OS inbuilt utility.
Pall teaches on remotely invoking an OS inbuilt utility. ([0037] In step 240, interface tool 150 determines the operating system of the selected remote system. An operating system has built-in utilities to respond to queries (on a network) and provide an identifier of the operating system as a response, such an utility can be conveniently invoked from the interface tool, to determine the operating system of the remote system.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by McCormick) by modifying Whipple per Pall to include remotely invoking an OS inbuilt utility. This would have been advantageous as discussed above, as it would allow the combined system to facilitate implementation of collecting system device information by providing details of remotely invoking/utilizing an OS native built-in utility of the system device and to provide efficient processing by only utilizing OS native utilities.
Claim(s) 6, 13, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 10,735,270 B1 (Whipple) in view of US 2010/0205650 Al (Pall) further in view of US 2016/0127250 A1 (McCormick) more in view of US 2016/0191672 A1 (Perlman).
Regarding Claims 6, 13, 20:
Whipple (as modified by Pall & McCormick) teaches the inventions of claims 1, 8, 15 as described.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). However, Whipple (as modified by Pall & McCormick) is silent on wherein the differentiating the first TCP/IP connections into the first inbound TCP/IP connections and the first outbound TCP/IP connections comprises executing a network engineering protocol logic layer on the common representation format wherein: for an active one of the first TCP/IP connections: if the an active one of the first TCP/IP connections is made to one of the first server’s IP addresses bound to one of the first server’s listening ports and has a local port number, where the local port number is lower than a remote port number then the active one of the first TCP/IP connections is considered to be one of the first inbound TCP/IP connections; and otherwise the active one of the first TCP/IP connections is considered to be one of the first outbound TCP/IP connections.
Perlman teaches, in the same field of endeavor, Methods and apparatus for multiplexing many client streams over a single connection, Abstract.
Perlman also teaches wherein differentiating the first TCP/IP connections into first inbound TCP/IP connections and first outbound TCP/IP connections comprises executing a network engineering protocol logic layer on the common representation format ([0048] The illustrated components for software processing stack 332 include a client stream processing block 334, and an HTTP/HTTPS layer 338. [0049] the data payload associated with an incoming HTTP communication is separated out by the HTTP layer and forwarded to the applicable application. In the reverse direction, applications generate HTTP response data that are returned to HTTP clients.) wherein:
for an active one of the first TCP/IP connections: if the active one of the first TCP/IP connections is made to one of the first server’s IP addresses bound to one of the first server’s listening ports and has a local port number, where the local port number is lower than a remote port number then the active one of the first TCP/IP connections is considered to be one of the first inbound TCP/IP connections; ([0057] An HTTP session is a sequence of network request response transactions. An HTTP client initiates a request by establishing a TCP connection to a particular port on a server (typically port 80, although many other ports may also be used). An HTTP server at the IP address included in the initial HTTP request "listening" on that port is configured to set-up the TCP connection.)
and otherwise the active one of the first TCP/IP connections is considered to be one of the first outbound TCP/IP connections. ([0051] The HTTP response data is received at HTTP layer 338 and an applicable HTTP header is added (depending on the type of HTTP response). In connection with opening a client ID TCP connection, a client output queue 346 is allocated by web server 122.The applicable client output queue 346 is identified by a lookup of client ID mapping table 302.) The active connection (HTTP response) is identified as outbound.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Whipple (as modified by Pall & McCormick) by modifying McCormick per Perlman to include wherein the differentiating the first TCP/IP connections into the first inbound TCP/IP connections and the first outbound TCP/IP connections comprises executing a network engineering protocol logic layer on the common representation format wherein: for an active one of the first TCP/IP connections: if the an active one of the first TCP/IP connections is made to one of the first server’s IP addresses bound to one of the first server’s listening ports and has a local port number, where the local port number is lower than a remote port number then the active one of the first TCP/IP connections is considered to be one of the first inbound TCP/IP connections; and otherwise the active one of the first TCP/IP connections is considered to be one of the first outbound TCP/IP connections. This would have been advantageous as discussed above, as it would allow the combined system to provide predefined rules/conditions for efficient processing of determining whether a packet is for an outbound or inbound connection.
Conclusion & Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHEL J HACKENBERG whose telephone number is (571)272-5417. 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, Glenton B Burgess can be reached on (571)272-3949. 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.
/RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454
Prosecution Insights