DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that “the Docker reference states, in part, that "A container is not a virtual machine" and that "Docker [] is not a cloud platform." Therefore, the Docker reference explicitly distinguishes the Linux containers of Docker (e.g., described in the Docker reference) from Virtual Machines (e.g., as described by the Agarwal and Palavalli references), from Cloud Platforms (e.g., as described by Mirsa) as different "tools" that operate differently and have different constraints, and explicitly states that Docker is not a virtual machine or a cloud platform. Accordingly, the Docker reference, in the light least favorable to the Office teaches away from the proposed combination of references.”
As an initial matter, applicant has provided no evidence whatsoever as to any “teaching away” of any references. There are no citations of the references and their statements that would allegedly disparage or disclose what “not to do” that was necessarily suggested in the proposed modification of the obviousness rationale of the rejection. Applicant’s arguments cannot replace evidence. The references discussing the well-known distinction between “virtual machines” and “containers” is not an explicit or implicit suggestion as to why the modification proposed by the obviousness rationale would be ill-advised to a person of ordinary skill in the art. Furthermore, “teaching away” is only one factor weighed in the consideration of obviousness and not a pre-emption of obviousness. In fact, a reference explicitly saying “don’t do X” is an acknowledgement that the prior art considered doing X prior to applicant’s invention (this is not the situation here).
Further, in response, it is first noted that FIG. 2A, [0010], and [0027] of the instant specification discuss that “a package may be designed and generated to operate within an executing supervisor component of the DEC system (e.g., a container)” and that “the run-time environments may include one or more of the following: one or more online program execution environments 245a; one or more virtual machines 245b; one or more virtualized containers 245c; one or more 'bare metal' (or 'bare machine') computer hardware systems 245m (e.g., on which one or more programs execute directly on the underlying hardware without an intervening operating system); etc.” It is also noted that [0020] of Palavalli states that “the term “client” is any software entity that can run on a computer system, such as a software application, a software process, a virtual machine (VM) and a “container” that provides system-level process isolation;” and that [0060] of Misra discusses substitution of “Containers/Virtual Machines/hosts on which user applications are executed.” The examiner finds/found that one of ordinary skill in the art considering virtualization techniques would look to both containers and virtual machines according to their respective advantages (e.g., Applicant’s cited portions of the Docker NPL). Thus, the substitution of the known element of a container for the known element of a virtual machine would have been known in the art at the time.
Applicant further argues that “the Docker reference still establishes that the Office's proposed combination of references is the product of impermissible hindsight bias. More specifically, the disclosure of Docker evidences that the Office has analyzed the claim elements piecemeal and selected different references (and portions therein) to map to different portions of the claimed elements without any teaching, suggestion, or motivation in the combined references whether combination of the features described by the various references and in reference to different "tools" is technically possible, or how the different "tools" and different features described by the cited references may be combined without undue experimentation.” In response to Applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). Agarwal concerns service applications (e.g., service apps in FIG. 15A-C) executing on nodes (e.g., nodes 1-n in FIG. 15A-C) that may be virtual machines (e.g., [0078]). As in FIG. 2A of the instant specification and FIG. 2-5 on page 24 of the Docker NPL, it is notorious within the knowledge of the art that virtual machines may run container applications.
Applicant additionally argues that “there is no teaching suggestion or motivation for the proposed combination, and the logical conclusion is that the proposed combination of references and features therein is the product of impermissible hindsight bias using only facts gleaned from the Applicant's claims and/or specification.” In response to Applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Docker is known to be a popular product for container applications, and container applications are known to be run on virtual machines. Thus, design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Finally, Applicant argues that “[b]y contrast "containers ... must be based on the same underlying operating system (i.e., Linux)." Therefore, Docker does not appear to disclose "abstracting functions of an execution environment including one or more functions of an operating system."” In response, it is noted that page 229 of the Docker NPL states that “[o]ne of Docker’s major strengths is its ability to abstract away the underlying hardware and operating system so that your application is not constrained to any particular host or environment.” Likewise, page 285 of the Docker NPL notes that the “Docker bedrock” is “its highly portable container format and its ability to abstract away so much of the underlying Linux system;” and page 351 of the Docker NPL states that “containers create a powerful abstraction layer between all of their software components and the underlying operating system.”
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 31-50 are rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 5-10, 12-18, and 20-21 of U.S. Patent No. 10,380,365 B2 in view of Misra (US 2014/0359552 A1) and Docker (“Docker: Up & Running”). The patent claims disclose the instant claims as per the analysis below. The patent claims do not disclose: wherein the first local software package has a functional dependency as a consumer in relation to the second software package, wherein the first local software package is subscribed to the second software package as a producer package; wherein the third software package subscribes to the first local software package and has a functional dependency as a consumer in relation to the first local software package, wherein the third software package is subscribed to the first local software package as a producer package; each local software package further being immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment.
However, the patent claims in view of [0058] Misra disclose: wherein the first local software package has a functional dependency as a consumer in relation to the second software package, wherein the first local software package is subscribed to the second software package as a producer package; wherein the third software package subscribes to the first local software package and has a functional dependency as a consumer in relation to the first local software package, wherein the third software package is subscribed to the first local software package as a producer package. It would have been obvious to one of ordinary skill in the art to modify the patent claims to further implement consumer, producer, and consumer-and-producer components because all of the claimed elements were known in the prior art (consumer and producer applications / functions) and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art at the time (using distributed components according to their intended functionality).
The patent claims in view of Misra do not disclose: software packages being agnostic as to an operating system associated with a run time execution environment. However, the patent claims in view of Misra and pages 4, 20-21, 125, and 179-180 of Docker disclose: each local software package further being immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment. It would have been obvious to one of ordinary skill in the art to modify the patent claims because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Claims 44-50 are substantially similar to claims 31-43, and are therefore likewise rejected.
Instant Application
US 10,380,365 B2
31. (Currently Amended) A system, comprising: multiple hardware processors of multiple computer systems; and
one or more memories having stored instructions that, when executed by the multiple hardware processors at run time, cause the multiple computer systems to: implement a plurality of supervisor components that inter-operate in a cooperative distributed manner to perform decentralized, distributed performance of a plurality of inter-related software packages, wherein each of the multiple computer systems implements a supervisor component from the plurality of supervisor components that manages execution of a previously generated, local software package within the one supervisor component and that coordinates that managed execution with other supervisor components of the plurality on other of the multiple computer systems, wherein each local software package is one of the plurality of inter-related software packages and is immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment including one or more functions of an operating system, and wherein the implementing of the plurality of supervisor components includes:
determining, by a first supervisor component of the plurality that is implemented on a first computer system and that has a first local software package to execute within the first supervisor component, interdependencies of the first supervisor component with other supervisor components of the plurality, including:
determining, based on one topology type associated with the first local software package and that is user selected from multiple, user- selectable, predefined topology types prior to generation of the first local software package, that the first supervisor component is to operate as a leader component for the plurality of supervisor components;
determining a second supervisor component of the plurality that executes second software package, wherein the first local software package has a functional dependency as a consumer in relation to the second software package, wherein the first local software package is subscribed to the second software package as a producer package;
and determining third supervisor component of the plurality that executes third software package, wherein the third software package subscribes to the first local software package and has a functional dependency as a consumer in relation to the first local software package, wherein the third software package is subscribed to the first local software package as a producer package;
communicating, by the first supervisor component, with the second supervisor component to obtain information about ongoing execution of the second software package, performing execution of the first local software package within the first supervisor component in a manner that is based on the obtained information, and monitoring the execution of the first local software package to generate status information about the execution of the first local software package;
communicating, by the first supervisor component, with the third supervisor component to provide at least some of the generated status information about the execution of the first local software package, to alter execution of the third software package based on the provided at least some status information; responding, by the first supervisor component on behalf of the plurality of supervisor components, and based on the first supervisor component operating as the leader component for the plurality of supervisor components, to a first request that is from a first software program separate from the plurality of supervisor components and is for a first type of functionality provided by the plurality of supervisor components;
delegating, by the first supervisor component, and based on the first supervisor component operating as the leader component for the plurality of supervisor components, a second request to one or more other supervisor components of the plurality, wherein the second request is from a second software program separate from the plurality of supervisor components and is for a second type of functionality provided by the plurality of supervisor components.
1. A system, comprising:
multiple hardware processors of multiple computer systems; and
one or more memories with stored instructions that, when executed by the multiple hardware processors, cause the multiple computer systems to implement functionality of a plurality of supervisor components that each manages execution of a local software package within the supervisor component and coordinates that managed execution with other supervisor components of the plurality, the managing of the execution by one of the supervisor components including:
determining, by the supervisor component, at least one other software package that is within at least one other supervisor component of the plurality and on which the local software package within the supervisor component has a dependency;
initiating, by the supervisor component, communications with the at least one other supervisor component to monitor information about ongoing execution of the at least one other software package;
5. The system of claim 1 wherein each supervisor component of the plurality is further configured to implement one of multiple predefined topology types for the local software package within that supervisor component, and wherein the stored instructions further cause the multiple computer systems to implement the functionality of the plurality of supervisor components by, for each of at least some supervisor components of the plurality, controlling interactions with other supervisor components of the plurality based on the one topology type configured for that supervisor component.
6. The system of claim 5 wherein the multiple predefined topology types include a leader-follower topology in which a group of multiple supervisor components of the plurality manages interactions for the group based at least in part on roles that include at least one supervisor component in the group acting as a leader for the group and that include at least one other supervisor component in the group acting as a follower for the group, and a stand-alone topology in which each supervisor component manages operations of its local software package without coordination with any other supervisor components.
executing, within the supervisor component and based at least in part on the monitored information, the local software package;
monitoring, by the supervisor component, ongoing execution of the local software package, and exposing information about the monitored ongoing execution to the other supervisor components; and
updating, by the supervisor component and while one or more other of the supervisor components continue to manage execution of local software packages within the one or more other supervisor components, the local software package within the supervisor component based on a specified predefined update strategy.
9. The system of claim 7 wherein the controlling by the two or more supervisor components of the interactions with other supervisor components of the plurality further includes, in response to a request received for functionality from the group, selecting the local software package of one of the two or more supervisor components to respond to the request based at least in part on a role of the selected local software package in the leader-follower topology.
32. (Previously Presented) The system of claim 31 wherein the multiple predefined topology types include a leader-follower topology having roles that include at least one supervisor component acting as a leader component and that include at least one other supervisor component acting as a follower component, and a stand-alone topology in which each supervisor component manages operations of its local software package without coordination with any other supervisor components.
6. The system of claim 5 wherein the multiple predefined topology types include a leader-follower topology in which a group of multiple supervisor components of the plurality manages interactions for the group based at least in part on roles that include at least one supervisor component in the group acting as a leader for the group and that include at least one other supervisor component in the group acting as a follower for the group, and a stand-alone topology in which each supervisor component manages operations of its local software package without coordination with any other supervisor components.
33. (Previously Presented) The system of claim 31 wherein the determining that the first supervisor component is to operate as the leader component includes electing, by at least some of the plurality of supervisor components, the first supervisor component as the leader component and further includes designating the one or more other supervisor components as follower components.
7. The system of claim 6 wherein two or more supervisor components of the plurality are configured to be part of a group implementing the leader-follower topology, and wherein the controlling by the two or more supervisor components of the interactions with other supervisor components of the plurality includes electing the local software package of at least one supervisor component of the group as a leader for the group and further includes designating the local software package of at least one other supervisor component of the group as a follower for the group.
34. (Previously Presented) The system of claim 33 wherein the implementing of the plurality of supervisor components further includes, after the first supervisor component becomes unavailable, electing a different supervisor component of the plurality as a new leader component for further operations.
8. The system of claim 7 wherein the group includes three or more supervisor components of the plurality, and wherein the controlling by the three or more supervisor components of the interactions with other supervisor components of the plurality further includes, after a previously elected leader for the group becomes unavailable, electing another local software package of a different supervisor component of the group as a new leader for the group.
35. (Previously Presented) The system of claim 31 wherein the one or more memories have further stored instructions of one or more builder components that, when executed by one or more of the multiple hardware processors, cause the one or more hardware processors to, before the implementing of the plurality of supervisor components, generate at least some of the local software packages of the plurality of supervisor components, the generating of each of the at least some local software packages including: receiving instructions from a user that specify one or more software applications to include in the local software package to be generated and that specify configuration information to use during execution of the one or more software applications; and generating the local software package to include the specified one or more software applications and the specified configuration information and to interact with one or more supervisor component interfaces during the execution of the one or more software applications.
10. The system of claim 1 further comprising one or more builder components that, when executed by one or more of the multiple hardware processors, cause the one or more processors to, before the managing of the execution of the local software package by each of the supervisor components of the plurality, generate multiple software packages that are used as the local software packages of the plurality of supervisor components, the generating of each of the multiple software packages including:
receiving instructions from a customer that specify one or more software applications to include in the software package to be generated and that specify configuration information to use during execution of the one or more software applications; and
generating the software package to include the specified one or more software applications and the specified configuration information and to interact with one or more interfaces of a supervisor component during the execution of the one or more software applications.
36. (Previously Presented) The system of claim 35 wherein the generating of one of the at least some software packages further includes: providing, to the user, information about the multiple, user selectable, predefined topology types; receiving, from the user, information about the predefined topology type that is selected by the user for use with the one software package; and storing information about the user selected predefined topology type as part of the generated one software package.
12. The system of claim 10 wherein the generating of one of the multiple software packages further includes:
providing, to the customer, information about multiple predefined topology types that are available for use; and
receiving, from the customer, information about one of the multiple predefined topology types that is selected by the customer for use with the one software package; and
storing information about the selected predefined topology type as part of the generated one software package,
and wherein managing of execution of the generated one software package by each of one or more of the plurality of supervisor components further includes using the stored information to implement the selected predefined topology type during the execution of the generated one software package.
37. (Previously Presented) The system of claim 36 wherein the generating of the one software package further includes: providing, to the user, information about multiple predefined security policies that are available for use; and receiving, from the user, information about one of the multiple predefined security policies that is selected by the user for use with the one software package; and storing further information about the selected predefined security policy as part of the generated one software package, and wherein the implementing of the plurality of supervisor components further includes using the stored further information to implement the selected predefined security policy during the execution of the generated one software package.
13. The system of claim 10 wherein the generating of one of the multiple software packages further includes:
providing, to the customer, information about multiple predefined security policies that are available for use; and
receiving, from the customer, information about one of the multiple predefined security policies that is selected by the customer for use with the one software package; and
storing information about the selected predefined security policy as part of the generated one software package,
and wherein managing of execution of the generated one software package by each of one or more of the plurality of supervisor components further includes using the stored information to implement the selected predefined security policy during the execution of the generated one software package.
38. (Previously Presented) The system of claim 35 wherein the one or more software applications specified for a first software package include a new software application designed to execute within a supervisor component, and wherein the one or more software applications specified for a second software package include a legacy software application that is not designed to execute within a supervisor component.
14. The system of claim 10 wherein the one or more software applications specified for one of the multiple software packages include a new software application designed to execute within a supervisor component, and wherein the one or more software applications specified for another of the multiple software packages include a legacy software application that is not designed to execute within a supervisor component.
39. (Previously Presented) The system of claim 31 wherein the implementing of the plurality of supervisor components further includes monitoring stored configuration information associated with the first local software package and, in response to a change in the stored configuration information that is identified from the monitoring, modifying further execution of the first local software package to use the changed configuration information.
15. The system of claim 1 wherein the managing of the execution of the one supervisor component further includes monitoring stored configuration information associated with the local software package for the one supervisor component, and, in response to a change in the stored configuration information that is identified from the monitoring, modifying further execution of the local software package to use the changed configuration information.
40. (Previously Presented) The system of claim 31 wherein the implementing of the plurality of supervisor components further includes: receiving information from a security server for use in performing security operations that include at least one of encryption and decryption; and using the received information to perform the security operations as part of at least one of decrypting an encrypted version of the first local software package before the execution of the first local software package, encrypting communications sent from the first supervisor component to one or more other supervisor components, decrypting communications received by the first supervisor component from one Page 6 of 14 or more other supervisor components, or decrypting stored data for use by the executing first local software package of the first supervisor component.
17. The system of claim 1 wherein the managing of the execution of the one supervisor component further includes:
receiving information from a security server for use in performing security operations that include at least one of encryption and decryption; and
using the received information to perform the security operations as part of at least one of decrypting an encrypted version of the local software package for the one supervisor component before the execution of that local software package, encrypting communications sent from the one supervisor component to one or more other supervisor components, decrypting communications received by the one supervisor component from one or more other supervisor components, or decrypting stored data for use by the executing local software package of the one supervisor component.
41. (Previously Presented) The system of claim 31 wherein the implementing of the plurality of supervisor components further includes: using stored information associated with the first local software package to identify a predefined callback function that is associated with one or more specified criteria and is specified by a user; and in response to satisfaction of the one or more specified criteria during the execution of the first local software package, providing information to the user about the execution of the first local software package that is related to the callback function, wherein the callback function corresponds to at least one of health information about a problem during the execution of the first local software package, a start of the execution of the first local software package, a restart of the execution of the first local software package, or a change in configuration used during the execution of the first local software package.
18. The system of claim 1 wherein the managing of the execution of the one supervisor component further includes:
using stored information associated with the local software package for the one supervisor component to identify a predefined callback function that is associated with one or more specified criteria and is specified by a customer; and
in response to satisfaction of the one or more specified criteria during the execution of the local software package, providing information to the customer about the execution of the local software package that is related to the callback function, wherein the callback function corresponds to at least one of health information about a problem during the execution of the local software package, a start of the execution of the local software package, a restart of the execution of the local software package, or a change in configuration used during the execution of the local software package.
42. (Currently Amended) The system of claim 31 wherein the plurality of supervisor components are inter-connected in a mesh structure in which at least one supervisor component of the plurality is connected to at least one other supervisor component of the plurality only indirectly via at least one further intermediate supervisor component of the plurality, and wherein at least one of the communicating with the at least one second supervisor component or the communicating with the at least one third supervisor component is performed using a gossip protocol and the mesh structure.
20. The system of claim 1 wherein the plurality of supervisor components are inter-connected in a mesh structure in which at least one supervisor component of the plurality is connected to at least one other supervisor component of the plurality only indirectly via at least one further intermediate supervisor component of the plurality, and wherein the initiating communications is performed by each of the plurality of supervisor components with at least one other supervisor component using a gossip protocol and the mesh structure.
43. (Currently Amended) The system of claim 31 wherein at least some communications between the plurality of supervisor components use a publish-subscribe model, and wherein at least one of the communicating with the at least one second supervisor component or the communicating with the at least one third supervisor component includes at least one of publishing information or subscribing to published information.
21. The system of claim 1 wherein communications between the plurality of supervisor components includes using a publish-subscribe model, wherein the initiating communications of is performed by each of the plurality of supervisor components with at least one other supervisor component to monitor information about at least one other software package and includes subscribing to information from the at least one other supervisor component, and wherein the exposing of the information is performed by each of the plurality of supervisor components to other supervisor components and includes publishing the information to be exposed.
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 31-34, 39, 41, 44-45, 48, and 50 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal (US 2017/0214738 A1) in view of Palavalli (US 2016/0381133 A1), Misra (US 2014/0359552 A1), and Docker (“Docker: Up & Running”).
Regarding claim 31, Agarwal discloses: A system, comprising:
multiple hardware processors of multiple computer systems; and
one or more memories having stored instructions that, when executed by the multiple hardware processors at run time, cause the multiple computer systems to implement a plurality of supervisor components that inter-operate in a cooperative distributed manner to perform decentralized, distributed performance of inter-related software packages, wherein each of the multiple computer systems implements a supervisor component from the plurality of supervisor components that manages execution of a previously generated, local software package (e.g., [0041]-[0042] of Agarwal concerning packaged applications) within the one supervisor component and that coordinates that managed execution with other supervisor components of the plurality on other of the multiple computer systems (e.g., FIG. 15C of Agarwal concerning a distributed service app integrated with load balancer components; the service app distributed over a plurality of virtual nodes), wherein each local software package the plurality of inter-related software packages (e.g., 15A-C and [0042]-[0044] of Agarwal concerning packaged applications), and wherein the implementing of the plurality of supervisor components includes:
determining, by a first supervisor component of the plurality that is implemented on a first computer system and that has a first local software package to execute within the first supervisor component, interdependencies of the first supervisor component with other supervisor components of the plurality, including:
determining, [based on configuration information], that the first supervisor component is to operate as a leader component for the plurality of supervisor components;
Refer to at least [0072], [0076], [0086]-[0087], and FIG24A-B of Agarwal with respect to the load balancer components selecting a leader component based on e.g., layout, configuration, and performance data.
determining a second supervisor component of the plurality that executes a second software package; and
determining a third supervisor component of the plurality that executes a third software package;
Refer to at least [0078]-[0079], [0088]-[0090], [0092], and [0095] of Agarwal with respect to application-aware load balancing where the application state (e.g., performance monitoring and operational characteristics of the distributed application) are used in allocating nodes and resources for performing the associated service.
communicating, by the first supervisor component, with the second supervisor component to obtain information about ongoing execution of the second software package, performing execution of the first local software package within the first supervisor component in a manner that is based on the obtained information, and monitoring the execution of the first local software package to generate status information about the execution of the first local software package;
communicating, by the first supervisor component, with the third supervisor component to provide at least some of the generated status information about the execution of the first local software package, to alter execution of the third software package based on the provided at least some status information;
Refer to at least [0078]-[0079], [0088]-[0090], [0092], and [0095] as above, and further to at least [0002], [0057], [0066], [0068], and [0086] of Agarwal with respect to operation of a distributed application: i.e., multiple instances of the application performing coordinated execution; updating a distributed shared memory. Resources are allocated in an application-aware manner as above.
responding, by the first supervisor component on behalf of the plurality of supervisor components, and based on the first supervisor component operating as the leader component for the plurality of supervisor components, to a first request that is from a first software program separate from the plurality of supervisor components and is for a first type of functionality provided by the plurality of supervisor components; and
Refer to at least [0068] and [0076] of Agarwal with respect to the leader component being operable to receive and respond to requests on behalf of the service app.
delegating, by the first supervisor component, and based on the first supervisor component operating as the leader component for the plurality of supervisor components, a second request to one or more other supervisor components of the plurality, wherein the second request is from a second software program separate from the plurality of supervisor components and is for a second type of functionality provided by the plurality of supervisor components.
Refer to at least [0076] and [0084] of Agarwal with respect to the leader component being operable to delegate requests to other components of the service app; with respect to subsequent requests.
Agarwal does not specify: based on configuration information further comprising based on one topology type associated with the first software package and that is user selected from multiple, user-selectable, predefined topology types prior to generation of the first software package; predefined topology; second software package, wherein the first local software package has a functional dependency as a consumer in relation to the second software package, wherein the first local software package is subscribed to the second software package as a producer package; third software package, wherein the third software package subscribes to the first local software package and has a functional dependency as a consumer in relation to the first local software package, wherein the third software package is subscribed to the first local software package as a producer package; each local software package further being immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment including one or more functions of an operating system. However, Agarwal in view of Palavalli discloses: based on configuration information further comprising based on one topology type associated with the first software package and that is user selected from multiple, user-selectable, predefined topology types prior to generation of the first software package; predefined topology;
Refer to at least the abstract, FIG. 4, [0033], [0056], and [0069]-[0070] of Palavalli with respect to selecting topologies for application deployment. The topologies can be selected from a catalog. The selection may be manual.
second software package, wherein the first local software package has a functional dependency; third software package [having a dependency].
Refer to at least [0033] and [0069] of Palavalli with respect to defined dependencies between applications and/or components.
The teachings of Agarwal and Palavalli concern cloud computing and managing applications. Accordingly, the teachings are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to include further support for application deployment based on application topologies/blueprints for at least the reasons discussed in [0002]-[0003] and [0072] of Palavalli (i.e., improving application deployment efficiency and reducing operational costs), as well as for ensuring interoperability.
Argarwal-Palavalli does not disclose: wherein the first local software package has a functional dependency as a consumer in relation to the second software package, wherein the first local software package is subscribed to the second software package as a producer package; wherein the third software package subscribes to the first local software package and has a functional dependency as a consumer in relation to the first local software package, wherein the third software package is subscribed to the first local software package as a producer package; each local software package further being immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment including one or more functions of an operating system. However, Agarwal-Palavalli in view of Misra discloses: wherein the first local software package has a functional dependency as a consumer in relation to the second software package, wherein the first local software package is subscribed to the second software package as a producer package; wherein the third software package subscribes to the first local software package and has a functional dependency as a consumer in relation to the first local software package, wherein the third software package is subscribed to the first local software package as a producer package.
Refer to at least [0058] of Misra with respect to application components as producers, consumers. The application components may further act as consumers and producers simultaneously.
The teachings of Misra likewise concern cloud computing and managing applications. Accordingly, the teachings are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to further implement consumer, producer, and consumer-and-producer components because all of the claimed elements were known in the prior art (consumer and producer applications / functions) and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art at the time (using distributed components according to their intended functionality).
Agarwal-Palavalli-Misra does not specify: each local software package further being immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment including one or more functions of an operating system. However, Agarwal-Palavalli-Misra in view of Docker discloses: each local software package further being immutable but dynamically configurable at runtime, without modification to the local software package, to act as an executable artifact while abstracting functions of an execution environment including one or more functions of an operating system.
Refer to at least page 3 of Docker, which discloses that “applications are highly portable between servers because all of the state has to be included directly into the deployment artifact and be immutable.” Further see at least pages 4, 20-21, and 125 of Docker with respect to abstraction—e.g., Docker abstracting away the underlying hardware and OS and applications as executable artifacts.
Refer to at least pages 17, 62, and 179-180 of Docker with respect to environmental variables in Docker, such a process launched in the container “will have access to these environment variables so that it can properly configure itself at runtime.”
The teachings of Docker also concern containers and managing applications, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to further implement Docker containers because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner (i.e., Docker is a popular product for container applications).
Regarding claim 32, Agarwal-Palavalli-Misra-Docker discloses: The system of claim 31 wherein the multiple predefined topology types include a leader-follower topology having roles that include at least one supervisor component acting as a leader component and that include at least one other supervisor component acting as a follower component, and a stand-alone topology in which each supervisor component manages operations of its local software package without coordination with any other supervisor components.
Refer to at least [0087] and [0100]-[0101] of Agarwal with respect to leader election.
Regarding claim 33, Agarwal-Palavalli-Misra-Docker discloses: The system of claim 31 wherein the determining that the first supervisor component is to operate as the leader component includes electing, by at least some of the plurality of supervisor components, the first supervisor component as the leader component
Refer to at least [0087] of Agarwal with respect to electing a leader.
and further includes designating the one or more other supervisor components as follower components.
Refer to at least FIG. 18A-I of Agarwal with respect to leader and non-leader nodes.
Regarding claim 34, Agarwal-Palavalli-Misra-Docker discloses: The system of claim 33 wherein the implementing of the plurality of supervisor components further includes, after the first supervisor component becomes unavailable, electing a different supervisor component of the plurality as a new leader component for further operations.
Refer to at least [0086]-[0087] of Agarwal with respect to electing a new leader responsive to failure.
Regarding claim 39, it is rejected for substantially the same reasons as claim 31 above (i.e., the citations).
Regarding claim 41, Agarwal-Palavalli-Misra-Docker discloses: The system of claim 31 wherein the implementing of the plurality of supervisor components further includes: using stored information associated with the first local software package to identify a predefined callback function that is associated with one or more specified criteria and is specified by a user; and in response to satisfaction of the one or more specified criteria during the execution of the first local software package, providing information to the user about the execution of the first local software package that is related to the callback function, wherein the callback function corresponds to at least one of health information about a problem during the execution of the first local software package, a start of the execution of the first local software package, a restart of the execution of the first local software package, or a change in configuration used during the execution of the first local software package.
Refer to at least [0068], [0076], and [0083]-[0084] of Agarwal with respect to the service app being operable to send a response message to a requesting client. For instance, a banking service app which is operable to send a response message to a user.
Regarding independent claim 44, it is substantially similar to elements of independent claim 31 above, and is therefore likewise rejected (i.e., refer to the citations).
Regarding claim 45, it is substantially similar to elements of claim 31 above, and is therefore likewise rejected (i.e., refer to the citations concerning application-aware load balancing).
Regarding independent claim 48, it is substantially similar to elements of independent claim 31 above, and is therefore likewise rejected (i.e., refer to the citations).
Regarding claim 50, it is substantially similar to elements of claim 31 above, and is therefore likewise rejected (i.e., refer to the citations concerning electing a leader component; the citations concerning load-balancing requests)
Claims 35-36, 46-47, and 49 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal-Palavalli-Misra-Docker as applied to claims 31-34, 39, 41, 44-45, 48, and 50 above, and further in view of Hendry (US 2014/0280799 A1).
Regarding claim 35, Agarwal-Palavalli-Misra-Docker discloses programming the load balancing and weighting (e.g., FIG. 26A-D), but does not specify: wherein the one or more memories have further stored instructions of one or more builder components that, when executed by one or more of the multiple hardware processors, cause the one or more hardware processors to, before the implementing of the plurality of supervisor components, generate at least some of the local software packages of the plurality of supervisor components, the generating of each of the at least some local software packages including: receiving instructions from a user that specify one or more software applications to include in the local software package to be generated and that specify configuration information to use during execution of the one or more software applications; and generating the local software package to include the specified one or more software applications and the specified configuration information and to interact with one or more supervisor component interfaces during the execution of the one or more software applications. However, Agarwal-Palavalli-Misra-Docker in view of Hendry discloses: wherein the one or more memories have further stored instructions of one or more builder components that, when executed by one or more of the multiple hardware processors, cause the one or more hardware processors to, before the implementing of the plurality of supervisor components, generate at least some of the local software packages of the plurality of supervisor components, the generating of each of the at least some local software packages including: receiving instructions from a user that specify one or more software applications to include in the local software package to be generated and that specify configuration information to use during execution of the one or more software applications; and generating the local software package to include the specified one or more software applications and the specified configuration information and to interact with one or more supervisor component interfaces during the execution of the one or more software applications.
Refer to at least [0015], [0020]-[0021], and [0026] of Hendry with respect to its variety of agent types, as well as potential configuration changes requested by an administrator.
The teachings of Agarwal-Palavalli-Misra-Docker concern service apps and computing environments generally (i.e., [0066] of Agarwal). Hendry concern managing virtual computing services; distributed services. Accordingly, the teachings are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to include further support for an interface and functionality to configure and load service apps because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner (i.e., supporting deployment of service apps with application-aware load balancing).
Regarding claim 36, Agarwal-Palavalli-Misra-Docker-Hendry discloses: The system of claim 35 wherein the generating of one of the at least some software packages further includes: providing, to the user, information about the multiple, user selectable, predefined topology types; receiving, from the user, information about the predefined topology type that is selected by the user for use with the one software package; and storing information about the user selected predefined topology type as part of the generated one software package.
Refer to at least [0020]-[0021] and [0026] of Hendry, wherein an administrative user programs various configuration changes which prompt an update;
Refer to at least [0022]-[0023] of Hendry with respect to organizing the update;
This claim would have been rejected for substantially the same reasons as claim 35 above.
Regarding claim 46, it is rejected for substantially the same reasons as claims 35-36 above.
Regarding claim 47, Agarwal-Palavalli-Misra-Docker-Hendry discloses: The computer-implemented method of claim 46 wherein the multiple predefined types of topologies include a leader-follower topology with roles that include at least one supervisor component acting as a leader and at least one other supervisor component acting as a follower, and a stand-alone topology in which each supervisor component manages operations of its local software package without coordination with any other supervisor components, wherein the selected one predefined type of topology is the leader-follower topology, and wherein the executing of the plurality of supervisor components further includes:
Refer to at least [0087] and [0100]-[0101] of Agarwal with respect to nodes selected as leaders.
Refer to at least FIG. 18A-I of Agarwal with respect to leader and non-leader nodes.
electing, by the other supervisor components, the first supervisor component to act as the leader, and designating the other supervisor components to act as followers; and
Refer to at least [0087] of Agarwal with respect to electing a leader.
responding, by the first supervisor component and based on the first supervisor component acting as the leader, to an external request over the one or more computer networks from a software program for a specified type of functionality.
Refer to at least [0068] and [0076] of Agarwal with respect to the leader component being operable to receive and respond to requests on behalf of the service app.
Regarding claim 49, it is rejected for substantially the same reasons as claims 35-36 above.
Claim 37 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal-Palavalli-Misra-Docker-Hendry as applied to claims 35-36, 46-47, and 49 above, and further in view of Dornemann (US 2016/0373291 A1).
Regarding claim 37, Agarwal-Palavalli-Misra-Docker-Hendry does not disclose: wherein the generating of the one software package further includes: providing, to the user, information about multiple predefined security policies that are available for use; and receiving, from the user, information about one of the multiple predefined security policies that is selected by the user for use with the one software package; and storing further information about the selected predefined security policy as part of the generated one software package, and wherein the implementing of the plurality of supervisor components further includes using the stored further information to implement the selected predefined security policy during the execution of the generated one software package. However, Agarwal-Palavalli-Misra-Docker-Hendry in view of Dornemann discloses: wherein the generating of the one software package further includes: providing, to the user, information about multiple predefined security policies that are available for use; and receiving, from the user, information about one of the multiple predefined security policies that is selected by the user for use with the one software package; and storing further information about the selected predefined security policy as part of the generated one software package, and wherein the implementing of the plurality of supervisor components further includes using the stored further information to implement the selected predefined security policy during the execution of the generated one software package.
Refer to at least [0232] of Dornemann with respect to security / audit policies as part of information management policies for administrators to determine as part of configuration information.
The teachings of Dornemann concern virtual machine environments and associated agents for performing work orders. Accordingly, they are considered to be in the same field of endeavor, and are further considered to be combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Agarwal-Palavalli-Misra-Docker-Hendry to include configuring security / audit policies because the substitution of one known element for another (i.e., configuration information; security policies) would have yielded predictable results to one of ordinary skill in the art at the time of the invention (i.e., the disclose of Agarwal includes support for policy-based load balancing).
Claim 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal-Palavalli-Misra-Docker-Hendry as applied to claims 35-36, 46-47, and 49 above, and further in view of Beaty (US 2011/0131589 A1).
Regarding claim 38, Agarwal-Palavalli-Misra-Docker-Hendry does not disclose: wherein the one or more software applications specified for one of the multiple software packages include a new software application designed to execute within a supervisor component, and wherein the one or more software applications specified for another of the multiple software packages include a legacy software application that is not designed to execute within a supervisor component. However, Agarwal-Palavalli-Misra-Docker-Hendry in view of Beaty discloses: wherein the one or more software applications specified for one of the multiple software packages include a new software application designed to execute within a supervisor component, and wherein the one or more software applications specified for another of the multiple software packages include a legacy software application that is not designed to execute within a supervisor component.
Refer to at least the abstract and FIG. 7 of Beaty with respect to transforming legacy desktop environments to a virtualized desktop model.
The teachings of both Beaty concern virtualized environments and agents for configuring said environments. Accordingly, they are considered to be combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Agarwal-Palavalli-Misra-Docker-Hendry to include configuring legacy applications because the substitution of one known element for another (i.e., a type of application as per at least [0066] of Agarwal) would have yielded predictable results to one of ordinary skill in the art at the time of the invention.
Claim 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal-Palavalli-Misra-Docker as applied to claims 31-34, 39, 41, 44-45, 48, and 50 above, and further in view of Tripathy (US 9,892,265 B1).
Regarding claim 40, Agarwal-Palavalli-Misra-Docker does not disclose: wherein the implementing of the plurality of supervisor components further includes: receiving information from a security server for use in performing security operations that include at least one of encryption and decryption; and using the received information to perform the security operations as part of at least one of decrypting an encrypted version of the first local software package before the execution of the first local software package, encrypting communications sent from the first supervisor component to one or more other supervisor components, decrypting communications received by the first supervisor component from one or more other supervisor components, or decrypting stored data for use by the executing first local software package of the first supervisor component. However, Agarwal-Palavalli-Misra-Docker in view of Tripathy discloses: wherein the implementing of the plurality of supervisor components further includes: receiving information from a security server for use in performing security operations that include at least one of encryption and decryption; and using the received information to perform the security operations as part of at least one of decrypting an encrypted version of the first local software package before the execution of the first local software package, encrypting communications sent from the first supervisor component to one or more other supervisor components, decrypting communications received by the first supervisor component from one or more other supervisor components, or decrypting stored data for use by the executing first local software package of the first supervisor component.
Refer to at least the abstract, and FIG. 5-6 of Tripathy with respect to providing encrypted OS images.
The teachings of Tripathy concern storing virtual machine data in cloud environments. Accordingly, they are considered to be combinable with the teachings of Agarwal concerning virtual machine environments.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Agarwal-Palavalli-Misra-Docker to include protecting virtual machine data via encryption for at least the purpose of increasing data security (i.e., Col. 1, Ll. 35-43, Col. 3, Ll. 20-65, and Colo. 4, Ll. 33-40 of Tripathy).
Claim 42 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal-Palavalli-Misra-Docker as applied to claims 31-34, 39, 41, 44-45, 48, and 50 above, and further in view of Jain (US 2011/0276951 A1).
Regarding claim 42, Agarwal does not disclose: wherein the plurality of supervisor components are inter-connected in a mesh structure in which at least one supervisor component of the plurality is connected to at least one other supervisor component of the plurality only indirectly via at least one further intermediate supervisor component of the plurality, and wherein at least one of the communicating with the second supervisor component or the communicating with the third supervisor component is performed using a gossip protocol and the mesh structure. However, Agarwal in view of Jain discloses: wherein the plurality of supervisor components are inter-connected in a mesh structure in which at least one supervisor component of the plurality is connected to at least one other supervisor component of the plurality only indirectly via at least one further intermediate supervisor component of the plurality, and wherein at least one of the communicating with the second supervisor component or the communicating with the third supervisor component is performed using a gossip protocol and the mesh structure.
Refer to at least [0047] of Jain with respect to a mesh structure built on top of a gossip protocol.
The teachings of Jain concern executing and monitoring cloud-based applications, and accordingly, are considered to be combinable with those of Agarwal-Palavalli-Misra-Docker concerning such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Agarwal-Palavalli-Misra-Docker to include a mesh structure built on top of a gossip protocol for at least the purpose of obtaining the advantages of a mesh structure (i.e., reduced load on low-spec nodes).
Claim 43 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal-Palavalli-Misra-Docker as applied to claims 31-34, 39, 41, 44-45, 48, and 50 above, and further in view of Austel (US 2017/0212747 A1).
Regarding claim 43, Agarwal-Palavalli-Misra-Docker does not disclose: wherein at least some communications between the plurality of supervisor components use a publish-subscribe model, and wherein at least one of the communicating with the one second supervisor component or the communicating with the one third supervisor component includes at least one of publishing information or subscribing to published information. However, Agarwal-Palavalli-Misra-Docker in view of Austel discloses: wherein at least some communications between the plurality of supervisor components use a publish-subscribe model, and wherein at least one of the communicating with the one second supervisor component or the communicating with the one third supervisor component includes at least one of publishing information or subscribing to published information.
Refer to at least [0030] and [0037] of Austel with respect to agents publishing information as part of passing information during a work queue.
The teachings of Agarwal-Palavalli-Misra-Docker and Austel concern managing virtual computing services; distributed services. Accordingly, the teachings are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to include further support for a publish-subscribe model for the load balancing components for at least the purpose of reducing the number of network communications and thereby improving operational efficiency.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432