FIELD OF THE INVENTION

The present invention relates to diagnosing computing devices and par ticularly to providing means for performing diagnostic test prioritization for a com puting device.

BACKGROUND

The following background description art may include insights, discov eries, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but provided by the pre sent disclosure. Some such contributions disclosed herein may be specifically pointed out below, whereas other such contributions encompassed by the present disclosure the invention will be apparent from their context.

Often when diagnosing mobile devices to detect faults in different com ponents of the mobile devices, the same set of diagnostic tests is performed on each mobile device regardless of, for example, the model or make of the mobile device under diagnostics. While this type of brute-force approach may provide a sure-fire method for diagnosing each mobile device if said set of diagnostic tests comprises all the relevant diagnostic tests available, it is not the most expedient or time-effi cient solution in most cases. The failure probability of a mobile device may depend on various device-specific factors such as the type, model and age of the mobile device. To further complicate the matter, some components of a mobile device may be more prone to breaking than others and are thus more likely to be faulty and in need for replacement or repair at any given time. This fault likelihood for each com ponent may also be a device-specific property. Thus, for a given mobile device some diagnostic tests in the set of diagnostic tests to be performed may be considered of high importance for achieving a successful diagnosis while others may be consid ered redundant or at least excessive. If all or at least some of the aforementioned factors could be taken into account in performing diagnostic testing of a mobile device, a significant improvement in the time required for testing each mobile de vice could be achieved.

BRIEF DESCRIPTION

According to an aspect, there is provided the subject matter of the in dependent claims. Embodiments are defined in the dependent claims. One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of preferred embodiments with reference to the attached drawings, in which

Figure 1 illustrates a system according to embodiments;

Figures 2 to 7 illustrate processes according to embodiments; and

Figures 8 and 9 illustrate apparatuses according to embodiments.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, words "comprising" and "including" should be understood as not limiting the de scribed embodiments to consist of only those features that have been mentioned and such embodiments may contain also features/structures that have not been specifically mentioned.

An architecture of a communications system to which embodiments of the invention may be applied is illustrated in Figure 1. Figure 1 illustrates a simpli fied system architecture only showing some elements and functional entities, all being logical units whose implementation may differ from what is shown. The con nections shown in Figure 1 are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the systems also comprise other functions and structures.

Figure 1 illustrates a system 100 comprising a remote computing sys tem 101 which is connected via a communications network 110 to one or more local systems 120, 130. Each local system 120, 130 comprises at least a first com puting device 121 connected via a first interface 126 to a second computing device 124 and via a second interface 127 to the communications network 110 (shown in Figure 1 only for the local system 120 for simplicity). In some embodiments, the first computing device 121 in at least some of the one or more local systems 120, 130 may be connected via first interfaces 126 to two or more second computing devices 124 simultaneously.

The first computing device 121 is a computing device capable of per forming or causing performing of a plurality of diagnostic tests on the second com puting device 124 in a controlled manner. To be able to perform said diagnostic tests or cause them to be performed by the second computing device 124 itself, the first computing device 121 may be configured, for example, to access information (e.g., device information and/or results of one or more diagnostic tests) stored to the second computing device 124, send information (e.g., device parameters or a generated diagnostic report) to the remote computing system 101 via the commu nications network 110 using the second interface 127, receive information (e.g., predicted results of one or more diagnostic tests when performed on the second computing device or lack thereof and/or other diagnostics information) from the remote computing system 101 via the communications network 110 using the sec ond interface 127 and running one or more diagnostic tests on the second compu ting device 124. The running of the one or more diagnostic tests on the second com puting device 124 may specifically comprise instructing or commanding the second computing device 124 to execute the one or more diagnostic tests and to transmit results of the one or more diagnostic tests back to the first computing device 124 or executing the one or more diagnostic tests targeting the second computing de vice 124 using the first computing device 121 (with the second computing device 124 having a predominantly passive role in running the one or more diagnostic test). A combination of these two options is also possible, in some embodiments. Moreover, the first computing device 121 may comprise at least one user input de vice 122 which provides a user of the first computing device 121 means for input ting information, for example, in connection with the diagnostic testing. The at least one user input device 122 may comprise, for example, a keyboard, a touch screen, a mouse, a touch pad and/or voice activated control device. The first computing device 121 further comprises a display 123 through which the user may be able to monitor the running of the diagnostic tests. The first interface 126 may be used, by the first computing device 121, at least for retrieving device information and/or results of one or more diagnostic tests from the second computing device 124 (or specifically from the memory 125 thereof) when performing the diagnostic test(s). The first computing device 121 may be connected via the first interface 126 to the second computing device 124 using a wire or a cable such as a USB (Universal Serial Bus)-to-USB cable, a USB-to-mini-USB cable or a USB-to-micro-USB cable, using a docking station or wirelessly (e.g., via WiFi or Bluetooth). The first computing de vice 121 may be configured to run dedicated diagnosis client software for guiding a user or an operator of the first computing device 121 through the diagnosing of the second computing device 124.

The second computing device 124 is a computing device which is to be diagnosed using the first computing device 121. The second computing device 124 may comprise one or more memories. While the first computing device 121 may be actively operated by a user or an operator, the second computing device 124 may be configured only (or at least for the most part) to receive user inputs via the first computing device 121 (that is, not via any possible user input devices of the second computing devices 124) during the processes according to some embodi ments to be discussed in the following. In some embodiments, some of the diagnos tic tests may require input from the user directly via a user input device of the sec ond computing device 124 (e.g., testing operation of a push-button, a touch sensor, a fingerprint sensor, a speaker or a screen).

Each of the first and the second computing device 121, 124 refer to a portable or non-portable computing device (equipment, apparatus). Computing devices which may be employed include wireless mobile communication devices operating with or without a subscriber identification module (SIM) in hardware or in software, including, but not limited to, the following types of devices: desktop computer, laptop, touch screen computer, mobile phone, smartphone, personal digital assistant (PDA), handset, e-reading device, tablet, game console, note-book, multimedia device, sensor, actuator, video camera, car, wearable computer, telem etry appliances, and telemonitoring appliances. The first and second computing de vices 121, 124 may be computing device of the same type or of a different type. In a typical non-limiting embodiment, the first computing device 121 may be a desk top computer or a laptop and the second computing device 124 may be a mobile device (e.g., a smartphone, a tablet computer or a laptop). In general, the second computing device 124 may be any computing device which may be electrically con nected to the first computing device 121.

The second computing device 124 may comprise a plurality of different components (or parts) operation of which may be diagnosed. For example, said plurality of components may comprise one or more components of one or more of the following types or categories: a touch sensor, a speaker, a screen, a connector, a proximity sensor, a microphone, a light (e.g., a LED light), a heartbeat monitor, a headphone jack, a headset, a front camera, a back camera, a push-button, a finger print sensor, a near-field communication (NFC) component, a receiving speaker, a battery, a temperature sensor, a barometer, a vibrator motor, a compass, a camera flash, an autofocus, an auto rotation sensor and an infrared sensor. The plurality of components may comprise one or more components of the same type. Each diag nostic test may diagnose operation of a single component or multiple components of the same and/or different category simultaneously.

In some embodiments, the first computing device 121 and the second computing device 124 may be parts of a single apparatus or the second computing device 124 may be comprised within the first computing device 121. In other words, the first and second computing devices may be fixed together (as opposed to being easily detachable from each other as discussed earlier). For example, the second computing device 124 may correspond to a memory or a storage device of the first computing device 121.

The communications network 110 may comprise one or more wireless networks, wherein a wireless network may be based on any mobile system, such as GSM, GPRS, LTE, 4G, 5G and beyond, and a wireless local area network, such as Wi-Fi. Furthermore, the communications network 110 may comprise one or more fixed networks and/or the Internet.

The remote computing system 101 is a device configured to receive in formation (e.g., device information, such as one or more device parameters, char acterizing the computing device) regarding second computing devices 124 from first computing devices 121 connected to it via the communications network 110, analyze the received information and send analysis results (e.g., predicted diagno sis results and/or other diagnostic guidance information) to the first computing devices 121 via the communications network 110. The analysis may be carried out specifically by a diagnostic analysis unit or apparatus of the remote computing sys tem (not shown in Figure 1) and/or may be based on information stored to a diag nostic report database 103 connected to or comprised in the remote computing system. The diagnostic report database 103 may comprise at least a plurality of diagnostic reports describing results of diagnostic tests performed by first compu ting devices (i.e., by the first computing device 121 and/or other corresponding devices) on second computing devices (i.e., on the second computing device 124 and/or other corresponding devices), to be described in detail in relation to further embodiments.

The other diagnostic guidance information sent to the first computing devices 121 by the remote computing system 101 may comprise, for example, in formation on the second computing device 124 maintained in the diagnostic report database of the remote computing system 101. Such information may relate, for example, to errors or warnings given by the second computing device 124 (or spe cifically, by a dedicated user application running on the second computing device 124) during its operation. In addition to or alternatively, the other diagnostics in formation may comprise nominal or reference values indicated by the manufac turer of the second computing device and/or further statistical information on the diagnostic tests performed on the plurality of computing devices.

The remote computing system 101 may be equally called a remote server or a server as seen by the first computing device 121. In other words, the first computing device 121 and the remote computing system may be seen as form ing a client-server relationship. Similarly, the first computing device 121 may be equally called a local client or a client.

According to an embodiment, the first computing device 121 is con nected to multiple second computing devices 124 via USB (Universal Serial Bus) interface 126 using a USB hub. This embodiment provides the advantage that the number of USB ports in the first computing device may be fewer than the number of second computing devices handled by the first computing device. According to an embodiment, the USB hub is a 10-port USB hub.

The remote computing system 101 may be fully or partly cloud-based, that is, the remote computing system 101 may be or comprise at least one compu ting cloud. Specifically, the diagnostic analysis unit and/or the diagnostic report database may be cloud-based.

The embodiments to be discussed below seek to facilitate and/or expe dite the process of diagnosing a computing device (e.g., the second computing de vice 124 of Figure 1). The computing device to be diagnosed may specifically be a mobile (computing) device such as a smartphone or a tablet computer, though the embodiments are not limited to mobile devices. A conventional mobile device such as a smartphone or a tablet computer comprises a large number of components (e.g., a front and/or back camera, a screen and a touch sensor) which may become faulty during the lifetime of the mobile computing device. Different diagnostic tests may be performed on the mobile device to determine whether one or more com ponents of the mobile computing device are working correctly. In order to fully di agnose a computing device, a large number of different diagnostic tests may have to be performed which may take a considerable amount of time. It would be advan tageous if the amount of time required for the diagnosing a single mobile device could be reduced without considerably compromising the quality of the diagnosis (i.e., without causing component faults to be missed). The likelihood of a particular component becoming faulty differs depending at least on the type of the compo nent and the age of the mobile device. For example, for a mobile device which is at least one year old, the probability that the screen is not working correctly may be relatively high while the probability that there is a problem with the microphone may be almost zero. Thus, in diagnosing the mobile device the performing of the diagnostic test for diagnosing the status or condition of the screen should be prior itized over the performing of the diagnostic test for diagnosing the status or condi tion of the microphone. In other words, the diagnostic test for the microphone may be skipped with relative safety while the diagnostic test for the screen should prob ably not be skipped. However, while this principle may apply in most cases, the microphone in a mobile device of a particular model may be known to be consider ably more likely to fail than most microphones and thus the diagnostic test for the microphone should be performed on that particular model. It would require a huge amount of effort from a user to keep track of all the various factors effecting the fault probabilities of each component of each device so as to make informed deci sions regarding which diagnostic tests should be performed on a particular mobile device. The embodiments facilitate this decision-making by providing relevant sta tistical information regarding the mobile device and its fault probabilities.

Figure 2 illustrates signaling, according to embodiments for providing a user with information on predicted results for at least one diagnostic test to be performed on a second computing device and performing the diagnosing using a first computing device. The illustrated processes may be carried out using a system 101 of Figure 1. While the illustrated process (and also the following illustrated processes) are discussed for a first computing device acting on a single second com puting device, in other embodiments multiple second computing devices may be handled by the first computing device in a similar manner simultaneously (i.e., in parallel).

Referring to Figure 2, it is initially assumed that the remote computing system maintains, in block 201, in a diagnostic report database a plurality of diag nostic reports on a plurality of computing devices. Each diagnostic report com prises results of one or more diagnostic tests performed on a computing device of the plurality of computing devices and a set of one or more device parameters char acterizing said computing device. Said results of one or more diagnostic tests per formed on a computing device of the plurality of computing devices may comprise at least information on one or more diagnostic tests (or processes) performed on a particular computing device and on the outcome (or diagnosis) of each of said one or more diagnostic tests. The information on the outcome of a diagnostic test may at least indicate whether or not the diagnostic test gave a positive or negative diag nosis (i.e., indicated correct operation or a failure of the relevant component or components of the computing device). In some embodiments, the information on the outcome of a diagnostic test may also provide further information on the de tected failure (e.g., in the form of an error code) and/or a duration of the diagnostic test. One or more diagnostic reports may be maintained for each of the plurality of computing devices. The set of one or more device parameters for a given computing device may comprise, for example, one or more of a manufacturer, a model, a year or date of manufacture, International Mobile Equipment Identity (IMEI) or other a device identifier, hardware information (e.g., component information), type and/or capacity of at least one memory, operating system, at least a part of a log history of the computing device and/or the age of the computing device. A more comprehen sive list of possible device parameters is provided after the discussion on Figure 2.

