Patent Description:
Reference will now be made, by way of example only, to the accompanying drawings in which:.

The invention is defined in detail in the appended independent claims, whereas preferred embodiments of the invention are defined in the appended dependent claims. Devices connected to a network may be widely accepted and may often be more convenient to use. In particular, new services have developed to provide devices as a service where a consumer simply uses the device while a service provider maintains the device and ensures that its performance is maintained at a certain level.

With repeated use of any device over time, the device uses various parts or components that may wear down over time and eventually fail. Failure of a part in any device may result in significant effects for a consumer since the consumer may generally rely on the device, such as to operate a business or generate output for consumption. When a device fails, the device is to be taken offline and the down time used to diagnose the problem and to identify the cause of the failure. Subsequently, the device may be repaired, which may include the replacement of a part or component of the device. In some instances, the failure of a component may result in unintended side effects where additional components are damaged. In addition, if the failed part or component is not known, repair and replacement of the part or component is not possible.

To reduce the amount of downtime of a device, some parts and components may have estimated life expectancies measured in time, usage, or a combination of both. Accordingly, parts and components may be preemptively replaced to reduce the likelihood of downtime affecting the device. In order to reduce downtime, the estimated life expectancies of parts may be lower than the actual life expectancy to decrease the probability of a premature failure. Even with the reduced estimated life expectancies, parts or components may fail before its estimated life expectancy. This may cause the device to go out of service during the diagnosis and repair or replacement the failed part.

Telemetry data are collected at a device and forwarded to a central server to identify parts or components that are to be replaced. The telemetry data may be data associated with the wear on the part or component, such as the cumulative operational time, or other measure. In other examples, the telemetry data may include measurements of a component, such as data integrity, or electrical properties of the part or component. In many examples, it is to be appreciated that telemetry data is collected using a background process that does not significant affect the performance of the device which may be running other applications. It is to be appreciated that the telemetry data may not provide a definitive predictor that a part or component is to imminently fail. Accordingly, the central server may identify a part or component for replacement prematurely resulting in replacing a part or component well before it is to fail. Once the central server predicts a part or component of the device is about to fail based on telemetry data, the central server requests a further deep diagnosis be carried out at the device. The deep diagnostic may be carried out on a specific part or component using a local process that may assess the health of the part or component more accurately than the telemetry data collected using a background process.

Referring to <FIG>, an example of a server of a hardware replacement prediction system to monitor parts or components of a device is generally shown at <NUM>. The server <NUM> may include additional components, such as various memory storage units, interfaces to communicate with other devices, and further input and output devices to interact with an administrator with access to the server <NUM>. In addition, input and output peripherals may be used to train or configure the server <NUM> as described in greater detail below. In the present example, the server <NUM> includes a communication interface <NUM>, a prediction engine <NUM>, a diagnostic evaluator <NUM>, and a reporter <NUM>. Although the present example shows the prediction engine <NUM>, the diagnostic evaluator <NUM>, and a reporter <NUM> as separate components, in other examples, the prediction engine <NUM>, the diagnostic evaluator <NUM>, and a reporter <NUM> may be part of the same physical component such as a microprocessor configured to carry out multiple functions.

The communications interface <NUM> is to communicate with devices over a network. In the present example, the server <NUM> may be in the cloud to manage a plurality of client devices. Accordingly, the communications interface <NUM> may be to receive telemetry data several different client devices which the server <NUM> manages. The telemetry data indicate the health of a client device. The manner by which the communications interface <NUM> receives the telemetry data is not particularly limited. In the present example, the server <NUM> may be a cloud server located at a distant location from the client devices which may be broadly distributed over a large geographic area. Accordingly, the communications interface <NUM> may be a network interface communicating over the internet. In other examples, the communication interface <NUM> may connect to the client devices via a peer to peer connection, such as over a wire or private network.

In the present example, the telemetry data collected is not particularly limited. For example, the telemetry data may include system device information, such as account name, model, manufacturer, born on date, type, etc., hardware information, such as smart drive information, firmware revision, disk physical information like model, manufacturer, self-test results, and cell voltage. The telemetry data are collected using a background process at the client device. The background process may use little resources such that it does not substantially affect foreground processes running on the device. The telemetry data may be received by the communications interface <NUM> at regularly scheduled intervals. For example, the telemetry data may be received once a day. In other examples, the telemetry data may be received more frequently, such as every hour, or less frequently, such as every week.

The prediction engine <NUM> is to process the telemetry data to determine the health of the client device from which the telemetry data was received. In particular, the prediction engine <NUM> is to apply a prediction model to identify a potential hardware issue at the client device. The identification of the hardware issue may include the determination of a remaining life expectancy. In the present example, the prediction engine <NUM> may flag a component with an expected failure and continue to monitor other parts and components to aggregate multiple issues before presenting to a user of the client device. By aggregating the issues, it is to be appreciated that the user of the device may be subjected to fewer requests for a deep or heavy diagnosis carried out the client device. Accordingly, this may lead to less interruptions for the user and an improved user experience. In other examples, the prediction engine <NUM> may immediately provide an indication of a potential hardware failure.

The prediction model used by the prediction engine <NUM> is not particularly limited. In the present example, the prediction engine <NUM> may use a rules-based prediction method where the telemetry data is applied to various rules to determine whether the part or component from which the telemetry data was collected will develop a hardware issue. In other examples, machine learning models may be used to predict potential hardware failures. For example, the prediction model may be a neural network or a classifier model. In particular, the prediction model may include support vector machines, random forest trees, Naïve Bayes classifiers, recurring neural networks, and other types of neural networks.

The diagnostic evaluator <NUM> is to receive a message from the prediction engine <NUM> to indicate a potential hardware failure has been predicted at a client device based on an application of the prediction model to the telemetry data received from the client device. In the present example, upon receiving the message from the prediction engine <NUM> of a request for a local confirmation of the hardware issue identified by the prediction engine <NUM> is sent to the client device. In the present example, the request for local confirmation from the local device may cause the client device to carry out a deep or heavy diagnostic process on the identified component. For example, the diagnostic process may be carried out via a local diagnostic engine described in greater detail below.

In the present example, the diagnostic engine may lock out the client device such that no other applications may be used by the user of the client device. Accordingly, it is to be appreciated that by running the heavy diagnostic process, the user of the client device may be inconvenienced. Therefore, to improve the user experience, the diagnostic evaluator <NUM> may further generate a message and transmit the message to explain the potential hardware issue to the user. The message may also include additional advice for the user, such as to connect the client device to a power source. The message may then be displayed by the client device to the user. In this example, the message may solicit a response from the user of the client device to run the diagnostic process to collect diagnostic data for providing the local confirmation. If the user fails to provide authorization, such as when a user does not want to be interrupted during use of the client device, the diagnostic evaluator <NUM> may re-send the message or generate follow-up messages periodically for the client device until the user provides authorization.

In other examples, the diagnostic evaluator <NUM> may not seek user authorization and the message provided to the client device may be informational. Accordingly, the client device may then be forced into a diagnostic process and lock out the user from all other functionality. In further examples, the diagnostic evaluator <NUM> may solicit a response for a predetermined number of times and then force the client device to lock out the user after no authorization is received. The diagnostic evaluator <NUM> may also determine to lock out the user of the client device when a serious issue is predicted by the prediction engine <NUM> and solicit a response when a less serious issued is predicted.

The reporter <NUM> is to report the hardware issue upon receiving local confirmation from the client device. The manner by which the reporter <NUM> reports the hardware issue is not limited. For example, the reporter <NUM> may generate a ticket in the server <NUM> which is to be acted on upon by a technician to repair or replace the hardware of the client device. In other examples, the reporter <NUM> may send a message to another server for further processing to determine a course of action to take to solve the hardware issue.

Referring to <FIG>, an example of a device of a hardware replacement prediction system to monitor parts or components is generally shown at <NUM>. The device <NUM> may be a client device or any other device connected to the server <NUM>, such as a shared device like a scanner or printer. The device <NUM> may include additional components, such as various memory storage units, interfaces to communicate with other devices, and may include peripheral input and output devices to interact with a user. In the present example, the device <NUM> includes a data collection engine <NUM>, a communication interface <NUM>, a diagnostic engine <NUM>, and a confirmation engine <NUM>. Although the present example shows the data collection engine <NUM>, the communication interface <NUM>, the diagnostic engine <NUM>, and the confirmation engine <NUM> as separate components, in other examples, the data collection engine <NUM>, the communication interface <NUM>, the diagnostic engine <NUM>, and the confirmation engine <NUM> may be part of the same physical component such as a microprocessor configured to carry out multiple functions.

The data collection engine <NUM> is to collect telemetry data from a plurality of components within the device <NUM>. The components from which the data collection engine <NUM> collects data are not limited and may include components such as memory storage devices (e.g. a hard drive, a solid-state drive, a non-volatile memory controller), batteries, displays, processors, applications, or other software running on the device <NUM>. In the present example, the data collection engine <NUM> operates as a background process during normal operation of the device <NUM> to collect the telemetry data. The background process may use a small amount of processor resources such that the background process does not substantially affect foreground processes running on the device <NUM>. The telemetry data may be automatically transmitted to the central server <NUM> via the communications interface <NUM> at regular intervals. For example, the telemetry data may be transmitted once a day from the device <NUM>. In other examples, the telemetry data may be transmitted more frequently, such as every hour, for components subjected to more rapid changes, or less frequently, such as every week, for more stable components.

The communications interface <NUM> is to communicate with the server <NUM> over a network. In the present example, the device <NUM> may be connected to a cloud to be managed by the server <NUM> in the cloud. Accordingly, the communications interface <NUM> may be to transmit telemetry data to indicate of the health of a client device <NUM> for further processing by the server <NUM>. The manner by which the communications interface <NUM> transmits the telemetry data is not particularly limited. In the present example, the device <NUM> may connect with the server <NUM> at a distant location over a network, such as the internet. In other examples, the communication interface <NUM> may connect to the server <NUM> via a peer to peer connection, such as over a wire or private network. In the present example, the server <NUM> is a central server. However, in other examples, the server <NUM> may be a virtual server existing in the cloud where functionality may be distributed across several physical machines.

The diagnostic engine <NUM> is to carry out a diagnostic process on a component of the device <NUM> upon receiving a request from the server <NUM> via the communication interface <NUM>. In the present example, the diagnostic engine <NUM> is to carry out a deep or heavy diagnostic process on the component. The diagnostic process is to examine the health of the component using various measurements to compare against known performance metrics. Accordingly, it is to be appreciates that the diagnostic engine <NUM> carries out a significantly more resource intensive process than the collection of telemetry data by the data collection engine <NUM>.

In the present example, the diagnostic engine <NUM> may lock out a user from the device <NUM> such that no other applications may running concurrently. Accordingly, it is to be appreciated that the diagnostic engine <NUM> may be inconvenience users of the device <NUM>. To improve user experience, the diagnostic engine <NUM> may also receive a message from the server <NUM> to explain the potential hardware issue to the user. This message may then be rendered on a display (not shown) of the device for a user to review. In the present example, the message may also include additional advice for the user, such as to connect the device <NUM> to a power source such that the diagnostic engine <NUM> does not encounter issues with the device <NUM> running out of power. Furthermore, the message may solicit a response from the user of the device <NUM> to run the diagnostic process to collect diagnostic data for providing the local confirmation of a hardware issue. If the user fails to provide authorization, such as when a user does not want to be interrupted during use of the device <NUM>, the diagnostic engine <NUM> may receive additional messages periodically to request authorization from the user.

In other examples, it is to be appreciates that the diagnostic engine <NUM> may also generate messages for the user to explain the process. In such examples, the device <NUM> may include a memory storage unit including code to interpret the request from the server such that an appropriate message is generated by the diagnostic engine <NUM> for the user of the device <NUM> to improve the user experience.

The confirmation engine <NUM> is to evaluate the diagnostic data to determine the condition of the component from which the diagnostic data is collected. In particular, the confirmation engine <NUM> may confirm whether the component is operating normally or about to fail. If the component of the device <NUM> is about to fail as predicted by the prediction engine <NUM>, the confirmation engine <NUM> will generate a confirmation message and send the confirmation to the server <NUM>.

In some examples, the diagnostic engine <NUM> may receive a request for the diagnostic process to be carried out on the components of the device <NUM> to confirm that there are no hardware issues. The origin of the request is not limited and may be randomly generated at the server <NUM>, randomly generated locally at the device <NUM>, or generated based on input received from a user. The diagnostic data collected by the diagnostic engine <NUM> is used to subsequently confirm that the last set of telemetry data sent by the data collection engine <NUM> does not correspond to a hardware issue. Accordingly, this may be used to train the prediction model to improve performance of the prediction engine <NUM> upon receipt of telemetry data.

Referring to <FIG>, an example of a hardware replacement prediction system to monitor parts or components of a device is generally shown at <NUM>. In the present example, the server <NUM> is in communication with a plurality of devices <NUM> via a network <NUM>. It is to be appreciated that the devices <NUM> are not limited and may be a variety of devices <NUM> managed by the server <NUM>. For example, the device <NUM> may be a personal computer, a tablet computing device, a smart phone, or laptop computer.

Referring to <FIG>, a flowchart of an example method of hardware replacement prediction is generally shown at <NUM>. In order to assist in the explanation of method <NUM>, it will be assumed that method <NUM> may be performed with the system <NUM>. Indeed, the method <NUM> may be one way in which system <NUM> along with a server <NUM> and device <NUM> may be configured. Furthermore, the following discussion of method <NUM> may lead to a further understanding of the system <NUM> and the server <NUM> and device <NUM>. In addition, it is to be emphasized, that method <NUM> may not be performed in the exact sequence as shown, and various blocks may be performed in parallel rather than in sequence, or in a different sequence altogether.

Beginning at block <NUM>, telemetry data is collected from a plurality of components in the device <NUM>. In the present example, the data collection engine <NUM> is used to collect the telemetry data using a background process. The components from which the data collection engine <NUM> collects data are not limited and may include components such as memory storage devices (e.g. a hard drive), batteries, displays, processors, applications, or other software running on the device <NUM>. The background process carried out by the data collection engine uses a relatively small amount of processor resources such that the background process does not substantially affect foreground processes running on the device <NUM>. Accordingly, a user of the device <NUM> may not notice that telemetry data is being collected during normal use of the device.

As an example of telemetry data collected, it may be assumed that the device <NUM> includes a hard drive equipped with self-monitoring, analysis and reporting technology. In this example, the hard drive will provide telemetry data that may be silently collected by the data collection engine <NUM> at pre-defined intervals. It is to be appreciated that the telemetry data is not particularly limited and may include system device information, such as company name, hostname, PC model, PC manufacturer, born on date, product type, etc., component information, such as smart drive information, firmware revision, sectors count, total capacity, used capacity, cell voltage, electric current, and charge capacity.

Block <NUM> transmits the telemetry data collected by the data collection engine <NUM> to the server <NUM> for processing. The manner by which the telemetry data is transmitted to the server <NUM> is not limited. For example, the telemetry data may be sent via the internet. In other examples, the device <NUM> may connect to the server <NUM> via a peer to peer connection, such as over a wire or private network. In some examples, the telemetry data may be automatically transmitted to the central server <NUM> via the communications interface <NUM> at regular intervals. For example, the telemetry data may be transmitted once a day from the device <NUM>. In other examples, the telemetry data may be transmitted more frequently, such as every hour, for components subjected to more rapid changes, or less frequently, such as every week, for more stable components.

Block <NUM> involves processing the telemetry data at the server <NUM> to determine a health of the device <NUM>. In particular, the prediction engine <NUM> of the server may process the telemetry data using a prediction model to identify a hardware issue, or potential hardware issue of a component in the device <NUM>. In the present example, the prediction model may be a rules-based prediction model where the telemetry data is applied to various rules to determine whether the part or component from which the telemetry data was collected will develop a hardware issue. In other examples, machine learning models may be used to predict potential hardware failures. For example, the prediction model may be a neural network or a classifier model. In particular, the prediction model may include support vector machines, random forest trees, Naïve Bayes classifiers, recurring neural networks, and other types of neural networks.

Continuing with the example above of a hard drive having self-monitoring, analysis and reporting technology, the hard drive may provide telemetry data to the prediction engine <NUM> of the server <NUM>. The prediction engine <NUM> may then apply the prediction model to determine that the hard drive has exceeded a threshold value, such as cumulative operational time. It is to be appreciated that the threshold is not limited and may be a predetermine value set by a manufacturer.

Next, block <NUM> transmits a message from the server <NUM> to the device <NUM>. In the present example, the message may be generated by the diagnostic evaluator <NUM> on the server. In order to maintain a level of user satisfaction, it is to be understood that the message is to provide information to the user to explain the reasons for locking the user out as the diagnostic process is being carried out. Furthermore, block <NUM> may involve soliciting an authorization from the user of the device <NUM> to collect diagnostic data.

Returning to the present example of the hard drive, the message may notify a user of that the hard drive may have degrade. The message may explain that the hard drive may have degraded below acceptable performance standards and that a diagnosis is to be carried out to confirm. Furthermore, the message may solicit authorization from the user to take the device <NUM> offline temporarily while the diagnosis is carried out via a pop-up prompt. Upon receiving authorization, a follow-up message may be displayed to inform the user to not disturb the diagnosis and to ensure that the device <NUM> has sufficient power to carry out the diagnosis or to ensure the device <NUM> is connected to a power source.

Block <NUM> involves collecting the diagnostic data from the component identified by the prediction engine <NUM> upon receiving the authorization from the user. In the present example, the collection of the diagnostic data involves carrying out a diagnostic process at the device <NUM>. In particular, the diagnostic process is a local process carried out by the diagnostic engine <NUM>. Continuing with the hard drive example, the diagnostic engine <NUM> will carry out a complete disk self-test which collects various data from the hard drive. The diagnosis data to be collected from the hard drive is not limited and may include a determination of an extended self-test result, device statistics such as logical sectors written, number of read commands, temperature statistics, transport statistics, etc..

Next, block <NUM> involves evaluating the diagnostic data collected from block <NUM> to determine if the condition of the component. In the present example, the evaluation is carried out by the confirmation engine <NUM> on the device. In the present example, the confirmation engine <NUM> may have access to a database of information that outlines normal operating conditions for the component being test. Accordingly, the evaluation may involve comparing a value measured by the diagnosis engine with a stored value in the database provided by the component manufacturer or set by the administrator of the device <NUM>. Continuing with the above example, the diagnosis data collected from the hard drive may be compared with values provided by the manufacturer to determine if the hard drive is still operating within acceptable limits.

After evaluating the diagnosis data, the confirmation engine <NUM> provides a confirmation of whether the component is about to fail as predicted by the prediction engine <NUM> on the server <NUM> or whether the prediction engine <NUM> made an incorrect prediction. The confirmation engine <NUM> may subsequently generate a message to be transmitted to from the device <NUM> to the server <NUM> at block <NUM> to provide confirmation where the server <NUM> may take further action to repair or replace the component of the device <NUM>.

