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 .
Response to Arguments
Applicant's arguments filed 08/21/2025 have been fully considered.
Applicant argues that with the amendments to the claims, claim interpretation under 112f is now moot. In response to the argument, Examiner respectfully agrees. The claims are no longer interpreted under 112f.
Applicant argues that with the amendment to Claim 8, the claim objection is now moot. Examiner respectfully agrees. The claim objection is withdrawn.
Applicant argues, regarding claim 8, that Wichelman does not teach on a RST network.
In response to the argument, Examiner respectfully disagrees. Wichelman teaches on an RST network and on spectrum analyzer connected to a switch, where the switch is a radio frequency switch.
See Wichelman, Fig 1A-C, Col 6 ln 56-58, The spectrum analyzer 12 can be any suitable analyzer or test device that can monitor and retrieve spectrum information from a signal. Col 10 ln 31-37, The switch 16 can be any suitable device for connecting one of the nodes 18 to the spectrum analyzer 12 under the control of the computer 22 of the data acquisition/analysis system 14 via control connection 34. The switch 16 is a 1x32 port radio frequency (RF) switch with auxiliary test port.
NIC: The switch 16 has a 1x32 port with auxiliary test port.
RST network: The monitoring system 10' includes a spectrum analyzer 12, a data acquisition/analysis system 14, and a switch 16. The data acquisition/analysis system 14 controls the spectrum analyzer 12 and the switch 16 to retrieve signal data from signals on one or more of the plurality of nodes 18. The spectrum analyzer 12 can be any suitable analyzer or test device that can monitor and retrieve spectrum information from a signal.
Applicant argues, regarding claim 8, that the switch is not controlled outside the computer's OS by a separate API.
In response to the argument, Examiner respectfully disagrees.
The switch in Wichelman is controlled by computer 22 which utilizes a separate control process software that utilizes a separate software GUI. The computer 22 is connected remotely via control connection 34 (see Fig 1B). Wichelman teaches that this software is preferably executed on Windows NT OS. The controlling software is not part of the OS.
See Wichelman, Col ln 21-29, The local computer 22 executes a control process software 26 (server process), implemented in software, that controls the spectrum analyzer 12 and the switch 16. Preferably, the control process software 26 is stored in a memory(ies) (not shown, for simplicity) associated with the computer 22 and is executed by a suitable processor (not shown) associated therewith. In the preferred embodiment, the source code of the control process software 26 is written in C+ programming language and is executed on a Windows NT operating system (O/S).
Applicant argues, regarding claim 9, that Wichelman does not teach on a test stream.
In response to the argument, Examiner respectfully disagrees. Wichelman teaches on a GUI which allows the user to choose a test stream.
See Wichelman, Col 23 ln 57-65, At block 110 of FIG. 5A, the GUI software 32 enables the user to select which whole node test plan 64 to utilize. Col 24 ln 21-24, FIG. 5B, at block 116, the GUI software 32 enables the user to select a test plan 64 from a preexisting test plans list, which is retrieved by the control process software 26 from the database 28. At block 110 of FIG. 5A, the GUI software 32 enables the user to select which whole node test plan 64 to utilize, for example, the spectrum scan test 64a or the total node power test 64b. This is essentially the test that is run on the entire return path spectrum. If the user does not enter a particular whole node test plan 64, then the GUI software 32 or control process software 26 will select a default whole node test plan 64 that is predefined.
Applicant argues, regarding Claim 10, 11 that Wichelman does not teach receiving from the user a plurality of characteristics of a new test stream and building and adding the new test stream to a library.
In response to the argument, Examiner respectfully disagrees. Wichelman teaches on a GUI that allows a user to select, modify and save or cancel a newly created test plan.
See Wichelman, Col 25 ln 27-35, At block 129 of FIG. 7A, the GUI software 32 enables the user to specify performance of the spectrum scan test 64a, and a determination is made by the GUI software 32 as to whether the spectrum scan test 64a is enabled by the user. If so, then the GUI software 32 allows the user to enable or disable alarms and set alarm limits, as indicated at block 130. If not, then process flow reverts to block 131. At denoted at block 131, the GUI software 32 enables the user to specify performance of the total node power test 64b, and a determination is made by the GUI software 32 as to whether the total node power test 64b is enabled by the user. If so, then the GUI software 32 enables the user to enable or disable alarms and set alarm limits as denoted at block 132. If not, then process flow reverts to 133, where the GUI software 32 enables the user to save or cancel the aforementioned data.
Applicant argues, regarding Claim 1, that Klotz does not teach on an RST network, a NIC, analyzing RF networks, processing Ethernet packets on RF networks, and on the need “for strict separation between the OS used to control the GUI and the specialized API used to control the signal processing function of the analysis device”.
In response to the argument, Examiner respectfully disagrees.
A. Klotz teaches on an RST network, a NIC, and analyzing RF networks.
See Klotz, [0004] The communication medium between the stations may be wired, such as coaxial, twisted pair, or fiber optic cable, or a wireless communications medium, such as cellular or radio frequency (RF) transmission systems. [0036] FIG. 2, The metrics manager 203 generally handles the interaction with the GUI 202 and retrieves the metrics from the appropriate protocol experts 204, which may, for example, be a FC expert, a SCSI expert, … The interface between the metrics manager and the protocol experts is configured such that additional experts for other protocols may be easily added. [0089] The software also includes the ability to receive input from multiple analyzers allowing for highly time synchronized (sub-nanosecond) analysis across multiple ports or connections within the network. Performance measurements can be plotted in Graph View from multiple data points simultaneously, allowing for analysis of rates and behaviors and direct correlation between cause and effect on performance between ports. [0030] The SANMetrics analysis package is specifically configured as an analysis tool for FC, GigE, TCP, IP, iSCSI, FCIP, FCP-SCSI and Small Computer System Interface (SCSI) traffic. [0096] In order to capture and analyze accurate statistics for a component in a switched fabric environment, the user should generally place the analyzer on that component. In a switched fabric environment involving F Port and N Port components, the FC protocol runs as a "point-to-point" protocol.
B. Klotz teaches on an application programming interface (API) for controlling the RST NIC and managing the processor, wherein the API manages packet processing outside of the OS; and a software program compatible with the API for composing and parsing Ethernet packets.
See Klotz, [0030] The SANMetrics analysis package is specifically configured as an analysis tool for FC, GigE, TCP, IP, iSCSI, FCIP, FCP-SCSI and Small Computer System Interface (SCSI) traffic. [0031] In operation, the SANMetrics analysis package receives input from trace files, which may be saved data from a previous analyzer captures or tapped directly from trace buffers or other data sources. The trace files, which may come from various FC topologies (such as arbitrated loop, public loop, switch fabric, etc.) or Gigabit Ethernet topologies, are processed and displayed in time based graph views, topological views with an error log, or in a text based report form. [0035] The SANMetrics IO layer 103 is capable of sending and receiving data to/from a trace buffer 105 and/or a trace file 104. Further, the peer application IO layer is optionally capable of transmitting and receiving commands from the peer application 101, as well as SANMetrics trace file 104 and/or trace buffer 105.
Applicant argues, regarding Claim 2, that Klotz (as modified by Ali & Woodings) does not teach wherein the management NIC routes information for system management, and the RST NIC routes information for packet processing.
In response to the argument, Examiner respectfully disagrees. Klotz teaches wherein the management NIC routes information for system management, and the RST NIC routes information for packet processing.
See Klotz, [0035] The system architecture illustrates that the SANMetrics package 100 is capable of passing commands between itself and a peer application 101 and sending commands to the SANMetrics IO layer 103. Data is also transmitted between the SANMetrics IO layer 103 and SANMetrics 100. The SANMetrics IO layer 103 is capable of sending and receiving data to/from a trace buffer 105 and/or a trace file 104. Further, the peer application IO layer is optionally capable of transmitting and receiving commands from the peer application 101, as well as SANMetrics trace file 104 and/or trace buffer 105. [0036] The metrics manager 203 generally handles the interaction with the GUI 202 and retrieves the metrics from the appropriate protocol experts 204, which may, for example, be a FC expert, a SCSI expert, or another specific protocol expert.
Applicant argues, regarding Claim 3, that Klotz (as modified by Ali) does not teach wherein the first port and second port of the RST NIC are each configured to process Ethernet packets at a rate of 100 gigabits per second or greater.
In response to the argument, Examiner respectfully disagrees. Klotz teaches on gigabit ethernet ([0030][0031]) and multiple ports (Fig 5, [0096]). However, Klotz is silent on the RST NIC having a first port and a second port, wherein the first port and second port are each configured to process Ethernet frames at a rate of 100 gigabits per second or greater;
Ali teaches on a NIC (ie. network interface 1240) having a first port and a second port, wherein the first port and second port (ie. input ports) are each configured to process Ethernet frames at a rate of 100 gigabits per second or greater. ([0029] front-end devices 205a-205b may be configured to monitor all of the network traffic (e.g., 10 GE, 100 GE, etc.) through the links to which the respective front-end device 205a or 205b is connected. [0034) FIG. 3, a network monitoring probe within the network monitoring system of FIG. 2. Input port(s) 305 for the network monitoring probe implemented by front-end device 205 may have throughput speeds of, for example, 8, 40, or 100 gigabits per second (Gb/s) or higher. Input port(s) 305 may be coupled to network 100 and to classification engine 310, which may include DPI module 315. [0079] Computer system 1200 further includes a network interface 1240 coupled to memory/data storage and interface 1230.)
It would have been obvious to modify Klotz per Ali as it would allow the modified system greater flexibility by providing analytics support in many types of networks with varying architecture including 100 Gigabit plus high speed data networks.
Applicant argues, regarding Claim 3, that to combine Ali with Klotz is based on hindsight reasoning.
In response to the argument, Examiner respectfully disagrees. Klotz teaches using GigE and on multiple ports. As such, there is no hindsight reasoning for modifying Klotz per the teaching of Ali. It would have been obvious to include the teaches of Ali with ports processing Ethernet packets at a rate of 100 gigabits per second in Klotz with expected results of receiving and analyzing ethernet packets received through the ports.
See Klotz, [0008] Typically, a protocol analyzer is designed for use with a particular electrical communication interface protocol, such as ATA, SCSI, Ethernet, or Fiber Channel (FC). [0030] The SANMetrics analysis package is specifically configured as an analysis tool for FC, GigE, TCP, IP, iSCSI, FCIP, FCP-SCSI and Small Computer System Interface (SCSI) traffic. [0096] In order to capture and analyze accurate statistics for a component in a switched fabric environment, the user should generally place the analyzer on that component. In a switched fabric environment involving F Port and N Port components, the FC protocol runs as a "point-to-point" protocol.
Applicant argues, regarding Claim 4, that Klotz does not teach wherein the GUI includes a monitor page for displaying information relevant to one or more monitored data streams observed on the RST network, a transmit page for transmitting one or more sample streams from a library, and a receive page for performing analysis on one or more monitored data streams.
In response to the argument, Examiner respectfully disagrees. Klotz teaches wherein the GUI includes a monitor page for displaying information relevant to one or more monitored data streams observed on the RST network, a transmit page for transmitting one or more sample streams from a library, and a receive page for performing analysis on one or more monitored data streams.
See Klotz, [0064][0065] The software determines a workable scale that makes sense across the time frame of the sampled trace. To do so, the software allows a user to define the scale from a number of plot points, which the software then scales for presentation and analysis. However, this process then allows the events in the selected trace window to carry over several sample windows, which means that the software accounts for carry over in the statistics or metrics. [0066] The sample management performed by the invention provides the novel ability to produce meaningful and accurate metrics that are based upon events that are completely outside of the bounds of the analysis window. This is accomplished by the ability of SANMetrics to take a snapshot of time at the boundary edge of a sample (a plot point) and be able to recreate the exact state at that instant in time for all of the measured protocols-including events that have lingering side-effect or are long lasting and thus not “visible” at the start of the state.
Applicant argues, regarding Claim 5, that Klotz (as modified by Woodings) does not teach wherein the ethernet packets are compliant with a standard for transmitting and receiving digitized Intermediate Frequency data and metadata.
In response to the argument, Examiner respectfully disagrees. Klotz teaches wherein the Ethernet packets are compliant with a standard for transmitting and receiving RF data and metadata. Klotz is silent on the term “digitized Intermediate Frequency data”.
Klotz teaches wherein the Ethernet packets are compliant with a standard ([0106] Standard baselines) for transmitting and receiving RF data and metadata. See Klotz, [0004] The communication medium between the stations may be wired, such as coaxial, twisted pair, or fiber optic cable, or a wireless communications medium, such as cellular or radio frequency (RF) transmission systems. [0031] In operation, the SANMetrics analysis package receives input from trace files, which may be saved data from a previous analyzer captures or tapped directly from trace buffers or other data sources. The trace files, which may come from various FC topologies (such as arbitrated loop, public loop, switch fabric, etc.) or Gigabit Ethernet topologies, are processed and displayed in time based graph views, topological views with an error log, or in a text based report form. [0066] SANMetrics has the ability to take a snapshot of time at the boundary edge of a sample (a plot point) and be able to recreate the exact state at that instant in time for all of the measured protocols-including events that have lingering side-effect or are long lasting and thus not “visible” at the start of the state. [0106] Standard baselines.)
Klotz teaches on receiving radio frequency data ([0004]). However, Klotz is silent on wherein the Ethernet packets are compliant with a standard for transmitting and receiving digitized Intermediate Frequency data and metadata.
Woodings teaches on transmitting and receiving digitized Intermediate Frequency data. (Fig 3, Radio 304, The receiver and transmitter of the radio 304 may be single-conversion low-intermediate frequency (IF) architecture with 55 fully integrated IF channel matched filters to achieve high performance in the presence of interference. Abstract: The radio is suitable for detecting a frequency spectrum and the processing device is suitable for transferring detected frequency spectrum data to the connected computing device.)
It would have been obvious to modify Klotz per Woodings as it would allow the modified system greater flexibility by providing implementation of analytics support in many types of networks with varying architecture and signals.
Applicant argues, regarding Claim 6, that Klotz does not teach wherein the device determines if a device under test transmits and receives a data stream compliant with the standard.
In response to the argument, Examiner respectfully disagrees. Klotz teaches wherein the device determines if a device under test transmits and receives a data stream compliant with the standard.
See Klotz, [0083] In addition to identifying anomalous and erroneous behaviors (errors and warnings), the software package of the invention also provides a large amount of data about how the network is performing and behaving (metrics). [0084] These performance metrics are valuable in determining the errors and performance deficiencies of the network or system being tested. The software can go through the trace to see which devices were monopolizing the network resources to determine if an improper operational characteristic or network resource allocation is present. [0106] Standard baselines.
Applicant argues, regarding Claim 7, that Klotz (as modified by Gintis) does not teach a simulator for simulating a channel effect, wherein the channel effect is applied to a simulated transmission path.
In response to the argument, Examiner respectfully disagrees. Klotz teaches on tools to generate I/O loads ([0107]). However, Klotz is silent on a simulator for simulating a channel effect, wherein the channel effect is applied to a simulated transmission path.
Gintis teaches a simulator for simulating a channel effect (overloading of ports/channels), wherein the channel effect is applied to a simulated transmission path (ie. tunnel between emulated devices). ([0026][0027] The user device emulator may include functionality for simulating or emulating one or more user devices, e.g., sending communications, receiving communications, and/or testing communications capabilities of various nodes or components. For example, test platform 102 may be configured to generate control plane commands that trigger establishment of one or more tunnels for numerous emulated user devices to communicate with a packet data network, such as the Internet. [0028] Test platform 102 may include one or more port module(s) 110 which may be configured to simulate or emulate packets associated with various nodes or UEs. [0045] Test platform 102 and/or TAM 106 may perform or execute multiple instances of a test designed to overload or oversubscribe ports.)
It would have been obvious to modify Klotz per Gintis as it would allow the combined system to provide accurate and predictive test results without disturbing the live system/network.
Please see updated rejection below in view of:
Claim(s) 8-11 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 7,080,398 B1 (Wichelman).
Claim(s) 1-2, 4, 6 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2005/0060574 A1 (Klotz).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2005/0060574 A1 (Klotz) in view of US 2016/0380861 A1 (Ali).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2005/0060574 A1 (Klotz) in view of US 7,459,898 B1 (Woodings).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2005/0060574 A1 (Klotz) in view of US 2016/0373334 A1 (Gintis).
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 8-11 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 7,080,398 B1 (Wichelman).
Regarding Claim 8:
Wichelman teaches A method comprising: observing a Radio Signal Transport (RST) network with a device connected through a network interface card (NIC) (ie. auxiliary test port), wherein the NIC is operated by an application programming interface (API) that operates outside of an operating system of the device; (Fig 1A-C, Col 6 ln 56-58, The spectrum analyzer 12 can be any suitable analyzer or test device that can monitor and retrieve spectrum information from a signal. Col 10 ln 31-37, The switch 16 can be any suitable device for connecting one of the nodes 18 to the spectrum analyzer 12 under the control of the computer 22 of the data acquisition/analysis system 14 via control connection 34. The switch 16 is a 1x32 port radio frequency (RF) switch with auxiliary test port.)
receiving from a user a selected data stream from among data streams transmitted on the RST network; (Col 24 ln 21-24, FIG. 5B, at block 116, the GUI software 32 enables the user to select a test plan 64 from a preexisting test plans list, which is retrieved by the control process software 26 from the database 28.)
monitoring the selected data stream; (Col 6 ln 38-43, FIG. 1A, the monitoring system 10' includes a spectrum analyzer 12, a data acquisition/analysis system 14, and a switch 16. The data acquisition/analysis system 14 controls the spectrum analyzer 12 and the switch 16 to retrieve signal data from signals on one or more of the plurality of nodes 18.)
displaying statistics about the selected data stream including one or more of the following: a packet class, a packet count, a count of Ethernet frame bytes, a bit depth, a gap count, a lost packet count, and a sampling rate. (Col 20 ln 55-57, Burst Duration Tables, Count. Col 19 ln 23-26, The control process software 26 is configured to set the duration of the burst counter to be 30 seconds, in the preferred embodiment. The measurement result is displayed as a histogram by the GUI software 32.)
Regarding Claim 9:
Wichelman teaches on the invention of Claim 8 as described.
Wichelman teaches further comprising: receiving from the user an instruction to display a test stream page (ie. GUI opens channel plan list); (FIG. 5A, the GUI software 32 enables a user to open a channel plan list generated by the GUI software 32. The GUI software 32 provides a prompt, dialog box, display screen indicia, or some other suitable communication to the user to solicit the prescribed information from the user. The user can select a preexisting channel plan 56 to manipulate or can choose to create a new channel plan 56.)
displaying the test stream page listing one or more candidate test streams (ie. channel plan list) from a library; (Col 23 ln 43-48, As indicated at block 107, the GUI software 32 enables the user to commence a dialog for creating a new channel plan 56 for a node 18. The GUI software 32 enables the user to enter information about the channel plan 56 in blocks 108-113 and information about each channel 58 within the channel plan 56 in the looping operation denoted by blocks 114-117.)
receiving from the user a selected test stream (ie. user selects a test plan from the channel list) from the library; (Col 23 ln 57-65, At block 110 of FIG. 5A, the GUI software 32 enables the user to select which whole node test plan 64 to utilize. Col 24 ln 21-24, FIG. 5B, at block 116, the GUI software 32 enables the user to select a test plan 64 from a preexisting test plans list, which is retrieved by the control process software 26 from the database 28.)
and transmitting the selected test stream (ie. selected test) on the RST network. (Col 23 ln 57-65, At block 110 of FIG. 5A, the GUI software 32 enables the user to select which whole node test plan 64 to utilize, for example, the spectrum scan test 64a or the total node power test 64b. This is essentially the test that is run on the entire return path spectrum.)
Regarding Claim 10:
Wichelman teaches on the invention of Claim 9 as described.
Wichelman teaches further comprising: receiving from the user a plurality of characteristics of a new test stream (ie. user specifies alarm limits); (At block 129 of FIG. 7A, the GUI software 32 enables the user to specify performance of the spectrum scan test 64a, and a determination is made by the GUI software 32 as to whether the spectrum scan test 64a is enabled by the user. If so, then the GUI software 32 allows the user to enable or disable alarms and set alarm limits, as indicated at block 130. If not, then process flow reverts to block 131.)
building the new test stream based on the received characteristics; receiving from the user a command to add the new test stream to the library; and adding (ie. saving) the new test stream to the library. (Col 25 ln 27-35, At denoted at block 131, the GUI software 32 enables the user to specify performance of the total node power test 64b, and a determination is made by the GUI software 32 as to whether the total node power test 64b is enabled by the user. If so, then the GUI software 32 enables the user to enable or disable alarms and set alarm limits as denoted at block 132. If not, then process flow reverts to 133, where the GUI software 32 enables the user to save or cancel the aforementioned data.)
Regarding Claim 11:
Wichelman teaches on the invention of Claim 9 as described.
Wichelman teaches further comprising: receiving from the user an instruction to perform analytics on the selected data stream; (Col 38-39 ln 65-67, 1-10, FIG. 11E also includes the run manual test button 496. In this way, the user enters manual mode with the 301 OH spectrum analyzer already configured to perform a particular test with the same settings that were used when the test was performed when the data acquisition/analysis system 14 was in automatic test mode. In this way, the user can determine what is currently occurring on a particular node 18 or channel 56.)
displaying a signal analytics page; (Col 39 ln 15-21, FIG. 11F, shown is a node level GUI screen 440c in which the spectrum scan results tab 449 is active. The node spectrum scan 503 also includes a plot of an actual spectrum scan 506 across a particular node 189.)
receiving from the user a selected analytic chosen from among the following: a power spectrum plot, a signal power plot, a histogram plot; and displaying the selected analytic in a graphics panel. (Col 39 ln 23-27, FIG. 11F, The user may cause the frequency bands 466 to appear or disappear based on a channel plan selector 509. In this manner, the user can display the channel plan that comprises the number of frequency bands 466 and compare it with the actual spectrum scan 606 of the node itself.)
Claim(s) 1-2, 4, 6 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2005/0060574 A1 (Klotz).
Regarding Claim 1:
Klotz teaches A device, comprising: a computer processor; ([0036] FIG. 2 illustrates the SANMetrics architecture. The SANMetrics architecture is generally divided into a GUI component 202, and an engine component 201. The engine 201 consists of a metrics manager 203 and one or more protocol experts 204. The metrics manager 203 generally handles the interaction with the GUI 202 and retrieves the metrics from the appropriate protocol experts 204, which may, for example, be a FC expert, a SCSI expert. [0171] The iSCSI processor will receive the frame at 2 ms and begin processing of the frame at this time.)
a management network interface card (NIC) (ie. interface between the metrics manager and the protocol experts) controlled by an operating system (OS) (ie. SANMetrics) for connecting to a network (ie. data network, SAN); ([0031] In operation, the SANMetrics analysis package receives input from trace files, which may be saved data from a previous analyzer captures or tapped directly from trace buffers or other data sources. The trace files, which may come from various FC topologies (such as arbitrated loop, public loop, switch fabric, etc.) or Gigabit Ethernet topologies, are processed and displayed in time based graph views, topological views with an error log, or in a text based report form. [0036] FIG. 2, The metrics manager 203 generally handles the interaction with the GUI 202 and retrieves the metrics from the appropriate protocol experts 204, which may, for example, be a FC expert, a SCSI expert, … The interface between the metrics manager and the protocol experts is configured such that additional experts for other protocols may be easily added.)
a graphical user interface (GUI) (Fig 2, GUI 202) for relaying input and output through the management NIC; ([0036] FIG. 2, The metrics manager 203 generally handles the interaction with the GUI 202 and retrieves the metrics from the appropriate protocol experts 204, which may, for example, be a FC expert, a SCSI expert, … The interface between the metrics manager and the protocol experts is configured such that additional experts for other protocols may be easily added. [0089] The software also includes the ability to receive input from multiple analyzers allowing for highly time synchronized (sub-nanosecond) analysis across multiple ports or connections within the network. This allows for correlation of errors and behaviors within the trace. Performance measurements can be plotted in Graph View from multiple data points simultaneously, allowing for analysis of rates and behaviors and direct correlation between cause and effect on performance between ports.)
a Radio Signal Transport (RST) NIC for connecting to an RST network and having a first and second port (Fig 5, [0096] multiple ports); ([0008] Typically, a protocol analyzer is designed for use with a particular electrical communication interface protocol, such as ATA, SCSI, Ethernet, or Fiber Channel (FC). [0030] The SANMetrics analysis package is specifically configured as an analysis tool for FC, GigE, TCP, IP, iSCSI, FCIP, FCP-SCSI and Small Computer System Interface (SCSI) traffic. [0096] In order to capture and analyze accurate statistics for a component in a switched fabric environment, the user should generally place the analyzer on that component. In a switched fabric environment involving F Port and N Port components, the FC protocol runs as a "point-to-point" protocol.)
an application programming interface (API) for controlling the RST NIC and managing the processor, ([0030] The SANMetrics analysis package is specifically configured as an analysis tool for FC, GigE, TCP, IP, iSCSI, FCIP, FCP-SCSI and Small Computer System Interface (SCSI) traffic. [0171] The iSCSI processor will receive the frame at 2 ms and begin processing of the frame at this time.)
wherein the API manages packet processing outside of the OS; (ie. separately from SANMetrics 100). ([0035] The SANMetrics IO layer 103 is capable of sending and receiving data to/from a trace buffer 105 and/or a trace file 104. Further, the peer application IO layer is optionally capable of transmitting and receiving commands from the peer application 101, as well as SANMetrics trace file 104 and/or trace buffer 105. [0171] The iSCSI processor will receive the frame at 2 ms and begin processing of the frame at this time.)
and a software program compatible with the API for composing and parsing Ethernet packets. ([0004] The communication medium between the stations may be wired, such as coaxial, twisted pair, or fiber optic cable, or a wireless communications medium, such as cellular or radio frequency (RF) transmission systems. [0031] In operation, the SANMetrics analysis package receives input from trace files, which may be saved data from a previous analyzer captures or tapped directly from trace buffers or other data sources. The trace files, which may come from various FC topologies (such as arbitrated loop, public loop, switch fabric, etc.) or Gigabit Ethernet topologies, are processed and displayed in time based graph views, topological views with an error log, or in a text based report form. [0066] SANMetrics has the ability to take a snapshot of time at the boundary edge of a sample (a plot point) and be able to recreate the exact state at that instant in time for all of the measured protocols-including events that have lingering side-effect or are long lasting and thus not “visible” at the start of the state.)
Regarding Claim 2:
Klotz teaches on the invention of Claim 1 as described.
Klotz teaches wherein the management NIC (ie. SANMetrics 100) routes information for system management, ([0035] The system architecture illustrates that the SANMetrics package 100 is capable of passing commands between itself and a peer application 101 and sending commands to the SANMetrics IO layer 103. Data is also transmitted between the SANMetrics IO layer 103 and SANMetrics 100. [0036] The metrics manager 203 generally handles the interaction with the GUI 202 and retrieves the metrics from the appropriate protocol experts 204, which may, for example, be a FC expert, a SCSI expert, or another specific protocol expert, illustrated in FIG. 2. Depending on the type of event in the trace, the payload data for the upper level protocols may be parsed to determine if the lower level protocol experts are required for further analysis.)
and the RST NIC (ie. SANMetrics IO layer 103) routes information for packet processing. ([0035] The SANMetrics IO layer 103 is capable of sending and receiving data to/from a trace buffer 105 and/or a trace file 104. Further, the peer application IO layer is optionally capable of transmitting and receiving commands from the peer application 101, as well as SANMetrics trace file 104 and/or trace buffer 105. [0171] The iSCSI processor will receive the frame at 2 ms and begin processing of the frame at this time.)
Regarding Claim 4:
Klotz teaches on the invention of Claim 1 as described.
Klotz teaches wherein the GUI includes a monitor page for displaying information relevant to one or more monitored data streams observed on the RST network, ([0066] The sample management performed by the invention provides the novel ability to produce meaningful and accurate metrics that are based upon events that are completely outside of the bounds of the analysis window. This is accomplished by the ability of SANMetrics to take a snapshot of time at the boundary edge of a sample (a plot point) and be able to recreate the exact state at that instant in time for all of the measured protocols-including events that have lingering side-effect or are long lasting and thus not “visible” at the start of the state.)
a transmit page for transmitting one or more sample streams from a library (ie. events in selected trace window), ([0064][0065] The software determines a workable scale that makes sense across the time frame of the sampled trace. To do so, the software allows a user to define the scale from a number of plot points, which the software then scales for presentation and analysis. However, this process then allows the events in the selected trace window to carry over several sample windows, which means that the software accounts for carry over in the statistics or metrics.)
and a receive page for performing analysis on one or more monitored data streams. ([0066] The sample management performed by the invention provides the novel ability to produce meaningful and accurate metrics that are based upon events that are completely outside of the bounds of the analysis window. This is accomplished by the ability of SANMetrics to take a snapshot of time at the boundary edge of a sample (a plot point) and be able to recreate the exact state at that instant in time for all of the measured protocols-including events that have lingering side-effect or are long lasting and thus not “visible” at the start of the state.)
Regarding Claim 6:
Klotz teaches on the invention of Claim 1 as described.
Klotz teaches wherein the device determines if a device under test transmits and receives a data stream compliant with the standard. ([0083] In addition to identifying anomalous and erroneous behaviors (errors and warnings), the software package of the invention also provides a large amount of data about how the network is performing and behaving (metrics). [0084] These performance metrics are valuable in determining the errors and performance deficiencies of the network or system being tested. The software can go through the trace to see which devices were monopolizing the network resources to determine if an improper operational characteristic or network resource allocation is present. [0106] Standard baselines. [0201] Fiber Channel (FC) arbitrated loop (AL) standard.)
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) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2005/0060574 A1 (Klotz) in view of US 2016/0380861 A1 (Ali).
Regarding Claim 3:
Klotz (as modified by Ali) teaches on the invention of Claim 1 as described.
Klotz teaches a Radio Signal Transport (RST) NIC for connecting to an RST network and having a first and second port; ([0008] Typically, a protocol analyzer is designed for use with a particular electrical communication interface protocol, such as ATA, SCSI, Ethernet, or Fiber Channel (FC). [0030] The SANMetrics analysis package is specifically configured as an analysis tool for FC, GigE, TCP, IP, iSCSI, FCIP, FCP-SCSI and Small Computer System Interface (SCSI) traffic. [0096] In order to capture and analyze accurate statistics for a component in a switched fabric environment, the user should generally place the analyzer on that component. In a switched fabric environment involving F Port and N Port components, the FC protocol runs as a "point-to-point" protocol.)
Klotz teaches on gigabit ethernet ([0030][0031]) and multiple ports (Fig 5, [0096]). However, Klotz is silent on the RST NIC having a first port and a second port, wherein the first port and second port are each configured to process Ethernet frames at a rate of 100 gigabits per second or greater;
Ali teaches on a NIC (ie. network interface 1240) having a first port and a second port, wherein the first port and second port (ie. input ports) are each configured to process Ethernet frames at a rate of 100 gigabits per second or greater. ([0029] front-end devices 205a-205b may be configured to monitor all of the network traffic (e.g., 10 GE, 100 GE, etc.) through the links to which the respective front-end device 205a or 205b is connected. [0034) FIG. 3, a network monitoring probe within the network monitoring system of FIG. 2. Input port(s) 305 for the network monitoring probe implemented by front-end device 205 may have throughput speeds of, for example, 8, 40, or 100 gigabits per second (Gb/s) or higher. Input port(s) 305 may be coupled to network 100 and to classification engine 310, which may include DPI module 315. [0079] Computer system 1200 further includes a network interface 1240 coupled to memory/data storage and interface 1230.)
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 Klotz per Ali to include a NIC having a first port and a second port, wherein the first port and second port are each configured to process Ethernet frames at a rate of 100 gigabits per second or greater. This would have been advantageous as discussed above, as it would allow the modified system greater flexibility by providing analytics support in many types of networks with varying architecture including 100 Gigabit plus high speed data networks.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2005/0060574 A1 (Klotz) in view of US 7,459,898 B1 (Woodings).
Regarding Claim 5:
Klotz teaches on the invention of Claim 1 as described.
Klotz teaches wherein the Ethernet packets are compliant with a standard ([0106] Standard baselines) for transmitting and receiving RF data and metadata. ([0004] The communication medium between the stations may be wired, such as coaxial, twisted pair, or fiber optic cable, or a wireless communications medium, such as cellular or radio frequency (RF) transmission systems. [0031] In operation, the SANMetrics analysis package receives input from trace files, which may be saved data from a previous analyzer captures or tapped directly from trace buffers or other data sources. The trace files, which may come from various FC topologies (such as arbitrated loop, public loop, switch fabric, etc.) or Gigabit Ethernet topologies, are processed and displayed in time based graph views, topological views with an error log, or in a text based report form. [0066] SANMetrics has the ability to take a snapshot of time at the boundary edge of a sample (a plot point) and be able to recreate the exact state at that instant in time for all of the measured protocols-including events that have lingering side-effect or are long lasting and thus not “visible” at the start of the state. [0106] Standard baselines.)
Klotz teaches on receiving radio frequency data ([0004]). However, Klotz is silent on the term “digitized Intermediate Frequency data”. Klotz is silent on wherein the Ethernet packets are compliant with a standard for transmitting and receiving digitized Intermediate Frequency data and metadata.
Woodings teaches, in the same field of endeavor, An apparatus comprising a radio, the radio is suitable for detecting a frequency spectrum and the processing device is suitable for transferring detected frequency spectrum data to the connected computing device, Abstract.
Woodings teaches on transmitting and receiving digitized Intermediate Frequency data. (Fig 3, Radio 304, The receiver and transmitter of the radio 304 may be single-conversion low-intermediate frequency (IF) architecture with fully integrated IF channel matched filters to achieve high performance in the presence of interference. Abstract: The radio is suitable for detecting a frequency spectrum and the processing device is suitable for transferring detected frequency spectrum data to the connected computing device.)
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 Klotz per Woodings to include transmitting and receiving digitized Intermediate Frequency data. This would have been advantageous as discussed above, as it would allow the modified system greater flexibility by providing implementation of analytics support in many types of networks with varying architecture and signals.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2005/0060574 A1 (Klotz) in view of US 2016/0373334 A1 (Gintis).
Regarding Claim 7:
Klotz teaches on the invention of Claim 1 as described.
Klotz teaches on tools to generate I/O loads ([0107]). However, Klotz is silent on a simulator for simulating a channel effect, wherein the channel effect is applied to a simulated transmission path.
Gintis teaches, in the same field of endeavor, a graphical representation of a transmission path of the network flow within the network device from the ingress interface, Abstract.
Gintis also teaches a simulator for simulating a channel effect (overloading of ports/channels), wherein the channel effect is applied to a simulated transmission path (ie. tunnel between emulated devices). ([0026][0027] The user device emulator may include functionality for simulating or emulating one or more user devices, e.g., sending communications, receiving communications, and/or testing communications capabilities of various nodes or components. For example, test platform 102 may be configured to generate control plane commands that trigger establishment of one or more tunnels for numerous emulated user devices to communicate with a packet data network, such as the Internet. [0028] Test platform 102 may include one or more port module(s) 110 which may be configured to simulate or emulate packets associated with various nodes or UEs. [0045] Test platform 102 and/or TAM 106 may perform or execute multiple instances of a test designed to overload or oversubscribe ports.)
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 Klotz per Gintis to include a channel effects module for simulating one or more channel effects in a data stream. This would have been advantageous as discussed above, as it would allow the combined system to provide accurate and predictive test results without disturbing the live system/network.
Conclusion & Contact Information
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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