The process for guiding a user in selecting diagnostic test(s) for diag nosing a second computing device starts when a first computing device retrieves, in messages 202, a first set of one or more device parameters characterizing the second computing device electrically connected to the first computing device from a memory of the second computing device. The retrieving in messages 202 may be initiated in response to establishing a connection between the first and second computing devices (e.g., in response to connecting the two devices with a USB cable or some other cable). According to an embodiment, in addition to retrieving one or more device parameters from a memory of the second computing device, the first computing device also retrieves one or more further device parameters from a re mote computing system, where these parameters are maintained in a database. Ac cording to an embodiment, said further device parameters are maintained in the same remote computing system where diagnostic reports are maintained in the di agnostic report database.

The one or more device parameters in the first set may be defined as described above in relation to the contents of a diagnostic report. The retrieving may specifically comprise sending, by the first computing device, a request for de vice parameters to the second computing device and in response to receiving the request in the second computing device, retrieving, by the second computing de vice, the first set of one or more device parameters from a memory of the second computing device and sending them from the second computing device to the first computing device. After the retrieving, in messages 202, the first computing device sends, in message 203, the first set of one or more device parameters (or at least a subset therein) characterizing the second computing device via a communications network to a remote computing system. The first set of one or more device param eters may be sent within a separate request for predicting results of one or more diagnostic tests for the second computing device or as a part of regular reporting operation of the first computing device. In some alternative embodiments, the sec ond computing device may send one or more of its own device parameters (via the communications network) to the remote computing system. In some embodi ments, the retrieving in block 202 may be initiated automatically in response to the second computing device being electrically connected to the first computing de vice.

In response to receiving, in block 204, a first set of one or more device parameters characterizing (or defining) the second computing device from the first computing device via the communications network, the remote computing system compares, in block 204, the first set of one or more device parameters to the plu rality of sets of device parameters comprised in the plurality of diagnostic reports maintained in the diagnostic report database. Specifically, the remote computing system may compare the first set to each of the plurality of sets to find one or more diagnostic reports relevant for the second computing device. The diagnostic re ports with matching device parameters are considered relevant (or applicable or pertinent) for the second computing device as they correspond to the same or sim ilar computing devices as the second computing device. Thus, the comparing may comprise searching for matches for the one or more device parameters in the first set from the plurality of diagnostic reports, where the matches may be required to be full matches and/or close or partial matches (e.g., at least some device parame ters given in a diagnostic report match the one or more device parameters in the first set or a full set of device parameters given in a diagnostic report is correlated with the first set of one or more device parameters to a certain degree). A different importance or weight may be applied for each device parameter in the comparing. For example, an acceptable partial match for a second computing device being a smartphone could be a smartphone of the same model and the same age within one year but having a processor of higher clock rate. In other words, larger weights may applied, in the comparing, for device parameters of a model of the computing de vice and the age of the computing device while a smaller weight may be applied to a device parameter of a processor clock rate. The comparing procedure according to an embodiment is to be described in more detail in connection with Figure 3.

Based on the comparing in block 204 or more specifically on results of the one or more relevant diagnostic reports, the remote computing system pre dicts, in block 205, results of one or more diagnostic tests when performed on the second computing device based on results of one or more diagnostic tests in the one or more relevant diagnostic reports by using statistical analysis. The predicting may comprise evaluating at least a predicted probability of a positive (i.e., favour able) diagnosis for each of the one or more diagnostic tests when performed on the second computing device (i.e., probability for each diagnostic test failing to indicate a fault, defect or breakage in corresponding component(s) of the second computing device). If the one or more relevant diagnostic reports comprise not only diagnostic reports relating to fully matching computing devices but also one or more compu ting devices matching the second computing device only partially, the extent of the mismatch may be taken into account in the predicting. For example, the fully or highly matching diagnostic reports may be weighted in the predicting relative to the moderately well matching diagnostic reports.

In general, the predicted results of one or more diagnostic tests when performed on the second computing device may comprise, for each diagnostic test, one or more statistical metrics derived from the results of the diagnostic tests. Said one or more statistical metrics may comprise, for example, said predicted proba bility of a positive diagnosis and one or more related uncertainty metrics (e.g., the number of diagnostic reports on which the prediction is based).

In some embodiments, the remote computing system predicts, in block 205, one or more components of the second computing device which are most likely to be defective based on the one or more relevant diagnostic reports. This prediction may be based on the aforementioned predicted probability of a positive diagnosis for one or more diagnostic tests as each diagnostic test may provide in formation regarding the functioning of a specific component or a specific group of components. The one or more components considered to be typically defective may be defined so as to comprise a pre-defined number of components or to comprise all components for which at least one diagnostic test is predicted to provide a pos itive diagnosis with a predicted probability which falls below a pre-defined thresh old.

Modern mobile devices may comprise a group of components of the same type, such as multiple microphones and/or multiple loudspeakers, for exam ple. According to an embodiment, a diagnostic test on loudspeakers provides infor mation regarding the functioning of the whole group of loudspeakers or a sub group therein. For example, the diagnostic test may provide information regarding the functioning of all loudspeakers, only those loudspeakers that produce audible sound or only those loudspeakers that function ("in reverse") as microphones. Ac cording to an embodiment, a diagnostic test provides information regarding the functioning of a specific loudspeaker. For example, the diagnostic test may provide information regarding the functioning of the front speaker designed to convert an electrical signal into an audible sound during a phone call.

Once the remote computing system has performed the predicting in block 205, it sends, in message 206, results of the predicting to the first computing device via the communications network for guiding a user of the first computing device in selecting suitable diagnostic tests for diagnosing the second computing device. The results of the predicting may comprise at least information on a pre dicted probability of a positive diagnosis for each of the one or more diagnostic tests when performed on the second computing device and/or information on one or more likely defective components of the second computing device. The results of the predicting may further comprise any of the information used for predicting the probabilities and information on how reliable each probability prediction is (e.g., how many diagnostic reports were considered relevant and were thus used for the prediction). In some embodiments, the results of the predicting sent to the first computing device may comprise a recommendation regarding whether a par ticular diagnostic test should be performed. Such a recommendation may be in cluded in the information sent to the first computing device, for example, if a prob ability of a positive diagnosis for a diagnostic test is below a pre-defined threshold.

