Determining the state of a portable electronic device

Abstract

A method for use in determining a state of a portable electronic device includes repeatedly reading information from a debug log stored in a ring buffer of the portable electronic device, repeatedly using the information read from the debug log to build and maintain an event history of the portable electronic device, and repeatedly determining a state of the portable electronic device based on the event history. The method may be particularly, but not exclusively, used in determining the state of one or more hardware elements of a mobile phone, smartphone, tablet, and / or laptop. Systems and computer programs for use in determining the state of a portable electronic device are also disclosed.

Description

[Technical field]

[0001] The present disclosure relates to systems, methods, and computer programs for use in determining the state of a portable electronic device, and in particular, but not exclusively, to systems, methods, and computer programs for use in determining the state of one or more hardware elements of a mobile phone, smartphone, tablet, and / or laptop. [Background technology]

[0002] It is known that diagnostic applications can be installed on a portable electronic device and used when executed by a processor of the portable electronic device to verify whether the portable electronic device is operating in an expected or desired manner. Such diagnostic applications can indirectly receive information regarding at least one of the status, activation and / or operation of one or more hardware inputs of the portable electronic device from the portable electronic device's OS via an application programming interface (API) of the OS. For example, such diagnostic applications can indirectly receive information regarding at least one of the status, activation and / or operation of one or more controls, one or more push buttons, a touch screen, one or more sensors, etc. of the portable electronic device from the portable electronic device's OS via the API of the OS.

[0003] However, in some circumstances, installation and / or execution of a diagnostic application on a portable electronic device may not be technically possible, for example as a result of a lack of memory available on the portable electronic device. Additionally or alternatively, installation and / or execution of a third party diagnostic application on a portable electronic device may be prohibited by the manufacturer of the portable electronic device and / or the manufacturer of the operating system of the portable electronic device. Also, in some circumstances, a portable electronic device may have one or more broken controls, one or more broken push buttons, a broken touch screen, and / or one or more broken sensors, which may prevent a user of the portable electronic device from navigating to or executing the diagnostic application and / or prevent a user of the portable electronic device from inputting and / or receiving instructions from the portable electronic device. Summary of the Invention [Means for solving the problem]

[0004] According to one aspect of the present disclosure, there is provided a method for use in determining a state of a portable electronic device, comprising: repeatedly reading information from a debug log stored in a ring buffer of the portable electronic device; repeatedly using information retrieved from the debug log to build and maintain an event history for the portable electronic device; and repeatedly determining a state of the portable electronic device based on the event history.

[0005] This method for use in determining the status of a portable electronic device does not require the installation and / or execution of a diagnostic application on the portable electronic device and therefore may be used even when the installation and / or execution of a diagnostic application on the portable electronic device is technically impossible, for example as a result of a lack of memory available on the portable electronic device. This method for use in determining the status of a portable electronic device may avoid any need to indirectly receive information from the portable electronic device's OS via the OS's API. Additionally or alternatively, this method for use in determining the status of a portable electronic device may avoid any restrictions imposed by the portable electronic device manufacturer and / or the portable electronic device's OS manufacturer that may prohibit the installation and / or execution of a third party diagnostic application on the portable electronic device. Furthermore, this method may still be applicable even when the portable electronic device has one or more broken controls, one or more broken push buttons, a broken touch screen and / or one or more broken sensors such that the user of the portable electronic device is unable to navigate to or execute the diagnostic application and / or the user of the portable electronic device is unable to input and / or receive instructions from the portable electronic device.

[0006] Repeatedly determining a state of the portable electronic device may include repeatedly determining whether the portable electronic device is operating in a predetermined manner.

[0007] Operation of the portable electronic device in a predetermined manner may correspond to at least one of correct, normal, expected, default, and desired behavior of the portable electronic device, and / or operation of the portable electronic device in compliance with one or more predetermined standards.

[0008] The method may include reading information from the debug log stored in the ring buffer at a plurality of different instants, where any two successive instants are separated by a sufficiently small amount of time to avoid an operating system of the portable electronic device overwriting information in the debug log stored in the ring buffer before the information can be read.

[0009] The method may include repeatedly reading information from the debug log at regular intervals.

[0010] The method may include reading only information from the debug log stored in the ring buffer at any given moment that is new or additional to information read from the debug log at a previous moment. The method may include identifying such new or additional information based on timestamps of corresponding entries in the debug log. The method may include reading information from the debug log stored in the ring buffer only at moments when new information is added to the debug log stored in the ring buffer. The method may include identifying moments when new information is added to the debug log stored in the ring buffer based on metadata of the debug log maintained by an OS of the portable electronic device.

