Patent ID: 12212703

DETAILED DESCRIPTION OF THE DRAWINGS

Referring initially toFIG.1A, there is shown a system generally designated2for use in determining a status of a mobile electronic device in the form of an iPhone4. The system2includes a PC6and a cable8which connects the PC6to the iPhone4. The iPhone4includes a plurality of hardware elements in the form of a plurality of input elements and a plurality of output elements. Specifically, the iPhone4includes several input elements in the form of an ON/OFF button or power key10, a home/touch ID button12, an accelerometer13, a volume down button14, a volume up button16, a silent mode switch18, a proximity sensor22, and a touchscreen24. The smartphone4includes output elements in the form of the touchscreen24.

As shown inFIG.1B, the iPhone4further includes a processing resource in the form of a processor30. The iPhone4further includes a ringbuffer32which stores a debug log34. One of ordinary skill in the art will understand that, in use, the processor30runs an iOS operating system (OS).

The PC6includes a processing resource in the form of a processor40, a memory42and a display44. The memory42stores a computer program46which, when executed by the processor40, causes the processor40to perform a method as described below.

In use, with the iPhone4configured in normal mode, the OS of the iPhone4repeatedly receives information relating to the status, activation and/or operation of the hardware elements10,12,13,14,16,18,22,24and writes the received information to the debug log34stored in the ringbuffer32via the syslog relay service. As will be described in more detail below, when the iPhone4is connected to the PC6via the cable8and the processor40of the PC6executes the computer program46, the processor40of the PC6repeatedly reads information from the debug log34stored in the ringbuffer32of the iPhone4, the processor40repeatedly uses the information read from the debug log34to construct and maintain an event history for the iPhone4, and the processor40repeatedly determines a status of the smartphone4based on the event history.

For example,FIG.2Ashows the iPhone4held in front of the display44of the PC6after activation of the home/touch ID button12but before activation of hardware elements10,13,14,16,18,22,24of the iPhone4, whereasFIG.2Bshows the iPhone4held in front of the display44of the PC6after activation of the home/touch ID button12and after activation of the power key10of the iPhone4but before activation of hardware elements13,14,16,18,22,24. When the processor40of the PC6executes the computer program46, the processor40causes the display44of the PC6to display a graphical representation50of the iPhone4, which graphical representation50includes a graphical representation of each hardware element10,12,14,16,18,22,24by way of a corresponding coloured dot or circle. For example, as shown inFIG.2A, the home/touch ID button12is graphically represented by a green coloured dot or circle51to signify that the home/touch ID button12has already been activated and/or is operating correctly and each of the other hardware elements10,14,16,18,22,24is graphically represented by one or more yellow coloured dots or circles52to signify that the corresponding hardware element10,14,16,18,22,24has not yet been activated. As shown inFIG.2A, when a cursor54of the display44is positioned over the yellow coloured dot or circle52corresponding to the power key10, the display44displays a text bubble56identifying the functionality of the power key10of the iPhone4with the words “Power key”. Similarly, when the cursor54of the display44is positioned over any of the other coloured dots or circles51,52corresponding to any of the other hardware elements, the display44displays a text bubble identifying the functionality of the corresponding hardware element.

As will be described in more detail below, when the processor40of the PC6executes the computer program46, the processor40repeatedly reads information from the debug log34stored in the ringbuffer32of the iPhone4and determines the status of hardware elements10,12,13,14,16,18,22,24based on the information read from the debug log34and updates the graphical representation50of the iPhone4displayed on the display44of the PC6accordingly. For example, if the processor40determines that the power key10of the iPhone4has been activated, the processor40causes the display44of the PC6to update the graphical representation of the power key10from the yellow coloured dot or circle52shown inFIG.2Ato a green coloured dot or circle51as shown inFIG.2Bto signify that the OS of the iPhone4has detected activation of the power key10and that the power key10is therefore functioning correctly.

