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
The instant application having Application No. 18/678,121 filed on 5/30/2024 is presented for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below 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 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 or disclosed by the examiner.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submissions of the Information Disclosure Statement dated 5/30/2024 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 20210014114) in view of Abbasi (US 20170134520).
As per claim 1, Doshi discloses a computer-implemented method for dynamically optimizing microservice placement in a distributed edge and cloud computing environment (Abstract “workload placement in an edge environment. An example apparatus for workload placement in an edge environment includes an orchestrator to receive a request to execute a workload from an edge platform within an edge environment, and a capability controller to analyze the request to determine operating parameters for the workload from the edge platform, and analyze candidate edge tier and edge platform placements based on the operating parameters, the orchestrator to determine a candidate edge tier and edge platform placement for the workload based on a candidate edge tier and edge platform placement that satisfies the operating parameters.), comprising:
receiving application specifications that include telemetry data collection methods, placement rules, and modes of operation (Paragraph 34 “Telemetry can be generated from a plurality of sources including each hardware component or portion thereof, virtual machines (VMs), operating systems (OSes), applications, and orchestrators. Telemetry can be used by orchestrators, schedulers, etc., to determine a quantity, quantities, and/or type of computation tasks to be scheduled for execution at which resource or portion(s) thereof, and an expected time to completion of such computation tasks based on historical and/or current (e.g., instant or near-instant) telemetry. For example, a core of a multi-core central processing unit (CPU) can generate over a thousand different varieties of information every fraction of a second using a performance monitoring unit (PMU) sampling the core and/or, more generally, the multi-core CPU. Periodically aggregating and processing all such telemetry in a given edge platform, edge node, etc., can be an arduous and cumbersome process. Prioritizing salient features of interest and extracting such salient features from telemetry to identify current or future problems, stressors, etc., associated with a resource is difficult. Furthermore, identifying a different resource to offload workloads from a burdened resource is a complex undertaking.”);
validating the received application specifications to ensure completeness and correctness (Paragraph 35 “Some edge environments desire to obtain telemetry data associated with resources executing a variety of functions or services, such as data processing or video analytics functions (e.g., machine vision, image processing for autonomous vehicle, facial recognition detection, visual object detection, etc.). However, many high-throughput workloads, including one or more video analytics functions, may execute for less than a millisecond (or other relatively small time duration). Such edge environments do not have distributed monitoring software or hardware solutions or a combination thereof that are capable of monitoring such highly-granular stateless functions that are executed on a platform (e.g., a resource platform, a hardware platform, a software platform, a virtualized platform, etc.).”);
deploying the microservices according to initial placement rules (Paragraphs 25-27);
collecting and evaluating telemetry data from the deployed microservices and underlying infrastructure against the placement rules (Paragraph 34 “Telemetry can be generated from a plurality of sources including each hardware component or portion thereof, virtual machines (VMs), operating systems (OSes), applications, and orchestrators. Telemetry can be used by orchestrators, schedulers, etc., to determine a quantity, quantities, and/or type of computation tasks to be scheduled for execution at which resource or portion(s) thereof, and an expected time to completion of such computation tasks based on historical and/or current (e.g., instant or near-instant) telemetry. For example, a core of a multi-core central processing unit (CPU) can generate over a thousand different varieties of information every fraction of a second using a performance monitoring unit (PMU) sampling the core and/or, more generally, the multi-core CPU. Periodically aggregating and processing all such telemetry in a given edge platform, edge node, etc., can be an arduous and cumbersome process. Prioritizing salient features of interest and extracting such salient features from telemetry to identify current or future problems, stressors, etc., associated with a resource is difficult. Furthermore, identifying a different resource to offload workloads from a burdened resource is a complex undertaking.”); and
dynamically adjusting the placement of microservices responsive to a determination that current microservice placement is suboptimal based on the evaluating of the collected telemetry data (Paragraph 42 “Examples disclosed herein include analyzing candidate edge tier and edge platform placements of workloads based on the operating parameters. In some examples, analyzing the candidate edge tier and edge platform placements includes determining resource availabilities of each of the candidate edge tier and edge platform placements. In some examples, the resource availabilities correspond to power availability, thermal availability, latency availability, and/or bandwidth availability at each of the candidate edge tier and edge platform placements based on telemetry data from each of the candidate edge tier and edge platform placements. Examples disclosed herein include determining a candidate edge tier and edge platform placement for the workload based on a candidate edge tier and edge platform placement that satisfies the operating parameters. In some examples, determining the candidate edge tier and edge platform placement for the edge platform includes: determining an operating parameter percentage for each of the candidate edge tier and edge platform placements, the operating parameter percentage corresponding to a percentage of the resource availabilities of an edge tier and edge platform placement that satisfy the resource requirements of the edge platform; selecting the edge tier and edge platform placement with the optimal operating parameter percentage as the candidate edge tier and edge platform placement; and implementing the workload at the candidate edge tier and edge platform placement. In some examples, in response to the operating parameter percentages for each of the candidate edge tier and edge platform placements not satisfying a threshold, resource requirements and a cost function weight are adjusted. As used herein, “cost function weight” or “cost function” refer to a penalty that increases with a magnitude of error (e.g., a number of iterations) to ensure accuracy and security during placement and execution of a workload.”).
Doshi does not expressly disclose but Abbasi discloses composing an application graph where vertices represent microservices and edges represent connections between the microservices (Abstract “distributed multi-component network-aware service placement in a resource pool include utilizing a hierarchy of agents associated with computing resources of a cloud architecture. An agent in the hierarchy can merge solution encodings to find cover sets indicating feasible placement solutions that can cover an entire application placement request. The agent can partition the components across its children nodes such that global network traffic is minimized. An application graph is generated with components as vertices and edges indicating connections between the components and having associated weights indicating a data transfer rate between the components. The edges can be sorted, and each cover set can be processed by repeatedly assigning unassigned pairs of components having higher data transfer rates to a common assignment set. If multiple placement solutions are found, determined placement costs for each can be used to identify the preferred placement.” See also, paragraph 11 “a hierarchy of agents can identify a network-optimal placement configuration for a multi-component application within a distributed cloud satisfying the requirements of the application. In some embodiments, this network-aware service placement does not utilize any centrally-maintained repository of resource availability or topology information of all resources in the cloud.”);
checking availability of resources specified in the application graph (Paragraph 12 “The root agent acts as a parent to a plurality of intermediate agents in a hierarchy of agents, and each of the plurality of intermediate agents acts as a parent to one or more descendant agents associated with one or more electronic devices having resources available for service placement.”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Doshi to include the teachings of Abbasi because it facilitates interdependent workload components by distributing workload amongst them.
As per claim 2, Doshi further discloses further comprising dynamically generating and executing a fallback placement strategy responsive to resource availability changes during microservice execution (Paragraph 34 “Prioritizing salient features of interest and extracting such salient features from telemetry to identify current or future problems, stressors, etc., associated with a resource is difficult. Furthermore, identifying a different resource to offload workloads from a burdened resource is a complex undertaking.”).
As per claim 3, Doshi further discloses wherein the telemetry data includes real-time video frame processing metrics, such as frame rate, processing time per frame, and dropped frame count (Paragraph 30 “Examples of workloads to be executed in an edge environment include autonomous driving computations, video surveillance monitoring, machine learning model executions, and real time data analytics. Additional examples of workloads include delivering and/or encoding media streams, measuring advertisement impression rates, object detection in media streams, speech analytics, asset and/or inventory management, and augmented reality processing.”).
As per claim 4, Doshi further disclose further comprising utilizing machine learning algorithms to predict future workload changes based on historical telemetry data and preemptively adjusting microservice placement accordingly (Paragraph 48 “Examples disclosed herein can be expanded with artificial intelligence (AI) objective-based techniques such as re-enforced learning. For example, the data generated and post-mortem performance and telemetry data per each of the services can be provided to AI models that afterwards can utilize the disclosed examples to have another input in the decision process. As in many other types of architectures, the re-enforced learning can be implemented in a centralized location (and fed back to the distributed layers) such as clouds or in a federated learning approach. The later may allow more specific learning based on geo-locations or different parts of the edge computing system 100, for example.”).
As per claim 6, Doshi further discloses wherein the application specifications include rules for prioritizing and dynamically adjusting microservice placement for microservices deemed critical during periods of high workload to ensure consistent performance of essential functions, with the dynamically adjusting microservice placement including redistributing computational loads across multiple edge nodes to prevent overloading any single node (Paragraph 33 “To meet the low-latency and/or high-bandwidth demands of endpoint devices, orchestration in edge clouds is performed on the basis of timely information about the utilization of many resources (e.g., hardware resources, software resources, virtual hardware and/or software resources, etc.), and the efficiency with which those resources are able to meet the demands placed on them. Such timely information is generally referred to as telemetry (e.g., telemetry data, telemetry information, etc.).”).
As per claim 7, Doshi further discloses further comprising continuously collecting the telemetry data and re-evaluating the placement rules at periodic intervals to maintain optimal performance (Paragraph 78).
Claims 5, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi in view of Abbasi in further view of Coviello (US 20230153182).
As per claim 5, Doshi does not expressly disclose but Coviello discloses further comprising introducing additional microservices to bridge communications between microservices distributed across multiple DataX deployments (Paragraphs 15-17).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Doshi to include the teachings of Coviello because it allows for the deployment of a known technique such as DataX in order to address the same problem as address by the combination of references.
As per claims 8-11, 13 and 14, they are system claims having similar limitations as cited in claims 1-4, 6 and 7 and are rejected under the same rationale.
As per claims 15-17, 19 and 20, they are product claims having similar limitations as cited in claims 1-4, 6 and 7 and are rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shivadas (US 8,914,836) discloses allowing for the load adaptive downloading, processing, and rendering of video by a video processing client, where the downloading is adaptive to the processing load of a computing system on which a video processing client operates.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY A MUDRICK whose telephone number is (571)270-3374. The examiner can normally be reached 9am-5pm Central Time.
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, Pierre Vital can be reached at (571)272-4215. 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.
/TIMOTHY A MUDRICK/Primary Examiner, Art Unit 2198 10/02/2026
Prosecution Insights