DETAILED ACTION
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 .
This office action is in response to Applicant’s communication filed on 04/30/2025. Claims 1- 20 have been examined.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 8-11 filed on 4/30/2025, with respect to the rejection of claims 1,8,15 under 103 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 Dey.
Claim Objections
Claims 1,8,15 objected to because of the following informalities:
With regards to claims 1,8,15, the claims recite “ presenting ….from the multiple transport layer device..” the examiner suggests amending the claims to recite “…the multiple transport layer devices …”.
With regards to claim 15, the claim recites “the transport layer devices..” the examiner suggests amending the claim to recite “…the multiple transport layer devices …” for consistency.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 8-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Regarding claim 8, Applicant is seeking to patent a device configured for receiving/receiving/generating….. . The device is performing a plurality of steps (instructions) which can be interpreted as software per se.
An invention that covers a software embodiment is considered as non-statutory subject matter as software per se which does not meet one of the four categories of invention (See MPEP 2106.03).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-14,16-18,20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With regards to claims 1,8, the claims recite “the transport layer devices..” It is unclear what the transport layer devices is referring to because claims 1,8 recite “transport layer devices” in the preamble of the claims and “ “multiple transport layer devices” in receiving limitation.. Therefore, the examiner is unable to determine the metes and bounds of the claim language.
With regards to claims 2, 4, 9,11,16,18, the claims recite “the one or more devices”. It is unclear what the one or more devices is referring to . The independent claims which claims 2, 4, 9,11,16,18 depend on are amended to recite “multiple transport layer devices”. Examiner suggests amending the claim to recite “ the multiple transport layer devices”
With regards to claims 3,6,7,10,13,14,17,20, the claims recite “the one or more transport layer devices”. It is unclear what the one or more transport layer devices is referring to . The independent claims which claims 3,6,7,10,13,14,17,20, depend on are amended to recite “multiple transport layer devices”. Examiner suggests amending the claim to recite “ the multiple transport layer devices”.
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.
Claims 1,2,6,8,9,13,15,16,20 are rejected under 35 U.S.C. 103 as being unpatentable over Skovron et al. Publication No. US 2018/0302303 A1 ( Skovron hereinafter) in view of Dey et al. Publication No. US 2022/0326976 A1 ( Dey hereinafter)
Regarding claim 1,
Skovron teaches a method for providing automatic software upgrades for [..] devices (Abstract, Fig.7&8), comprises:
receiving, on a user interface (UI), selection of multiple [..] devices from a device list for upgrading; receiving, via the UI, upgrade details for upgrading the multiple [..] devices selected from the device list for upgrading (¶0033 -¶0036 the user interface 400 may allow a user (an IT professional) to view notifications of new releases (offered, required, or recommended upgrades), review devices and assets, and scope and define a software deployment plan. A software deployment plan may include a set of recommended steps to accomplish a task by using available information from the tenant's devices, assets, other telemetry data, target deadlines – ¶ 0038 - The user interface may also allow a user to specify a version of an operating system or a software application to apply during the upgrade. Similarly, as illustrated in FIG. 8, a user can set the devices to be included in the upgrade (individually, by group, or a combination thereof). The user interface 700 may allow a user to query an inventory to locate desired devices and may display a summary of the selected devices, such as by indicating a number of devices included and a number of assets associated with such devices. In some embodiments, as illustrated in FIG., the software deployment tool also provides various metrics for a tenant's devices, including a readiness metric, to aid a user in selecting an appropriate number and group of devices to include in an upgrade – ¶0040 FIG. 13 illustrates a user interface ( dashboard) generated by the software deployment tool (updated in real time) that tracks the progress of an existing plan, including providing a readiness metric for a group of devices. A user can drill-down into a readiness metric to see information on individual devices and what actions need to be taken for each device to ready the device for the upgrade -See Also ¶0041).
Based on the upgrade details, generating instructions to initiate the upgrading of the [..] devices,[..] (¶ 0038 - Similarly, selecting the deployment plan section 404 may allow a user to view existing deployment plans and create a new deployment plan. For example, FIGS. 7-11 illustrate a user interface 700 generated by the software deployment tool 226 displaying a plurality of input mechanisms for receiving user input to configure a new ( or existing) deployment plan. Using the user interface 700, a target device ( or group of devices) associated with the tenant to update, a target software application (or group of applications) associated with the tenant to update, a target schedule for performing an update, and a target completion date. The user interface 700 may also allow a user to set a scope of an upgrade, such as by the upgrade to an operating system- only scope, a software application-only scope, or an operating-system-and-software application scope -¶ 0039 - As illustrated in FIG. 9, as part of creating a deployment plan, a user can set deployment rules. For example, a user can select to exclude particular hardware, drivers, or software applications from an upgrade through the user interface 700. For example, as illustrated in FIG. 10, applications can be included or excluded from an upgrade individually or in groups, such as based on category or number of installs. A user can also set validation rules for an upgrade that define how upgrades of particular devices or assets will be tested and validated – See Also ¶ 0041),
in response to the generated instructions, initiating the upgrading each of the multiple [..] devices simultaneously to one another; presenting, on the UI, real-time information returned from the multiple [..]devices during the upgrading of each of the multiple [..] devices, validating the upgrading each of the multiple [..] devices based on the real- time information (¶0042 -¶ 0043 After reviewing and configuring a pilot, a user can deploy the upgrade for the pilot devices through the software deployment tool 226 and, therefore, can use the tool 226 to monitor the deployment status of the pilot (see, for example, FIG. 13) and gain insight into failures and remediation actions. users can see pilot results and sign-off on items as needed through the software deployment tool 226. Users can also use the results of a pilot to modify the deployment plan (including modifying the current pilot, future pilots, and production deployment – See Fig.13 – Deploying devices ready for pilot ,review pilot devices with health alerts and sign off on items validated by pilot – ¶0033 - software deployment plan may include a set of recommended steps to accomplish a task by using available information from the tenant's devices, assets, other telemetry data, target deadlines, and the like. These steps may be reviewed, validated, remediated, and optimized as part of the deployment plan. In some embodiments, the user interface also allows a user to monitor the execution of a deployment plan and, optionally, perform ongoing monitoring of a tenant's device, assets, or a combination thereof to track a tenant's overall health and trigger alerts accordingly).
However, Skovron does not explicitly teach that devices are transport layer devices
wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list;
Dey teaches
devices are transport layer devices. wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the nodes indicates that the nodes are in non critical state ( Dey – Abstract).
Regarding claim 2,
Skovron further teaches
wherein the presenting the real-time information includes receiving state changes and logs, identification of configuration conflicts, a status of configuration parameters associated with the one or more devices selected from the device list for upgrading (¶0042 – ¶0043 - a user can deploy the upgrade for the pilot devices through the software deployment tool 226 and, therefore, can use the tool 226 to monitor the deployment status of the pilot (see, for example, FIG. 13) and gain insight into failures and remediation actions. users can see pilot results and sign-off on items as needed through the software deployment tool. Users can also use the results of a pilot to modify the deployment plan (including modifying the current pilot, future pilots, and production deployment – such as after a successful pilot and thereafter can monitor the deployment status (see, for example, FIG. 13) and gain insight into failures and remediation actions through the software deployment tool. The software deployment tool can also be configured to trigger alerts for devices that have post-upgrade issues.¶0006- For example, embodiments described herein leverage device data gather by cloud-side telemetry data that includes, for example, both device status and software states. By using data collected by a cloud service regarding users, device management tools can provide IT professionals with a more complete view of the devices associated with a particular organization and more accurate information regarding upgrade readiness of particular devices or a particular tenant of the cloud service – See Fig.12, Fig.13).
Regarding claim 6,
Skovron further teaches
wherein the receiving the upgrade details for upgrading the one or more [..] devices includes receiving a schedule for initiating the upgrading of the one or more [..] devices (¶0041 - The software deployment tool can also be configured to generate other recommendations within a deployment plan, including, for example, a recommended set of devices associated with the tenant to be included in the software deployment plan, a recommended deployment schedule for the tenant, and a recommended set of applications to update as part of the software deployment - the software deployment tool may use information regarding the availability of support for particular devices, applications, or the like and use this information to recommend a schedule or completion date for a plan to ensure that an upgrade is completed before support ends).
However, Skovron does not explicitly teach that the one or more devices are one or more transport layer devices
Dey teaches
One or more devices are one or more transport layer devices (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the node indicates that the node is in non critical state ( Dey – Abstract).
Regarding claim 8,
Skovron teaches a device for performing automatic software upgrades for [..] devices, configured for: (Abstract, Fig.7&8),
receiving, via the UI, selection of multiple [..] devices from the device list for upgrading; receiving, via the UI, upgrade details for upgrading the multiple [..] devices selected from the device list for upgrading; (¶ 0033 -¶ 0036 the user interface 400 may allow a user (an IT professional) to view notifications of new releases ( offered, required, or recommended upgrades), review devices and assets, and scope and define a software deployment plan. A software deployment plan may include a set of recommended steps to accomplish a task by using available information from the tenant's devices, assets, other telemetry data, target deadlines – ¶ 0038 - The user interface may also allow a user to specify a version of an operating system or a software application to apply during the upgrade. Similarly, as illustrated in FIG. 8, a user can set the devices to be included in the upgrade (individually, by group, or a combination thereof). The user interface may allow a user to query an inventory to locate desired devices and may display a summary of the selected devices, such as by indicating a number of devices included and a number of assets associated with such devices. In some embodiments, as illustrated in FIG. 12, the software deployment tool also provides various metrics for a tenant's devices, including a readiness metric, to aid a user in selecting an appropriate number and group of devices to include in an upgrade – ¶ 0040 FIG. 13 illustrates a user interface ( dashboard) generated by the software deployment tool (updated in real time) that tracks the progress of an existing plan, including providing a readiness metric for a group of devices. A user can drill-down into a readiness metric to see information on individual devices and what actions need to be taken for each device to ready the device for the upgrade -See Also ¶ 0041).
Based on the upgrade details, generating instructions to initiate the upgrading of the [..] devices,[..] (¶ 0038 - Similarly, selecting the deployment plan section 404 may allow a user to view existing deployment plans and create a new deployment plan. For example, FIGS. 7-11 illustrate a user interface 700 generated by the software deployment tool 226 displaying a plurality of input mechanisms for receiving user input to configure a new ( or existing) deployment plan. Using the user interface 700, a target device ( or group of devices) associated with the tenant to update, a target software application (or group of applications) associated with the tenant to update, a target schedule for performing an update, and a target completion date. The user interface 700 may also allow a user to set a scope of an upgrade, such as by the upgrade to an operating system- only scope, a software application-only scope, or an operating-system-and-software application scope -¶ 0039 - As illustrated in FIG. 9, as part of creating a deployment plan, a user can set deployment rules. For example, a user can select to exclude particular hardware, drivers, or software applications from an upgrade through the user interface 700. For example, as illustrated in FIG. 10, applications can be included or excluded from an upgrade individually or in groups, such as based on category or number of installs. A user can also set validation rules for an upgrade that define how upgrades of particular devices or assets will be tested and validated – See Also ¶ 0041),
in response to the generated instructions, initiating the upgrading each of the multiple [..] devices simultaneously to one another; presenting on the UI, real-time information returned from the multiple[..] device during the upgrading each of the one or more [..] devices; and validating the upgrading each of the multiple [..] devices based on the real-time information (¶ 0042 -¶ 0043 After reviewing and configuring a pilot, a user can deploy the upgrade for the pilot devices through the software deployment tool and, therefore, can use the tool to monitor the deployment status of the pilot (see, for example, FIG. 13) and gain insight into failures and remediation actions. users can see pilot results and sign-off on items as needed through the software deployment tool. Users can also use the results of a pilot to modify the deployment plan (including modifying the current pilot, future pilots, and production deployment – See Fig.13 – Deploying devices ready for pilot ,review pilot devices with health alerts and sign off on items validated by pilot – ¶ 0033 - software deployment plan may include a set of recommended steps to accomplish a task by using available information from the tenant's devices, assets, other telemetry data, target deadlines, and the like. These steps may be reviewed, validated, remediated, and optimized as part of the deployment plan. In some embodiments, the user interface also allows a user to monitor the execution of a deployment plan and, optionally, perform ongoing monitoring of a tenant's device, assets, or a combination thereof to track a tenant's overall health and trigger alerts accordingly).
However, Skovron does not explicitly teach that devices are transport layer devices
wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list;
Dey teaches
devices are transport layer devices. wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the nodes indicates that the nodes are in non critical state ( Dey – Abstract).
Regarding claim 9,
Skovron further teaches
present the real-time information by presenting state changes and logs, identification of configuration conflicts, a status of configuration parameters associated with the one or more devices selected from the device list for upgrading. (¶0042 – ¶0043 - a user can deploy the upgrade for the pilot devices through the software deployment tool and, therefore, can use the tool to monitor the deployment status of the pilot (see, for example, FIG. 13) and gain insight into failures and remediation actions. users can see pilot results and sign-off on items as needed through the software deployment tool. Users can also use the results of a pilot to modify the deployment plan (including modifying the current pilot, future pilots, and production deployment – such as after a successful pilot and thereafter can monitor the deployment status (see, for example, FIG. 13) and gain insight into failures and remediation actions through the software deployment tool. The software deployment tool can also be configured to trigger alerts for devices that have post-upgrade issues.¶ 0006- For example, embodiments described herein leverage device data gather by cloud-side telemetry data that includes, for example, both device status and software states. By using data collected by a cloud service regarding users, device management tools can provide IT professionals with a more complete view of the devices associated with a particular organization and more accurate information regarding upgrade readiness of particular devices or a particular tenant of the cloud service – See Fig.12, Fig.13).
Regarding claim 13,
Skovron further teaches
receive the upgrade details for upgrading the one or more [..] devices by receiving a schedule for initiating the upgrading of the one or more [..] devices. (¶ 0041 - The software deployment tool 226 can also be configured to generate other recommendations within a deployment plan, including, for example, a recommended set of devices associated with the tenant to be included in the software deployment plan, a recommended deployment schedule for the tenant, and a recommended set of applications to update as part of the software deployment - the software deployment tool may use information regarding the availability of support for particular devices, applications, or the like and use this information to recommend a schedule or completion date for a plan to ensure that an upgrade is completed before support ends).
However, Skovron does not explicitly teach that the one or more devices are one or more transport layer devices
Dey teaches
One or more devices are one or more transport layer devices ¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the node indicates that the node is in non critical state ( Dey – Abstract).
Regarding claim 15,
Skovron teaches a non-transitory computer-readable media having computer-readable instructions stored thereon, which when executed to perform operations comprising:(Abstract, Fig.7&8),
receiving, on a user interface (UI), selection of multiple [..] devices from a device list for upgrading; receiving, via the UI, upgrade details for upgrading the multiple [..] devices selected from the device list for upgrading (¶ 0033 -¶ 0036 the user interface 400 may allow a user (an IT professional) to view notifications of new releases ( offered, required, or recommended upgrades), review devices and assets, and scope and define a software deployment plan. A software deployment plan may include a set of recommended steps to accomplish a task by using available information from the tenant's devices, assets, other telemetry data, target deadlines – ¶ 0038 - The user interface may also allow a user to specify a version of an operating system or a software application to apply during the upgrade. Similarly, as illustrated in FIG. 8, a user can set the devices to be included in the upgrade (individually, by group, or a combination thereof). The user interface may allow a user to query an inventory to locate desired devices and may display a summary of the selected devices, such as by indicating a number of devices included and a number of assets associated with such devices. In some embodiments, as illustrated in FIG. the software deployment tool 226 also provides various metrics for a tenant's devices, including a readiness metric, to aid a user in selecting an appropriate number and group of devices to include in an upgrade – ¶ 0040 FIG. 13 illustrates a user interface ( dashboard) generated by the software deployment tool (updated in real time) that tracks the progress of an existing plan, including providing a readiness metric for a group of devices. A user can drill-down into a readiness metric to see information on individual devices and what actions need to be taken for each device to ready the device for the upgrade -See Also ¶ 0041).
Based on the upgrade details, generating instructions to initiate the upgrading of the [..] devices,[..] (¶ 0038 - Similarly, selecting the deployment plan section 404 may allow a user to view existing deployment plans and create a new deployment plan. For example, FIGS. 7-11 illustrate a user interface 700 generated by the software deployment tool 226 displaying a plurality of input mechanisms for receiving user input to configure a new ( or existing) deployment plan. Using the user interface 700, a target device ( or group of devices) associated with the tenant to update, a target software application (or group of applications) associated with the tenant to update, a target schedule for performing an update, and a target completion date. The user interface 700 may also allow a user to set a scope of an upgrade, such as by the upgrade to an operating system- only scope, a software application-only scope, or an operating-system-and-software application scope -¶ 0039 - As illustrated in FIG. 9, as part of creating a deployment plan, a user can set deployment rules. For example, a user can select to exclude particular hardware, drivers, or software applications from an upgrade through the user interface 700. For example, as illustrated in FIG. 10, applications can be included or excluded from an upgrade individually or in groups, such as based on category or number of installs. A user can also set validation rules for an upgrade that define how upgrades of particular devices or assets will be tested and validated – See Also ¶ 0041),
in response to the generated instructions, initiating the upgrading each of the multiple [..] devices simultaneously to one another; presenting, on the UI, real-time information returned from the multiple [..]device during the upgrading each of the multiple [..] devices, validating the upgrading each of the multiple [..] devices based on the real- time information (¶0042 -¶ 0043 After reviewing and configuring a pilot, a user can deploy the upgrade for the pilot devices through the software deployment tool 226 and, therefore, can use the tool 226 to monitor the deployment status of the pilot (see, for example, FIG. 13) and gain insight into failures and remediation actions. users can see pilot results and sign-off on items as needed through the software deployment tool 226. Users can also use the results of a pilot to modify the deployment plan (including modifying the current pilot, future pilots, and production deployment – See Fig.13 – Deploying devices ready for pilot ,review pilot devices with health alerts and sign off on items validated by pilot – ¶0033 - software deployment plan may include a set of recommended steps to accomplish a task by using available information from the tenant's devices, assets, other telemetry data, target deadlines, and the like. These steps may be reviewed, validated, remediated, and optimized as part of the deployment plan. In some embodiments, the user interface also allows a user to monitor the execution of a deployment plan and, optionally, perform ongoing monitoring of a tenant's device, assets, or a combination thereof to track a tenant's overall health and trigger alerts accordingly).
However, Skovron does not explicitly teach that devices are transport layer devices
wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list;
Dey teaches
devices are transport layer devices. wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using ¶meters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the nodes indicates that the nodes are in non critical state ( Dey – Abstract).
Regarding claim 16,
Skovron further teaches
wherein the presenting the real-time information includes receiving state changes and logs, identification of configuration conflicts, a status of configuration parameters associated with the one or more devices selected from the device list for upgrading (¶0042 – ¶0043 - a user can deploy the upgrade for the pilot devices through the software deployment tool 226 and, therefore, can use the tool 226 to monitor the deployment status of the pilot (see, for example, FIG. 13) and gain insight into failures and remediation actions. users can see pilot results and sign-off on items as needed through the software deployment tool 226. Users can also use the results of a pilot to modify the deployment plan (including modifying the current pilot, future pilots, and production deployment – such as after a successful pilot and thereafter can monitor the deployment status (see, for example, FIG. 13) and gain insight into failures and remediation actions through the software deployment tool 226. The software deployment tool 226 can also be configured to trigger alerts for devices that have post-upgrade issues.¶ 0006- For example, embodiments described herein leverage device data gather by cloud-side telemetry data that includes, for example, both device status and software states. By using data collected by a cloud service regarding users, device management tools can provide IT professionals with a more complete view of the devices associated with a particular organization and more accurate information regarding upgrade readiness of particular devices or a particular tenant of the cloud service – See Fig.12, Fig.13).
Regarding claim 20,
Skovron further teaches
wherein the receiving the upgrade details for upgrading the one or more [..] devices includes receiving a schedule for initiating the upgrading of the one or more [..] devices (¶ 0041 - The software deployment tool 226 can also be configured to generate other recommendations within a deployment plan, including, for example, a recommended set of devices associated with the tenant to be included in the software deployment plan, a recommended deployment schedule for the tenant, and a recommended set of applications to update as part of the software deployment - the software deployment tool 226 may use information regarding the availability of support for particular devices, applications, or the like and use this information to recommend a schedule or completion date for a plan to ensure that an upgrade is completed before support ends).
However, Skovron does not explicitly teach that the one or more devices are one or more transport layer devices
Dey teaches
devices are transport layer devices. wherein the instructions are generated according to the interface type supported by the transport layer devices selected from the device list (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the node indicates that the node is in non critical state ( Dey – Abstract).
Claims 3,10,17 rejected under 35 U.S.C. 103 as being unpatentable over Skovron in view of Dey further in view of Mahimkar et al Publication No. US 2022/0321408 A1 (Mahimkar hereinafter) .
Regarding claim 3,
Skovron further teaches wherein the presenting the real-time information includes displaying an alarm for at least one of the [..] one or more devices (Fig.13, ¶0042-¶0043, ¶0006).
However, Skovron does not explicitly teach that the one or more devices are transport layer devices
displaying an alarm in response to determining a mismatch between a pre-upgrade configuration and a post-upgrade configuration, and receiving input to roll back the post-upgrade configuration upgrade of the at least one of the one or more transport layer devices associated with the alarm to the pre- upgrade configuration.
Dey teaches
the one or more devices are transport layer devices (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the node indicates that the node is in non critical state ( Dey – Abstract).
Mahimkar teaches
displaying an alarm in response to determining a mismatch between a pre-upgrade configuration and a post-upgrade configuration, and receiving input to roll back the post-upgrade configuration upgrade of at least one of one or more devices associated with the alarm to the pre- upgrade configuration (Fig.3, Table 1, ¶0024 -If the pre/post comparison after the software upgrade fails ( decision output is no), then the action is to roll-back the software – ¶ 0077 -the verifier conducts a robust pre and post comparison of the network and service performance and ensures that the impacts are expected. For unexpected impacts, it automatically notifies the operator who then can make a decision for halting the roll-out and potentially roll-back the changes. A workflow may be considered a sequence of steps---e.g., for building blocks A, B, C, . . . Z. One workflow may be A-B-C; another can be E-F-G-X-Y. Verification rules may be separate from a workflow. Rules are conditions. Example, if software upgrade results in a KPI degradation, then take an action such as rolling back the software – ¶0036 -The impacts may be presented on display (or fed to another computer-implemented process) for enabling a quick go/no go decision to continue the roll-out or halt).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron in view of Dey to include the teachings of Mahimkar. The motivation for doing so is to allow system to provide verification rules for pre-impact and post-impact comparison of performance associated with the one or more changes in the network (¶0003 – Mahimkar).
Regarding claim 10,
Skovron further teaches present the real-time information by displaying an alarm for at least one of the one or more [..] devices (Fig.13, ¶0042-¶0043, ¶0006).
However, Skovron does not explicitly teach that the one or more devices are transport layer devices
displaying an alarm in response to determining a mismatch between a pre-upgrade configuration and a post-upgrade configuration, and receiving input to roll back the post-upgrade configuration upgrade of the at least one of the one or more transport layer devices associated with the alarm to the pre- upgrade configuration.
Dey teaches
the one or more devices are transport layer devices (¶ 0058 -The upgrade manager 702 may receive an upgrade directive 704 from an administrator 703 such as a node administrator or data center administrator. The upgrade directive can provide a list of nodes to upgrade or can otherwise identify the nodes to upgrade. For example, the upgrade directive can specify nodes using parameters such as a tenant identifier, a node name, a node type, a node role, a smart NIC type – ¶ 0007 - the critical state policy uses values of constant node attributes (See Fig.3) to determine the criticality state of the node. ¶ 0009 - the upgrade manager is configured to upgrade a plurality of nodes that are identified by a plurality of nodes identifiers, the upgrade manager stores a plurality of critical state policies that are associated with the nodes via the plurality of node identifiers, and each of the nodes is upgraded only when in the noncritical state according to the critical state policies. producing criticality state time series data that indicates the criticality state of each of the nodes as a function of time, determining upgrade windows for the nodes, and scheduling node upgrades based on the upgrade windows – ¶ 0055 - The smart NIC 604 is an upgradeable node that can send its constant and nonconstant attributes to the upgrade manager 620 See Claim 13 & 14 - Note: The examiner interprets the transport devices as equivalent to Smart NIC nodes that are upgradeable nodes that can be upgraded according to constant attributes such as smart NIC type ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Skovron to include the teachings of Dey. The motivation for doing so is to allow the upgrade to be performed only when the criticality state of the node indicates that the node is in non critical state ( Dey – Abstract).
Mahimkar teaches
displaying an alarm in response to determining a mismatch between a pre-upgrade configuration and a post-upgrade configuration, and receiving input to roll back the post-upgrade configuration upgrade of at least one of one or more devices associated with the alarm to the pre- upgrade configuration (Fig.3, Table 1, ¶0024 -If the pre/post comparison after the software upgrade fails ( decision output is no), then the action is to roll-back the software – ¶ 0077 -the verifier conducts a robust pre and post comparison of the network and service performance and ensures that the impacts are expected. For unexpected impacts, it automatically notifies the operator who then can make a decision for halting the roll-out and potentially roll-back the changes. A workflow may be considered a sequence of steps---e.g., for building blocks A, B, C, . . . Z. One workflow may be A-B-C; another can be E-F-G-X-Y. Verification rules may be separate from a workflow. Rules are conditions. Example, if software upgrade results in a KPI degradation, then take an action such as rolling back the software – ¶0036 -The impacts may be presented on display (or fed to another computer-implemented process) for enabling a quick go/no go decision to continue the roll-out or halt).
It would have been obvious to a person of ordinary