DETAILED ACTION
This office action is in response to the original application filed on July 29, 2024.
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 .
Claims 1-20 have been cancelled.
Claims 21-40 are pending.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-14 of U.S. Patent No. 12,081,523. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application and ‘523 is directed to a method for managing firewall rules between different services.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 21-22, 24-30 and 32-40 are rejected under 35 U.S.C. 103 as being unpatentable over Leviseur (US 11,265,292) in view of Venkiteswaran (US Pub. No. 2020/0351176).
As per claim 21 Leviseur discloses:
A computer-implemented method for managing firewall rules between different services, the method comprising: determining a first service running on a first virtual private cloud (VPC) environment and a second service running on a second VPC environment; (column 25, line 45-55 of Leviseur, the server computer may manage (and/or deploy) an instance of the virtualized infrastructure in the service provider environment using the graph stored in the graph database. Management of the instance of the virtualized infrastructure may include deploying the virtualized infrastructure onto physical devices (e.g., launching computing instances), configuring initial and subsequent states for virtualized infrastructure resources by setting parameters derived from the graph, starting, stopping, and migrating virtualized infrastructure resources) and (column 28, line 34-40 of Leviseur, some examples of filtering traffic coming into and out of a virtualized infrastructure resource may include allowing traffic, denying traffic, dropping traffic, forwarding traffic, translating traffic, mangling traffic) and (Column 21 line 65-67, the computing service 500 may be established for an organization by or on behalf of the organization. That is, the computing service 500 may offer a “private cloud environment.”).
In response to determining that the first service depends on the at least one application programming interface (API) of the second service, configuring one or more rules for a firewall between the first VPC environment and the second VPC environment to allow an initial communication from the first service to the second service; (Column 28, line 28-34 of Leviseur, the server computer may configure a security group with a firewall rule that is associated with the virtual network interface using the set of parameters. The security group may be associated with a virtualized infrastructure resource and provide security at the protocol and port access level. The security group may operate as a firewall and contain a set of firewall rules that filter traffic coming into and out of a virtualized infrastructure resource) and (column 28, line 34-40 of Leviseur, some examples of filtering traffic coming into and out of a virtualized infrastructure resource may include allowing traffic, denying traffic, dropping traffic, forwarding traffic, translating traffic, mangling traffic) and (Column 21 line 65-67, the computing service 500 may be established for an organization by or on behalf of the organization. That is, the computing service 500 may offer a “private cloud environment.”).
Establishing a virtual private connection between the first VPC environment and second VPC environment based on the one or more rules of the firewall. (Column 24, line 56-61, the graph may include a first node representing the first virtualized infrastructure resource (and/or the first virtual network interface corresponding thereto) and a second node representing the second virtualized infrastructure resource (and/or the second virtual network interface corresponding thereto)).
Leviseur teaches the method of having API in relation to the received graph (column 16, line 58-63 of Leviseur) but fails to clearly disclose:
Determining whether a first service depends on at least one application programming interface (API) of a second service.
However, in the same field of endeavor, Venkiteswaran teaches this limitation as, (paragraph 70 of Venkiteswaran, at 412, one or more data values are retrieved from the one or more APIs based on the data dependency graph. According to various embodiments, the one or more data values may be retrieved by transmitting one or more of the input parameters determined at 410 to the appropriate API specified in the data dependency graph).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Leviseur and include the above limitation using the teaching of Venkiteswaran in order to securely retrieve information by one device (i.e., client) from another device (i.e., server) (see paragraph 40 of Venkiteswaran).
Claims 29 and 37 are rejected under the same reason set forth in rejection of claim 21:
As per claim 22 Leviseur in view of Venkiteswaran discloses:
The computer-implemented method of claim 1, wherein the first VPC environment is distinct from the second VPC environment. (Column 24, line 56-61, the graph may include a first node representing the first virtualized infrastructure resource (and/or the first virtual network interface corresponding thereto) and a second node representing the second virtualized infrastructure resource (and/or the second virtual network interface corresponding thereto)).
Claim 30 is rejected under the same reason set forth in rejection of claim 22.
As per claim 24 Leviseur in view of Venkiteswaran discloses:
The computer-implemented method of claim 21, further comprising: receiving a discovery graph comprising a plurality of services and one or more application programming interface (API) dependencies, wherein the plurality of services comprises the first service and the second service. (Column 26, line 22-30 of Leviseur, a server computer or service in the service provider environment may receive a graph representing virtualized infrastructure resources and application dataflows in a virtualized infrastructure in the service provider environment) and (column 16, line 58-63 of Leviseur, the infrastructure mapping service 310 may provide a mapping service API 324 to enable the user or service to make API calls to the infrastructure mapping service 310, for example, to interact with the graph modeling module 320 and the graph management module 322).
Claims 32 and 38 are rejected under the same reason set forth in rejection of claim 24.
As per claim 25 Leviseur in view of Venkiteswaran discloses:
The computer-implemented method of claim 24, wherein the determining whether a first service running on a first virtual private cloud (VPC) environment depends on at least one application programming interface (API) of a second service running on a second VPC environment comprises determining whether the first service running on the first virtual private cloud (VPC) environment depends on at least one application programming interface (API) of the second service running on the second VPC environment based on the discovery graph. (Column 26, line 22-30 of Leviseur, a server computer or service in the service provider environment may receive a graph representing virtualized infrastructure resources and application dataflows in a virtualized infrastructure in the service provider environment) and (column 16, line 58-63 of Leviseur, the infrastructure mapping service 310 may provide a mapping service API 324 to enable the user or service to make API calls to the infrastructure mapping service 310, for example, to interact with the graph modeling module 320 and the graph management module 322).
Claims 33 and 39 are rejected under the same reason set forth in rejection of claim 25:
As per claim 26 Leviseur in view of Venkiteswaran discloses:
The computer-implemented method of claim 21, further comprising: in response to determining that the first service does not depend on any application programming interface (API) of the second service, configuring the one or more rules for the firewall to restrict the second service from receiving the initial communication from the first service. (Column 28, line 34-40 of Leviseur, some examples of filtering traffic coming into and out of a virtualized infrastructure resource may include allowing traffic, denying traffic, dropping traffic, forwarding traffic, translating traffic, mangling traffic).
Claims 34 and 40 are rejected under the same reason set forth in rejection of claim 26:
As per claim 27 Leviseur in view of Venkiteswaran discloses:
The computer-implemented method of claim 24, further comprising dynamically updating the discovery graph in response to a change in the one or more API dependencies. (Column 14, line 13-18, modifications may be made to the infrastructure graph(s) 270 by users of the accounts in the service provider environment 200. The infrastructure deployment service 210 and the infrastructure management service 212 may utilize the modifications to the infrastructure graph(s) 270 to derive and modify configurations for the virtualized infrastructure(s) 204).
Claim 35 is rejected under the same reason set forth in rejection of claim 27:
As per claim 28 Leviseur in view of Venkiteswaran discloses:
The computer-implemented method of claim 27, further comprising: in response to determining that the second service is no longer permitted to receive the initial communication from the first service based upon the change in the one or more API dependencies, configuring the one or more rules for the firewall to restrict the second service from receiving the initial communication from the first service; (Column 28, line 34-40 of Leviseur, some examples of filtering traffic coming into and out of a virtualized infrastructure resource may include allowing traffic, denying traffic, dropping traffic, forwarding traffic, translating traffic, mangling traffic).
In response to determining that the second service is permitted to receive the initial communication from the first service based upon the change in the one or more API dependencies, configuring the one or more rules for the firewall to allow the second service to receive the initial communication from the first service. (Column 28, line 34-40 of Leviseur, some examples of filtering traffic coming into and out of a virtualized infrastructure resource may include allowing traffic, denying traffic, dropping traffic, forwarding traffic, translating traffic, mangling traffic).
Claim 36 is rejected under the same reason set forth in rejection of claim 28:
Claims 23 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Leviseur (US 11,265,292) in view of Venkiteswaran (US Pub. No. 2020/0351176) further in view of Azimi (US 11,062,700).
As per claim 23:
The combination of Leviseur and Venkiteswaran teaches the method of having API in relation to the received graph (column 16, line 58-63 of Leviseur) but fails to disclose:
The computer-implemented method of claim 21, wherein the initial communication is a one-way communication from the first service to the second service.
However, in the same field of endeavor, Azimi teaches this limitation as, (column 17, line 7-19 of Azimi, the access control component 148 may be any suitable component, system or other element to provide a one-way connection in this way. For example, the first KG 144 may be stored on a different and/or separate server than the second KG 146. The first KG 144 may therefore be hosted within a first virtual private cloud (VPC) and the second KG 146 may be hosted with a second VPC, with a VPC peering connection between the two VPCs, which acts as the access control component 148. A VPC peering connection is for example a network connection between two VPCs, which may be configured to allow two-way or (in this case) one-way traffic between the VPCs).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Leviseur and include the above limitation using the teaching of Venkiteswaran in order to securely retrieve information by one device (i.e., client) from another device (i.e., server) (see paragraph 40 of Venkiteswaran).
Claim 31 is rejected under the same reason set forth in rejection of claim 23:
Conclusion
The prior art made or record and not relied upon is considered pertinent to applicant’s disclosure is Levin (US 11,467,034). Levin discloses:
Enriched access data supports anomaly detection to enhance network cybersecurity. Network access data is enriched using service nodes representing resource provision and other services, with geolocation nodes representing grouped access origins, and access values representing access legitimacy confidence. Data enrichment provides a trained model by mapping IP addresses to geolocations, building a bipartite access graph whose inter-node links indicate aspects of accesses from geolocations to services, and generating semantic vectors from the graph. Vector generation may include collaborative filtering, autoencoding, neural net embedding, and other machine learning tools and techniques. Anomaly detection systems then calculate service-geolocation or geolocation-geolocation vector distances with anomaly candidate vectors and the model's graph-based vectors, and treat distances past a threshold as anomaly indicators. Some embodiments curtail false positives relative to simply checking network access logs or packets for activity coming from unexpected places. Some avoid or reduce model retraining.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TESHOME HAILU whose telephone number is (571)270-3159. The examiner can normally be reached M-F 8 a.m. - 5 p.m..
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, Kambiz Zand can be reached at (571) 272-3811. 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.
/TESHOME HAILU/Primary Examiner, Art Unit 2434