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 .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description: Figure 3 does not include “path 1” and “path 2” mentioned in the specification paragraph [0057]. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
Claim 12 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.
Claim 12 recites the limitation “the session information" in line 2. There is insufficient antecedent basis for this limitation in the claim. Claim 10, which claim 12 depends upon, does not recite the session information. For the purpose of examination, Examiner is interpreting as “a session information”.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-18 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. co-pending application No. 19/037,663. Although the claims at issue are not identical, they are not patentably distinct from each other as illustrated in the table below. The subject matter claimed in the instant application is fully disclosed in the co-pending application since the co-pending application and the instant application are claiming common subject matter, as shown in table below.
Instant Application No. US 18/896,308
Co-pending Application No. US 19/037,663
Claim 1: A cloud network message processing method, comprising: obtaining a cloud network message; wherein the cloud network message is sent from a source end to a cloud security device; determining a target security device for the cloud network message from pre-configured multiple types of candidate security devices; wherein the candidate security devices comprise: a built-in security device inside the cloud security device, and a third-party security device outside the cloud security device; and sending the cloud network message to the target security device for security processing, and sending the cloud network message processed by the target security device to a destination end.
Claim 1: A cloud network message processing method, comprising: obtaining a cloud network message, wherein the cloud network message is sent from a source end to a cloud security device; determining, from at least one type of pre-configured candidate security device, a target type of candidate security device corresponding to the cloud network message; in the case that there are multiple candidate security devices of the target type, determining a target security device from the multiple candidate security devices of the target type based on session information included in the cloud network message, wherein cloud network messages with same session information correspond to a same target security device (claim 4 and claim 5 of the instant application), and sending the cloud network message to the target security device for security processing, and sending the cloud network message having been security processed by the target security device to a destination end.
Claim 2: The method according to claim 1, wherein, the cloud security device internally further comprises: a traffic director; obtaining the cloud network message comprises: receiving, by the traffic director, the cloud network message sent from the source end.
Claim 4: The method according to claim 3, wherein: the multiple types of candidate security devices comprise: a built-in security device inside the cloud security device and a third-party security device external to the cloud security device (claim 1 of the instant application); wherein the cloud security device internally further comprises: a traffic director; and wherein obtaining the cloud network message comprises: receiving, by the traffic director, the cloud network message sent from the source end.
Claim 3: The method according to claim 1, wherein determining the target security device for the cloud network message from the pre-configured multiple types of candidate security devices comprises: determining a target type corresponding to identification information contained in the cloud network message; determining one or more candidate security devices of the target type from the pre-configured multiple types of candidate security devices; and determining the target security device from the one or more candidate security devices of the target type.
Claim 3: The method according to claim 1, wherein: the at least one type of candidate security device comprises multiple types of candidate security devices; and wherein determining, from at least one type of pre-configured candidate security device, the target type of candidate security device corresponding to the cloud network message comprises: determining a target type corresponding to identification information included in the cloud network message; and determining the candidate security devices of the target type from pre- configured multiple types of candidate security devices.
Claim 4: The method according to claim 3, wherein determining the target security device from the one or more candidate security devices of the target type comprises: in the case that there is only one candidate security device of the target type, taking the one candidate security device of the target type as the target security device; or in the case that there are multiple candidate security devices of the target type, determining the target security device from the multiple candidate security devices of the target type.
In claim 1 of the co-pending application
Claim 5: The method according to claim 4, wherein determining the target security device from the multiple candidate security devices of the target type comprises: determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message; wherein target security devices corresponding to a same session information are identical.
In claim 1 of the co-pending application, plus
Claim 5: The method according to claim 1, wherein the cloud network message is sent to the target security device through a traffic routing path pre-established corresponding to the target security device.
Claim 6: The method according to claim 5, wherein, the session information includes: a source IP address and a destination IP address; determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message comprises: performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device.
Claim 2: The method according to claim 1, wherein: the session information comprises a source IP address and a destination IP address; and wherein determining the target security device based on the session information included in the cloud network message comprises: performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an order-independent hash computation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking a candidate security device of the target type corresponding to the remainder as the target security device.
Claim 7: A cloud network system, comprising: a traffic director, a built-in security device provided inside a cloud security device, and a third-party security device provided outside the cloud security device; the traffic director is configured for obtaining a cloud network message; determining a target security device for the cloud network message from pre-configured multiple types of candidate security devices; sending the cloud network message to the target security device for security processing, and sending the cloud network message processed by the target security device to a destination end; wherein the cloud network message is sent from a source end to the cloud security device; and the candidate security devices comprise: the built-in security device and the third-party security device; the built-in security device is configured for performing security processing on the cloud network message after receiving the cloud network message; the third-party security device is configured for performing security processing on the cloud network message after receiving the cloud network message.
Claim 6: A cloud network system, comprising: a traffic director and a target security device; wherein the traffic director is configured to obtain a cloud network message, determine, from at least one type of pre-configured candidate security device, a target type of candidate security device corresponding to the cloud network message, in the case that there are multiple candidate security devices of the target type, determine a target security device from the multiple candidate security devices of the target type based on session information included in the cloud network message (claim 10 and claim 11 of the instant application), send the cloud network message to the target security device for security processing, and send the cloud network message having been security processed by the target security device to a destination end, wherein the cloud network message is sent from a source end to the cloud security device, and cloud network messages with same session information correspond to a same target security device (claim 11 of the instant application); and the target security device is configured to perform security processing on the cloud network message upon receiving it.
Claim9: The system according to claim 8, wherein: the multiple types of candidate security devices comprise: a built-in security device inside the cloud security device and a third-party security device external to the cloud security device; the traffic director is located inside the cloud security device; wherein the traffic director is further configured to: receive the cloud network message sent from the source end (claim 8 of the instant application).
Claim 10: The system according to claim 9, wherein the built-in security device is a built-in firewall, and the third-party security device is a virtual firewall pre-deployed by a user sending the cloud network message.
Claim 8: The system according to claim 7, wherein, the traffic director is provided inside the cloud security device; correspondingly, the traffic director is further configured for: receiving the cloud network message sent from the source end.
In claim 6 of the co-pending application.
Claim 9: The system according to claim 8, wherein the traffic director is further configured for: determining a target type corresponding to identification information contained in the cloud network message; determining the target security device from one or more candidate security devices corresponding to the target type.
Claim 8: The system according to claim 6, wherein: the at least one type of candidate security device comprises multiple types of candidate security devices; and wherein the traffic director is further configured to: determine a target type corresponding to identification information included in the cloud network message; and determine the candidate security devices of the target type from pre-configured multiple types of candidate security devices.
Claim 10: The system according to claim 9, wherein the traffic director is further configured for: in the case that there is only one candidate security device of the target type, taking the one candidate security device of the target type as the target security device; or in the case that there are multiple candidate security devices of the target type, determining the target security device from the multiple candidate security devices of the target type.
In claim 6 of the co-pending application.
Claim 11: The system according to claim 10, wherein the traffic director is further configured for: determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message; wherein target security devices corresponding to a same session information are identical.
In claim 6 of the co-pending application
Claim 12: The system according to claim 10, wherein, the session information includes: a source IP address and a destination IP address; the traffic director is further configured for: performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device.
Claim 7: The system according to claim 6, wherein: the session information comprises a source IP address and a destination IP address; and wherein the traffic director is further configured to: perform combination processing on the source IP address and the destination IP address to obtain a combined IP address; perform an order-independent hash computation on the combined IP address to obtain a hash value; perform a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and take a candidate security device of the target type corresponding to the remainder as the target security device.
Claim 13: An electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, the instructions when executed by the at least one processor cause the at least one processor to perform a cloud network message processing method, comprising: obtaining a cloud network message; wherein the cloud network message is sent from a source end to a cloud security device; determining a target security device for the cloud network message from pre-configured multiple types of candidate security devices; wherein the candidate security devices comprise: a built-in security device inside the cloud security device, and a third-party security device outside the cloud security device; and sending the cloud network message to the target security device for security processing, and sending the cloud network message processed by the target security device to a destination end.
Claim 11: An electronic device used as a cloud security device, comprising: at least one processor; and a memory connected with the at least one processor communicatively; wherein the memory stores instructions executable by the at least one processor to cause the at least one processor to perform a cloud network message processing method, comprising: obtaining a cloud network message, wherein the cloud network message is sent from a source end to the cloud security device; determining, from at least one type of pre-configured candidate security device, a target type of candidate security device corresponding to the cloud network message; in the case that there are multiple candidate security devices of the target type, determining a target security device from the multiple candidate security devices of the target type based on session information included in the cloud network message, wherein cloud network messages with same session information correspond to a same target security device (claim 16 and claim 17 of the instant application); and sending the cloud network message to the target security device for security processing, and sending the cloud network message having been security processed by the target security device to a destination end.
Claim 14: The electronic device according to claim 13, wherein: the multiple types of candidate security devices comprise: a built-in security device inside the cloud security device and a third-party security device external to the cloud security device; wherein the cloud security device internally further comprises: a traffic director, and the cloud network message is received by the traffic director (claim 14 of the instant application).
Claim 14: The electronic device according to claim 13, wherein, the electronic device serves as a traffic director located inside the cloud security device.
In claim 14 of the co-pending application.
Claim 15: The electronic device according to claim 13, wherein determining the target security device for the cloud network message from pre-configured multiple types of candidate security devices comprises: determining a target type corresponding to identification information contained in the cloud network message; determining one or more candidate security devices of the target type from the pre-configured multiple types of candidate security devices; and determining the target security device from the one or more candidate security devices of the target type.
Claim 13: The electronic device according to claim 11, wherein: the at least one type of candidate security device comprises multiple types of candidate security devices; and wherein determining, from at least one type of pre-configured candidate security device, the target type of candidate security device corresponding to the cloud network message comprises: determining a target type corresponding to identification information included in the cloud network message; and determining the candidate security devices of the target type from pre- configured multiple types of candidate security devices.
Claim 16: The electronic device according to claim 15, wherein determining the target security device from the one or more candidate security devices of the target type comprises: in the case that there is only one candidate security device of the target type, taking the one candidate security device of the target type as the target security device; or in the case that there are multiple candidate security devices of the target type, determining the target security device from the multiple candidate security devices of the target type.
In claim 11 of the co-pending application.
Claim 17: The electronic device according to claim 16, wherein determining the target security device from the multiple candidate security devices of the target type comprises: determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message; wherein target security devices corresponding to a same session information are identical.
In claim 11 of the co-pending application, plus
Claim 15: The electronic device according to claim 11, wherein the cloud network message is sent to the target security device through a traffic routing path pre- established corresponding to the target security device.
Claim 18: The electronic device according to claim 17, wherein, the session information includes: a source IP address and a destination IP address; determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message comprises: performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device.
Claim 12: The electronic device according to claim 11, wherein: the session information comprises a source IP address and a destination IP address; and wherein determining the target security device based on the session information included in the cloud network message comprises: performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an order-independent hash computation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking a candidate security device of the target type corresponding to the remainder as the target security device.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 7-11, 13-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kirby et al (US PG-PUB No. 20170208097 A1), hereinafter Kirby.
Regarding claim 1, claim 7 and claim 13, Kirby teaches a cloud network message processing method, system and device, the method comprising:
obtaining a cloud network message; wherein the cloud network message is sent from a source end to a cloud security device (Fig 16: step 1602: “Receive a configuration policy in a vendor neutral language (obtaining a cloud network message).”; Paragraph [0024] further teaches: “In some embodiments, a security device controller includes receiving a configuration policy in a vendor neutral language; and automatically configuring a plurality of security devices on a heterogeneous network based on the configuration policy.”; Paragraph [0026]: “The security device controller then can automatically translate the rules/policies into vendor-specific languages/commands and send these instructions and/or configurations to the various security devices (e.g., firewalls, routers, and/or other security devices) (the cloud network message is sent from a source end to a cloud security device) in the appropriate form that can be implemented by the respective security devices, in a heterogeneous network environment in which the security devices are from two or more different vendors.”);
determining a target security device for the cloud network message from pre-configured multiple types of candidate security devices; wherein the candidate security devices comprise: a built-in security device inside the cloud security device, and a third-party security device outside the cloud security device (Fig 16: step 1604: “Automatically translate the vendor neutral language into a plurality of vendor specific languages for automatically configuring the plurality of security devices (pre-configured multiple types of candidate security devices).” Paragraph [0024]: “the heterogeneous network can include security devices from a plurality of different vendors (the candidate security devices include built-in and third-party security devices from different vendors).”; Paragraph [0035]: “In some embodiments, the security device controller includes a workbook engine that determines at which device(s) to implement configuration/policy changes (e.g., at which firewalls and/or routers or other devices to send particular configuration/policy changes) (determining a target security device for the cloud network message).”); and
sending the cloud network message to the target security device for security processing, and sending the cloud network message processed by the target security device to a destination end (Fig 16: step 1606: “Send the translated configuration policies (cloud network message) for each of the plurality of security devices to each of the plurality of security devices (sending the cloud network message to the target security device for security processing)”; Paragraph [0024]: “the configuration policy can include a rule-list (e.g., including routing ACLs for a router, a security policy for a firewall such as allow/block rules based on various criteria such as port numbers and protocols, etc.). Generally, a rule provides a description of a network flow and/or a filtering access (e.g., allow or deny, such as to allow/deny from <Source > to <Destination> for Service (sending the cloud network message from the source end to a destination end)).”).
Regarding claim 2, claim 8 and claim 14, Kirby teaches all of the features with respect to claim 1, claim 7 and claim 13, as outlined above.
Kirby further teaches wherein, the cloud security device internally further comprises: a traffic director; obtaining the cloud network message comprises: receiving, by the traffic director, the cloud network message sent from the source end (Paragraph [0024]: “In some embodiments, a security device controller (a traffic director) includes receiving a configuration policy in a vendor neutral language (obtaining the cloud network message comprises: receiving, by the traffic director, the cloud network message sent from the source end); and automatically configuring a plurality of security devices on a heterogeneous network (cloud) based on the configuration policy.”).
Regarding claim 3, claim 9 and claim 15, Kirby teaches all of the features with respect to claim 1, claim 8 and claim 13, as outlined above.
Kirby further teaches wherein determining the target security device for the cloud network message from the pre-configured multiple types of candidate security devices comprises: determining a target type corresponding to identification information contained in the cloud network message; determining one or more candidate security devices of the target type from the pre-configured multiple types of candidate security devices; and determining the target security device from the one or more candidate security devices of the target type (Paragraph [0035]: “In some embodiments, the security device controller includes a workbook engine that determines at which device(s) to implement configuration/policy changes (e.g., at which firewalls and/or routers or other devices to send particular configuration/policy changes) (determining the target security device for the cloud network message from the pre-configured multiple types of candidate security devices).”; Paragraph [0050]: “In some embodiments, the security device controller uses workbooks to organize security device rules and rule lists into an accessible framework. Workbooks can also be used to search across collections of devices to locate values in the devices' rule lists (By organizing and searching across collections of security devices, the security device controller uses workbooks to determine a target type of security devices, determine one or more candidate security devices of the target type from the pre-configured multiple types of candidate security devices, and determine the target security device from the one or more candidate security devices of the target type).”; Paragraph [0038]: “In some embodiments, the security device controller includes automatically implementing a policy change transaction (e.g., a set of commands/configurations of a security device on a heterogeneous network), including logging into a security device (e.g., using credentials, such as a username/password, a device-based digital certificate, and/or other credentials for authentication and authorization (the target type of security device corresponding to identification information contained in the cloud network message)), sending commands to add/delete/modify policies to the security device, and then logging out of the security device.”).
Regarding claim 4, claim 10 and claim 16, Kirby teaches all of the features with respect to claim 3, claim 9 and claim 15, as outlined above.
Kirby further teaches wherein determining the target security device from the one or more candidate security devices of the target type comprises: in the case that there is only one candidate security device of the target type, taking the one candidate security device of the target type as the target security device; or in the case that there are multiple candidate security devices of the target type, determining the target security device from the multiple candidate security devices of the target type (Paragraph [0051]: “In some embodiments, the workbook is specified as end points in a network flow (e.g., flow), and the security device controller automatically determines any intermediate rule-lists that are traversed by the flow. In some embodiments, the whitelist(s) and blacklist(s) are verified on top of an access search function that evaluates whether a particular flow is permitted or denied throughout a workbook (As would be apparent to one of ordinary skill in the art, the security device controller automatically determines the target security device from the multiple candidate security devices of the target type, thus in the case that there is only one candidate security device of the target type, taking the one candidate security device; in the case that there are multiple candidate security devices of the target type, determining the target security device based on the workbook.).”).
Regarding claim 5, claim 11 and claim 17, Kirby teaches all of the features with respect to claim 4, claim 10 and claim 16, as outlined above.
Kirby further teaches wherein determining the target security device from the multiple candidate security devices of the target type comprises: determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message; wherein target security devices corresponding to a same session information are identical (Paragraph [0038]: “In some embodiments, the security device controller includes connecting to a security device, maintaining a session with the security device, and sending multiple commands to the security device over a period of time that the session is maintained/open (based on session information) (e.g., the multiple commands can be on a blocking or non-blocking channel in which the security device can send an authorization token that can be used accordingly to send commands).”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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 6, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kirby et al (US PG-PUB No. 20170208097 A1), in view of Whillock et al (US Patent No. US 8150970 B1), hereinafter Whillock.
Regarding claim 6, claim 12 and claim 18, Kirby teaches all of the features with respect to claim 5, claim 10 and claim 17, as outlined above.
Kirby teaches wherein, the session information includes: a source IP address and a destination IP address (Paragraph [0069]: “In some embodiments, the security device controller also provides more advanced search features including the ability to search multiple rules against multiple devices.”; [0070]: “The search process can begin by selecting a workbook. The search type (e.g., access or rule) can be selected (e.g., the access search type can return any and all matches, including larger subnets, overlapping rules, and partial matches; and the rule search type can return exact matches, if any exist, from the filter sets in the selected workbook). A source and destination IP address or prefix in CIDR format, subnet mask or as a range (e.g., 10.0.0.0-12.0.0.0) can be entered.”).
Kirby fails to explicitly teach performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device.
However, Whillock teaches performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device ([Col 4, line 40] – [Col 5, line 6]: “The target (target security device) can be determined from the incoming identifier of the connection. For example, the identifier can be a URI (the source IP address and destination IP address). The URI includes all of the information to determine each level of the hierarchy 400 that will receive the work corresponding to this request. Typically, a client's computer contacts a DNS server to resolve the website address, e.g., www.happy.com, into an IP address. The IP address combined with the port receiving the request for work can be used to identify the adaptor (performing combination processing on the source IP address and the destination IP address to obtain a combined IP address). In this example, an identifier for the incoming work request is the URI provided above, i.e., rtmp://www.happy.com/happyApplication/someInstance. A hash function is applied to generate a unique number representing the identifier (performing an order-independent hash operation on the combined IP address to obtain a hash value), for example, the number 12345. The modulo operation is then applied, where the dividend is 12345 and the divisor is the number of core processes (performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder), i.e., 14. The remainder is determined in this example to be "11". The work request is therefore assigned to the core process mapped to the remainder of "11" (taking the candidate security device of the target type corresponding to the remainder as the target security device.). The next time a work request is received from the same source, i.e., the same application instance having the same URI, the request will be sent to the same core process.”).
Kirby and Whillock are both considered to be analogous to the claimed invention because they both teach message forwarding (work load distribution) among security devices (among server processes). Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method, systema and device disclosed by Kirby with adding performing combination processing on the source IP address and the destination address to obtain a combined IP address; performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device disclosed by Whillock.
One of the ordinary skills in the art would have been motivated to make this modification in order to provide fairness and affinity in the work distribution (cloud network message processing), as suggested by Whillock, in [Col 2, line 67].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (see PTO form 892 for details)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASMINE DAY whose telephone number is (571)272-0204. 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, Philip Chea can be reached at 571-272-3951. 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.
/J.M.D./ Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499