Statement of claims
The present amended application includes:
Claims 1 and 13 were amended.
Claims 1-20 remain pending in the application. Claims 1-20 are being considered on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Patent Eligible Subject Matter Under 35 U.S.C. § 101
Applicant argues that:
“Step 2A (Prong 2) - Applicant submits that the claims integrate any alleged exception into a practical application . Regarding Step 2A, Prong 2, Applicant respectfully submits that the claims as amended herein, as a whole, provide a practical application by providing a technical solution to a technical problem, and thus are eligible. Moreover, the USPTO's advance-notice update in light of Ex Parte Desjardins, further emphasizes proper application of Enfish/McRO at Step 2A, Prong 2 for claims directed to improvements to computer functionality or another technology/technical field. In view of this recent USPTO guidance, Applicant respectfully submits that the Examiner's characterization of the limitations of the claims (especially the independent claims) are inconsistent with the USPTO guidance to consider the claims as a whole.
Examiner respectfully disagree and submit that:
In response to applicant argues based on Enfish/McRO, the pending claims are directed to merely utilizing the computer as a tool for synchronizing corresponding application tasks based determining synchronization points, verifying a successful synchronization of the application task rather than “the organization of a logical structure in software to improve computer capacity” as directed in Enfish/McRO
Thus, taken alone , the claims and the additional elements do not amount to significantly more the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functionality of the computer itself. Accordingly, the claims and the additional elements of “performing, in response to failed synchronization, hot recovery wherein at least a portion of the application task is retransmitted from the active controller to the standby controller” do not amount to significantly more than the abstract idea and cannot provide an inventive concept.
Claims 1 and 13 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claims 1 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, claims 1-20 appear to be patent ineligible under 35 USC 101.
Claim Rejection(s) under 35 U.S.C. 103
Applicant argues that:
“Jacek fails to disclose "in response to failed synchronization, performing hot recovery wherein at least a portion of the application task is retransmitted from the active controller to the standby controller.".
Applicant’s arguments with respect to the newly added limitations have been considered but are moot because the arguments do not apply to the references Holenstein et al. (US 2010/0191884) being used in the current rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under Step 2A, Prong 1,
Claim 1 recites A method of synchronizing corresponding application tasks executing on an active controller and on a standby controller, the active controller and the standby controller each configurable for use in an electrical substation, the method comprising: “determining, by a synchronization manager interface executing on the active controller, a first state of execution of the application task executing on the active controller at the synchronization points”; “determining, by the synchronization manager interface executing on the standby controller, a second state of execution of the application task executing on the standby controller at the synchronization points” , “verifying a successful synchronization of the application task on the active controller and the standby controller based on a comparison of the first state with the second state of execution of the application task executing on the standby controller at the synchronization points” . The limitations of “determining…” and “verifying…” is a process that, under their broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting “synchronizing corresponding application tasks executing on an active controller and on a standby controller, the active controller and the standby controller each configurable for use in an electrical substation”, nothing in the claim element precludes the step from practically being performed in a human mind or with the aid of pen and paper. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgment, and opinion).
Under Prong 2,
The judicial exception is not integrated into a practical application.
The additional elements “synchronizing corresponding application tasks executing on an active controller and on a standby controller, the active controller and the standby controller each configurable for use in an electrical substation,” “synchronizing execution of the application task on the active controller and the standby controller at each of the synchronization points”, “in response to failed synchronization, performing hot recovery wherein at least a portion of the application task is retransmitted from the active controller to the standby controller” which “synchronizing … “ , “… accepting …” , “performing…” amount no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
The additional elements “, “identifying an application task executing on the active controller and the standby controller capable of synchronization”, “defining, for the application task, a plurality of synchronization points at which execution of the application task is to be synchronized”, “, “transmitting the first state from the active controller to the standby controller via a communications channel established therebetween”, ” , are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application) .
The additional elements “application tasks executing”, “an active controller and on a standby controller”, “electrical substation”, “synchronization points” , “the first state with the second state of execution”, “performing hot recovery” , are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)). The claim is directed to an abstract idea.
Step 2B:
The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. The limitations ““synchronizing … “ , “… accepting …” , “performing…” , amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Therefore, claim 1 as a whole does not amount to significantly more than the judicial exception. Consequently, claim 1 is not eligible.
Further claim 2 recites “executing an application programming interface for performing the determining ,transmitting, and verifying amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, do not integrate the judicial exception into a practical application. The additional element of “performing “, merely recite the generic computer or computer components for carrying out or applying the abstract idea , therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
Further claim 3 recites “wherein executing the application programming interface initiates automatically at start-up” amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and “ as result as result to “determining, by the synchronization manager interface executing on the standby controller, a second state of execution of the application task executing on the standby controller at the synchronization points” , is merely applying the judicial exception, do not integrate the judicial exception into a practical application. The additional element of “initiates automatically at start-up “, merely recite the generic computer or computer components for carrying out or applying the abstract idea , therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
Further claim 4 recites “wherein executing the application programming interface initiates periodically at an interval defined by the application task” amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and , is merely applying the judicial exception, do not integrate the judicial exception into a practical application. The additional element of “initiates periodically at an interval defined by the application task “, merely recite the generic computer or computer components for carrying out or applying the abstract idea , therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
Further claim 5 recites “storing the first state in a transmit state table on the active controller and storing the second state in a receive state table on the standby controller” amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, do not integrate the judicial exception into a practical application. The additional element of “state table “, merely recite the generic computer or computer components for carrying out or applying the abstract idea , therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
With regard to claim 6 , it recites additional abstract idea of “wherein verifying the successful synchronization comprises “comparing the transmit state table and the receive state table and determining the transmit state table and the receive state table match each other.” The limitations of “comparing”, “determining…” is a process that, under their broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting “successful synchronization”, “the transmit state table and the receive state table”, nothing in the claim element precludes the step from practically being performed in a human mind or with the aid of pen and paper. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgment, and opinion).
With regard to claim 7, it recites additional element “performing a synchronization of the application task on the active controller and the standby controller when the comparison of the first state and the second state indicate a need for synchronization”, which are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application), which do not integrate a judicial exception into practical application. See MPEP 2106.05(d). Accordingly, these additional elements, do not integrate a judicial exception into practical application, do not amount to significantly more than the abstract idea, thus cannot provide an inventive concept.
With regard to claim 8, it recites additional element “wherein performing the synchronization comprises transmitting one or more synchronization messages between the active controller and the standby controller via the communications channel”, which are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application), which do not integrate a judicial exception into practical application. See MPEP 2106.05(d). Accordingly, these additional elements, do not integrate a judicial exception into practical application, do not amount to significantly more than the abstract idea, thus cannot provide an inventive concept.
With regard to claim 9, it recites additional element “sharing minimal data between the active controller and the standby controller in response to the one or more synchronization messages.”, which are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application), which do not integrate a judicial exception into practical application. See MPEP 2106.05(d). Accordingly, these additional elements “synchronization messages”, do not integrate a judicial exception into practical application, do not amount to significantly more than the abstract idea, thus cannot provide an inventive concept.
With regard to claim 10, it recites additional element “communicating a result of the synchronization, the result comprising at least one of Synch Success, Synch Failure, and Synch Timeout.”, which are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application), which do not integrate a judicial exception into practical application. See MPEP 2106.05(d). Accordingly, these additional elements “Synch Success, Synch Failure, and Synch Timeout”, do not integrate a judicial exception into practical application, do not amount to significantly more than the abstract idea, thus cannot provide an inventive concept.
With regard to claim 11, it recites additional element “wherein the communication channel comprises a low bandwidth communication channel on which the one or more synchronization messages are transmitted to achieve the synchronization and provide high availability capabilities.”, which are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application), which do not integrate a judicial exception into practical application. See MPEP 2106.05(d). Accordingly, these additional elements “low bandwidth communication channel”, “high availability capabilities” , do not integrate a judicial exception into practical application, do not amount to significantly more than the abstract idea, thus cannot provide an inventive concept.
With regard to claim 12, it recites additional element “wherein the active controller and the standby controller integrate a process domain and a power domain of an industrial operation”, which are insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated, insignificant application), which do not integrate a judicial exception into practical application. See MPEP 2106.05(d). Accordingly, the additional elements “process domain and a power domain of an industrial operation”, do not integrate a judicial exception into practical application, do not amount to significantly more than the abstract idea, thus cannot provide an inventive concept.
As to claims 13-20,
Similar analysis as claim 1-12 is applied to claim 13-20 .
Further Claim 13-20 : The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements “A system ” , “a synchronization manager interface” which are merely recitations of generic computing components (see MPEP §2106.05(f)) which does not integrate a judicial exception into practical application. These elements represent no more than mere instructions to apply the judicial exception on a computer. The “ “A system ” , “a synchronization manager interface” are all mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). This does not integrate into a practical application, NOR does it provide significantly more.
For at least these reasons, claims 1-20 are not patent eligible.
Further Claim 13-20 is directed to A system comprising: “a first controller executing an application task” , “a second controller executing the application task” appear to be software per se. Thus, the claimed system is directed to software that is non statutory subject matter.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jacek Stój “Cost-Effective Hot-Standby Redundancy With Synchronization Using EtherCAT and
Real-Time Ethernet Protocols”, Jacek hereinafter, OCTOBER 2021 in view of Banks et al (US 7,003,692, Banks hereinafter) and Holenstein et al. (US 2010/0191884, Holenstein hereinafter).
Claim 1, Jacek teaches a method of synchronizing corresponding application tasks (e.g., see Fig. 6. Automata cycle in RCUs with synchronization using dedicated RMX Modules”, wherein the “user program execution” in active RCU and in standby RCU include the application tasks ) executing on an active controller and on a standby controller the active controller and the standby controller (e.g., ““user program execution” in active RCU “ , “user program execution” in standby RCU , Fig. 6. Automata cycle in RCUs with synchronization using dedicated RMX modules and Fig. 7. User program execution with the same input data in two consecutive automata cycles.) each configurable for use in an electrical substation (e.g., see Abstract, “implementation of an industrial controller with hot-standby redundancy using regular devices and an Ethernet communication interface for the needs of synchronization of the computing units. For this purpose,
EtherCAT and real-time Ethernet protocols were used.”. Thus, “an industrial controller” must include an electrical substation ) , the method comprising:
identifying an application task (e.g., “User Program executing”, FIG. 6 ) executing on the active controller and the standby controller (e.g., “User Program executing”, “active RCU”, User Program executing”, “standby RCU”Fig.6, page 2039.Thus, the User Program executing represent the application task executing on the active controller and the standby controller) capable of synchronization (e.g., “Synchronization “, FIG. 6, see page 2028, “D. Synchronization As already mentioned, synchronization of the redundant RCUs can be done using dedicated synchronization modules and fast fiber-optic communication links.”);
defining, for the application task a plurality of points at which execution of the application task is to be synchronized (e.g., see page 2038, “D. Synchronization”, “The synchronization extends the regular automata cycle by two steps of synchronization—the input transfer point and the output transfer point (see Fig. 6).” ; and
synchronizing execution of the application task on the active controller and the standby controller at each of the points
determining, by a synchronization manager interface executing (e.g., see page , p039, “Fig. 6. Automata cycle in RCUs with synchronization using dedicated RMX
modules” , wherein “redundancy memory exchange (RMX) modules [14]. “ in 2037. Thus, the (RMX) modules include the synchronization manager interface executing ) on the active controller, a first state (e.g., e.g., page 2037 , wherein “The RCU changes its state according to the current communication status, the current state of the other (remote) RCU “ for “operator’s requests”. Thus, one of the “state” of the active RCU include the first state for one of the requests/ application task ) for of execution of the application task executing on the active controller (e.g., see page 2037, “Six states of the RCUs have been distinguished and can be defined as follows. 1) NO_RIO: The communication between an RCU and the RIO station fails. 2) NO_SYNCH: The synchronization link is broken (cannotbe established or the other RCU is missing). 3) READY: A given RCU is ready, whereas the other RCU is not, i.e., it is switched OFF or in the states NO_RIO or NO_SYNCH). 4) READY_2RCU: The RCU is ready, and the other RCU is either ready or active. 5) ACTIVE: The RCU controls the system outputs, but the other RCU is not ready.
6) ACTIVE_2RCU: The RCU is active and the remote RCU is ready.The RCU changes its state according to the current communication status, the current state of the other (remote) RCU,and in response to the system operator’s requests. The RCUstate machine is shown in Fig. 3, whereas in Fig. 4, it is shown
what states the RCU may be in at the same time.The states named active refer to a situation when the given RCU controls the industrial process by writing to the RIOs’ outputs. The states described as ready mean that the RCU is capable of taking control over the process in case of the failureof an active RCU. “) at the points;
transmitting the first state (e.g., one of the “states” in page 2043, see FIG. 12, Fig. 4. Possible coincidences of the different RCU states in both units.) from the active controller to the standby controller via a communications channel (e.g., “ch1”, “ch2”, FIG. 12) established therebetween (e.g., see page 2043, “Fig. 12, local outputs of both RCUs were connected to inputs of the dPLC to let it monitor the state of the RCUs. For every RCU, five binary signals were used for that purpose, each corresponding to one of the possible states except for NO_SYNCH (the dPLC had not got enough inputs to connect six signals from each RCU). The binary signals informing about the RCUs states will
be called state description signals (SDSs). Some SDSs were also connected to the AFS, so the faults could be simulated according to the current state of the system”).;
determining, by the synchronization manager interface executing on the standby controller, a second state (e.g., another one of the “states” in page 2043, see FIG. 12) of execution of the application task executing on the standby controller at the points (e.g., (e.g., see page 2043, “Fig. 12, local outputs of both RCUs were connected to inputs of the dPLC to let it monitor the state of the RCUs. For every RCU, five binary signals were used for that purpose, each corresponding to one of the possible states except for NO_SYNCH (the dPLC had not got enough inputs to connect six signals from each RCU). The binary signals informing about the RCUs states will
be called state description signals (SDSs). Some SDSs were also connected to the AFS, so the faults could be simulated according to the current state of the system”); and
verifying a successful synchronization of the application task on the active controller and the standby controller (e.g., see Fig. 3. Diagram of the hot-standby unit state machine”, page 2037) .
However, Jacek does not explicitly teach defining a plurality of synchronization points; the application task executing on the active controller at the synchronization points, the application task executing on the standby controller at the synchronization points; verifying based on a comparison of the first state with the second state of execution of the application task executing on the standby controller at the synchronization points ; in response to failed synchronization, performing hot recovery wherein at least a portion of the application task is retransmitted from the active controller to the standby controller.
Bank teaches defining a plurality of synchronization points (e.g., col. 4, lines 48-55, “checkpointing messages between the Active and Standby RP.” and “(22) These points are: 1. Copying the start-up config from the Active RP to the Standby RP during initialization. 2. Copying the running-config from the Active RP to the Standby RP so that the Standby is configured the same as the Active. 3. Line-by-line Synchronizing subsequent CLI configuration commands. 4. Synchronizing whenever the Active start-up config file in NVRAM is closed or written” in col. 5, lines 15-30) at which execution of a application task (e.g., “Standby applications to Active”, “the applications themselves must decide when to synchronize” in col. 5, lines1-10 and lines 40-50 ) is to be synchronized (e.g., see FIG. 2A and 2B, in col. 5, lines1-10 and lines 40-50 , “(24) In the currently described embodiment a Redundancy Facility (RF) can assist with the "when to" synchronize while the system is progressing to a steady state condition. During steady state operation, the applications themselves must decide when to synchronize. The Checkpointing Facility (CF) assists with the "how to" synchronize. The RF and CF will now be briefly described with reference to FIG. 3.” , “When a service affecting fault occurs on the Active RP 42 (or a manual switchover is requested) the Standby RP 44 begins the process of assuming control of the Line Cards 48 and transitioning the Standby applications to Active so that the Standby can begin providing service as the new Active. FIGS. 2A and B “, “(21) In the present embodiment, in order to ensure that the configuration is kept synchronized between the Active and Standby RPs, there are multiple points at which synchronization takes place. This synchronization is initiated by the Active RP and the transfer of data takes place over the interconnect described above. There are four main synchronization points in the currently-described embodiment.
(22) These points are: 1. Copying the start-up config from the Active RP to the Standby RP during initialization. 2. Copying the running-config from the Active RP to the Standby RP so that the Standby is configured the same as the Active. 3. Line-by-line Synchronizing subsequent CLI configuration commands. 4. Synchronizing whenever the Active start-up config file in NVRAM is closed or written) ; and determining, by a synchronization manager interface (e.g., col. 5, lines 40-67, “RF” ,“CF”,FIG. 3, col…..”the applications themselves must decide when to synchronize. The Checkpointing Facility (CF) assists with the "how to" synchronize. The RF and CF will now be briefly described with reference to FIG. 3.”) , 27) The Redundancy Facility (RF) is a portable framework that provides synchronization and switchover coordination between redundant processors running IOS.RTM.. The RF infrastructure provides a series of client services as well as functions for control and monitoring of system redundancy. RF provides notification of transition events which occur on both processors to its clients executing on the active controller, a first state of execution of the application task executing on the active controller at the synchronization points (e.g., see col. 5, lines 40-67, “ the applications themselves must decide when to synchronize. The Checkpointing RP (which is the startup-config with any changes made on the Active via CLI) is copied to the RAM 14 of the Standby RP and is parsed there. Early during Standby initialization, a special file system, RCSF, is created for the running-config file synchronization on the Standby.
Col. 7, lines 8-20 “(38) The RCSF is the designated placeholder to receive the running configuration from Active. The RCSF file system resides in the Standby DRAM area. The running configuration is generated dynamically by traversing the entire parse tree and calling the command function to output the data associated with that command. This ensures that the Standby is running the same configuration as the Active at this point. In order to avoid race conditions with RF clients, Bulk Config Sync is completed early; that is, before any other Bulk Sync RF clients begin to run on the Standby. During Bulk Config Sync, any subsequent configuration request on the Active is delayed or rejected until bulk config sync is completed) ; transmitting the first state from the active controller to the standby controller via a communications channel established therebetween (e.g., see FIG. 3, col, ….”(25) As depicted in FIG. 3, each RP has a Checkpointing Facility and a Redundancy Facility Implementation. Messages are passed between the Active and Standby RPs via the interconnect utilizing IPC (interprocess communication) facilities) ; determining, by the synchronization manager interface executing on the standby controller, a second state (e.g., one of the “various states” include the a second state of execution of the application task executing on the standby controller at the synchronization points (e.g., see FIG. 3, col. 5, line 40-50, “(26) In a preferred embodiment a redundancy facility (RF) is utilized to determine when to initiate the configuration file sync. After initialization, the Standby RF progresses through various states until it reaches the Standby-Hot state.“. Thus, one of the “various states” include the a second state “ and col. 7, lines 20-35, “39) Turning next to the third point of synchronization, when the Standby RP is in the Standby-Hot state, subsequent CLI configuration commands are then synchronized to the Standby using line-by-line config sync. This process is depicted in the flow chart of FIG. 4 and is serialized to ensure predictable results by first executing the command on the Active. If the command succeeds on the Active RP then it is sent to the Standby RP to be executed there. If the command fails then it is not sent to the Standby RP.) ; and verifying a successful synchronization of the application task on the active controller and the standby controller based on a comparison of the first state with the second state of execution of the application task executing on the standby controller at the synchronization points (e.g., see FIG. 4, col. 7, lines 21-36, “(39) Turning next to the third point of synchronization, when the Standby RP is in the Standby-Hot state, subsequent CLI configuration commands are then synchronized to the Standby using line-by-line config sync. This process is depicted in the flow chart of FIG. 4 and is serialized to ensure predictable results by first executing the command on the Active. If the command succeeds on the Active RP then it is sent to the Standby RP to be executed there. If the command fails then it is not sent to the Standby RP.
(40) If the command succeeds on the Standby RP, then the Standby RP remains a viable switchover target for the Active RP. If the command fails on the Standby RP, then the Standby is out of sync and, by default, must be reset because it no longer represents a stateful replica of the Active RP. However, the Fault Manager may have been instructed to take other programmatic action when such a failure occurs.”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jacek with those of Banks because both references are directed to related systems addressing similar technical problems within the same field and seek to improve system performance, reliability, and efficiency.
Jacek et al. disclose A method of synchronizing corresponding application tasks executing on an active controller and on a standby controller while Banks et al. teach defining a plurality of synchronization points, synchronizing execution of the application task on the active controller and the standby controller at each of the synchronization points.
Incorporating the teachings of Banks et al. into the system of Jacek et al. would have been a predictable and logical modification, yielding improved operational robustness and efficiency without requiring undue experimentation.
Such a combination would merely involve the substitution or integration of known elements performing their established functions, as taught by Banks et al., into the system of Jacek et al., consistent with design incentives and market demands for improved performance and scalability. Moreover, Banks et al. explicitly recognize benefits to “supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) . —that would naturally be desirable in the system of Jacek et al.
Accordingly, to one of ordinary skill in the art would have had a reasonable expectation of success in combining Jacek et al. with Banks et al., and the combination represents no more than the predictable use of prior art elements according to their known functions.
Holenstein teaches in response to failed synchronization, performing hot recovery wherein at least a portion of the application task is retransmitted from the active controller to the standby controller (e.g., para 475, 476 and 480, “1.8.5.1 Sizzling-Hot Standby”, “hot standby configuration is an HP NonStop checkpointed process pair, except that process state is replicated”, “Should the active node fail, all that is required for failover is to switch the users or their transactions to the standby node”, “failed node can be resynchronized upon recovery”.
Thus, “Should the active node fail” include in response to failed synchronization” , the “resynchronized upon recovery” therefore , in response to failed synchronization, performing hot recovery wherein at least a portion of the application task is retransmitted from the active controller to the standby controller).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Jacek and Banks by adopting the teachings of Holenstein in order to “ maintain synchronization of a backup database with its primary database. .” , “guarantees that the target database, though delayed by the replication latency, is always a consistent copy of the source database” (see Holenstein, para 539) .
Claim 2 Jacek does not teach executing the application programming interface for performing the determining, transmitting, and verifying. However, Bank teaches executing the application programming interface for performing the determining, transmitting, and verifying (see FIG. 4, col. 7, lines 20-40, “(39) Turning next to the third point of synchronization, when the Standby RP is in the Standby-Hot state, subsequent CLI configuration commands are then synchronized to the Standby using line-by-line config sync. This process is depicted in the flow chart of FIG. 4 and is serialized to ensure predictable results by first executing the command on the Active. If the command succeeds on the Active RP then it is sent to the Standby RP to be executed there. If the command fails then it is not sent to the Standby RP. (40) If the command succeeds on the Standby RP, then the Standby RP remains a viable switchover target for the Active RP. If the command fails on the Standby RP, then the Standby is out of sync and, by default, must be reset because it no longer represents a stateful replica of the Active RP. However, the Fault Manager may have been instructed to take other programmatic action when such a failure occurs.”). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to Claim 3 , Jacek does not teach wherein executing the application programming interface initiates automatically at start-up . However, Bank teaches wherein executing the application programming interface initiates automatically at start-up (e.g., col. 3, lines 1-5 “(18) In another embodiment of the invention, both the Active and Standby processors transition through states during startup. The Standby processor remains in a "cold" state until the Active processor becomes active. Then, the Active processor updates the configuration files of the Standby processor to transition it into a "Hot" state where it is ready to become active in the event of a switchover” and “(15) There are two types of configuration files in every router: 1) the startup-config file; and 2) the running-config file. The startup-config file is stored in NVRAM where the IOS.RTM. bootstrap program can fetch the router's configuration parameters when starting up. The image of the running-config, a snapshot version of the current configuration, is stored in RAM and can be dynamically changed by the user while the router is in operation” in col. 4, lines 20-40.). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
Claim 4 , Jacek does not teach wherein executing the application programming interface initiates periodically at an interval defined by the application task. However, Bank teaches wherein executing the application programming interface initiates periodically at an interval defined by the application task (e.g., col. 8, lines 25-35, “a compare utility is run periodically to confirm that the configuration on the Active and Standby RPs are synchronized.”) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to claim 5 Jacek teaches storing the first state in a transmit state table on the active controller and storing the second state in a receive state table on the standby controller (e.g., see page 2043, “TABLE I RCUS CHANGE OF STATES SEQUENCE DURING RIO COMMUNICATION LINK FAILURE”).
Claim 6, Jacek teaches further comparing the transmit state table and the receive state table and determining the transmit state table and the receive state table match each other (e.g., see page 2036, “A. Duplex Control Mode In the duplex control mode, the RIO stations receive the output states from the RCUs and compare them. If the states correspond to each other, i.e., both RCUs energize the outputs in the same way, then the outputs are updated according to the new data that were received.”) . . However, Jacek does not teach verifying the successful synchronization. Bank teaches verifying the successful synchronization (see FIG. 4, col. 7, lines 20-45 (39) Turning next to the third point of synchronization, when the Standby RP is in the Standby-Hot state, subsequent CLI configuration commands are then synchronized to the Standby using line-by-line config sync. This process is depicted in the flow chart of FIG. 4 and is serialized to ensure predictable results by first executing the command on the Active. If the command succeeds on the Active RP then it is sent to the Standby RP to be executed there. If the command fails then it is not sent to the Standby RP. (40) If the command succeeds on the Standby RP, then the Standby RP remains a viable switchover target for the Active RP. If the command fails on the Standby RP, then the Standby is out of sync and, by default, must be reset because it no longer represents a stateful replica of the Active RP. However, the Fault Manager may have been instructed to take other programmatic action when such a failure occurs.”). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to have wherein verifying the successful synchronization comprises comparing the transmit state table and the receive state table and determining the transmit state table and the receive state table match each other in order to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to claim 7 , Jacek does not teach performing a synchronization of the application task on the active controller and the standby controller when the comparison of the first state and the second state indicate a need for synchronization. However, Bank teaches performing a synchronization of the application task on the active controller and the standby controller when the comparison of the first state and the second state indicate a need for synchronization (see FIG. 4, col. 7, lines 20-40, “(39) Turning next to the third point of synchronization, when the Standby RP is in the Standby-Hot state, subsequent CLI configuration commands are then synchronized to the Standby using line-by-line config sync. This process is depicted in the flow chart of FIG. 4 and is serialized to ensure predictable results by first executing the command on the Active. If the command succeeds on the Active RP then it is sent to the Standby RP to be executed there. If the command fails then it is not sent to the Standby RP. (40) If the command succeeds on the Standby RP, then the Standby RP remains a viable switchover target for the Active RP. If the command fails on the Standby RP, then the Standby is out of sync and, by default, must be reset because it no longer represents a stateful replica of the Active RP. However, the Fault Manager may have been instructed to take other programmatic action when such a failure occurs.”). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to Claim 8 , Jacek does not teach wherein performing the synchronization comprises transmitting one or more synchronization messages between the active controller and the standby controller via the communications channel. . However, Bank teaches wherein performing the synchronization comprises transmitting one or more synchronization messages between the active controller and the standby controller (e.g., col. 4, lines 48-60, “19) In FIGS. 2A and B, an HA system 40 consists of redundant Active RP1 42 and Standby RP2 44 interconnected via some media 46 with sufficient bandwidth that it can be used for IPC and checkpointing messages between the Active and Standby RP. ). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to Claim 9 , Jacek does not teach sharing minimal data between the active controller and the standby controller in response to the one or more synchronization messages. However, Bank teaches sharing minimal data between the active controller and the standby controller in response to the one or more synchronization messages (e.g.,. col. 5, lines 45-67, “25) As depicted in FIG. 3, each RP has a Checkpointing Facility and a Redundancy Facility Implementation. Messages are passed between the Active and Standby RPs via the interconnect utilizing IPC (interprocess communication) facilities.”, “(28) RF clients may maintain state synchronization between their Active and Standby instances. If they choose to maintain state, clients will use the Checkpointing Facility (CF) to do so. The format of client messages and the details of the synchronization protocol are client-specific. Initial synchronization is expected to be done as a result of an RF notification. Dynamic state changes, once the systems have reached the stable state (i.e., Active-Fast and Standby-Hot for the Active and Standby RPs respectively), will be synchronized at times decided by the client application.”). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to Claim 10 , Jacek teaches communicating a result of the synchronization, the result comprising at least one of Synch Success, Synch Failure (e.g., see page 2037, “2) NO_SYNCH: The synchronization link is broken (cannot be established or the other RCU is missing).”) , and Synch Timeout.
As to Claim 11, Jacek does not teach wherein the communication channel comprises a low bandwidth communication channel on which the one or more synchronization messages are transmitted to achieve the synchronization and provide high availability capabilities . However, Bank teaches wherein the communication channel comprises a low bandwidth communication channel on which the one or more synchronization messages are transmitted to achieve the synchronization and provide high availability capabilities (e.g., col. 4, lines 45-67, (19) In FIGS. 2A and B, an HA system 40 consists of redundant Active RP1 42 and Standby RP2 44 interconnected via some media 46 with sufficient bandwidth that it can be used for IPC and checkpointing messages between the Active and Standby RP. This may or may not be a dedicated media. This interconnect 46 can be a dedicated Ethernet interface, some fabric interconnect or an internal bus, but it should be sized to support peak bandwidth requirements experienced during initialization or periods of high connection rate when a great deal of state information is being synchronized. Ideally this interconnect 46 should provide at least two paths since it is a critical single point of failure in the system. This communication path is best implemented as an out-of-band data path so that it is available at all times and so that it does not impact the routed traffic being serviced by the router. Thus, wherein the communication channel comprises a low bandwidth communication channel on which the one or more synchronization messages are transmitted to achieve the synchronization and provide high availability capabilities would have been inherent). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jacek by adopting the teachings of Banks to allow “ supporting a "hitless" switchover from an Active to a Standby processor utilizes several points of configuration synchronization.” (see Banks, Abstract) .
As to Claim 12 , Jacek teaches wherein the active controller and the standby controller integrate a process domain and a power domain of an industrial operation (e.g., see abstract, “cost-effective implementation of an industrial controller with hot-standby redundancy using regular devices and an Ethernet communication interface for the needs of synchronization of the computing units.”).
As to claim 13, see rejection of claims 1 , 2 and 8 above . Jacek teaches further a system (see page 2036, “Fig. 1. Distributed system with computing unit redundancy)
As to claim 14-20, see rejection of claims 3-6, 8 and 10-11 above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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, Pierre Vital can be reached at 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights