DETAILED ACTION
This action is responsive to communications filed 11 March 2026.
Claims 1-20 are subject to examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, 6, 10-12, 16 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3).
Regarding claim 1, Krishnamurthy discloses:
A method ([2:62-3:2] method), comprising:
receiving, by a network device ([2:62-3:2] management device … receiving a network session request from one of the plurality of network devices), a configuration request message sent by a first client ([2:62-3:2] network session request includes the bulk identifier, e.g. from one of the plurality of network devices (i.e. client), see [11:55-65] management device recognizes that network device requires specific configuration data (i.e. configuration request)), wherein the configuration request message comprises operation indication information ([11:55-65] when network device 14a boots using bulk configlet … identifies itself to management device using bulk identifier … management device recognizes that network device requires specific configuration data (i.e. operation indication information, e.g. indicating a configuration operation required)), the operation indication information indicates that the first client requests the network device to perform an operation on a first data object ([7:1-22] bulk configlet for network devices includes a set of configuration data that will enable each of network devices to configure a network stack and to connect to management device (i.e. performing configuration on network stack)), wherein the operation indication information comprises first version information ([10:21-38] network device passes the bulk configlet identifier to management device, see [11:55-12:15] bulk configlet includes bulk identifier … also includes information specific to bulk configlet, such as …. OS version)), and the first data object comprises configuration data of the network device ([7:1-22] bulk configlet for network devices includes a set of configuration data that will enable each of network devices to configure a network stack and to connect to management device (i.e. performing configuration on network stack));
performing, by the network device ([10:21-38] management device), the operation on the first data object in response to the network device detecting that the first version information is consistent with first reference version information stored by the network device ([10:21-38] recognizes the bulk configlet identifier by comparing the identifier (i.e. first version information) to the identifier stored in bulk device object (i.e. first reference version information) … when the received identifier matches (i.e. detecting that the version information is consistent with the reference version information) … forwards a specific configuration data from the one of device objects to the corresponding one of network devices (i.e. performing a configuration operation, e.g. network stack as above)), wherein the first reference version information is version information of the first data object and that is recorded by the network device ([10:21-38] identifier stored in bulk device object, see [11:30-12:15] management device generates bulk configlet in response to data received from administrator … includes bulk identifier).
Krishnamurthy does not explicitly disclose:
network configuration protocol (NETCONF), the first version information is version information of the first data object and that is recorded by the first client,
updating, by the network device in response to successfully performing the operation on the first data object, a first value of the first reference information to be a second value different from the first value and indicating a version of the first data object different than a version of the first data object indicated by the first value; and
sending, by the network device, to the first client, a configuration success message that indicates successful configuration and carries the second value as updated first reference version information.
However, A(2) discloses:
network configuration protocol (NETCONF) ([5:60-6:14] management device uses one or more network management protocols designed for management of configuration data … NETCONF),
updating, by the network device in response to successfully performing the operation on the first data object ([19:24-38] if the commit was successful … configuration module (see [FIG. 2] management device) updates the global version for the device with the latest revision … marks the device as successful), a first value of the first reference information to be a second value different from the first value and indicating a version of the first data object different than a version of the first data object indicated by the first value ([19:24-20:15] configuration module updates the global version for the device with the latest revision (i.e. first value of the revision is different than the second value of the updated revision, e.g. latest revision, indicating different revision values), see also [FIG. 5] e.g. committing configuration and updating the version with the latest revision); and
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of A(2) to have utilized NETCONF and updated, by the network device in response to successfully performing the operation on the first data object, a first value of the first reference information to be a second value different form the first value and indicating a version of the first data object different than a version of the first data object indicated by the first value. One of ordinary skill in the art would have been motivated to do so to allow parallel service commits and permit out of band changes (A(2), [7:51-65]).
Krishnamurthy-A(2) do not explicitly disclose:
the first version information is version information of the first data object and that is recorded by the first client,
sending, by the network device, to the first client, a configuration success message that indicates successful configuration and carries the second value as updated first reference version information.
However, A(3) discloses:
the first version information is version information of the first data object and that is recorded by the first client ([20:59-21:20] version of the configuration for network services stored by resource (i.e. client)),
sending, by the network device ([20:59-21:20] central controller), to the first client ([20:59-21:20] resource), a configuration success message that indicates successful configuration and carries the second value as updated first reference version information ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A(3) to have the first version information be version information of the first data object recorded by the client, and sent, from the network device to the client, a configuration success message indicating successful configuration carrying the second value. One of ordinary skill in the art would have been motivated to do so to output a request for configuration based on a comparison of the version numbers at the resource and the central controller (A(3), [24:43-53]).
Regarding claim 6, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 1, set forth above, wherein the method further comprises:
Krishnamurthy discloses:
completing, by the network device ([7:1-22] management device), performing the operation on the first data object ([7:1-22] bulk configlet for network devices includes a set of configuration data that will enable each of network devices to configure a network stack and to connect to management device (i.e. performing configuration on network stack)); and
Krishnamurthy does not explicitly disclose:
recording, by the network device, the first reference version information.
However, A(2) discloses:
recording, by the network device ([FIG. 2] management device), the first reference version information ([19:24-38] if the commit was successful … configuration module (see [FIG. 2] management device) updates the global version for the device with the latest revision … marks the device as successful).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of A(2) to have the reference version information recorded by the network device. One of ordinary skill in the art would have been motivated to do so to allow parallel service commits and permit out of band changes (A, [7:51-65]).
Regarding claim 10, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 1, wherein the method further comprises:
Krishnamurthy discloses:
receiving, by the network device ([12:40-51] management device), an access control function setting request message sent by the first client ([12:40-51] network device uses username/password to authenticate itself to management device … bulk configlet may … further include a password to prevent unauthorized access to management device), wherein the access control function setting request message comprises an identifier of the first data object ([12:40-51] bulk configlet includes username/password, see [11:55-12:15] bulk configlet includes bulk identifier … also includes information specific to bulk configlet, such as …. OS version));
setting, by the network device ([8:50-60] management device), an initial version information value for the first data object based on the identifier of the first data object in response to the network device determining ([8:50-60] management device dynamically assigns a device object to each of network device), based on the identifier of the first data object ([11:55-12:15] bulk configlet includes bulk identifier … also includes information specific to bulk configlet, such as …. OS version)), that the first data object meets an access control function setting condition ([12:40-51] network device uses username/password to authenticate itself to management device); and
Krishnamurthy does not explicitly disclose:
sending, by the network device, a setting success response message to the first client, wherein the setting success response message indicates the first client to record the version information of the first data object.
However, A(2) discloses:
sending, by the network device ([FIG. 2] management device), a setting success response message ([19:24-38] if the commit was successful … configuration module (see [FIG. 2] management device) updates the global version for the device with the latest revision … marks the device as successful).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of A(2) to have sent, by the network device a setting success response message. One of ordinary skill in the art would have been motivated to do so to allow parallel service commits and permit out of band changes (A(2), [7:51-65]).
Krishnamurthy-A(2) do not explicitly disclose:
sending a setting success response message to the first client, wherein the setting success response message indicates the first client to record the version information of the first data object.
However, A(3) discloses:
sending a setting success response message to the first client ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration), wherein the setting success response message indicates the first client to record the version information of the first data object ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A(3) to have the setting success response message sent to the first client to indicate the client to record the version information. One of ordinary skill in the art would have been motivated to do so to output a request for configuration based on a comparison of the version numbers at the resource and the central controller (A(3), [24:43-53]).
Regarding claim 11, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 10, set forth above,
Krishnamurthy-A(2) do not explicitly disclose:
wherein the setting success response message comprises the initial version information value, or the setting success response message indicates the first client to set the initial version information value for the first data object.
However, A(3) discloses:
the setting success response message indicates the first client to set the initial version information value for the first data object ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A(3) to have the setting success response message sent to the first client to indicate the client to set the initial version information value. One of ordinary skill in the art would have been motivated to do so to output a request for configuration based on a comparison of the version numbers at the resource and the central controller (A(3), [24:43-53]).
Regarding claim 12, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 10, wherein the access control function setting condition, set forth above, comprises:
Krishnamurthy discloses:
the network device supports setting of an access control function ([12:40-51] network device uses username/password to authenticate itself to management device … bulk configlet may … further include a password to prevent unauthorized access to management device (i.e. supporting setting of a access control function, e.g. password), and the first data object has no version information ([19:14-31] check, during bootup, whether a bulk configlet is available … does not include instructions for a bulk configlet (i.e. no version information) … boots from stored configuration data if possible).
Regarding claim 16, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 1, set forth above, wherein the method further comprises:
Krishnamurthy discloses:
sending, by the network device ([22:33-58] management device), a capability notification message to the first client ([22:33-58] management device presents user interface … enables a user to continue the process of generating a bulk configlet … one-time password … radio buttons … IP address drop0down menu … server port text field (i.e. capabilities to be assigned for the configlet)), wherein the capability notification message comprises a support capability parameter of an access control function ([22:33-58] one-time password … presents a dialog box … to receive a one-time password from the user (i.e. supporting a one-time password)), and the support capability parameter indicates whether the network device supports setting of the access control function ([22:33-58] one-time password … presents a dialog box … to receive a one-time password from the user (i.e. supporting a one-time password, e.g. specifying network connection settings of a bulk configlet comprising a one-time password)).
Regarding claim 18, Krishnamurthy discloses:
A method ([2:62-3:2] method), comprising:
sending, by a first client ([2:62-3:2] management device … receiving a network session request from one of the plurality of network devices), a configuration request message to a network device ([2:62-3:2] network session request includes the bulk identifier, e.g. from one of the plurality of network devices (i.e. client), see [11:55-65] management device recognizes that network device requires specific configuration data (i.e. configuration request), e.g. to management device as above in [2:62-3:2]), wherein the configuration request message comprises operation indication information ([11:55-65] when network device 14a boots using bulk configlet … identifies itself to management device using bulk identifier … management device recognizes that network device requires specific configuration data (i.e. operation indication information, e.g. indicating a configuration operation required)), wherein the operation indication information indicates that the first client requests the network device to perform an operation on a first data object ([7:1-22] bulk configlet for network devices includes a set of configuration data that will enable each of network devices to configure a network stack and to connect to management device (i.e. performing configuration on network stack)), the operation indication information comprises first version information ([10:21-38] network device passes the bulk configlet identifier to management device, see [11:55-12:15] bulk configlet includes bulk identifier … also includes information specific to bulk configlet, such as …. OS version)), and the first data object comprises configuration data of the network device ([7:1-22] bulk configlet for network devices includes a set of configuration data that will enable each of network devices to configure a network stack and to connect to management device (i.e. performing configuration on network stack)), and
wherein the configuration request message indicates, in response to the network device detecting that the first version information is consistent with first reference version information ([10:21-38] recognizes the bulk configlet identifier by comparing the identifier (i.e. first version information) to the identifier stored in bulk device object (i.e. first reference version information) … when the received identifier matches (i.e. detecting that the version information is consistent with the reference version information) … forwards a specific configuration data from the one of device objects to the corresponding one of network devices (i.e. performing a configuration operation, e.g. network stack as above)), the network device to perform the operation on the first data object ([10:21-38] recognizes the bulk configlet identifier by comparing the identifier (i.e. first version information) to the identifier stored in bulk device object (i.e. first reference version information) … when the received identifier matches (i.e. detecting that the version information is consistent with the reference version information) … forwards a specific configuration data from the one of device objects to the corresponding one of network devices (i.e. performing a configuration operation, e.g. network stack as above)), wherein the first reference version information is version information of the first data object and that is recorded by the network device ([10:21-38] identifier stored in bulk device object, see [11:30-12:15] management device generates bulk configlet in response to data received from administrator … includes bulk identifier).
Krishnamurthy does not explicitly disclose:
network configuration protocol (NETCONF), the first version information is version information of the first data object and that is recorded by the first client,
receiving, by the first client, a configuration success message sent by the network device and that indicates successful configuration by successfully performing the operation on the first data object by the network device, wherein the configuration success message carries updated first reference version information having a second value, wherein the second value is a value of the first reference version information at the network device after the first reference version information is updated, in response to successfully performing the operation on the first data object, from a first value to the second value, wherein the second value is different from the first value and indicates a version of the first data object different than a version indicated by the first value;
updating, by the first client, in response to successfully performing the operation on the first data object, the first version information to have the second value.
However, A(2) discloses:
network configuration protocol (NETCONF) ([5:60-6:14] management device uses one or more network management protocols designed for management of configuration data … NETCONF),
receiving a configuration success message sent by the network device and that indicates successful configuration by successfully performing the operation on the first data object by the network device ([19:24-20:15] configuration module updates the global version for the device with the latest revision (i.e. first value of the revision is different than the second value of the updated revision, e.g. latest revision, indicating different revision values), see also [FIG. 5] e.g. committing configuration and updating the version with the latest revision), wherein the configuration success message carries updated first reference version information having a second value ([19:24-38] if the commit was successful … configuration module (see [FIG. 2] management device) updates the global version for the device with the latest revision … marks the device as successful), wherein the second value is a value of the first reference version information at the network device after the first reference version information is updated ([19:24-38] updates the global version for the device with the latest revision, see [FIG. 5] e.g. different revision updated), in response to successfully performing the operation on the first data object ([FIG. 5] success in committing configuration), from a first value to the second value ([19:24-38] to the new LLM configuration (i.e. old configuration to new configuration)), wherein the second value is different from the first value and indicates a version of the first data object different than a version indicated by the first value ([19:24-38] if the commit was successful … configuration module (see [FIG. 2] management device) updates the global version for the device with the latest revision … marks the device as successful, see [FIG. 5] device version and global version wherein updated version information is a different version than a pre-update version information);
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of A(2) to have utilized NETCONF and updated, by the network device in response to successfully performing the operation on the first data object, a first value of the first reference information to be a second value different form the first value and indicating a version of the first data object different than a version of the first data object indicated by the first value, wherein the second value is a value of the first reference information at the network device after the first reference version and the second value is different from the first value and indicates a version of the first data object different than a version indicated by the first value. One of ordinary skill in the art would have been motivated to do so to allow parallel service commits and permit out of band changes (A(2), [7:51-65]).
Krishnamurthy-A(2) do not explicitly disclose:
the first version information is version information of the first data object and that is recorded by the first client,
updating, by the first client, in response to successfully performing the operation on the first data object, the first version information to have the second value.
However, A(3) discloses:
the first version information is version information of the first data object and that is recorded by the first client ([20:59-21:20] version of the configuration for network services stored by resource (i.e. client)),
updating, by the first client ([20:59-21:20] resource), in response to successfully performing the operation on the first data object ([25:17-26] apply the updated set of configurations), the first version information to have the second value ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A(3) to have the first version information be version information of the first data object recorded by the client, and sent, from the network device to the client, a configuration success message indicating successful configuration carrying the second value in response to successfully performing the operation. One of ordinary skill in the art would have been motivated to do so to output a request for configuration based on a comparison of the version numbers at the resource and the central controller (A(3), [24:43-53]).
Regarding claim 19, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 18, wherein
Krishnamurthy-A(2) do not explicitly disclose:
the receiving the configuration success message sent by the network device, and
the updating the first version information are performed after sending, by the first client, the NETCONF configuration request message to the network device.
However, A(3) discloses:
the receiving the configuration success message sent by the network device ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration), and
the updating the first version information are performed ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration) after sending, by the first client, the NETCONF configuration request message to the network device ([18:28-38] resources may provide a NETCONF interface message to manage the configuration on the resources).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A(3) to have the receiving the configuration success message and the updating the first version information after sending the NETCONF configuration message to the network device. One of ordinary skill in the art would have been motivated to do so to output a request for configuration based on a comparison of the version numbers at the resource and the central controller (A(3), [24:43-53]).
Regarding claim 20, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 19, set forth above,
Krishnamurthy-A(2) do not explicitly disclose:
wherein the updating the first version information comprises:
updating and recording, by the first client, the first version information as the updated first reference version information.
However, A(3) discloses:
updating and recording, by the first client ([25:17-26] resource), the first version information as the updated first reference version information ([24:33-42] central controller may generate a version number for the configuration … output the version number for the configuration [25:17-26] resource may … update the version number for the resource configuration).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A(3) to have the receiving the configuration success message and the updating the first version information after sending the NETCONF configuration message to the network device. One of ordinary skill in the art would have been motivated to do so to output a request for configuration based on a comparison of the version numbers at the resource and the central controller (A(3), [24:43-53]).
Claim(s) 2-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3) further in view of Chen et al. (US-11455291-B2) hereinafter Chen.
Regarding claim 2, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 1, set forth above,
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
wherein the NETCONF configuration request message is sent in response to the first client detecting that the first version information is consistent with the first reference version information.
However, Chen discloses:
wherein the NETCONF configuration request message is sent in response to the first client detecting that the first version information is consistent with the first reference version information ([19:64-20:14] receiving, from the client device, a second request for updates to the client version of the database … including … a second client database version number that matches the remote database version number that was provided to the client device (i.e. first version information is consistent with the first reference version information to send an update request)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of Chen to have sent the NETCONF configuration request message in response to the first client detecting that the version information is consistent with the reference version information. One of ordinary skill in the art would have been motivated to do so to process an update request where the starting position is specified by the cursor rather than starting at the first database entry (Chen, [19:64-20:14]).
Regarding claim 3, Krishnamurthy-A(2)-A(3)-Chen disclose:
The method according to claim 2, set forth above, wherein the method further comprises:
Krishnamurthy discloses:
receiving, by the network device ([2:62-3:2] management device … receiving a network session request from one of the plurality of network devices), a query message sent by the first client ([2:62-3:2] network session request includes the bulk identifier, e.g. from one of the plurality of network devices (i.e. client), see [11:55-65] management device recognizes that network device requires specific configuration data (i.e. configuration request)), wherein the query message comprises an identifier of the first data object ([11:55-65] when network device 14a boots using bulk configlet … identifies itself to management device using bulk identifier); and
sending, by the network device ([10:21-38] management device), a query response message to the first client ([10:21-38] forwards a specific configuration data from the one of device objects to the corresponding one of network devices), wherein the query response message comprises the version information of the first data object that is recorded by the network device ([10:21-38] recognizes the bulk configlet identifier by comparing the identifier (i.e. first version information) to the identifier stored in bulk device object (i.e. first reference version information) … when the received identifier matches (i.e. detecting that the version information is consistent with the reference version information) … forwards a specific configuration data from the one of device objects to the corresponding one of network devices (i.e. performing a configuration operation, e.g. network stack as above), see [11:55-12:15] bulk configlet includes bulk identifier … also includes information specific to bulk configlet, such as …. OS version)).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3) further in view of Chen et al. (US-11455291-B2) hereinafter Chen further in view of Ji (US-20100057849-A1).
Regarding claim 4, Krishnamurthy-A(2)-A(3)-Chen disclose:
The method according to claim 2, set forth above, wherein the method further comprises:
Krishnamurthy discloses:
sending, by the network device ([10:21-38] management device), a data change notification message to the first client ([10:21-38] forwards a specific configuration data (i.e. data change notification by sending the data) from the one of device objects to the corresponding one of network devices), wherein the data change notification message comprises the version information of the first data object that is recorded by the network device ([10:21-38] recognizes the bulk configlet identifier by comparing the identifier (i.e. first version information) to the identifier stored in bulk device object (i.e. first reference version information) … when the received identifier matches (i.e. detecting that the version information is consistent with the reference version information) … forwards a specific configuration data from the one of device objects to the corresponding one of network devices (i.e. performing a configuration operation, e.g. network stack as above), see [11:55-12:15] bulk configlet includes bulk identifier … also includes information specific to bulk configlet, such as …. OS version)), and
Krishnamurthy does not explicitly disclose:
the data change notification message is sent by the network device in response to the first client subscribing to a change notification of data in the first data object.
However, Ji discloses:
the data change notification message is sent by the network device in response to the first client subscribing to a change notification of data in the first data object ([0012] method for sending a NETCONF-based notification … accepting, by the NETCONF server, a notification subscription of the NETCONF client; generating, by the NETCONF server, a notification when an event occurs in the system).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of Ji to have the data change notification message sent by the network device in response to the first client subscribing to a change notification of data in the first data object. One of ordinary skill in the art would have been motivated to do so to send a NETCONF-based notification based on a notification subscription of a NETCONF client when an event occurs in the system (Ji, [0012]).
Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3) further in view of Sidaraddi et al. (US-10567223-B1) hereinafter Sidaraddi.
Regarding claim 5, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 1, set forth above,
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
wherein the version information comprises a timestamp, and the first reference version information is system time, at which the network device completes performing the operation on the first data object, recorded by the network device, or the first reference version information is system time, at which the network device starts to perform the operation on the first data object, recorded by the network device.
However, Sidaraddi discloses:
wherein the version information comprises a timestamp ([7:6-12] revision value (e.g., a revision number for most recently received configuration data and/or a timestamp value corresponding to a time at which the most recent configuration data was received), and the first reference version information is system time, at which the network device completes performing the operation on the first data object, recorded by the network device, or the first reference version information is system time, at which the network device starts to perform the operation on the first data object ([10:32-48] determines that the expected current revision value is equal to the actual current revision value … updates the configuration data (i.e. starts to perform the operation)), recorded by the network device ([7:6-12] revision value (e.g., a revision number for most recently received configuration data and/or a timestamp value corresponding to a time at which the most recent configuration data was received)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of Sidaraddi to have the version information comprise a timestamp and the first reference version information is system time at which the network device starts to perform the operation on the first data object. One of ordinary skill in the art would have been motivated to do so to reduce the amount of time configuration of elements will be locked in a distributed transaction and promote simultaneous configuration changes in the network (Sidaraddi, [7:49-59]).
Regarding claim 15, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 1, set forth above, wherein the method further comprises:
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
receiving, by the network device, an access control function setting deletion request message sent by the first client, wherein the access control function setting deletion request message comprises an identifier of the first data object; and
deleting, by the network device, the version information of the first data object based on the identifier of the first data object in response to the network device determining, based on the identifier of the first data object, that the first data object meets an access control function setting deletion condition.
However, Sidaraddi discloses:
receiving, by the network device ([5:48-6:2] management devices), an access control function setting deletion request message sent by the first client ([6:26-50] management devices 10 include one or more translation functions for translating high-level configuration data to low-level … configuration data … accept the high-level configuration data … output respective sets of low-level device configuration data changes, e.g. … deletions (i.e. input to delete equated to an access control function setting deletion request)), wherein the access control function setting deletion request message comprises an identifier of the first data object ([9:38-56] configuration update data specifies existing elements to be deleted (i.e. identifies the data object) … deletes the specified elements from configuration database); and
deleting, by the network device ([5:48-6:2] management devices), the version information of the first data object based on the identifier of the first data object ([9:38-56] deletes the specified elements from configuration database) in response to the network device determining, based on the identifier of the first data object ([9:38-56] specified elements), that the first data object meets an access control function setting deletion condition ([9:38-56] validates configuration update data … deletes the specified elements from configuration database, see [7:27-44] administrators … specify certain operational characteristics that further objectives of administrators … specify for an element a particular operational policy regarding security, device accessibility … etc. (i.e. access control)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of Sidaraddi to have received an access control function setting deletion request message comprising an identifier of the first data object to delete the version information based on the identifier, and in response to determining that the first data object meets an access control function setting deletion condition. One of ordinary skill in the art would have been motivated to do so to delete specified elements from the configuration database based on the configuration update data specifying existing elements to be deleted in view of validation of a configuration (Sidaraddi, [9:38-56]).
Claim(s) 7-8, 13 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3) further in view of Zhang (US-8549165-B2).
Regarding claim 7, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 6, wherein recording, by the network device, the first reference version information, set forth above, comprises:
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
updating and recording, by the network device, the first reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets an access control function.
However, Zhang discloses:
updating and recording, by the network device, the first reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets an access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of Zhang to have updated and recorded the first reference version in response to a data granularity of the first data object corresponding to the first reference version meeting a data granularity at which the network device sets an access control function. One of ordinary skill in the art would have been motivated to do so to achieve a data integrity check to enable proper handling and avoid loading failures and execution failures caused by data incompleteness (Zhang, [13:58-64]).
Regarding claim 8, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 6, wherein the operation indication information, set forth above, further comprises
Krishnamurthy discloses:
an identifier of a second data object ([8:61-9:17] bulk configlet comprises an XML file … one or more various elements required to be filled in (i.e. second data object, a second element)), the first data object is a child data object of the second data object ([8:61-9:17] bulk configlet comprises an XML file … one or more various elements required to be filled in (i.e. second data object, a second element) … relationships between elements (e.g., parent/child relationships, i.e. first data object is child of second data object)), and
Krishnamurthy does not explicitly disclose:
second reference version information is version information of the second data object and that is recorded by the network device; and recording, by the network device, the first reference version information comprises:
updating and recording, by the network device, the first reference version information and the second reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets an access control function, and a data granularity of the second data object corresponding to the second reference version information meeting the data granularity at which the network device sets the access control function.
However, A(2) discloses:
second reference version information is version information of the second data object and that is recorded by the network device ([19:24-20:15] configuration module updates the global version for the device with the latest revision (i.e. second value of the revision is different than the first value of the previous revision, e.g. indicating different revision values), see also [FIG. 5] e.g. committing configuration and updating the version with the latest revision);
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of A(2) to have recorded second reference version information of the second data object. One of ordinary skill in the art would have been motivated to do so to allow parallel service commits and permit out of band changes (A(2), [7:51-65]).
Krishnamurthy-A(2) do not explicitly disclose:
and recording, by the network device, the first reference version information comprises:
updating and recording, by the network device, the first reference version information and the second reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets an access control function, and a data granularity of the second data object corresponding to the second reference version information meeting the data granularity at which the network device sets the access control function
However, Zhang discloses:
and recording, by the network device, the first reference version information comprises:
updating and recording, by the network device, the first reference version information and the second reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets an access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete), and a data granularity of the second data object corresponding to the second reference version information meeting the data granularity at which the network device sets the access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of Zhang to have updated and recorded the first and second reference version in response to a data granularity of the first data object corresponding to the first reference version meeting a data granularity at which the network device sets an access control function and the second data object corresponding to the second reference version meeting a data granularity at which the network device also sets an access control function. One of ordinary skill in the art would have been motivated to do so to achieve a data integrity check to enable proper handling and avoid loading failures and execution failures caused by data incompleteness (Zhang, [13:58-64]).
Regarding claim 13, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 12, wherein the access control function setting condition, set forth above, further comprises:
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
a data granularity of the first data object meeting a data granularity that is of setting the access control function and that is supported by the network device.
However, Zhang disclose:
a data granularity of the first data object meeting a data granularity that is of setting the access control function and that is supported by the network device ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of Zhang to have a data granularity of the first data object corresponding to the first reference version meeting a data granularity at which the network device sets an access control function. One of ordinary skill in the art would have been motivated to do so to achieve a data integrity check to enable proper handling and avoid loading failures and execution failures caused by data incompleteness (Zhang, [13:58-64]).
Regarding claim 17, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 16, wherein the capability notification message, set forth above, further comprises
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
a support granularity parameter of the access control function, the support granularity parameter indicates that the network device supports a data granularity of setting the access control function, and the data granularity comprises a dataset granularity, a YANG module granularity, or a data node granularity.
However, Zhang discloses:
a support granularity parameter of the access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity in a parameter of XML file)), the support granularity parameter indicates that the network device supports a data granularity of setting the access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete), and the data granularity comprises a dataset granularity ([11:49-59] size of the control data packet (i.e. granularity)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of Zhang to have updated and recorded the first reference version in response to a data granularity of the first data object corresponding to the first reference version meeting a data granularity at which the network device sets an access control function. One of ordinary skill in the art would have been motivated to do so to achieve a data integrity check to enable proper handling and avoid loading failures and execution failures caused by data incompleteness (Zhang, [13:58-64]).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3) further in view of A et al. (US-11711262-B2) hereinafter A further in view of Zhang (US-8549165-B2).
Regarding claim 9, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 6, wherein the operation indication information, set forth above, further comprises
Krishnamurthy discloses:
an identifier of a third data object ([8:61-9:17] bulk configlet comprises an XML file … one or more various elements required to be filled in (i.e. third data object, a third element)), the first data object is a child data object of the third data object ([8:61-9:17] bulk configlet comprises an XML file … one or more various elements required to be filled in (i.e. third data object, a third element) … relationships between elements (e.g., parent/child relationships, i.e. first data object is child of third data object)),
Krishnamurthy does not explicitly disclose:
third reference version information is version information of the third data object and that is recorded by the network device, an access control function that is set by the network device supports a reverse selection mechanism, and recording, by the network device, the first reference version information comprises:
updating and recording, by the network device, the first reference version information and the third reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets the access control function, a data granularity of the third data object corresponding to the third reference version information meeting the data granularity at which the network device sets the access control function, and a reverse selection mechanism parameter of the access control function that is set by the network device not comprising the identifier of the first data object; or
updating and recording, by the network device, the first reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets the access control function, a data granularity of the third data object corresponding to the third reference version information meeting the data granularity at which the network device sets the access control function, and a reverse selection mechanism parameter of the access control function that is set by the network device comprising the identifier of the first data object.
However, A(2) discloses:
third reference version information is version information of the third data object and that is recorded by the network device ([19:24-20:15] configuration module updates the global version for the device with the latest revision (i.e. second value of the revision is different than the third value of the updated revision, e.g. latest revision, indicating different revision values), see also [FIG. 5] e.g. committing configuration and updating the version with the latest revision),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy in view of A(2) to have recorded third reference version information of the third data object. One of ordinary skill in the art would have been motivated to do so to allow parallel service commits and permit out of band changes (A(2), [7:51-65]).
Krishnan-A(2) do not explicitly disclose:
an access control function that is set by the network device supports a reverse selection mechanism, and recording, by the network device, the first reference version information comprises:
updating and recording, by the network device, the first reference version information and the third reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets the access control function, a data granularity of the third data object corresponding to the third reference version information meeting the data granularity at which the network device sets the access control function, and a reverse selection mechanism parameter of the access control function that is set by the network device not comprising the identifier of the first data object; or
updating and recording, by the network device, the first reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets the access control function, a data granularity of the third data object corresponding to the third reference version information meeting the data granularity at which the network device sets the access control function, and a reverse selection mechanism parameter of the access control function that is set by the network device comprising the identifier of the first data object.
However, A discloses:
an access control function that is set by the network device supports a reverse selection mechanism ([7:27-44] administrators … specify certain operational characteristics that further objectives of administrators … specify for an element a particular operational policy regarding security, device accessibility … etc. (i.e. access control), see [15:62-16:5] retrieves the resource ID and version ID for children of that resource (i.e. reverse selection mechanism {note: specification defines reverse selection as [0019] “… reversely select a child data object from the parent data object, so that data change of the child data object does not affect version information of the parent data object})), and recording, by the network device, the first reference version information comprises:
a reverse selection mechanism parameter of the access control function that is set by the network device not comprising the identifier of the first data object ([2:65-3:10] if any child resource in the hierarchy has a different version ID, then the server can specifically make a call for the specific resource [7:27-44] administrators … specify certain operational characteristics that further objectives of administrators … specify for an element a particular operational policy regarding security, device accessibility … etc. (i.e. access control));
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2) in view of A to have an access control function to support a reverse selection mechanism where the parameter is set by the network device not comprising the identifier of the first data object. One of ordinary skill in the art would have been motivated to do so to specify certain operational characteristics such as device accessibility (A, [7:27-44]).
Krishnamurthy-A(2)-A do not explicitly disclose:
updating and recording, by the network device, the first reference version information and the third reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets the access control function, a data granularity of the third data object corresponding to the third reference version information meeting the data granularity at which the network device sets the access control function,
However, Zhang discloses:
updating and recording, by the network device, the first reference version information and the third reference version information in response to a data granularity of the first data object corresponding to the first reference version information meeting a data granularity at which the network device sets the access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete), and a data granularity of the third data object corresponding to the third reference version information meeting the data granularity at which the network device sets the access control function ([11:49-59] size of the control data packet may be provided to the client through XML file (i.e. granularity) … client may determine whether the size of the downloaded control data package equals the control data package size analyzed from the XML file … performing the third check-code generating step, see [13:42-45] control data package may also include a second record file for storing name and version information of the control data files of the control [14:27-36] if the third check code is the same as the second check code … downloaded control data packet is complete).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A in view of Zhang to have updated and recorded the first and third reference version in response to a data granularity of the first data object corresponding to the first reference version meeting a data granularity at which the network device sets an access control function and the third data object corresponding to the third reference version meeting a data granularity at which the network device also sets an access control function. One of ordinary skill in the art would have been motivated to do so to achieve a data integrity check to enable proper handling and avoid loading failures and execution failures caused by data incompleteness (Zhang, [13:58-64]).
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al. (US-9253034-B1) hereinafter Krishnamurthy in view of A et al. (US-10374886-B1) hereinafter A(2) further in view of A et al. (US-11611474-B2) hereinafter A(3)further in view of A et al. (US-11711262-B2) hereinafter A.
Regarding claim 14, Krishnamurthy-A(2)-A(3) disclose:
The method according to claim 10, wherein the access control function setting request message, set forth above, further comprises
Krishnamurthy-A(2)-A(3) do not explicitly disclose:
a reverse selection mechanism parameter, the reverse selection mechanism parameter comprises an identifier of one or more fourth data objects, and the fourth data object is a child data object of the first data object.
However, A discloses:
a reverse selection mechanism parameter ([2:65-3:10] if any child resource in the hierarchy has a different version ID, then the server can specifically make a call for the specific resource), the reverse selection mechanism parameter comprises an identifier of one or more fourth data objects ([2:65-3:10] if any child resource in the hierarchy has a different version ID, then the server can specifically make a call for the specific (i.e. identified by specificity, e.g. identifier) resource), and the fourth data object is a child data object of the first data object ([2:65-3:10] if any child resource in the hierarchy has a different version ID, then the server can specifically make a call for the specific resource [7:27-44] administrators … specify certain operational characteristics that further objectives of administrators … specify for an element a particular operational policy regarding security, device accessibility … etc. (i.e. access control));
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Krishnamurthy-A(2)-A(3) in view of A to have an access control function to support a reverse selection mechanism where the parameter is set by the network device not comprising the identifier of the first data object. One of ordinary skill in the art would have been motivated to do so to specify certain operational characteristics such as device accessibility (A, [7:27-44]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
DeSalvo (US-20090144395-A1) SYSTEM AND METHOD FOR OPTIMIZING CONTENT RETRIEVAL OVER A DATA NETWORK;
Fan (US-10038630-B2) NETWORK SYSTEM AND SOFTWARE UPDATING METHOD;
Chhabda et al. (US-11461040-B2) ASYNCHRONOUS WRITE REQUEST MANAGEMENT.
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 Alex Tran whose telephone number is (571)272-8173. The examiner can normally be reached Monday-Friday 10AM-6PM ET.
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, Kamal Divecha can be reached at (571)272-5863. 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.
/Alex Tran/Primary Examiner, Art Unit 2453
Prosecution Insights