In some embodiments, a probability of a negative diagnosis (i.e., a fail ure rate) may be calculated (in block 205) and sent to the first computing device (in block 206), instead of a probability of a positive diagnosis (i.e., a success rate).

The first computing device receives, in block 207, at least the results of the predicting (and possibly other diagnostic guidance information) and subse quently (or consequently) displays, in block 207, said information to a user via a display of the first computing device. By providing the results of the predicting re garding one or more diagnostic tests to the first computing device and displaying them to the user of the first computing device, the decision making regarding which diagnostic tests (if any) to perform for diagnosing the second computing device us ing the first computing device is facilitated. Specifically, based on the displayed in formation the user may determine which diagnostic tests are unlikely to give a neg ative diagnosis taking into account various properties of the second computing de vice (i.e., device parameters) and may thus be skipped with relative safety if time for performing the diagnostics is limited.

In response to receiving a user input confirming a selection of one or more diagnostic tests via a user input device of the first computing device, the first computing device causes, in messages 209, performing of the one or more selected diagnostic tests for diagnosing the second computing device.

In some embodiments, the one or more selected diagnostic tests (or at least one of them) may be performed, in messages 209, as follows. The first com puting device, first, generates a diagnostic test program (or simply instructions) for performing at least one diagnostic test by the second computing device and report ing results of said at least one diagnostic test back to the first computing device. Then, the first computing device sends said diagnostic test program to the second computing device. No particular diagnostics software needs to be pre-installed in the second computing device. In response to receiving said diagnostic test pro gram, the second computing device executes the diagnostic test program. The exe cution of the diagnostic test program may be fully automatic or it may require user input via a user input device (e.g., a touchscreen, a push-button or an acceleration sensor) of the second computing device at one or more stages. For example, if the diagnostic test program pertains to diagnosing a speaker, the second computing device may prompt the user to confirm that a reference sound is heard when said sound is played. To give another example, diagnosing a push-button of the second computing device (e.g., a Home key) may require the user to push said push-button. The diagnostic test program instructs the second computing device to transmit the results of the at least one diagnostic test defined by the diagnostic test program to the first computing device. According to the diagnostic test program, the results may be sent automatically after the completion of said at least one diagnostic test. Alternatively, the user may be, first, prompted by the second computing device to approve the sending and the results may be sent only in response to the user providing their approval via a user input device of the second computing device. In some embodiments, a separate diagnostic test program may be generated for each diagnostic test while in other embodiments all of the one or more selected diagnos tic test may be covered by a single diagnostic test program.

In some alternative embodiments, the selecting of one or more diagnos tic tests and performing said one or more diagnostic tests may be performed auto matically based on information received in block 207 (e.g., on success rates of dif ferent diagnostic tests). In such embodiments, at least block 208 is, thus, omitted.

The processes according to embodiments provide the advantage that since device-specific information on predicted results of one or more diagnostic tests (and possibly other diagnostic guidance information) are provided to the user of the first computing device, the user of the first computing device is capable of making more informed and expedient decisions regarding the selection of the di agnostic tests since the decision on the diagnostic test selection does not depend solely on the expertise of the user. If no device-specific information on predicted results of one or more diagnostic tests would be available for the user of the first computing device, the user would likely have to perform each available diagnostic test for the second computing device in order not to risk missing a fault in any com ponent of the second computing device due to skipping the performing of a vitally important diagnostic test. In other words, the embodiments enable time-saving in performing diagnostic testing in a way which minimizes the chances for a missed negative diagnosis.

In some embodiments, the one or more device parameters retrieved by the first computing device and/or comprised in each diagnostic report may com prise one or more of the following hardware-related pieces of information regard ing the device in question: a name of the manufacturer, a name, a model, a year or date of manufacture, an identifier for the device, 1ME1, a serial number, an internal model, a chassis type, a rooting (e.g., rooted/not rooted), a (clock) speed of the pro cessor of the computing device, a manufacturer of the processor of the computing device, a model of the processor of the computing device, information on at least some of one or more memories of the computing device and at least a part of a log history of the computing device.

The information regarding the chassis type of the computing device in cluded in the one or more device parameters may comprise, for example, infor mation on a form factor of the chassis, a material of the chassis and/or a manufac turer of the chassis. According to an embodiment, the information regarding the chassis type indicates whether the chassis is made partially or wholly of plastic or metal. According to an embodiment, the information regarding the chassis type in dicates whether the chassis is reinforced with an extra cover, protective layer, coat ing or surface treatment.

The information on at least some of one or more memories of the com puting device may comprise, for example, a name for each or some of one or more memories of the device, capacity for each or some of said one or more memories (given, e.g., in megabytes), type of each or some of said one or more memories, a serial number for each or some of said one or more memories, a vendor for each or some of said one or more memories and/or condition monitoring information from said one or more memories. According to an embodiment, the condition monitor ing information may comprise indicators detected by the in-built S.M.A.R.T. (Self- Monitoring, Analysis and Reporting Technology) system of a hard disk drive (HDDs), solid-state drive (SSDs) or embedded Multi-Media Controller (eMMC) drive of the computing device. According to an embodiment, the condition moni toring information may comprise information on the number or percentage of bad memory units (blocks or sectors) in said one or more memories.

In some embodiments, the one or more device parameters retrieved by the first computing device and/or comprised in each diagnostic report may further comprise one or more of the following software-related pieces of information re garding the device in question: a name of the operating system, a version of the operating system, a software used for performing the diagnostic test(s), a version of said software used for performing the diagnostic test(s) and a source or vendor of said software used for performing the diagnostic test(s).

In some embodiments, the one or more device parameters retrieved by the first computing device and/or comprised in each diagnostic report may com prise the age of the computing device and/or the effective age of the computing device (evaluated, for example, based on the at least a part of the log history of the computing device or capacity deterioration of a battery of the computing device). Obviously, an almost new smartphone (or other computing device) is much less unlikely to be faulty than a three-year-old identical smartphone. Therefore, the (ef fective) age of the computing device may be a very significant factor in determining the one or more relevant diagnostic report (in block 204) and in predicting the re sults of the one or more diagnostic tests (in block 205). In general, the effective age may be defined as a metric quantifying the amount of deterioration in the perfor mance of the computing device (compared to optimal performance of a new com puting device). The effective age may be indicative of how heavily said computing device has been used during its lifetime. The age and/or effective age may be given in years, months or days and possibly as a non-negative integer.

The one or more device parameters retrieved by the first computing de vice and/or comprised in each diagnostic report may, also or alternatively, com prise information on use history of the computing device. According to an embod iment, the information on use history of the computing device is comprised in the at least a part of the log history of the computing device. For example, the use his tory may reveal how actively and for what types of tasks the computing device has been used. This information may be important as a smartphone used solely for oc casional phone calls is likely to be less prone to breakage compared to a smartphone used extensively for a variety of demanding tasks such as playing mu sic, video chats, setting up a mobile access point and augmented reality -based gam ing. Such a difference in usage history would likely be visible also as a difference in the effective ages of the computing devices.

According to an embodiment, said at least a part of the log history is at least a part of a memory log, a log of applications installed on the computing device, a battery charging log and/or a battery temperature log. According to an embodi ment, the memory log comprises information on the number or percentage of bad memory units (blocks or sectors) in one or more memories of the computing de vice. According to an embodiment, the battery charging log comprises information on how many times the battery of the mobile device has been charged and/or dis charged. According to an embodiment, the battery temperature log comprises in formation on the maximum and the minimum temperatures the battery has been exposed to and the duration of the exposure.

Figure 3 illustrates a process performed by a remote computing system according to an embodiment for providing a user with information on predicted results of one or more diagnostic tests for a second computing device. The illus trated process is an alternative to the process carried out by the remote computing system in blocks 201, 204, 205 and message 206 of Figure 2. The illustrated process may be carried out by the remote computing system 101 of Figure 1. Unless other wise stated, the definitions given in relation previous embodiments may apply also here.

Similar to Figure 2, it is initially assumed in block 301 that the remote computing system maintains a plurality of diagnostic reports in a diagnostic report database. The remote computing system receives, in block 302, information on a first set of one or more device parameters characterizing a second computing de vice from a first computing device via a communications network. Blocks 301, 302 may correspond to blocks 201, 204 ("receive" only) of Figure 2.

In the embodiment illustrated in Figure 3, the comparing described in relation to block 204 of Figure 2 is divided into blocks 303 to 307. In a pre-pro cessing phase, the remote computing system identifies, in block 303, a device cate gory of the second computing device based on the one or more device parameters received from the first computing device. The device category may be one of the device parameters or it may be identified based on the one or more device param eters. The available device categories may comprise, for example, a mobile phone (or a smartphone), a tablet computer, a desktop computer, a laptop, a mass media storage, a smart watch, a digital still camera, a digital video camera, a mobile Inter net device, a personal digital assistant (PDA), a handheld game console, a calculator and a personal navigation device or any subset of said categories. In one embodi ment, the available device categories are a mobile device, a desktop computer and a laptop.

In some embodiments, the device categories may be defined in a more limited manner. For example, the device categories may be specific to a certain manufacturer, that is, a Samsung smartphone and Apple smartphone may be de fined to be different device categories. Similar limitation based on some other de vice parameter (e.g., memory type or operating system) may be applied in other embodiments.

The remote computing system generates, in block 304, a vector based on at least one of the one or more device parameters in the first set and the identi fied device category. Specifically, a particular subset of one or more device param eters from the first set are selected as element(s) of the vector based on the identi fied device category. Each element of each vector may have a numerical value cor responding (or mapping) to a particular feature or features of the second compu ting device. Said at least one of the one or more device parameters based on which the vector is generated may comprise only device parameters which are consid ered relevant or significant for diagnosing the second computing device belonging to the identified device category. Each element of a vector may correspond directly to a device parameter or it may be generated based on one or more device param eters (e.g., if the device parameter does not have a numeric value and/or if multiple device parameters are used for generating the element).

To give a simplistic example, the vector for a smartphone may comprise three values describing manufacturer, model and capacity of memory. If the second computing device is, for example, Apple iPhone 8 with 64 GB of memory, the vector generated for the second computing device may be [1 1 1]. In other words, "Apple" may map to a numerical value of one for the first element of the vector, "iPhone 8" may map to a numerical value of one for the second element of the vector and "64 GB" may map to a numeric value of one for the third element of the vector. In this system, the vector [1 1 2] may correspond, for example, to Apple iPhone 8 128 GB and the vector [1 2 2] may correspond, for example, to Apple iPhone 9 128 GB.

The remote computing system compares, in block 305, the vector asso ciated with the second computing device to one or more corresponding vectors which were generated for one or more computing devices of the plurality of com puting devices based on one or more sets of one or more device parameters in the plurality of diagnostic reports. Here, said one or more computing devices may be specifically computing devices of the same device category as the second compu ting device. The one or more corresponding vectors may be generated after (or simultaneously with) the generation of the vector for the second computing device. Alternatively, each of the one or more corresponding vectors may have been gen erated earlier (i.e., before the performing of the process of Figure 3), for example, when a diagnostic report on that particular computing device was received by the remote computing system. The generated vectors may be maintained in the diag nostic report database.

In some embodiments, the comparing in block 305 may specifically comprise calculating, for the vector of the second computing device, a value of a distance metric quantifying the difference (or distance) between the vector of the second computing device and corresponding one or more vectors of other compu ting devices (of the same device category). The distance metric may be the Euclid ean distance d which may be calculated using the equation d = ,

where / is the index, n is the number of elements in each vector, q = [q _± q ₂ — q _n ] is the vector of one of the one or more computing devices associated with the plural ity of diagnostic reports and p = [p ₁ p ₂ ... p _n ] is the vector of the second computing device. Instead of the Euclidean distance, the difference between two vectors may be quantified using another (distance) metric. For example, a weighted Euclidean distance may be employed. The weighted Euclidean distance d _w may be defined using the equation d _w ,

N

where w _£ are weighting factors which may be defined independently for each vec tor element (i.e., for each index /). Referring to the above example with a three- element vector, the manufacturer (i.e., the first element) may, for example, have the largest weighting factor and the capacity of the memory (i.e., the third element) may have the smallest weighting factor. In some other embodiments, standardized Euclidean distance may be employed as the distance metric.

In some embodiments, the vector generation in block 304 may not de pend on the identified device category, but the comparing in block 305 may so that said comparing is carried out only for one or more computing devices of the iden tified device category.

Based on the comparing in block 305, the remote computing system de termines, in block 306, whether one or more of the one or more vectors associated with the same device category as the second computing device match the vector of the second computing device according to pre-defined criteria. Specifically, the pre-defined criteria may define that a value of the distance metric between the vec tor of the second computing device and the matching vector should be below a pre defined (upper) threshold.