Referring to <FIG>, another example of a server of a hardware replacement prediction system to monitor parts or components of a device <NUM> is shown at 10a. Like components of the server 10a bear like reference to their counterparts in the server <NUM>, except followed by the suffix "a". The server 10a includes a communication interface 15a, a prediction engine 20a, a diagnostic evaluator 25a, and a reporter 30a. In the present example, the prediction engine 20a, the diagnostic evaluator 25a, and the reporter 30a, are implemented by processor 35a. The server 10a further includes a training engine 40a and a memory storage unit 45a. Although the present example shows the training engine 40a as a separate component, in other examples, the training engine 40a may also be implemented by the processor 35a.

The processor 35a may include a central processing unit (CPU), a graphics processing unit (GPU), a microcontroller, a microprocessor, a processing core, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or similar. The processor 35a and the memory storage unit 45a may cooperate to execute various instructions. The processor 35a may execute instructions stored on the memory storage unit 45a to carry out processes such as the method <NUM>. In other examples, the processor 35a may execute instructions stored on the memory storage unit 45a to implement the prediction engine 20a, the diagnostic evaluator 25a, and the reporter 30a. In other examples, the prediction engine 20a, the diagnostic evaluator 25a, and the reporter 30a may each be executed on a separate processor. In further examples, the prediction engine 20a, the diagnostic evaluator 25a, and the reporter 30a may be operated on a separate machine, such as from a software as a service provider or in a virtual cloud server.

The training engine 40a is to train the prediction model used by the prediction engine based on a local confirmation received from the device <NUM>. The manner by which the training engine 40a trains the prediction model is not limited and may be dependent on the prediction model used. For example, if the prediction mode is a rules-based model where the rules are stored in a database 510a, the local confirmation received indicating that a component is about to fail or not may be validated by the training engine 40a by comparing the local confirmation with the original prediction generated by the prediction engine 20a. In the case of any discrepancy, the database 510a storing the rules of the prediction model may be updated.

In some examples, the training engine 40a may solicit a response from the user of the device <NUM> to run the diagnostic process to collect diagnostic data for providing the local confirmation. In particular, the message may indicate that there is no predicted issue with device <NUM> and that the diagnostic data is for training purposes to improve the operation of the system <NUM>. In particular, the message may indicate that participation may be voluntary.

In other examples where the prediction model involves a machine learning or artificial intelligence model, the local confirmation may be added to the database 510a as additional training data used by the training engine 40a to train the prediction model.

Various advantages will now become apparent to a person of skill in the art. For example, the system <NUM> may benefit from having a hardware failure prediction carried out on a server <NUM> based on telemetry data received from a device <NUM> and the benefit of have a local confirmation from the device <NUM> prior to implementing any corrective measures. In particular, this will increase the accuracy the prediction generated at the server to reduce unnecessary hardware replaces to reduce costs. In addition, by carrying out the local diagnosis process on healthy machines periodically, the prediction engine <NUM> of a server <NUM> may be trained to increase the accuracy of future predictions.

Claim 1:
A server (<NUM>, 10a) comprising:
a communication interface (<NUM>, 15a, <NUM>) to receive telemetry data from a plurality of client devices (<NUM>), wherein the telemetry data is to indicate a health of a component of a client device (<NUM>) from the plurality of client devices (<NUM>);
a prediction engine (<NUM>, 20a) to process the telemetry data to determine the health of the client device (<NUM>) with a prediction model to identify a hardware issue at a component of the client device (<NUM>);
characterized in that the server (<NUM>, 10a) further comprises:
a diagnostic evaluator (<NUM>, 25a) in communication with the prediction engine (<NUM>, 20a), wherein the diagnostic evaluator (<NUM>, 25a) is to request a local confirmation of the hardware issue from the client device (<NUM>) upon identification of the hardware issue by the prediction engine (<NUM>, 20a), and wherein the local confirmation is determined at the client device (<NUM>) via a diagnostic engine (<NUM>); and
a reporter (<NUM>, 30a) to report the hardware issue upon receipt of the local confirmation.