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 .
Claims 1 – 20 are pending for examination.
Examiner’s Note
The prior art rejection below cites particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Priority
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/30/2024 and 10/31/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 - 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to claim 1, the claim recites
An instance deployment method, wherein the method comprises:
obtaining a resource requirement of a service; and
deploying instances of the service across a central cloud and an edge cloud based on the resource requirement of the service.
Step 2A:
Prong 1: the limitations of " An instance deployment method” and
“deploying instances of the service across a central cloud and an edge cloud based on the resource requirement of the service” recite mental processes since "calculating", "determining", and "identifying" are all functions that can be reasonably performed in the human mind including observations and with or without the use of pen and paper through observation, evaluation, judgement and opinion.
Prong 2: the additional element of "obtaining a resource requirement of a service" merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
Thus, these additional elements do not integrate the judicial exception into a practical application.
Step 2B: the additional element of "obtaining a resource requirement of a service" merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
Accordingly, the additional elements do not amount to significantly more than the abstract idea.
As to claim 2, The method according to claim 1, wherein the method further comprises:
obtaining deployment location information of the service merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d), wherein the deployment location information is used to separately determine one or more availability zones from the central cloud and the edge cloud to obtain N availability zones, and the N availability zones are used for deploying the instances of the service recite mental processes since "calculating", "determining", and "identifying" are all functions that can be reasonably performed in the human mind including observations and with or without the use of pen and paper through observation, evaluation, judgement and opinion.
As to claim 3, The method according to claim 2, wherein obtaining the deployment location information of the service comprises: obtaining the deployment location information of the service input by a user merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 4, The method according to claim 2, wherein the deployment location information comprises at least one of a geographical location level or a geographical location name merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 5, The method according to claim 2, wherein the deployment location information comprises at least one of a target area or a target availability zone merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 6, The method according to claim 2, wherein the deployment location information further comprises a priority of each of the N availability zones merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 7, The method according to claim 2, wherein the method further comprises: obtaining a deployment strategy merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d), wherein the deployment strategy is used to determine distribution of the instances of the service in the N availability zones recite mental processes since "calculating", "determining", and "identifying" are all functions that can be reasonably performed in the human mind including observations and with or without the use of pen and paper through observation, evaluation, judgement and opinion.
As to claim 8, The method according to claim 7, wherein the deployment strategy recite mental processes since "calculating", "determining", and "identifying" are all functions that can be reasonably performed in the human mind including observations and with or without the use of pen and paper through observation, evaluation, judgement and opinion comprises any one of geographical centralization, geographical dispersion, costs first, data synchronization, latency first, and performance first merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 9, The method according to claim 7, wherein the resource requirement comprises a resource type, a quantity of required resources, and M resource specifications, and M is a positive integer merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 10, The method according to claim 9, wherein deploying the instances of the service across the central cloud and the edge cloud comprises:
for each of the M resource specifications, determining a quantity of first instantiations of each resource specification in each of the N availability zones; and if a sum of quantities of first instantiations of each resource specification in all the availability zones is greater than or equal to the quantity of required resources, determining, based on the first instantiations of each resource specification in each availability zone, the resource requirement, and the deployment strategy, a quantity of second instantiations of each resource specification in each availability zone, and deploying the instances of the service based on the quantity of second instantiations of each resource specification in each availability zone recite mental processes since "calculating", "determining", and "identifying" are all functions that can be reasonably performed in the human mind including observations and with or without the use of pen and paper through observation, evaluation, judgement and opinion.
As to claim 11, The method according to claim 9, wherein the resource type comprises at least one of a virtual machine, a docker, or a bare metal server merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 12, The method according to claim 2, wherein the method further comprises: if the N availability zones cannot meet the resource requirement of the service, prompting a user of a deployment failure recite mental processes since "calculating", "determining", and "identifying" are all functions that can be reasonably performed in the human mind including observations and with or without the use of pen and paper through observation, evaluation, judgement and opinion.
As to claim 13, this is a computing device of claim 1. See rejection for claim 1 above.
As to claims 14 – 20, these claims recite similar scope of claims 2 – 9. See rejection for claims 2 - 9 above.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 and 13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Spoczynski et al., (US PUB 2020/0228602 hereinafter Spoczynski.
As to claim 1, Spoczynski teaches An instance deployment method, wherein the method comprises:
obtaining a resource requirement of a service (“...To achieve results with low latency, the services executed within the edge cloud 110 balance varying requirements in terms of: (a) Priority (throughput or latency) and Quality of Service (QoS) (e.g., traffic for an autonomous car may have higher priority than a temperature sensor in terms of response time requirement; or, a performance sensitivity/bottleneck may exist at a compute/accelerator, memory, storage, or network resource, depending on the application); (b) Reliability and Resiliency (e.g., some input streams need to be acted upon and the traffic routed with mission-critical reliability, where as some other input streams may be tolerate an occasional failure, depending on the application); and (c) Physical constraints (e.g., power, cooling and form-factor).” para. 0056) and (“..the measurement of the fulfillment of the agreement (to identify what elements are required by the system to conduct a service, how the system responds to service conditions and changes, and the like).” Para. 0069) and (“...This arrangement and other service management features described herein are designed to meet the various requirements of edge computing with its unique and complex resource and service interactions. This service management arrangement is intended to inherently address several of the resource basic services within its framework, instead through an agent or middleware capability. Services such as: locate, find, address, trace, track, identify, register may be placed immediately in effect as resources appear on the framework...” para. 0079 and 0113) and (“..The main design challenges to run other services on the base station relate to: (1) limited space; (2) physical exposure that requires more security and better thermal solutions; (3) limited amount of power; (4) operating expense (OPEX) or total cost of ownership (TCO) derived from managing such a highly distributed compute environment....” para. 0107) and (“..Furthermore, 5G EDGE devices may also be included in the slice depending on the service latency requirements.” Para. 0211); and
deploying instances of the service across a central cloud and an edge cloud based on the resource requirement of the service (The following describes aspects of an edge cloud architecture that covers multiple potential deployments and addresses restrictions that some network operators or service providers may have in their own infrastructures. These include, variation of configurations based on the edge location (because edges at a base station level, for instance, may have more constrained performance and capabilities in a multi-tenant scenario); configurations based on the type of compute, memory, storage, fabric, acceleration, or like resources available to edge locations, tiers of locations, or groups of locations; the service, security, and management and orchestration capabilities; and related objectives to achieve usability and performance of end services” para. 0052) and (“..The deployment of a multi-stakeholder edge computing system may be arranged and orchestrated to enable the deployment of multiple services and virtual edge instances, among multiple edge nodes and subsystems, for use by multiple tenants and service providers. In a system example applicable to a cloud service provider (CSP), the deployment of an edge computing system may be provided via an “over-the-top” approach, to introduce edge nodes as a supplemental tool to cloud computing. In a contrasting system example applicable to a telecommunications service provider (TSP), the deployment of an edge computing system may be provided via a “network-aggregation” approach, to introduce edge nodes at locations in which network accesses (from different types of data access networks) are aggregated....” para. 0083) and (“..Different locations therefore may be usable across the edge cloud 110 to perform services management, as both compute resources are mapped to the workload data, and workload data instances are mapped to the compute resources. In a highly distributed architecture, the features are based on mapping services on the base station. In this case, the platform physical requirements in terms of power and space will mostly limit the amount of hardware that can be placed in this particular edge node. Furthermore, in order to get more service density, acceleration schemes such as hardware inference acceleration may be utilized. In a central office architecture, the architecture is less distributed but less power and space constrained according to the capabilities and servicing location of the central office...” para. 0121) and (“... On the other hand, a computing edge for a CDN workload may be hosted at a base station, at a central office, or at any other intermediate point of aggregation (POA or POP) of the operator infrastructure.” Para. 0179) and (“...Said any compute node may therefore have knowledge of various physical infrastructure devices of the edge computing system that are capable of providing a service to each service-requesting client. According to some other embodiments, orchestration by a compute node according to embodiments may be both logically and physically centralized.” Para. 0242).
As to claim 13, this is a computing device claim of claim 1. See rejection for claim 1 above. Further, Spoczynski teaches at least one processor; and at least one memory coupled to the at least one processor and storing program instructions for execution by the at least one processor (“...the compute node 1500 includes or is embodied as a processor 1504 and a memory 1506...” para. 0135).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2 – 11 and 14 - 19 are rejected under 35 U.S.C. 103 as being unpatentable over Spoczynski et al., (US PUB 2020/0228602 hereinafter Spoczynski) in view of Dunsmore et al., (US PAT 11,425,054).
As to claim 2, Spoczynski teaches The method according to claim 1, wherein the method further comprises:
obtaining deployment location information of the service Within this arrangement, multiple considerations and capabilities are evaluated for the location and type of workload execution among devices of the edge computing system 10” para. 0109),
Spoczynski does not but Dunsmore teaches wherein the deployment location information is used to separately determine one or more availability zones from the central cloud and the edge cloud to obtain N availability zones, and the N availability zones are used for deploying the instances of the service (“...These deployment zone types can include traditional cloud provider regions and availability zones...” abstract) and (“.These deployment zones generally correspond to physical locations where the cloud provider network provides data centers or other compute capacity and can include deployment zones of various types, e.g., traditional cloud provider regions and availability zones as well as so-called edge locations (e.g., cloud provider operated edge locations, customer-operated edge locations, third-party operated edge locations, communications service provider (CSP) associated edge locations)....” col. 2 lines27 - 52).
It 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 was made to modify Spoczynski by applying the teachings of Dunsmore because Dunsmore would determine locations as well as availability zones to automatically deploy and scale and provide single or multi-services for users across both centralized and edge cloud in any of deployment zones (abstract, figure 13 and associated text).
As to claim 3, Spoczynski modified by Dunsmore teaches The method according to claim 2, Spoczynski teaches wherein obtaining the deployment location information of the service comprises:
obtaining the deployment location information of the service input by a user (“...FIG. 11 illustrates workload deployments and mapping to operational layers (e.g., corresponding to layers 1020-1070) of an edge computing system 1100. Within this arrangement, multiple considerations and capabilities are evaluated for the location and type of workload execution among devices of the edge computing system 10” para. 0109) and (A utility value according to some embodiments may be calculated for each subgroup of service-requesting clients against each candidate physical infrastructure device, using, as input, the average attribute values for location-related attributes...” para. 0246).
As to claim 4, Spoczynski modified by Dunsmore teaches The method according to claim 2, Spoczynski does not but Dunsmore teaches wherein the deployment location information comprises at least one of a geographical location level or a geographical location name (“...This SOADM service 102 can then dynamically select locations to deploy user applications, orchestrate underlying compute and networking resources, and streamline the collection of observability telemetry to a central location...” col. 23 lines 54 – 64).
See motivation for claim 2 above.
As to claim 5, Spoczynski modified by Dunsmore teaches The method according to claim 2, Spoczynski teaches wherein the deployment location information comprises at least one of a target area (“...As a result, the configuration of FIG. 14B may provide a suitable target for base station deployments...” para. 0130) or a target availability zone.
As to claim 6, Spoczynski modified by Dunsmore teaches The method according to claim 2, Spoczynski teaches wherein the deployment location information further comprises a priority (“...Top priorities for edge computing among various network layers include central office...” para. 0181)
Spoczynski does not but Dunsmore teaches of each of the N availability zones (“...availability zones...” abstract).
See motivation for claim 2 above.
As to claim 7, Spoczynski modified by Dunsmore teaches The method according to claim 2, Spoczynski does not but Dunsmore teaches wherein the method further comprises:
obtaining a deployment strategy, wherein the deployment strategy is used to determine distribution of the instances of the service in the N availability zones (“...Using such configurations, the SOADM service automatically deploys and scales simple or complex, single or multi-service applications for users across any number of deployment zones and deployment zone types.” abstract).
It 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 was made to modify Spoczynski by applying the teachings of Dunsmore because Dunsmore would determine locations as well as availability zones to automatically deploy and scale and provide single or multi-services for users across both centralized and edge cloud in any of deployment zones (abstract, figure 13 and associated text).
As to claim 8, Spoczynski modified by Dunsmore teaches The method according to claim 7, Spoczynski does not but Dunsmore teaches wherein the deployment strategy comprises any one of geographical centralization, geographical dispersion, costs first, data synchronization, latency first (“...he SOADM service 102 also provides latency-based scaling for components of a user application, which allows the application to be scaled to new locations to accommodate changes in localized demand, site availability, capacity availability, etc...” col. 24 lines 12 – 35), and performance first.
See motivation for claim 2 above.
As to claim 9, Spoczynski modified by Dunsmore teaches The method according to claim 7, Spoczynski teaches wherein the resource requirement comprises a resource type (“...In this case, the platform physical requirements in terms of power and space will mostly limit the amount of hardware that can be placed in this particular edge node...” para. 0121), a quantity of required resources, and M resource specifications, and M is a positive integer.
As to claim 10, Spoczynski modified by Dunsmore teaches The method according to claim 9, Spoczynski does not but Dunsmore teaches wherein deploying the instances of the service across the central cloud and the edge cloud comprises:
for each of the M resource specifications, determining a quantity of first instantiations of each resource specification in each of the N availability zones (“In this example of FIG. 1, the deployment causes a set of service instances 152A-152N for an example “first” service of the service group (represented as black squares) to various deployment zone 118 locations—here, two instances to a CSP edge location 142A as shown at circle (3A), one instance to a cloud provider network-managed edge location 140A as shown at circle (3B), and one instance to each of a first AZ 114A and a second AZ 114B of a first region 112A as shown at circle (3C)....” col. 27 lines 37 – 67); and
if a sum of quantities of first instantiations of each resource specification in all the availability zones is greater than or equal to the quantity of required resources, determining, based on the first instantiations of each resource specification in each availability zone, the resource requirement, and the deployment strategy, a quantity of second instantiations of each resource specification in each availability zone, and deploying the instances of the service based on the quantity of second instantiations of each resource specification in each availability zone (“..As introduced earlier, the cloud provider network 100 (sometimes referred to simply as a “cloud”) refers to a pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which can be virtualized or bare-metal. The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to user commands. These resources can be dynamically provisioned and reconfigured to adjust to variable load....” col. 6 lines 40 – 67) and (“...This placement may be localized at the beginning (e.g., only deploy to locations within or associated with a first region) and then scaled as needed based on client traffic/latency, distributed at the beginning (e.g., by placing resources in a wide number of locations, such as all locations or a random sampling of locations) and again scaled out or back based on traffic...” col. 27 lines 12 - 22).
It 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 was made to modify Spoczynski by applying the teachings of Dunsmore because Dunsmore’s system can be dynamically provisioned and reconfigured resources to scale up or down depending on demand of workload to save resources (col. 6 lines 35 – col. 7 lines 18 and col. 27).
As to claim 11, Spoczynski modified by Dunsmore teaches The method according to claim 9, Spoczynski teaches wherein the resource type comprises at least one of a virtual machine, a docker, or a bare metal server (“...the isolation environments may include: bare metal (dedicated) equipment, virtual machines, containers, virtual machines on containers, or combinations thereof...” para. 0090).
As to claims 14 – 19, these claims recite similar scope of claims 2 – 8. See rejection for claims 2 - 8 above.
Claims 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Spoczynski et al., (US PUB 2020/0228602 hereinafter Spoczynski) in view of Dunsmore et al., (US PAT 11,425,054), as applied to claims 2 and 14, and further in view of Qian et al., (US PUB 20160127201 hereinafter Qian).
As to claim 12, Spoczynski modified by Dunsmore teaches The method according to claim 2, Spoczynski does not but Dunsmore teaches wherein the method further comprises: if the N availability zones cannot meet the resource requirement of the service (“...In some implementations, an edge location 116 can be an extension of the cloud provider network substrate including a limited quantity of capacity provided outside of an AZ (e.g., in a small data center or other facility of the cloud provider that is located close to a user workload and that may be distant from any AZs)...” col. 16 lines 46 – 65).
Spoczynski and Dunsmore do not but Qian teaches prompting a user of a deployment failure (“..deploy services 112 responsive to service orders 108, request and/or orchestrate allocation of physical network resources 114 and/or virtual network resources 116 to host the services 112, detect failure conditions on the network 104 (e.g., by receiving one or more alerts 118)....” para. 0034).
It 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 was made to modify Spoczynski and Dunsmore by applying the teachings of Qian because Qian would detect system failure to and alert users for fixing (para. 0034).
As to claim 20, this claim recites similar scope of claim 12. See rejection for claim 12 above.
Conclusion
The prior art made of record but not relied upon request is considered to be pertinent to applicant’s disclosure.
Barclay, (US PAT 11,765,244), discloses a method of location-aware service-oriented application deployment management (title, abstract and figures 1 – 19).
Chen, (US PUB 2021/0399957), discloses a method of automatically managing performance of software deployed in a distributed computing environment (title, abstract and figures 1 – 3).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHUONG N HOANG whose telephone number is (571)272-3763. The examiner can normally be reached 9:5-30.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/PHUONG N HOANG/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194