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 Objections
Claim 10 objected to because of the following informalities: "that is determined by an orchestration layer of that facilitates operation of the respective microservices" is stated. A leftover "of" seems to be in the text that reduces clarity. Removal Appropriate correction is required.
Claims 11-13 are dependent on objected claim 10, so claims 11-13 are objected to for being dependent on objected claim 10.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1,9, and 14 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Sukhomlinov (US 2019/0004871 A1), hereinafter Sukhomlinov.
Regarding claim 1, Sukhomlinov recites:
A system, comprising: at least one processor; and at least one memory that stores executable instructions that, when executed by the at least one processor, facilitate performance of operations, (see e.g., page [01], abstract, “configured to: receive a microservice instance registration for a microservice accelerator, wherein the registration includes a microservice that the microservice accelerator is configured to provide” Microservices facilitate the performance of their adjacent services by allowing for developers to focus on the functionality of the service they are designing, rather than each dependency and unique feature of their machine instance.) comprising:
identifying a containerized application that comprises a group of microservices, wherein respective microservices of the group of microservices correspond to respective sidecars of a group of sidecars; (see e.g., page [09], paragraph [0113], “In operation 3, MANO 628 launches or otherwise provisions an instance of the desired microservice instance. This could include, for example, an application container 640 with an API wrapper 644 and a software library 648. In another example, this includes an application container 650, with an API wrapper 654, a driver or middleware 658, and a hardware accelerator 660.”) Examiner is using instances of microservices to read on the sidecars that correspond to microservices generally described by the claim. Moving forward the Examiner will treat sidecars as instances of microservices.
decorating respective entry points of the respective microservices and the respective sidecars; (see e.g., page [02], paragraph [0026], “The present specification provides a system and method to alleviate this issue by providing so-called “microservices.” Microservices refers to a framework for partitioning functionality in a highly configurable and scalable way that can seamlessly encapsulate a desired function in a wrapper, without the system designer needing to be aware at design time how or on what resources the function will be carried out.”) Examiner is reading the API wrapper function as an entry point into the functionality of the microservice it is attached to.
receiving execution order data indicative of an execution order of the respective microservices and the respective sidecars in initiating the containerized application; (see e.g., page [01], paragraph [0009], “FIG. 6 is a block diagram of initial setup of a microservices instance, according to one or more examples of the present specification.”)
(see also e.g., page [11], paragraph [0168], “This is seen in FIG. 9, wherein service discovery function 900 receives as an input a description of the desired service. This may be a single function or a sequence of functions to be applied to the same message in a service chain. In another example, this may be an enumerated list of desired capabilities.”)
and based on determining to run the containerized application, initializing the respective microservices and the respective sidecars in an order identified by the execution order data, wherein the initializing is performed utilizing the respective entry points of the respective microservices and the respective sidecars. (see e.g., page [09], paragraph [0113], “In operation 3, MANO 628 launches or otherwise provisions an instance of the desired microservice instance. This could include, for example, an application container 640 with an API wrapper 644 and a software library 648. In another example, this includes an application container 650, with an API wrapper 654, a driver or middleware 658, and a hardware accelerator 660.”) (see also e.g., page [09], paragraph [0117] “In general, a chain of microservice invocations may be built up by continuing to repeat this operation such that each instance of a microservice is dynamically chosen and customized for direct communication from its predecessor microservice instance in the chain. Thus, the setting up of message forwarder 624 in the case of a microservices chain provides linkage in some cases not between application 604 and the microservice, but rather between a preceding microservice and the next microservice in the service chain.”)
Regarding claim 9, Sukhomlinov recites:
A method, comprising: decorating, by a system comprising at least one processor and at least one deployable microservice, (see e.g., page [01], abstract, “configured to: receive a microservice instance registration for a microservice accelerator, wherein the registration includes a microservice that the microservice accelerator is configured to provide” Microservices facilitate the performance of their adjacent services by allowing for developers to focus on the functionality of the service they are designing, rather than each dependency and unique feature of their machine instance.)
[decorating] respective entry points of respective microservices of the at least one deployable microservice and respective sidecars, (see e.g., page [02], paragraph [0026], “The present specification provides a system and method to alleviate this issue by providing so-called “microservices.” Microservices refers to a framework for partitioning functionality in a highly configurable and scalable way that can seamlessly encapsulate a desired function in a wrapper, without the system designer needing to be aware at design time how or on what resources the function will be carried out.”)
wherein an application comprises the respective microservices and the respective sidecars, and wherein the respective microservices correspond to the respective sidecars of a group of sidecars; (see e.g., page [09], paragraph [0113], “In operation 3, MANO 628 launches or otherwise provisions an instance of the desired microservice instance. This could include, for example, an application container 640 with an API wrapper 644 and a software library 648. In another example, this includes an application container 650, with an API wrapper 654, a driver or middleware 658, and a hardware accelerator 660.”)
receiving, by the system, execution order data indicative of an execution order of the respective microservices and the respective sidecars in initiating the application; (see e.g., page [01], paragraph [0009], “FIG. 6 is a block diagram of initial setup of a microservices instance, according to one or more examples of the present specification.”)
(see also e.g., page [11], paragraph [0168], “This is seen in FIG. 9, wherein service discovery function 900 receives as an input a description of the desired service. This may be a single function or a sequence of functions to be applied to the same message in a service chain. In another example, this may be an enumerated list of desired capabilities.”)
and based on determining to run the application, initializing, by the system, the respective microservices and the respective sidecars in an order identified by the execution order data, wherein the initializing is performed utilizing the respective entry points of the respective microservices and the respective sidecars. (see e.g., page [09], paragraph [0113], “In operation 3, MANO 628 launches or otherwise provisions an instance of the desired microservice instance. This could include, for example, an application container 640 with an API wrapper 644 and a software library 648. In another example, this includes an application container 650, with an API wrapper 654, a driver or middleware 658, and a hardware accelerator 660.”) (see also e.g., page [09], paragraph [0117] “In general, a chain of microservice invocations may be built up by continuing to repeat this operation such that each instance of a microservice is dynamically chosen and customized for direct communication from its predecessor microservice instance in the chain. Thus, the setting up of message forwarder 624 in the case of a microservices chain provides linkage in some cases not between application 604 and the microservice, but rather between a preceding microservice and the next microservice in the service chain.”)
Regarding claim 14, Sukhomlinov recites:
A non-transitory computer-readable medium comprising instructions that, in response to execution, cause a system comprising at least one processor to perform operations, comprising: decorating respective entry points of respective microservices and respective sidecars; (see e.g., page [01], abstract, “configured to: receive a microservice instance registration for a microservice accelerator, wherein the registration includes a microservice that the microservice accelerator is configured to provide” Microservices facilitate the performance of their adjacent services by allowing for developers to focus on the functionality of the service they are designing, rather than each dependency and unique feature of their machine instance.) (see e.g., page [02], paragraph [0026], “The present specification provides a system and method to alleviate this issue by providing so-called “microservices.” Microservices refers to a framework for partitioning functionality in a highly configurable and scalable way that can seamlessly encapsulate a desired function in a wrapper, without the system designer needing to be aware at design time how or on what resources the function will be carried out.”)
identifying execution order data indicative of an execution order of the respective microservices and the respective sidecars in initiating an application; (see e.g., page [01], paragraph [0009], “FIG. 6 is a block diagram of initial setup of a microservices instance, according to one or more examples of the present specification.”)
(see also e.g., page [11], paragraph [0168], “This is seen in FIG. 9, wherein service discovery function 900 receives as an input a description of the desired service. This may be a single function or a sequence of functions to be applied to the same message in a service chain. In another example, this may be an enumerated list of desired capabilities.”)
and based on determining to initiate the application, initializing the respective microservices and the respective sidecars in an order identified by the execution order data, wherein the initializing is performed utilizing the respective entry points of the respective microservices and the respective sidecars. (see e.g., page [09], paragraph [0113], “In operation 3, MANO 628 launches or otherwise provisions an instance of the desired microservice instance. This could include, for example, an application container 640 with an API wrapper 644 and a software library 648. In another example, this includes an application container 650, with an API wrapper 654, a driver or middleware 658, and a hardware accelerator 660.”) (see also e.g., page [09], paragraph [0117] “In general, a chain of microservice invocations may be built up by continuing to repeat this operation such that each instance of a microservice is dynamically chosen and customized for direct communication from its predecessor microservice instance in the chain. Thus, the setting up of message forwarder 624 in the case of a microservices chain provides linkage in some cases not between application 604 and the microservice, but rather between a preceding microservice and the next microservice in the service chain.”)
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Sukhomlinov as applied to claim 1 above, and further in view of Reynolds et. al. (GB 2456189), hereinafter Reynolds.
Regarding Claim 2, Sukhomlinov teaches:
The system of claim 1, wherein the execution order data is initialization order data, wherein the order is a first order, and wherein the operations further comprise: (see e.g., paragraph [0168], This is seen in FIG. 9, wherein service discovery function 900 receives as an input a description of the desired service. This may be a single function or a sequence of functions to be applied to the same message in a service chain. In another example, this may be an enumerated list of desired capabilities. In one example, open API may be used for this purpose, although this is a nonlimiting example. The description of services may be provided in different ways or formats, and required functions may be provided in addition to other information such as function-specific parameters or desired performance parameters. The output of service discovery function 900 may include a path ID to use for the service, details of the endpoint, and available options.
Sukhomlinov fails to explicitly teach:
receiving shutdown order data indicative of a shutdown order of the respective microservices in initiating the containerized application; and based on determining to shut down the containerized application, halting execution of the respective microservices and the respective sidecars in a second order identified by the shutdown order data, wherein the shutting down is performed utilizing the respective entry points of the respective microservices and the respective sidecars.
However, Reynolds teaches:
receiving shutdown order data indicative of a shutdown order of the respective microservices in initiating the containerized application; and based on determining to shut down the containerized application, halting execution of the respective microservices and the respective sidecars in a second order identified by the shutdown order data, wherein the shutting down is performed utilizing the respective entry points of the respective microservices and the respective sidecars. (see e.g., Page [001], lines [005-010], “The present invention relates to a computing device and an associated method of shutting down such a device. More specifically, when shutdown of the device is requested, a multiplicity of software components are running on the device and each component is instructed to perform shutdown tasks in a sequence according to how severely the computing device is affected if the component is unable to complete its shutdown tasks.”) It would be obvious to one of ordinary skill in the art before the effective filing date of the claims to combine the method of managing startup tasks, along with other generic computer tasks of Sukhomlinov, with the specific shutdown method of Reynolds because Sukhomlinov shows that any function can be performed in the manner described by the claim, and Reynolds specifies a shutdown task being performed in the manner described by the claim. Both inventors would have encountered the same problem to solve of having a complicated system to turn off. There would be no undue experimentation to fit the shutdown task of Reynolds to fit the model of Sukhomlinov, and the benefits that Reynolds provides to operating systems would also be beneficial to the microservices of Sukhomlinov, as organized shutdowns are a great benefit to devices that shut down by machine request. (see Reynolds, page [16], lines [03 – 09])
Claims 3 and 4 rejected under 35 U.S.C. 103 as being unpatentable over Sukhomlinov as applied to claim 1 above, and further in view of alansj et al. (“HOWTO: unpack, edit, and Repack boot images”, 2008), hereinafter alansj.
Regarding Claim 3, Sukhomlinov teaches:
The system of claim 1, wherein decorating the respective entry points of the respective microservices and the respective sidecars comprises:
performing static decoration on respective image metadata of the respective microservices and the respective sidecars, wherein performing the static decoration comprises, (see e.g., page [15], paragraph [0237], “Example 5 includes the computing apparatus of example 1, wherein the microservice registration database is further configured to include information for mapping a microservices application programming interface (API) call to a native invocation for the microservice accelerator, wherein the microservices API is a universal API for devices accessing the microservice accelerator.”)
Sukhomlinov fails to teach:
extracting respective entry points from the respective image metadata, producing respective decorated entry points from the respective entry points, and rebuilding respective images that correspond to the respective image metadata using the respective decorated entry points, to produce respective rebuilt images,
However, alansj teaches:
extracting respective entry points from the respective image metadata, producing respective decorated entry points from the respective entry points, and rebuilding respective images that correspond to the respective image metadata using the respective decorated entry points, to produce respective rebuilt images, (See page [04], “Unpacking, Editing, and Re-Packing the images
Note: below I give you the details for unpacking and repacking manually, but I have attached two perl scripts that do most of this for you
If you are good with a hex editor, you can open up any of these images and strip off the first 2k of data. Then, look for a bunch of zeroes followed by the hex 1F 8B (which is the magic number of a gzip file). Copy everything from the first line of the file, through the zeroes, and stopping at the 1F 8B. That is the kernel. Everything from the 1F 8B through the end is the ramdisk. You could save each of these files separately. In order to see the contents of the ramdisk, you need to un-gzip it and then un-cpio it. You could use a command like this (ideally after creating a new directory and cd'ing into it):
Code:
gunzip -c ../your-ramdisk-file | cpio -i
That will place all of the files from the ramdisk in your working directory. You can now edit them.
In order to re-create the ramdisk, you need to re-cpio them and re-gzip those files, with a command like the following (remember, cpio will include everything in the current working directory, so you probably want to remove any other cruft you might have in there):
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
The final step is to combine the kernel and your new ramdisk into the full image, using the mkbootimg program (which you should download and compile from the git repository):
Code:
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel your-kernel-file --ramdisk newramdisk.cpio.gz -o mynewimage.img
Now, there's a lot of hassle in pulling apart files in hex editors and remembering all of these commands, so I wrote unpack and repack perl scripts for you (attached). Hooray.”) Sukhomlinov teaches that microservices can have decorators [api exposure points] added to existing method calls. alansj teaches the steps that would be performed on a system image to do that, those steps being to extract, modify, and rebuild, which would be the problem one who wants to edit a microservice’s image to add a decorator would run into. Therefore, it would be obvious to one of ordinary skill in the art to combine the decoration taught by Sukhomlinov with the method to add a change to a system image taught by alansj in order to be able to add a change [a decorator] to the system image without needing to perform undue experimentation.
wherein initializing the respective microservices and the respective sidecars is performed based on the respective rebuilt images. (see e.g., page [05], paragraph [01], “You will probably only ever be flashing boot images directly to the phone, given the fact that /system/recovery.img automatically flashes the recovery device for you (as noted above). If you have created a new recovery image, just stick it in /system/recovery.img and reboot. If you are flashing a boot image, stick it on your phone viat adb:”)
Regarding claim 4, alansj recites:
The system of claim 3, Wherein the operations further comprise: storing the respective rebuilt images in an image registry of the system. (see e.g., page [05], paragraph [01-02], “If you have created a new recovery image, just stick it in /system/recovery.img and reboot. If you are flashing a boot image, stick it on your phone via adb […] Then, open a shell to your phone via ‘adb shell’, get root, and do the following two commands to flash your new boot image:”)
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Sukhomlinov in view of alansj as applied to claim 3 above, and further in view of Shahin et al. (“Continuous Integration, delivery and deployment: a systematic review on approaches, tools, challenges and practices”, 2017), hereinafter Shahin.
Regarding claim 5, Sukhomlinov in view of alansj teaches:
The system of claim 3
Sukhomlinov in view of alansj fails to teach:
Wherein the static decoration is performed by a continuous integration and continuous deployment component of the system
However, Shahin teaches:
Wherein the static decoration is performed by a continuous integration and continuous deployment component of the system. (see e.g., page [3910], paragraph [02-03], “Due to the growing importance of continuous practices, an increasing amount of literature describing approaches, tools, practices, and challenges has been published through diverse venues.”)
Sukhomlinov in view of alansj and Shahin are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of receiving updates in a consistent manner. Therefore, it would be obvious to one of ordinary skill in the art to combine the static decoration method as taught by Sukhomlinov in view of alansj with the continuous checking for updates of Shahin. Continuous checking would enable quicker dev cycle times, frequent updates, and faster deployments (see e.g., page [3910], paragraph [01-02])
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Sukhomlinov in view of alansj as applied to claim 3 above, and further in view of Pankanti et al. (US 2022/0300343 A1), hereinafter Pankanti.
Regarding claim 6, Sukhomlinov in view of alansj teaches:
The system of claim 3,
Sukhomlinov in view of alansj fails to explicitly teach:
wherein the static decoration is performed for a first image of an image registry based on a registry updates listener component identifying that that the first image has been created or modified in the image registry.
However, Pankati teaches:
wherein the static decoration is performed for a first image of an image registry based on a registry updates listener component identifying that that the first image has been created or modified in the image registry. (see e.g., page [04], paragraph [0053], “Thus, use of a KUBERNETES controller enables one or more embodiments of the present invention to customize a KUBERNETES deployment resource definition, in order to provide an image uniform resource locator (URL) to the KUBERNETES controller, where the image URL enables the KUBERNETES controller to retrieve the first updated image from an image registry. That is, once the first updated image is created, the KUBERNETES controller is able to use an image URL to retrieve that image (e.g., a DOCKER file) from the image registry.”)
Sukhomlinov in view of alansj and Pankati are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of storing updates in a database. Therefore, it would be obvious to one of ordinary skill in the art to combine the static decoration method as taught by Sukhomlinov in view of alansj with the use of Kubernetes for image storage and deployment. Doing so would allow for a more responsive update manager, as it would allow for the retrieval of any updated image by replacing the URL.
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Sukhomlinov in view of alansj and further in view of Pankanti as applied to claim 6 above, and further in view of Kubernetes docs (“Labels and Selectors”, 2018, Kubernetes Docs), hereinafter Kubernetes.
Regarding claim 7, Sukhomlinov in view of alansj in view of Pankanti teaches:
The system of claim 6,
Sukhomlinov in view of alansj in view of Pankanti fails to explicitly teach:
wherein the registry updates listener component is configured to filter images of the image registry that are sent to a decoration controller that is configured to perform the producing of the respective decorated entry points.
However, Kubernetes teaches
wherein the registry updates listener component is configured to filter images of the image registry that are sent to a decoration controller that is configured to perform the producing of the respective decorated entry points. (see e.g., page [05], paragraph [03], “LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string):”) Kubernetes filters objects based on tags, parameters, and object-specific items. Filtering input system images is certainly not out of the picture, and obvious over the use to “sort and group in UIs and CLIs” (see e.g., page [01], paragraph [02]).
Sukhomlinov in view of alansj and Pankanti and Kubernetes are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of how to select images from a database. Therefore, it would be obvious to one of ordinary skill in the art to combine the system to edit and launch microservices by Sukhomlinov in view of alansj and Pankanti with Kubernetes’ organizational systems. Doing so would allow objects to be given their own organizational structures while avoiding hard-coding them or storing copies on each client (see e.g., page [02], paragraph [01-02]).
Regarding Claim 8, Kubernetes recites:
The system of claim 3, wherein a decoration controller of the system is configured to perform operations, comprising: receiving a name and tag of first image that is stored in an image registry; and performing the producing of the respective decorated entry points based on the name and the tag.
(see e.g., page [01], paragraph [01], “Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time. Each object can have a set of key/value labels defined. Each Key must be unique for a given object.”) A key would correspond to the name [of the dictionary value] while the value would correspond to the tag. Since we’ve established that filtering the input images would be obvious, using one of the filter methods (see e.g., page [05], paragraph [03] again) with one of the filter parameter styles (see e.g., page [05], the two list items after paragraph [03]) to only include or exclude certain items is also obvious.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Sukhomlinov as applied to claim 14 above, and further in view of Skiena (“The Algorithm Design Manual”, 3rd Edition, 2020).
Regarding Claim 18, Sukhomlinov teaches:
The non-transitory computer-readable medium of claim 14,
Sukhomlinov fails to explicitly teach:
wherein the execution order data comprises graph data that identifies a topological order between respective containers that host the respective microservices and the respective sidecars.
However, Skiena teaches:
wherein the execution order data comprises graph data that identifies a topological order between respective containers that host the respective microservices and the respective sidecars. (see e.g., page [546], paragraph [4], “Topological sort can be used to schedule jobs under precedence constraints. Suppose we have a set of tasks to do, but certain tasks must be performed before other ones. These precedence constraints form a directed acyclic graph, and any topological sort (also known as a linear extension) defines an order to perform these tasks such that each is done only after all of its constraints are satisfied.”)
Sukhomlinov and Skiena are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of finding an order that fulfills precedence constraints. Therefore, it would be obvious to one of ordinary skill in the art to combine the system to edit and launch microservices by Sukhomlinov with Skiena’s method to organize jobs so that they fulfill all precedence constraints. Doing so would allow microservices to not need to worry if all their dependencies were fulfilled, as any task is only performed once its constraining tasks are satisfied (see e.g., page [546], paragraph [4]) which would result in less null errors (attempts to operate on null values, or instructions attempted to be called without them being present).
Allowable Subject Matter
Claims 10-13, 15-17, and 19-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5.
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.
/C.I.B./ Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights