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 .
DETAILED ACTION
The present office action is responsive to communications received on 11/07/2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/11/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Status of Claims
Claims 1-20 are pending.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
(a)(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.
Claim(s) 1,4, 6, 8, 11, 13, 15, 17 and 19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stienhans et al. (US 20100042720 A1) hereinafter referred to as Stienhans.
With respect to claim 1, Stienhans discloses: A method for communicating data across multi-cloud platforms, wherein, the method is applied to a multi-cloud management platform, which connects with one or more private clouds and one or more public clouds, and the method comprises: (Stienhans Fig. 2 illustrates establishing communication in multi-cloud “A, B, C …” Wherein ¶3 “A cloud-based computing resource is thought to execute or reside somewhere on the "cloud", which may be an internal corporate network [private clouds] or the public Internet [public clouds].”)
receiving a first set of initial configuration instructions issued by a configuration user to the one or more private clouds; (Stienhans ¶16 “a user or administrator [configuration user] can utilize a common interface to configure and provision computer resources [initial configuration instructions] on any one of several clouds [one or more private clouds], regardless of whether the cloud is an enterprise-maintained cloud, or a third-party cloud”)
receiving a second set of initial configuration instructions issued by the configuration user to the one or more public clouds; (It can be understood from the mapping above that each cloud has its own provisioning configuration and Stienhans ¶16 explicitly discloses provisioning instructions on a cloud of any one of several clouds).
wherein, the first set of initial configuration instructions and the second set of initial configuration instructions are to enable a first data communication across the one or more private clouds and the one or more public clouds, and are compiled based on an initial configuration format supported by the multi-cloud management platform; (Stienhans ¶16 teaches the provisioning configuration instructions is to enable communication between clouds. Stienhans ¶18 teaches the need for formatting, that initial configuration, instructions to accommodate different cloud(s) when reciting “The cloud-based service offerings are heterogeneous in the sense that each cloud may have different administrative or provisioning interfaces implemented with different application programming interfaces (APIs). Additionally, the underlying virtualization software for each cloud may be different thereby requiring variations in the particular configuration settings and/or formats for the machine images upon which each instance of a virtual server or virtual appliance is based.”).
converting the first set of initial configuration instructions into a first set of configuration instructions with a first configuration format, and the second set of initial configuration instructions into a second set of configuration instructions with a second configuration format based on a preset conversion policy; (Stienhans ¶36 “For example, the request, which is initially received in a non-cloud-specific format is converted into one or more provisioning commands that are compatible with the particular cloud to which the request is ultimately directed.” Wherein converting a “non-cloud-specific format” to a format that is compatible with a particular cloud is interpreted as preset conversion policy).
wherein the first configuration format is supported by the one or more private clouds and the second configuration format is supported by the one or more public clouds; (Stienhans ¶36 discloses the solution for “provisioning commands compatible [supported] with the cloud management module of the particular cloud” wherein the particular cloud refers to the number of provisioning configuration receiving clouds which are public and/or private clouds as disclosed by Stienhans Fig. 2 and ¶3).
issuing the first set of configuration instructions to the one or more private clouds; and issuing the second set of configuration instructions to the one or more public clouds. (Stienhans ¶36 “Finally, at method operation 78, the cloud-specific provisioning command(s) are communicated [issuing] from the multi-cloud management module to the specific cloud [public/private cloud(s)], thereby enabling the cloud management module of the specific cloud to execute the provisioning commands and provision the appropriate cloud-based computing resource.”)
Claims 8 and 15 recite an apparatus and A non-transitory computer-readable storage medium respectively. While the claims might have slight difference in language, still they recite the same matter as claim 1 and are therefore rejected based on the same rationale.
With respect to claim 4, Stienhans discloses: The method according to claim 1, wherein the converting the first set of initial configuration instructions into the first set of configuration instructions with the first configuration format, and the second set of initial configuration instructions into the second set of configuration instructions with the second configuration format based on the preset conversion policy, comprises: determining the first configuration format supported by the one or more private clouds and the second configuration format supported by the one or more public clouds based on a pre-transmitted registration information of the one or more private clouds and the one or more public clouds; (Stienhans ¶18 teaches format converting API adapters installed [pre-transmitted registration] for conversion “provisioning interfaces implemented with different application programming interfaces (APIs) … each cloud may be different thereby requiring variations in the particular configuration settings and/or formats for the machine images upon which each instance of a virtual server or virtual appliance is based.”).
converting the first set of initial configuration instructions compiled in the initial configuration format into the first set of configuration instructions compiled in the first configuration format, based on using a first format mapping relationship recorded in the preset conversion policy between the initial configuration format and the first configuration format; (using the different APIs for each cloud recited in ¶18 the data is converted to compatible format for each type/different of cloud; Stienhans ¶36 “For example, the request, which is initially received in a non-cloud-specific format is converted into one or more provisioning commands that are compatible with the particular cloud to which the request is ultimately directed.” Wherein converting a “non-cloud-specific format” to a format that is compatible with a particular cloud is interpreted as preset conversion policy).
and converting the second set of initial configuration instructions complied in the initial configuration format into the second set of configuration instructions compiled in the second configuration format, based on a second format mapping relationship recorded in the preset conversion policy between the initial configuration format and the second configuration format. (using the different APIs for each cloud recited in ¶18 the data is converted to compatible format for each type/different of cloud; Stienhans ¶36 “For example, the request, which is initially received in a non-cloud-specific format is converted into one or more provisioning commands that are compatible with the particular cloud to which the request is ultimately directed.” Wherein converting a “non-cloud-specific format” to a format that is compatible with a particular cloud is interpreted as preset conversion policy).
Claims 11 and 17 recite an apparatus and A non-transitory computer-readable storage medium respectively. While the claims might have slight difference in language, still they recite the same matter as claim 4 and are therefore rejected based on the same rationale.
With respect to claim 6, Stienhans discloses: The method according to claim 1, wherein issuing the first set of configuration instructions to the one or more private clouds, and issuing the second set of configuration instructions to the one or more public clouds, comprises: issuing the first set of configuration instructions to a Software-Defined Network (SDN) controller in the one or more private clouds; (The commands are issued through “cloud management module(s) 50” [SDN controller] of “VPN service” illustrated in Stienhans Fig. 2).
and issuing the second set of configuration instructions to a cloud computing platform service in the one or more public clouds. (Stienhans ¶23 “the multi-cloud management module 22 includes a variety of processing modules (e.g., processing modules 30, 32, 34, 36 and 38). These processing modules allow third-party cloud-based services to be better integrated with existing enterprise infrastructure … to execute various administrative and provisioning commands”)
Claims 13 and 19 recite an apparatus and A non-transitory computer-readable storage medium respectively. While the claims might have slight difference in language, still they recite the same matter as claim 6 and are therefore rejected based on the same rationale.
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) 2-3, 9-10 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stienhans as applied to claims 1,4, 6, 8, 11, 13, 15, 17 and 19 above, and further in view of Ritchie (US 20210058290 A1) hereinafter referred to as Ritchie.
With respect to claim 2, Stienhans discloses: The method according to claim 1, wherein the receiving the first set of initial configuration instructions issued by the configuration user to the one or more private clouds comprises: receiving the first set of initial configuration instructions issued by the configuration user, the first set of initial configuration instructions being to instruct the one or more private clouds to configure a first set of network parameters and establish a communication channel; (Stienhans ¶28 to establish a communication channel “the configuration management module 34 keeps track of various configuration parameters associated with different cloud-based computing resources. For instance, in some cases, certain cloud-based computing resources may require that certain configuration settings be provided when the resource is initially provisioned.”).
the receiving the second set of initial configuration instructions issued by the configuration user to the one or more public clouds comprises: receiving the second set of initial configuration instructions issued by the configuration user, the second set of initial configuration instructions being to instruct the one or more public clouds to configure a second set of network parameters and connect to the communication channel. (Stienhans ¶28 to establish/connect to a communication channel “the configuration management module 34 keeps track of various configuration parameters associated with different cloud-based computing resources. For instance, in some cases, certain cloud-based computing resources may require that certain configuration settings be provided when the resource is initially provisioned.”).
Stienhans does not explicitly disclose: wherein the communication channel is an encrypted channel for the first data communication across the one or more private clouds and the one or more public clouds;
However, Ritchie in an analogous art discloses: wherein the communication channel is an encrypted channel for the first data communication across the one or more private clouds and the one or more public clouds; (Ritchie ¶28 teaches configuration attributes to allow clouds to communicate with each other, which comprises “communication protocols and/or encryption used by the cloud”).
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 public/private clouds communication taught by Stienhans wherein the communication channel is an encrypted channel for the first data communication across the one or more private clouds and the one or more public clouds as disclosed by Ritchie to allow for more control over different encryption or communication protocols to use between entities like public and private clouds (Ritchie ¶28).
Claims 9 and 16 recite an apparatus and A non-transitory computer-readable storage medium respectively. While the claims might have slight difference in language, still they recite the same matter as claim 2 and are therefore rejected based on the same rationale.
With respect to claim 3, Stienhans and Ritchie disclose: The method according to claim 2, wherein the first set of initial configuration instructions comprises: address parameters and encryption policy parameters of first intercommunication nodes, and subnet information and routing information used for routing data packet flows among the first intercommunication nodes, wherein the first intercommunication nodes locate in the one or more private clouds and perform the first data communication with the one or more public clouds; (Ritchie ¶28 teaches address and encryption configuration while Richie ¶48 teaches “Configuration of the cloud service provider may include, but is not limited to, transmitting requests to the cloud service provider to configure a communication device of the provider to receive communication from the network 102, verifying customer information and rights to configure the cloud service provider, requesting one or more cloud computing services from the cloud service provider (such as a storage service, a networking service, a computing service, a security service, and the like), requesting a Virtual Private Network (VPN) connection, and any other requests accepted by a cloud service provider. Other configurations of endpoints , such as customer network 104 [routing information], data center A 114, data center B 116 [subnet information], etc., may include the same or similar configuration as discussed above in relation to network devices, including requesting a layer 2 interface, a layer 3 interface, one or more firewall rules, an aspect of a virtual connection, and the like.”).
and, a first set of channel parameters used for instructing a first channel node to establish the communication channel, wherein the first channel node is a firewall, a router, or a Virtual Private Network (VPN) gateway in the private cloud, (Ritchie ¶17 “connection parameters. The combination of the endpoint devices or networks and the intermediate network elements define the layer 3 connections, which may be across a core network of preexisting network elements. Core network elements may include provider edge devices, switches, routers, virtual gateway devices, virtual private cloud interfaces, and the like.”).
Claim(s) 10 recites an apparatus. While the claim might have slight difference in language, still they recite the same matter as claim 3 and therefore rejected based on the same rationale.
Claim(s) 5, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stienhans as applied to claims 1,4, 6, 8, 11, 13, 15, 17 and 19 above, and further in view of Yoshida (US 20200065129 A1) hereinafter referred to as Yoshida.
With respect to claim 5, Stienhans discloses: The method according to claim 4, wherein the method further comprises:
Stienhans does not explicitly disclose: converting the node names
However, Yoshida in an analogous art disclsoes: obtaining first initial node names corresponding to first intercommunication nodes and comprised in the first set of initial configuration instructions; and obtaining second initial node names corresponding to second intercommunication nodes and comprised in the second set of initial configuration instructions; (Yoshida ¶84 obtaining names of cloud(s) with “The request message analyzing section 124 performs format conversion into a request message corresponding to a transmission destination according to a request to obtain charging information or a monitoring observation value of the CPU or the memory from the VM. The format conversion converts an instruction name, an argument, or the like.”)
wherein the first intercommunication nodes locate in the one or more private clouds and perform the first data communication with the one or more public clouds, and the second intercommunication nodes locate in the one or more public clouds and perform a second data communication with the one or more private clouds; converting the first initial node names into first node names recognizable for the one or more private clouds, and converting the second initial node names into second node names recognizable for the one or more public clouds, based on the preset conversion policy. (Yoshida ¶111 “the request message analyzing section 124 first transmits, to the management information converting section 125, a request to obtain the instance ID of a management target registered as the same tenant system as the VM 131 and information (cloud ID) of the location of the instance ID.” In this regard the instance ID or cloud ID can be interpreted as the name).
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 public/private clouds communication taught by Stienhans with converting the node names as taught by Yoshida to allow for compatible cloud names to identify destination cloud(s) (see Yoshida ¶111).
Claims 12 and 18 recite an apparatus and A non-transitory computer-readable storage medium respectively. While the claims might have slight difference in language, still they recite the same matter as claim 5 and are therefore rejected based on the same rationale.
Claim(s) 7, 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stienhans as applied to claims 1,4, 6, 8, 11, 13, 15, 17 and 19 above, and further in view of Ranjbar et al. (US 20200267051 A1) hereinafter referred to as Ranjbar.
With respect to claim 7, Stienhans discloses: The method according to claim 1,
Stienhans does not explicitly disclose: wherein prior to receiving initial configuration instructions issued by the configuration user, the method further comprises: receiving registration information transmitted by the one or more clouds, wherein the registration information comprises the first configuration format supported by the one or more private clouds and address information of the SDN controller;
However, Ranjbar in an analogous art discloses: wherein prior to receiving the first set of initial configuration instructions issued by the configuration user and receiving the second set of the initial configuration instructions issued by the configuration user, the method further comprises: receiving first registration information transmitted by the one or more private clouds, wherein the first registration information comprises the first configuration format supported by the one or more private clouds and address information of the SDN controller; (Ranjbar ¶36 teaches operator network receiving “addresses of SDN switches 108 and mapping [format]” in order to communicated which is used later on for communication; because otherwise communication would not be possible without that information with the SDN switches of the different clouds illustrated in Ranjbar Fig. 1).
receiving second registration information transmitted by the one or more public clouds, wherein the second registration information comprises the second configuration format supported by the one or more public clouds and credential information for the cloud computing platform service. (Ranjbar ¶36 teaches operator network [configuration user network] receiving “addresses of SDN switches 108 and mapping [format]” in order to communicated which is used later on for communication; because otherwise communication would not be possible without that information with the SDN switches of the different clouds illustrated in Ranjbar Fig. 1).
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 public/private clouds communication taught by Stienhans wherein prior to receiving initial configuration instructions issued by the configuration user, the method further comprises: receiving registration information transmitted by the one or more clouds, wherein the registration information comprises the first configuration format supported by the one or more private clouds and address information of the SDN controller as disclosed by Ranjbar to allow for communication and establishing certain mapping/format for communication prior to sending commands by the operator (see Ranjbar ¶36 and Fig. 1).
Claims 14 and 20 recite an apparatus and A non-transitory computer-readable storage medium respectively. While the claims might have slight difference in language, still they recite the same matter as claim 7 and are therefore rejected based on the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Cherkas (US 20230179495 A1) ¶76 “receive user input, and a listing 428 of construct parameters including whether the construct is encrypted, the cloud provider of the construct, the gateway name associated with the construct, the VPC identifier associated with the construct, the cloud type of the construct, the VPC region of the construct, whether the construct is a transit VPC, etc. It should be noted that the construct parameters may correspond to the construct metadata received by the controller 102 as discussed above and is not limited to the parameters illustrated in the drawings. Instead, the disclosure includes all parameters of the selected construct. As is known in the art, a transit VPC operates to connect multiple VPCs and/or remote networks.”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANY S GADALLA whose telephone number is (571)272-2322. The examiner can normally be reached Mon to Fri 8:00AM - 4:00PM.
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, Carl Colin can be reached at (571) 272-3862. 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.
/HANY S. GADALLA/Primary Examiner, Art Unit 2493