If no matches are found in block 306, the remote computing system may send, in block 310, information on the failure to predict results of any diagnostic tests to the first computing device via the communications network. In some em bodiments, block 310 may be omitted.

If one or more matches according to pre-defined criteria is found in block 306, the remote computing system selects, in block 307, one or more diag nostic reports associated with said one or more matching vectors (matching the vector of the second computing device) as a classification cluster for the second computing device. In some embodiments, the classification cluster may be defined separately for each diagnostic test. The classification cluster represents a set of di agnostic reports whose relevant device parameters match the corresponding de vice parameters of the second computing device to a sufficiently high degree. The classification cluster(s) may correspond to the one or more relevant diagnostic re ports as discussed in relation to block 204 of Figure 2.

The remote computing system predicts, in block 308, results of one or more diagnostic tests for the second computing device based on the one or more diagnostic reports in the classification cluster by using statistical analysis. The pre dicting may be performed similar to as described in relation to Figure 2 with the difference that, in this case, the predicting in block 308 is limited to the classifica tion cluster and may be based on, alternative or in addition to the diagnostic infor mation comprised in each relevant diagnostic report, to vectors associated with the classification cluster.

Also similar to the embodiment of Figure 2, once the remote computing system has performed the predicting of the results of one or more diagnostic tests for the second computing device in block 308, it sends, in message 309, information on the results of the predicting (e.g., the probabilities for a negative or positive di agnosis for each diagnostic test and/or information on one or more components most likely to be defective) to the first computing device via the communications network.

In some embodiments, the pre-processing described in relation to block 303 (i.e., identifying the device category) may be omitted. Subsequent analysis in blocks 306 to 309 may, in those cases, be carried out irrespective of the device cat egories associated with the second computing device and the plurality of diagnostic reports. In other words, instead of analyzing only diagnostic reports corresponding to the same device category (e.g., a smartphone) as the second computing device, all of the plurality of diagnostic reports (and corresponding vectors) may be in volved in blocks 306 to 309.

Figure 4 illustrates another alternative process for providing a user with information on predicted results of one or more diagnostic tests for a second computing device. The illustrated process is an alternative to the process carried out by the remote computing system in blocks 201, 204, 205 and message 206 of Figure 2 and to the process of Figure 3. The illustrated process may be carried out by the remote computing system 101 of Figure 1. Unless otherwise stated, the def initions given in relation previous embodiments may apply also here.

Referring to Figure 4, the initial blocks 401, 402 may correspond to blocks 301, 302 of Figure 3 and are thus not discussed here for brevity. In response to a first set of one or more device parameters having been received in block 402, the remote computing system determines, in block 403, for each of one or more components of the second computing device, a second set of one or more compo nent-specific device parameters based on the first set of one or more device param eters received from the first computing device. Each second set may be a subset of the first set. The one or more component-specific device parameters in each second set may comprise, for example, a manufacturer of the component and/or a model of the component. Moreover, the one or more component-specific device parame ters in each second set may comprise one or more component-specific device pa rameters which depend on the type of the component. For example, if the compo nent in question is a front or back camera, the one or more component-specific de vice parameters in the corresponding second set may comprise resolution of the camera and/or support (or lack thereof) for Optical Image Stabilization (01S) or simply a manufacturer of the camera. As another example, if the component in question is a mass media drive (e.g. HDD or SSD), the one or more component-spe cific device parameters may comprise support for a S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) monitoring system. Some device parameters (e.g., age and/or an effective age of the first computing device given in full years) may be included in all or most of the second sets of component-specific device pa rameters.

Then, the remote computing system searches, in block 404, for matches for one or more second sets of one or more component-specific device parameters from diagnostic report database. This search for a particular component defined through a second set of one or more component specific parameters may ignore all other features or properties of the computing device such as device category. Therefore, the matches for a second set of one or more component-specific device parameters (e.g., manufacturer and age) defining a back camera of a smartphone may comprise, for example, one or more diagnostic reports associated with smartphones with the same or similar back cameras and/or one or more diagnostic reports associated with tablet computers with the same or similar back cameras. The matches may be required to be full matches and/or close or partial matches. A different importance or weight may be applied for each device parameter in each second set.

If at least one match for at least one second set of one or more compo nent-specific device parameters is found in block 405, the remote computing sys tem selects, in block 406, for each second set of one or more component-specific device parameters for which at least one match was found, one or more diagnostic reports associated with the one or more corresponding matches as a component- specific classification cluster for said component. Subsequently, the remote com puting system predicts, in block 407, the results of one or more diagnostic test(s) based on one or more component-specific classification clusters. Apart from the component-specific definition for the classification cluster, the predicting may be carried out as described in relation to block 309 of Figure 3. Furthermore, actions pertaining to blocks 408, 409 may correspond to actions described in relation to blocks 309, 310 of Figure 3.

Figure 5 illustrates another process for providing a user with infor mation on predicted results of one or more diagnostic tests for a second computing device where the predicting is performed not only on a device level but on a com ponent level, similar to Figure 4. In contrast to Figure 4, the process of Figure 5 employs also the idea of generating vectors similar to Figure 3. The process of Fig ure 5 may, thus, be considered a combination of embodiments illustrated in Figures 3 and 4. The illustrated process is an alternative to the process carried out by the remote computing system in blocks 201, 204, 205 and message 206 of Figure 2 and to the process of Figure 3. The illustrated process may be carried out by the remote computing system 101 of Figure 1. Unless otherwise stated, the definitions given in relation previous embodiments may apply also here.

Referring to Figure 5, the initial blocks 501, 502 may correspond to blocks 301, 302 of Figure 3 and are thus not discussed here for brevity. The basic idea of the process of Figure 5 is to apply the process of Figure 3 on a component level (as opposed to on a device level). Therefore, in response to a first set of one or more device parameters having been received in block 502, the remote compu ting system identifies, in block 503, a component category (e.g., a screen, a back camera or a touch sensor) of each of one or more components of the second com puting device based on the first set of one or more device parameters. Thereafter, the remote computing system generates, in block 504, a component-specific vector for each of said one or more components based on the first set of one or more de vice parameters and the one or more identified component categories. Each ele ment of each component-specific vector may have a numerical value correspond ing (or mapping) to a particular feature or features of a particular component of the second computing device. Said at least one of the one or more device parame ters based on which the component-specific vector is generated may comprise only device parameters which are considered relevant or significant for diagnosing that particular component of the second computing device. Each element of a compo nent-specific vector may correspond directly to a device parameter or it may be generated based on one or more device parameters (e.g., if the device parameter does not have a numeric value and/or if multiple device parameters are used for generating the element). Some device parameters (e.g., age and/or effective of the second computing device) may be included in all or most of generated one or more component-specific vectors.