More specifically, when the processor40of the PC6executes the computer program46, the processor40repeatedly reads information from the debug log34stored in the ringbuffer32of the iPhone4at a plurality of different instants in time, wherein any two successive instants in time are separated by a time period which is sufficiently small so as to avoid the OS of the iPhone4from over-writing any information in the debug log34stored in the ringbuffer32before the processor40can read the information. Specifically, when the processor40of the PC6executes the computer program46, the processor40obtains the contents of the debug log34stored in the ringbuffer32of the iPhone4by executing an “idevicesyslog” command. The processor40reads only the information from the debug log34stored in the ringbuffer32at one instant in time which is new or additional to the information which the processor40reads from the debug log34at a preceding instant in time. By proceeding in this way, there is no need for the processor40to repeatedly read the whole debug log34at each instant in time. The processor40uses the information which is repeatedly read from the debug log34to construct and maintain an event history for the iPhone4which includes an event history of each of the hardware elements10,12,13,14,16,18,22,24. The event history for the iPhone4may also include any errors or warnings which the OS of the iPhone4has encountered or generated during execution of the computer program46.

The processor40repeatedly searches the event history to identify any entries in, portions of, or lines of code of, the event history which contain one or more characters, one or more symbols, one or more keywords, or one or more commands associated with at least one of the status, the activation and/or the operation of each hardware element10,12,13,14,16,18,22,24. For example, the processor40repeatedly executes a “grep” command for each of the hardware elements10,12,13,14,16,18,22,24of the iPhone4to repeatedly search the event history and identify any entries in, portions of, or lines of code of, the event history which contain one or more characters, one or more symbols, one or more keywords, or one or more commands associated with at least one of the status, the activation and/or the operation of each hardware element10,12,13,14,16,18,22,24. The processor40repeatedly determines the status of each hardware element10,12,13,14,16,18,22,24from the corresponding entries in, portions of, or lines of code of, the event history identified during the search. For example, the processor40repeatedly determines the status of each hardware element10,12,13,14,16,18,22,24by repeatedly parsing the corresponding lines of code of the event history identified during the search. The processor40causes the display44of the PC6to repeatedly update the graphical representation50of the iPhone4including the graphical representations of each hardware element10,12,13,14,16,18,22,24according to the determined status of each hardware element10,12,13,14,16,18,22,24. At the instant in time corresponding toFIG.2B, the only hardware element10,12,13,14,16,18,22,24which has changed status relative to the instant time corresponding toFIG.2Ais the power key10and the processor40causes the display44of the PC6to update the graphical representation of the power key10from the yellow coloured dot or circle52shown inFIG.2Ato the green coloured dot or circle51shown inFIG.2Bto signify that the OS of the iPhone4has detected activation of the power key10and that the power key10is therefore functioning correctly.

Referring now toFIG.3A, the iPhone4is shown held in front of the display44of the PC6after activation of the home/touch ID button12, the power key10, the volume down button14, the volume up button16, and the silent mode switch18but before activation of the proximity sensor22and the touchscreen24of the iPhone4, whereasFIG.3Bshows the iPhone4held in front of the display44of the PC6after activation of the home/touch ID button12, the power key10, the volume down button14, the volume up button16, the silent mode switch18and the proximity sensor22, but before activation of the touchscreen24. As shown inFIG.3A, each of the home/touch ID button12, the power key10, the volume down button14, the volume up button16, and the silent mode switch18is graphically represented by a corresponding green coloured dot or circle51to signify that these hardware elements have already been activated, whereas the proximity sensor22is graphically represented by a yellow coloured dot or circle52to signify that the proximity sensor22has not yet been activated. Similarly, the touchscreen24is graphically represented by a group of yellow coloured dots or circles52to signify that the corresponding regions of the touchscreen24have not yet been activated.

When the processor40of the PC6executes the computer program46, the processor40repeatedly reads information from the debug log34stored in the ringbuffer32of the iPhone4. The processor40uses the information read from the debug log34to construct and maintain an event history for the iPhone4. The processor40determines the status of hardware elements10,12,13,14,16,18,22,24based on the event history and updates the graphical representation50of the iPhone4displayed on the display44of the PC6accordingly. For example, if the processor40determines that the proximity sensor22of the iPhone4has been activated, the processor40causes the display44of the PC6to update the graphical representation of the proximity sensor22from the yellow coloured dot or circle52shown inFIG.3Ato a green coloured dot or circle51as shown inFIG.3Bto signify that the OS of the iPhone4has detected activation of the proximity sensor22and that the proximity sensor22is therefore functioning correctly. One of skill in the art will understand that the processor40determines that the proximity sensor22of the iPhone4has been activated based on the event history in the same way that the processor40determines that the power key10of the iPhone4has been activated based on the event history as described above with reference toFIGS.2A and2B.

