Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
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 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 6, and 7 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rocha De Maria (US 2016/0080241 A1), hereinafter Rocha.
Per claims 1 and 6, Rocha teaches “A network device comprising: a network interface hardware circuit, arranged to receive a plurality of packets sent from another network device, wherein the network interface hardware circuit comprises: (Fig.2; Abstract, The SSA may allow for a bandwidth measurement for a connection between the server and client … The test stream may be received and analyzed by a stream analyzer; ¶ [0076], stream packets transmitted by the test application to network interfaces; ¶ [0021], the system circuitry 204 may include circuitry that facilitates, as just a few examples, connecting to a speed test control server, requesting a speed test … establishing a test connection with the data server, initiating bandwidth tests with the data server, and analyzing packet streams to determine test results; ¶ [0019], In FIG. 2, the device 200 includes one or more communication interfaces 202, system circuitry 204) a counter, arranged to count the plurality of packets during a period of a network speed test, (¶ [0021], a speed test) wherein the plurality of packets comprise a plurality of first packets and a plurality of second packets; (¶ [0030], the architecture 300 partitions the bandwidth test within the same traffic flow, e.g., the UDP test packet stream. In one aspect, the traffic flow includes the test packets that determine that bandwidth of the link. The receiving device may simply count and drop the test packets without any further substantial processing; ¶ [0083], Table: Example Protocol Upstream Mode, The client device MUST count the total number of packets received) and a proactive packet dropping circuit, arranged to proactively drop the plurality of second packets among the plurality of packets during the period of the network speed test; (¶ [0030], the architecture 300 partitions the bandwidth test within the same traffic flow, e.g., the UDP test packet stream. In one aspect, the traffic flow includes the test packets that determine that bandwidth of the link. The receiving device may simply count and drop the test packets without any further substantial processing; ¶ [0038], The packet analyzer may pass special packets up the stack for processing, but update statistics and drop test packets; ¶ [0079], The packet analyzer may examine packets received from the network interfaces. The packet analyzer may drop detected test packets and responsively update test statistics) [Comment: Test packets being dropped without any further substantial processing is “proactive packet dropping,” because it is an active dropping chosen to be performed, instead of involuntary/lost dropping.] a storage device, arranged to store a program code; and a processor, arranged to load and execute the program code to perform following operation: (¶ [0084-0086], all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor … The circuitry may further include or access instructions for execution by the circuitry. The instructions may be stored in a tangible storage medium … Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and the instructions when executed by the circuitry in a device may cause the device to implement any of the processing) during the period of the network speed test, (¶ [0021], a speed test) reading packet count values of the counter that are generated at different time instants to calculate a number of received packets at the network device within a time interval between the different time instants.” (¶ [0030], the architecture 300 partitions the bandwidth test within the same traffic flow, e.g., the UDP test packet stream. In one aspect, the traffic flow includes the test packets that determine that bandwidth of the link. The receiving device may simply count and drop the test packets without any further substantial processing; ¶ [0083], TThe client device MUST count the total number of packets received … the client device MAY return to the PREPARE operation to start another burst. When the test is complete, the client device MUST send the control server “END” followed by space). [Comment: counting the total number of packets received necessarily has a time interval of the counting including a start time of the counting and an end time of the counting.]
Per claims 2 and 7, Rocha further teaches “wherein each of the plurality of packets is a user datagram protocol (UDP) packet” (¶ [0030], the UDP test packet stream; ¶ [0033], The UDP connection may carry the test data traffic flow between the client device 306 and the control server functionality of the unified server 404; ¶ [0024], The bandwidth determination may use a connectionless or stateless protocol … UDP is an example of a suitable connectionless protocol for the data traffic transfer. The architecture 300 thereby avoids the overhead of processing more complex connection-oriented protocols such as TCP and HTTP, which consume additional memory space and processing power than UDP).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claims 3 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Rocha (US 2016/0080241 A1), in view of Kerpez (WO 2022/164732 A1).
Per claims 3 and 8, although Rocha teaches UDP test packets, (¶ [0030], the UDP test packet stream; ¶ [0033], The UDP connection may carry the test data traffic flow between the client device 306 and the control server functionality of the unified server 404) however Rocha does not teach “wherein the network speed test employs a TR-471 speed test protocol.”
In analogous teaching of a UDP speed test, Kerpez teaches a UDP speed test include TR-471 (¶ [0056], invoking a User-Datagram Protocol (UDP) speed test, as defined in Broadband Forum TR-471, Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements, 2020 to determine network speed).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine a TR-471 speed test of Kerpez into a speed test of Rocha. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of speed tests to yield predictable results, especially given that Kerpez and Rocha are in the same field of endeavor of UDP speed tests (KSR(A), MPEP 2143).
Claims 4 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Rocha (US 2016/0080241 A1), in view of Wolf (US 2019/0230017 A1).
Per claims 4 and 9, Rocha does not teach “wherein the network device is an optical network unit (ONU).”
In analogous teaching of a speed test, Wolf teaches an optical network unit (ONU) in a speed test (¶ [0088], it is desired to run a speed test between the OLT 1812 and the S-ONU 1822 through a WAN port. In a non-limiting example, S-ONU 1822 includes a 10 Gbps bi-directional optical subassembly (BOSA) on-board transceiver 1993 with a 10G connection to system-on-chip (SoC) 1991; ¶ [0002], where the CPE is a Service ONU (S-ONU; ONU=optical network unit).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine an ONU in a speed test of Wolf into a speed test of Rocha. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of speed tests to yield predictable results (KSR(A), MPEP 2143).
Claims 5 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Rocha (US 2016/0080241 A1), in view of Schrecke (US 2014/0328205 A1).
Per claims 5 and 10, although Rocha teaches “wherein the processor is further arranged to execute the program code to perform following operation: during the period of the network speed test ¶ [0021], the system circuitry 204 may include circuitry that facilitates, as just a few examples, connecting to a speed test control server, requesting a speed test … establishing a test connection with the data server, initiating bandwidth tests with the data server, and analyzing packet streams to determine test results … calculating a drop count (¶ [0047], Test algorithms may be configured to perform a wide range of analyses … the packet loss (e.g., a number or percentage of packets)), however Rocha does not specify how to calculate the drop count. Therefore, Rocha does not teach “using the plurality of the first packets to calculate a number of transmitted packets from the another network device within the time interval between the different time instants, and calculating a drop count according to the number of transmitted packets and the number of received packets.”
In analogous teaching of determining network metrics (Abstract, determining link characteristics of a network link), Schrecke teaches “using the plurality of the first packets to calculate a number of transmitted packets from the another network device within the time interval between the different time instants, and calculating a drop count according to the number of transmitted packets and the number of received packets” (¶ [0035], link loss is determined by dividing the number of packets received in a time interval by the number of packets sent. This can be calculated using existing data in the messages such as sequence numbers, by repurposing unused data fields in the message or by augmenting the message … the sequence number is extracted from the received packet. The total number of missing frames with respect to the number of transmitted frames provides the loss percentage. As a simplified example, using a sliding 10 second window, if messages sequenced 100 through 109 are transmitted but the receiver only receives 100 through 107 and 109, a 10% loss would result. The above processes are repeated for an interval of time in block 210. At the end of the time interval, in block 212, the invention compares the number of packets received to the number of packets expected and then determines data loss per time interval on the link through which the packets were transmitted, in block 214. For example, the invention determines the link loss by dividing the number of packets received by the receiving participating node in a time interval by the number of packets expected; claim 5, comparing a number of received network traffic packets to a number of expected network traffic packets received by the receiving network node to determine whether there is any missing packets transmitted after said previously received network traffic packet and before said network traffic packet to determine said link loss). [Comment: determining a number of expected traffic packets derived from received sequence number(s) by the receiving network device are calculating a number of transmitted packets. In the example of Schrecke above, sequence numbers 100 and 109 are received by the receiving network device, which derives10 transmitted/expected packets.]
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine calculating the number of transmitted/expected packets based on received sequence numbers and calculating a drop count based on the number of transmitted packets and the number of received packets as taught by Schrecke into calculating a drop count during a speed test as taught by Rocha. One of ordinary skill in the art would have been motivated to do so because Schrecke recognizes that it would have been advantageous to repurpose unused data fields to include sequence numbers to calculate a drop count/link loss (¶ [0035], link loss is determined by dividing the number of packets received in a time interval by the number of packets sent. This can be calculated using existing data in the messages such as sequence numbers, by repurposing unused data fields in the message or by augmenting the message. Referring to FIG. 2, the invention selects an existing traffic data packet (for example, a protocol message) and checks to see if the existing traffic packet includes a sequence number (or any other data that is unique to this packet), in block 202. If the packet does not include a sequence number, the invention adds a sequence number to the packet, in block 204) (KSR(G), TSM, MPEP 2143). Additionally, one of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of calculating a drop count to yield predictable results (KSR(A), MPEP 2143).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SHU (US 2020/0235991) discloses calculating a drop count based on the number of transmitted packets and the number of received packets (¶ [0047]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANNAH S. WANG whose telephone number is (571)272-9018. The examiner can normally be reached on Monday-Friday 9am-5pm EST.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HANNAH S WANG/Supervisory Patent Examiner, Art Unit 2631
Prosecution Insights