DETAILED ACTION
Applicant’s amendment and response dated 1/22/2026 has been provided in response to the 10/22/2026 Office Action which rejected claims 1-21, wherein claims 2, 9, 10, 11, and 16-21 have been amended. Thus, claims 1-21 remain pending in this application and have been fully considered by the examiner.
Applicant’s arguments, see page 11 of Applicant’s remarks, filed 1/22/2026, with respect to the rejection(s) of claims 1, 2, 611, 13-18, 20 and 21 under 35 U.S.C 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Bahat et al. (US Patent Application Publication 2008/0301663 A1).
For claim 17, the claimed node requires only RAM and one or more processors. Instructions (“to store instructions”) are not part of the claimed node. Applicant is advised to replace “to store” with --storing--.
Claim Objections
3. Claims 10-16 are objected to because of the following informalities:
Claim 10 at line 23, “said final set of values” lacks proper antecedent basis.
Dependent claims 11-16 do not overcome the deficiency of the base claim and,
therefore, are objected for the same reasons as the base claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
5. Claims 1, 2, 8, 10, 11, 15, 17, 18, and 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bahat et al. (US Patent Application Publication 2008/0301663 A1).
As to claim 1, Bahat teaches a method implemented in a node (e.g. replication client 200) of a distributed system (See Fig.1, 100 and associated text, e.g. [0016]- replication system 100, such as a data backup and recovery replication system, which includes a plurality of user systems, a target storage system and a management system), the method comprising:
operating a first version of a software module (e.g. old version) based on a first set of values for a set of configuration flags (e.g. old configuration, see e.g. [0016]- each computer is configured to execute software components that comprise a collection of executable software modules embodied as, e.g., applications and [0027]- contents, e.g., data structures and features/services, of the old configuration of the replication system and [0028]- The configuration database 126 illustratively contains information relating to the configuration of the current (old) version of the replication system 100 (e.g., the old configuration). As used herein, configuration denotes the representation of software components (executing on the computers of the replication system) as objects stored on the configuration database 128, e.g., a client application object, a server application object, and a replication connection between source/destination volumes of the replication client/replication server (a "pair" object));
receiving a change request to change said software module to a second version (see e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions), said change request specifying a second set of values for said set of configuration flags (e.g. new configuration, see e.g. [0029]- The director module 124 of the upgrade application 125 may also instruct the new version of the management application 122 to manage configuration of new versions of the components, which new versions may include, e.g., additional data structures and/or features/services. As described herein, these data structures may include bitmap and log data structures, as well as a registry adapted to store the configuration information, etc.; the configuration state of the new version of the replication system (maintained in the new configuration of the configuration database) is "empty", i.e., not configured for the replication system, e.g. default values);
in response to said change request:
modifying, by a first time instance, said software module from said first version to said second version (see e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions),
operating said second version of said software module, after said first time instance based on said first set of values for said set of configuration flags (see e.g. [0029]- the director module 124 instructs the new version of the management application 122 to configure the new version of the system to resemble the old, existing version of the system and [0030]- the upgrade application 125 cooperates (interacts) with the old version of the management application 122 to retrieve the configuration of the old version of the replication system 100. To that end, the director module 124 instructs the player module 126 to contact the old version of the management application to retrieve the contents of the old configuration, i.e., the configuration of the existing versions of the client application/write interception component (object), server application (object), management application (object), any replication pairs (objects), etc. The upgrade application then uses that existing configuration to configure a new configuration of the system),
receiving, at a second time instance after said first time instance, an indication to promote said set of configuration flags (e.g. place new configuration into resynchronization mode, see e.g. [0030]- the director module 124 of the upgrade application 125 cooperates with the new version of the management application 122 to provide configuration commands that instruct the server to, e.g., add a client application (object), add a server application (object), add a pair (object), etc., to the new configuration. In response, the new version of the management application connects to the new versions of those components and instructs them to configure themselves according to, e.g., supplied parameters) and [0040]- the new configuration of the replication system completes, and the new version of the write interception component intercepts writes and registers them in the new version of the bitmap volume) and after receipt of said indication, operating said second version of said software module based on said second set of values for said configuration flags (see e.g. [0041]- The new configuration of the replication system is then placed into a resynchronization mode (e.g., manually by the user) that resynchronizes the newly intercepted write data with the old write data, e.g., A, B, C . . . X, Y, Z. That is, the contents of the storage locations registered in the merged bitmap volume are retrieved from the source volume 160.sub.S and reflected (copied) on the destination volume 160.sub.D. Later, the old configuration of the replication system is removed and [0044]- in Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D. In Step 430, the new versions of the software components are transitioned from (out of) the freeze state and back to a normal mode of operation),
wherein between said first time instance and said second time instance, said second version of said software module is operative based on said first set of values for said set of configuration flags (See e.g. Fig.4: 404, 414, 416 and associated text, e.g. [0043]- the player module of the upgrade application queries, e.g., an old version of the management application component to obtain the old configuration of the old versions of the software components as stored on the configuration database and, in Step 416, the director module of the upgrade application instructs the new version of the management application component to configure the new configuration of the system to resemble the old configuration of the system, i.e., configure the new versions of the components substantially identical to the old versions of the components), wherein after said second time instance, said second version of said software module is operative based on said second set of values for said set of configuration flags (See e.g. Fig.4: 426, 428, 430 and associated text, e.g. [0044]- In Step 426, the old versions of the software components are uninstalled, e.g., manually by the user. In Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D. In Step 430, the new versions of the software components are transitioned from (out of) the freeze state and back to a normal mode of operation).
As to claim 2, Bahat teaches wherein said software module is an instance of a plurality of instances of a software component, said plurality of instances being deployed on respective nodes in said distributed system, said respective nodes including said node (See e.g. [0016] a replication system 100, such as a data backup and recovery replication system, which includes a plurality of user systems, a target storage system and a management system that may be advantageously used with the present invention. The user systems are illustratively computers embodied as replication (source) clients 200.sub.S, while the target storage system is illustratively a computer embodied as a replication (destination) server 200.sub.D and the management system is a computer embodied as a management server 120. Each computer is configured to execute software components that comprise a collection of executable software modules embodied as, e.g., applications) wherein said indication is received after completion of said modifying of all instances of said plurality of instances of said software component from said first version to said second version (See e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions; Once a new version of each component, including the write interception component, is upgraded and operational, e.g., intercepting writes, then the old version of the component is uninstalled).
As to claim 8, Bahat teaches wherein said operating said first version and said second version of said software module comprises processing requests based on a set of current values for said set of configuration flags, wherein said set of current values is defined to equal said first set of values prior to said indication and defined to equal said second set of values after receipt of said indication (see e.g. [0037]- Once installed, both the new (and old) versions of the replication system are configured to intercept and process the same writes issued from the user application 112, [0042]- The procedure 400 starts at Step 402 and proceeds to Step 404 where a system administrator or user installs new versions of the software components onto the computers of the replication system such that both old and new versions of the software components are running on the computers simultaneously, [0043]- In Step 414, the player module of the upgrade application queries, e.g., an old version of the management application component to obtain the old configuration of the old versions of the software components as stored on the configuration database and, in Step 416, the director module of the upgrade application instructs the new version of the management application component to configure the new configuration of the system to resemble the old configuration of the system, i.e., configure the new versions of the components substantially identical to the old versions of the components and [0044]- In Step 422, the old configuration of the old versions of the software components of the replication system is removed from the configuration database and, in Step 424, the old version of the write interception component is removed. In Step 426, the old versions of the software components are uninstalled, e.g., manually by the user. In Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D).
As to claim 10, Bahat teaches a non-transitory machine-readable medium storing one or more sequences of instructions (see e.g. [0046]), wherein execution of said one or more instructions by one or more processors contained in a node of a distributed system (e.g. replication client 200, See Fig.1, 100 and associated text, e.g. [0016]- replication system 100, such as a data backup and recovery replication system, which includes a plurality of user systems, a target storage system and a management system), cause said node to perform the actions of:
receiving a change request to change a software module from a first version to a second version (see e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions), said software module being operative based on values for a set of configuration flags (e.g. old configuration, see e.g. [0016]- each computer is configured to execute software components that comprise a collection of executable software modules embodied as, e.g., applications and [0027]- contents, e.g., data structures and features/services, of the old configuration of the replication system and [0028]- The configuration database 126 illustratively contains information relating to the configuration of the current (old) version of the replication system 100 (e.g., the old configuration). As used herein, configuration denotes the representation of software components (executing on the computers of the replication system) as objects stored on the configuration database 128, e.g., a client application object, a server application object, and a replication connection between source/destination volumes of the replication client/replication server (a "pair" object)), said change request specifying a set of initial values and a set of target values for said set of configuration flags (e.g. new configuration, see e.g. [0029]- The director module 124 of the upgrade application 125 may also instruct the new version of the management application 122 to manage configuration of new versions of the components, which new versions may include, e.g., additional data structures and/or features/services. As described herein, these data structures may include bitmap and log data structures, as well as a registry adapted to store the configuration information, etc.; the configuration state of the new version of the replication system (maintained in the new configuration of the configuration database) is "empty", i.e., not configured for the replication system), e.g. default values),
in response to said change request: modifying, by a first time instance, said software module from said first version to said second version (see e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions),
operating said second version of said software module, after said first time instance, based on said set of initial values for said set of configuration flags (see e.g. [0029]- the director module 124 instructs the new version of the management application 122 to configure the new version of the system to resemble the old, existing version of the system and [0030]- the upgrade application 125 cooperates (interacts) with the old version of the management application 122 to retrieve the configuration of the old version of the replication system 100. To that end, the director module 124 instructs the player module 126 to contact the old version of the management application to retrieve the contents of the old configuration, i.e., the configuration of the existing versions of the client application/write interception component (object), server application (object), management application (object), any replication pairs (objects), etc. The upgrade application then uses that existing configuration to configure a new configuration of the system),
receiving, at a second time instance after said first time instance, an indication to promote said set of configuration flags (e.g. place new configuration into resynchronization mode, see e.g. [0030]- the director module 124 of the upgrade application 125 cooperates with the new version of the management application 122 to provide configuration commands that instruct the server to, e.g., add a client application (object), add a server application (object), add a pair (object), etc., to the new configuration. In response, the new version of the management application connects to the new versions of those components and instructs them to configure themselves according to, e.g., supplied parameters) and [0040]- the new configuration of the replication system completes, and the new version of the write interception component intercepts writes and registers them in the new version of the bitmap volume) and after receipt of said indication, operating said second version of said software module based on said set of target values for said configuration flags (see e.g. [0041]- The new configuration of the replication system is then placed into a resynchronization mode (e.g., manually by the user) that resynchronizes the newly intercepted write data with the old write data, e.g., A, B, C . . . X, Y, Z. That is, the contents of the storage locations registered in the merged bitmap volume are retrieved from the source volume 160.sub.S and reflected (copied) on the destination volume 160.sub.D. Later, the old configuration of the replication system is removed and [0044]- in Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D. In Step 430, the new versions of the software components are transitioned from (out of) the freeze state and back to a normal mode of operation),
wherein between said first time instance and said second time instance, said second version of said software module is operative based on said initial set of values (e.g. old configuration) for said set of configuration flags (See e.g. Fig.4: 404, 414, 416 and associated text, e.g. [0043]- the player module of the upgrade application queries, e.g., an old version of the management application component to obtain the old configuration of the old versions of the software components as stored on the configuration database and, in Step 416, the director module of the upgrade application instructs the new version of the management application component to configure the new configuration of the system to resemble the old configuration of the system, i.e., configure the new versions of the components substantially identical to the old versions of the components), wherein after said second time instance, said second version of said software module is operative based on said final set of values (e.g. new configuration) for said set of configuration flags (See e.g. Fig.4: 426, 428, 430 and associated text, e.g. [0044]- In Step 426, the old versions of the software components are uninstalled, e.g., manually by the user. In Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D. In Step 430, the new versions of the software components are transitioned from (out of) the freeze state and back to a normal mode of operation\).
As to claim 11, the limitations of claim 11 are substantially similar to the limitations of method claim 2, and therefore, it is rejected for the reasons stated above.
As to claim 15, the limitations of claim 15 are substantially similar to the limitations of claim 8, and therefore, it is rejected for the reasons stated above.
As to claim 17, Bahat teaches a node (e.g. replication client 200) of a distributed system (See Figs.1 and 2 and associated text, e.g. [0016]- replication system 100, such as a data backup and recovery replication system, which includes a plurality of user systems, a target storage system and a management system),, the node comprising:
a random access memory (RAM) to store instructions (see Fig.2, 224 and associated text, e.g. [0019]); and
one or more processors to retrieve and execute the instructions (see Fig.2 222 and associated text, e.g. [0019]), wherein execution of the instructions causes said node to perform the actions of:
operating a first version of a software module (e.g. old version) based on a first set of values for a set of configuration flags (e.g. old configuration, see e.g. [0016]- each computer is configured to execute software components that comprise a collection of executable software modules embodied as, e.g., applications and [0027]- contents, e.g., data structures and features/services, of the old configuration of the replication system and [0028]- The configuration database 126 illustratively contains information relating to the configuration of the current (old) version of the replication system 100 (e.g., the old configuration). As used herein, configuration denotes the representation of software components (executing on the computers of the replication system) as objects stored on the configuration database 128, e.g., a client application object, a server application object, and a replication connection between source/destination volumes of the replication client/replication server (a "pair" object));
receiving a change request to change said software module to a second version (see e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions), said change request specifying a second set of values for said set of configuration flags (e.g. new configuration, see e.g. [0029]- The director module 124 of the upgrade application 125 may also instruct the new version of the management application 122 to manage configuration of new versions of the components, which new versions may include, e.g., additional data structures and/or features/services. As described herein, these data structures may include bitmap and log data structures, as well as a registry adapted to store the configuration information, etc.; the configuration state of the new version of the replication system (maintained in the new configuration of the configuration database) is "empty", i.e., not configured for the replication system, e.g. default values),
in response to said change request:
modifying, by a first time instance, said software module from said first version to said second version (see e.g. [0027]- In response to a software upgrade request issued by the user, the entire collection of software components executing on the replication system, e.g., the client, server and management applications 115, 114 and 122, as well as the write interception component 116, is illustratively upgraded from old versions to new versions),
operating said second version of said software module, after said first time instance based on said first set of values for said set of configuration flags (see e.g. [0029]- the director module 124 instructs the new version of the management application 122 to configure the new version of the system to resemble the old, existing version of the system and [0030]- the upgrade application 125 cooperates (interacts) with the old version of the management application 122 to retrieve the configuration of the old version of the replication system 100. To that end, the director module 124 instructs the player module 126 to contact the old version of the management application to retrieve the contents of the old configuration, i.e., the configuration of the existing versions of the client application/write interception component (object), server application (object), management application (object), any replication pairs (objects), etc. The upgrade application then uses that existing configuration to configure a new configuration of the system),
receiving, at a second time instance after said first time instance, an indication to promote said set of configuration flags (e.g. place new configuration into resynchronization mode, see e.g. [0030]- the director module 124 of the upgrade application 125 cooperates with the new version of the management application 122 to provide configuration commands that instruct the server to, e.g., add a client application (object), add a server application (object), add a pair (object), etc., to the new configuration. In response, the new version of the management application connects to the new versions of those components and instructs them to configure themselves according to, e.g., supplied parameters) and [0040]- the new configuration of the replication system completes, and the new version of the write interception component intercepts writes and registers them in the new version of the bitmap volume) and after receipt of said indication, operating said second version of said software module based on said second set of values for said configuration flags (see e.g. [0041]- The new configuration of the replication system is then placed into a resynchronization mode (e.g., manually by the user) that resynchronizes the newly intercepted write data with the old write data, e.g., A, B, C . . . X, Y, Z. That is, the contents of the storage locations registered in the merged bitmap volume are retrieved from the source volume 160.sub.S and reflected (copied) on the destination volume 160.sub.D. Later, the old configuration of the replication system is removed and [0044]- in Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D. In Step 430, the new versions of the software components are transitioned from (out of) the freeze state and back to a normal mode of operation),
wherein between said first time instance and said second time instance, said second version of said software module is operative based on said first set of values for said set of configuration flags (See e.g. Fig.4: 404, 414, 416 and associated text, e.g. [0043]- the player module of the upgrade application queries, e.g., an old version of the management application component to obtain the old configuration of the old versions of the software components as stored on the configuration database and, in Step 416, the director module of the upgrade application instructs the new version of the management application component to configure the new configuration of the system to resemble the old configuration of the system, i.e., configure the new versions of the components substantially identical to the old versions of the components), wherein after said second time instance, said second version of said software module is operative based on said second set of values for said set of configuration flags (See e.g. Fig.4: 426, 428, 430 and associated text, e.g. [0044]- In Step 426, the old versions of the software components are uninstalled, e.g., manually by the user. In Step 428, the new configuration of the replication system is placed into a resynchronization mode that resynchronizes the newly intercepted write data with the old write data by, e.g., retrieving the contents of the storage locations registered in the merged bitmap volume from the source volume and copying them to the destination volume 160.sub.D. In Step 430, the new versions of the software components are transitioned from (out of) the freeze state and back to a normal mode of operation\).
As to claim 18, the limitations of claim 18 are substantially similar to the limitations of claim 2, and therefore, it is rejected for the reasons stated above.
As to claim 21, the limitations of claim 21 are substantially similar to the limitations of claim 8, and therefore, it is rejected for the reasons stated above.
Claim Rejections - 35 USC § 103
6. 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.
7. Claims 3, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bahat et al. (US Patent Application Publication 2008/0301663 A1) in view of Horowitz et al. (US Patent Application 2019/0102410 A1, art already of record, see IDS filed on 10/1/2024).
As to claim 3, Bahat teaches the limitations of claim 2, but does not specifically teach wherein said software component is part of a distributed database deployed in said distributed system, said distributed database when operative in said distributed system providing a distributed data service, wherein said distributed data service is continued to be provided by said distributed system while said plurality of instances of said software component are modified from said first version to said second version.
In an analogous art of updated software, however, Horowitz teaches wherein said software component is part of a distributed database deployed in said distributed system (see Fig. 6 and associated text, e.g. [0076]- new database binaries are downloaded to upgrade the database to version 2.6), said distributed database when operative in said distributed system providing a distributed data service (see Fig. 1 and associated text, e.g. [0037]- systems 103 and 105 host elements of a distributed database; any number of underlying systems like 103 and 105 may host copies of the database data accessible through database manager processes or services), wherein said distributed data service is continued to be provided by said distributed system while said plurality of instances of said software component are modified from said first version to said second version (see Fig. 6 and associated text, e.g. [0076]- data balancers move heavily loaded data from one database node or instance to another to better distribute load; automation agents are configured to disable data balances to prevent data loss and/or corruption during upgrade).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Bahat to incorporate/implement the limitations as taught by Horowitz in order to provide a more efficient method/system of automating management functions of distributed database systems that would allow execution plans to upgrade database nodes from a current state to a goal state to be generated and executed as needed.
As to claim 12, the limitations of claim 12 are substantially similar to the limitations of claim 3, and therefore, it is rejected for the reasons stated above.
As to claim 19, the limitations of claim 19 are substantially similar to the limitations of claim 3, and therefore, it is rejected for the reasons stated above.
8. Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Bahat et al. (US Patent Application Publication 2008/0301663 A1) in view of Collins et al. (US Patent Application 2004/0253956, art already of record, see IDS filed on 10/1/2024).
As to claim 4, Bahat teaches the limitations of claim 2, but does not specifically teach wherein said set of configuration flags comprises a first configuration flag, wherein said first configuration flag is set to a first value in said first set of values and a second value in said second set of values, said first value and said second value respectively indicating a first data format and a second data format, said first data format being different from said second data format, wherein said second version of said software module operates with said first data format prior to said indication in view of said first configuration flag being set to said first value and with said second data format after receipt of said indication in view of said first configuration flag being set to said second value.
In an analogous art of updating software, however, Collins teaches wherein said set of configuration flags (e.g. System Request Broker (SRB)) comprises a first configuration flag, wherein said first configuration flag is set to a first value in said first set of values and a second value in said second set of values (Fig. 6 and associated text, e.g. [0103]-[0105] - the SRB defines the Node Table and provides an application programming interface to set and retrieve the Node Table data; the Node Tables contains the Reference Partition address either Am or An, the New Partition Address, either Am or An, where the Reference Partition address and the New Partition address are different), said first value and said second value respectively indicating a first data format and a second data format, said first data format being different from said second data format (see Fig. 6 and associated text, e.g. [0110]-[0111])- the Reference Partition address is an An address and the New Partition address is an Am address; the Node Monitor queries the SRB to find out what address to use for SM2; the SRB returns the Am address; the Node Monitor then loads a local SRB and tells the local SRB to use the Ap address and the Am address; the SRB in SM1 is not visible to any applications running in SM2 even though the applications may define the same named services as in SM1, because the address spaces are different the applications are not accessible between the two partitions), wherein said second version of said software module operates with said first data format prior to said indication in view of said first configuration flag being set to said first value and with said second data format after receipt of said indication in view of said first configuration flag being set to said second value (see Fig. 5 and associated text, e.g. [0081]- the new software in the New Partition 530 is loaded through each Node Monitor located in each New Partition node; the CM application 455 then tests the newly loaded software; if the newly loaded software passes the test, each node in the Reference Partition 520 is shutdown, the new software is installed in the New Partition 530 and the SRB address is changed for the New Partition Nodes).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Bahat to incorporate/implement the limitations as taught by Collins in order to provide a more efficient method/system of upgrading software that would not require the device to be taken off line for the purpose of minimizing downtime.
As to claim 5, Collins further teaches wherein said first data format and said second data format are related to one of data formats used to send data within nodes of said distributed system, data formats used to persist the data in said distributed system and data formats used to communicate with systems external to said distributed system (see Fig. 6 and associated text, e.g. [0110]-[0111]- the ReferencePartition address is an An address and the New Partition address is an Am address; the Node Monitor queries the SRB to find out what address to use for SM2; the SRB returns the Am address; the Node Monitor then loads a local SRB and tells the local SRB to use the Ap address and the Am address; the SRB in SM1 is not visible to any applications running in SM2 even though the applications may define the same named services as in SM1, because the address spaces are different the applications are not accessible between the two partitions).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Bahat to incorporate/implement the limitations as taught by Collins in order to provide a more efficient method/system of upgrading software that would not require the device to be taken off line for the purpose of minimizing downtime.
Allowable Subject Matter
9. Claims 6, 7, 9, 13, 14, 16 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights