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 .
DETAILED ACTION
This action is in response to communication filed on 6/5/2026.
Claims 1-18 are pending.
Claims 1, 7 and 13 have been amended.
Response to Arguments
Applicant’s argument(s) filed on 6/5/2026 with respect to claim(s) 1-18 have been considered but are moot in view of the new ground(s) of rejection.
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 of this title, 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.
1. Claim(s) 1, 3-5, 7, 9-11, 13 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Lu (US 20240244117 A1) in view of Saha (US 20200169531 A1) in view of Agarwal (US 20080184151 A1).
With respect to independent claims:
Regarding claim(s) 1, an information handling system comprising:
Lu teaches at least one processor; and a memory; wherein the information handling system is configured to provide tracking for a provisioning process executing on a plurality of target nodes by: (Lu, FIG.1A shows a plurality of nodes. [0039] FIG. 5 illustrates a computer system 500 (e.g., as part of a network monitoring system) which facilitates orchestration of policies for service monitoring and measurement in a network, in accordance with an aspect of the present application. Computer system 500 includes a processor 502, a memory 504, and a storage device 506. Memory 504 can include a volatile memory (e.g., RAM) that serves as a managed memory, and can be used to store one or more memory pools. [0030] Network monitoring system 230 can integrate with WLAN system 210 by synchronizing the obtained metrics and information with WLAN services 214 (via a communication 270). WLAN system 210 can thus orchestrate, by WLAN services 214, policies for network monitoring system 230 based on the integration of network monitoring system 230 and WLAN system 210.) advertising a uniform resource locator (URL) of an endpoint via multicast domain name system (mDNS) and DNS Service Discovery (DNS-SD) protocols on a computer network; (Lu, [0030] Based on the configured instructions, sensor 236 can monitor one or more services indicated in the registration information, e.g., by sending the generated instructions (i.e., the mDNS request) to access point 216 to be executed by access point 216 (via a communication 266). Access point 216 can execute the generated instructions (e.g., via a communication 252 with WLAN services 214 and communications with devices providing services (e.g., 222 and 224) relating to a device (e.g., 218 and 220) which may have requested access to access point 216, which request can be monitored by sensor 236. Access point 216 can return results of the executed instructions to sensor 236 (via communication 266). Sensor 236 can obtain from access point 216 metrics associated with the mDNS discovery and information indicating the determined server reachability (via communication 266) and send the obtained metrics and information to network monitoring system back end 234 (via a communication 268). Network monitoring system 230 can integrate with WLAN system 210 by synchronizing the obtained metrics and information with WLAN services 214 (via a communication 270). WLAN system 210 can thus orchestrate, by WLAN services 214, policies for network monitoring system 230 based on the integration of network monitoring system 230 and WLAN system 210.)
receiving telemetry information from the plurality of target nodes during the provisioning process via the endpoint, (Lu, [0030] Based on the configured instructions, sensor 236 can monitor one or more services indicated in the registration information, e.g., by sending the generated instructions (i.e., the mDNS request) to access point 216 to be executed by access point 216 (via a communication 266). Access point 216 can execute the generated instructions (e.g., via a communication 252 with WLAN services 214 and communications with devices providing services (e.g., 222 and 224) relating to a device (e.g., 218 and 220) which may have requested access to access point 216, which request can be monitored by sensor 236. Access point 216 can return results of the executed instructions to sensor 236 (via communication 266). Sensor 236 can obtain from access point 216 metrics associated with the mDNS discovery and information indicating the determined server reachability (via communication 266) and send the obtained metrics and information to network monitoring system back end 234 (via a communication 268). Network monitoring system 230 can integrate with WLAN system 210 by synchronizing the obtained metrics and information with WLAN services 214 (via a communication 270). WLAN system 210 can thus orchestrate, by WLAN services 214, policies for network monitoring system 230 based on the integration of network monitoring system 230 and WLAN system 210.)
and providing a user with access to the telemetry information. (Lu, [0030] Based on the configured instructions, sensor 236 can monitor one or more services indicated in the registration information, e.g., by sending the generated instructions (i.e., the mDNS request) to access point 216 to be executed by access point 216 (via a communication 266). Access point 216 can execute the generated instructions (e.g., via a communication 252 with WLAN services 214 and communications with devices providing services (e.g., 222 and 224) relating to a device (e.g., 218 and 220) which may have requested access to access point 216, which request can be monitored by sensor 236. Access point 216 can return results of the executed instructions to sensor 236 (via communication 266). Sensor 236 can obtain from access point 216 metrics associated with the mDNS discovery and information indicating the determined server reachability (via communication 266) and send the obtained metrics and information to network monitoring system back end 234 (via a communication 268). Network monitoring system 230 can integrate with WLAN system 210 by synchronizing the obtained metrics and information with WLAN services 214 (via a communication 270). WLAN system 210 can thus orchestrate, by WLAN services 214, policies for network monitoring system 230 based on the integration of network monitoring system 230 and WLAN system 210.)
Lu does not teach wherein the telemetry information is received via link-local addresses of the plurality of target nodes; and wherein the telemetry information indicates, for each target node, a state of the target node and an installation progress of one or more software or firmware components being installed on that target node at each of a plurality of installation stages of the provisioning process;
Saha however in the same field of computer networking teaches wherein the telemetry information is received via link-local addresses of the plurality of target nodes; (Saha, [0043] Generated link-local addresses, in some embodiments, are advertised (e.g., distributed) using standard IPv6 protocols (e.g., unsolicited neighbor advertisement (NA), NA in response to a neighbor solicitation (NS), etc.) and verified using duplicate address detection (DAD) or other similar protocols. As part of the advertisement, some embodiments, receive data messages (e.g., NS) from other nodes (e.g., network elements, such as VMs, routers, containers, etc.) on the local link indicating the link-local address and a layer 2 address (e.g., MAC address) of the other nodes.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Lu by incorporating the teachings of saha. The motivation/suggestion would have been because there is a need to assigning a unique internet protocol version 6 (IPv6) link-local address to each interface of a software router implementing a plurality of logical interfaces for a corresponding plurality of logical networks (saha, [0002]).
Lu does not teach and wherein the telemetry information indicates, for each target node, a state of the target node and an installation progress of one or more software or firmware components being installed on that target node at each of a plurality of installation stages of the provisioning process;
Agarwal however in the same field of computer networking teaches and wherein the telemetry information indicates, for each target node, a state of the target node and an installation progress of one or more software or firmware components being installed on that target node at each of a plurality of installation stages of the provisioning process; (Agarwal, [0046], [0050], [0059], [0060], [0066], FIG. 5 illustrates a system 500 that facilitates collecting data from an RFID device within an RFID network. The system 500 can include an upgrade component 502 that can collect real-time data related to an RFID network 504 and/or an RFID process (not shown). The upgrade component 502 can provide real-time data related to an entity associated with at least one of an RFID server (not shown), an RFID host (not shown), the RFID network 504, the RFID process, and/or any combination thereof. Moreover, the real-time data and/or updates can be, but are not limited to, a status, a state, details/information, connectivity, a setting, etc. Furthermore, it is to be appreciated that the upgrade component 502 and the RFID network 504 can be substantially similar to previously described figures. FIG. 8 shows progress status (installation progress) of firmware upgrading. FIG.10, thus, each portion of applicable firmware can be streamed out to each device that the firmware corresponds. At reference numeral 1008, a status related to at least one of the identification and/or deployment of the applicable portion of firmware can be provided. In one example, the real-time status of a search related to finding a particular portion of firmware for a device can be provided. In another example, a real-time status (installation stages) related to deployment completion associated with the device in the RFID network can be provided. It is to be appreciated that the methodology 1000 can further include utilizing most any suitable user interface (UI) and/or graphical user interface (GUI).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Lu by incorporating the teachings of Agarwal. The motivation/suggestion would have been because there is a need to deploy applicable firmware to the device (Agarwal, [0006]).
Claim(s) 7 and 13 is/are substantially similar to claim 1, and is thus rejected under substantially the same rationale.
With respect to dependent claims:
Regarding claim(s) 3, the information handling system of claim 1,
Lu-Saha-Agarwal teach wherein the link-local addresses are IPv6 addresses. (Saha, [0043] Generated link-local addresses, in some embodiments, are advertised (e.g., distributed) using standard IPv6 protocols (e.g., unsolicited neighbor advertisement (NA), NA in response to a neighbor solicitation (NS), etc.) and verified using duplicate address detection (DAD) or other similar protocols. As part of the advertisement, some embodiments, receive data messages (e.g., NS) from other nodes (e.g., network elements, such as VMs, routers, containers, etc.) on the local link indicating the link-local address and a layer 2 address (e.g., MAC address) of the other nodes.)
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 4, the information handling system of claim 1,
Lu-Saha-Agarwal teach wherein the link-local addresses are IPv6 addresses., wherein the computer network does not include a non-multicast domain name system (DNS) server. (Lu, [0027] The role-based mDNS service discovery of FIGS. 1A and 1B does not provide visibility into the actual service discovery process itself. Therefore, given constantly changing dynamic and temporary policies in an enterprise WLAN with a very large number of mDNS servers which need to be monitored, the process described above may not scale and may not be efficient in the enterprise WLAN scenario. [examiner notes: mDNS (Multicast DNS) and DHCP are distinct network protocols. mDNS resolves hostnames to IP addresses on local networks without a central server (e.g..local addresses). DHCP automatically assigns IP addresses and network configuration. mDNS does not replace DHCP; it operates on top of it for name resolution.])
Regarding claim(s) 5, the information handling system of claim 1,
Lu-Saha-Agarwal teach wherein the link-local addresses are IPv6 addresses. wherein the computer network does not include a dynamic host configuration protocol (DHCP) server. (Lu, [0027] The role-based mDNS service discovery of FIGS. 1A and 1B does not provide visibility into the actual service discovery process itself. Therefore, given constantly changing dynamic and temporary policies in an enterprise WLAN with a very large number of mDNS servers which need to be monitored, the process described above may not scale and may not be efficient in the enterprise WLAN scenario. [examiner notes: mDNS (Multicast DNS) and DHCP are distinct network protocols. mDNS resolves hostnames to IP addresses on local networks without a central server (e.g..local addresses). DHCP automatically assigns IP addresses and network configuration. mDNS does not replace DHCP; it operates on top of it for name resolution.])
Claim(s) 9 and 15 is/are substantially similar to claim 3, and is thus rejected under substantially the same rationale.
Claim(s) 10 and 16 is/are substantially similar to claim 4, and is thus rejected under substantially the same rationale.
Claim(s) 11 and 17 is/are substantially similar to claim 5, and is thus rejected under substantially the same rationale.
2. Claim(s) 2, 8 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Saha in view of Agarwal further in view of Andersen (US 20200133733 A1).
Regarding claim(s) 2, the information handling system of claim 1,
Lu-Saha-Agarwal do not teach wherein the information handling system is an element of a hyper-converged infrastructure (HCI) system.
Andersen however in the same field of computer networking teaches wherein the information handling system is an element of a hyper-converged infrastructure (HCI) system. (Andersen, [0001] The present disclosure relates generally to information handling systems, and more particularly to provisioning ephemeral workloads and data in a Hyper-Converged Infrastructure (HCI) provided by an information handling system.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Lu by incorporating the teachings of Andersen. The motivation/suggestion would have been because there is a need to provide an improved ephemeral workload/data provisioning system for HCI clusters (Andersen, [0005]).
Claim(s) 8 and 14 is/are substantially similar to claim 2, and is thus rejected under substantially the same rationale.
3. Claim(s) 6, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Saha in view of Agarwal further in view of Wood (US 20110246093 A1).
Regarding claim(s) 6, the information handling system of claim 1,
Lu-Saha-Agarwal do not teach wherein the plurality of target nodes includes a first group of target nodes of a first type, and a second group of target nodes of a second type.
Wood however in the same field of computer networking teaches wherein the plurality of target nodes includes a first group of target nodes of a first type, and a second group of target nodes of a second type. (Wood, [0035] The second type of sensor (222, 224, and 226) is used to monitor operating environment parameters associated with the operation of a set of components or the entire computer system 102. For example, sensor 222 can be used to monitor temperature in the vicinity of the set of microprocessors 1-3, while sensor 226 can be used to monitor a vibration level during the operation of computer system 102. As illustrated in FIG. 1, outputs from both the first type and the second type of sensor are collected by telemetry device 104 and reported to RUL prediction tool 108, so that RUL prediction tool 108 can compute an RUL for a component, a group of components, or entire computer system 102 based on these sensor signals.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Lu by incorporating the teachings of. The motivation/suggestion would have been because there is a need to predict the remaining useful life of a system component or a computer system (Wood, [0002]).
Claim(s) 12 and 18 is/are substantially similar to claim 6, and is thus rejected under substantially the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Prosecution Insights