Similarly,FIGS.4A,4B and4Cillustrate the sequential activation of different regions of the touchscreen24of the iPhone4, the detection of the activation of the different regions of the touchscreen24by the processor40of the PC6, and how the processor40updates the graphical representation50of the iPhone4on the display44of the PC6to show the live status of hardware elements10,12,13,14,16,18,22,24of the iPhone4on the display44of the PC6. One of skill in the art will understand that the processor40determines that the different regions of the touchscreen24of the iPhone4have been activated based on the event history in the same way that the processor40determines that the power key10of the iPhone4has been activated based on the event history as described above with reference toFIGS.2A and2B.

FIGS.5A,5B and5Cillustrate the activation of the accelerometer13of the iPhone4by rotating the iPhone4though approximately 90° from a “portrait orientation” to a “landscape orientation”, the detection of the activation of the accelerometer13by the processor40of the PC6, and how the processor40updates the graphical representation50of the iPhone4on the display44of the PC6to show the live status of hardware elements10,12,14,16,18,22,24of the iPhone4on the display44of the PC6together with the live orientation of the iPhone4on the display44of the PC6.FIG.5Ashows the iPhone4and the graphical representation50of the iPhone4on the display44of the PC6after hardware elements10,12,14,16,18,22,24of the iPhone4have been activated with the iPhone4in a “portrait orientation”.FIG.5Bshows the iPhone4and the graphical representation50of the iPhone4on the display44of the PC6after hardware elements10,12,14,16,18,22,24of the iPhone4have been activated but just after the iPhone4has been oriented in a “landscape orientation”. At the instant of time corresponding toFIG.5B, the processor40of the PC6has not yet had sufficient time to update the graphical representation50of the iPhone4on the display44of the PC6.FIG.5Cshows the iPhone4and the graphical representation50of the iPhone4on the display44of the PC6at an instant in time just after the instant in time corresponding toFIG.5Band after the hardware elements10,12,14,16,18,22,24of the iPhone4have been activated, after the iPhone4has been oriented in a “landscape orientation” and after the graphical representation50of the iPhone4on the display44of the PC6has been updated, but before completion of the re-orientation of the image displayed on the touchscreen24of the iPhone4from “portrait” to “landscape”. One of skill in the art will understand that the processor40determines that the accelerometer13of the iPhone4has detected the re-orientation of the iPhone4from the “portrait orientation” to the “landscape orientation” based on the information read from the debug log34in essentially the same way that the processor40determines that the power key10of the iPhone4has been activated based on the event history as described above with reference toFIGS.2A and2B. Moreover, as may be appreciated fromFIG.5C, the processor40determines that the accelerometer13of the iPhone4has detected the re-orientation of the iPhone4from the “portrait orientation” to the “landscape orientation” and updates the graphical representation50of the iPhone4on the display44of the PC6so fast that the iPhone4does not even have time to complete the re-orientation of the image displayed on the touchscreen24of the iPhone4from “portrait” to “landscape”, thereby illustrating the real-time nature of the method of determining the status of the iPhone4.

Although not described above, one of ordinary skill in the art will understand that when the program46is executed by the processor40, the processor40may detect the status, activation and/or operation of any of the hardware elements10,12,13,14,16,18,22,24and update the graphical representation50of the iPhone4on the display44of the PC6accordingly using a method which is essentially identical to the methods described above with reference toFIGS.2A-5C.

In this way, the processor40may determine whether or not any of the hardware elements10,12,13,14,16,18,22,24are operating in a predetermined manner. For example, the processor40may determine whether or not any of the hardware elements10,12,13,14,16,18,22,24are operating in a predetermined manner which corresponds to at least one of correct, normal, expected, default and desired operation of the hardware element and/or operation of the hardware element in compliance with one or more predetermined criteria. Such methods may be useful for diagnosing faults or problems with any of the hardware elements10,12,13,14,16,18,22,24.

