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 .
Information Disclosure Statement
Applicant’s IDS submission has been considered, but it is noted that Applicant has submitted over 50 pages of unique references, at least totaling between 450 and 500 references, for consideration. It is further noted that many of the references have questionable relevance to the instant application. For example, the first reference in the submission filed 1/13/2025 (US 6,115,830) is titled “Failure Recovery for Process Relationships in a Single System Image Environment,” and was filed March 28, 1998. This reference involves computer networking with multiple nodes being represented as a single node (See Column 1, lines 33-50), and provides an improvement in the area of failure recovery techniques. It is unclear how the disclosure has any significant relevance to the instant application. With the sheer number of references, only a cursory review of each document could be performed. If Applicant has knowledge of any of the submitted references that are of particular relevance, it is requested that Applicant provide information on these particularly relevant references (Note that this is not a requirement, such as under 37 CFR 1.105).
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 1-27 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1- of U.S. Patent No. 12,155,731. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are an obvious variation of the claims of ‘731.
With regard to claim 1, claim 1 of ‘731, recites “domains” in place of “operating environment,” where an operating environment, as in the instant claims, is a broader and more generic term for domain, as used in ‘731. Further, the instant claims recites the generating of the operating environments, while claims 2-4 provides different ways that the operating environments are deployed (which is considered to be within the scope of the generating.
With regard to claims 3, 6-7, the instant claims are substantially within the scope of claims 4 and 1, and are thus deemed to be obvious variations.
With regard to claim 2, claim 1 of ‘731 fails to teach, but Smith (US 2015/0067030) teaches wherein the first computing platform comprises a first cloud platform and the second computing platform comprises a second cloud platform, such that the first computing platform and the second computing platform comprise a multi-cloud system (smith: Paragraph [0003]. Various cloud infrastructures were known, including hybrid clouds (that include multiple clouds).). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to utilize clouds and multi-cloud systems to leverage the well-known benefits of such, including improved scalability, reliability, etc.
With regard to claim 4, claim 1 of ‘731 fails to teach, but Full Stack Python (“Full Stack Python,” as posted at <www.fullstackpython.com/platform-as-a-service.html> on 8/24/2019) teaches wherein said generating the first operating environment for installation on the first computing platform comprises abstracting one or more platform-specific details about the first computing platform (Full Stack Python: Pages 1-2. PaaS allows for the abstraction of multiple layers, including server hardware.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to abstract platform-specific details about the computing environment to allow the proper providing of instructions from the applications/services to the hardware in accordance with PaaS.
With regard to claim 5, claim 1 of ‘731 fails to teach, but Full Stack Python (“Full Stack Python,” as posted at <www.fullstackpython.com/platform-as-a-service.html> on 8/24/2019) teaches wherein said generating the second operating environment for installation on the second computing platform comprises abstracting one or more platform-specific details about the second computing platform (Full Stack Python: Pages 1-2. PaaS allows for the abstraction of multiple layers, including server hardware.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to abstract platform-specific details about the computing environment to allow the proper providing of instructions from the applications/services to the hardware in accordance with PaaS.
With regard to claim 8, claim 1 of ‘731 fails to teach, but Devouge (Devouge et al. in “Openshift 3: private PaaS with Docker,” published 7/24/2015) teaches wherein the instructions further cause the computing node to manage a lifecycle of at least one of the one or more platform agnostic applications, a lifecycle of at least one of the one or more platform agnostic services, or a combination thereof (Devouge: Page 6. Lacking detail of how the lifecycle is managed, the manual control of Devouge performed through its REST API, CLI, or web portal would serve to manage a lifecycle of the components of the system, including the applications and services implemented in the containers. Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to provide some lifecycle control, even if it is manual, via the system to allow for proper management of the application and services, including the provisioning, removal, and updating of such.
With regard to claim 9, claim 1 of ‘731 fails to teach, but knowledge possessed by one of ordinary skill in the art at the time of filing teaches wherein the instructions further cause the computing node to provide one or more upgrades, one or more patches, or a combination thereof to at least one of the one or more platform agnostic applications, at least one of the one or more platform agnostic services, or a combination thereof (More specifically, Official Notice is taken that the pushing of updates to deployed code was well-known to one of ordinary skill in the art at the time of filing.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to deploy some form of upgrades to update the deployments, whether by deploying additional containers to add additional functions or deploying a new container to overwrite the previous container, at least by using the same process as the initial deployment, to allow additions of functionalities and corrections of coding errors to be made to the deployed software.
With regard to claims 10-27, the instant claims are similar to claims 1-9, and are rejected for similar reasons.
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(s) 1-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devouge et al. in “Openshift 3: private PaaS with Docker,” published 7/24/2015 (Devouge) in view of US 2015/0067030 (Smith), 2014/0201218 (Catalano), and “Full Stack Python,” as posted at <www.fullstackpython.com/platform-as-a-service.html> on 8/24/2019 (Full Stack Python).
With regard to claim 1, Devouge discloses at least one non-transitory computer-readable storage medium including instructions that, when executed by a computing node, cause the computing node to:
provide a first operating environment for installation on a first computing platform having a first architecture (Devouge: Pages 4-6. A pod is provided on multiple nodes, where the pod is a runtime environment for containers. The term “provide” is used here, as there is no detail of how the pod is actually placed in the device.);
provide a second operating environment for installation on a second computing platform (Devouge: Pages 4-6);
deploy the first operating environment on the first computing platform and the second operating environment on the second computing platform such that the first operating environment and the second operating environment provide a common platform to host one or more platform agnostic applications, one or more platform agnostic services, or a combination thereof (Devouge: Page 1. The use of containers as a PaaS would provide a platform agnostic way to host different functions, which would at least include the applications of Devouge.); and
deploy an application of the one or more platform agnostic applications on the first operating environment and the second operating environment (Devouge: Pages 1 and 4-6. The application are run in the containers which are deployed by the master to the other nodes.).
Devouge fails to disclose expressly, but smith teaches the second computing platform having a second architecture different from the first architecture (Smith: Paragraph [0017]); that provide is generate (smith: Paragraph [0019]. The application functionality, which serves to bridge the code with the architecture of the device, is deployed by the PaaS provider.).
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to have the platforms have different architectures, as this is a functionality that was known to be realized by PaaS and Devouge, where the platform agnostic functionality of Devouge would allow for the deployment of code onto different types of architectures without needing to specifically create code for each individual architecture as part of the application to be deployed. Further, by deploying the environment prior to the applications to be executed in the environment, the system would able to fully configure the devices to utilize the system.
Devouge fails to teach, but Catalano teaches deploy a service of the one or more platform agnostic services on the first operating environment and the second operating environment (Catalano: Paragraph [0003]. Catalano provides that PaaS environments can be used to deploy both services and applications, where Devouge provides that applications can be provided by the container (Devouge: Page 1), while Devouge also provides that two types of containers can be deployed in certain cases, such as when it is necessary to share local resources (Devouge: Page 4, “POD”), which would be similar to a service as opposed to being an application.
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to deploy both applications and services to allow known types of software to be used in the system of Devouge in view of smith. As a note, the instant claim does not appear to provide any actual distinction between an “application” and a “service” (where it would appear that there would be overlap in the scope of these terms) or any link or relationship between the deployment other than that both are deployed on both operating environments.
Devouge fails to teach, but Full Stack Python teaches that each of the first operating environment and the second operating environment comprising a PaaS software stack and storage (Full Stack Python: Page 2. Smith provides a stack with an application sitting on top of the stack as a typical for a PaaS, where the actual maintaining of the application, such as within the pod of Devouge, would constitute a “storage” lacking any detail of functions of the stack or storage.
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to provide both a PaaS software stack and storage in the system of Devouge to provide an efficient abstraction of the functions performed by the PaaS implementation to bridge the gap between the application and the hardware, in accordance with standard practice, while providing a capability to store information, even if the information is the application/service, itself.
With regard to claim 2, Devouge fails to teach, but Smith teaches wherein the first computing platform comprises a first cloud platform and the second computing platform comprises a second cloud platform, such that the first computing platform and the second computing platform comprise a multi-cloud system (smith: Paragraph [0003]. Various cloud infrastructures were known, including hybrid clouds (that include multiple clouds).). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to utilize clouds and multi-cloud systems to leverage the well-known benefits of such, including improved scalability, reliability, etc.
With regard to claim 3, Devouge in view of smith, Catalano, and Full Stack Python teaches the second computing platform comprises a bare metal platform (Full Stack Python: Page 2. A PaaS stack can include multiple layers, including an operating system, thus enabling a direct interaction with the hardware, where such would thus be an example of a bare metal system (See Specification: Paragraph [0012]).
Devouge fails to teach, but smith teaches wherein the first computing platform comprises a first cloud platform (smith: Paragraph [0003]. Various cloud infrastructures were known.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to utilize clouds and multi-cloud systems to leverage the well-known benefits of such, including improved scalability, reliability, etc.
With regard to claim 4, Devouge in view of smith, Catalano, and Full Stack Python teaches wherein said generating the first operating environment for installation on the first computing platform comprises abstracting one or more platform-specific details about the first computing platform (Full Stack Python: Pages 1-2. PaaS allows for the abstraction of multiple layers, including server hardware.).
With regard to claim 5, Devouge in view of smith, Catalano, and Full Stack Python teaches wherein said generating the second operating environment for installation on the second computing platform comprises abstracting one or more platform-specific details about the second computing platform (Full Stack Python: Pages 1-2. PaaS allows for the abstraction of multiple layers, including server hardware.).
With regard to claim 6, Devouge fails to teach, but knowledge possessed by one of ordinary skill in the art at the time of filing teaches wherein the instructions further cause the computing node to receive a request to deploy a service of the one or more services to the first computing platform having the first architecture and to deploy the service to the second computing platform having the second architecture, wherein the service is computing platform agnostic (More specifically, Official Notice is taken that there would have been generally two ways to deploy software onto a node, pull and push. For pull, a request would be made to receive the software.). Accordingly, it would have been obvious to utilize a request to deploy the service to utilize a well-known mechanism for receiving data, where a pull mechanism has certain benefits over a push mechanism, such as ensuring that the recipient node is prepared for receiving the data.
With regard to claim 7, Devouge fails to teach, but knowledge possessed by one of ordinary skill in the art at the time of filing teaches wherein the instructions further cause the computing node to receive a request to deploy an application of the one or more applications to the first computing platform having the first architecture and to deploy the application to the second computing platform having the second architecture, wherein the application is computing platform agnostic (More specifically, Official Notice is taken that there would have been generally two ways to deploy software onto a node, pull and push. For pull, a request would be made to receive the software.). Accordingly, it would have been obvious to utilize a request to deploy the service to utilize a well-known mechanism for receiving data, where a pull mechanism has certain benefits over a push mechanism, such as ensuring that the recipient node is prepared for receiving the data.
With regard to claim 8, Devouge in view of smith and Catalano teaches wherein the instructions further cause the computing node to manage a lifecycle of at least one of the one or more platform agnostic applications, a lifecycle of at least one of the one or more platform agnostic services, or a combination thereof (Devouge: Page 6. Lacking detail of how the lifecycle is managed, the manual control of Devouge performed through its REST API, CLI, or web portal would serve to manage a lifecycle of the components of the system, including the applications and services implemented in the containers.
With regard to claim 9, Devouge fails to teach, but knowledge possessed by one of ordinary skill in the art at the time of filing teaches wherein the instructions further cause the computing node to provide one or more upgrades, one or more patches, or a combination thereof to at least one of the one or more platform agnostic applications, at least one of the one or more platform agnostic services, or a combination thereof (More specifically, Official Notice is taken that the pushing of updates to deployed code was well-known to one of ordinary skill in the art at the time of filing.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to deploy some form of upgrades to update the deployments, whether by deploying additional containers to add additional functions or deploying a new container to overwrite the previous container, at least by using the same process as the initial deployment, to allow additions of functionalities and corrections of coding errors to be made to the deployed software.
With regard to claims 10-27, the instant claims are similar to claims 1-9, and are rejected for similar reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT B CHRISTENSEN whose telephone number is (571)270-1144. The examiner can normally be reached Monday through Friday, 6AM to 2PM.
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, John Follansbee can be reached at (571) 272-3964. 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.
SCOTT B. CHRISTENSEN
Examiner
Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444