[0011] The method may include iteratively identifying one or more entries or portions of an event history associated with at least one of a state, activation and / or operation of a hardware element of the portable electronic device.

[0012] The method may include iteratively determining a state of the hardware element based on one or more entries or portions of the identified event history.

[0013] The method may include iteratively identifying one or more entries or portions of the event history associated with at least one of the state, activation, and / or operation of the hardware element including iteratively searching the event history for at least one of one or more characters, one or more symbols, one or more keywords, and one or more commands associated with the at least one of the state, activation, and / or operation of the hardware element.

[0014] The method may include repeatedly analyzing one or more entries or portions of the identified event history. The method may include repeatedly determining a state of the hardware element based on the one or more entries or portions of the analyzed event history.

[0015] Determining the state of a hardware element may include determining whether the hardware element is operating in a predetermined manner.

[0016] Operation of a hardware element in a predetermined manner may correspond to at least one of correct, normal, expected, default, and desired behavior of the hardware element, and / or operation of the hardware element in compliance with one or more predetermined criteria.

[0017] The hardware element may include at least one of a transducer, a component, and a device.

[0018] The hardware elements may include input elements. The hardware elements may include output elements.

[0019] The hardware elements may include at least one of a control, a push button, a knob, a switch, a key, a keyboard, a keypad, a sensor, an accelerometer, an image sensor, a microphone, a proximity sensor, a motion sensor, a user interface, and a touch screen.

[0020] The hardware elements may include at least one of an indicator, a display, a speaker, a user interface, and a touch screen.

[0021] The method may include configuring, controlling or enabling the portable electronic device such that an operating system of the portable electronic device writes information regarding the operation of the portable electronic device to a debug log stored in a ring buffer of the portable electronic device.

[0022] The method may include configuring, controlling or enabling the portable electronic device to increase the detail of information related to operation of the portable electronic device that an operating system of the portable electronic device writes to a debug log stored in a ring buffer of the portable electronic device.

[0023] The method may include configuring, controlling or enabling the portable electronic device to cause an operating system of the portable electronic device to perform redundant logging.

[0024] The portable electronic device may include an iOS® device or an iOS® operating system. The method may include using a syslog relay service when the portable electronic device is in a normal mode.

[0025] The portable electronic device may be an Android® device or include an Android® operating system. The method may include enabling USB debugging.

[0026] The method may include repeatedly reading information from a debug log stored in a ring buffer of the portable electronic device using an external processing resource external to the portable electronic device.

[0027] The method may include using external processing resources to repeatedly display, on an external display external to the portable electronic device, information representative of the determined state of the portable electronic device.

[0028] The method may include using the external processing resource to cause an external display to display information to guide or prompt a user of the portable electronic device to perform one or more actions in connection with the portable electronic device. The one or more actions to be performed in connection with the portable electronic device may include configuring, controlling, or enabling the portable electronic device, or activating or manipulating an input element of the portable electronic device. Additionally, the one or more actions to be performed in connection with the portable electronic device may include configuring, controlling, or enabling the portable electronic device, or activating or manipulating an input element of the portable electronic device to provide increased detail of information regarding the operation of the portable electronic device.

[0029] The method may include repeatedly retrieving information from a debug log stored in a ring buffer of the portable electronic device after the external display displays information to guide or prompt a user to take one or more actions in association with the portable electronic device. The method may include repeatedly using the information retrieved from the debug log to build and maintain an event history of the portable electronic device. The method may include repeatedly determining whether one or more actions have been taken in association with the portable electronic device based on the event history.

[0030] The method may include using the external processing resource to cause the external display to sequentially display information on the external display that guides or prompts a user of the portable electronic device to sequentially perform a plurality of actions in connection with the portable electronic device.

[0031] The method may include repeatedly reading information from a debug log stored in a ring buffer of the portable electronic device after the external display displays information to guide or prompt a user to perform a respective one of a plurality of actions in association with the portable electronic device. The method may include repeatedly using the information read from the debug log to build and maintain an event history for the portable electronic device. The method may include repeatedly determining whether a respective one of a plurality of actions has been performed in association with the portable electronic device based on the information read from the debug log.

[0032] The external processing resource and / or the external display may be part of an external computing resource, such as a PC external to the portable electronic device and configured to communicate with the portable electronic device.

[0033] The external computing resource may be configured to communicate with the portable electronic device via one or more wires or a cable, such as a USB cable, connected between the external computing resource and the portable electronic device.

[0034] The portable electronic device may include a mobile phone, a smart phone, a tablet, or a laptop.

[0035] According to one aspect of the present disclosure, a method is provided for use in determining a state of a portable electronic device.

[0036] The method may include repeatedly reading information from a debug log stored in a ring buffer of the portable electronic device.

[0037] The method may include repeatedly using information retrieved from the debug log to build and maintain an event history of the portable electronic device.

[0038] The method may include repeatedly determining a state of the portable electronic device based on the event history.

[0039] According to one aspect of the present disclosure, there is provided a system for use in determining a state of a portable electronic device, the system comprising an external processing resource external to the portable electronic device, the external processing resource configured to communicate with the portable electronic device and configured to perform any of the methods described above.

[0040] According to one aspect of the present disclosure there is provided a computer program for use in determining a state of a portable electronic device, the computer program being configured, when executed by an external processing resource external to the portable electronic device, to cause the external processing resource to perform any of the methods described above.

[0041] It should be understood that any one or more features of any one of the above aspects of the present disclosure may be combined with any one or more features of any one of the other aspects of the present disclosure.

[0042] BRIEF DESCRIPTION OF THE DRAWINGS Systems, methods and computer programs for use in determining a state of a portable electronic device will now be described, by way of non-limiting example only, with reference to the following drawings: [Brief description of the drawings]

[0043] [Figure 1A] FIG. 1A is a schematic diagram of a portable electronic device and a system for use in determining a state of the portable electronic device. [Figure 1B] FIG. 1B is a schematic diagram of the portable electronic device and system of FIG. 1A showing internal components of the portable electronic device and system of FIG. 1A. [Figure 2A]FIG. 2A shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment before activation of the power key of the portable electronic device. [Figure 2B] FIG. 2B shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device, a moment after activation of the power key of the portable electronic device. [Figure 3A] FIG. 3A shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment before activation of a proximity sensor of the portable electronic device. [Figure 3B] FIG. 3B shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device, a moment after activation of a proximity sensor of the portable electronic device. [Figure 4A] FIG. 4A shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment before activation of the touchscreen of the portable electronic device. [Figure 4B] FIG. 4B shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment after activation of an area of ​​the touchscreen of the portable electronic device. [Figure 4C] FIG. 4C shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment after activation of five different regions of the touchscreen of the portable electronic device. [Figure 5A] FIG. 5A shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment before rotation of the portable electronic device from portrait to landscape orientation. [Figure 5B]FIG. 5B shows the portable electronic device of FIG. 1A held in front of a PC display showing a graphical representation of the portable electronic device at a moment shortly after rotation of the portable electronic device from portrait to landscape orientation. [Figure 5C] Figure 5C shows the portable electronic device of Figure 1A held in front of a PC display showing a graphical representation of the portable electronic device, at a moment shortly after the moment corresponding to Figure 5B, but before the change in orientation of the image displayed on the touch screen of the portable electronic device from portrait to landscape is completed. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0044] Referring first to FIG. 1A, there is shown a system, generally designated 2, for use in determining the state of a portable electronic device in the form of an iPhone® 4. The system 2 includes a PC 6 and a cable 8 connecting the PC 6 to the iPhone® 4. The iPhone® 4 includes a number of hardware elements in the form of a number of input elements and a number of output elements. In particular, the iPhone® 4 includes several input elements in the form of an ON / OFF button or power key 10, a home / touch ID button 12, an accelerometer 13, a volume down button 14, a volume up button 16, a silent mode switch 18, a proximity sensor 22, and a touch screen 24. The smartphone 4 includes an output element in the form of a touch screen 24.

[0045] As shown in Figure 1B, the iPhone® 4 further includes processing resources in the form of a processor 30. The iPhone® 4 further includes a ring buffer 32 that stores a debug log 34. Those skilled in the art will appreciate that, in use, the processor 30 runs the iOS® operating system (OS).

[0046] The PC 6 includes processing resources in the form of a processor 40, a memory 42, and a display 44. The memory 42 stores a computer program 46 which, when executed by the processor 40, causes the processor 40 to perform the methods described below.

[0047] In use, with iPhone® 4 configured in normal mode, the OS of iPhone® 4 repeatedly receives information regarding the status, activation and / or operation of hardware elements 10, 12, 13, 14, 16, 18, 22, 24 and writes the received information to debug log 34 stored in ring buffer 32 via a syslog relay service. As described in more detail below, when iPhone® 4 is connected to PC 6 via cable 8 and processor 40 of PC 6 executes computer program 46, processor 40 of PC 6 repeatedly reads information from debug log 34 stored in ring buffer 32 of iPhone® 4, processor 40 repeatedly uses the information read from debug log 34 to build and maintain an event history of iPhone® 4, and processor 40 repeatedly determines the state of smartphone 4 based on the event history.