The processor40may determine whether or not the iPhone4is operating in a predetermined manner. For example, the processor40may determine whether or not the iPhone4is operating in a predetermined manner which corresponds to at least one of correct, normal, expected, default and desired operation of the iPhone4and/or operation of the iPhone4in compliance with one or more predetermined criteria. Such methods may be useful for diagnosing faults or problems with the iPhone4.

It should be understood that the methods for use in determining the status of the iPhone4described above with reference toFIGS.2A-5Cdo not require the installation and/or execution of a diagnostic application on the iPhone4and can therefore be used even when it is not technically possible to install and/or execute a diagnostic application on the iPhone4e.g. as a consequence of lack of memory available on the iPhone4. The methods described above may avoid any requirement to receive information indirectly from the OS of the mobile electronic device via the APIs of the OS. Additionally or alternatively, the methods described above may avoid any restrictions imposed by the manufacturer of the iPhone4and/or a manufacturer of the OS of the iPhone4, which restrictions may prohibit the installation and/or execution of a third-party diagnostic application on the iPhone4. Furthermore, the methods described above can still be applied even if the iPhone4has one or more broken controls, one or more broken push buttons, a broken touchscreen, and/or one or more broken sensors which may prevent a user of the iPhone4from navigating to, or executing, a diagnostic application and/or which may prevent a user of the iPhone4from inputting and/or receiving instructions from the iPhone4.

In a variant of the method for use in determining the status of the iPhone4described above with reference toFIGS.2A-5C, the processor40may cause the display44of the PC6to display information for guiding or prompting a user of the iPhone4to perform one or more actions in relation to the iPhone4. For example, the processor40may cause the display44of the PC6to display information for guiding or prompting a user of the iPhone4to activate or operate an input element of the iPhone4. The method may comprise repeatedly reading information from the debug log34stored in the ringbuffer32of the iPhone4after the display44of the PC6has displayed the information for guiding or prompting the user to perform one or more actions in relation to the iPhone4. The method may comprise using the information read from the debug log34to construct and maintain an event history for the iPhone4. The method may comprise determining whether the one or more actions have been performed in relation to the iPhone4based on the event history.

The processor40may cause the display44of the PC6to sequentially display information which sequentially guides or prompts a user of the iPhone4to sequentially perform a plurality of actions in relation to the iPhone4. The method may comprise repeatedly reading the information from the debug log34stored in the ringbuffer32of the iPhone4after the display44of the PC6has displayed the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the iPhone4. The method may comprise determining whether each one of the plurality of actions has been performed in relation to the iPhone4based on the event history.

One of ordinary skill in the art will understand that various modifications are possible to the system and methods described above. For example, although the foregoing methods are described in the context of an iPhone, it should be understood that the same methods may be applied to a mobile electronic device of any kind, for example to other types, kinds or makes of mobile phone or smartphone, to a tablet and/or to a laptop. In particular, it should be understood that the same methods may be applied to a mobile electronic device running an operating system other than an iOS operating system. For example, the same methods may be applied to a mobile electronic device running an Android operating system.

The method may comprise setting, controlling or enabling the mobile electronic device so as to increase a level of detail of the information relating to the operation of the mobile electronic device which the operating system of the mobile electronic device writes to the debug log stored in the ringbuffer of the mobile electronic device.

The method may comprise setting, controlling or enabling the mobile electronic device so as to cause the operating system of the mobile electronic device to perform verbose logging.

The mobile electronic device may comprise an iOS device or an iOS operating system. The method may comprise using the syslog relay service when the mobile electronic device is in normal mode.

The mobile electronic device may comprise an Android device or an Android operating system. The method may comprise enabling USB debugging.

The mobile electronic device may comprise more or fewer hardware elements than the hardware elements described above. For example, the mobile electronic device may comprise at least one of a microphone, an image sensor and a speaker.

One of ordinary skill in the art will understand that one or more of the features of the embodiments of the present disclosure described above with reference to the drawings may produce effects or provide advantages when used in isolation from one or more of the other features of the embodiments of the present disclosure and that different combinations of the features are possible other than the specific combinations of the features of the embodiments of the present disclosure described above.