DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-20 are pending.
Claims 1-20 are rejected, grounds follow.
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-4, 8-11, and 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gopalan et al., US Pg-Pub 2021/0318900 in view of Allocca, US 9,672,137.
Regarding Claims 1, 8 and 15, Gopalan teaches:
A powered system ([0025] “virtualization system 100 may refer to a collection or group of software-hardware components that provide “virtual hardware” or “virtual operating systems” on a user's computing device (e.g., laptop) to gain access to a shared computing system, server, and/or infrastructure”) comprising: a control system having processors ([0035] “first virtual machine 106-1 to second virtual machine 106-2 may be located and/or operational on distinct physical computing machines and/or servers that may be both connected and in communication with host 102”) communicatively coupled with each other by a data plane of a communication network, (Hypervisor 104 may be positioned between, with respect to the communication link or path, virtual machines 106 and host 102. As such, hypervisor 104 may control, engage, manage, and/or maintain operation of virtual machines 106 of virtualization system 100”)
the processors configured to run software applications in containers to control operation of the powered system, ([0032] “Each of the plurality of containers 120 may refer to a collection and/or predefined grouping of features included within virtual machine 106 including, but not limited to, APPS 112”)
the processors configured to switch which of the processors are running different ones of the software applications operating in different ones of the containers, ([0035] “With continued reference to FIG. 2, a process for live migration of containers 120 from first virtual machine 106-1 to second virtual machine 106-2 is discussed below.”)
Gopalan differs from the claimed invention in that:
Gopalan does not appear to clearly articulate: the processors configured to change a mode of at least one of the containers to a shadow mode that prevents output from at least a first application of the software applications that is running in the at least one of the containers operating in the shadow mode from changing operation of the powered system.
However, Allocca teaches a software system for a production plant (see fig. 1, production system 106) which runs at least one instance of a software application (col. 1 line 65 “a production (or “live”) version of software”) in a shadow mode (col. 2 line 2 “a shadow proxy service operating at least a candidate version of the software (e.g. trial or test version, etc.”) which prevents output from the shadow application from changing operation of the powered system. (col. 2 line 5 “The production version of software, unlike the candidate version, may update production system data and may transmit data back to the end users while the shadow request does not output to the users and/or affect the production system.”)
Allocca is analogous art because it is from the same field of endeavor as the claimed invention and other references of software services for controlling production computing environments; and contains overlapping structural and functional similarities, such as running multiple software instances and sharing communication between them over a common communication infrastructure.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Gopalan to include designating one or more software containers of Gopalan to be operating in a shadow proxy state where their outputs do not control the operational plant, as suggested by Allocca.
One of ordinary skill in the art before the effective filing date of the application could have been motivated to make this modification in order test system functionality of a candidate software application with real operational requests without modifying the production data itself, as suggested by Allocca (col. 2 line 8 “In contrast to typical A/B testing, the testing of the candidate version occurs without updating production system data and thus is used primarily to test system functionality and performance when executing sample requests (shadow requests) that are based on actual requests (processed with the production version of the software).”)
Regarding Claims 8 and 15, these claims recite substantively the same subject matter, except embodied as a method and a control system, respectively. Mutatis mutandis, these claims are likewise obvious over the teachings of Gopalan in view of Allocca for the same reasons articulated with respect to claim 1.
Regarding Claims 2, 9 and 16, Gopalan in view of Allocca teaches all of the limitations of parent claims 1, 8, and 15, respectively;
Allocca further teaches:
wherein the control system is configured to provide real time data related to operation of the powered system to the software applications running in the containers in both a non-shadow mode and in the shadow mode along the data plane. (Col. 3 line 65 “production system 106 may operate to perform the functions of the authority version 116. In such a case, the authority requests 132 are sent to the production system 106 by the shadow proxy service 112 and may be tagged such that the production system 106 knows the authority request 132 is a shadow request” see also col. 3 line 29 “in addition to forwarding production requests to the production system 106, the interceptor 110 forwards the requests (such as requests 120) to the shadow proxy service 112 as shadow requests 124.”)
Although not relied upon for the rejection, examiner notes for completeness of the record that this feature is also taught by Amaro Jr. US Pg-Pub 2022/0404813, see [0164]-[0166] and fig. 45 of Amaro Jr.
Regarding Claims 3 and 10, Gopalan in view of Allocca teaches all of the limitations of claims 1 and 8, respectively;
Allocca further teaches:
wherein the software applications running in the containers are configured to provide the output based on data received from the data plane, (see fig. 1, Production responses 126 and Candidate responses 134; e.g. col. 3 line 14 “The production system 106 processes the production requests normally using the production version 108 of the software and replies with production responses 126.”)
the software applications running in the containers other than the at least one container in the shadow mode configured to provide the output that changes operation of the powered system, (col. 2 line 4: “The production version of software, unlike the candidate version, may update production system data and may transmit data back to the end users”
the software application or the software applications running in the at least one container in the shadow mode configured to provide the output that does not change the operation of the powered system. (col. 2 line 6 “while the shadow request does not output to the users and/or affect the production system.” nb. and is instead output to logs, see col. 2 line 25 “The shadow proxy service system may then derive metrics and log data about the shadow testing on a request-by-request or aggregate basis.”)
Regarding Claims 4, 11 and 17, Gopalan in view of Allocca teaches all of the limitations of parent claims 1, 8 and 15, respectively.
Allocca further teaches:
wherein the processors are configured to log or record the output from the software application or the software applications running in the at least one container in the shadow mode. (see col. 2 line 25 “The shadow proxy service system may then derive metrics and log data about the shadow testing on a request-by-request or aggregate basis.” See also col 4 lines 45-50).
Claim(s) 5-7, 12-14, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gopalan in view of Allocca, further in view of Amaro Jr. US Pg-Pub 2022/0404813.
Regarding Claims 5, 12, and 18, Gopalan in view of Allocca teaches all of the limitations of parent claims 1, 8, and 15, respectively;
Gopalan in view of Allocca differs from the claimed invention in that:
Neither reference clearly articulates: wherein the processors are configured to change the mode of another container of the containers from a non-shadow mode to the shadow mode.
However, Amaro Jr. teaches a powered system include software containerized controllers (see fig. 45, controller containers) running on processors (fig. 45, physical servers 3430, 3432) where the mode of the containers may be changed between shadow (“redundant”, see [0141] “In that case, each of the redundant I/O server containers may be receiving process data from the field devices in the process plant, and may be receiving outputs from one or more controller containers, but only the outputs from the active I/O server container will be transmitted, via the physical I/O layer, to the field devices in the process plant, and each of the controller containers will be receiving process data only from the active I/O server container.”) and non-shadow modes ([0141] “In some embodiments, the orchestrator 222 selects an “active” container from among the multiple, redundant copies of a container. As used herein, the term “active” refers to a one of a plurality of redundant containers that is selected such that the outputs of the selected container drive the inputs to another container, control a field device, or the like.” ) to handle operational failovers gracefully. ([0141] “ Fault tolerance is created by taking a horizontal scaling approach whereby multiple copies of a container are instantiated for a multiple input, single output mechanism.” See [0149] “by instantiating the controller containers 304A-304C on different computing hardware, a fault on any one of the controller containers 304A-304C does not lead to a loss of control of the equipment controlled by the logical controller 304. In the event that the fault occurs on the active one of the controllers 304A-304C, one of the remaining two controllers would become the active controller.” ).
Amaro Jr. is analogous art because it is from the same field of endeavor as the claimed invention and other references of software services for controlling production computing environments; and contains overlapping structural and functional similarities, such as running multiple software instances and sharing communication between them over a common communication infrastructure.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Gopalan to include designating one or more of the operational software containers as a shadow mode (i.e. online redundant application) for an active software container application as suggested by Amaro Jr.
One of ordinary skill in the art before the effective filing date of the application could have been motivated to make this modification in order to provide fault tolerance by means of horizontal scaling, as suggested by Amaro Jr. ([0149] “by instantiating the controller containers 304A-304C on different computing hardware, a fault on any one of the controller containers 304A-304C does not lead to a loss of control of the equipment controlled by the logical controller 304. In the event that the fault occurs on the active one of the controllers 304A-304C, one of the remaining two controllers would become the active controller.” ).
Regarding Claims 6, 13 and 19 Gopalan in view of Allocca teaches all of the limitations of parent claims 1, 8, and 15 respectively;
Gopalan in view of Allocca differs from the claimed invention in that:
Neither reference clearly articulates: wherein the processors are configured to change the mode of the at least one of the containers from the shadow mode to a non-shadow mode.
However, Amaro Jr. teaches a powered system include software containerized controllers (see fig. 45, controller containers) running on processors (fig. 45, physical servers 3430, 3432) where the mode of the containers may be changed between shadow (“redundant”, see [0141] “In that case, each of the redundant I/O server containers may be receiving process data from the field devices in the process plant, and may be receiving outputs from one or more controller containers, but only the outputs from the active I/O server container will be transmitted, via the physical I/O layer, to the field devices in the process plant, and each of the controller containers will be receiving process data only from the active I/O server container.”) and non-shadow modes ([0141] “In some embodiments, the orchestrator 222 selects an “active” container from among the multiple, redundant copies of a container. As used herein, the term “active” refers to a one of a plurality of redundant containers that is selected such that the outputs of the selected container drive the inputs to another container, control a field device, or the like.” ) to handle operational failovers gracefully. ([0141] “ Fault tolerance is created by taking a horizontal scaling approach whereby multiple copies of a container are instantiated for a multiple input, single output mechanism.” See [0149] “by instantiating the controller containers 304A-304C on different computing hardware, a fault on any one of the controller containers 304A-304C does not lead to a loss of control of the equipment controlled by the logical controller 304. In the event that the fault occurs on the active one of the controllers 304A-304C, one of the remaining two controllers would become the active controller.” ).
Amaro Jr. is analogous art because it is from the same field of endeavor as the claimed invention and other references of software services for controlling production computing environments; and contains overlapping structural and functional similarities, such as running multiple software instances and sharing communication between them over a common communication infrastructure.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Gopalan to include designating one or more of the operational software containers as a shadow mode (i.e. online redundant application) for an active software container application as suggested by Amaro Jr.
One of ordinary skill in the art before the effective filing date of the application could have been motivated to make this modification in order to provide fault tolerance by means of horizontal scaling, as suggested by Amaro Jr. ([0149] “by instantiating the controller containers 304A-304C on different computing hardware, a fault on any one of the controller containers 304A-304C does not lead to a loss of control of the equipment controlled by the logical controller 304. In the event that the fault occurs on the active one of the controllers 304A-304C, one of the remaining two controllers would become the active controller.” ).
Regarding Claims 7, 14, and 20, Gopalan in view of Allocca, further in view of Amaro Jr., teaches all of the limitations of parent claims 6, 13, and 19, respectively;
Amaro Jr. further teaches:
wherein the output from the software application or the software applications running in the at least one of the containers that was switched from the shadow mode to the non-shadow mode changes the operation of the powered system. ([0149] “Because all three of the controller containers 304A-304C implement the same control algorithms and receive all of the data received by the active controller, the outputs being provided by each of the controller containers 304A-304C is identical and a new active controller may be selected from the controllers 304A-304C when the active controller experiences a fault.” Nb. the active controller modifies the system, see [0141] “As used herein, the term “active” refers to a one of a plurality of redundant containers that is selected such that the outputs of the selected container drive the inputs to another container, control a field device, or the like.”)
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, 8 and 15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 14 of copending Application No. 18/450,826 (reference application) in view of Allocca. Although the claims at issue are not identical, they are not patentably distinct from each other because as illustrated in the table below, the reference application in view of Allocca teaches or fairly suggests the claims at issue in the instant application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
18/450,826
1. A powered system comprising:
a control system having processors communicatively coupled with each other by a data plane of a communication network, the processors configured to run software applications in containers to control operation of the powered system, the processors configured to switch which of the processors are running different ones of the software applications operating in different ones of the containers,
1. A powered system comprising:
a control system having processors communicatively coupled with each other by a data plane of a communication network, the processors configured to run software applications in containers to control operation of the powered system, the processors configured to switch which of the processors are running different ones of the software applications operating in different ones of the containers
the processors configured to change a mode of at least one of the containers to a shadow mode that prevents output from at least a first application of the software applications that is running in the at least one of the containers operating in the shadow mode from changing operation of the powered system.
(in view of Allocca, fig. 1, which teaches at least one software process that is set to be in a shadow mode and does not change operation of the powered system.)
8. A method comprising:
communicatively coupling processors of a control system with each other by a data plane of a communication network;
running software applications in containers using the processors to control operation of a powered system;
switching which of the processors are running different ones of the software applications operating in different ones of the containers; and
8. A method comprising:
communicatively coupling processors with each other by a data plane of a communication network;
running software applications in containers generated by the processors to control operation of a powered system; and switching which of the processors are running different ones of the software applications operating in different ones of the containers
changing a mode of at least one of the containers to a shadow mode that prevents output from at least a first application of the software applications that is running in the at least one of the containers operating in the shadow mode from changing operation of the powered system.
(in view of Allocca, fig. 1, which teaches at least one software process that is set to be in a shadow mode and does not change operation of the powered system.)
15. A control system comprising:
a control system having processors communicatively coupled with each other by a data plane of a communication network, the processors configured to run software applications in containers to control operation of a powered system,
14. A control system configured to be onboard a vehicle, the control system comprising:
processors communicatively coupled with each other by a data plane of a communication network, the processors configured to run software applications in containers to control operation of the vehicle
the processors configured to switch the containers between operating in a normal mode and a shadow mode,
the software applications running in the containers in the normal mode generating output that controls operation of the powered system, the software applications running in the containers in the shadow mode generating output that does not control operation of the powered system.
(in view of Allocca, fig. 1, which teaches at least one software process that is set to be in a shadow mode and does not change operation of the powered system.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Weber et al., US Pg-Pub 2003/0158615 discussing the fault tolerance by use of “hot backup” controllers running identical software on independent hardware in a control system by used of shared memories and communications (see [0306])
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA T SANDERS whose telephone number is (571)272-5591. The examiner can normally be reached Generally Monday through Friday.
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, Mohammad Ali can be reached at 571-272-4105. 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.
/J.T.S./Examiner, Art Unit 2119
/MOHAMMAD ALI/Supervisory Patent Examiner, Art Unit 2119
Prosecution Insights