[0048] For example, Fig. 2A shows an iPhone 4 held in front of a display 44 of a PC 6 after activation of the home / touch ID button 12 but before activation of the hardware elements 10, 13, 14, 16, 18, 22, 24 of the iPhone 4, whereas Fig. 2B shows an iPhone 4 held in front of a display 44 of a PC 6 after activation of the home / touch ID button 12 and after activation of the power key 10 of the iPhone 4 but before activation of the hardware elements 13, 14, 16, 18, 22, 24. When the processor 40 of the PC 6 executes the computer program 46, the processor 40 causes the display 44 of the PC 6 to display a graphical representation 50 of the iPhone 4. The graphical representation 50 includes a graphical representation of each of the hardware elements 10, 12, 14, 16, 18, 22, 24 with a dot or circle of a corresponding color. For example, as shown in FIG 2A, the home / touch ID button 12 is graphically represented by a green dot or circle 51 to indicate that the home / touch ID button 12 has already been activated and / or is operating correctly, and each of the other hardware elements 10, 14, 16, 18, 22, 24 is graphically represented by one or more yellow dots or circles 52 to indicate that the corresponding hardware element 10, 14, 16, 18, 22, 24 has not yet been activated. As shown in FIG 2A, when the cursor 54 of the display 44 is placed over the yellow dot or circle 52 corresponding to the power key 10, the display 44 displays a speech bubble 56 identifying the functionality of the power key 10 of the iPhone® 4 along with the word “power key”. Similarly, when the cursor 54 of the display 44 is placed over any of the other colored dots or circles 51, 52 corresponding to any of the other hardware elements, the display 44 displays a speech bubble identifying the functionality of the corresponding hardware element.

[0049] As described in more detail below, when the processor 40 of the PC 6 executes the computer program 46, the processor 40 repeatedly reads information from the debug log 34 stored in the ring buffer 32 of the iPhone 4, determines the status of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 based on the information read from the debug log 34, and updates the graphical representation 50 of the iPhone 4 displayed on the display 44 of the PC 6 accordingly. For example, if the processor 40 determines that the power key 10 of the iPhone 4 has been activated, the processor 40 causes the display 44 of the PC 6 to update the graphical representation of the power key 10 from a yellow dot or circle 52 shown in FIG. 2A to a green dot or circle 51 as shown in FIG. 2B to indicate that the OS of the iPhone 4 has detected activation of the power key 10 and that the power key 10 is therefore functioning properly.

[0050] More specifically, when the processor 40 of the PC 6 executes the computer program 46, the processor 40 repeatedly reads information from the debug log 34 stored in the ring buffer 32 of the iPhone 4 at multiple different instants, where any two consecutive instants are separated by a time that is small enough to prevent the OS of the iPhone 4 from overwriting information in the debug log 34 stored in the ring buffer 32 before the processor 40 can read this information. Specifically, when the processor 40 of the PC 6 executes the computer program 46, the processor 40 obtains the contents of the debug log 34 stored in the ring buffer 32 of the iPhone 4 by executing the "idevicesyslog" command. The processor 40 reads only information that is new or additional to the information that the processor 40 reads from the debug log 34 stored in the ring buffer 32 at a given instant from the debug log 34 at the previous instant. By proceeding in this manner, the processor 40 does not need to repeatedly read the entire debug log 34 at each instant. Processor 40 uses information repeatedly read from debug log 34 to build and maintain an event history for iPhone® 4 that includes the event history for each of hardware elements 10, 12, 13, 14, 16, 18, 22, and 24. The event history for iPhone® 4 may include any errors or warnings encountered or generated by the OS of iPhone® 4 during execution of computer program 46.

