DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending.
The claim objection has been withdrawn in view of the claim amendment.
The 112(b) rejections have been withdrawn in view of the claim amendments.
Response to Arguments
Applicant's arguments filed on 03/16/26 have been fully considered.
In response to Applicant’s argument that Wakameda does not teach or suggest “receiving an IP packet at the kernel-space network stack” and “obtaining an ESP tunnel IP from an IPsec policy lookup of an IP of the IP packet to identify an ESP tunnel IP of an ESP tunnel” as recited by the pending claims (pages 6-7 of Remarks), Examiner acknowledged Applicant’s perspective but respectfully disagrees for the following reasons.
Wakameda discloses an IP packet comprising data, TCP, and IP header with dst HoA and src CN is received and the same IP packet is sent to the IPsec protocol processing section (e.g. ¶218-219). For at least the above reasons, Wakameda-Abraham does disclose or suggest “receiving an IP packet at the kernel-space network stack” and “obtaining an ESP tunnel IP from an IPsec policy lookup of an IP of the IP packet to identify an ESP tunnel IP of an ESP tunnel” as recited by the pending claims.
In response to Applicant’s argument that Ido does not teach or suggest “performing a route lookup for the ESP tunnel IP in the kernel-space network stack to obtain an ESP tunnel IP route that avoids a route lookup for the IP of the IP packet” as recited by the pending claims (pages 7-8 of Remarks), Examiner acknowledged Applicant’s perspective but respectfully disagrees for the following reasons.
Ido discloses pre-storing the routing information and ARP information that have been searched for and acquired (from the routing table and the ARP table respectively) in association with the tunnel SA during processing of generating and registering security parameter information and subsequently during data transmission processing, transmitting an IP packet based on the prestored routing information and ARP information without searching the routing table and ARP table (i.e. that avoids a route lookup for the IP of the IP packet) (e.g. ¶12, 31, 40, 45, 46, and 50). Thus, searching of the routing information in the routing table and ARP information in the ARP table (route lookup for the IP of the IP packet) is avoided during data transmission processing.
Note that ¶12 of Ido discloses “However, processing of searching the routing table to decide the next transfer destination of the packet, and acquiring S the MAC address of the transfer destination from the ARP table every time an IP packet is transmitted impose a heavy load. To solve this problem, there is proposed a method of temporarily storing routing information which has been searched for and acquired, and transmitting a packet based on the temporarily stored routing information without searching the routing table and ARP table every time a packet is transmitted. This method makes it possible to increase the speed of packet transmission processing, and reduce the processing load”.
Furthermore, ¶43 and 45 of Ido cited by Applicants are descriptions related to processing of generating and registering security parameter information and not during data transmission processing cited for the claimed “performing a route lookup for the ESP tunnel IP in the kernel-space network stack to obtain an ESP tunnel IP route that avoids a route lookup for the IP of the IP packet”.
For at least the above reasons, Ido-Abraham does disclose or suggest “performing a route lookup for the ESP tunnel IP in the kernel-space network stack to obtain an ESP tunnel IP route that avoids a route lookup for the IP of the IP packet” as recited by the pending claims.
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 1-20 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 pre-AIA the applicant regards as the invention.
Claim 1 recites “the ESP tunnel IP” in line 6. However, it’s unclear whether this refers to “an ESP tunnel IP” in line 4 or 5. Claims 2-11 and 18-19 that depend from claim 1 also have this issue. For examination purposes, “the ESP tunnel IP” in line 7 has been interpreted as referring to “an ESP tunnel IP” in line 4.
Claim 12 recites “the ESP tunnel IP” in line 7. However, it’s unclear whether this refers to “an ESP tunnel IP” in line 5 or 6. Claims 13-17 and 20 that depend from claim 12 also have this issue. For examination purposes, “the ESP tunnel IP” in line 6 has been interpreted as referring to “an ESP tunnel IP” in line 5.
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 of this title, 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 1 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Wakameda (US 20070186100) in view of Abraham (US 20200059459).
Claim 1, this claim is rejected for similar reasons as in claim 12.
Claim 12, Wakameda discloses A non-transitory computer-readable medium containing instructions for providing accelerated lookup for IPsec IP encapsulating security payload (ESP) tunnels in a network stack which, when executed, cause a system to perform steps comprising:
receiving an IP packet at the network stack; (e.g. figs. 19-20, ¶218-219: receiving an IP packet comprising data, TCP, and IP header with dst HoA and src CN)
obtaining an ESP tunnel IP from an IPsec policy lookup of an IP of the IP packet to identify an ESP tunnel IP of an ESP tunnel; (e.g. fig. 20, ¶220, 222: searching the SAD 19b for security association and applying the security association to add a security (ESP) header by the IPsec tunnel and a header for tunnel communication to the IP packet)
performing a route lookup for the ESP tunnel IP in the network stack that avoids a route lookup for the IP of the IP packet to obtain an ESP tunnel IP route; and (e.g. fig. 20, ¶221: using the path table 15b-1 to perform a path search)
sending an encrypted version of the IP packet across the ESP tunnel using the ESP tunnel IP route, wherein the IP packet includes an IP header that is encrypted in the encrypted version of the IP packet. (e.g. fig. 20, ¶220-221: sending the IP packet to the outside where the IP packet includes an added security header by the IPsec tunnel and an added header for tunnel communication illustrated in fig. 20)
Although Wakameda discloses a network stack (see above), Wakameda does not appear to explicitly disclose but Abraham discloses a kernel-space network stack (e.g. fig. 3D, ¶46, 65, 70-72, 76, 78, 80: kernel space 112, which is protected and generally inaccessible by user processes…The operating system kernel implements an operating system networking stack 123 in kernel space 112 as shown in FIG. 3D…operating system network stack 123 may represent a first software network stack executing in kernel space 112 while virtual router 120 may implement its own corresponding software network stack, where each network stack implements corresponding functionality for network layers (e.g., layers 1-3 of the OSI model))
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Abraham into the invention of Wakameda for the purpose of enabling IPsec processing to be perform at a kernel space thereby increasing security and flexibility of the system.
Claims 1 and 3-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ido (US 20150100784) in view of Abraham (US 20200059459).
Claim 1, this claim is rejected for similar reasons as in claim 12.
Claim 3, Ido-Abraham discloses The method of claim 1, further comprising using the accelerated lookup for instruction-set level hardware-accelerated network processing. (Ido, e.g. ¶30, 47, 89)
Claim 4, Ido-Abraham discloses The method of claim 1, further comprising using the accelerated lookup for network stack processing in a environment. (Ido, e.g. ¶27, 30)
Although Ido discloses using the accelerated lookup for network stack processing in a environment (see above), Ido does not appear to explicitly disclose but Abraham discloses a virtualized environment, the virtualized environment comprising at least one of a virtual machine and containers (e.g. fig. 3D, ¶70). Same motivation as in claim 1 would apply.
Claim 5, Ido-Abraham discloses The method of claim 1, further comprising using the accelerated lookup for distributed network stack processing. (Ido, e.g. figs. 2, 4, ¶30, 47)
Claim 6, Ido-Abraham discloses The method of claim 1, further comprising using the accelerated lookup for top-of-rack network stack processing. (Ido, e.g. ¶27, 30, 47, 89)
Claim 7, Ido-Abraham discloses The method of claim 1, wherein in the networking stack, passing data and sending the IP packet by a first user to a second user includes sending the IP packet to and through (Ido, e.g. figs. 2, 4, ¶28, 30, 47). Although Ido discloses a networking stack and passing data and sending the IP packet by a first user to a second user includes sending the packet to and through (see above), Ido does not appear to explicitly disclose but Abraham discloses a kernel-space networking stack and includes sending the packet to and through an operating system (OS) kernel (e.g. fig. 3D, ¶70-72, 78, 80). Same motivation as in claim 1 would apply.
Claim 8, Ido-Abraham discloses The method of claim 7, wherein sending the IP packet further comprises adding IP headers, performing IPsec processing on the IP packet, handing off the processed IP packet to a network interface card (NIC), and sending, by the NIC, the processed IP packet out (Ido, e.g. fig. 4, ¶33-34, 52-54). Although Ido discloses adding IP headers and performing IPsec processing on the IP packet (see above), Ido does not appear to explicitly disclose but Abraham discloses adding IP headers at the OS kernel and performing IPsec processing in the OS kernel (e.g. ¶80). Same motivation as in claim 7 would apply.
Claim 9, Ido-Abraham discloses The method of claim 1, further comprising sending the encrypted version of the IP packet to a second user host, wherein the IP packet goes to the second user host, is processed there, then to a socket interface at the second user host, then to a user space application on the second user host (Ido, e.g. ¶27-28, 38, 47). Although Ido discloses wherein the IP packet goes to the second user host and a socket interface at the second user host (see above), Ido does not appear to explicitly disclose but Abraham discloses wherein the IP packet goes to a kernel of the second user host and a socket interface at the kernel of the second user host (e.g. ¶81). Same motivation as in claim 1 would apply.
Claim 10, Ido-Abraham discloses The method of claim 1, further comprising offloading a plurality of network tasks to a user space networking stack by a user space application invoking processing by a user space networking library. (Ido, e.g. ¶30, 47, 89)
Claim 11, Ido-Abraham discloses The method of claim 1, wherein offloading is performed using a TCP offload or IPsec offload engine. (Ido, e.g. ¶28, 30, 33)
Claim 12, Ido discloses A non-transitory computer-readable medium containing instructions for providing accelerated lookup for IPsec IP encapsulating security payload (ESP) tunnels in a network stack which, when executed, cause a system to perform steps comprising:
receiving an IP packet at the network stack; (e.g. ¶47-48: a transmission request or packet to be transmitted from terminal 11 to terminal 12 via IPsec tunnel mode)
obtaining an ESP tunnel IP from an IPsec policy lookup of an IP of the IP packet to identity an ESP tunnel IP of an ESP tunnel; (e.g. figs. 3-4, ¶31-33, 40, 45, 49, 52-53: searching for a security parameter (SA) to detect a tunnel SA for IPsec encryption processing of the packet to add an IPsec tunnel mode header)
performing a route lookup for the ESP tunnel IP in the network stack that avoids a route lookup for the IP of the IP packet to obtain an ESP tunnel IP route; and (e.g. figs. 3-4, ¶12, 31, 45, 50: searching for the routing information and the ARP resolution information which have been associated with the tunnel SA and managed by the information management unit without searching the routing table and the ARP table (avoided a route lookup for the IP packet IP))
sending an encrypted version of the IP packet across the ESP tunnel using the ESP tunnel IP route, wherein the IP packet includes an IP header that is encrypted in the encrypted version of the IP packet. (e.g. fig. 4, ¶34, 52-54: transmitting the packet after IPsec tunnel processing and encapsulation processing)
Although Ido discloses a network stack (see above), Ido does not appear to explicitly disclose but Abraham discloses a kernel-space network stack (e.g. fig. 3D, ¶70-72, 78, 80: kernel space 112, which is protected and generally inaccessible by user processes…The operating system kernel implements an operating system networking stack 123 in kernel space 112 as shown in FIG. 3D…operating system network stack 123 may represent a first software network stack executing in kernel space 112 while virtual router 120 may implement its own corresponding software network stack, where each network stack implements corresponding functionality for network layers (e.g., layers 1-3 of the OSI model))
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Abraham into the invention of Ido for the purpose of enabling IPsec processing to be perform at a kernel space thereby increasing security and flexibility of the system.
Claim 13, Ido-Abraham discloses The computer-readable medium of claim 12, the instructions further comprising using the accelerated lookup for at least one of: an IPsec implementation in a kernel-space network stack, a non-IPsec implementation using GPRS Tunneling Protocol (GTP) tunnels, instruction set level, hardware/firmware-accelerated network processing, network stack processing in a virtualized environment using a virtual machine and containers, distributed network stack processing, and top-of-rack network stack processing, (Ido, e.g. figs. 2, 4, ¶27, 30, 47, 89 and Abraham, e.g. fig. 3D, ¶70-72, 78, 80). Same motivation as in claim 12 would apply.
Claim 14, Ido-Abraham discloses The computer-readable medium of claim 12, further comprising instructions which, when executed, cause the system to perform step comprising avoiding adding the IP packet IP to a routing table in the network stack (Ido, e.g. figs. 3-4, ¶12, 31, 45, 50: the IP packet IP is not added to a routing table in the network stack during data transmission processing). Although Ido discloses a networking stack (see above), Ido does not appear to explicitly disclose but Abraham discloses a kernel-space networking stack (e.g. fig. 3D, ¶70-72, 78, 80). Same motivation as in claim 1 would apply.
Claim 15, this claim is rejected for similar reasons as in claim 8.
Claim 16, this claim is rejected for similar reasons as in claim 9.
Claim 17, this claim is rejected for similar reasons as in claim 11.
Claim 18, Ido-Abraham discloses The method of claim 1, wherein the ESP tunnel terminates at a single user device. (Ido, e.g. ¶27-28, 38)
Claim 19, this claim is rejected for similar reasons as in claim 14.
Claim 20, this claim is rejected for similar reasons as in claim 18.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Ido (US 20150100784 in view of Abraham (US 20200059459) and further in view of Kant (US 20170127273).
Claim 2, Ido-Abraham discloses The method of claim 1, further comprising using the accelerated lookup for a implementation using Tunneling Protocol tunnels (Ido, e.g. ¶28) and does not appear to explicitly discloses but Kant discloses a non-IPsec implementation using GPRS Tunneling Protocol (GTP) tunnels. (e.g. ¶26)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Kant into the invention of Ido-Abraham for the purpose of securing packets using GTP, an IP-in-IP tunneling scheme (Kant, ¶26).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
RFC 4303 discloses IP encapsulating security payload (ESP).
RFC 4301 discloses Security architecture for the internet protocol.
US 7624263 discloses schematic diagrams illustrating outgoing data from TCP through tunnel mode ESP processing for IPv4 and IPv6 respectively (e.g. fig. 6c-d).
US 20140101435 discloses an arrangement for ensuring the security of data flowing on a network by applying IPsec to an IP packet (e.g. ¶23-27).
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 706.07(a). 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 extension fee 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 TRONG NGUYEN whose telephone number is (571)270-7312. The examiner can normally be reached on Monday through Thursday 9:30 AM - 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, GELAGAY SHEWAYE can be reached on (571)272-4219. 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.
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436
Prosecution Insights