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 .
This written action is responding to the communication dated on 04/21/2026.
Claims 1-2 and 11-12 have been amended and all other claims are previously presented.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
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.
Priority
This application filed on April 22, 2024 claims priority of Provisional application 63/609,196 filed on December 12, 2023.
Information Disclosure Statement
The following Information Disclosure Statements in the instant application submitted in compliance with the provisions of 37 CFR 1.97, and thus, have been fully considered:
IDS filed on 22 April 2024.
Response to Arguments
Applicant’s amendment, filed on April 21, 2026 has claim 1-2 and 11-12 amended and all other claims are previously presented.
Applicant’s remark, filed on April 21, 2026 on top of page 9 regarding, “"in response to receiving a start message to start a first instance of a gateway service, transmitting a boot message to a cloud service provider to cause the cloud service provider to boot an image corresponding to the gateway service." The art of record does not teach or suggest at least this limitation” has been considered, however is not found persuasive. Crouse teaches, “a client can request that an instance is added to a cluster by sending a message to the cloud service provider application programming interface (API). If the instance is hosted within a customer partition, the request can identify the instance by an address such as an internet protocol version 4 (IPv4) or an internet protocol version 6 (IPv6) address. The request can include an instance image for the new instance (e.g., an image file) or the request can include an address for the instance image so that the cloud service provider application programming interface can retrieve the instance image”. (Fig. 2, ¶32). “The cloud service provider can launch the instance. The instance can be launched within the cloud service provider partition or in the customer partition. An instance that is within the cloud service provider can be an instance that is hosted on premises that are controlled by the cloud service provider (e.g., a data center), and an instance that is within the customer partition can be an instance that is hosted by computing hardware that is located within a facility that is not controlled by the cloud service provider. Hardware can be controlled by the cloud service provider if the computing hardware is located in a facility that is managed by the cloud service provider's employees or by workers that are contracted by the cloud service provider. Launching the instance can mean providing the instance with at least one of an address for the control plane and an authentication credential. In some embodiments, launching the instance can include provisioning computing hardware and/or software to host the instance and adding the instance to the cloud service provider partition or the customer partition”. (Fig. 2, ¶34). Crouse further teaches, “The control plane VCN can include a control plane demilitarized zone (DMZ) tier that acts as a perimeter network (e.g., portions of a corporate network between the corporate intranet and external networks). The DMZ-based servers may have restricted responsibilities and help keep breaches contained. Additionally, the DMZ tier can include one or more load balancer (LB) subnet(s), a control plane app tier that can include app subnet(s), a control plane data tier that can include database (DB) subnet(s) (e.g., frontend DB subnet(s) and/or backend DB subnet(s)). The LB subnet(s) contained in the control plane DMZ tier can be communicatively coupled to the app subnet(s) contained in the control plane app tier and an Internet gateway that can be contained in the control plane VCN, and the app subnet(s) can be communicatively coupled to the DB subnet(s) contained in the control plane data tier and a service gateway and a network address translation (NAT) gateway. The control plane VCN can include the service gateway and the NAT gateway”. (Fig. 4, ¶54). Alfonso teaches, “the IaaS platform stores the image package. In one embodiment, the IaaS platform installs the application resources using the image packages. In one embodiment, the application resource is a node host of the PaaS system. In one embodiment, the node host is the VM. As discussed above, an image package includes an image file that has pre-installed packages to run a VM or a physical system. In one embodiment, the image package is modified to customize the VM for the application resource. The image package may be modified to include elements associated with configurations and settings of the application resources. As such, the image package includes a script file including a plurality of software updates and a plurality of runtime configuration files (e.g., in the form of executable script files or other binary applications executable by a VM instance bootstrap process). In one embodiment, the script file includes parameters indicating that the script file is to configure the VM as a node host and the script file is downloaded as a node host in the PaaS system. In one embodiment, the parameters may vary based on type of the node hosts”. (¶27). Alfonso further teaches, “an orchestration service may implement loading script files into images of VM instances described herein. In one embodiment, the VM instance runs an operating system with the script file having the software installed and configured to manage all services that enable the PaaS system. For every instance to be built, orchestration service may retrieve script file from the image package to be injected into the instance. As, as discussed above, the image package may be a registered node image package. The runtime script file may specify its target location (e.g., the full file system path and the filename) within the VM instance, so that a VM instance bootstrap process would be able to reference the script file after the script file has been successfully injected into the VM instance. In one embodiment, the VM instance bootstrap process is an installation process, which applies the script file including the software updates as well as runtime configuration specific to a single VM during start up. In one embodiment, the file target location is the PaaS system. (¶31). “The orchestration service may communicate the script file to the VM instance, thus causing the VM instance bootstrap process to download the script file into the PaaS system within the VM instance. The VM instance bootstrap process may process an element by downloading the script file and placing the script file into PaaS system. After the script file has been successfully downloaded and placed into the PaaS system, the VM instance bootstrap process may use the downloaded files, e.g., by executing runtime agent scripts and/or retrieving configuration data from the downloaded files.. (Fig. 2, ¶34). “A script file from the image package is retrieved from the storage memory. The boot process of the VM instance (i.e. the VM instance bootstrap process) is caused to download the script file as a node into the PaaS system. When a VM is started up for the first time, the VM instance bootstrap process runs the script file, which downloads the software updates and the configurations to be installed on the VM. In one embodiment, VM instance bootstrap process references the script file injected into the VM instance“. (Fig. 3, ¶41). Thus combination of Crouse and Alfonso teaches the limitation, “in response to receiving a start message to start a first instance of a gateway service, transmitting a boot message to a cloud service provider to cause the cloud service provider to boot an image corresponding to the gateway service”. The motivation/suggestion for doing so would be to automatically installing and scaling of application resources in a multi-tenant Platform-as-a-Service (PaaS) environment in a cloud computing system.
Applicant’s remark, filed on April 21, 2026 on top of page 10 regarding, “"the boot message including boot script information and key information for authenticating the first instance." The art of record does not teach or suggest at least this limitation”, has been considered, however is not found persuasive. Crouse teaches, “When launching the instance, the customer can provide the instance with cluster credentials and an address for the control plane associated with the cluster. The cluster credentials can include at least one of a cluster identifier, a transport layer security (TLS) key, or a signed certificate”. (¶21). “After deciding on an instance image and shape for the new instances, the customer obtains permission for the new instances to join the cluster by adding the instances to the group associated with the cluster. In this case, the group is a static group, and the customer adds the instances to the group by adding entries in the group table named “new_instance1” and “new_instance2.” Once permission has been obtained, the customer launches the instances using the custom shape and instance image and names them “new_instance1” and “new_instance2.” The customer obtains authentication credentials for each instance from the cloud service provider including a transport layer security key, a signed certificate, an address for the control plane associated with the cluster, and a cluster identifier. The customer provides these authentication credentials to the instances and the instances provides these credentials to the control plane so that the new instances can be authenticated.”. (¶23). “The instance can request authentication from the control plane. The request for authentication that is sent from the instance to the control plane can comprise at least the authentication credential and the request can be sent to the address from. The authentication can be a token or certificate that has been signed by a private key. The control plane can verify the validity of the authentication token with a public key that corresponds to the private key.”. (¶35). “The first instance can be added to the cluster identified in the request. The first instance can be an instance such as instance 110a, instance 110b, instance 110c, instance 110d, or instance 215. Authenticating the first instance can include verifying the authentication credential from using a private key associated with the cluster identified”. (Fig. 3, ¶43). Alfonso teaches, “the IaaS platform stores the image package. In one embodiment, the IaaS platform installs the application resources using the image packages. In one embodiment, the application resource is a node host of the PaaS system. In one embodiment, the node host is the VM. As discussed above, an image package includes an image file that has pre-installed packages to run a VM or a physical system. In one embodiment, the image package is modified to customize the VM for the application resource. The image package may be modified to include elements associated with configurations and settings of the application resources. As such, the image package includes a script file including a plurality of software updates and a plurality of runtime configuration files (e.g., in the form of executable script files or other binary applications executable by a VM instance bootstrap process). In one embodiment, the script file includes parameters indicating that the script file is to configure the VM as a node host and the script file is downloaded as a node host in the PaaS system. In one embodiment, the parameters may vary based on type of the node hosts”. (¶27). Alfonso further teaches, “an orchestration service may implement loading script files into images of VM instances described herein. In one embodiment, the VM instance runs an operating system with the script file having the software installed and configured to manage all services that enable the PaaS system. For every instance to be built, orchestration service may retrieve script file from the image package to be injected into the instance. As, as discussed above, the image package may be a registered node image package. The runtime script file may specify its target location (e.g., the full file system path and the filename) within the VM instance, so that a VM instance bootstrap process would be able to reference the script file after the script file has been successfully injected into the VM instance. In one embodiment, the VM instance bootstrap process is an installation process, which applies the script file including the software updates as well as runtime configuration specific to a single VM during start up. In one embodiment, the file target location is the PaaS system. (¶31). “The orchestration service may communicate the script file to the VM instance, thus causing the VM instance bootstrap process to download the script file into the PaaS system within the VM instance. The VM instance bootstrap process may process an element by downloading the script file and placing the script file into PaaS system. After the script file has been successfully downloaded and placed into the PaaS system, the VM instance bootstrap process may use the downloaded files, e.g., by executing runtime agent scripts and/or retrieving configuration data from the downloaded files.. (Fig. 2, ¶34). “A script file from the image package is retrieved from the storage memory. The boot process of the VM instance (i.e. the VM instance bootstrap process) is caused to download the script file as a node into the PaaS system. When a VM is started up for the first time, the VM instance bootstrap process runs the script file, which downloads the software updates and the configurations to be installed on the VM. In one embodiment, VM instance bootstrap process references the script file injected into the VM instance“. (Fig. 3, ¶41). Thus combination of Crouse and Alfonso teaches the claim limitation, “the boot message including boot script information and key information for authenticating the first instance.”. The motivation/suggestion for doing so would be to automatically installing and scaling of application resources in a multi-tenant Platform-as-a-Service (PaaS) environment in a cloud computing system.
Applicant’s remark, filed on April 21, 2026 on bottom of page 10 regarding, “Claim 1 recites in part: "receiving a join message from the first instance to join a gateway service cluster, the join message including credentials based on the key information." The art of record does not teach or suggest at least this limitation.” has been considered, however is not found persuasive. Crouse teaches, “A request to add an instance to a cluster can identify the cluster and the request can include a request to grant permission for the instance to join the cluster. Permission to join a cluster can be determined by membership in a group with group members having permission to join the cluster. The group can be a static group and membership in a group can be defined by a list of individual instances. Alternatively, the group can be a dynamic group and group membership can be determined by a set of rules. In a dynamic group, an instance can be added, or removed, from the group based on whether the instance satisfies the rules that determine group membership.”. (¶33). “When launching the instance, the customer can provide the instance with cluster credentials and an address for the control plane associated with the cluster. The cluster credentials can include at least one of a cluster identifier, a transport layer security (TLS) key, or a signed certificate. The instance can use the address and cluster credentials to authenticate with the control plane associated with the cluster. During authentication, the control plane can check that the instance is a member of a group with permission to join the cluster, and, after authentication, the instance can be added to the cluster.”, (¶21). “After deciding on an instance image and shape for the new instances, the customer obtains permission for the new instances to join the cluster by adding the instances to the group associated with the cluster. In this case, the group is a static group, and the customer adds the instances to the group by adding entries in the group table named “new_instance1” and “new_instance2.” Once permission has been obtained, the customer launches the instances using the custom shape and instance image and names them “new_instance1” and “new_instance2.” The customer obtains authentication credentials for each instance from the cloud service provider including a transport layer security key, a signed certificate, an address for the control plane associated with the cluster, and a cluster identifier. The customer provides these authentication credentials to the instances and the instances provides these credentials to the control plane so that the new instances can be authenticated. After authentication, the new nodes are added to the cluster and control plane begins to assign workloads to “new_instance1” and “new_instance2.”. (¶23).
Applicant’s remark, filed on April 21, 2026 on middle of page 11 regarding, “Claim 1 recites in part: "configuring the first instance with the gateway service cluster based on credentials included in the join message, wherein configuring the first instance with the gateway service cluster includes validating the credentials using the key information." The art of record does not teach or suggest at least this limitation.”, has been considered, however is not found persuasive. Crouse teaches, “the instance can request authentication from the control plane. The request for authentication that is sent from the instance to the control plane can comprise at least the authentication credential and the request can be sent to the address from. The authentication can be a token or certificate that has been signed by a private key. The control plane can verify the validity of the authentication token with a public key that corresponds to the private key.”. (¶35). “An authentication decision can be returned to the instance. If the instance has been authenticated, returning the authentication decision can mean adding the instance to the cluster”. (¶37). “A request to authenticate the first instance can be received. The request can be received from the instance launched at such as instance 110a, instance 110b, instance 110c, instance 110d, or instance 215. The request can be generated by the first instance's instance agent such as instance agent 130a, instance agent 130b, instance agent 130c, or instance agent 130d. The request can be received at a control plane associated with the cluster identified. For instance, the control plane can be control plane 125 or control plane 220. The first instance can be added to the cluster identified in the request. The first instance can be an instance such as instance 110a, instance 110b, instance 110c, instance 110d, or instance 215. Authenticating the first instance can include verifying the authentication credential from 320 using a private key associated with the cluster identified in 310. The first instance may need to have permission to join the cluster before the cluster can be authenticated and authenticating the cluster can mean checking that the cluster is a member of a static group or dynamic group associated with the cluster identified at 310. Adding the first instance to the cluster can comprise at least adding the first instance to a group associated with the cluster. In some instances, adding the first instance may comprise at least creating a group, associating the created group with the cluster, and adding the first instance to the created group. Adding the group may comprise at least creating the cluster where the created cluster can be a Kubernetes cluster”. (¶42-¶43).
Applicant’s remark, filed on April 21, 2026 on bottom of page 11 and middle of page 12 regarding, “The proposed combination rationale remains inadequate….The rejection does not articulate why a person of ordinary skill would have modified Crouse's launch and authentication framework, in view of Alfonso's bootstrap- script teachings, to arrive at that particular key-driven architecture. Nor does the rejection explain how the combined references would produce the required continuity between boot-message key information, join-message credentials, and credential validation. The reasoning remains too generalized to support the amended claim”, has been considered, however is not found persuasive. Crouse discloses, “techniques may include receiving a request to launch a first instance in a customer partition. The request can identify one or more of a cluster and an instance image. In addition, the techniques may include launching the first instance on a server in the customer partition using the instance image identified by the request. The techniques may include receiving a request to authenticate the first instance. Moreover, the techniques may include in response to a determination that the first instance is authentic: adding the first instance to the cluster identified in the request”. (Abstract). Alfonso discloses, “A mechanism for automatic installing and scaling of application resources in a multi-tenant Platform-as-a-Service (PaaS) environment in a cloud computing system is disclosed. A method includes creating, by a processing device of an Infrastructure-as-a-Service (IaaS) platform, an image package corresponding to a node host on a multi-tenant Platform-as-a-Service (PaaS) system. The image package comprises an image file including a script file having a plurality of software updates and run time configuration files. The image package is stored in a storage memory of the IaaS platform and is accessible by a virtual machine (VM) instance. The method also includes retrieving, from the storage memory, the script file from the image package and causing a boot process of the VM instance to download the script file into the PaaS system”. (Abstract). A person having an ordinary skill in the art would have combined Crouse and Alphonso to automatically installing and scaling of application resources in a multi-tenant Platform-as-a-Service (PaaS) environment in a cloud computing system.
Applicant further recites similar remarks as listed above for independent claim 11. Please see response for remarks in above paragraphs 10-14 that clearly shows how the cited prior arts Crouse and Alfonso clearly teaches the claimed limitations.
Applicant further recites similar remarks as listed above for dependent claims 2-10 and 12-20. Please see response for remarks in above paragraphs 10-14 that clearly shows how the cited prior arts Crouse and Alfonso clearly teaches the claimed limitations.
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 1, 4-9, 11 and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Devon Howard Crouse (US PGPUB. # US 2024/0187232, hereinafter “Crouse”), and further in view of Alfonso et al. (US PGPUB. # US 2015/0242197, hereinafter “Alfonso”).
Referring to Claims 1 and 11:
Regarding Claim 1, Crouse teaches,
A method comprising:
in response to receiving a start message to start a first instance of a gateway service, [transmitting a boot message to a cloud service provider to cause the cloud service provider to boot] an image corresponding to the gateway service, (Fig. 2(202, 204), ¶32, “a client 205 can request that an instance 215 is added to a cluster by sending a message to the cloud service provider application programming interface (API) 210”, “The request can include an instance image for the new instance (e.g., an image file) or the request can include an address for the instance image so that the cloud service provider application programming interface 210 can retrieve the instance image, Fig. 2(204), ¶34, “At step 204, the cloud service provider can launch the instance”, Fig. 3(310), ¶39, Fig. 3(320), ¶41, Fig. 4, “Service Gateway 436”, ¶58, Fig. 1(105, 125, 110a..110d), ¶24, ¶27, Fig. 4(416, 434,438,436), ¶54, i.e. a client sends a message including instance image information to launch the instance (start the instance). The instances are managed in a control plane. The control plane has various gateways, thus instance is started for a gateway services) [the boot message including boot script information] and key information for authenticating the first instance (¶21, When launching the instance, the customer can provide the instance with cluster credentials and an address for the control plane associated with the cluster. The cluster credentials can include at least one of a cluster identifier, a transport layer security (TLS) key, or a signed certificate”, ¶23, ¶35; Fig. 3, ¶43, i.e. a key information is included to authenticate an instance);
receiving a join message from the first instance to join a gateway service cluster, the join message including credentials based on the key information; (¶33, “A request to add an instance to a cluster can identify the cluster and the request can include a request to grant permission for the instance 215 to join the cluster”, Fig. 4(416, 434,438,436), ¶54, ¶21, ¶23, ¶34-¶35, Fig. 3, ¶42-¶43, “The cluster credentials can include at least one of a cluster identifier, a transport layer security (TLS) key, or a signed certificate”, i.e. request to join a cluster (message) is received. The control plane has various Gateway clusters, thus join message is to join a gateway cluster and the join message includes a credential based on the key information) and
configuring the first instance with the gateway service cluster based on credentials included in the join message, wherein configuring the first instance with the gateway service cluster includes validating the credentials using the key information. (Fig. 2(206, 208), ¶35, ”comprise at least the authentication credential and the request can be sent to the address“, “certificate that has been signed by a private key”, ¶37, “If the instance has been authenticated at 206, returning the authentication decision can mean adding the instance to the cluster from 202”, Fig. 3(340), ¶42-¶43, “the first instance can be added to the cluster identified in the request”, “Authenticating the first instance can include verifying the authentication credential from 320 using a private key associated with the cluster identified in 310”, Fig. 4(416, 434,438,436), ¶54).
Crouse does not teach explicitly,
[in response to receiving a start message to start a first instance of a gateway service], transmitting a boot message to a cloud service provider to cause the cloud service provider to boot [an image corresponding to the gateway service], the boot message including boot script information.
However, Alfonso teaches,
[in response to receiving a start message to start a first instance of a gateway service], transmitting a boot message to a cloud service provider to cause the cloud service provider to boot [an image corresponding to the gateway service], the boot message including boot script information. (¶27, ¶31, “a VM instance bootstrap process would be able to reference the script file after the script file has been successfully injected into the VM instance. In one embodiment, the VM instance bootstrap process is an installation process, which applies the script file including the software updates as well as runtime configuration specific to a single VM during start up”, Fig. 2, ¶34, “The orchestration service 258 may communicate the script file to the VM instance, thus causing the VM instance bootstrap process to download the script file into the PaaS system 240 within the VM instance”, Fig. 3, ¶41, “At block 330, a script file from the image package is retrieved from the storage memory. At block 340, the boot process of the VM instance (i.e. the VM instance bootstrap process) is caused to download the script file as a node into the PaaS system. When a VM is started up for the first time, the VM instance bootstrap process runs the script file”, i.e. Examiner submits that boot process includes a boot messages that has boot script information).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Alfonso with the invention of Crouse.
Crouse teaches, cloud service provider launches an image based on a received start message and configures an instance to join a cluster after authenticating the instance utilizing key information. Alfonso teaches, providing a boot script information to download the script and run during the bootstrap process. Therefore, it would have been obvious to provide a boot script information to download the script and run during the bootstrap process of Alfonso with cloud service provider launches an image based on a received start message and configures an instance to join a cluster after authenticating the instance utilizing key information of Crouse to automatically installing and scaling of application resources in a multi-tenant Platform-as-a-Service (PaaS) environment in a cloud computing system.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 11, it is a computing system claim of above method claim 1 and therefore Claim 11 is rejected with the same rationale as applied against Claim 1 above.
Crouse teaches a processor (Fig. 8) and a storage (Fig. 8).
Referring to Claims 4 and 14:
Regarding Claim 4 rejection of Claim 1 is included and for the same motivation Crouse does not teach explicitly,
The method of claim 1, wherein the boot script information includes a location of a boot script associated with the boot.
However, Alfonso teaches,
The method of claim 1, wherein the boot script information includes a location of a boot script associated with the boot. (¶31, “The runtime script file may specify its target location (e.g., the full file system path and the filename) within the VM instance”).
Regarding Claim 14, rejection of Claim 11 is included and Claim 14 is rejected with the same rationale as applied against Claim 4 above.
Referring to Claims 5 and 15:
Regarding Claim 5 rejection of Claim 4 is included and for the same motivation Crouse does not teach explicitly,
The method of claim 4, wherein the cloud service provider is configured to retrieve the boot script from a storage source based on the boot script information and insert the boot script into the image.
However, Alfonso teaches,
The method of claim 4, wherein the cloud service provider is configured to retrieve the boot script from a storage source based on the boot script information and insert the boot script into the image. (¶31, “The runtime script file may specify its target location (e.g., the full file system path and the filename) within the VM instance, so that a VM instance bootstrap process would be able to reference the script file after the script file has been successfully injected into the VM instance”, ¶32, “the script file references a location from which the file may be retrieved”, ¶34).
Regarding Claim 15, rejection of Claim 14 is included and Claim 15 is rejected with the same rationale as applied against Claim 5 above.
Referring to Claims 6 and 16:
Regarding Claim 6 rejection of Claim 5 is included and for the same motivation Crouse teaches,
The method of claim 5, wherein the first instance is configured to send the join message (¶33, “A request to add an instance to a cluster can identify the cluster and the request can include a request to grant permission for the instance 215 to join the cluster”) [based on the boot script information].
Crouse does not teach explicitly,
The method of claim 5, [wherein the first instance is configured to send the join message] based on the boot script information.
However, Alfonso teaches,
The method of claim 5, [wherein the first instance is configured to send the join message] based on the boot script information. (¶31, ¶33).
Regarding Claim 16, rejection of Claim 15 is included and Claim 16 is rejected with the same rationale as applied against Claim 6 above.
Referring to Claims 7 and 17:
Regarding Claim 7 rejection of Claim 5 is included and for the same motivation Crouse teaches,
The method of claim 5, wherein the first instance is configured to sign information with a private key and include signed information within the join message. (Fig. 2, ¶35, “The authentication can be a token or certificate that has been signed by a private key”, i.e. signed token (information) is included with the join message).
Regarding Claim 17, rejection of Claim 15 is included and Claim 17 is rejected with the same rationale as applied against Claim 7 above.
Referring to Claims 8 and 18:
Regarding Claim 8 rejection of Claim 1 is included and for the same motivation Crouse teaches,
The method of claim 1, wherein, after joining the gateway service cluster, a load balancer is configured to provide network traffic and the first instance processes the network traffic based on a configuration in the boot message. (¶50, “Other infrastructure elements may also be provisioned, such as a load balancer, a database, or the like”, ¶54, Fig. 4, “Additionally, the DMZ tier 420 can include one or more load balancer (LB) subnet(s) 42”).
Regarding Claim 18, rejection of Claim 11 is included and Claim 18 is rejected with the same rationale as applied against Claim 8 above.
Referring to Claims 9 and 19:
Regarding Claim 9 rejection of Claim 1 is included and for the same motivation Crouse teaches,
The method of claim 1, wherein the first instance is not added to the gateway service cluster when the credentials included in the join message do not correspond to a public key. (Fig. 2, ¶35, “The authentication can be a token or certificate that has been signed by a private key. The control plane 220 can verify the validity of the authentication token with a public key that corresponds to the private key”, ¶37, “returning the authentication decision can mean informing the instance 215, or the client 205, that the instance has been denied access to the cluster from 202”).
Regarding Claim 19, rejection of Claim 11 is included and Claim 19 is rejected with the same rationale as applied against Claim 9 above.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Devon Howard Crouse (US PGPUB. # US 2024/0187232, hereinafter “Crouse”), and further in view of Alfonso et al. (US PGPUB. # US 2015/0242197, hereinafter “Alfonso”), and further in view of Elemenshawy et al. (US PGPUB. # US 2025/0141696, hereinafter “Elemenshawy”).
Referring to Claims 2 and 12:
Regarding Claim 2 rejection of Claim 1 is included and combination of Crouse and Alfonso does not teach explicitly,
The method of claim 1, further comprising:
generating the key information, the key information including a private key and a public key associated with the first instance based on the start message, wherein the boot message includes the private key.
However, Elemenshawy teaches,
The method of claim 1, further comprising:
generating the key information, the key information including a private key and a public key associated with the first instance based on the start message, wherein the boot message includes the private key. (¶20-¶21, ¶39, ¶102, ¶128, ¶136, “the private key generated by the key generation service 624b associated with the network entity 612, for use in credential requests that the network entity 612”, ¶139, “When the asymmetric key pair is generated by the network entity 612 or a key generation service 624b associated with the network entity 612 “, ¶3, “The credential request is digitally signed by the network entity using the private key (obtained during bootstrapping)”).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Elemenshawy with the invention of Crouse in view of Alfonso.
Crouse in view of Alfonso teaches, cloud service provider launches an image based on a received start message and configures an instance to join a cluster after authenticating the instance utilizing key information and providing a boot script information to download the script and run during the bootstrap process. Elemenshawy teaches, generating private key and public key associated with an instance and including the private key with boot message. Therefore, it would have been obvious to generate private key and public key associated with an instance and including the private key with boot message of Elemenshawy into the teachings of Crouse in view of Alfonso to provide access to resources to only authorized entity in a multi-tenant Platform-as-a-Service (PaaS) environment in a cloud computing system.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 12, rejection of Claim 11 is included and Claim 12 is rejected with the same rationale as applied against Claim 2 above.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Devon Howard Crouse (US PGPUB. # US 2024/0187232, hereinafter “Crouse”), and further in view of Alfonso et al. (US PGPUB. # US 2015/0242197, hereinafter “Alfonso”), and further in view of Elemenshawy et al. (US PGPUB. # US 2025/0141696, hereinafter “Elemenshawy”), and further in view of Leafe et al. (US PGPUB. # US 2012/0233668, hereinafter “Leafe”).
Referring to Claims 3 and 13:
Regarding Claim 3, rejection of Claim 2 is included and combination of Crouse, Alfonso and Elemenshawy does not teach explicitly,
The method of claim 2, further comprising: determining an authenticity of the join message based on an information within the join message encrypted with the private key.
However, Leafe teaches,
The method of claim 2, further comprising: determining an authenticity of the join message based on an information within the join message encrypted with the private key. (¶152, “A user's access key needs to be included in a request, and the request must be signed with the secret key. Upon receipt of API requests, the rules engine verifies the signature”, ¶281, “ In an embodiment in which user information accompanies the request, either explicitly or implicitly via a signing and/or encrypting key or certificate”).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Leafe with the invention of Crouse in view of Alfonso and Elemenshawy.
Crouse in view of Alfonso and Elemenshawy teaches, cloud service provider launches an image based on a received start message and configures an instance to join a cluster after authenticating the instance utilizing key information and providing a boot script information to download the script and run during the bootstrap process and generating private key and public key associated with an instance and including the private key with boot message. Leafe teaches, authenticating a message based on an encrypted/signed information utilizing a private key. Therefore, it would have been obvious to authenticate a message based on an encrypted/signed information utilizing a private key of Leafe into the teachings of Crouse in view of Alfonso and Elemenshawy to provide access to provide a better-functioning cloud computing system with superior operational capabilities for end users.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 13, rejection of Claim 12 is included and Claim 13 is rejected with the same rationale as applied against Claim 3 above.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Devon Howard Crouse (US PGPUB. # US 2024/0187232, hereinafter “Crouse”), and further in view of Alfonso et al. (US PGPUB. # US 2015/0242197, hereinafter “Alfonso”), and further in view of Silk et al. (US PAT. # US 10,339,150, hereinafter “Silk”).
Referring to Claims 10 and 20:
Regarding Claim 10 rejection of Claim 1 is included and combination of Crouse and Alfonso does not teach explicitly,
The method of claim 1, wherein a load balancer is configured to destroy the first instance based on a volume of traffic processed by the first instance.
However, Silk teaches,
The method of claim 1, wherein a load balancer is configured to destroy the first instance based on a volume of traffic processed by the first instance. (Fig. 2, CL(6), LN(38-55), “The load balancer 204 may monitor the load (e.g., the amount of processing performed by the host system instances 101A-N, an amount of network traffic handled by the load balancer 204, etc.) of the system to dynamically scale the instances 101A-N to add or remove instances 101A-N as needed”, i.e. instance is removed (destroyed) by the load balancer).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Silk with the invention of Crouse in view of Alfonso.
Crouse in view of Alfonso teaches, cloud service provider launches an image based on a received start message and configures an instance to join a cluster after authenticating the instance utilizing key information and providing a boot script information to download the script and run during the bootstrap process. Sil teaches, removing instance based on the network traffic processed by an instance. Therefore, it would have been obvious to remove instance based on the network traffic processed by an instance of Silk into the teachings of Crouse in view of Alfonso to manage resources efficiently in a shared cloud environment.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 20, rejection of Claim 11 is included and Claim 20 is rejected with the same rationale as applied against Claim 10 above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Gupta et al. (US PGPUB. # US 2025/0168199) discloses, a secure web gateway for a cloud computing environment comprises a data plane component, comprising: a front-end domain name service (DNS) configured to receive an inbound DNS request and map an IP address of the DNS request to a policy identification value corresponding to a customer policy and a plurality of plugin modules utilized by the front-end DNS to process the DNS request according to the mapping of the IP address from which the DNS request originates to the policy identification value. The secure web gateway further comprises a control plane component that provides the customer policy to the front-end DNS and configures the IP address to permit access to a DNS service according to the customer policy.
Poddar et al. (US PGPUB. # US 2022/0350642) discloses, a chart package is selectively retrieved from a chart repository based upon the chart package corresponding to a set of services to host within a cluster and dependencies amongst the set of services. A set of container images may be retrieved from a container repository based upon the set of container images corresponding to the set of services. A cluster may be created within a computing environment. The set of services may be deployed as resources of the computing environment within the cluster and the dependencies may be configured using the chart package and the set of container images.
Burus et al. (US PAT. # US 11,405,098) discloses, a Data Delivery Service (DDS) is described, which is a service in a multi-tenant environment that transmits satellite data between a satellite antenna and a user instance. The DDS transports the antenna data to a different region, which allows a user to reuse their infrastructure for multiple antenna sites, thereby, reducing their infrastructure footprint and costs. Gateway instances can be launched at scheduled times in different regions and a secure communication channel can be established between the gateway instances to establish inter-region communication.
Agarwal et al. (US PAT. # US 10,783,235) discloses, when a client requests to access a computing resource, a computing service may generate a first password value for the computing resource and transmit the first password value to the client. The client may then generate and transmit key data for entry of the first password value back to the computing service. The client may generate and transmit the key data on the user's behalf, without requiring any activation or selection of keys by the user. Upon receiving the key data, the computing service may enter the first password value into the computing resource, thereby allowing the client to access the computing resource. The computing service may detect the accessing of the computing resource and may change the first password value to a second password value.
Kludy (US PGPUB. # US 2019/0163460) discloses, cloud service automation of common image management. An image update orchestrator may receive a request to upgrade a virtual machine image. The image update orchestrator may spin up an instance of a virtual machine and provision the instance of the virtual machine with a virtual machine image and cause to install a plurality of software updates to the instance of the virtual machine. The image update orchestrator may take a snapshot of the instance of the virtual machine and generate a sealed master image. Finally, the image update orchestrator may cause to deploy, to one or more policy managed devices, the sealed master image.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5:00 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/DARSHAN I DHRUV/ Primary Examiner, Art Unit 2498
Prosecution Insights