Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-22 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding Step 1 (MPEP § 2106.03), claim 1 recites “[a] method for generating microsegmentation recommendations,” which falls within a statutory category.
Regarding Step 2A Prong One (MPEP § 2106.04), claim 1 recites “analyzing flows collected by the network monitoring service in order to generate a set of recommended firewall rules relating to the set of logical network compute nodes,” which, under its broadest reasonable interpretation, covers a mental process. See MPEP 2106.04(a)(2)(III). The analyzing may be performed in the mind but for recitation of generic computer components. For example, a human operator could data regarding “flows collected by the network monitoring service” and mentally analyze them in order to “generate a set of recommended firewall rules relating to the set of logical network compute node.” If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. See MPEP 2106.04(a)(2)(III). Accordingly, claim 1 recites an abstract idea.
Regarding Step 2A Prong Two (MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. In particular, the claim additionally recites “providing the set of recommended firewall rules to a local network manager at the particular datacenter for the local network manager to configure network elements at the particular datacenter to enforce the set of firewall rules,” which amounts to insignificant extra-solution activity of mere data gathering. See MPEP 2106.05(g). Courts have found gathering data and collecting statistics to amount to insignificant extra solution activity of mere data gathering. MPEP § 2106.05(g) (citing OIP Technologies, 788 F.3d at 1363, 115 USPQ2d at 1092-93). Accordingly, this additional element does not integrate the abstract idea into a practical application.
Regarding Step 2B (MPEP § 2106.05), claim 1 additionally recites “receiving a selection of a set of logical network compute nodes located at a particular one of the group of datacenters for which to generate recommended firewall rules” (receiving step) and “the firewall rules use compute node identifiers for logical network compute nodes located at the particular datacenter and network addresses for logical network compute nodes located at other datacenters in the group of datacenters as the local network manager does not store data regarding compute nodes located at the other datacenters” (defining firewall rules).
Regarding the receiving step, it does not amount to significantly more than an abstract idea because it amounts to insignificant extra solution activity of mere data gathering. Courts have found “[s]electing information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display” amounts to mere data gathering. MPEP § 2106.05 (citing to Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016). Here, the receiving step corresponds to the selecting information for collection in Electric Power Group, which was found to amount to mere data gathering. Accordingly, the recited “receiving a selection of a set of logical network compute nodes located at a particular one of the group of datacenters for which to generate recommended firewall rules” does not amount to significantly more than an abstract idea.
Regarding the defining firewall rules (claim 1, “the firewall rules use compute node identifiers for logical network compute nodes located at the particular datacenter and network addresses for logical network compute nodes located at other datacenters in the group of datacenters as the local network manager does not store data regarding compute nodes located at the other datacenters”), it amounts to well-understood, routine, conventional activity. See MPEP § 2106.05(d). Masurekar (US 9,755,903) discloses that “[t]he objects referenced in firewall rules are categorized into two groups. The first group of objects includes objects with identifiers that are recognized by the local network manager” (col. 2:16-19). Further, “A typical translation service translates the objects consumed in firewall rules into a set of IP addresses, MAC addresses, and VNIC universally unique identifier (UUID) based on whether the object is used in source, destination or AppliedTo field in the firewall rule” (Id. at col. 12:64-67 and col. 13:1). Therefore, in view of Masurekar, a person having ordinary skill would have found the defining firewall rules, as recited in claim 1, well-understood, routine, conventional activity. Accordingly, claim 1 does not recite additional limitations that amount to significantly more than an abstract idea.
Therefore, claim 1 is directed to ineligible subject matter.
Regarding claim 2, it merely further refines the selection of the set of logical network computer nodes. Therefore, it is directed to insignificant extra solution activity.
Regarding claim 3, it is directed to insignificant extra solution activity for the same reason as claim 2.
Regarding claim 4, it is directed to additional “analyz[ing],” which is treated under Step 2A Prong One, and amounts to the abstract idea of mentally analyzing.
Regarding claim 5, it further refines the nodes that are analyzed; therefore, it is directed to a mental process.
Regarding claim 6, it further refines the firewall rules, which does not amount to significantly more than an abstract idea.
Regarding claim 7, it is directed to receiving data, which amounts to insignificant extra solution activity of mere data gathering.
Regarding claim 8, it further refines the firewall rules, which does not amount to significantly more than an abstract idea.
Regarding claim 9, it further recites generating firewall rules and providing the rules to various components, which amounts to mere data gathering.
Regarding claim 10, is directed to receiving data, which amounts to insignificant extra solution activity.
Regarding claim 11, it is directed to defining the public cloud, which amounts to well understood routine conventional activity.
Claims 12–22 correspond to claims 1-11; therefore, they are rejected for the same reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-10 and 12-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hamou (US 2020/0036758) and further in view of Masurekar (US 9,755,903).
Regarding claim 1, Hamou teaches: A method for generating microsegmentation recommendations (¶ 24, “micro-segmentation facilitates segregation of virtual machines into virtual networks that can be managed using policies to ensure isolation and security at the network level”), the method comprising:
at a network monitoring service implemented in a public cloud to monitor data flows for a network spanning a group of datacenters (¶ 69, “management entity 160 may monitor micro-segment 160/162/164 to identify a performance issue” and ¶ 40, “management entity 160 may obtain the network flow information using any suitable cloud management solution(s)”):
analyzing flows collected by the network monitoring service in order to generate a set of recommended firewall rules relating to the set of logical network compute nodes (¶ 59, “security policies for inter-segment communication may be designed based on network flow information”); and
providing the set of recommended firewall rules to a local network manager at the particular datacenter for the local network manager to configure network elements at the particular datacenter to enforce the set of firewall rules (¶ 32, “A security policy may include one or more firewall rules for implementation by a micro-segment to protect traffic within, to or from the micro-segment” and ¶ 62, “management entity 160 configures hosts 110A-110C to implement micro-segments 160-164 and security policies 510-540”).
Hamou does not teach; however, Masurekar discloses: receiving a selection of a set of logical network compute nodes located at a particular one of the group of datacenters (col. 5:35-37, “the process receives (at 205) the identification of a set of network managers (such as network managers 151-153 in FIG. 1)”) for which to generate recommended firewall rules (col. 5:44-46, “The process then receives (at 215) firewall rules for the VMs located across the multiple data centers at the master network manager”);
wherein the firewall rules use compute node identifiers for logical network compute nodes located at the particular datacenter (col. 6:9-13, “Firewall rules in some embodiments include additional tuples such as rule number and rule name. Each grouping construct has an identifier. The grouping constructs identifiers are, for example, used in the AppliedTo tuple of firewall rules”) and network addresses for logical network compute nodes located at other datacenters in the group of datacenters (col. 14:18-21, “The translator resolves local objects by searching the local objects inventory 1362 to resolve the rules, for example, to a globally recognized IP address or a MAC address”) as the local network manager does not store data regarding compute nodes located at the other datacenters (col. 13:2-5, “The translation process resolves the objects used in firewall rules locally based on the objects present in the local inventory and not based on objects across multiple network managers in a multi datacenter environment”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of receiving a selection of a set of logical network compute nodes located at a particular one of the group of datacenters; wherein the firewall rules use compute node identifiers for logical network compute nodes located at the particular datacenter and network addresses for logical network compute nodes located at other datacenters in the group of datacenters as the local network manager does not store data regarding compute nodes located at the other datacenters., as taught by Masurekar, in the same way to the network monitoring service, as taught by Hamou. Both inventions are in the field of managing firewall rules, and combining them would have predictably resulted in a method that “provides micro-segmentation between . . . department[s],” as indicated by Masurekar (col. 11:66-67).
Regarding claim 2, Hamou teaches: The method of claim 1, wherein the selection of the set of logical network compute nodes comprises a selection of an application deployed at the particular datacenter (¶ 28, “At 210 in FIG. 2, application implementation information associated with one or more applications executed by virtual machines 131-138 may be obtained”), wherein the set of logical network compute nodes are the compute nodes that implement the selected application (¶ 28, “ownership information that sets out virtual machines' ownership of the application components (e.g., “VM1” 131 implements a web tier and “VM4” 134 implements a database tier of the same application), etc”).
Regarding claim 3, Hamou teaches: The method of claim 1, wherein the selection of the set of logical network compute nodes comprises a selection of a security group (¶ 32, “based on the application implementation information, security policies are determined for the respective detected micro-segments”), wherein the security group specifies a set of criteria and the set of logical network compute nodes comprises logical network compute nodes at the particular datacenter that match the set of criteria (¶ 31, “Clustering refers generally to a technique for partitioning a set of objects (e.g., virtual machines) into various clusters based on whether the objects have similar or dissimilar characteristics”).
Regarding claim 4, Hamou teaches: The method of claim 1, wherein the analyzed flows comprise (i) flows between pairs of compute nodes in the selected set of logical network compute nodes (¶ 28, “network flow information among components of the application (e.g., network flows between “VM1” 131 and “VM4” 134)”), (ii) flows between compute nodes in the set of logical network compute nodes and logical network compute nodes that are separate from the set of logical network compute nodes (¶ 69, “application implementation information may include network flow information relating to network flows within, to and from a particular micro-segment (e.g., within “MS1” 160, from “MS1” 160 to “MS2” 162 or DNS server 180, etc.)”), and (iii) flows between compute nodes in the set of logical network compute nodes and endpoints external to the network (¶ 69, “(e.g., within “MS1” 160, from “MS1” 160 to “MS2” 162 or DNS server 180, etc.)”).
Regarding claim 5, Masurekar teaches: The method of claim 4, wherein the logical network compute nodes that are separate from the set of logical network compute nodes comprise logical network compute nodes located in the particular datacenter and logical network compute nodes located at other datacenters in the group of datacenters (col. 2:6-8, “the VMs of a tenant are spread across multiple data centers that are managed by different compute manager servers and network manager servers”).
Regarding claim 6, Hamou teaches: The method of claim 1, wherein the set of recommended firewall rules comprises firewall rules allowing and blocking different flows in the analyzed flows (¶ 53, “a firewall rule may be recommended to allow or deny packets from a source (s) to a destination (d) based on their past communication behavior”).
Regarding claim 7, Hamou teaches: The method of claim 1 further comprising, prior to providing the set of recommended firewall rules to the local network manager (¶ 61, “micro-segments detected at block 350 and/or security policies determined at block 360 may be presented to a user (e.g., network administrator, etc.) as recommendations”), receiving input specifying to publish the set of recommended firewall rules (¶ 61, “The user may then review the recommendations, and make any necessary changes based on other considerations”).
Regarding claim 8, Masurekar teaches: The method of claim 1, wherein the particular datacenter is a first datacenter (col. 2:25-27, “The first inventory of objects in each data center is an inventory of the locally defined and recognized objects for that data center”), wherein the set of firewall rules comprises a first rule that specifies an action to take for flows between a first logical network compute node located at the first datacenter and a second logical network compute node located at a second, different datacenter in the group of datacenters (col. 5:50-52, “Typically, firewall rule definitions include the following five tuples: source, source port, destination, destination port, and service (or application), in addition to an action value”), the first rule as provided to the local network manager using a first compute node identifier for the first logical network compute node and a first network address for the second logical network compute node (col. 14:18-21, “The translator resolves local objects by searching the local objects inventory 1362 to resolve the rules, for example, to a globally recognized IP address or a MAC address”).
Regarding claim 9, Masurekar teaches: The method of claim 8, wherein the set of recommended firewall rules is a first set of recommended firewall rules generated for a first set of logical network compute nodes and the local network manager is a first local network manager, the method further comprising: generating a second set of recommended firewall rules (col. 5:44-46, “The process then receives (at 215) firewall rules for the VMs located across the multiple data centers at the master network manager”) for a second set of logical network compute nodes located at the second datacenter and including the second logical network compute node (col. 5:35-37, “the process receives (at 205) the identification of a set of network managers (such as network managers 151-153 in FIG. 1)”); and providing the second set of recommended rules to a second local network manager at the second datacenter for the second local network manager to configure network elements at the second datacenter to enforce the second set of firewall rules (col. 8:23-26, “a set of global rules defined at another data center (e.g., data center 101 in FIG. 1 that includes the master network manager 151) are synchronized with the firewall rules in data center A”), wherein the second set of firewall rules comprises a second rule that specifies an action to take for flows between the second logical network compute node and the first logical network compute node (col. 2:11-12, “The firewall rules typically include several tuples and an action”), the second rule as provided to the second local network manager using a second compute node identifier for the second logical network compute node and a second network address for the first logical network compute node (col. 14:18-21, “The translator resolves local objects by searching the local objects inventory 1362 to resolve the rules, for example, to a globally recognized IP address or a MAC address”).
Regarding claim 10, Hamou teaches: The method of claim 1, wherein the network monitoring service receives data flow information from computing devices hosting logical network compute nodes at the group of datacenters (¶ 38, “At 310 in FIG. 3, management entity 160 obtains network flow information (i.e., an example of application implementation information in FIG. 2) associated with one or more applications executed by a set of N virtual machines from collector 170”).
Claims 12-21 recite commensurate subject matter as claims 1-10. Therefore, they are rejected for the same reasons.
Claim(s) 11 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hamou and Masurekar, as applied above, and further in view of Baddepudi (US 11,095,714).
Regarding claim 11, Hamou and Masurekar do not teach; however, Baddepudi discloses: the public cloud is a first public cloud (col. 4:18-21, “Examples of such diverse cloud infrastructures include, but are not limited to, public clouds such as Amazon Web Services (AWS) Cloud available from Amazon.com, Inc.”), wherein the group of datacenters comprises at least (i) a virtual datacenter implemented for an entity in a second public cloud (col. 1:39-42, “Cloud infrastructure refers to a collection of processing nodes, connectivity infrastructure, data storages, etc., which are engineered to together provide a virtual computing infrastructure for various customers”) and (ii) a physical on-premises datacenter of the entity (col. 4:20-23, “private clouds such as On-Premises clouds owned by the customers”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the public cloud is a first public cloud, wherein the group of datacenters comprises at least (i) a virtual datacenter implemented for an entity in a second public cloud and (ii) a physical on-premises datacenter of the entity, as taught by Baddepudi, in the same way to the public cloud and group of datacenters, as taught by Hamou and Masurekar. Both inventions are in the field of managing clouds and datacenters, and combining them would have predictably resulted in “orchestration of data services in multiple cloud infrastructures,” as indicated by Baddepudi (col. 1:34-35).
Claims 22 recites commensurate subject matter as claim 11. Therefore, it is rejected for the same reason.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Maheve (US 11,888,890) discloses “a persistent connection may be established between a threat management facility and a zero trust network access (ZTNA) gateway using, for example a WebSocket connection” in lines 16-19 of column 25, which is relevant to the unclaimed feature of establishing persistent bidirectional connections (disclosed in paragraph [0015] of the specification).
Srinivasan (US 9,069,979) discloses “single LDAP directory can store identities for entities for all tenants, in separate partitions or subtrees of the LDAP directory, each such partition or subtree being dedicated to a separate identity domain for a tenant” in lines 45-–48 of column 2, which is relevant to the unclaimed feature of structuring policy configurations as hierarchical policy trees with dedicated subtrees (disclosed in paragraph [0035] of the specification).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/ Primary Examiner, Art Unit 2198