[0051] The processor 40 iteratively searches the event history to identify any entries, portions, or lines of code in the event history that include one or more characters, one or more symbols, one or more keywords, or one or more commands associated with at least one of the states, activations, and / or operations of each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24. For example, the processor 40 may repeatedly execute a "grep" command for each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 of the iPhone® 4, and iteratively search the event history to identify any entries, portions, or lines of code in the event history that include one or more characters, one or more symbols, one or more keywords, or one or more commands associated with at least one of the states, activations, and / or operations of each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24. The processor 40 iteratively determines the state of each hardware element 10, 12, 13, 14, 16, 18, 22, 24 from a corresponding entry, portion, or line of code of the event history identified during the search. For example, the processor 40 iteratively determines the state of each hardware element 10, 12, 13, 14, 16, 18, 22, 24 by iteratively analyzing the corresponding line of code of the event history identified during the search. The processor 40 causes the display 44 of the PC 6 to iteratively update a graphical representation 50 of the iPhone 4, including a graphical representation of each hardware element 10, 12, 13, 14, 16, 18, 22, 24, in response to the determined state of each hardware element 10, 12, 13, 14, 16, 18, 22, 24. At the moment corresponding to Figure 2B, the only hardware element 10, 12, 13, 14, 16, 18, 22, 24 whose state has changed with respect to the moment corresponding to Figure 2A is the power key 10, and the processor 40 causes the display 44 of the PC 6 to update the graphical representation of the power key 10 from the yellow dot or circle 52 shown in Figure 2A to the green dot or circle 51 shown in Figure 2B, indicating that the OS of the iPhone® 4 has detected activation of the power key 10 and that the power key 10 is therefore functioning correctly.

[0052] Referring now to FIG. 3A , an iPhone® 4 is shown held in front of a display 44 of a PC 6 after activation of the home / Touch ID button 12, power key 10, volume down button 14, volume up button 16, and silent mode switch 18 of the iPhone® 4, but before activation of the proximity sensor 22 and touch screen 24, while FIG. 3B shows an iPhone® 4 held in front of a display 44 of a PC 6 after activation of the home / Touch ID button 12, power key 10, volume down button 14, volume up button 16, silent mode switch 18 and proximity sensor 22, but before activation of the touch screen 24. 3A , each of the home / Touch ID button 12, power key 10, volume down button 14, volume up button 16, and silent mode switch 18 are graphically represented by a corresponding green dot or circle 51 to represent that these hardware elements have already been activated, while the proximity sensor 22 is graphically represented by a yellow dot or circle 52 to represent that the proximity sensor 22 has not yet been activated. Similarly, the touchscreen 24 is graphically represented by a group of yellow dots or circles 52 to represent that the corresponding area of ​​the touchscreen 24 has not yet been activated.

[0053] As the processor 40 of the PC 6 executes the computer program 46, the processor 40 repeatedly reads information from the debug log 34 stored in the ring buffer 32 of the iPhone 4. The processor 40 uses the information read from the debug log 34 to build and maintain an event history of the iPhone 4. The processor 40 determines the state of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 based on the event history and updates the graphical representation 50 of the iPhone 4 displayed on the display 44 of the PC 6 accordingly. For example, if the processor 40 determines that the proximity sensor 22 of the iPhone 4 has been activated, the processor 40 causes the display 44 of the PC 6 to update the graphical representation of the proximity sensor 22 from a yellow dot or circle 52 shown in FIG. 3A to a green dot or circle 51 as shown in FIG. 3B to indicate that the OS of the iPhone 4 has detected activation of the proximity sensor 22 and, therefore, that the proximity sensor 22 is functioning normally. Those skilled in the art will appreciate that processor 40 determines that proximity sensor 22 of iPhone® 4 has been activated based on event history in the same way that processor 40 determines that power key 10 of iPhone® 4 has been activated based on event history, as described above with reference to Figures 2A and 2B.

[0054] Similarly, Figures 4A, 4B and 4C illustrate the sequential activation of different regions of the touchscreen 24 of the iPhone® 4, detection of the activation of the different regions of the touchscreen 24 by the processor 40 of the PC 6, and the processor 40 updating the graphical representation 50 of the iPhone® 4 on the display 44 of the PC 6 to show the live state of the hardware elements 10, 12, 13, 14, 16, 18, 22 and 24 of the iPhone® 4 on the display 44 of the PC 6. Those skilled in the art will appreciate that the processor 40 determines that the different regions of the touchscreen 24 of the iPhone® 4 have been activated in the same manner that the processor 40 determines that the power key 10 of the iPhone® 4 has been activated based on an event history, as discussed above with reference to Figures 2A and 2B.

