DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-15 rejected on the ground of nonstatutory double patenting as being unpatentable over claim1-18 of U.S. copending application No. 18/896,308. 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.
Instant application 19/037,663
Co-pending: 18/896,308
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; 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 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 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.
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.
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 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 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 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 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; 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 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 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 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 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.
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, 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; and the target security device is configured to perform security processing on the cloud network message upon receiving it.
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 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.
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.
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 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 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 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 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.
Claim 9 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.
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 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.
In claim 7 of the co-pending
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; 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 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.
Claim16. 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.
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.
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 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 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 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 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.
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.
In claim 13 of the co-pending and claim14. The electronic device according to claim 13, wherein,
the electronic device serves as a traffic director located inside the cloud security device.
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 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.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: traffic director is configured to … in claim 6 and target security device is configured to … in claim 6.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 6-10 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.
Claim limitation of “traffic director is configured to…” and “target security device is configured to…” has been evaluated under the three-prong test set forth in MPEP § 2181, subsection I, but the result is inconclusive. Thus, it is unclear whether this limitation should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because there is insufficient disclosure of the corresponding structure. The boundaries of this claim limitation are ambiguous; therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In response to this rejection, applicant must clarify whether this limitation should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Mere assertion regarding applicant’s intent to invoke or not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph is insufficient. Applicant may:
(a) Amend the claim to clearly invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, by reciting “means” or a generic placeholder for means, or by reciting “step.” The “means,” generic placeholder, or “step” must be modified by functional language, and must not be modified by sufficient structure, material, or acts for performing the claimed function;
(b) Present a sufficient showing that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, should apply because the claim limitation recites a function to be performed and does not recite sufficient structure, material, or acts to perform that function;
(c) Amend the claim to clearly avoid invoking 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, by deleting the function or by reciting sufficient structure, material or acts to perform the recited function; or
(d) Present a sufficient showing that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, does not apply because the limitation does not recite a function or does recite a function along with sufficient structure, material or acts to perform that function.
Claim Rejections - 35 USC § 102
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, 3-6, 8-11 and 13-15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hira (US 20190068500).
Re. claim 1, Hira discloses 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 (Hira discloses the path that a data message takes from VM 122 to VM 132 in some embodiments. As shown, the logical switch 120 initially receives this message and forwards this message to the logical router 130 [0028]. the logical router 130 provides the data message from VM 122 to the underlay downlink gateway 140, this gateway forwards this message to the service VPC 150 [0029]); 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 (Hira discloses one or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140 (e.g., on data messages that have source and/or destination addresses in the logical overlay address space). Examples of these service operations include typical middlebox service operations such as firewall operations, NAT operations, etc. [0030]. At 430, the process 400 configures one or more service machines with one or more service rules that direct the service machines to perform one or more services on the data messages that it receives from the underlay forwarding element directly or through intervening network fabric. Each such service rule is defined in terms of one or more logical overlay addresses [0044], determining the security device from the 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 (Hira discloses one or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140 (e.g., on data messages that have source and/or destination addresses in the logical overlay address space). Examples of these service operations include typical middlebox service operations such as firewall operations, NAT operations, etc. [0030]. When multiple service machines perform multiple service operations on this data message, the last service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface. In either case, a separate route table of the service machine's uplink interface is configured to route the processed data message to the underlay default uplink gateway 145 for the particular tenant in the public cloud [0031]. The path that this reply message takes is identical to the path of the original message from VM 122 to VM 132. The reply message traverses the same path as the original message when it goes from the logical router 130 to the underlay downlink gateway 140, and then to the service VPC 150, the underlay uplink gateway 145 and then the tenant gateway 135 [0034]); 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 (Hira discloses when only one service machine performs a service on the data message from VM 122, the service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface that handles the forwarding of data messages to networks outside of the service machine's VPC. On the other hand, when multiple service machines perform multiple service operations on this data message, the last service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface. [0031]. this gateway 145 forwards the data message from VM 122 to the tenant gateway 135. The tenant's cloud gateway 135 is configured to forward to the logical router 130 data messages that have destination addresses in the logical overlay address space [0032]. The gateway forwards the processed data message to the logical router 130, which then forwards it to the logical switch 125. This switch then forwards the data message to the VM 132. For the logical switch 125 to forward the data message to VM 132, the data message is supplied by a logical router instance executing on one host computer to the logical switch instance [0033]).
Re. claim 3, Hira discloses the method according to claim 1, wherein: the at least one type of candidate security device comprises multiple types of candidate security devices(Hira discloses [0030][0031][0033][0034][0044]); 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 (Hira discloses [0030][0031][0033][0034][0044]).
Re. claim 4, Hira discloses 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 (Hira discloses the service machines are within a service VPC in the public cloud. In other embodiments, the service machines can be outside of the public cloud. In still other embodiments, the service machines are part of the tenant's VPC but outside of the tenant's logical overlay network 115. [0030][0033][0034][0044]); 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 (Hira discloses the underlay default downlink gateway 140 is configured to send the data message destined to some or all logical overlay addresses to the service VPC 150, so that one or more service machines at this VPC can perform one or more services on the data message [0029].One or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140 (e.g., on data messages that have source and/or destination addresses in the logical overlay address space) [0030]).
Re. claim 5, Hira discloses 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 (Hira discloses the processed message to its uplink interface that handles the forwarding of data messages to networks outside of the service machine's VPC. On the other hand, when multiple service machines perform multiple service operations on this data message, the last service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface. In either case, a separate route table of the service machine's uplink interface is configured to route the processed data message to the underlay default uplink gateway 145 for the particular tenant in the public cloud [0031]).
Re. claim 6, Hira discloses a cloud network system, comprising: a traffic director and a target security device (Hira discloses one or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140. The service machines are within a service VPC in the public cloud. In other embodiments, the service machines can be outside of the public cloud. In still other embodiments, the service machines are part of the tenant's VPC but outside of the tenant's logical overlay network 115 [0030]); wherein the traffic director is configured to obtain a cloud network message (Hira discloses one or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140 (e.g., on data messages that have source and/or destination addresses in the logical overlay address space). Examples of these service operations include typical middlebox service operations such as firewall operations, NAT operations, etc. [0030]), 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 (Hira discloses one or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140 (e.g., on data messages that have source and/or destination addresses in the logical overlay address space). Examples of these service operations include typical middlebox service operations such as firewall operations, NAT operations, etc. [0030]. At 430, the process 400 configures one or more service machines with one or more service rules that direct the service machines to perform one or more services on the data messages that it receives from the underlay forwarding element directly or through intervening network fabric. Each such service rule is defined in terms of one or more logical overlay addresses [0044], determining the security device from the 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, 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 (Hira discloses one or more service machines 152 at the service VPC 150 are configured to perform one or more services on data messages received from the public cloud's underlay gateway 140 (e.g., on data messages that have source and/or destination addresses in the logical overlay address space). Examples of these service operations include typical middlebox service operations such as firewall operations, NAT operations, etc. [0030]. When multiple service machines perform multiple service operations on this data message, the last service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface. In either case, a separate route table of the service machine's uplink interface is configured to route the processed data message to the underlay default uplink gateway 145 for the particular tenant in the public cloud [0031]. The path that this reply message takes is identical to the path of the original message from VM 122 to VM 132. The reply message traverses the same path as the original message when it goes from the logical router 130 to the underlay downlink gateway 140, and then to the service VPC 150, the underlay uplink gateway 145 and then the tenant gateway 135 [0034]); and the target security device is configured to perform security processing on the cloud network message upon receiving it (Hira discloses when only one service machine performs a service on the data message from VM 122, the service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface that handles the forwarding of data messages to networks outside of the service machine's VPC. On the other hand, when multiple service machines perform multiple service operations on this data message, the last service machine 152 in the example of FIG. 1 provides the processed message to its uplink interface. [0031]. this gateway 145 forwards the data message from VM 122 to the tenant gateway 135. The tenant's cloud gateway 135 is configured to forward to the logical router 130 data messages that have destination addresses in the logical overlay address space [0032]. The gateway forwards the processed data message to the logical router 130, which then forwards it to the logical switch 125. This switch then forwards the data message to the VM 132. For the logical switch 125 to forward the data message to VM 132, the data message is supplied by a logical router instance executing on one host computer to the logical switch instance [0033]).
Re. claim 8, rejection of claim 6 is included and claim 8 is rejected with the same rationale as applied in claim 3 above.
Re. claim 9, rejection of claim 8 is included and claim 9 is rejected with the same rationale as applied in claim 4 above.
Re. claim 10, Hira discloses 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 (Hira discloses service operations include typical middlebox service operations such as firewall operations, NAT operations, etc. The service machines 152 can be standalone service appliances (e.g., third party service appliances, such firewall appliances of Palo Alto Network, etc.), or they can be service machines (e.g., virtual machines, containers, etc.) executing on host computers [0030][0044-0045]).
Re. claim 11, claim 11 is rejected with the same rationale as applied in claim 1 above. Hira further discloses 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 (Hira discloses various memory units, the processing unit(s) 610 retrieve instructions to execute, and data to process in order to execute the processes of some embodiments [0052][0051]).
Re. claim 13, rejection of claim 11 is included and claim 13 is rejected with the same rationale as applied in claim 3 above.
Re. claim 14, rejection of claim 13 is included and claim 14 is rejected with the same rationale as applied in claim 4 above.
Re. claim 15, rejection of claim 11 is included and claim 11 is rejected with the same rationale as applied in claim 5 above.
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 2, 7 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Hira (US 20190068500) in view of Whillock et al. (US8150970, hereinafter Whillock).
Re. claim 2, Hira discloses the method according to claim 1, wherein: the session information comprises a source IP address and a destination IP address (Hira discloses a data message with both a source and destination IP address [0030]); 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 (Hira discloses a data message with both a source and destination IP address [0030]). Hira does not explicitly teach but Whillock teaches 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 (Whillock teaches The IP address combined with the port receiving the request for work can be used to identify the adaptor. The name “happy.com” can be used to identify the virtual host. By way of illustrative example, consider a situation where incoming requests for work to be processed by the media server 302 are distributed at the application instance level, i.e., level 410 in the hierarchy. In this example, there are 14 application instances. The same number of core processes can be provided as there are number of application instances, i.e., in this example 14. 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, 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, 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”. [Col 4 line 40 – Col 5 line 6]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Hira to include 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 as disclosed by Whillock. One of ordinary skill in the art would have been motivated for the purpose of fairness and affinity in the work distribution (Whillock [Col 2 line 67]).
Re. claim 7, rejection of claim 6 is included and claim 7 is rejected with the same rationale as applied in claim 2 above.
Re. claim 12, rejection of claim 11 is included and claim 12 is rejected with the same rationale as applied in claim 2 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Miriyala (US 20220303246) discloses redirecting network traffic of virtualized application workload to a host-based firewall.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/KEVIN AYALA/Primary Examiner, Art Unit 2496
Prosecution Insights