The remote computing system compares, in block 505, the one or more component-specific vectors of the second computing device to one or more corre sponding component-specific vectors which were generated for one or more com ponents of one or more computing devices of the plurality of computing devices based on one or more sets of one or more device parameters in the plurality of diagnostic reports. Said one or more corresponding component-specific vectors may have been generated previously (before the performing of the process of Fig ure 5) and stored to the diagnostic report database. Alternatively, said one or more corresponding component-specific vectors may be generated between blocks 504 and 505 of Figure 5 based on the plurality of diagnostic reports (or specifically, the drive parameters stored therein). The comparing may be carried out using a dis tance metric, similar to as described in relation to block 305 of Figure 3 (though in this case the distance metric is defined for each component). Thus, in contrast to step 404 of Figure 4, the component-specific comparing in block 505 may not only consider computing devices which are exact matches for one or more specific de vice parameters of the second computing device but also computing devices which are sufficiently similar (with regard to a particular component) to the second com puting device.

Based on the comparing in block 505, the remote computing system de termines, in block 506, whether one or more of the one or more component-spe cific vectors generated for the one or more computing devices match the one or more component-specific vectors of the second computing device according to pre defined criteria. Similar to Figure 3, the pre-defined criteria may define that a value of the distance metric between each component-specific vector of the second com puting device and the matching component-specific vector should be below a pre defined (upper) threshold. To give a practical example, this may mean, for example, that, in comparing vectors characterizing cameras of computing devices, not only back cameras having exactly the same specifications are considered matches but also any back cameras (or even any front or back cameras) with the same manu facturer (associated with a large weighting factor) and sufficiently similar specifi cations such as resolution (associated with smaller weighting factors).

If no matches for any component of the second computing device are found in block 506, the remote computing system may send, in block 510, infor mation on the failure to predict results of any diagnostic tests to the first computing device via the communications network. In some embodiments, block 510 may be omitted.

If at least one match for at least one component of the second computing device is found in block 506, the remote computing system performs processes of blocks 507 to 509 which may correspond to blocks 406 to 408 of Figure 4.

Figure 6 illustrates a process performed by a first computing device ac cording to an embodiment for diagnosing a second computing device electrically connected to the first computing device guided by information on predicted results of one or more diagnostic tests provided by a remote computing device. The illus trated process is an alternative to the process carried out by the first computing device in messages 202, 203, 209 and blocks 207, 208 of Figure 2. The illustrated process may be carried out by the first computing device 121 of Figure 1. Unless otherwise stated, the definitions given in relation previous embodiments may ap ply also here.

Referring to Figure 6, the illustrated process corresponds in many as pects to the processes performed by the first computing device in Figure 1. Actions pertaining to blocks 601, 602 may be carried out as described in relation to mes sages 202, 203 of Figure 2. In response to receiving results of the predicting of one or more diagnostic tests (and possibly other diagnostic guidance information) for diagnosing the second computing device from the remote computing system via the communications network in block 603, the first computing device displays, in block 610, information on the received information to a user via a display of the first computing device. The received information (or at least some of it) may also be stored to a database connected to or comprised in the first computing device. The results of the predicting may be defined as described in relation to Figure 2. In response to receiving information on a failure to predict results of any diagnostic tests in block 604, the first computing device displays, in block 605, information on the failure to the user via the display of the first computing device. If neither infor mation is received in blocks 603, 604 (e.g., within a pre-defined time limit), the process may proceed directly to block 606 skipping block 605/610 (i.e., the dis playing).

In response to receiving a user input confirming a selection of one or more diagnostic tests via a user input device of the first computing device in block 606, the first computing device causes, in block 607, performing of the selected di agnostic tests on the second computing device. Block 607 may be performed as de scribed in relation to messages 209 of Figure 2. The first computing device may also record (or store), in block 607, the results of each diagnostic test. In the ideal case, the user may make the selection regarding the diagnostic tests guided by pre dicted results (e.g., probability of a negative or positive diagnosis) for at least one diagnostic test. However, if no prediction results were received in block 603, the user may have to make the selection based purely on his/her own expertise. The user may also be allowed to make the selection of the diagnostic test(s) and initiate the diagnostic test(s) without having to wait for reception of any (possible) predic tion results.

In response to the one or more selected diagnostic tests concluding, the first computing device generates, in block 608, a diagnostic report on the one or more diagnostic tests which were performed on the second computing device. The diagnostic report may be defined as described above in relation to Figure 2, that is, it may comprise at least the one or more device parameters of the second compu ting device and results of the one or more diagnostic tests. The results of each di agnostic test may comprise at least information on the outcome or diagnosis (i.e., the component is working correctly or the component has failed or is not working correctly) of the diagnostic test. The first computing device may include in the di agnostic report, in addition to the information on the outcome or diagnosis of the diagnostic test, one or more further diagnostic test properties such as the duration of the diagnostic test and/or at least some of the raw data generated by the diag nostic test.

In some alternative embodiments, the second computing device may generate the diagnostic report based on the one or more diagnostic tests which were performed on the second computing device, instead of the first computing device generating the diagnostic report, and subsequently send the generated di agnostic report to the first computing device.

Finally, the first computing device sends, in block 609, the generated di agnostic report to the remote computing system via the communications network. In some embodiments, the sending in block 609 may be performed only in re sponse to receiving, via a user input device of the first computing device, a user input requesting the sending (or confirming the sending if the user was explicitly prompted to confirm the sending by the second computing device).

Figure 7 illustrates a simple process for maintaining the diagnostic re port database using the remote computing system. The remote computing system may be the remote computing system 101 of Figure 1 and the diagnostic report database may the diagnostic report database 103 of Figure 1. The illustrated pro cess may be carried out in parallel with any of the processes of Figures 2 to 5 per taining to the remote computing system or a part of said processes.

Similar to previous embodiments, it is initially assumed in block 701 the remote computing system maintains a plurality of diagnostic reports in a diagnos tic report database. In response to receiving a diagnostic report on one or more diagnostic tests performed on a second computing device from a first computing device via a communications network in block 702, the remote computing system stores, in block 703, the received diagnostic report to the diagnostic report data base. In some embodiments, the remote computing system may also send an ac knowledgment acknowledging the successful reception of the diagnostic report to the first computing device via the communications network.

