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 1 – 21 and 34 - 40 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.
Regarding claim 1, claim limitation “controller for controller” have been interpreted under 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, because said limitations use the non-structural term “controller” coupled with functional language “for controlling” without reciting sufficient structure to achieve the function. Furthermore, the non-structural term is not preceded by a structural modifier (Note that the “switch for receiving” has not been interpreted as invoking 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, as a “switch” is not a placeholder/nonce term in line with “controller” given its well-defined status and definition in computer networking).
Since this claim limitation invokes 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, claim 1 is interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
Applicant describes the “controller” in [51] of their specification as being analogous to a “monitoring agent” (“agent” also being a non-structural term, similar to “controller”).
Though Fig. 2A of Applicant’s specification illustrate the claimed agent/controller, Applicant is reminded that if a claim function is a specific function to be performed by a special purpose computer, then the corresponding structure in the specification must be more than a mere reference to a general purpose computer, microprocessor, specialized computer, or an unidentified component of a computer system, software, logic, code or black box element. If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not wish to have the claim limitation treated under 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, applicant may amend the claim so that it will clearly not invoke 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph (e.g., by incorporating sufficient structure into the claim language to achieve the claimed functionality), or present a sufficient showing that the claim recites sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance with 35 U.S.C. § 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011). Regarding claims 2 – 21 and 34 40, said claim suffers from issues corresponding to those of claim 1.
Claims 9 – 11 and 31 – 33 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.
Regarding claim 9, said claim recites step (ab):“if said spare security protocol subsystem is already in use, editing one or more tables such that said specific security protocol subsystem that has said failed status is unreachable”.
This claim language is unclear and indefinite given the use of the terms “failed”, “already in use” and “unreachable”. The claim requires a “failed” system be “in use”, which appears inconsistent with the standard English language use of “failed”, as a service being “utilized” would not also be considered “failed” (the act of utilizing a service implies that the service has not in fact “failed”). In addition, the claim recites that the “failed” system must be checked to determine if it is ”in use”. The act performing this determination implies the service can be reached (such that the ”in use” determination can be made) and thus the service cannot be said to be “unreachable”. The non-standard, inconsistent use of these terms (“failed”, “in use”, and “unreachable”) result in an unclear claim with an indefinite scope. Regarding claims 10 and 11, said claims depend on claim 9 and fail to clarify the issues noted above.
Regarding claim 31, said claim recites limitations analogous to those in claim 9, and thus suffers from similar issues. Regarding claims 32 and 33, said claims depend on claim 31 and fail to clarify the issues noted above.
In order to perform a complete examination, the above claims have been interpreted broadly.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon (US-20210234800-A1) in view of Cooper (US-20160205071-A1).
Regarding claim 1, Sheldon shows a system for applying security protocols to packet flows passing between a pair of security zones, the system comprising:
a packet switch ([213] discussing a packet switch utilizing a group of security applications) for receiving incoming packet flows ([51-53,70] discussing handling incoming “Data flows and data packets”) from one of said pair of security zones ([67-68] discussing an enforced “boundary between two different security zones”) and for transmitting secured ([215], e.g., those packets processed by the rules of a particular security application enforcing a security zone) packet flows ([73]) to the other of said security zones, said secured packet flows being packet flows to which security protocols have been applied ([215-216]), said packet switch passing said incoming packet flows to one or more security protocol sub-systems (e.g., one of Fig. 9 items 9101 to 910T) and said packet switch receiving said secured packet flows from said one or more security protocol sub-system (Fig. 9], [213-218]);
one or more of said security protocol subsystems, each one of said one or more of said security protocol subsystems being for receiving incoming packet flows from said packet switch, said one or more security protocol subsystems applying security protocols to said incoming packet flows to result in said secured packet flows ([73]), said secured packet flows being transmitted from said one or more of said security protocol subsystems to said packet switch (Fig. 9, see the IN and OUT interfaces of the switch which are connected to multiple security application instances); and
a controller for controlling said packet switch such that a routing of incoming packet flows to said one or more security protocol subsystems is controlled by said controller ([18-19,217] discussing the load balancer and its configuration resulting in control commands sent to the switch, as well as the control functionality discussed in [213-214]),
wherein
said controller adjusts a routing (Fig. 2A) of said incoming packet flows to said one or more of said security protocol subsystems and manages said one or more of said security protocol subsystems ([214] discussing flow assignment by the SALB) by adjusting entries in tables (Fig. 9 item 908, [84,139]); and
said adjusting entries in said tables adjusts a function of said packet switch for said incoming packet flows such that all packets in a specific incoming packet flow are routed to a specific one of said one or more security protocol subsystems ([84-85,90]). Sheldon does not show where the routing tables are in said packet switch. Cooper shows routing tables are in a packet switch ([25-27]; e.g., [27] discussing “flow table(s) of the one or more SDN switches” as illustrated in Fig.1, where SDN SWITCH 102 contains FLOW TABLES 106).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and scaling techniques of Sheldon with the software defined networking, including the use of SDN switches - along with the other virtualization techniques of Cooper, in order leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network.
Claims 2, 12, 13, 18, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, as applied to claim 1 above, further in view of Bryson (US-20060056297-A1).
Regarding claim 2, Sheldon in view of Cooper show: wherein said packet switch comprises:
one or more network traffic ports (Sheldon, [194]) for receiving said incoming packet flows and for sending said secured packet flows, said at least one network traffic port being for communicating with (Sheldon, Fig. 9, [209-214]) said pair of security zones (e.g., A and Z, as shown in Sheldon’s Fig. 1C); and
one or more I/O ports for forwarding said incoming packet flows to said one or more security protocol subsystems and for receiving said secured packet flows from said one or more security protocol subsystems (Sheldon, Fig. 9, see IN and OUT and 9101 through 910T) by way of at least one virtual interface (Sheldon, Fig. 1C, [67-74]), The above combination does not show where: there is a one-to-one correspondence between said one or more I/O ports and said one or more security protocol subsystems such that each I/O port uniquely corresponds to a specific one of said one or more security protocol subsystems. Bryson shows where: there is a one-to-one correspondence between said one or more I/O ports and said one or more security protocol subsystems such that each I/O port uniquely corresponds to a specific one of said one or more security protocol subsystems (the claimed subsystems corresponding to the zones of Bryson, as discussed in [68-69, 172-173, 247]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and balancing techniques of the above combination with the port correspondence of Bryson in order to ensure reliable and consistent routing to the desired subsystems.
Regarding claim 12, the above combination further shows wherein said controller is external to said packet switch (Cooper, Fig. 1).
Regarding claim 13, the above combination further shows wherein said controller is operating on an external server in communication with said packet switch, said packet switch receiving communications from said external (Cooper, [25-26,60,64,174])) server to thereby adjust said tables as necessary (Cooper, Fig. 1, [89-100]).
Regarding claim 18, the above combination further shows wherein said controller manages security protocol subsystems (Sheldon, [18-19,217]) by periodically causing monitoring packets to be sent to said one or more of said security protocol subsystems (Sheldon, [117]).
Regarding claim 34, Sheldon in view of Cooper show claim 1. The above combination does not show wherein at least one security protocol subsystem implements a hardware firewall. Bryson shows wherein at least one security protocol subsystem implements a hardware firewall ([161]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the hardware firewall use of Bryson in order to better utilize common existing networking hardware in order to lower operating costs of the resultant disclosure.
Claims 3, 5, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Cornell (Cornell. "CS 4410: Operating Systems - 8/3 Internetworking". https://www.cs.cornell.edu/courses/cs4410/2018su/. (Year: 2018)), Cruz (US-20050172161-A1), and StackOverflow (StackOverflow. "How are MAC addresses used in routing packets?". https://stackoverflow.com/questions/23935095/how-are-mac-addresses-used-in-routing-packets. (Year: 2014)). Regarding claim 3, Sheldon in view of Cooper and Bryson show: wherein said system implements a method for determining which I/O port to send said incoming packet flows to on said packet switch, said method comprising the steps of:
(a) receiving one of said incoming packet flows, each of said incoming packet flows comprising a plurality of data packets (Sheldon, [51-53]);
wherein determining which specific I/O interface is to be used for routing said specific packet also determines which of said security protocol subsystems is to be used for applying security protocols to said specific packet (Sheldon, Fig. 3 and [213] showing each security appliance being paired with a particular I/O interface). The above combination does not show: (b) for each specific packet of said plurality of data packets,
(b1) determining an address for said specific packet based on a destination network of said specific packet;
(b2) based on said address, determining a routing path IP address for said address; Cornell shows: (b) for each specific packet of said plurality of data packets (pg. 3 lines 16-17, 25-27),
(b1) determining an address for said specific packet based on a destination network of said specific packet (ptg. 3 lines 25-27 and 43-45);
(b2) based on said address, determining a routing path IP address for said address (pg. 3 lines 37-65).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing.
The above combination does not show: use of virtual IP addresses. Cruz shows use of virtual IP addresses ([20-24]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual addressing of Cruz in order to continue to leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network
The above combination does not show: (b3) determining a MAC address for said routing path IP address;
(b4) determining a specific I/O interface that corresponds to said MAC address; and (b5) routing said specific packet to said specific I/O interface determined in step (b4) StackOverflow shows: (b3) determining a MAC address for said routing path IP address (pg.1, see the discussion provided by “jman”);
(b4) determining a specific I/O interface that corresponds to said MAC address (pg.3, see the discussion provided by “Lynn Crumbling”); and
(b5) routing said specific packet to said specific I/O interface determined in step (b4) (pg.3, see the discussion provided by “Lynn Crumbling”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the port usage discussed by StackOverflow in order to continue utilizing common networking techniques and tools (MAC addresses, interface management, etc.) in order to improve network reliability and facilitate simplified troubleshooting and maintenance.
Regarding claim 5, Sheldon in view of Cooper and Bryson show: wherein said system implements a method for determining which I/O port to send said incoming packet flows to on said packet switch, said method comprising the steps of:
(a) receiving one of said incoming packet flows, each of said incoming packet flows comprising a plurality of data packets (Sheldon, [51-53]);
wherein determining which specific I/0 interface is to be used for routing said specific packet also determines which of said security protocol subsystems is to be used for applying security protocols to said specific packet (Sheldon, Fig. 3 and [213] showing each security appliance being paired with a particular I/O interface). The above combination does not show (b) for each specific packet of said incoming packet flows, (b1) determining an address for said specific packet based on a destination network of said specific packet;
(b4) based on said address, determining a routing path IP address for said address; Cornell shows: (b) for each specific packet of said incoming packet flows (pg. 3 lines 16-17 and 25-27), (b1) determining an address for said specific packet based on a destination network of said specific packet (pg. 3 lines 25-27 and 43-45);
(b4) based on said address, determining a routing path IP address for said address (pg. 3 lines 37-65);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing.
The above combination does not show: use of virtual IP addresses,
(b2) determining a reachability of said virtual IP address;
(b3) in the event said virtual IP address is not reachable, determining an alternate virtual
IP address and using said alternate virtual IP address as said virtual IP address; Cruz shows use of virtual IP addresses ([20-24]),
(b2) determining a reachability of said virtual IP address (Figs. 7, 8 and [20-24]);
(b3) in the event said virtual IP address is not reachable, determining an alternate virtual
IP address and using said alternate virtual IP address as said virtual IP address (Figs. 7, 8 and [20-24]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual addressing of Cruz in order to continue to leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network.
The above combination does not show: (b5) determining a MAC address for said routing path IP address;
(b6) determining a specific I/O interface that corresponds to said MAC address; and (b7) routing said specific packet to said specific I/O interface determined in step b6), StackOverflow shows: (b5) determining a MAC address for said routing path IP address (pg.1, see the discussion provided by “jman”);
(b6) determining a specific I/O interface that corresponds to said MAC address (pg.3, see the discussion provided by “Lynn Crumbling”); and (b7) routing said specific packet to said specific I/O interface determined in step (b6) (pg.3, see the discussion provided by “Lynn Crumbling”),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the port usage discussed by StackOverflow in order to continue utilizing common networking techniques and tools (MAC addresses, interface management, etc.) in order to improve network reliability and facilitate simplified troubleshooting and maintenance.
Regarding claim 40, the above combination further shows wherein for step (b1), a same virtual IP address is determined for all packets in a particular incoming packet flow (Cornell, pg. 3 lines 37-65, and Cooper, [20-24]).
Claims 4 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Bryson, Cornell, Cruz, and StackOverflow, as applied to claim 5 above, further in view of Huawei (Huawei. "Why do we need consistent hashing . . .". https://support.huawei.com/enterprise/en/doc/EDOC1100086965/818af245/load-balancing-hash-algorithms. (Year: 2019)) Regarding claim 4, Sheldon in view of Cooper and Bryson, Cornell, Cruz, and StackOverflow show shows prior to step (b1), the following steps are executed:
(b1-1) determining a set of characteristics that said specific packet has in common with other packets such that said set of characteristics defines a unidirectional packet flow (Sheldon, [54,93]);
(b1-2) determining a directionally symmetric hash value from said set of characteristics (Sheldon, [93]);
wherein
said virtual IP address (Cruz, [24-27]) for said specific packet is based on said destination network of said specific packet (Cornell, pg. 3 lines 25-27 and 43-45). The above combination does not show: (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number,
basing the destination on said modulo result for said specific packet. Huawei shows (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number (pgs. 1 – 2, see answer provided by “Nancy Xiong”),
basing the destination on said modulo result for said specific packet (pgs. 1 – 2, see answer provided by “Nancy Xiong”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination in order to better control server load - and thus improve system reliability and consistency – when balancing requests between primary and backup servers.
Regarding claim 7, the above combination further shows wherein prior to step (b1), the following steps are executed:
(b1-1) determining a set of characteristics that said specific packet has in common with other packets such that said set of characteristics defines a unidirectional packet flow (Sheldon, [54,93]);
(b1-2) determining a directionally symmetric hash value from said set of characteristics (Sheldon, [93]); and
wherein
said virtual IP address (Cruz, [24-27]) for said specific packet is based on said destination network of said specific packet (Cornell, pg. 3 lines 25-27 and 43-45). The above combination does not show: (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number,
basing the destination on said modulo result for said specific packet. Huawei shows (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number (pgs. 1 – 2, see answer provided by “Nancy Xiong”),
basing the destination on said modulo result for said specific packet (pgs. 1 – 2, see answer provided by “Nancy Xiong”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination in order to better control server load - and thus improve system reliability and consistency – when balancing requests between primary and backup servers.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Bryson, Cornell, Cruz, and StackOverflow, as applied to claim 5 above, further in view of Capper (US-20200287964-A1). Regarding claim 6, Sheldon in view of Cooper and Bryson, Cornell, Cruz, and StackOverflow show use of an alternate virtual IP address (Cruz, [20-24], Figs. 7 and 8). The above combination does not show determination using resilient hashing. Capper shows determination using resilient hashing ([29-31]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the hashing of Capper in order to lower hash table churn, improving system efficiency (Capper, [31]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Farahmand (US-20110145639-A1), Bhalerao (US-10049023-B1), and Pillareddy (US-20220210113-A1).
Regarding claim 8, Sheldon in view of Cooper and Bryson show use of security protocol subsystems (Sheldon, Fig. 9, [67-68,84-85]) and with table entries (Cooper, [25-27]). The above combination does not show: (a) determining if a specific subsystem is to be designated as having a recovered status, said specific subsystem being previously determined to have failed;
(b) in the event said specific subsystem is to be designated as having said recovered status, designating said specific subsystem as a recovered subsystem; (e) in the event said recovered subsystem is not designated as a spare subsystem, adjusting at least entry to thereby restore a previously designated unreachable subsystem, to thereby designate the corresponding as a recovered subsystem. Farahmand shows (a) determining if a specific subsystem is to be designated as having a recovered status, said specific subsystem being previously determined to have failed ([52]);
(b) in the event said specific subsystem is to be designated as having said recovered status, designating said specific subsystem as a recovered subsystem ([52-52]),
(e) in the event said recovered subsystem is not designated as a spare subsystem, adjusting at least entry to thereby restore a previously designated unreachable subsystem, to thereby designate the corresponding as a recovered subsystem ([52-53]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the network management techniques of Farahmand in order to better track registrations in the network (i.e., better manage addresses) in order to improve the capability of the resultant system to handle greater numbers of clients and larger amounts of traffic (Farahmand, [5]).
The above combination does not show: (c) determining if said recovered subsystem is to be designated as a spare subsystem;
(d) in the event said recovered subsystem is to be designated as a spare subsystem, adjusting said tables such that said recovered subsystem is designated as a spare. Bhalerao shows: (c) determining if said recovered subsystem is to be designated as a spare subsystem (Fig. 6, col. 10 lines 36-50);
(d) in the event said recovered subsystem is to be designated as a spare subsystem, adjusting said tables such that said recovered subsystem is designated as a spare (Fig. 6, col. 10 lines 36-50).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the spare/failover system management of Bhalerao in order to better ensure that backup systems are utilized for their intended purpose, thus improving the reliability of the resultant system.
The above combination does not show updating (or restoring) a specific routing path specified using a virtual IP address by adjusting at least one entry to designate a MAC address corresponding to routing path. Pillareddy shows updating (or restoring) a specific routing path specified using a virtual IP address by adjusting at least one entry to designate a MAC address corresponding to routing path ([65,74,91,119-121]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual IP and MAC address management of Pillareddy in order to ensure that paired VIP and MAC addresses utilized for routing remain associated as intended, thus ensuring reliable and consistent operation of the resultant system.
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Li (Li, N. and Han, Q. English translation of CN_111903236_B_I. (Year: 2014)) and Brown (US-20080225726-A1).
Regarding claim 9, Sheldon in view of Cooper and Bryson show wherein said controller monitors a status of said one or more security protocol subsystems (Sheldon, Fig. 9, [67-68,84-85]) and, when said controller initially determines that a specific security protocol subsystem has a particular status, said controller executes steps (Sheldon, [19-20]) including editing of one or more tables (Cooper, [27,29-46,66]) The above combination does not show: consideration of a failed status, (aa) determining if a spare security protocol subsystem is already in use;
(ab) if said spare security protocol subsystem is available, editing one or more tables such that said specific subsystem that has said failed status;
(ac) if said spare subsystem is not available, editing one or more tables such that said spare subsystem is used by said system in place of said specific security protocol subsystem that has said failed status. Li shows: consideration of a failed status (pg. 5 lines 35-53), (aa) determining if a spare security protocol subsystem is already in use (pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55);
(ab) if said spare security protocol subsystem is available, editing one or more tables such that said specific subsystem that has said failed status (pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55);
(ac) if said spare subsystem is not available, editing one or more tables such that said spare subsystem is used by said system in place of said specific security protocol subsystem that has said failed status (pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the failover management techniques of Li in order to further improve network reliability by ensuring device status is accurately tracked.
The above combination does not show consideration of if a spare system is already in use, and if so, editing the status to reflect the failed system is unreachable. Brown shows: consideration of if a spare system is already in use, and if so, editing the status to reflect the failed system is unreachable ([30-33]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the failover management of Brown in order to better prevent cascading failovers.
Regarding claim 10, Sheldon in view of Cooper, Bryson, Li, and Brown show: wherein step (ab) is executed by editing one or more tables (Cooper, [27,29,45-46,66]) such that routing paths to virtual IP addresses (Brown, [15]) that correspond to said specific security protocol subsystem (Sheldon, Fig. 9, [67-68,84-85]) that has said failed status are removed (Li, pg. 2 line 61 – pg. 3 line 9, pg. 5 line 35-55 and Brown, [30-33]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Bryson, Li, and Brown, as applied to claim 9 above, further in view of StackOverflow.
Regarding claim 11, Sheldon in view of Cooper, Bryson, Li, and Brown show: wherein step (ac) is executed by editing one or more tables (Cooper, [27,29,45-46,66]) such that a correspondence to said specific security protocol subsystem (Sheldon, Fig. 9, [67-68,84-85]) that has said failed status is replaced by a corresponding to said spare security protocol subsystem (Li, pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55 and Brown, [30-33]). The above combination does not show: tracking endpoints via MAC address correspondence. StackOverflow shows tracking endpoints via MAC address correspondence (pg. 1, see answer by “jman”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the routing techniques discussed by StackOverflow in order to continue utilizing common networking techniques and tools (MAC addresses, interface management, etc.) in order to improve network reliability and facilitate simplified troubleshooting and maintenance.
Claims 14, 36, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Cornell, Cruz, Mack-Crane (US-20170222926-A1), and Xiao (Xiao, Wei-Cheng, et al. "VIP: a Virtual Interface-based aPproach for vertical handover in single-subnet networks." 21st International Conference on Advanced Information Networking and Applications (AINA'07). IEEE. (Year: 2007)).
Regarding claim 14, Sheldon in view of Cooper and Bryson show wherein said tables include:
one or more routing tables (Cooper, [25-27]). The above combination does not show: detailing a concordance between virtual IP addresses and routing paths; and one or more routing tables that detail a concordance between destination networks and IP addresses.
Cornell shows: detailing a concordance between virtual IP addresses and routing paths (pg. 3 lines 37-65); and one or more routing tables that detail a concordance between destination networks and IP addresses (pg. 3 lines 43-65).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing.
The above combination does not show use of virtual IP addresses ([20-24]). Cruz shows use of virtual IP addresses ([20-24]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing.
The above combination does not show: one or more MAC address tables that detail a concordance between MAC addresses and said I/O ports. Mack-Crane shows one or more MAC address tables that detail a concordance between MAC addresses and said I/O ports ([30,32,77]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the MAC address use of Mack-Crane in order to continue utilize old and well understood data structures and routing techniques (i.e., MAC address and port associations) to better ensure reliable network operation and communication routing.
The above combination does not show: one or more ARP tables that detail concordance between routing paths of IP addresses and MAC addresses. Xiao shows: one or more ARP tables that detail concordance between routing paths of IP addresses and MAC addresses (pg. 4, Section 3.2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the MAC address use of Xiao in order to continue utilize old and well understood data structures and routing techniques (i.e., MAC address and IP address associations) to better ensure reliable network operation and communication routing.
Regarding claim 36, the above combination further shows wherein each virtual IP address corresponds to a specific routing path (Cornell, pg. lines 25-65) and wherein each routing path corresponds to a specific MAC address (Xiao, pg. 4, Section 3.2).
Regarding claim 37, the above combination further shows wherein each MAC address corresponds to a specific I/O interface (Xiao, pg. 4, Section 3.2, Sheldon, Fig. 9).
Claims 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Cornell and Cruz.
Regarding claim 15, Sheldon in view of Cooper and Bryson show claim 2, including said tables (Cooper, [27,29,45-46,66]). The above combination does not show where destination network maps to at least one IP address. Cornell shows where destination network maps to at least one IP address (pg. 2 lines 24-27, pg. 3 lines 43-65).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing.
The above combination does not show use of virtual IP addresses. Cruz shows use of virtual IP addresses ([20-24]).
t would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual addressing of Cruz in order to continue to leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network.
Regarding claim 16, the above combination further shows wherein each virtual IP address (Cruz, [20-24]) maps to a routing path (Cornell, pg. 2 lines 24-27, pg. 3 lines 43-65).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Bryson, Cornell and Cruz, as applied to claim 15 above, further in view of Mack-Crane.
Regarding claim 17, Sheldon in view of Cooper, Bryson, Cornell and Cruz show claim 16. The above combination does not show wherein each of said routing path maps to a MAC addresses. Mack-Crane shows wherein each of said routing path maps to a MAC addresses ([30,42]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the MAC address use of Mack-Crane in order to continue utilize old and well understood data structures and routing techniques (i.e., MAC address and port/path associations) to better ensure reliable network operation and communication routing.
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Pillareddy. Regarding claim 19, Sheldon in view of Cooper and Bryson show use of security protocol subsystems (Sheldon, Fig. 9, [67-68,84-85]). The above combination does not show: wherein said controller determines a health of specific ones of said subsystems based on whether said monitoring packets are responded to or not ([74]) and wherein said controller adjusts said tables ([74] discussing triggering route deletion), when necessary, such that packets are not sent to subsystems that are considered to be sub-optimal (e.g., unresponsive; see [74]). Pillareddy shows wherein said controller determines a health of specific ones of said subsystems based on whether said monitoring packets are responded to or not and wherein said controller adjusts said tables, when necessary, such that packets are not sent to subsystems that are considered to be sub-optimal.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the route maintenance of in order to ensure recorded and utilized routing information and tables are accurate, thus ensuring consistent system operation.
Regarding claim 20, the above combination further shows wherein security protocol subsystems are considered to be sub-optimal when said security protocol subsystems are one or more of: non-functional (Pillareddy, [73-74], see “does not receive a response”, where responding is a function and thus not responding is within the broadest reasonable interpretation of non-functional); malfunctioning; and equipped with out-of-date security protocols.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of
Cooper, Bryson, and Pillareddy as applied to claim 19 above, further in view of Mikkilineni (US-20150149761-A1).
Regarding claim 21, Sheldon in view of Cooper, Bryson, and Pillareddy show use of security protocol subsystems (Sheldon, Fig. 9, [67-68,84-85]). The above combination does not show: wherein said controller replaces subsystems that are considered to be sub-optimal with one or more spare subsystems. Mikkilineni shows wherein said controller replaces subsystems that are considered to be sub-optimal with one or more spare subsystems ([53]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the spare system utilization of Mikkilineni in order to further improve operational reliability while also better utilizing available resources.
Claims 22 – 24, 27, 29, 41, and 42 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cornell, Cruz, and StackOverflow.
Regarding claim 22, Sheldon shows a method for determining which I/O interface to send incoming packet flows to on a packet switch (Figs. 3 and 9), said method comprising the steps of:
(a) receiving one of said incoming packet flows, each of said incoming packet flows comprising a plurality of data packets ([51-53]);
wherein determining which specific I/0 interface is to be used for routing said specific incoming packet flow also determines which of said security protocol subsystems is to be used for applying security protocols to said packets in said specific incoming packet flow (Fig. 3, [213] discussing particular I/O interfaces paired with particular security applications (i.e., subsystems)). Sheldon does not show: (b) for each specific packet of said plurality of data packets in a specific incoming packet flow,
(b1) determining an address for said specific packet based on a destination network of said specific packet;
(b2) based on said address, determining a routing path IP address for said address. Cornell shows: (b) for each specific packet of said plurality of data packets in a specific incoming packet flow (pg. 3 lines 16-17 and lines 25-27),
(b1) determining an address for said specific packet based on a destination network of said specific packet (pg. 3 lines 25-27 and 43-45);
(b2) based on said address, determining a routing path IP address for said address (pg. 3 lines 37-65).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing. The above combination does not show use of virtual IP addresses.
Cruz shows use of virtual IP addresses ([20-24]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual addressing of Cruz in order to continue to leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network.
The above combination does not show: (b3) determining a MAC address for said routing path IP address;
(b4) determining a specific I/0 interface that corresponds to said MAC address;
(b5) routing said specific packet in said specific incoming packet flow to said specific I/O interface determined in step (b4). StackOverflow shows: (b3) determining a MAC address for said routing path IP address (pg. 1, see the response by “jman”);
(b4) determining a specific I/0 interface that corresponds to said MAC address (pg. 3, see the response by “Lynn Crumbling”);
(b5) routing said specific packet in said specific incoming packet flow to said specific I/O interface determined in step (b4) (pg. 3, see the response by “Lynn Crumbling”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the port usage discussed by StackOverflow in order to continue utilizing common networking techniques and tools (MAC addresses, interface management, etc.) in order to improve network reliability and facilitate simplified troubleshooting and maintenance.
Regarding claim 23, the above combination further shows: wherein between steps (b1) and (b2), said method includes
(ba-1) determining a reachability of said virtual IP address (Cruz, Figs. 7, 8 and [20-24]); and
(ba-2) in the event said virtual IP address is not reachable, determining an alternate virtual IP address and using said alternate virtual IP address as said virtual IP address (Cruz, Figs. 7, 8 and [20-24]).
Regarding claim 24, the above combination further shows wherein said method is implemented by a controller that controls a packet switch (Sheldon, [213]) of which said I/O interface is a part (Sheldon, Fig. 9).
Regarding claim 27, Sheldon shows: a method for determining which I/O interface to send incoming packet flows to on a packet switch (Figs. 3 and 9), said method comprising the steps of:
(a) receiving one of said incoming packet flows, each of said incoming packet flows comprising a plurality of data packets ([51-53]);
wherein determining which specific I/O interface is to be used for routing said specific incoming packet flow also determines which of said security protocol subsystems is to be used for applying security protocols to said packets in said specific incoming packet flow (Fig. 3, [213] discussing particular I/O interfaces paired with particular security applications (i.e., subsystems)). Sheldon does not show: (b) for each specific packet of said plurality of data packets in a specific incoming packet flow,
(b1) determining a virtual IP address for said specific packet based on a destination network of said specific packet;
Cornell shows: (b) for each specific packet of said plurality of data packets in a specific incoming packet flow (pg. 3 lines 16-17 and lines 25-27),
(b1) determining an address for said specific packet based on a destination network of said specific packet (pg. 3 lines 25-27 and 43-45);
(b4) based on said address, determining a routing path IP address for said address (pg. 3 lines 37-65).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network management techniques of the above combination with the addressing and routing management of Cornell in order to utilize old and well understood data structures and routing techniques to better ensure reliable network operation and communication routing.
The above combination does not show use of virtual IP addresses,
(b2) determining a reachability of said virtual IP address;
(b3) in the event said virtual IP address is not reachable, determining an alternate virtual
IP address and using said alternate virtual IP address as said virtual IP address;
Cruz shows use of virtual IP addresses ([20-24]).
(b2) determining a reachability of said virtual IP address (Figs. 7, 8 and [20-24]);
(b3) in the event said virtual IP address is not reachable, determining an alternate virtual
IP address and using said alternate virtual IP address as said virtual IP address (Figs. 7, 8 and [20-24]); It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual addressing of Cruz in order to continue to leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network.
The above combination does not show: (b5) determining a MAC address for said routing path IP address;
(b6) determining a specific I/O interface that corresponds to said MAC address; and
(b7) routing said specific packet of said specific incoming packet flow to said specific I/O interface determined in step (b6). StackOverflow shows: StackOverflow shows: (b5) determining a MAC address for said routing path IP address (pg. 1, see the response by “jman”);
(b6) determining a specific I/O interface that corresponds to said MAC address (pg. 3, see the response by “Lynn Crumbling”);
(b7) routing said specific packet in said specific incoming packet flow to said specific I/O interface determined in step (b6) (pg. 3, see the response by “Lynn Crumbling”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the port usage discussed by StackOverflow in order to continue utilizing common networking techniques and tools (MAC addresses, interface management, etc.) in order to improve network reliability and facilitate simplified troubleshooting and maintenance.
Regarding claim 41, the above combination further shows wherein for step (b1), a same (Cornell, pg. 3 lines 37-65, showing consistent address-based routing decisions) virtual IP address (Cruz, [20-24]) is determined for all packets in a particular incoming packet flow (Sheldon, [51-53,70]).
Regarding claim 42, the above combination further shows wherein for step (b1), a same (Cornell, pg. 3 lines 37-65, showing consistent address-based routing decisions) virtual IP address (Cruz, [20-24]) is determined for all packets in a particular incoming packet flow (Sheldon, [51-53,70]).
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cornell, Cruz, and StackOverflow, as applied to claim 22 above, further in view of Huawei. Regarding claim 25, Sheldon in view of Cornell, Cruz, and StackOverflow show shows prior to step (b1), the following steps are executed:
(b1-1) determining a set of characteristics that said specific packet has in common with other packets such that said set of characteristics defines a unidirectional packet flow (Sheldon, [54,93]);
(b1-2) determining a directionally symmetric hash value from said set of characteristics (Sheldon, [93]);
wherein
said virtual IP address (Cruz, [24-27]) for said specific packet is based on said destination network of said specific packet (Cornell, pg. 3 lines 25-27 and 43-45). The above combination does not show: (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number,
basing the destination on said modulo result for said specific packet. Huawei shows (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number (pgs. 1 – 2, see answer provided by “Nancy Xiong”),
basing the destination on said modulo result for said specific packet (pgs. 1 – 2, see answer provided by “Nancy Xiong”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination in order to better control server load – and thus improve system reliability and consistency – when balancing requests between primary and backup servers.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cornell, Cruz, StackOverflow, and Huawei as applied to claim 22 above, further in view of Sharma (US-20230247054-A1).l
Regarding claim 26, Sheldon in view of Cornell, Cruz, StackOverflow, and Huawei show claim 25. The above combination does not show execution by dedicated hardware components of a system that includes said packet switch. Sharma shows execution by dedicated hardware components of a system that includes said packet switch (Fig. 3C, [27]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the hardware use of Sharma in order to enable improved performance via hardware-based acceleration, improving system responsiveness.
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Cornell, Cruz, StackOverflow, as applied to claim 27 above, further in view of Capper.
Regarding claim 28, Sheldon in view of Cooper, Cornell, Cruz, and StackOverflow show determination of an alternative virtual IP address (Cruz, Figs. 7 – 8, [20-24]). The above combination does not show determination via resilient hashing. Capper shows determination via resilient hashing ([29-31]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the hashing of Capper in order to lower hash table churn, improving system efficiency (Capper, [31]).
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cornell, Cruz, and StackOverflow, as applied to claim 5 above, further in view of Huawei.
Regarding claim 29, the above combination further shows wherein prior to step (b1), the following steps are executed:
(b1-1) determining a set of characteristics that said specific packet has in common with other packets such that said set of characteristics defines a unidirectional packet flow (Sheldon, [54,93]);
(b1-2) determining a directionally symmetric hash value from said set of characteristics (Sheldon, [93]); and
wherein
said virtual IP address (Cruz, [24-27]) for said specific packet is based on said destination network of said specific packet (Cornell, pg. 3 lines 25-27 and 43-45). The above combination does not show: (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number,
basing the destination on said modulo result for said specific packet. Huawei shows (b1-3) determining a modulo result from said symmetric hash value, said modulo result being a non-negative integer number (pgs. 1 – 2, see answer provided by “Nancy Xiong”),
basing the destination on said modulo result for said specific packet (pgs. 1 – 2, see answer provided by “Nancy Xiong”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination in order to better control server load - and thus improve system reliability and consistency – when balancing requests between primary and backup servers.
Claim 30 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Farahmand, Bhalerao, and Pillareddy.
Regarding claim 30, Sheldon shows: a method for managing said one or more security protocol subsystems used by a packet switch (Fig. 9, [67-68,84-85]), the method comprising: Sheldon does not show: use of table entries in said packet switch. Cooper shows use of table entries in said packet switch ([25-27]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and scaling techniques of Sheldon with the software defined networking, including the use of SDN switches - along with the other virtualization techniques of Cooper, in order leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network. The above combination does not show:
(a) determining if a specific subsystem is to be designated as having a recovered status, said specific subsystem being previously determined to have failed;
(b) in the event said specific subsystem is to be designated as having said recovered status, designating said specific subsystem as a recovered subsystem; (e) in the event said recovered subsystem is not designated as a spare subsystem, adjusting at least entry to thereby restore a previously designated unreachable subsystem, to thereby designate the corresponding as a recovered subsystem. Farahmand shows (a) determining if a specific subsystem is to be designated as having a recovered status, said specific subsystem being previously determined to have failed ([52]);
(b) in the event said specific subsystem is to be designated as having said recovered status, designating said specific subsystem as a recovered subsystem ([52-52]),
(e) in the event said recovered subsystem is not designated as a spare subsystem, adjusting at least entry to thereby restore a previously designated unreachable subsystem, to thereby designate the corresponding as a recovered subsystem ([52-53]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the network management techniques of Farahmand in order to better track registrations in the network (i.e., better manage addresses) in order to improve the capability of the resultant system to handle greater numbers of clients and larger amounts of traffic (Farahmand, [5]).
The above combination does not show: (c) determining if said recovered subsystem is to be designated as a spare subsystem;
(d) in the event said recovered subsystem is to be designated as a spare subsystem, adjusting said tables such that said recovered subsystem is designated as a spare. Bhalerao shows: (c) determining if said recovered subsystem is to be designated as a spare subsystem (Fig. 6, col. 10 lines 36-50);
(d) in the event said recovered subsystem is to be designated as a spare subsystem, adjusting said tables such that said recovered subsystem is designated as a spare (Fig. 6, col. 10 lines 36-50).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the spare/failover system management of Bhalerao in order to better ensure that backup systems are utilized for their intended purpose, thus improving the reliability of the resultant system.
The above combination does not show updating (or restoring) a specific routing path specified using a virtual IP address by adjusting at least one entry to designate a MAC address corresponding to routing path. Pillareddy shows updating (or restoring) a specific routing path specified using a virtual IP address by adjusting at least one entry to designate a MAC address corresponding to routing path ([65,74,91,119-121]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtual IP and MAC address management of Pillareddy in order to ensure that paired VIP and MAC addresses utilized for routing remain associated as intended, thus ensuring reliable and consistent operation of the resultant system.
Claims 31 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Li, and Brown.
Regarding claim 31, Sheldon shows a method for managing a group of security protocol subsystems used by a packet switch (Fig. 9, [67-68,84-85]). Sheldon does not show: use of table entries in said packet switch. Cooper shows use of table entries in said packet switch ([25-27]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and scaling techniques of Sheldon with the software defined networking, including the use of SDN switches - along with the other virtualization techniques of Cooper, in order leverage the implementation flexibility and adaptability facilitated by virtualization technologies and software implementation flexibility, improving the resiliency of the resultant network. The above combination does not show: consideration of a failed status, (a) determining if a spare security protocol subsystem is already in use;
(b) if said spare security protocol subsystem is available, editing one or more tables such that said specific subsystem that has said failed status;
(c) if said spare subsystem is not available, editing one or more tables such that said spare subsystem is used by said system in place of said specific security protocol subsystem that has said failed status. Li shows: consideration of a failed status (pg. 5 lines 35-53), (a) determining if a spare security protocol subsystem is already in use (pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55);
(b) if said spare security protocol subsystem is available, editing one or more tables such that said specific subsystem that has said failed status (pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55);
(c) if said spare subsystem is not available, editing one or more tables such that said spare subsystem is used by said system in place of said specific security protocol subsystem that has said failed status (pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the failover management techniques of Li in order to further improve network reliability by ensuring device status is accurately tracked.
The above combination does not show consideration of if a spare system is already in use, and if so, editing the status to reflect the failed system is unreachable. Brown shows: consideration of if a spare system is already in use, and if so, editing the status to reflect the failed system is unreachable ([30-33]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the failover management of Brown in order to better prevent cascading failovers.
Regarding claim 32, Sheldon in view of Cooper, Li, and Brown show editing one or more tables (Cooper, [27,29,45-46,66]) in said packet switch (Cooper, [25-27]) such that the routing path of the virtual IP address (Brown, [15]) that corresponds to said specific security protocol subsystem (Sheldon, Fig. 9, [67-68,84-85]) that has failed is removed (Li, pg. 2 line 61 – pg. 3 line 9, pg. 5 line 35-55 and Brown, [30-33]).
Claim 33 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper, Li, and Brown, as applied to claim 31 above, further in view of StackOverflow.
Regarding claim 33, Sheldon in view of Cooper, Li, and Brown show wherein step (c) is executed by editing one or more tables (Cooper, [27,29,45-46,66]) such that a correspondence to said specific security protocol subsystem (Sheldon, Fig. 9, [67-68,84-85]) that has said failed status is replaced by a corresponding to said spare security protocol subsystem (Li, pg. 2 line 61 – pg. 3 line 9, pg. 5 lines 35-55 and Brown, [30-33]).
The above combination does not show: tracking endpoints via MAC address correspondence.
StackOverflow shows tracking endpoints via MAC address correspondence (pg. 1, see answer by “jman”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the routing techniques discussed by StackOverflow in order to continue utilizing common networking techniques and tools (MAC addresses, interface management, etc.) in order to improve network reliability and facilitate simplified troubleshooting and maintenance.
Claim 35 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Nainar (US-20210111989-A1).
Regarding claim 35, Sheldon in view of Cooper and Bryson show wherein said packet switch load balances across said one or more security protocol subsystems (Sheldon, [209-216]). The above combination does not show: implements Equal Cost Multi-Path (ECMP) functionality and using said ECMP. Nainar shows: implements Equal Cost Multi-Path (ECMP) functionality and using said ECMP ([2]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination to utilize the ECMP suggested by Nainar in order to improve operational efficiency and scaling when managing larger networks (Nainar, [2]).
Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Li.
Regarding claim 38, Sheldon in view of Cooper and Bryson show use of security protocol subsystems (Sheldon, Fig. 9, [67-68,84-85]). The above combination does not show wherein said system includes a spare subsystem, said spare subsystem being for use in replacing a failed subsystem when said failed subsystem is detected by said controller. Li shows wherein said system includes a spare subsystem, said spare subsystem being for use in replacing a failed subsystem when said failed subsystem is detected by said controller (pg.2 line 61 – pg. 3 line 9, pg. 3 lines 42 – 48, pg. 5 lines 35-55).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the failover management techniques of Li in order to utilize the existing multiple subsystems of the invention for failovers, improving system reliability and uptime.
Claim 39 is rejected under 35 U.S.C. 103 as being unpatentable over Sheldon in view of Cooper and Bryson, as applied to claim 2 above, further in view of Roberson (EP-3282672-A1).
Regarding claim 39, Sheldon in view of Cooper and Bryson show use of security protocol subsystems (Sheldon, Fig. 9, [67-68,84-85]). The above combination does not show use of a dedicated security appliance. Roberson shows use of a dedicated security appliance.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the dedicated hardware utilization of Roberson in order to improve system efficiency by leveraging the performance advantages enabled by dedicated hardware.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
Kulkarni (US-20200257571-A1),
Bengough (US-20200084141-A1), and
Kwon (US-20110243142-A1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454