[0055] 5A, 5B and 5C illustrate the activation of the accelerometer 13 of the iPhone® 4 by rotating the iPhone® 4 approximately 90° from “portrait” to “landscape”, the detection of the activation of the accelerometer 13 by the processor 40 of the PC 6, and the processor 40 updating the graphical representation 50 of the iPhone® 4 on the display 44 of the PC 6 to show the live state of the hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone® 4 on the display 44 of the PC 6 along with the live orientation of the iPhone® 4 on the display 44 of the PC 6. FIG 5A shows the iPhone® 4 and the graphical representation 50 of the iPhone® 4 on the display 44 of the PC 6 after the hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone® 4 have been activated in the “portrait” orientation of the iPhone® 4. Figure 5B shows the iPhone® 4 and a graphical representation 50 of the iPhone® 4 on the display 44 of the PC 6 after the hardware elements 10, 12, 14, 16, 18, 22, and 24 of the iPhone® 4 have been activated, but just after the orientation of the iPhone® 4 has been turned to "landscape." At the moment corresponding to Figure 5B, the processor 40 of the PC 6 has not yet had enough time to update the graphical representation 50 of the iPhone® 4 on the display 44 of the PC 6. Figure 5C shows the iPhone (registered trademark) 4 and the graphical representation 50 of the iPhone (registered trademark) 4 on the display 44 of the PC 6 at a moment immediately after the moment corresponding to Figure 5B, after the hardware elements 10, 12, 14, 16, 18, 22, and 24 of the iPhone (registered trademark) 4 have been activated, after the orientation of the iPhone (registered trademark) 4 has been changed to "landscape", and after the graphical representation 50 of the iPhone (registered trademark) 4 on the display 44 of the PC 6 has been updated, but before the change in orientation of the image displayed on the touch screen 24 of the iPhone (registered trademark) 4 from "portrait" to "landscape" is completed.Those skilled in the art will appreciate that in essentially the same manner that the processor 40 determines that the power key 10 of the iPhone® 4 has been activated based on the event history, as described above with reference to Figures 2A and 2B, the processor 40 determines that the accelerometer 13 of the iPhone® 4 has detected a change in orientation of the iPhone® 4 from "portrait" to "landscape" based on information read from the debug log 34. Furthermore, as can be seen from Figure 5C, once the processor 40 determines that the accelerometer 13 of the iPhone® 4 has detected a change in orientation of the iPhone® 4 from "portrait" to "landscape", it updates the graphical representation 50 of the iPhone® 4 on the display 44 of the PC 6 so quickly that the image displayed on the touch screen 24 of the iPhone® 4 does not even have time to complete the change in orientation from "portrait" to "landscape", thus illustrating the real-time nature of the method for determining the state of the iPhone® 4.

[0056] Although not described above, those skilled in the art will appreciate that when program 46 is executed by processor 40, processor 40 may detect the status, activation and / or operation of any of hardware elements 10, 12, 13, 14, 16, 18, 22, 24 and update the graphical representation 50 of iPhone® 4 on display 44 of PC 6 accordingly using essentially the same method as described above with reference to Figures 2A-5C.

[0057] In this manner, the processor 40 may determine whether any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 are operating in a predetermined manner. For example, the processor 40 may determine whether any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 are operating in a predetermined manner that corresponds to at least one of correct, normal, expected, default, and desired behavior of the hardware element and / or behavior of the hardware element in accordance with one or more predetermined criteria. These methods may be useful for diagnosing a failure or problem with any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24.

[0058] The processor 40 may determine whether the iPhone® 4 is operating in a predetermined manner. For example, the processor 40 may determine whether the iPhone® 4 is operating in a predetermined manner that corresponds to at least one of correct, normal, expected, default, and desired behavior of the iPhone® 4 and / or behavior of the iPhone® 4 that complies with one or more predetermined criteria. These methods may be useful for diagnosing malfunctions or problems with the iPhone® 4.

[0059] It should be appreciated that the methods for use in determining the status of the iPhone® 4 described above with reference to Figures 2A-5C do not require the installation and / or execution of a diagnostic application on the iPhone® 4 and thus may be used even when the installation and / or execution of a diagnostic application on the iPhone® 4 is not technically possible, for example as a result of a lack of available memory on the iPhone® 4. The methods described above may avoid any need to indirectly receive information from the portable electronic device's OS via the OS's API. Additionally or alternatively, the methods described above may avoid any restrictions imposed by the iPhone® 4 manufacturer and / or the iPhone® 4 OS manufacturer that may prohibit the installation and / or execution of a third party diagnostic application on the iPhone® 4. Additionally, the methods described above may still be applicable even if the iPhone® 4 has one or more broken controls, one or more broken push buttons, a broken touch screen, and / or one or more broken sensors such that a user of the iPhone® 4 is unable to navigate to or run the diagnostic application and / or is unable to input and / or receive instructions from the iPhone® 4.

