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
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), filed on 12/12/2025 in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/12/2025 has been entered. Claims 1-20 are pending.
Response to Arguments
2. Applicant's arguments have been fully considered but they are not persuasive. The applicant argues the following issues.
(A) Rejection under 35 U.S.C. 103(a)
Issue 1: The applicant argues with respect to independent claims such as claim 1 the amended limitations overcome the current rejection.
This argument is moot in light of the new ground of rejections set forth below. See Examiner’s response in the corresponding rejection section.
Issue 2: The applicant’s arguments for other claims are based on the similar arguments for claim 1.
See Examiner’s response above.
Double Patenting
3. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
4. Claims 1-4 and 6-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-16 of US Patent No. 11658972 (hereafter “the Patent”) in view of Shevade (US 2019/0265996) and Ma (US 20190286486 A1) and Farhangi et al (US 10,986,065).
As to claim 1, the Patent discloses the claimed invention substantially, except for receiving, by a service application, a request to implement a client application and routing, by the service application, the request to a control plane process, and that that the cell comprises a name space reserved for the client. Shevade discloses receiving, by a service application, a request to implement a client application (see citation in art rejection to claim 1, limitation 1 below); routing, by the service application, the request to a control plane process ([0036], “A request to configure or reconfigure a standardized VM may be submitted by a client 180 to a request router and routed to control plane layer 110 or to a VMC 157 in some embodiments”); and determining, by the service application, a number of computing devices on which to instantiate a cell based at least in part on a demand associated with the client application and the profile data associated with the client application, the cell comprising a transaction processor for running the client application ([0034], “if a specified demand of a requested VM is less than a particular threshold with respect to a pre-defined combination of processing, storage and/or memory resources, the request may be directed to the cell-based layer…. A given cell 116 may comprise, for example, one or more resource processing nodes, one or more reconciliation nodes, a local instance of a persistent data store, and metadata indicative of a set of virtualization hosts 155 to be used for VMs managed by the cell in various embodiments”, wherein the VM is a transaction processor for running the client application, see citation in rejection to limitation 1).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine the Patent with Shevade. The suggestion/motivation of the combination would have been to process requests to create cells accordingly (Shevade, figure 9).
The patent in view of Shevade does not expressly disclose that the demand is a predicted demand. Ma discloses a concept of determining, by a service application, a number of computing devices on which to instantiate a cell based at least in part on a predicted demand associated with a client application ([0050], “predicted resource usage may be communicated to the container scheduler 604 of FIG. 6. The container scheduler 604 may be responsible for converting the resource usage output of the predictor into system resource allocation including a number of contains to be instantiated and CPU/memory allocation for each container”; [0017], “Each of these client applications may be hosted and run in the cloud as multiple independent instances of containers and allocated certain amount of resources”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine the patent-Shevade with Ma. The suggestion/motivation of the combination would have been to allocate resources based on prediction (Ma, [0050]).
Farhangi discloses a concept that a cell comprises a name space reserved for a client ((figure 3; col. 2. Lines 45-60).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Shevade with Farhangi. The suggestion/motivation of the combination would have been to isolate/create a namespace specifically for a cell (Farhangi, Figure 3; col. 2, lines 45-60).
As to claim 10, see similar rejection to claim 1.
As to claim 16, see similar rejection to claim 1.
As to claim 2, the Patent-Shevade discloses the method of claim 1, wherein the request is received from a client attempting to utilize the client application, the client corresponding to the client device (Shevade, [0036], “A request to configure or reconfigure a standardized VM may be submitted by a client 180 to a request router and routed to control plane layer 110 or to a VMC 157 in some embodiments”).
As to claim 11, see similar rejection to claim 2.
As to claim 4, the Patent-Shevade discloses the method of claim 2, wherein the client is assigned to an instance of the cell based on historical usage patterns associated with the client (the Patent, claim 3).
As to claim 13, see similar rejection to claim 4.
As to claim 18, see similar rejection to claim 4.
As to claim 6, the Patent-Shevade discloses the method of claim 1, wherein the request is received automatically upon a determination that a current implementation of the service is inadequate (Shevade, [0082]).
As to claim 9, the Patent-Shevade discloses the method of claim 1, wherein the cell further comprises a transaction processor configured to perform transactions for a number of resources associated with the client application (the Patent, claim 5).
As to claim 3, the Patent-Shevade discloses the method in claim 2, wherein the client is assigned to a namespace within the cell (the Patent, claim 2)
As to claim 12, see similar rejection to claim 3.
As to claim 17, see similar rejection to claim 3.
As to claim 7, the Patent-Shevade discloses the method as discussed in claim 1, wherein the worker thread is assigned to create computing resources to implement the requested service (the Patent, claim 7)
As to claim 14, see similar rejection to claim 7.
As to claim 19, see similar rejection to claim 7.
As to claim 8, the Patent-Shevade discloses the method of claim 7, wherein the cell is generated by the shard (the Patent, claim 7).
As to claim 15, see similar rejection to claim 8.
As to claim 20, see similar rejection to claim 8.
5. Claim 5 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over the Patent in view of Shevade-Ma- Farhangi, as applied to claim 1 above, and further in view of Hammer (US 2013/0166703).
As to claim 5, the patent in view of Shevade and Ma discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose wherein the request is authenticated prior to routing the request to the control plane process. Hammer discloses a concept of authenticate the sender of a request before forward the request further ([0061]).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine the patent in view of Shevade and Ma with Hammer. The suggestion/motivation of the combination would have been to improve security.
Claim Rejections - 35 USC § 103
6. 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.
7. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
8. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
9. Claims 1-4 and 6-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shevade (US 2019/0265996) in view of Ma et al (US 20190286486 A1) and further in view of Farhangi et al (US 10,986,065).
As to claim 1, Shevade discloses a method, comprising:
receiving, by a service application in a service tenancy of a computing system architecture, a request from a client to implement an client application ([0036], “A request to configure or reconfigure a standardized VM may be submitted by a client 180 to a request router and routed to control plane layer 110 or to a VMC 157 in some embodiments”; [0055], “smaller VMs may be launched within (e.g., using the resources accessible from) the parent bare-metal compute instance on behalf of customers of the VCS”; [0024], “A message requesting instantiation of the virtual machine (e.g., an internal representation of the client-submitted request for the VM) may be transmitted from the request router to an RPN of the selected cell in various embodiments”; [0038], “In the embodiment depicted in FIG. 1, a request router such as 122A may receive a request to set up a VM from a client 180 via an interface 177, and determine which component(s) of the control plane should be selected to fulfill the request. For example, based at least partly on one or more properties of the request, a decision may be made that a cell of the flexible-capability VM management layer should be used, and a particular cell may be identified”; [0042], “Depending on the estimated needs of the application for which a given VM is to be used by the client, a VM type from the appropriate family may be selected”. See Figure 1. Wherein the control plane is a service tenant);
routing, by the service application, the request to a control plane process in the service tenancy ([0036], “A request to configure or reconfigure a standardized VM may be submitted by a client 180 to a request router and routed to control plane layer 110 or to a VMC 157 in some embodiments”);
retrieving, by the service application, profile data associated with the client application (figure 9; [0079]-[0080], the initial cell parameter settings);
determining, by the service application, one or more computing devices on which to instantiate a cell in a customer tenancy of the computing system architecture based at least in part on a demand associated with the client application and the profile data associated with the client application, the cell comprising a transaction processor for running the client application ([0034], “if a specified demand of a requested VM is less than a particular threshold with respect to a pre-defined combination of processing, storage and/or memory resources, the request may be directed to the cell-based layer…. A given cell 116 may comprise, for example, one or more resource processing nodes, one or more reconciliation nodes, a local instance of a persistent data store, and metadata indicative of a set of virtualization hosts 155 to be used for VMs managed by the cell in various embodiments”, wherein the VM is a transaction processor for running the client application, see citation in rejection to limitation 1. See [0002], “virtualization technologies may allow a single physical virtualization host to be shared among multiple users by providing each user with one or more "guest" virtual machines hosted by the single virtualization host. Each such virtual machine may represent a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators of a given hardware computing resource, while also providing application isolation and security among the various virtual machines”);
executing, by the service application, a worker thread for implementing the client application, the worker thread configured to generate a cell on the one or more computing devices on the customer tenancy a determined number of computing devices (figure 9; [0079]-[0080], wherein the entity that sets up the initial cell poll is equivalent to a worker thread. Also see [0055]);
receiving, by the service application, a request to access the client application, the request being received from a client device, and the client device being assigned to the cell (figure 10, step 1001, “Receive a virtual machine instantiation request, e.g., at request router or other front-end component of a virtualized computing service (VCS)”; step 1013, “Select the particular cell to be used for the request (e.g., based on a mapping function) and the particular request processing node (RPN) of the cell to which the request is to be directed”, wherein the mapping function indicates that the client being assigned to the cell, see also [0034], “the mapping functions which may be used to select the particular cell to which a client request should be routed in the depicted embodiment”); and
routing, by the service application, the client device to the cell (figure 10, step 1013, “Select the particular cell to be used for the request (e.g., based on a mapping function) and the particular request processing node (RPN) of the cell to which the request is to be directed”; step 1016, “Transmit a representation of the request (and any further requests identified as being directed to the same VM) to the selected RPN at the selected cell”),
wherein the cell further comprises:
computing resources related to the request ().
but does not expressly disclose that the demand is a predicted demand, or that the cell comprises a name space reserved for the client.
Ma discloses a concept of determining, by a service application, a number of computing devices on which to instantiate a cell based at least in part on a predicted demand associated with a client application and profile data associated with the client application ([0050], “predicted resource usage may be communicated to the container scheduler 604 of FIG. 6. The container scheduler 604 may be responsible for converting the resource usage output of the predictor into system resource allocation including a number of contains to be instantiated and CPU/memory allocation for each container”. See also [0051]; [0029]; [0031]-[0032], wherein the initial number of containers and each allocated amount of system resources are a type of profile data associated with the service, which are based on for training and determine further number of containers; [0017], “Each of these client applications may be hosted and run in the cloud as multiple independent instances of containers and allocated certain amount of resources”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Shevade with Ma. The suggestion/motivation of the combination would have been to allocate resources based on prediction (Ma, [0050]).
Farhangi discloses a concept that a cell comprises a name space reserved for a client ((figure 3; col. 2. Lines 45-60).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Shevade with Farhangi. The suggestion/motivation of the combination would have been to isolate/create a namespace specifically for a cell (Farhangi, Figure 3; col. 2, lines 45-60).
As to claim 10, see similar rejection to claim 1.
As to claim 16, see similar rejection to claim 1.
As to claim 2, Shevade discloses the method of claim 1, wherein the request is received from a client attempting to utilize the client application, the client corresponding to the client device ([0036], “A request to configure or reconfigure a standardized VM may be submitted by a client 180 to a request router and routed to control plane layer 110 or to a VMC 157 in some embodiments”).
As to claim 11, see similar rejection to claim 2.
As to claim 3, Shevade-Ma discloses the claimed invention substantially as discussed in claim 2, but does not expressly disclose wherein the client is assigned to a namespace within the cell. Farhangi discloses a concept for a client to be assigned to a namespace within a cell (col.13 para 2).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Shevade-Ma with Farhangi. The suggestion/motivation of the combination would have been to mapping namespaces to clients (Farhangi, col. 13, para 2).
As to claim 12, see similar rejection to claim 3.
As to claim 17, see similar rejection to claim 3.
As to claim 4, Shevade discloses the method of claim 2, wherein the client is assigned to an instance of the cell based on historical usage patterns associated with the client ([0038], "a given cell may be used for a particular VM if it was previously used for a VM requested by the same requester”).
As to claim 13, see similar rejection to claim 4.
As to claim 18, see similar rejection to claim 4.
As to claim 6, Shevade discloses the method of claim 1, wherein the request is received automatically upon a determination that a current implementation of the service is inadequate ([0082]).
As to claim 9, Shevade discloses the method of claim 1, wherein the cell further comprises a transaction processor configured to perform transactions for a number of resources associated with the client application ([0044]).
As to claim 7, Shevade-Ma discloses the claimed inventions substantially as discussed in claim 1, wherein the worker thread is assigned to create computing resources to implement the requested service (see citation in rejection to claim 1, Shevade), but does not expressly disclose that the computing resources are a shard of computer resources. Farhangi discloses a concept of a shard of computer resources/data (see Farhangi, col.2-col.4).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Shevade-Ma with Farhangi. The suggestion/motivation of the combination would have been to dynamically mapping shards of resources/data to cells (Farhangi, col. 2).
As to claim 14, see similar rejection to claim 7.
As to claim 19, see similar rejection to claim 7.
As to claim 8, Shevade-Ma-Farhangi discloses the method of claim 7, wherein the cell is generated by the shard (Farhangi, col. 2-col. 4, allocating a shard of resources/data to a new cell is generating the cell by the shard of resources/data).
As to claim 15, see similar rejection to claim 8.
As to claim 20, see similar rejection to claim 8.
11. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Shevade-Ma- Farhangi, as applied to claim 1 above, and further in view of Hammer (US 2013/0166703).
As to claim 5, Shevade-Ma discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose wherein the request is authenticated prior to routing the request to the control plane process. Hammer discloses a concept of authenticate the sender of a request before forward the request further ([0061]).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Shevade-Ma with Hammer. The suggestion/motivation of the combination would have been to improve security.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUA FAN/Primary Examiner, Art Unit 2458