DETAILED ACTION
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 § 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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-4 and 15 are 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, 4, and 15 each recite the limitation "the block address". There is insufficient antecedent basis for this limitation in the claim. For the purposes of examination, the limitation is interpreted as “a block address”.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5, 7-8, 10-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bonica (US 11,245,617), hereinafter "Bonica", in view of Schug (US 2002/0091863), hereinafter "Schug".
Regarding claims 1, 13, Bonica teaches:
A WAN (wide area network) optimization method for optimizing traffic flows through a WAN that connects a plurality of sites, each of which has at least one router (see Bonica, Fig. 3, col. 12, lines 35-42: Network 330 includes one or more wired and/or wireless networks. For example, network 330 may include a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network, such as a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), and see col. 12, lines 7-14: Node 320 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a payload packet, a file, etc.) in a manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like), or a non-transitory machine readable medium storing a WAN (wide area network) optimization program for execution by a set of processing units, the WAN optimization program for optimizing traffic flows through a WAN that connects a plurality of sites, each of which has at least one router (see Bonica, Claim 15: A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors of a node, cause the one or more processors), the method comprising or the WAN optimization program comprising sets of instructions for:
at a first router located at a first site: from a second router located at a second site, receiving a file in an optimized first data stream originating from a source device at the second site and destined to a destination device at the first site, the file comprising a set of segment identifiers corresponding to a set of segments stored by the first router (see Bonica, Fig. 5, col. 14, lines 42-47: FIG. 5 is a flow chart of an example process 500 for routing a payload packet through a network using a transport header that has been extended with a compressed routing header (CRH). In some implementations, one or more process blocks of FIG. 5 may be performed by a node (e.g., node 320), and see col. 14, lines 51-60: process 500 may include receiving an internet protocol (IP) payload packet that has been encapsulated using an IPv6 transport header, wherein the IPv6 transport header includes a destination IP address of the node, wherein the IPv6 transport header has been extended with a compressed routing header (CRH) of variable length, and wherein the CRH includes a list of segment identifiers (SIDs) that identify a set of nodes that the IP payload packet is to traverse while being routed through a network (block 510), and see col. 7, lines 55-63: the first intermediary node may identify a SID number at index position i in the list of SIDs. In the example shown, the SID value at segment[0] is 129. Furthermore, this allows the first intermediary node to determine the next segment by searching the segment translation table for a corresponding SID that may be stored in association with a global IP address of a next-hop node, a link-local IPv6 address of a next-hop node, and a link identifier of a link to the next-hop node, and see col. 5, lines 49-60: the first peer device may provide an IP payload packet to the first edge node. For example, the first peer device may encapsulate an IP payload packet with a payload header (e.g., an IPv4 payload header, an IPv6 payload header, an ethernet payload header, etc.). The payload header may be an IPv4 payload header, an IPv6 payload header, an ethernet payload header, or the like. The payload header may include a source IP address of the first peer device (shown as 192.179.1.11) and a destination IP address of the second peer device (shown as 192.179.2.10). In this way, the first edge node is able to receive IP an IP payload packet from the first peer device, and see col. 6, line 48-54: As shown by reference number 110, the first edge node may provide the IP payload packet that has been encapsulated to the first intermediary node. In this way, the first edge node is able to encapsulate the IP payload packet using the IPv6 transport header that has been extended with the CRH and is able to use values included in the CRH to route the IP payload packet to the next-hop in the network, and see col. 9, line 67-col. 10, line 3: the payload header may include a destination IP address for the second peer device (192.172.1.10), which may allow the second edge device to route the IP payload packet to the second peer device, and see col. 12, lines 7-14: Node 320 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a payload packet, a file, etc.) in a manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like; in this case, a first router receives from a second router a message with segment identifiers that correspond to segments in the first router);
for each particular segment identifier in the set of segment identifiers of the file, attempting to retrieve a particular segment corresponding to the particular segment identifier (see Bonica, col. 7, lines 44-63: the first intermediary node may determine a next segment for the IP payload packet. For example, the first intermediary node may determine an index i for the next segment by subtracting a remaining segments value from a total segments value. In the example shown, the total segments value indicates that there are two total segments and the remaining segments value indicates that there are two segments left. By subtracting the remaining segments value from the total segments value, the first intermediary node may determine that the index i has a value of zero. Additionally, the first intermediary node may identify a SID number at index position i in the list of SIDs. In the example shown, the SID value at segment[0] is 129. Furthermore, this allows the first intermediary node to determine the next segment by searching the segment translation table for a corresponding SID that may be stored in association with a global IP address of a next-hop node, a link-local IPv6 address of a next-hop node, and a link identifier of a link to the next-hop node; in this case, the router determines a next segment based on the segment identifier, corresponding to attempting to retrieve a particular segment corresponding to the particular segment identifier);
However, Bonica does not teach:
wherein the particular segment is retrieved from a kernel memory of the first router;
when the particular segment is not stored in the kernel memory of the first router, performing an operation to DMA (direct memory access) the particular segment into the kernel memory from a disk storage of the first router.
Schug, in the same field of endeavor, teaches:
wherein the particular segment is retrieved from a kernel memory of the first router (see Schug, par. [0097]: The memory mapping between the OS communication segment and the application communication segment is done using the mmap ( ) system call and the inca_mmap ( ) entry point. The mmap ( ) system call returns a pointer to the communication segment in the OS, which can be used by the application to set-up the user-level descriptors to the communication segment. The user and kernel network communicated data structures hold the descriptor values corresponding to the mapped memory. These descriptors occupy the same physical memory and hence any change in one descriptor value in either kernel space or user space, will be visible from the other address space. This allows for the management of the shared memory, and see par. [0106]: INCA provides complete interoperability with existing network routers, switches, communication protocols so that the network data/mapping addresses can be identified and standard network protocol messages pass through network routers and switches without being rejected; in this case, segments are stored in the kernel);
when the particular segment is not stored in the kernel memory of the first router, performing an operation to DMA (direct memory access) the particular segment into the kernel memory from a disk storage of the first router (see Schug, par. [0099]: The INCA library performs the standard (i.e., IP, TCP/UDP, XTP, etc.) protocol processing, generates the headers for the packet, and then setup the transmit descriptor to point to this buffer region. This will be detected by the kernel network data/mapping structure transmit sub-system, and the OS uses DMA or programmed I/O to transfer the data directly out of the mapped communication segment. Similarly in the case of reception, the kernel network data/mapping structure sub-system acquires a free descriptor and then copies the received data into the free buffer and updates the receive descriptor in the kernel network data/mapping structure, and see par. [0117]: Control and management of transferring network communicated data from the NIU to internal computer memory (i.e., RAM), or some other type of memory (e.g. cache, hard disk) 241, 251, are initiated when a message arrives at the computer from a network connection. The NIU hardware signals the arrival of a message, typically a hardware interrupt 242. The message arrival notification signal is received by the INCA NIU driver software 200. Upon receipt of a message arrival notification, the NIU driver takes over control of the NIU (e.g., Asynchronous Transfer Mode (ATM) network card) 240, and sets up the registers, firmware, etc., of the device to transfer the message from the device to main memory 241, 251, and see par. [0106]: INCA provides complete interoperability with existing network routers, switches, communication protocols so that the network data/mapping addresses can be identified and standard network protocol messages pass through network routers and switches without being rejected; in this case, information is initially stored on a disk before being stored in the kernel in the DMA process).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the retrieval of a segment of Bonica with the retrieval from a kernel memory and DMA if not stored of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Regarding claims 2, 14, the combination of Bonica in view of Schug teaches the method or non-transitory machine readable medium. Bonica further teaches:
wherein when the segment is in the kernel memory, the method further comprises:
retrieving the segment (see Bonica, Fig. 5, col. 14, lines 42-47: FIG. 5 is a flow chart of an example process 500 for routing a payload packet through a network using a transport header that has been extended with a compressed routing header (CRH). In some implementations, one or more process blocks of FIG. 5 may be performed by a node (e.g., node 320), and see col. 14, lines 51-60: process 500 may include receiving an internet protocol (IP) payload packet that has been encapsulated using an IPv6 transport header, wherein the IPv6 transport header includes a destination IP address of the node, wherein the IPv6 transport header has been extended with a compressed routing header (CRH) of variable length, and wherein the CRH includes a list of segment identifiers (SIDs) that identify a set of nodes that the IP payload packet is to traverse while being routed through a network (block 510), and see col. 7, lines 44-63: the first intermediary node may determine a next segment for the IP payload packet. For example, the first intermediary node may determine an index i for the next segment by subtracting a remaining segments value from a total segments value. In the example shown, the total segments value indicates that there are two total segments and the remaining segments value indicates that there are two segments left. By subtracting the remaining segments value from the total segments value, the first intermediary node may determine that the index i has a value of zero. Additionally, the first intermediary node may identify a SID number at index position i in the list of SIDs. In the example shown, the SID value at segment[0] is 129. Furthermore, this allows the first intermediary node to determine the next segment by searching the segment translation table for a corresponding SID that may be stored in association with a global IP address of a next-hop node, a link-local IPv6 address of a next-hop node, and a link identifier of a link to the next-hop node; in this case); and
sending the retrieved segment to the destination device (see Bonica, col. 6, line 48-54: As shown by reference number 110, the first edge node may provide the IP payload packet that has been encapsulated to the first intermediary node. In this way, the first edge node is able to encapsulate the IP payload packet using the IPv6 transport header that has been extended with the CRH and is able to use values included in the CRH to route the IP payload packet to the next-hop in the network, and see col. 7, line 64-col. 8, line 9: As shown by reference number 120, the first intermediary node may update the destination IP address of the IP payload packet and the remaining segments value. For example, the first intermediary node may translate the destination IP address with a global IP address or a link-local IPv6 address of the next-hop node. In this case, the first intermediary node may translate the destination IP address with the global IP address if the remaining segments value is one (or another value that indicates that a next segment is a final segment) or may replace the destination IP address with the link-local IPv6 address if the remaining segments value is greater than one (or another value that indicates that the next segment is not the final segment), and see col. 9, line 67-col. 10, line 3: the payload header may include a destination IP address for the second peer device (192.172.1.10), which may allow the second edge device to route the IP payload packet to the second peer device).
Bonica does not teach, but Schug teaches:
retrieving the segment from the kernel memory (see Schug, par. [0097]: The memory mapping between the OS communication segment and the application communication segment is done using the mmap ( ) system call and the inca_mmap ( ) entry point. The mmap ( ) system call returns a pointer to the communication segment in the OS, which can be used by the application to set-up the user-level descriptors to the communication segment. The user and kernel network communicated data structures hold the descriptor values corresponding to the mapped memory. These descriptors occupy the same physical memory and hence any change in one descriptor value in either kernel space or user space, will be visible from the other address space. This allows for the management of the shared memory, and see par. [0106]: INCA provides complete interoperability with existing network routers, switches, communication protocols so that the network data/mapping addresses can be identified and standard network protocol messages pass through network routers and switches without being rejected; in this case, segments are stored in the kernel)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the retrieval of a segment of Bonica with the retrieval from a kernel memory of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Regarding claim 3, the combination of Bonica in view of Schug teaches the method. Bonica further teaches:
wherein attempting to retrieve the particular segment from the kernel memory comprises using the particular segment identifier to perform a lookup the first router to identify an entry for the particular segment, wherein the entry comprises (i) the segment identifier (see Bonica, Fig. 5, col. 14, lines 42-47: FIG. 5 is a flow chart of an example process 500 for routing a payload packet through a network using a transport header that has been extended with a compressed routing header (CRH). In some implementations, one or more process blocks of FIG. 5 may be performed by a node (e.g., node 320), and see col. 14, lines 51-60: process 500 may include receiving an internet protocol (IP) payload packet that has been encapsulated using an IPv6 transport header, wherein the IPv6 transport header includes a destination IP address of the node, wherein the IPv6 transport header has been extended with a compressed routing header (CRH) of variable length, and wherein the CRH includes a list of segment identifiers (SIDs) that identify a set of nodes that the IP payload packet is to traverse while being routed through a network (block 510, and see col. 7, lines 44-63: the first intermediary node may determine a next segment for the IP payload packet. For example, the first intermediary node may determine an index i for the next segment by subtracting a remaining segments value from a total segments value. In the example shown, the total segments value indicates that there are two total segments and the remaining segments value indicates that there are two segments left. By subtracting the remaining segments value from the total segments value, the first intermediary node may determine that the index i has a value of zero. Additionally, the first intermediary node may identify a SID number at index position i in the list of SIDs. In the example shown, the SID value at segment[0] is 129. Furthermore, this allows the first intermediary node to determine the next segment by searching the segment translation table for a corresponding SID that may be stored in association with a global IP address of a next-hop node, a link-local IPv6 address of a next-hop node, and a link identifier of a link to the next-hop node),
Bonica does not teach, but Schug teaches:
perform a lookup in a cache of the first router to identify an entry in the cache for the particular segment, wherein the entry comprises (ii) the block address of the particular segment, and (iii) an indicator value that indicates whether the particular segment is stored in the kernel memory (see Schug, par. [0097]: The memory mapping between the OS communication segment and the application communication segment is done using the mmap ( ) system call and the inca_mmap ( ) entry point. The mmap ( ) system call returns a pointer to the communication segment in the OS, which can be used by the application to set-up the user-level descriptors to the communication segment. The user and kernel network communicated data structures hold the descriptor values corresponding to the mapped memory. These descriptors occupy the same physical memory and hence any change in one descriptor value in either kernel space or user space, will be visible from the other address space. This allows for the management of the shared memory. The hostmembase member of the kernel network communicated data structure contains the aligned base address of the mapped memory. The buffer_area member of the user and the kernel network communicated data structures contain the base address of the free communication buffers, available for receive and transmission of data. The mmap ( ) system call returns the pointer to the kernel communication segment pointed to by the hostmembase member, and see par. [0098]: The application can then construct the mapping descriptor values from this base address. The user network data/mapping structure is used to manage the communication segment from the application address space. The user network data/mapping structure contains pointers to the receive, transmit and free buffers and they are used to manipulate the communication segment from the application. These descriptors are synchronized with the kernel network data/mapping structure of the communication segment; in this case, looking up is performed using addresses and free buffers correspond to an indicator of whether a segment is stored).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the lookup and entry of Bonica with the lookup in a cache and entry comprising a block address and indicator of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Regarding claim 4, the combination of Bonica in view of Schug teaches the method.
Bonica does not teach, but Schug teaches:
wherein performing the operation to DMA the segment into the kernel memory from the disk storage comprises using the block address to locate the segment in the disk storage in order to perform the operation to DMA the segment into the kernel memory from the disk storage (see Schug, par. [0099]: The INCA library performs the standard (i.e., IP, TCP/UDP, XTP, etc.) protocol processing, generates the headers for the packet, and then setup the transmit descriptor to point to this buffer region. This will be detected by the kernel network data/mapping structure transmit sub-system, and the OS uses DMA or programmed I/O to transfer the data directly out of the mapped communication segment. Similarly in the case of reception, the kernel network data/mapping structure sub-system acquires a free descriptor and then copies the received data into the free buffer and updates the receive descriptor in the kernel network data/mapping structure, and see par. [0100]: The buffers are identified and managed with respect to the base buffer_area member in the user (application) and OS (kernel) network data/mapping structures. The buffer_area contains the base pointer to the communication segment and all the other members hold values, which are offsets from this base address. All the addresses that these communication descriptors can hold are within the communication segment address space, and see par. [0117]: Control and management of transferring network communicated data from the NIU to internal computer memory (i.e., RAM), or some other type of memory (e.g. cache, hard disk) 241, 251, are initiated when a message arrives at the computer from a network connection. The NIU hardware signals the arrival of a message, typically a hardware interrupt 242. The message arrival notification signal is received by the INCA NIU driver software 200. Upon receipt of a message arrival notification, the NIU driver takes over control of the NIU (e.g., Asynchronous Transfer Mode (ATM) network card) 240, and sets up the registers, firmware, etc., of the device to transfer the message from the device to main memory 241, 251, and see par. [0106]: INCA provides complete interoperability with existing network routers, switches, communication protocols so that the network data/mapping addresses can be identified and standard network protocol messages pass through network routers and switches without being rejected).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Bonica with the DMA using block address of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Regarding claims 5, 16, the combination of Bonica in view of Schug teaches the method or non-transitory machine readable medium. Bonica further teaches:
further comprising:
for each particular segment identifier in the set of segment identifiers, replacing the particular segment identifier in the file with the retrieved particular segment to generate a reconstructed file (see Bonica, Fig. 1E, col. 7, lines 44-63: in FIG. 1E, and by reference number 118, the first intermediary node may determine a next segment for the IP payload packet. For example, the first intermediary node may determine an index i for the next segment by subtracting a remaining segments value from a total segments value. In the example shown, the total segments value indicates that there are two total segments and the remaining segments value indicates that there are two segments left. By subtracting the remaining segments value from the total segments value, the first intermediary node may determine that the index i has a value of zero. Additionally, the first intermediary node may identify a SID number at index position i in the list of SIDs. In the example shown, the SID value at segment[0] is 129. Furthermore, this allows the first intermediary node to determine the next segment by searching the segment translation table for a corresponding SID that may be stored in association with a global IP address of a next-hop node, a link-local IPv6 address of a next-hop node, and a link identifier of a link to the next-hop node); and
sending the reconstructed file to the destination device at the first site (see Bonica, Figs. 1F and 1H, col. 8, lines 50-52: in FIG. 1F, and by reference number 122, the first intermediary node may provide the IP payload packet that has been encapsulated to the third intermediary node, and see col. 9, line 67-col. 10, line 3: the payload header may include a destination IP address for the second peer device (192.172.1.10), which may allow the second edge device to route the IP payload packet to the second peer device).
Regarding claims 7, 18, the combination of Bonica in view of Schug teaches the method or non-transitory machine readable medium. Bonica further teaches:
wherein the file is a first file, wherein the optimized first data stream is generated by the second router after the second router receives a second file in an unoptimized second data stream from the source device (see Bonica, Fig. 1B, col. 5, lines 49-58: As shown by reference number 106, the first peer device may provide an IP payload packet to the first edge node. For example, the first peer device may encapsulate an IP payload packet with a payload header (e.g., an IPv4 payload header, an IPv6 payload header, an ethernet payload header, etc.). The payload header may be an IPv4 payload header, an IPv6 payload header, an ethernet payload header, or the like. The payload header may include a source IP address of the first peer device (shown as 192.179.1.11) and a destination IP address of the second peer device (shown as 192.179.2.10), and see Fig. 1C, col. 5, line 61-col. 6, line 1: in FIG. 1C, and by reference number 108, the first edge node may encapsulate the IP payload packet using an IPv6 transport header that has been extended using a compressed routing header (CRH). For example, the first edge node may reference the segment translation table and/or the route instructions to determine that the IP payload packet is to be encapsulated using an IPv6 transport header that has been extended with a CRH, and see col. 12, lines 7-14: Node 320 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a payload packet, a file, etc.) in a manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like; in this case, the message received by the first edge node corresponds to an unoptimized second data stream from the source device. Performing operations on this message before sending it corresponds to generating the optimized first data stream).
Regarding claims 8, 19, the combination of Bonica in view of Schug teaches the method or non-transitory machine readable medium. Bonica further teaches:
wherein the second file comprises the set of segments corresponding to the set of segment identifiers that comprise the first file, wherein the second router generates the optimized first data stream by performing a set of optimization operations on the second file (see Bonica, col. 5, line 61-col. 6, line 19: in FIG. 1C, and by reference number 108, the first edge node may encapsulate the IP payload packet using an IPv6 transport header that has been extended using a compressed routing header (CRH). For example, the first edge node may reference the segment translation table and/or the route instructions to determine that the IP payload packet is to be encapsulated using an IPv6 transport header that has been extended with a CRH. As an example, the route instructions may indicate that IP payload packets with a particular source IP address or destination IP address are to be encapsulated with an IPv6 transport header that is extended with a CRH. The CRH may include a list of SIDs that define the path for the IP payload packet, a total segments value, a remaining segments value, a compression value, a next header value, a header extension length, a routing type, and a reserved value. The list of SIDs may include a list of node-specific values that correspond to a list of SIDs included in the segment translation table. The total segments value may identify a maximum number of segments needed for the IP payload packet to reach a final-hop node (e.g., the second edge device). The remaining segments value may identify a number of remaining segments between an origin node (e.g., the node that receives the IP payload packet) and the second edge node).
Regarding claim 10, the combination of Bonica in view of Schug teaches the method. Bonica further teaches:
wherein the first router comprises a software router executing on a host computer (see Bonica, col. 12, lines 7-14: Node 320 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a payload packet, a file, etc.) in a manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like, and see col. 12, lines 19-23: node 320 may be a physical device implemented within a housing, such as a chassis. In some implementations, node 320 may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center)
Bonica does not teach, but Schug teaches:
the disk storage is a disk storage of the host computer (see Schug, par. [0049]: in FIG. 2, the present invention comprises three main software components: an INCA NIU driver 200, an IPP execution loop 201 and an API 202. These components reside inside a computer together with the current computer software components such as application programs 210, OS 220, communication protocols 230, and the current computer hardware components such as the NIU 240, system memory bus 250 and 280, memory 260, 270 and one or more CPUs, disks).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Bonica with the disk storage of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Regarding claim 11, the combination of Bonica in view of Schug teaches the method. Bonica further teaches:
wherein at least one source or one destination of WAN traffic flows execute on the host computer with the software router (see Bonica, col. 12, lines 7-14: Node 320 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a payload packet, a file, etc.) in a manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like, and see col. 12, lines 19-23: node 320 may be a physical device implemented within a housing, such as a chassis. In some implementations, node 320 may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center; in this case, a router capable of receiving, routing, and providing traffic corresponds to executing traffic flows).
Regarding claim 12, the combination of Bonica in view of Schug teaches the method. Bonica further teaches:
wherein the first router comprises a standalone appliance (see Bonica, col. 12, lines 7-14: Node 320 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a payload packet, a file, etc.) in a manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like)
Bonica does not teach, but Schug teaches:
the disk storage is a disk storage of the standalone appliance (see Schug, par. [0049]: in FIG. 2, the present invention comprises three main software components: an INCA NIU driver 200, an IPP execution loop 201 and an API 202. These components reside inside a computer together with the current computer software components such as application programs 210, OS 220, communication protocols 230, and the current computer hardware components such as the NIU 240, system memory bus 250 and 280, memory 260, 270 and one or more CPUs, disks).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Bonica with the disk storage of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Regarding claim 15, the combination of Bonica in view of Schug teaches the non-transitory machine readable medium. Bonica further teaches:
wherein:
the set of instructions for attempting to retrieve the particular segment from the kernel memory comprises a set of instructions for using the particular segment identifier to perform a lookup in the first router to identify an entry for the particular segment, the entry comprising (i) the segment identifier (see Bonica, Fig. 5, col. 14, lines 42-47: FIG. 5 is a flow chart of an example process 500 for routing a payload packet through a network using a transport header that has been extended with a compressed routing header (CRH). In some implementations, one or more process blocks of FIG. 5 may be performed by a node (e.g., node 320), and see col. 14, lines 51-60: process 500 may include receiving an internet protocol (IP) payload packet that has been encapsulated using an IPv6 transport header, wherein the IPv6 transport header includes a destination IP address of the node, wherein the IPv6 transport header has been extended with a compressed routing header (CRH) of variable length, and wherein the CRH includes a list of segment identifiers (SIDs) that identify a set of nodes that the IP payload packet is to traverse while being routed through a network (block 510, and see col. 7, lines 44-63: the first intermediary node may determine a next segment for the IP payload packet. For example, the first intermediary node may determine an index i for the next segment by subtracting a remaining segments value from a total segments value. In the example shown, the total segments value indicates that there are two total segments and the remaining segments value indicates that there are two segments left. By subtracting the remaining segments value from the total segments value, the first intermediary node may determine that the index i has a value of zero. Additionally, the first intermediary node may identify a SID number at index position i in the list of SIDs. In the example shown, the SID value at segment[0] is 129. Furthermore, this allows the first intermediary node to determine the next segment by searching the segment translation table for a corresponding SID that may be stored in association with a global IP address of a next-hop node, a link-local IPv6 address of a next-hop node, and a link identifier of a link to the next-hop node),
Bonica does not teach, but Schug teaches:
perform a lookup in a cache of the first router to identify an entry in the cache for the particular segment, wherein the entry comprises (ii) the block address of the particular segment, and (iii) an indicator value that indicates whether the particular segment is stored in the kernel memory (see Schug, par. [0097]: The memory mapping between the OS communication segment and the application communication segment is done using the mmap ( ) system call and the inca_mmap ( ) entry point. The mmap ( ) system call returns a pointer to the communication segment in the OS, which can be used by the application to set-up the user-level descriptors to the communication segment. The user and kernel network communicated data structures hold the descriptor values corresponding to the mapped memory. These descriptors occupy the same physical memory and hence any change in one descriptor value in either kernel space or user space, will be visible from the other address space. This allows for the management of the shared memory. The hostmembase member of the kernel network communicated data structure contains the aligned base address of the mapped memory. The buffer_area member of the user and the kernel network communicated data structures contain the base address of the free communication buffers, available for receive and transmission of data. The mmap ( ) system call returns the pointer to the kernel communication segment pointed to by the hostmembase member, and see par. [0098]: The application can then construct the mapping descriptor values from this base address. The user network data/mapping structure is used to manage the communication segment from the application address space. The user network data/mapping structure contains pointers to the receive, transmit and free buffers and they are used to manipulate the communication segment from the application. These descriptors are synchronized with the kernel network data/mapping structure of the communication segment; in this case, looking up is performed using addresses and free buffers correspond to an indicator of whether a segment is stored); and
the set of instructions for performing the operation to DMA the segment into the kernel memory from the disk storage comprises a set of instructions for using the block address to locate the segment in the disk storage in order to perform the operation to DMA the segment into the kernel memory from the disk storage (see Schug, par. [0099]: The INCA library performs the standard (i.e., IP, TCP/UDP, XTP, etc.) protocol processing, generates the headers for the packet, and then setup the transmit descriptor to point to this buffer region. This will be detected by the kernel network data/mapping structure transmit sub-system, and the OS uses DMA or programmed I/O to transfer the data directly out of the mapped communication segment. Similarly in the case of reception, the kernel network data/mapping structure sub-system acquires a free descriptor and then copies the received data into the free buffer and updates the receive descriptor in the kernel network data/mapping structure, and see par. [0100]: The buffers are identified and managed with respect to the base buffer_area member in the user (application) and OS (kernel) network data/mapping structures. The buffer_area contains the base pointer to the communication segment and all the other members hold values, which are offsets from this base address. All the addresses that these communication descriptors can hold are within the communication segment address space, and see par. [0117]: Control and management of transferring network communicated data from the NIU to internal computer memory (i.e., RAM), or some other type of memory (e.g. cache, hard disk) 241, 251, are initiated when a message arrives at the computer from a network connection. The NIU hardware signals the arrival of a message, typically a hardware interrupt 242. The message arrival notification signal is received by the INCA NIU driver software 200. Upon receipt of a message arrival notification, the NIU driver takes over control of the NIU (e.g., Asynchronous Transfer Mode (ATM) network card) 240, and sets up the registers, firmware, etc., of the device to transfer the message from the device to main memory 241, 251, and see par. [0106]: INCA provides complete interoperability with existing network routers, switches, communication protocols so that the network data/mapping addresses can be identified and standard network protocol messages pass through network routers and switches without being rejected).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the non-transitory machine readable medium of Bonica with the lookup in a cache and entry comprising a block address and indicator and DMA using block address of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bonica in view of Schug, as applied to claims 1-5, 7-8, 10-16, and 18-19 above, and further in view of Shalev et al. (US 10,880,204), hereinafter “Shalev”.
Regarding claims 6, 17, the combination of Bonica in view of Schug teaches the method or non-transitory machine readable medium.
Bonica does not teach, but Schug teaches:
wherein performing the operation to DMA the particular segment into the kernel memory from the disk storage of the first router comprises directing a device operating on the first router to perform the operation to DMA the particular segment into the kernel memory from the disk storage (see Schug, par. [0099]: The INCA library performs the standard (i.e., IP, TCP/UDP, XTP, etc.) protocol processing, generates the headers for the packet, and then setup the transmit descriptor to point to this buffer region. This will be detected by the kernel network data/mapping structure transmit sub-system, and the OS uses DMA or programmed I/O to transfer the data directly out of the mapped communication segment. Similarly in the case of reception, the kernel network data/mapping structure sub-system acquires a free descriptor and then copies the received data into the free buffer and updates the receive descriptor in the kernel network data/mapping structure, and see par. [0117]: Control and management of transferring network communicated data from the NIU to internal computer memory (i.e., RAM), or some other type of memory (e.g. cache, hard disk) 241, 251, are initiated when a message arrives at the computer from a network connection. The NIU hardware signals the arrival of a message, typically a hardware interrupt 242. The message arrival notification signal is received by the INCA NIU driver software 200. Upon receipt of a message arrival notification, the NIU driver takes over control of the NIU (e.g., Asynchronous Transfer Mode (ATM) network card) 240, and sets up the registers, firmware, etc., of the device to transfer the message from the device to main memory 241, 251, and see par. [0106]: INCA provides complete interoperability with existing network routers, switches, communication protocols so that the network data/mapping addresses can be identified and standard network protocol messages pass through network routers and switches without being rejected).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or non-transitory machine readable medium of Bonica with the DMA of Schug with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of increased speed of communication protocol processing (see Schug, pars. [0050-0057]).
However, the combination of Bonica in view of Schug does not teach:
directing an NVMe (non-volatile memory express) device to perform the operation to DMA the particular segment
Shalev, in the same field of endeavor, teaches:
directing an NVMe (non-volatile memory express) device to perform the operation to DMA the particular segment (see Shalev, col. 8, lines 31-33: The NVMr protocol disclosed herein may comply with the NVMf specification for creating queues, data transfer, and RDMA operations, and see col. 14, lines 58-67: At block 1110, the remote system may receive a first network transport unit from the host system, for ex