DETAILED ACTION
This office action is in response to amendment filed in 12/22/2025,
Claims 1, 2, 4 – 7, 10, 12 – 14, 16 – 19 are amended.
Claims 3, 8, 9, 15 and 20 are cancelled.
Claims 21 – 24 are added.
Claims 1, 2, 4 – 7, 10 – 14 and 16 – 19 and 21 – 24 are pending.
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 .
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.
Claim(s) 1, 2, 4 – 7, 10 – 14 and 16 – 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al (US 20200374974, hereinafter Sun), in view of Gupta et al (US 20210168092, hereinafter Gupta).
As per claim 1, Sun discloses: A method for scheduling a compute instance, wherein the method comprising:
obtaining, by a client, resource requirement information of an application (APP) running on a terminal device; (Sun figure 1B and [0024]: “the MEC orchestration platform may receive information related to a requested MEC session to support an application workload for a user equipment in communication with a base station located in the edge region of the RAN… the requests from the first user equipment 102 and the second user equipment 104 may indicate one or more performance requirements and/or other constraints associated with the requested session(s) (e.g., requirements related to latency, bandwidth, security, location, connectivity or mobility, cost, persistent storage, and/or the like).”)
sending, by the client, the resource requirement information to a cloud resource scheduling system, wherein the cloud resource scheduling system is used to manage plurality of sites; (Sun figure 1B and [0026]: “the MEC orchestration platform may submit a work order related to a requested MEC session to the various MEC hosts located in the edge region of the RAN. For example, the work order may indicate the performance requirements and/or constraints associated with the requested MEC session.”)
sending, by the client during running of the APP, some one or more processing tasks of the APP to a target [host] compute instance, wherein the target [host] is determined by the cloud resource scheduling system based on the resource requirement information, the target [host] located in one of the plurality of sites (Sun [0026]: “the various MEC hosts located in the edge region of the RAN may submit bids for the work order according to an automated process based on the information contained in the distributed ledger. For example, each MEC host in the edge region of the RAN may indicate a cost to support the application workload, a performance level that can be offered to support the application workload, and/or the like, and the bids may be recorded in the distributed ledger. As further shown in FIG. 1B, and by reference number 145, the MEC orchestration platform may receive information identifying one or more bidders that can meet the performance requirements or otherwise satisfy the constraints associated with the requested MEC session.”; [0069]: “the MEC orchestration device (e.g., using processor 420, memory 430, storage component 440, input component 450, output component 460, communication interface 470, and/or the like) may assign at least a portion of the application workload to the MEC host based on the profile for the MEC host and a service level agreement specifying one or more performance requirements associated with the application workload, as described above. In some implementations, the portion of the application workload may be assigned to the MEC host based on a bid to service the application workload from the MEC host.”)
and receiving, by the client, results of processing the some one or more processing tasks of the APP by the target compute instance from the target compute instance. (Sun [0009]: “the user equipment transmits the data to the application server via a data network such as the Internet, and the application server processes the data before the processed data is returned to the user equipment via the data network.”)
Sun did not explicitly disclose:
wherein the resource requirement comprises at least one of a type of compute instance, configuration of a compute instance, and a quantity of required compute instance;
wherein the target host runs a compute instance;
However, Gupta teaches:
wherein the resource requirement comprises at least one of a type of compute instance, configuration of a compute instance, and a quantity of required compute instance; (Gupta [0029])
wherein the target host runs a compute instance; (Gupta [0109]: “at block 808, sending, to a provider substrate extension, instructions to launch a compute instance based on the application profile, the compute instance to be used to execute the workload at the provider substrate extension. In some embodiments, the compute instance is a microVM running on a virtual machine manager (VMM) hosted by a server of the provider substrate extension.”; [0042]: “a PSE 102 forms an edge location”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gupta into that of Sun in order to have the target host runs a compute instance, and wherein the resource requirement comprises at least one of a type of compute instance, configuration of a compute instance, and a quantity of required compute instance. Gupta has shown that the concept of executing compute instances on edge servers is commonly known in the field, applicants have thus merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
As per claim 2, the combination of Sun and Gupta further teach:
The method according to claim 1, wherein the obtaining, by the clinet, the resource requirement information of the APP comprises: obtaining, compute instance configuration data of the APP, determining that cloud resource enabling information is configured in the app, and obtaining the resource requirement information based on the cloud resource enabling information and the compute instance configuration data of the app, wherein the resource requirement information comprises at least one of a type of a compute instance, configuration information of a compute instance, or a quantity of required compute instances. (Sun [0026]: “the various MEC hosts located in the edge region of the RAN may submit bids for the work order according to an automated process based on the information contained in the distributed ledger. For example, each MEC host in the edge region of the RAN may indicate a cost to support the application workload, a performance level that can be offered to support the application workload, and/or the like, and the bids may be recorded in the distributed ledger. As further shown in FIG. 1B, and by reference number 145, the MEC orchestration platform may receive information identifying one or more bidders that can meet the performance requirements or otherwise satisfy the constraints associated with the requested MEC session.”; Gupta [0030]: “The client represents instructions that enable a compute instance to connect to, and perform I/O operations at, a remote data volume (e.g., a data volume stored on a physically separate computing device accessed over a network).”)
As per claim 4, the combination of Sun and Gupta further teach:
The method according to claim 2, wherein the determining, by the client, that the cloud resource enabling information is configured in the APP, and obtaining, by the client, resource requirement information based on the cloud resource enabling information and the compute instance configuration data of the APP comprises: sending, a cloud service request to the cloud resource scheduling system, wherein the cloud service request is used to request the cloud resource scheduling system to enable a cloud service function for the APP; and after the cloud resource scheduling system enables the cloud service function for the APP, obtaining, the resource requirement information based on the cloud resource enabling information and the compute instance configuration data of the APP. (Sun [0025] - [0026] and Gupta [0030].)
As per claim 5, the combination of Sun and Gupta further teach:
The method according to claim 1, wherein the sending, by the client, the resource requirement information to the cloud resource scheduling system comprises: sending, the resource requirement information to the cloud resource scheduling system when the APP starts running; or sending, the resource requirement information to the cloud resource scheduling system when network quality of at least one previous compute instance allocated by the cloud resource scheduling system meets an access switching condition. (Sun [0025] - [0026].)
As per claim 6, the combination of Sun and Gupta further teach:
The method according to claim 5, wherein the method further comprises: sending, by the client, location information of the terminal device to the cloud resource scheduling system, wherein at least one compute instance is allocated by the cloud resource scheduling system based on the resource requirement information and the location information. (Sun [0016] and [0025] - [0026])
As per claim 7, the combination of Sun and Gupta further teach:
The method according to claim 1, further comprising receiving resource allocation information from the cloud resource scheduling system, wherein the resource allocation information comprises information about a plurality of compute instances allocated by the cloud resource scheduling system based on the resource requirement information, and the information about the plurality of compute instances comprises at least one of a type of compute instance, an identifier of the compute instance, network quality information of the compute instance, and connection information of a far-side site on which the compute instance is located. (Sun [0025] - [0026] and Gupta [0029].)
As per claim 10, Sun discloses: A method for scheduling a compute instance, the method comprising:
receiving, by a cloud resource scheduling system, resource requirement information from a client of a terminal device, wherein the resource requirement information is used to indicate a resource requirement of an application (APP} running on the terminal device; (Sun figure 1B and [0024]: “the MEC orchestration platform may receive information related to a requested MEC session to support an application workload for a user equipment in communication with a base station located in the edge region of the RAN… the requests from the first user equipment 102 and the second user equipment 104 may indicate one or more performance requirements and/or other constraints associated with the requested session(s) (e.g., requirements related to latency, bandwidth, security, location, connectivity or mobility, cost, persistent storage, and/or the like).”; [0026]: “the MEC orchestration platform may submit a work order related to a requested MEC session to the various MEC hosts located in the edge region of the RAN. For example, the work order may indicate the performance requirements and/or constraints associated with the requested MEC session.”)
determining, by the cloud resource scheduling system, a [host] based on the resource requirement information; (Sun [0026]: “the various MEC hosts located in the edge region of the RAN may submit bids for the work order according to an automated process based on the information contained in the distributed ledger. For example, each MEC host in the edge region of the RAN may indicate a cost to support the application workload, a performance level that can be offered to support the application workload, and/or the like, and the bids may be recorded in the distributed ledger. As further shown in FIG. 1B, and by reference number 145, the MEC orchestration platform may receive information identifying one or more bidders that can meet the performance requirements or otherwise satisfy the constraints associated with the requested MEC session.”)
and sending, by the cloud resource scheduling system, resource allocation information to the client, wherein the resource allocation information comprises information about the plurality of [hosts]. (Sun [0009]: “the user equipment transmits the data to the application server via a data network such as the Internet, and the application server processes the data before the processed data is returned to the user equipment via the data network.”)
compute instance in a plurality of compute instances
Sun did not explicitly disclose:
wherein the host runs a compute instance;
wherein the plurality of [host] are deployed on at least one far-side site managed by the cloud resource scheduling system, and any [host] among the plurality of [host] is used to process some processing tasks of the APP
However, Gupta teaches:
wherein the target host runs a compute instance; wherein the plurality of [host] are deployed on at least one far-side site managed by the cloud resource scheduling system, and any [host] among the plurality of [host] is used to process some processing tasks of the APP; (Gupta [0109]: “at block 808, sending, to a provider substrate extension, instructions to launch a compute instance based on the application profile, the compute instance to be used to execute the workload at the provider substrate extension. In some embodiments, the compute instance is a microVM running on a virtual machine manager (VMM) hosted by a server of the provider substrate extension.”; [0042]: “a PSE 102 forms an edge location… Such edge locations may be referred to as “far zones” (due to being far from other availability zones) or “near zones” (due to being near to customer workloads). ”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gupta into that of Sun in order to have the target host runs a compute instance, and wherein the resource requirement comprises at least one of a type of compute instance, configuration of a compute instance, and a quantity of required compute instance. Gupta has shown that the concept of executing compute instances on edge servers is commonly known in the field, applicants have thus merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
As per claim 11, the combination of Sun and Gupta further teach:
The method according to claim 10, wherein the method further comprises: receiving, by the cloud resource scheduling system, a cloud service request from the client, wherein the cloud service request comprises cloud resource enabling information configured in the APP; and enabling, by the cloud resource scheduling system, a cloud service function for the APP based on the cloud resource enabling information. (Sun [0025] - [0026].)
As per claim 12, the combination of Sun and Gupta further teach:
The method according to claim 10, wherein the at least one far-side site is-comprises a plurality of far-side sites, and the method further comprises: receiving, by the cloud resource scheduling system, location information from the client; and the determining, by the cloud resource scheduling system, the compute instance in a plurality of compute instances based on the resource requirement information comprises: selecting, by the cloud resource scheduling system, at least one candidate site from a plurality of sites based on the resource requirement information and the location information; and determining, by the cloud resource scheduling system based on the resource requirement information, the plurality of compute instances among compute instances deployed on the at least one candidate site. (Sun [0025] - [0026].)
As per claim 13, it is the system variant of claim 1 and is therefore rejected under the same rationale.
As per claim 14, it is the system variant of claim 2 and is therefore rejected under the same rationale.
As per claim 16, it is the system variant of claim 4 and is therefore rejected under the same rationale.
As per claim 17, it is the system variant of claim 5 and is therefore rejected under the same rationale.
As per claim 18, it is the system variant of claim 6 and is therefore rejected under the same rationale.
As per claim 19, it is the system variant of claim 7 and is therefore rejected under the same rationale.
As per claim 21, the combination of Sun and Gupta further teach:
The method according to claim 1, wherein determining the target compute instance by the cloud resource scheduling system based on the resource requirement information comprises: selecting, by the cloud resource scheduling system among the plurality of managed sites, the target compute instance, wherein the target compute instance meets the type of a compute instance and configuration information of a compute instance, the number of the target compute instance equals to or greater than the quantity of required compute instances. (Sun [0026] and [0069])
As per claim 22, the combination of Sun and Gupta further teach:
The method according to claim 1, wherein determining the target compute instance by the cloud resource scheduling system based on the resource requirement information comprises: obtaining, by the cloud resource scheduling system among a plurality of compute instances from the plurality of managed sites, resource status information of the plurality of compute instances from the plurality of managed sites; and determining, by the cloud resource scheduling system based on the resource status information of the plurality of compute instances, the target compute instance. (Sun [0026] and [0069])
As per claim 23, it is the system variant of claim 21 and is therefore rejected under the same rationale.
As per claim 24, it is the system variant of claim 22 and is therefore rejected under the same rationale.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 2, 4 – 7, 10 – 19 and 21 – 24 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. 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.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196