DETAILED ACTION
This communication is responsive to Application No. #18/150253 filed on January 5, 2023. Claims 1-20 are subject to examination.
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 .
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.
Claims 1-2, 8-9, and 15-16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sivaramakrishnan et.al. (US Patent No. 9571394, hereinafter, “Sivaramakrishnan”).
Regarding claim 1, Sivaramakrishnan teaches:
A computer-implemented method comprising (Sivaramakrishnan: [Column 5, lines 8-10] (5) FIG. 5 is a flowchart illustrating an example mode of operation of a computing device for processing tunnel packets …):
receiving packets to be sent over a communication network (Sivaramakrishnan: [Column 7, lines 25-28] In some aspects, the virtual router buffers and aggregates multiple tunneled packets received from the underlying physical network fabric prior to delivery to the appropriate routing instance for the packets …);
determining the packets that have a predefined traffic class (Sivaramakrishnan: [Column 7, lines 28-32] … In some examples, the virtual router aggregates multiple packets according to matching criteria that includes the virtual network identifier of the outer header as well as one or more fields of the inner header …);
combining the packets having the predefined traffic class into an aggregated packet, the aggregated packet comprising an aggregated packet header (Sivaramakrishnan: [Column 7, lines 32-42] … That is, a virtual router executing on one of servers 12 may receive inbound tunnel packets of a packet flow from switches 16 and, prior to routing the tunnel packets to a locally executing virtual machine, process the tunnel packets to construct a single, aggregate tunnel packet for forwarding to the virtual machine. That is, the virtual router may buffer multiple inbound tunnel packets and construct the single, tunnel packet in which the payloads of the multiple tunnel packets are combined into a single payload and the outer/overlay headers on the tunnel packets are removed and replaced with a single header virtual network identifier ... Fig. 1); and
transmitting the aggregated packet over the communication network (Sivaramakrishnan: [Column 7, lines 43-45] … the aggregate tunnel packet can be forwarded by the virtual router to the virtual machine as if a single inbound tunnel packet was received from the virtual network ...).
Regarding claim 8, Sivaramakrishnan teaches:
A system comprising (Sivaramakrishnan: [Column 11, lines 31-35] FIG. 3 is a block diagram illustrating a computing device that executes an example virtual router for virtual networks according to techniques described herein. Computing device 100 may represent any of servers 12 of FIGS. 1-2 or other device, such as any of TOR switches 16.):
a memory having computer readable instructions (Sivaramakrishnan: [Column 12, lines 1-9] Main memory 144 includes one or more computer-readable storage media, which may include random-access memory (RAM) such as various forms of dynamic RAM (DRAM), e.g., DDR2/DDR3 SDRAM, or static RAM (SRAM), flash memory, or any other form of fixed or removable storage medium that can be used to carry or store desired program code and program data in the form of instructions or data structures and that can be accessed by a computer …); and
a computer for executing the computer readable instructions, the computer readable instructions controlling the computer to perform operations comprising (Sivaramakrishnan: [Column 11, lines 31-35] FIG. 3 is a block diagram illustrating a computing device that executes an example virtual router for virtual networks according to techniques described herein. Computing device 100 may represent any of servers 12 of FIGS. 1-2 or other device, such as any of TOR switches 16.):
receiving packets to be sent over a communication network (Sivaramakrishnan: [Column 7, lines 25-28] In some aspects, the virtual router buffers and aggregates multiple tunneled packets received from the underlying physical network fabric prior to delivery to the appropriate routing instance for the packets …);
determining the packets that have a predefined traffic class (Sivaramakrishnan: [Column 7, lines 28-32] … In some examples, the virtual router aggregates multiple packets according to matching criteria that includes the virtual network identifier of the outer header as well as one or more fields of the inner header …);
combining the packets having the predefined traffic class into an aggregated packet, the aggregated packet comprising an aggregated packet header (Sivaramakrishnan: [Column 7, lines 32-42] … That is, a virtual router executing on one of servers 12 may receive inbound tunnel packets of a packet flow from switches 16 and, prior to routing the tunnel packets to a locally executing virtual machine, process the tunnel packets to construct a single, aggregate tunnel packet for forwarding to the virtual machine. That is, the virtual router may buffer multiple inbound tunnel packets and construct the single, tunnel packet in which the payloads of the multiple tunnel packets are combined into a single payload and the outer/overlay headers on the tunnel packets are removed and replaced with a single header virtual network identifier ... Fig. 1); and
transmitting the aggregated packet over the communication network (Sivaramakrishnan: [Column 7, lines 43-45] … the aggregate tunnel packet can be forwarded by the virtual router to the virtual machine as if a single inbound tunnel packet was received from the virtual network ...).
Regarding claim 15, Sivaramakrishnan teaches:
A computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a computer to cause the computer to perform operations comprising (Sivaramakrishnan: [Column 11, lines 31-35] FIG. 3 is a block diagram illustrating a computing device that executes an example virtual router for virtual networks according to techniques described herein. Computing device 100 may represent any of servers 12 of FIGS. 1-2 or other device, such as any of TOR switches 16 … [Column 12, lines 1-9] Main memory 144 includes one or more computer-readable storage media, which may include random-access memory (RAM) such as various forms of dynamic RAM (DRAM), e.g., DDR2/DDR3 SDRAM, or static RAM (SRAM), flash memory, or any other form of fixed or removable storage medium that can be used to carry or store desired program code and program data in the form of instructions or data structures and that can be accessed by a computer …):
receiving packets to be sent over a communication network (Sivaramakrishnan: [Column 7, lines 25-28] In some aspects, the virtual router buffers and aggregates multiple tunneled packets received from the underlying physical network fabric prior to delivery to the appropriate routing instance for the packets …);
determining the packets that have a predefined traffic class (Sivaramakrishnan: [Column 7, lines 28-32] … In some examples, the virtual router aggregates multiple packets according to matching criteria that includes the virtual network identifier of the outer header as well as one or more fields of the inner header …);
combining the packets having the predefined traffic class into an aggregated packet, the aggregated packet comprising an aggregated packet header (Sivaramakrishnan: [Column 7, lines 32-42] … That is, a virtual router executing on one of servers 12 may receive inbound tunnel packets of a packet flow from switches 16 and, prior to routing the tunnel packets to a locally executing virtual machine, process the tunnel packets to construct a single, aggregate tunnel packet for forwarding to the virtual machine. That is, the virtual router may buffer multiple inbound tunnel packets and construct the single, tunnel packet in which the payloads of the multiple tunnel packets are combined into a single payload and the outer/overlay headers on the tunnel packets are removed and replaced with a single header virtual network identifier ... Fig. 1); and
transmitting the aggregated packet over the communication network (Sivaramakrishnan: [Column 7, lines 43-45] … the aggregate tunnel packet can be forwarded by the virtual router to the virtual machine as if a single inbound tunnel packet was received from the virtual network ...).
Regarding claims 2, 9, and 16, Sivaramakrishnan discloses on the features with respect to claims 1, 8, and 15 as outlined above.
Sivaramakrishnan further teaches:
wherein the predefined traffic class is a destination (Sivaramakrishnan: [Column 2, lines 27-43] … In some examples, the virtual router provides multiple tunneled packets to GRO for aggregation by in part setting the respective virtual network identifiers and invoking the GRO routine as if the virtual network identifiers are a L2 destination address for the inner packets of the tunneled packets. In this way, the GRO routine considers each packet received from the virtual router for aggregation purposes as a non-tunneled, layer 2 packet that includes at least a L2 destination address (e.g., a destination MAC address) set to the virtual network identifier for a received tunneled packet and a layer 3 (“network”) packet that corresponds to the inner packet for the received tunneled packet. By matching according to at least L2 (“data link”) destination address and one or more header fields of the layer 3 packet, the GRO routine may aggregate multiple by merging such packets into a single, aggregate packet for delivery to the appropriate routing instance …).
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 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.
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Sivaramakrishnan in view of Kajizaki et.al. (US Patent Application Publication, 20010055317, hereinafter, “Kajizaki”).
Regarding claims 3, 10, and 17, Sivaramakrishnan discloses on the features with respect to claims 1, 8, and 15 as outlined above.
Sivaramakrishnan does not explicitly teach:
wherein the packets having the predefined traffic class are combined into the aggregated packet until a timer expires, the aggregated packet being transmitted over the communication network in response to the timer expiring.
However, in the same field of endeavor, Kajizaki teaches:
wherein the packets having the predefined traffic class are combined into the aggregated packet until a timer expires, the aggregated packet being transmitted over the communication network in response to the timer expiring (Kajizaki: [0060] … The packet to be transmitted is stored in the combining buffer created for the destination network, but before that, it is examined whether the combined size of the already stored packets and the current packet exceeds the MTU of the transmission route to the destination network (step 1204) … If the combined size does not exceed the MTU, the current packet is additionally stored in the combining buffer (step 1216). If a new combining buffer is created to start accumulating packets, an accumulation timer is started (step 1214) … [0061] When the accumulation timer has timed out, the contents of the combining buffer at that instant are combined into one packet, and the combined packet is sent to the transmit driver ... Fig. 11).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivaramakrishnan to include the features as taught by Kajizaki above in order to reduce network load. (Kajizaki, ¶ [0009]).
Regarding claims 4, 11, and 18, Sivaramakrishnan discloses on the features with respect to claims 1, 8, and 15 as outlined above.
Sivaramakrishnan does not explicitly teach:
wherein the packets having the predefined traffic class are combined into the aggregated packet until a maximum transmission unit (MTU) limit is reached for the aggregated packet, the aggregated packet being transmitted over the communication network in response to the MTU limit being reached.
However, in the same field of endeavor, Kajizaki teaches:
wherein the packets having the predefined traffic class are combined into the aggregated packet until a maximum transmission unit (MTU) limit is reached for the aggregated packet, the aggregated packet being transmitted over the communication network in response to the MTU limit being reached (Kajizaki: [0060] … The packet to be transmitted is stored in the combining buffer created for the destination network, but before that, it is examined whether the combined size of the already stored packets and the current packet exceeds the MTU of the transmission route to the destination network (step 1204); if the combined size exceeds the MTU, the already stored packets are combined into one packet and the combined packet is sent out to the transmit driver (step 1206), after which the current packet is stored in the combining buffer (step 1212) ... Fig. 11).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivaramakrishnan to include the features as taught by Kajizaki above in order to reduce network load. (Kajizaki, ¶ [0009]).
Claims 5-7, 12-14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sivaramakrishnan in view of An et.al. (US Patent Application Publication, 20110271008, hereinafter, “An”).
Regarding claims 5, 12, and 19, Sivaramakrishnan discloses on the features with respect to claims 1, 8, and 15 as outlined above.
Sivaramakrishnan does not explicitly teach:
wherein the aggregated packet header comprises offsets that delineate a location for each of the packets combined in the aggregated packet.
However, in the same field of endeavor, An teaches:
wherein the aggregated packet header comprises offsets that delineate a location for each of the packets combined in the aggregated packet (An: [0031] The example shown in FIG. 3 shows that, packet aggregator 160 determined that packets 310-330 should be aggregated and, therefore, creates aggregated packet 350. Aggregated packet 350 includes the same destination IP address A as packets 310-330, along with data X, data Y, and data Z from packets 310-330. Aggregated packet 350 also includes TCP context A, which includes the same source port identifier and destination port identifier as packets 310-330, and also includes the sequence number [to provide “offsets” into different data portions] corresponding to packet 310. For example, assuming the sequence number of packet 310 is "1" and it's data payload length is 100 bytes, then the TCP sequence number of packet 320 will be 101 (1+100 bytes). Continuing with this example, the resulting aggregated packet 350 that is built from packets 310, 320, and 330, include a sequence number of "1" (the sequence number of the first TCP packet 310) ... Fig. 3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivaramakrishnan to include the features as taught by An above in order to aggregate packets based upon a packet's target destination. (An, ¶ [0001]).
Regarding claims 6, 13, and 20, Sivaramakrishnan discloses on the features with respect to claims 1, 8, and 15 as outlined above.
Sivaramakrishnan does not explicitly teach:
wherein the aggregated packet header is configured to be utilized to individually delineate and distribute the packets combined in the aggregated packet in accordance with offsets.
However, in the same field of endeavor, An teaches:
wherein the aggregated packet header is configured to be utilized to individually delineate and distribute the packets combined in the aggregated packet in accordance with offsets (An: [0031] The example shown in FIG. 3 shows that, packet aggregator 160 determined that packets 310-330 should be aggregated and, therefore, creates aggregated packet 350. Aggregated packet 350 includes the same destination IP address A as packets 310-330, along with data X, data Y, and data Z from packets 310-330. Aggregated packet 350 also includes TCP context A, which includes the same source port identifier and destination port identifier as packets 310-330, and also includes the sequence number [to provide “offsets” into different data portions] corresponding to packet 310. For example, assuming the sequence number of packet 310 is "1" and it's data payload length is 100 bytes, then the TCP sequence number of packet 320 will be 101 (1+100 bytes). Continuing with this example, the resulting aggregated packet 350 that is built from packets 310, 320, and 330, include a sequence number of "1" (the sequence number of the first TCP packet 310) ... Fig. 3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivaramakrishnan to include the features as taught by An above in order to aggregate packets based upon a packet's target destination. (An, ¶ [0001]).
Regarding claims 7 and 14, Sivaramakrishnan discloses on the features with respect to claims 1 and 8 as outlined above.
Sivaramakrishnan does not explicitly teach:
prior to receiving the packets to be sent over the communication network, two or more of the packets have been previously aggregated by a gateway based on the predefined traffic class; and
combining the packets having the predefined traffic class into the aggregated packet comprises automatically adding the two or more of the packets in the aggregated packet based on the two or more of the packets having been previously aggregated by the gateway.
However, in the same field of endeavor, An teaches:
prior to receiving the packets to be sent over the communication network, two or more of the packets have been previously aggregated by a gateway based on the predefined traffic class (An: [0031] The example shown in FIG. 3 shows that, packet aggregator 160 determined that packets 310-330 should be aggregated and, therefore, creates aggregated packet 350. Aggregated packet 350 includes the same destination IP address A as packets 310-330, along with data X, data Y, and data Z from packets 310-330 ... Fig. 3); and
combining the packets having the predefined traffic class into the aggregated packet comprises automatically adding the two or more of the packets in the aggregated packet based on the two or more of the packets having been previously aggregated by the gateway (An: [0041] On the other hand, if the received packet's TCP context matches an in-process aggregated packet context [i.e., having predefined traffic class], decision 520 branches to "Yes" branch 522, whereupon processing adds the data included in the packet to the in-process aggregated packet at step 525 (see FIG. 3 and corresponding text for further details). A determination is made as to whether the in-process aggregated packet is full (e.g., all data slots are full) (decision 540). If the in-process aggregated packet is not full, decision 540 branches to "No" branch 542, which loops back to process another packet [i.e., multiple packets can be aggregated into a single aggregated packet]. This looping continues until one of the in-process aggregated packets are full, at which point decision 540 branches to "Yes" branch 548 whereupon processing sends the full aggregated packet for further processing at step 550 (e.g., to processing unit 170 shown in FIGS. 1 and 2). Fig. 5).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivaramakrishnan to include the features as taught by An above in order to aggregate packets based upon a packet's target destination. (An, ¶ [0001]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LIEM H NGUYEN whose telephone number is (408) 918-7636. The examiner can normally be reached on Monday-Friday, 8:30AM-5:00PM PT.
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, Noel Beharry can be reached on (571) 270-5630. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/LIEM H. NGUYEN/Primary Examiner, Art Unit 2416