[0060] In a variation of the method for use in determining the state of the iPhone® 4 described above with reference to FIGS. 2A-5C, the processor 40 may cause the display 44 of the PC 6 to display information to guide or prompt the user of the iPhone® 4 to perform one or more actions in connection with the iPhone® 4. For example, the processor 40 may cause the display 44 of the PC 6 to display information to guide or prompt the user of the iPhone® 4 to activate or manipulate an input element of the iPhone® 4. The method may include repeatedly reading information from the debug log 34 stored in the ring buffer 32 of the iPhone® 4 after the display 44 of the PC 6 displays the information to guide or prompt the user to perform one or more actions in connection with the iPhone® 4. The method may include using the information read from the debug log 34 to build and maintain an event history of the iPhone® 4. The method may include determining whether one or more actions have been performed in connection with the iPhone® 4 based on the event history.

[0061] The processor 40 may cause the display 44 of the PC 6 to sequentially display information guiding or prompting the user of the iPhone (registered trademark) 4 to sequentially perform a plurality of actions in relation to the iPhone (registered trademark) 4. The method may include repeatedly reading information from the debug log 34 stored in the ring buffer 32 of the iPhone (registered trademark) 4 after the display 44 of the PC 6 displays the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the iPhone (registered trademark) 4. The method may include determining whether each one of the plurality of actions has been performed in relation to the iPhone (registered trademark) 4 based on the event history.

[0062] Those skilled in the art will appreciate that various variations of the above-described systems and methods are possible. For example, although the above-described methods have been described in the context of an iPhone®, it should be understood that the same methods may be applied to any kind of portable electronic device, such as other models, types or manufacturers of mobile phones or smartphones, tablets, and / or laptops. In particular, it should be understood that the same methods may be applied to portable electronic devices running operating systems other than the iOS® operating system. For example, the same methods may be applied to portable electronic devices running the Android® operating system.

[0063] The method may include configuring, controlling or enabling the portable electronic device to increase the detail of information about the operation of the portable electronic device that an operating system of the portable electronic device writes to a debug log stored in a ring buffer of the portable electronic device.

[0064] The method may include configuring, controlling or enabling the portable electronic device to cause an operating system of the portable electronic device to perform redundant logging.

[0065] The portable electronic device may include an iOS® device or an iOS® operating system. The method may include using a syslog relay service when the portable electronic device is in a normal mode.

[0066] The portable electronic device may include an Android® device or an Android® operating system. The method may include enabling USB debugging.

[0067] The portable electronic device may include more or less hardware elements than those described above. For example, the portable electronic device may include at least one of a microphone, an image sensor, and a speaker.

[0068] Those skilled in the art will appreciate 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 separately from one or more of the other features of the embodiments of the present disclosure, and that different feature combinations other than the specific feature combinations of the embodiments of the present disclosure described above are possible.

Claims

1. 1. A method for use in determining whether a hardware element of a portable electronic device is operating in a predetermined manner and / or a state associated with at least one of correct, normal, expected, default and desired operation of said hardware element in an apparatus comprising a processor, said processor comprising: repeatedly reading information from a debug log stored in a ring buffer of the portable electronic device; iteratively using the information retrieved from the debug log to build and maintain an event history associated with at least one of the state, activation, and / or operation of the hardware elements of the portable electronic device; repeatedly determining the state of the portable electronic device based on the event history; A method, wherein the steps of the method are performed without first installing a diagnostic application on the portable electronic device.

2. 2. The method of claim 1, wherein repeatedly determining the state of the portable electronic device includes the processor repeatedly determining whether the portable electronic device is operating in a predetermined manner.

3. 3. The method of claim 2, wherein the operation of the portable electronic device in the predetermined manner corresponds to one of a correct, normal, expected, default, and desired behavior of the portable electronic device, and / or operation of the portable electronic device in accordance with one or more predetermined standards.

4. 4. A method according to claim 1, further comprising the processor reading information from the debug log stored in the ring buffer at a plurality of different instants, where any two successive instants are separated by a time sufficiently small to avoid an operating system of the portable electronic device overwriting information in the debug log stored in the ring buffer before being able to read the information.

5. 5. A method as claimed in any preceding claim, including the processor repeatedly reading information from the debug log at regular intervals.

6. 6. A method according to any preceding claim, comprising the processor reading only information from the debug log stored in the ring buffer at a given moment that is new or additional to the information read from the debug log at a previous moment.

7. 7. The method of claim 1, wherein the processor: iteratively identifying one or more entries or portions of the event history associated with at least one of the state, the activation, and / or the operation of the hardware elements of the portable electronic device; and iteratively determining the state of the hardware element based on the identified one or more entries or portions of the event history.