In some embodiments, the first computing device may be configured to perform any of the processes described in relation to Figures 2 to 7 simultaneously for multiple second computing devices electrically connected to the first computing device (that is, the same first computing device).

In the following, an exemplary use case for the embodiments from the point of view of an operator of a first computing device is discussed.

1. Raimo, the diagnostic technician, receives a batch of mobile phones which need to be diagnosed for estimating their potential for reuse potential. He sees that the shipment contains dozens of mobile phones with different models from various manufacturers.

2. Raimo takes the shipment next to his diagnostics work station (i.e., a first computing device) with a dedicated mobile device diagnosis application and having access to a cloud-based remote computing system.

3. Raimo starts to plug in (second computing) devices and sees how the devices show up in a user interface on a screen of the diagnostics work sta tion. He sees that each of the connected devices go into preprocessing state.

4. After a short time, Raimo sees how the devices begin to receive the prediction data from the cloud-based remote computing system. He sees (at least) the predicted success rates for each diagnostic test in the user interface.

5. The estimates provided by cloud-based remote computing system look promising, except for one mobile phone. The metrics for that mobile phone show that the failure estimate for the display of the device is exceptionally high.

6. Raimo takes the phone under manual inspection and executes a di- agnostic test for the display. Indeed, the display of the device is not fully func tional. Therefore, he sets the device aside for further processing.

7. The rest of the batch looks promising, so Raimo selects randomly some devices and executes full diagnostics (i.e., a complete set of diagnostic tests) only for those.

8. Everything is fine with those devices, so Raimo is happy to proceed with the batch and moves it forward in the process.

Figure 8 illustrates an apparatus 801 configured to perform the func tions described above in connection with a remote computing system such as re mote computing system 101 shown in Figure 1. The apparatus may be an elec tronic device comprising electronic circuitries. The apparatus may be a separate network entity or a plurality of separate entities. The apparatus may comprise a control circuitry 820, such as at least one processor, and at least one memory 830 including a computer program code (software) 831 wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus to perform any one of the embodi ments of the remote computing system described above. The apparatus may com prise at least one database 832 which may comprise at least the diagnostic report database as described in relation to above embodiments.

The memory 830 may comprise a database 832 which may correspond to the diagnostic report database, as described in previous embodiments. The memory 830 may also comprise other databases which may or may not be related to the described diagnostic test prediction functionalities according to embodi ments.

Referring to Figure 8, the control circuitry 820 may comprise at least diagnostic profiler circuitry 821. The diagnostic profiler circuitry 821 may be con figured, for example, to perform at least some of blocks 201, 204, 205 and mes sage 206 of Figure 2 and/or any of blocks in Figures 3 to 5 and 7.

Figure 9 illustrates an apparatus 901 configured to perform the func tions described above in connection with a first computing device, such as the first computing device 121 of Figure 1. The apparatus may be an electronic device comprising electronic circuitries. The apparatus may be a separate network entity or a plurality of separate entities. The apparatus may comprise a control circuitry 920 such as at least one processor, and at least one memory 930 including a com puter program code (software) 931 wherein the at least one memory and the computer program code (software) are configured, with the at least one proces sor, to cause the apparatus to perform any one of the embodiments of the first computing device described above. The apparatus 901 may comprise, similar to the first computing device 121 of Figure 1, a user input device and/or a display (not shown in Figure 9).

The memory 930 may comprise a database 932 which may comprise, for example, information on one or more device parameters of one or more (sec ond) computing devices electrically connected to the apparatus 901, prediction results received from a remote computing system via a communications network and/or one or more diagnostic reports generated by the apparatus. The memory 930 may also comprise other databases which may or may not be related to the functionalities of the first computing device according to any of presented embod iments.

Referring to Figure 9, the control circuitry 920 may comprise diagnos tic analysis circuitry 921 configured to provide the first computing device func tionalities for retrieving the device parameter(s) of the (second) computing de vice targeted for diagnosis and providing predicted diagnostic results regarding the second computing device to a user based on communication with a remote computing system and generating and sending to the remote computing system diagnostic reports according to any of presented embodiments. The control cir cuitry may further comprise diagnosis circuitry 922 configured to perform the se lected diagnostic test(s). For example, the diagnostic analysis circuitry 921 may be configured to perform at least some of messages 202, 203 and/or blocks 207, 208 of Figure 2 and/or any of blocks of Figure 6 other than block 607. Moreover, the diagnosis circuitry 922 may be configured to perform at least messages 209 of Figure 2 and/or block 607 of Figure 6. In some other embodiments, the control circuitry 920 may be divided into three or more or only a single individual cir cuitry.

The apparatuses 801, 901 described in relation to Figures 8 and 9 may further comprise (communication) interfaces 810, 910 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The communication interface may provide the apparatuses with communication capabilities to communicate via a communica tions network and enable communication, for example, in the case of the appa ratus 801 of Figure 8 with one or more (first) computing devices and in the case of the apparatus 901 of Figure 9 with a remote computing system. In the case of the apparatus 901 of Figure 9, the communication interfaces 910 may provide a connection to one or more second computing devices, for example, using any means discussed in relation to Figure 1.

The communication interfaces 810, 910 may comprise standard well- known components such as an amplifier, filter, frequency-converter, (de) modula tor, and encoder/decoder circuitries and one or more antennas.

The memories 830, 930 of the apparatuses 801, 901 described in rela tion to Figures 8 and 9 may be implemented using any suitable data storage tech nology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of ana log and/or digital hardware circuit(s) with software/firmware and (ii) any por tions of hardware processor(s) with software (including digital signal proces sor^)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a mi- croprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this appli cation, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a base band integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

In an embodiment, at least some of the processes described in connec tion with Figures 2 to 7 may be carried out by an apparatus comprising corre sponding means for performing at least some of the described processes. Some example means for performing the processes may include at least one of the fol lowing: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form (processing) means for or com prise one or more computer program code portions for performing one or more operations according to any one of the embodiments of Figures 2 to 7 or opera tions thereof.

Further regarding the means for performing the processes, the tech niques and methods described herein may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus (es) of embodiments may be implemented within one or more application-specific inte grated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate ar rays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combi nation thereof. For firmware or software, the implementation can be carried out through modules of at least one chipset (procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rear ranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodi ments of the methods described in connection with Figures 2 to 7 may be carried out by executing at least one portion of a computer program comprising corre sponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of car rier, which may be any entity or device capable of carrying the program. For ex ample, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and soft ware distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for performing the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be com bined with other embodiments in various ways.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The inven tion and its embodiments are not limited to the examples described above but may vary within the scope of the claims.