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 05/14/2025 has been entered.
Response to Arguments
Applicant's arguments filed 05/14/2025 have been fully considered.
Applicant argues that Whipple does not teach on definition in the specification of “inbuilt OS-native”. Applicant filed an affidavit on 05/14/2025 to support the definition of the term “inbuilt OS-native”, under “Skepticism of Experts”. Examiner accepts the Expert’s opinion in the Affidavit Declaration filed under 37 CFR 1.132 for the definition of “inbuilt OS-native” and “OS-native”.
Although the Examiner finds the Affidavit persuasive for the definition of “inbuilt OS-native”, Examiner would like to point out that the “device representation” as taught by Whipple is executed/invoked on the particular server/device and is therefore a utility/script. Whipple is clear that the device representation utility/script is executed/invoked to create a device representation (connections, etc.) of the particular server/device and operating system on which it is executed and the data collector receives these different device representations.
Applicant argues that Whipple teaches on vendor specific formats: “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, hard-ware capabilities among other differences.” as found in Whipple (Col 10, ln 23-25).
In response to the argument, Examiner respectfully disagrees. The paragraph can be read “devices with varying operating systems”. The paragraph recited above is not inclusive of all elements listed nor does it state that the devices were provided with vendor specific utilities or scripts. However, the utility/script that is run on each particular device provides the data collector with data that is in common format so that any device (regardless of varying operating systems) may be supported.
An updated search was conducted and a prior art was discovered to read on the definition provided in the specification and in the filed Affidavit for inbuilt OS-native utility/script: US 2010/0205650 Al (Terry).
Whipple teaches on a device representation that when executed/invoked provides device connections, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches on invoking inbuilt OS-native utility to identify first TCP/IP connections; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
It would have been obvious to modify Whipple per Terry as it would allow the modified system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Please see rejection below in view of:
Claim(s) 1, 3-5, 7-8, 10-12, 14-15, 17-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 (Terry) further in view of US 2016/0127250 A1 (McCormick).
Claim(s) 2, 9, 16 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 (Terry) 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 (Terry) further in view of US 2016/0127250 A1 (McCormick) more in view of US 2016/0191672 A1 (Perlman).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3, 10, 17 recites the limitation “the first OS-native script” and “the second OS-native script” in lines 5-6. This renders the claim unclear as there is insufficient antecedent basis for this limitation in the claim. Claims 3, 10, 17 are dependent on Claims 1, 8, 15 and Claims 1, 8, 15 do not recite “a first OS-native script” and “a second OS-native script”.
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, 3-5, 7-8, 10-12, 14-15, 17-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 (Terry) 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) 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches, in the same field of endeavor, A method of monitoring all network communications, including a real-time analysis of intercepting all networked connections, Abstract.
Terry also teaches on invoking inbuilt OS-native utility to identify first TCP/IP connections; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking inbuilt OS-native utility to identify first TCP/IP connections. This would have been advantageous as it would allow the modified system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Terry) 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 Terry) 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 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) 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches on invoking inbuilt OS-native utility to identify first TCP/IP connections; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking inbuilt OS-native utility to identify first TCP/IP connections. This would have been advantageous as it would allow the modified system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Terry) 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 Terry) 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 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) 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches on invoking inbuilt OS-native utility to identify first TCP/IP connections; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking inbuilt OS-native utility to identify first TCP/IP connections. This would have been advantageous as it would allow the modified system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Terry) 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 Terry) 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 it would allow the combined system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Regarding Claims 3, 10, 17:
Whipple (as modified by Terry & McCormick) teaches the inventions of claims 1, 8, 15 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches that the first OS-native script is native to the first operating system; and the second OS-native script is native to the second operating system. ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking a inbuilt OS-native utility. This would have been advantageous as it would allow the combined system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Regarding Claims 4, 11, 18:
Whipple (as modified by Terry & 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches invoking a inbuilt OS-native utility; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking a inbuilt OS-native utility. This would have been advantageous as it would allow the modified system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Whipple teaches on mapping dependencies between nodes in a network (Col 11 ln 3-5, 40-54). Whipple (as modified by Terry) 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 Terry ) 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 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 Terry & 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches invoking a inbuilt OS-native utility; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking a inbuilt OS-native utility. This would have been advantageous as it would allow the combined system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Regarding Claims 7, 14, 21:
Whipple (as modified by Terry & 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 Terry) 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 Terry) 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 it would allow the modified system to provide in-depth analysis of connections to provide targeted/accurate analysis of connections/sessions.
Claim(s) 2, 9, 16 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 (Terry) 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 Terry & 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, etc. (Col 9 ln 62-66, Col 10 ln 3-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.
Terry teaches invoking a inbuilt OS-native utility; ([0020] FIG. 1, detailed flow diagram of an O/S utility program executing (110) as a service from the time the computer is powered-on (i.e. , booted-up) and retrieving (200) Media Access Codes (MAC) and IP addresses from the computer and performing a basic analysis of the communications configuration of the computer, analyzing (300) and securing the network shares, and reading (i.e., retrieving) (400) the TCP software update policy.)
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 Terry to include invoking a inbuilt OS-native utility. This would have been advantageous as it would allow the combined system to provide further clarification of the implementation of the device representation within the particular device, to provide all necessary details required to retrieve an accurate device representation.
Whipple teaches on parsing the first and second connections into a common representation format (Col 10 ln 34-41). However, Whipple (as modified by Terry & 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 Terry & 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 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.
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 (Terry) 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 Terry & 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 Terry & 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 a