8. 8. The method of claim 7, wherein iteratively identifying the one or more entries or portions of the event history associated with at least one of the state, the activation, and / or the operation of the hardware element includes the processor iteratively searching the event history for at least one of one or more characters, one or more symbols, one or more keywords, and one or more commands associated with at least one of the state, the activation, and / or the operation of the hardware element.

9. 9. The method of claim 7 or 8, wherein the processor: iteratively analyzing one or more entries or portions of the identified event history; and iteratively determining the state of the hardware element based on one or more entries or portions of the analyzed event history.

10. 10. The method of claim 7, wherein determining the state of the hardware element comprises the processor determining whether the hardware element is operating in a predetermined manner.

11. 11. The method of claim 10, wherein the operation of the hardware element in the predetermined manner corresponds to at least one of correct, normal, expected, default, and desired behavior of the hardware element and / or operation of the hardware element in compliance with one or more predetermined criteria.

12. 12. The method of any one of claims 7 to 11, wherein the hardware element comprises at least one of a transducer, a component, a device, an input element, an output element, a control, a push button, a knob, a switch, a key, a keyboard, a keypad, a sensor, an accelerometer, an image sensor, a microphone, a proximity sensor, a motion sensor, a user interface, a touch screen, an indicator, a display, and a speaker.

13. 13. A method according to any preceding claim, comprising configuring, controlling or enabling the portable electronic device such that an operating system of the portable electronic device writes information regarding the operation of the portable electronic device to the debug log stored in the ring buffer of the portable electronic device.

14. 14. The method according to any one of claims 1 to 13, configuring, controlling or enabling the portable electronic device such that the operating system of the portable electronic device writes to the debug log stored in the ring buffer of the portable electronic device with increasing detail of the information relating to the operation of the portable electronic device; and / or A method comprising: configuring, controlling or enabling the portable electronic device to cause the operating system of the portable electronic device to perform redundant logging.

15. 15. The method of any of claims 1 to 14, wherein the portable electronic device comprises an iOS device or iOS operating system, the method including using a syslog relay service when the portable electronic device is in normal mode.

16. 16. The method of any preceding claim, wherein the portable electronic device comprises an Android device or an Android operating system, the method including enabling USB debugging.

17. 17. A method as claimed in any preceding claim, comprising the processor repeatedly reading information from the debug log stored in the ring buffer of the portable electronic device using an external processing resource external to the portable electronic device.

18. 20. The method of claim 17, further comprising: the processor using the external processing resource to repeatedly cause an external display, external to the portable electronic device, to display information representative of the determined state of the portable electronic device.

19. 20. The method of claim 18, further comprising: the processor using the external processing resource to cause the external display to display information to guide or prompt a user of the portable electronic device to perform one or more actions in connection with the portable electronic device, for example, the one or more actions to be performed in connection with the portable electronic device including activating or manipulating an input element of the portable electronic device.

20. 20. The method of claim 18 or 19, wherein the processor: repeatedly reading information from the debug log stored in the ring buffer of the portable electronic device after the external display displays the information to guide or prompt a user of the portable electronic device to perform one or more actions in connection with the portable electronic device; repeatedly using the information retrieved from the debug log to build and maintain an event history of the portable electronic device; and iteratively determining whether the one or more actions have occurred in association with the portable electronic device based on the event history.

21. 21. A method according to any one of claims 18 to 20, comprising the processor using the external processing resource to cause the external display to sequentially display information on the external display that guides or prompts a user of the portable electronic device to sequentially perform a plurality of actions in relation to the portable electronic device.

22. 22. The method of claim 21, wherein the processor: repeatedly reading information from the debug log stored in the ring buffer of the portable electronic device after the external display displays the information to guide or prompt the user to take a respective one of the plurality of actions in relation to the portable electronic device; repeatedly using the information retrieved from the debug log to build and maintain an event history of the portable electronic device; and iteratively determining whether a respective one of the plurality of actions has occurred in connection with the portable electronic device based on the information retrieved from the debug log.

23. 23. The method of any preceding claim, wherein the portable electronic device comprises a mobile phone, a smartphone, a tablet, or a laptop.

24. 24. A system for use in determining a state of a portable electronic device, the system comprising an external processing resource external to the portable electronic device, the external processing resource configured to communicate with the portable electronic device and configured to perform the method of any one of claims 1 to 23.

25. 24. A computer program for use in determining a state of a portable electronic device, the computer program being configured, when executed by an external processing resource external to the portable electronic device, to cause the external processing resource to perform a method according to any one of claims 1 to 23.

Images