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 .
Response to Arguments
On page 10, applicant argues that “deploying the container associated with the software application using the runtime and the storage driver.” Examiner respectfully disagrees the deployment step is not the result of any operation recited in the preceding limitations. Also deploying a container is well understood, routine and convention in containerized and distributed computing environments. The deploying limitation constitutes insignificant post-solution activity and does not integrate the abstract ide into a practical application.
Applicant' s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection.
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.
In adhering to the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG), claim 1’s evaluation under Step 1 indicates it is directed to a statutory class. Herein, the claims fall within statutory class of machine.
With Step 1 being directed to a statutory category, 2019 PEG flowchart is directed to Step 2. Step 2 is a two prong inquiry. Prong one considers whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). In this case independent claim 1 recite mental process.
Further, claim 1 recites step 2 prong 1 steps of:
“generating, by a runtime selector of a management node in a distributed computing environment, a mapping that associates each runtime of a set of runtimes to at least one storage driver of a set of storage drivers based on historical data that indicates a compatibility of executing the at least one storage driver with the runtime;
identifying, by the runtime selector, a runtime of the set of runtimes and a storage driver of the set of storage drivers for the software application from the mapping that satisfies the set of criteria for the software application;
generating, by the runtime selector, a container associated with the software application using the runtime and the storage driver;
and deploying the container associated with the software application using the runtime and the storage driver..
Under their broadest reasonable interpretation these limitations are directed to collecting information, analyzing information (mapping, identifying and associating runtimes/drivers based on information) and generating a result. This comprises a mental process or abstract idea. See MPEP 2106.04(a)(2)(ii). For example, a human could receive a set of requirements , generating an analysis from the requirements, select suitable components, and initiating a sending of data to the components, which is a mental process.
The claims do not integrate the abstract idea into a practical application. The computing components and the steps of generating mapping, receiving , and selecting are performed by generic computing functions. The limitation of “generating a container” is the result of applying the selection but it just uses the abstract idea on generic computing components (runtime selector, management node ). Deploying a container is well understood, routine and convention in containerized and distributed computing environments. The deploying limitation constitutes insignificant post-solution activity and does not integrate the abstract ide into a practical application. Therefore, claim 1 is directed toward an abstract idea. Independent claims 9 and 16 and are rejected for the same reasons.
The dependent claims just add further data processing, information analysis or data transmission steps to the independent claims. For example claims 2-5, 10-13 and 17-20 recite steps of adjusting, updating or responding to changes in data. This steps amount to conventional computer operations and do not integrate the abstract idea into a practical application.
Claims 6-8 and 14-15 just expands on the type of criteria such as metrics, the use of machine learning algorithms and communication with client devices.
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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jobi (US 20180189122 A1) in view of Kochura (US 20220027778 A1).
Regarding claim 1 , Jobi teaches:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising: (Claim 8. A system comprising)
generating, by a runtime selector of a management node in a distributed computing environment, a mapping that associates each runtime of a set of runtimes to at least one storage driver of a set of storage drivers based on historical data that indicates a compatibility of executing the at least one storage driver with the runtime. ([0100] According to various embodiments, the performance characteristic may be identified in any of various ways. For example, the performance characteristic may be identified by receiving configuration information from a remote location such as a central image layer repository or a different node in a cluster of nodes. As another example, the performance characteristic may be determined dynamically and/or automatically by the graph driver. For instance, the graph driver may review past performance information associated with the application and determine characteristics such as access frequency and/or access sequentialness. See also [0102-0106, 0109-0111])
receiving, by the runtime selector, a set of criteria for a software application. ([0095] At 602, a request to store an application image layer to disk is received. According to various embodiments, the request may be generated when an application image layer is retrieved from a remote location for use on the local system to generate an application container. For instance, when a request to instantiate a new application container is received, the system may retrieve any application image layers necessary for instantiating the new application container. See also [0100])
identifying, by the runtime selector, a runtime of the set of runtimes and a storage driver of the set of storage drivers for the software application from the mapping that satisfies the set of criteria for the software application. ([0102] At 608, a storage location is selected for storage based on the identified performance characteristic. According to various embodiments, the storage location may be selected by matching the characteristics of the block device with the characteristics of the application image layer. For example, an application image layer likely to be accessed in a relatively random fashion may be stored on a solid-state drive, while an application image layer likely to be accessed in a relatively sequential fashion may be stored on a spinning disk drive. As another example, an application image layer having a relatively higher priority may be located on a block device with relatively lower latency, while an application image layer having a relatively lower priority may be located on a block device with relatively higher latency. See also [0103-0106, 0109-0111])
deploying the container associated with the software application using the runtime and the storage driver. ([0053] According to various embodiments, the graph driver 102 may be configured to store and manage application images associated with application containers. Application containers may be instantiated and implemented based on shared application images. The application image layers may be stored as read-only, and may be used as the basis of instantiating application containers. For example, application containers, such as application A container 140, application A container 146, and application C container 150 may be instantiated based on their respective application image layers which may be application A image layers 110 and application C image layers 126. In this example, the underlying image layers may be stored and shared in application image layer manager 108, and each application container may store application instance data used to instantiate a particular instance of an application. See also [0102-0106, 0109-0111])
Jodi does not appear to explicitly teach: generating, by the runtime selector, a container associated with the software application using the runtime and the storage driver;
However, Kochura teaches: ([0043] Controller 110 may identify runtime parameters of software container 120 (306). Controller 110 may identify these runtime environments during runtime of software container 120 in runtime environment 130A. In some examples, controller 110 may gather a set of real time static parameters of software container 120, where these real time static parameters are an updated version of the preliminary static parameters identified by controller 110 (where the preliminary static parameters were those static parameters identified at step 302). Put differently, where static parameters are gathered by controller 110 both prior to runtime to identify an initial runtime environment 130 and then during runtime, a version of the static parameters that are gathered prior to runtime may be classified as preliminary static parameters and a (potentially, but not necessarily) different version of those static parameters gathered during runtime may be classified as real time static parameters. See also [0035-0039])
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Jobi and Kochura before them, to include Kochura’s runtime selection techniques in Jobi’s system to deplou software containers using storage driver based on performance characteristics. One would have been motivated to make such a combination to improve container deployment by considering runtime environment and storage driver. The combination merely applies known runtime techniques and would have yield predictable results as both references are directed to deploying containers based on observed characteristics and past performance.
Regarding claim 2 , Jobi teaches:
The system of claim 1, wherein the set of criteria is a first set of criteria, the runtime is a first runtime, the storage driver is a first storage driver, and the container is a first container, and the memory device further includes instructions executable by the processing device to cause the processing device to perform operations comprising: identifying, by the runtime selector, a second runtime of the set of runtimes and a second storage driver of the set of storage drivers for the software application from the mapping that satisfies the first set of criteria for the software application; generating, by the runtime selector, a second container associated with the software application using the second runtime and the second storage driver; receiving, by the runtime selector, first performance metrics for execution of the software application in the first container and second performance metrics for execution of the software application in the second container; and adjusting a subsequent selection of one of the first runtime and the second runtime and one of the first storage driver and the second storage driver based on the first performance metrics and the second performance metrics. ([0096] In some implementations, the request to store an application image layer to disk may be generated periodically. For example, the system may periodically evaluate the storage of image layers at the graph driver. Then, application image layers may be moved from one storage location to another to reflect features such as performance characteristics and available disk space. [0097] At 604, a performance characteristic associated with the application image layer is identified. According to various embodiments, the performance characteristic may be associated with an application as a whole or may vary for different application image layers associated with an application. [0100] According to various embodiments, the performance characteristic may be identified in any of various ways. For example, the performance characteristic may be identified by receiving configuration information from a remote location such as a central image layer repository or a different node in a cluster of nodes. As another example, the performance characteristic may be determined dynamically and/or automatically by the graph driver. For instance, the graph driver may review past performance information associated with the application and determine characteristics such as access frequency and/or access sequentialness. [0101] At 606, two or more potential storage locations are identified for the application image layer. In some embodiments, a graph driver may have access to a number of different block devices, such as the block devices 134 shown in FIG. 1. Each block device may be associated with any of various types of characteristics. For example, a block device may be a solid-state drive or a spinning disk drive. As another example, different block devices may vary in terms of storage capacities, data retrieval latencies, data retrieval bandwidth, and other such characteristics. Such characteristics may be provided explicitly by the operating system or may be inferred by the graph driver based on past data access.)
Regarding claim 3 , Kochura teaches:
The system of claim 1, wherein the memory device further includes instructions executable by the processing device to cause the processing device to identify the runtime of the set of runtimes for the software application from the mapping that satisfies the set of criteria for the software application by: determining a performance threshold based on the set of criteria for the software application; and identifying the runtime based on historical data of the runtime exceeding the performance threshold. ([0028] Controller 110 may determine that one of runtime environments 130 matches software container 120 when a performance of software container 120 satisfies a threshold, and/or when a cost (e.g., a billable resource usage, such as a usage of memory or processing power) of software container 120 as executed within the assigned runtime environment 130 satisfies a threshold. See also [0030-0031])
Regarding claim 4 , Jobi teaches:
The system of claim 1, wherein the memory device further includes instructions executable by the processing device to cause the processing device to perform operations comprising: receiving, by the runtime selector, an adjustment to the set of criteria; and adjusting, by the runtime selector, the mapping substantially contemporaneously based on the adjustment to the set of criteria. ([0099] In some implementations, the performance characteristic may indicate a prioritization of data access between different applications or application image layers. For example, one application or application image layer may be designated as having a relatively high priority, while another application or application image layer may be designated has having a relatively low priority.[0100] According to various embodiments, the performance characteristic may be identified in any of various ways. For example, the performance characteristic may be identified by receiving configuration information from a remote location such as a central image layer repository or a different node in a cluster of nodes. As another example, the performance characteristic may be determined dynamically and/or automatically by the graph driver. For instance, the graph driver may review past performance information associated with the application and determine characteristics such as access frequency and/or access sequentialness.)
Regarding claim 5 , Jobi teaches:
The system of claim 1, wherein the memory device includes instructions executable by the processing device to cause the processing device to generate the mapping by: adjusting, by the runtime selector, the mapping substantially contemporaneously based on availability of each runtime of the set of runtimes, compatibility of each storage driver of the set of storage drivers and each runtime of the set of runtimes, and the set of criteria for the software application. ([0104] At 612, the storage of the application image layer is recorded in a database. According to various embodiments, recording the storage of the application image layer in the database may involve adding or updating a database entry to include information such as a name, checksum, storage location, and/or other such metadata associated with the application image layer. For instance, the information may be recorded in the database 104 shown in FIG. 1.[0105] FIG. 7 illustrates an example of a method 700) for application image layer querying. According to various embodiments, the method 700 may be performed at a graph driver such as the graph driver 102 shown in FIG. 1. The method 700 may be used to provide any of various types of information about application images stored via the graph driver. [0106] At 702, a request to provide information about one or more image layers is received. In some implementations, a request may be received via a network from a centralized control point or a different node in a distributed system. Alternately, or additionally, a request may be generated locally, for instance when determining where to store an application image layer in the method 600 shown in FIG. 6.)
Regarding claim 6 , Jobi teaches:
The system of claim 1, wherein the set of criteria includes a security metric, the runtime is a first runtime, the storage driver is a first storage driver, and the container is a first container and wherein the memory device includes instructions executable by the processing device to cause the processing device to: adjust, by the runtime selector, the mapping based on the security metric; identify, by the runtime selector, a second runtime of the set of runtimes and a second storage driver of the set of storage drivers from the mapping that satisfies the security metric; and generate, by the runtime selector, a second container that exhibits stronger isolation than the first container using the second runtime and the second storage driver. ([0102] At 608, a storage location is selected for storage based on the identified performance characteristic. According to various embodiments, the storage location may be selected by matching the characteristics of the block device with the characteristics of the application image layer. For example, an application image layer likely to be accessed in a relatively random fashion may be stored on a solid-state drive, while an application image layer likely to be accessed in a relatively sequential fashion may be stored on a spinning disk drive. As another example, an application image layer having a relatively higher priority may be located on a block device with relatively lower latency, while an application image layer having a relatively lower priority may be located on a block device with relatively higher latency. See also [0097-100])
Regarding claim 7 , Jobi teaches:
The system of claim 1, wherein the memory device further includes instructions executable by the processing device to cause the processing device to perform operations comprising: receiving, by the runtime selector, a request from a client device, the request including the set of criteria for the software application; generating, by the runtime selector, the mapping based on the request; and providing, by the runtime selector, the runtime and the storage driver to the client device based on the mapping. ([0106] At 702, a request to provide information about one or more image layers is received. In some implementations, a request may be received via a network from a centralized control point or a different node in a distributed system. Alternately, or additionally, a request may be generated locally, for instance when determining where to store an application image layer in the method 600 shown in FIG. 6. [0107] At 704, authorization information corresponding with the request is verified. According to various embodiments, verifying authorization information may allow the graph driver to ensure that the source of the query is authorized to access the information requested by the query. For instance, the graph driver may use information associated with the request to verify that the request originated from a central control point or another node in a distributed system.)
Regarding claim 8 , Jobi teaches:
The system of claim 1, wherein the memory device further includes instructions executable by the processing device to cause the processing device to perform operations comprising: inputting the set of criteria into a machine learning algorithm; and receiving an output of the machine learning algorithm indicating the runtime and the storage driver. ([0039] Memory 230 may further include machine learning techniques 246 that controller 110 may use to improve a process of determining parameters of software containers to assign these software containers to runtime environments as discussed herein over time. Machine learning techniques 244 can comprise algorithms or models that are generated by performing supervised, unsupervised, or semi-supervised training on a dataset, and subsequently applying the generated algorithm(s) or model(s) to assign software containers. Using these machine learning techniques 246, controller 110 may improve an ability of assigning software containers over time.)
Regarding claim 9, Jodi teaches:
A method comprising. (Claim 1. A method comprising: )
the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.)
Regarding claim 10, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 11, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 12, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Regarding claim 15, the claim recites similar limitation as corresponding claim 8 and is rejected for similar reasons as claim 8 using similar teachings and rationale.
Regarding claim 16, Kochura teaches:
A non-transitory computer-readable medium comprising instructions that are executable by a processing device for causing the processing device to perform operations comprising. (Claim 15. One or more non-transitory computer readable media having instructions stored thereon for performing a method, the method comprising:)
Regarding claim 17, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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 CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199