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 initial written action is responding to the communication dated on 04/22/2024.
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.
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];
receiving a join message from the first instance to join a gateway service cluster; (¶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, 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
configuring the first instance with the gateway service cluster based on credentials included in the join message. (Fig. 2(206, 208), ¶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. 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 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-3 and 12-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”).
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 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 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, ¶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, ¶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 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 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 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
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