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 .
Status of Claims
The following claim(s) is/are pending in this office action: 17-36
The following claim(s) is/are amended: 17-19
The following claim(s) is/are new: 21-36
The following claim(s) is/are cancelled: 1-16
Claim(s) 17-36 is/are rejected. This rejection is FINAL.
Response to Arguments
Applicant’s arguments filed in the amendment filed 9/30/2025, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
Claim Rejections - 35 USC § 103
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 17-18, 22-26 and 30-34 are rejected under 35 U.S.C. 103 as being unpatentable over Eyada (US Pat. 9,762,537) in view of Nedeltchev (US Pub. 2016/0099853).
With respect to Claim 17, Eyada teaches a method comprising: receiving, at a network device, a packet sent from a user device, (A user device will be taught later. Fig. 1, column (c) 5, line (l) 38 to c6, l52; Network includes edge routers at the edge of the network, connected to security devices, and internal routers for routing through the network. C9, l28-41; network traffic is received by an edge router. The router determines a path through the network. Fig. 3; router contains both a forwarding plane comprising a forwarding component and a routing plane comprising a routing engine.)
determining a destination of the packet; (c17, l34-49; system uses the destination address or the entire five-tuple (which includes the destination address to resolve paths) of the packet or flow.)
determining, based at least in part on the security service header, that the security function to be applied to the packet; (A security service header will be taught later. c9, l29 to c10,l20; a network administrator defines policies for network traffic. The edge router identifies which security services to apply to the traffic based on the policies. C17, l34-49; security module, based on the destination address, may access policies to determine which security services apply to the traffic.)
determining whether the network device is capable of performing the security function; (c8, ln25 to c9, l57; edge routers receive information about what security services each security device can perform. They use the information to construct a table that functions as a security topology. The security topology is used to identify the path through the network. c10, l1-44; For a first flow, system determines that device 14D can perform the services. For a second flow, the system determines two services are needed and finds a device that can do both services. Assuming a single device that performs both services does not exist, the system determines two devices which each perform one of the services, such as 14B and 14C, and routes to devices 14B and C. Therefore, the system determines which devices can perform which security functions. c5, l65 to c6, l20; security devices may be separate devices or may be incorporated with the routers.)
and forwarding the packet to the destination. (c10,l1-20; after determining path, system forwards traffic according to the path. Fig. 1, c8,l60 to c9,l12 and c11,l36-52; system routes incoming traffic 22 from router 12a to router 12e so it may route the traffic out 24. It does so via routes 20a, 20b or 20c as dictated by security policies.)
But Eyada does not explicitly teach a user device.
Nedeltchev, however, does teach from a user device (Examiner notes that Eyada may render this feature obvious on its own since it discloses that end-user devices transmit data, see c1, l11-23. A person of ordinary skill would have reasonably recognized an embodiment where an end user device was the source of the incoming traffic 22 in Eyada, Fig. 1. Regardless, Examiner will cite Nedeltchev, para. 91; network elements in a network include sources. Para. 92; end user devices can be network elements.)
the packet including a security service header indicating a security function relating to a security policy associated with the packet (paras. 19-28; packets have service headers which indicate what service is to be applied to the packet based upon a desired policy for the packet flow. para. 21; service functions include firewalls or deep packet inspection, which are security functions.
adding information to the security service header of the packet regarding whether the security function was applied to the packet; (paras. 23-28; system may use a network service header which identifies the service path and which function. paras. 30-31; updating of service header such as changing the service index. Paras. 43-50, 54-57; network service header may include a timestamp portion, which includes a first timestamp indicating when the service chain began, and second timestamps made when the service node processes the packet. Therefore, the second timestamp is an indication that the service was performed.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Eyada with the user device in order to provide security on user device-generated network traffic.
With respect to Claim 18, modified Eyada teaches the method of claim 17, and Eyada also teaches further comprising: in a first instance, where the network device is capable of performing the security function, performing, by the network device, the security function, (c10, l1-44; devices apply their security services.)
And Nedeltchev also teaches wherein the information added to the security service header of the packet indicates that the security function was performed by the network device. (paras. 23-28; system may use a network service header which identifies the service path and which function. paras. 30-31; updating of service header such as changing the service index. Paras. 43-50, 54-57; network service header may include a timestamp portion, which includes a first timestamp indicating when the service chain began, and second timestamps made when the service node processes the packet. Therefore, the second timestamp is an indication that the service was performed.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 22, modified Eyada teaches the method of Claim 17, and Nedeltchev also teaches wherein the security service header includes an ordered list, the ordered list including the security function and at least one additional security function, and wherein the method further comprises: based at least in part on the security service header, determining that the function is to be applied before the at least one additional security function of the ordered is applied to the packet. (Fig. 1, paras. 20-25; SFC is an ordered list of functions to be applied to the packet. The service path identifies the path the packet takes as it goes to nodes to apply functions. Therefore the service path identifies an order of functions to be applied to the packet.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 23, modified Eyada teaches the method of Claim 22, and Eyada also teaches determining that the network device is unable to perform the at least one additional security function; (c8, ln25 to c9, l57; edge routers receive information about what security services each security device can perform. They use the information to construct a table that functions as a security topology. The security topology is used to identify the path through the network. c10, l1-44; For a first flow, system determines that device 14D can perform the services.)
And selecting a route for the packet based at least in part on the routing the packet to another network device that is able to perform the at least on additional security function. (c9, ln28 to c10, ln20; Router determines path based upon what services are needed to be applied and what devices can apply those services. To the extent that this can be construed as a claim to dynamically routing, see Eyada, c7, ln54 to c8, ln24 and c9, lns 13-58; dynamic routing based upon dynamic link property measurements. Therefore, it would have been obvious to one of ordinary skill prior to the effective filing date to dynamically reroute a packet if link goes down (c7, ln 8-18) or bandwidth is low (c9, ln. 7-24).)
With respect to Claim 24, modified Eyada teaches the method of Claim 22, and Nedeltchev also teaches wherein the ordered list was added to the security service header by the user device. (paras. 20-28; Encapsulating NSH to include path information. para. 91; network elements in a network include sources. Para. 92; end user devices can be network elements. Examiner asserts this anticipates a user device being a network element that determines and encapsulates the path, but in the event it is not it would have been obvious to one of ordinary skill to simply substitute the encapsulation functionality in the router into the user device for the predictable benefit of allowing the device to perform the initial encapsulation itself.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 25, it is substantially similar to Claim 17 and is rejected in the same manner, the same art and reasoning applying. Further, Eyada also teaches a network device comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: (c12, l56 to c13, l3; processor and hard drive.)
With respect to Claims 26, 30-32, they are substantially similar to Claims 18, 22-24, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 33, Eyada teaches a computer-implemented method comprising: receiving, at a network device, a packet sent from a user device, (A user device will be taught later. Fig. 1, column (c) 5, line (l) 38 to c6, l52; Network includes edge routers at the edge of the network, connected to security devices, and internal routers for routing through the network. C9, l28-41; network traffic is received by an edge router. The router determines a path through the network. Fig. 3; router contains both a forwarding plane comprising a forwarding component and a routing plane comprising a routing engine.)
based at least in part on the ordered list, determining a first security function to be applied to the packet; (An ordered list will be taught later. c9, l29 to c10,l20; a network administrator defines policies for network traffic. The edge router identifies which security services to apply to the traffic based on the policies. C17, l34-49; security module, based on the destination address, may access policies to determine which security services apply to the traffic.)
determining whether the network device is capable of performing the first security function; (c8, ln25 to c9, l57; edge routers receive information about what security services each security device can perform. They use the information to construct a table that functions as a security topology. The security topology is used to identify the path through the network. c10, l1-44; For a first flow, system determines that device 14D can perform the services. For a second flow, the system determines two services are needed and finds a device that can do both services. Assuming a single device that performs both services does not exist, the system determines two devices which each perform one of the services, such as 14B and 14C, and routes to devices 14B and C. Therefore, the system determines which devices can perform which security functions. c5, l65 to c6, l20; security devices may be separate devices or may be incorporated with the routers.)
determining a route for the packet based at least in part on the ordered list and whether the first security function was applied to the packet; (c9, ln28 to c10, ln20; Router determines path based upon what services are needed to be applied and what devices can apply those services. To the extent that this can be construed as a claim to dynamically routing, see Eyada, c7, ln54 to c8, ln24 and c9, lns 13-58; dynamic routing based upon dynamic link property measurements. Therefore, it would have been obvious to one of ordinary skill prior to the effective filing date to dynamically reroute a packet if link goes down (c7, ln 8-18) or bandwidth is low (c9, ln. 7-24). See also Nedeltchev, paras. 23-28; system may use a network service header which identifies the service path and which function. paras. 30-31; updating of service header such as changing the service index. Paras. 43-50, 54-57; network service header may include a timestamp portion, which includes a first timestamp indicating when the service chain began, and second timestamps made when the service node processes the packet. Therefore, the second timestamp is an indication that the service was performed.)
Nedeltchev, however, does teach from a user device (Examiner notes that Eyada may render this feature obvious on its own since it discloses that end-user devices transmit data, see c1, l11-23. A person of ordinary skill would have reasonably recognized an embodiment where an end user device was the source of the incoming traffic 22 in Eyada, Fig. 1. Regardless, Examiner will cite Nedeltchev, para. 91; network elements in a network include sources. Para. 92; end user devices can be network elements.)
the packet including a security service header that includes an ordered list of security service functions relating to a security policy associated with the packet; (paras. 19-28; packets have service headers which indicate what service is to be applied to the packet based upon a desired policy for the packet flow. Fig. 1, paras. 20-25; SFC is an ordered list of functions to be applied to the packet. The service path identifies the path the packet takes as it goes to nodes to apply functions. Therefore the service path identifies an order of functions to be applied to the packet. para. 21; service functions include firewalls or deep packet inspection, which are security functions.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Eyada with the user device in order to provide security on user device-generated network traffic.
With respect to Claim 34, modified Eyada teaches the computer-implemented method of Claim 33, and Nedeltchev also teaches wherein the ordered list was added to the security service header by the user device. (paras. 20-28; Encapsulating NSH to include path information. para. 91; network elements in a network include sources. Para. 92; end user devices can be network elements. Examiner asserts this anticipates a user device being a network element that determines and encapsulates the path, but in the event it is not it would have been obvious to one of ordinary skill to simply substitute the encapsulation functionality in the router into the user device for the predictable benefit of allowing the device to perform the initial encapsulation itself.)
The same motivation to combine as the independent claim applies here.
Claims 19-20 and 27-28 are rejected under 35 U.S.C. 103(a) as being unpatentable over Eyada (US Pat. 9,762,537) in view of Nedeltchev (US Pub. 2016/0099853), and further in view of Migault (US Pub. 2020/0314139).
With respect to Claim 19, modified Eyada teaches the method of claim 18, and Eyada also teaches and the method further comprises: routing the packet to a security service before the destination. (c10, l1-44; traffic is routed to a device that can apply the security service.)
But modified Eyada does not explicitly teach indicating a function was not performed.
Migault, however, does teach wherein, in a second instance in which the network device is not capable of performing the security function, the information added to the header of the packet indicates that the security function was not performed by the network device, (paras. 10-11, 82; system sets metadata in the NSH header to indicate whether traffic has been treated by a function or not.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Eyada with the indication that the function was not performed in order to allow downstream functions to process the traffic correctly.
With respect to Claim 20, modified Eyada teaches the method of claim 19, and Eyada also teaches further comprising: determining that the security service is able to perform the security function, wherein the routing the packet to the security service is based at least in part on the security service being capable of performing the security function. (c8, ln25 to c9, l57; edge routers receive information about what security services each security device can perform. They use the information to construct a table that functions as a security topology. The security topology is used to identify the path through the network. c10, l1-44; For a first flow, system determines that device 14D can perform the services. For a second flow, the system determines two services are needed and finds a device that can do both services. Assuming a single device that performs both services does not exist, the system determines two devices which each perform one of the services, such as 14B and 14C, and routes to devices 14B and C. Therefore, the system determines which devices can perform which security functions. c5, l65 to c6, l20; security devices may be separate devices or may be incorporated with the routers.)
With respect to Claims 27-28, they are substantially similar to Claims 19-20, respectively, and are rejected in the same manner, the same art and reasoning applying.
Claims 21, 29, and 35-36 are rejected under 35 U.S.C. 103 as being unpatentable over Eyada (US Pat. 9,762,537) in view of Nedeltchev (US Pub. 2016/0099853) and further in view of Maino (US Pub. 2022/0086083).
With respect to Claim 21, modified Eyada teaches the method of claim 17, but does not explicitly teach trust scores.
Maino, however, does teach receiving a trust score for the user device; based at least in part on the trust score, determining that the security service header is trustworthy, wherein the determining that the security function is to be applied to the packet is dependent on the security service header being trustworthy. (paras. 137-141; system maintains a trust level score for every network device and policies take into account the trust level. Paras. 142-143; providing direct access on high trust or dropping the communication when there is no trust, which is performing processing based upon the trust score.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Eyada with the trust score in order to protect against security compromises. (Maino, para. 51)
With respect to Claim 29, it is substantially similar to Claim 21 and is rejected in the same manner, the same art and reasoning applying.
With respect to Claim 35, modified Eyada teaches the computer-implemented method of Claim 34, and Eyada also teaches perofrming the first security function on the packet. (c10, l1-44; devices apply their security services.)
But modified Eyada does not explicitly teach a trust score.
Maino, however, does teach receiving a trust score for the user device; in a first instance, based at least in part on the trust score, determining that the security service header is trustworthy; (paras. 137-141; system maintains a trust level score for every network device and policies take into account the trust level. Paras. 142-143; providing direct access on high trust or dropping the communication when there is no trust, which is performing processing based upon the trust score.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Eyada with the trust score in order to protect against security compromises. (Maino, para. 51)
With respect to Claim 36, modified Eyada teaches the computer-implemented method of Claim 35, and Maino also teaches in a second instance, based at least in part on the trust score, determining that the security service header is not trustworthy; and adding a new security service header to the packet. (paras. 137-141; system maintains a trust level score for every network device and policies take into account the trust level. Para. 143; redirecting a packet to a trusted element for a medium or low level of trust.)
The same motivation to combine as the parent claim applies here.
Remarks
Applicant argues at Remarks, pg. 9 that Eyada does not teach a security service header indicating a security function. Examiner cites Nedeltchev in combination with Eyada to teach the header. The new claims are taught above. All claims remain rejected.
Conclusion
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 NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. 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.
/NICHOLAS P CELANI/Examiner, Art Unit 2449