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 § 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.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the clam recites “a computer-readable medium storing computer executable code for a process implemented by one or more computing devices.” In view of the specification:
[0024] Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise a random-access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.
As demonstrated, the computer-readable medium is not limited to hardware, but can be any software or data structures. Software, per se, is non-statutory.
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.
Claim(s) 1-7, and 9-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gokan Khan et al., (US 20220385542, hereinafter referred to as “GK”) in view of Savalle et al., (US 20240406078, hereinafter referred to as “Savalle”).
Regarding claim 1, GK teaches a method, implemented by one or more computing devices, comprising:
obtaining an initial deployment configuration specifying connectivity between a plurality of microservices of a distributed application (abstract - Based on a resource allocation configuration, an initial set of training data for the plurality of microservices within the network (1260) is determined.);
deploying the plurality of microservices in a high-capacity computing environment (abstract - A method (1000) for performance modeling of a plurality of microservices (215) includes deploying the plurality of microservices (215) within a network (1260));
monitoring resource utilization and performance metrics while executing the distributed application with sufficient resources in the high-capacity computing environment ([0052] To evaluate the performance of an NFC system; [0055] For example, with regard to the initial placement of the microservices 215 at step 410, it is recognized that before starting to perform benchmarks, the CNF's microservices are deployed on a lab environment. According to certain embodiments, in order to get accurate results, this deployment may follow one or more of the following criteria: [0056] Each microservice 215 may be placed on a completely isolated worker node 220, such that other microservices 215 may not have negative performance effect over a microservice 215 (no noisy neighbor). If worker nodes 220 are VMs, they need to be explicitly pinned to CPU cores (using NUMA filters in case of OpenStack). [0057] The placement of microservices 215 may need to hold all affinity rules, according to certain embodiments. [0058] There should be minimum systemic performance bottlenecks in the deployment (no misconfigurations, scalability issues, etc.) such that the resource allocation configuration of microservices would be the only bottleneck for getting higher QoS.); and
generating multiple candidate service profiles by varying resource allocations for the plurality of microservices ([0053] According to certain embodiments, CNFs QoS metrics behaviour modeling may be based on an algorithm that performs a minimal set of benchmarks and recommends a resource allocation and replica size configuration for each microservice 215 in a service chain 315. In other words, for each SC.sub.k, 215 given a set of SLA requirements {SLA.sub.α.sup.k(q.sub.c)}.sub.q.sub.c.sub.∈Q, the final goal is to recommend an optimal amount of resource capacities for each microservice MS.sub.i,j 215 in a production environment based on a minimum number of experiments in a smaller-scale deployment and guaranty the agreed QoS constraints on all QoS metrics q.sub.c∈Q for a user α. It is assumed that the NFC system comes with a sophisticated benchmark tool that allows to define a test scenario based on a given service chain(s), arrival rate(s), duration(s) and burst setting(s).).
However, GK does not explicitly teach collecting performance measurements and quality of experience feedback for each candidate service profile; and generating a final service profile based on the collected performance measurements and quality of experience feedback.
Savalle teaches collecting performance measurements and quality of experience feedback for each candidate service profile ([0080] The techniques herein allow for the collection of user labels/QoE feedback in a for collecting user labels in a sample-efficient manner, by leveraging two levels of active learning: 1.) by automatically onboarding new users to the data collection program based on how interesting their data may be and/or 2.) by selecting when to query onboarded users for QoE feedback using feature vectors (or sequences thereof, to capture time-based patterns), and the current model uncertainty (to focus queries on the more informative cases to decrease the overall uncertainty of the model in hard-to-predict situations). In some aspects, this active learning strategy allows the system to quickly (re) train QoE prediction models that are able to accurately predict the QoE across a large range of situations, including more fringe ones, with only a limited budget of user feedback queries.); and
generating a final service profile based on the collected performance measurements and quality of experience feedback ([0098] Referring again to FIG. 5, onboarding recommendation engine 504 may monitor the stream of predictions and uncertainties from QoE uncertainty estimator 502 and compute statistics for those users not currently onboarded to the feedback mechanism. At a regular interval, onboarding recommendation engine 504 may select the top n-number of users to onboard based on those statistics. For instance, onboarding recommendation engine 504 may compute the daily maximum uncertainty per user (or a percentile of that distribution for more robustness) and output the ten users with the highest value. In some embodiments, onboarding recommendation engine 504 may also be configured to select users for onboarding in accordance with a budget of users that can be onboarded by time interval, so as not to be too intrusive to the overall population of users.).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to incorporate the QoE feedback collection of Savalle into the profile of GK in order to improve accuracy of the generated performance model by accounting for user-perceived application quality in addition to objective performance measurements.
Regarding claim 2, GK teaches the method of claim 1, wherein deploying the plurality of microservices comprises: creating virtual nodes in the high-capacity computing environment ([0116] The functions may be implemented by one or more applications 1420 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.); and instantiating each microservice of the plurality of microservices in at least one of the virtual nodes (abstract - deploying the plurality of microservices within a network).
Regarding claim 3, GK teaches the method of claim 1, wherein monitoring resource utilization and performance metrics comprises: measuring at least one of CPU utilization, memory utilization, and storage utilization for each microservice ([0063] QoS metric q.sub.c∈Q (e.g. serving throughput, latency, CPU utilizations, etc.); and measuring network performance metrics including at least one of message rates, message sizes, link delays, and packet loss rates between communicating microservices ([0134] SLA Service Level Agreement: e.g. max arrival rate and max latency).
Regarding claim 4, GK teaches the method of claim 1, wherein generating multiple candidate service profiles comprises: selecting different combinations of compute and communication resource allocations; applying network emulation to simulate different network conditions between microservices; and recording the resource allocations and network conditions in a database ([0063] According to certain embodiments, such training data is gathered by selecting a single microservice 215 at a time and assigning a resource allocation configuration T.sub.p=(t.sub.p (r.sub.d.sub.1), . . . , t.sub.p(r.sub.d|R|)) (e.g. a t.sub.p(cpu) can be measured as the milicpu, or for memory can be measured as bytes) to each of its resource types r.sub.dεR (e.g., CPU, memory, etc.), while assigning maximum possible resources to other microservices in the service chain 315.).
regarding claim 5, GK teaches the method of claim 4, wherein applying network emulation comprises simulating at least one of: packet delays; delay variations; bandwidth limitations; and packet loss rates ([0043] Certain embodiments of the present disclosure may provide solutions enabling model-based resource recommendation for cloud applications by the network node. Certain embodiments may include functionality providing a model based approach for extracting resource capacity and replication size versus application's QoS behaviours. In particular, certain embodiments may perform only a minimal set of benchmarks (instead of trying out all possible combinations) to recommend an efficient initial resource configuration for each microservice. According to certain embodiments, the recommended resource configuration may satisfy all the required QoS constraints agreed on a given user's SLA. In a particular embodiment, the techniques may be implemented on a cloud-native 5G HSS-frontend prototype together with an MME simulator, which both are deployed on top of Kubernetes. Such a system may reach 87% accuracy in the initial modeling phase.).
Regarding claim 6, GK teaches the method of claim 1, wherein collecting quality of experience feedback comprises at least one of: collecting objective measurements for applications with quantifiable performance metrics ([0052] To evaluate the performance of an NFC system, one should measure the key QoS metrics (serving throughput, latency, etc.). This set of QoS metrics may be defined as Q={q.sub.c}.sub.c=1.sup.|Q|. Assuming that an SLA agreement for a customer a on service chain SC.sub.k 310a-z and QoS metric q.sub.c∈Q is in place, SLA.sub.α.sup.k(q.sub.c) may be defined such that it denotes the guaranteed value of QoS metric q.sub.c in user αSLA agreement on service chain SC.sub.k 310a-z.).
However, GK does not teach collecting subjective user feedback ratings for applications requiring human evaluation. Savalle teaches collecting subjective user feedback ratings for applications requiring human evaluation (abstract - user feedback collection for application quality of experience (QoE) prediction). The motivation to combine is the same as claim 1.
Regarding claim 7, GK teaches the method of claim 1, further comprising: training a machine learning model using the collected performance measurements and quality of experience feedback; and using the trained machine learning model to predict application performance under different resource conditions ([0061] As mentioned in previous sections, one of the main challenges with CNFs is the huge number of separately configurable microservices 215 as well as sheer number of combinations of configuration parameters which makes it very time consuming to benchmark all possible setting. If there is no systemic bottleneck in a deployment (based on the criteria discussed above) and QoS measures in a service chain 315 behave harmonically (as is typical) with the amount of resource capacities assigned to its microservices 215, an algorithm is proposed to effectively select and benchmark only a small subset of configurations and predict the value of the rest using machine learning models. Because it is not necessary to try out all possible resource configurations with this methodology, both the dimensioning time as well as the number of benchmarks required is dramatically reduced for modeling the effect of resource configuration of microservices 215 on a service chain's QoS measurements.).
Regarding claim 9, GK teaches the method of claim 1, further comprising validating the service profile generation by: implementing a load generator to simulate a configurable workload pattern; and monitoring application behavior under the simulated workload pattern ([0043] Certain embodiments of the present disclosure may provide solutions enabling model-based resource recommendation for cloud applications by the network node. Certain embodiments may include functionality providing a model based approach for extracting resource capacity and replication size versus application's QoS behaviours. In particular, certain embodiments may perform only a minimal set of benchmarks (instead of trying out all possible combinations) to recommend an efficient initial resource configuration for each microservice. According to certain embodiments, the recommended resource configuration may satisfy all the required QoS constraints agreed on a given user's SLA. In a particular embodiment, the techniques may be implemented on a cloud-native 5G HSS-frontend prototype together with an MME simulator, which both are deployed on top of Kubernetes. Such a system may reach 87% accuracy in the initial modeling phase).
Regarding claim 10, GK teaches the method of claim 9, wherein the load generator is configured to: generate adjustable CPU and memory utilization patterns; and simulate different messaging patterns between microservices ([0043] Certain embodiments of the present disclosure may provide solutions enabling model-based resource recommendation for cloud applications by the network node. Certain embodiments may include functionality providing a model based approach for extracting resource capacity and replication size versus application's QoS behaviours. In particular, certain embodiments may perform only a minimal set of benchmarks (instead of trying out all possible combinations) to recommend an efficient initial resource configuration for each microservice. According to certain embodiments, the recommended resource configuration may satisfy all the required QoS constraints agreed on a given user's SLA. In a particular embodiment, the techniques may be implemented on a cloud-native 5G HSS-frontend prototype together with an MME simulator, which both are deployed on top of Kubernetes. Such a system may reach 87% accuracy in the initial modeling phase).
Regarding claim 11, GK teaches the method of claim 1, wherein the final service profile includes: compute resource requirements for each microservice; and communication requirements between communicating microservices ([0004] FIG. 1 demonstrates SLA violations over time as a result of uncharted resource requirements of a set of microservices in a 5G Cloud-native Network Function (CNF). FIG. 1 also shows the corresponding scaling operations (both scale-ups and scale-downs) to heal the failures in the Network Function Cloudification (NFC) system. FIG. 1 shows a relatively high failure rate or a relatively low MTBF as a result of wrong or no minimum resource requirements).
Regarding claim 12, GK teaches the method of claim 11, wherein the communication requirements specify: maximum tolerable message delays; bandwidth requirements; message rates; and packet loss rate tolerances ([0082] In a particular embodiment, a communication capacity of each of the plurality of microservices is considered when determining the at least one network node to host each of the plurality of microservices. In particular embodiments, the communication capacity may be the network bandwidth.).
Regarding claim 13, GK teaches the method of claim 1, further comprising: monitoring runtime performance of the distributed application using the final service profile; detecting when performance requirements are not being met; and dynamically adjusting resource allocations to maintain application performance ([0019] Another advantage may be that certain embodiments extract a behavioural model for microservices with any kind of QoS/performance behaviour, either linearly or non-linearly, or any other kind of distribution. Moreover, certain embodiments may provide a parametrized solution, so that one can change, add, delete or adjust modeling parameters to get the best results if needed. Moreover, certain embodiments work with any type of resource types, QoS metrics and SLAs.).
Regarding claim 14, GK teaches the method of claim 1, wherein the high-capacity computing environment comprises at least one of: a single server with multiple CPU cores; a cluster of multiple servers; and a cloud computing infrastructure ([0120] As shown in FIG. 15, hardware 1430 may be a standalone network node with generic or specific components. Hardware 1430 may comprise antenna 14225 and may implement some functions via virtualization. Alternatively, hardware 1430 may be part of a larger cluster of hardware (e.g. such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 14100, which, among others, oversees lifecycle management of applications 1420.).
Regarding claim 15, GK teaches the method of claim 1, further comprising: storing the final service profile in a structured data format; and deploying the final service profile with the distributed application for use by an orchestrator in managing resource allocation ([0120] As shown in FIG. 15, hardware 1430 may be a standalone network node with generic or specific components. Hardware 1430 may comprise antenna 14225 and may implement some functions via virtualization. Alternatively, hardware 1430 may be part of a larger cluster of hardware (e.g. such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 14100, which, among others, oversees lifecycle management of applications 1420.).
Claims 16-19 are similar to claims 1-4, respectively, therefore are rejected under the same rationale.
Claim 20 is similar to claim 1, therefore is rejected under the same rationale.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gokan Khan et al., (US 20220385542, hereinafter referred to as “GK”) in view of Savalle et al., (US 20240406078, hereinafter referred to as “Savalle”) in further view of Kankani et al. (US 20240354016, hereinafter referred to as “Kankani”).
Regarding claim 8, neither GK nor Savalle teaches the method of claim 1, wherein generating the final service profile comprises: generating a hierarchical service profile including one or more tiers of resource requirements; and specifying minimum and desired performance levels for each tier.
Kankani teaches generating the final service profile comprises: generating a hierarchical service profile including one or more tiers of resource requirements; and specifying minimum and desired performance levels for each tier (abstract - Systems and methods for improving inbound/outbound prioritization and processing for large blob workloads. The system can receive latency profiles and determine parameters that control movement of data across data tiers. The method includes receiving a plurality of commands to interact with data. The method includes detecting conditions that fail to satisfy at least one latency profile. The method includes adjusting parameters based on detecting the conditions. Adjusting the parameters adjusts a percentage of data being classified in a first tier to being reclassified in a second tier to satisfy the latency profiles. The method includes processing the plurality of commands based on the adjusted percentage of data.).
Before the effective filing date, one of ordinary skill in the art would have been motivated to incorporate the teaching of Kankani into the teachings of GK and Savalle because doing so would provide a structured representation of resource-performance tradeoffs, therefore facilitating automated orchestration decisions, and enables selection of an appropriate operating level based on available resources while maintaining desired application performance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Arvidsson et al., US 8972568 - generate quality of experience (QoE) metrics for hypertext transfer protocol (HTTP) sessions.
Gupta et al., US 20210142159 - receiving microservice profile information at a microservice profiler, performing lexical analysis of the microservice profile information (where the lexical analysis produces tokenized information), generating microservice modification information by performing machine learning analysis of one or more inputs (where the one or more inputs comprise the tokenized information), and outputting the microservice modification information from the microservice profiler.
Chen et al., CN 113064712 - a micro-service optimization deployment control method based on cloud-edge environment, system and cluster, the micro-service optimization deployment control method based on the cloud-edge environment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, 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 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights