EP4035014A1 - Determining a status of a mobile electronic device - Google Patents

Determining a status of a mobile electronic device

Info

Publication number
EP4035014A1
EP4035014A1 EP20768359.0A EP20768359A EP4035014A1 EP 4035014 A1 EP4035014 A1 EP 4035014A1 EP 20768359 A EP20768359 A EP 20768359A EP 4035014 A1 EP4035014 A1 EP 4035014A1
Authority
EP
European Patent Office
Prior art keywords
electronic device
mobile electronic
repeatedly
status
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20768359.0A
Other languages
German (de)
French (fr)
Inventor
Markus TÖRMÄ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Blancco Technology Group IP Oy
Original Assignee
Blancco Technology Group IP Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Blancco Technology Group IP Oy filed Critical Blancco Technology Group IP Oy
Publication of EP4035014A1 publication Critical patent/EP4035014A1/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/24—Arrangements for testing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/02—Constructional features of telephone sets
    • H04M1/0202—Portable telephone sets, e.g. cordless phones, mobile phones or bar type handsets
    • H04M1/0287—Portable telephone sets, e.g. cordless phones, mobile phones or bar type handsets being disposable or recyclable
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/02—Constructional features of telephone sets
    • H04M1/23—Construction or mounting of dials or of equivalent devices; Means for facilitating the use thereof
    • H04M1/236—Construction or mounting of dials or of equivalent devices; Means for facilitating the use thereof including keys on side or rear faces

Definitions

  • the present disclosure relates to a system, method, and computer program for use in determining a status of a mobile electronic device and, in particular though not exclusively, for use in determining a status of one or more hardware elements of a mobile phone, a smartphone, a tablet and/or a laptop.
  • diagnostic applications may receive information indirectly from the OS of the mobile electronic device via the application programming interfaces (APIs) of the OS, which information relates to at least one of the status, the activation and/or the operation of one or more hardware inputs of the mobile electronic device.
  • APIs application programming interfaces
  • diagnostic applications may receive information indirectly from the OS of the mobile electronic device via APIs of the OS, which information relates to at least one of the status, the activation and/or the operation of one or more controls, one or more push buttons, a touchscreen, one or more sensors and the like of the mobile electronic device.
  • the mobile electronic device may have 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 mobile electronic device from navigating to, or executing, a diagnostic application and/or which may prevent a user of the mobile electronic device from inputting and/or receiving instructions from the mobile electronic device.
  • Such a method for use in determining the status of a mobile electronic device does not require the installation and/or execution of a diagnostic application on the mobile electronic device and can therefore be used even when it is not technically possible to install and/or execute a diagnostic application on the mobile electronic device e.g. as a consequence of lack of memory available on the mobile electronic device.
  • Such a method for use in determining the status of the mobile electronic device may avoid any requirement to receive information indirectly from the OS of the mobile electronic device via the APIs of the OS.
  • such a method for use in determining the status of the mobile electronic device may avoid any restrictions imposed by the manufacturer of the mobile electronic device and/or a manufacturer of an OS of the mobile electronic device, which restrictions may prohibit the installation and/or execution of a third-party diagnostic application on the mobile electronic device. Furthermore, such a method can still be applied even if the mobile electronic device has 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 mobile electronic device from navigating to, or executing, a diagnostic application and/or which may prevent a user of the mobile electronic device from inputting and/or receiving instructions from the mobile electronic device.
  • Repeatedly determining the status of the mobile electronic device may comprise repeatedly determining whether or not the mobile electronic device is operating in a predetermined manner.
  • the operation of the mobile electronic device in the predetermined manner may correspond to at least one of correct, normal, expected, default and desired operation of the mobile electronic device and/or operation of the mobile electronic device in compliance with one or more predetermined criteria.
  • the method may comprise reading information from the debug log stored in the ringbuffer at 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 an operating system of the mobile electronic device from over-writing any information in the debug log stored in the ringbuffer before the information can be read.
  • the method may comprise reading at any one instant in time only such information from the debug log stored in the ringbuffer which is new or additional to the information read from the debug log at a preceding instant in time.
  • the method may comprise identifying such information that is new or additional based on a time stamp of the corresponding entry in the debug log.
  • the method may comprise reading the information from the debug log stored in the ringbuffer only at such instants in time when new information is added to the debug log stored in the ringbuffer.
  • the method may comprise identifying such instants in time when new information is added to the debug log stored in the ringbuffer based on metadata of the debug log maintained by the OS of the mobile electronic device.
  • the method may comprise repeatedly identifying one or more entries in, or portions of, the event history which are associated with at least one of the status, the activation and/or the operation of a hardware element of the mobile electronic device.
  • the method may comprise repeatedly determining the status of the hardware element based on the identified one or more entries in, or portions of, the event history.
  • Repeatedly identifying the one or more entries in, or portions of, the event history which are associated with at least one of the status, the activation and/or the operation of the hardware element may comprise repeatedly 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 status, the activation and/or the operation of the hardware element.
  • the method may comprise repeatedly parsing the identified one or more entries in, or portions of, the event history.
  • the method may comprise repeatedly determining the status of the hardware element based on the one or more parsed entries in, or portions of, the event history.
  • Determining the status of the hardware element may comprise determining whether or not the hardware element is operating in a predetermined manner.
  • the operation of the hardware element in the predetermined manner may correspond 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.
  • the hardware element may comprise at least one of a transducer, a component, and a device.
  • the hardware element may comprise an input element.
  • the hardware element may comprise output element.
  • the hardware element may comprise 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 touchscreen.
  • the hardware element may comprise at least one of an indicator, a display, a speaker, a user interface and a touchscreen.
  • the method may comprise setting, controlling or enabling the mobile electronic device so that an operating system of the mobile electronic device writes information relating to the operation of the mobile electronic device 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 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 method may comprise using an external processing resource which is external to the mobile electronic device to repeatedly read information from the debug log stored in the ringbuffer of the mobile electronic device.
  • the method may comprise using the external processing resource to cause an external display which is external to the mobile electronic device to repeatedly display information representative of the determined status of the mobile electronic device.
  • the method may comprise using the external processing resource to cause the external display to display information for guiding or prompting a user of the mobile electronic device to perform one or more actions in relation to the mobile electronic device.
  • the one or more actions to be performed in relation to the mobile electronic device may comprise setting, controlling or enabling the mobile electronic device or activating or operating an input element of the mobile electronic device.
  • the one or more actions to be performed in relation to the mobile electronic device may comprise setting, controlling or enabling the mobile electronic device or activating or operating an input element of the mobile electronic device so as to increase a level of detail of the information relating to the operation of the mobile electronic device.
  • the method may comprise repeatedly reading information from the debug log stored in the ringbuffer of the mobile electronic device after the external display has displayed the information for guiding or prompting the user to perform one or more actions in relation to the mobile electronic device.
  • the method may comprise repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device.
  • the method may comprise repeatedly determining whether the one or more actions have been performed in relation to the mobile electronic device based on the event history.
  • the method may comprise using the external processing resource to cause the external display to sequentially display information on the external display to sequentially guide or prompt a user of the mobile electronic device to sequentially perform a plurality of actions in relation to the mobile electronic device.
  • the method may comprise repeatedly reading information from the debug log stored in the ringbuffer of the mobile electronic device after the external display has displayed the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the mobile electronic device.
  • the method may comprise repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device.
  • the method may comprise repeatedly determining whether each one of the plurality of actions has been performed in relation to the mobile electronic device based on the information read from the debug log.
  • the external processing resource and/or the external display may be part of an external computing resource such as a PC which is external to the mobile electronic device and which is configured for communication with the mobile electronic device.
  • the external computing resource may be configured for communication with the mobile electronic device via one or more wires or a cable such as a USB cable connected between the external computing resource and the mobile electronic device.
  • the mobile electronic device may comprise a mobile phone, a smartphone, a tablet or a laptop.
  • a method for use in determining a status of a mobile electronic device there is provided a method for use in determining a status of a mobile electronic device.
  • the method may comprise repeatedly reading information from a debug log stored in a ringbuffer of the mobile electronic device.
  • the method may comprise repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device.
  • the method may comprise repeatedly determining the status of the mobile electronic device based on the event history.
  • a system for use in determining a status of a mobile electronic device comprising an external processing resource which is external to the mobile electronic device, wherein the external processing resource is configured for communication with the mobile electronic device and is configured to perform any of the methods described above.
  • a computer program for use in determining a status of a mobile electronic device, the computer program being configured so that, when executed by an external processing resource external to the mobile electronic device, the external processing resource performs any of the methods described above.
  • FIG. 1A is a schematic of a mobile electronic device and a system for use in determining a status of the mobile electronic device
  • FIG. 1 B is a schematic of the mobile electronic device and system of FIG. 1 A showing internal components of the mobile electronic device and system of FIG. 1 A;
  • FIG. 2A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before the activation of a power key of the mobile electronic device;
  • FIG. 2B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of the power key of the mobile electronic device;
  • FIG. 3A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before the activation of a proximity sensor of the mobile electronic device;
  • FIG. 3B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of the proximity sensor of the mobile electronic device;
  • FIG. 4A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before the activation of a touchscreen of the mobile electronic device;
  • FIG. 4B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of one region of the touchscreen of the mobile electronic device;
  • FIG. 4C shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of five different regions of the touchscreen of the mobile electronic device
  • FIG. 5A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before rotation of the mobile electronic device from a portrait orientation to a landscape orientation;
  • FIG. 5B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time just after rotation of the mobile electronic device from a portrait orientation to a landscape orientation;
  • FIG. 5C shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time just after the instant in time corresponding to FIG. 5B but before completion of the re-orientation of the image displayed on a touchscreen of the mobile electronic device from portrait to landscape.
  • the system 2 includes a PC 6 and a cable 8 which connects the PC 6 to the iPhone 4.
  • the iPhone 4 includes a plurality of hardware elements in the form of a plurality of input elements and a plurality of output elements.
  • 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 touchscreen 24.
  • the smartphone 4 includes output elements in the form of the touchscreen 24.
  • the iPhone 4 further includes a processing resource in the form of a processor 30.
  • the iPhone 4 further includes a ringbuffer 32 which stores a debug log 34.
  • the processor 30 runs an iOS operating system (OS).
  • OS iOS operating system
  • the PC 6 includes a processing resource 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 a method as described below.
  • the OS of the iPhone 4 In use, with the iPhone 4 configured in normal mode, the OS of the iPhone 4 repeatedly receives information relating to the status, activation and/or operation of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 and writes the received information to the debug log 34 stored in the ringbuffer 32 via the syslog relay service.
  • the processor 40 of the PC 6 when the iPhone 4 is connected to the PC 6 via the cable 8 and the processor 40 of the PC 6 executes the computer program 46, the processor 40 of the PC 6 repeatedly reads information from the debug log 34 stored in the ringbuffer 32 of the iPhone 4, the processor 40 repeatedly uses the information read from the debug log 34 to construct and maintain an event history for the iPhone 4, and the processor 40 repeatedly determines a status of the smartphone 4 based on the event history.
  • FIG. 2A shows the iPhone 4 held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12 but before activation of hardware elements 10, 13, 14, 16, 18, 22, 24 of the iPhone 4
  • FIG. 2B shows the iPhone 4 held in front of the display 44 of the 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 hardware elements 13, 14, 16, 18, 22, 24.
  • 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, which graphical representation 50 includes a graphical representation of each hardware element 10, 12, 14, 16, 18, 22, 24 by way of a corresponding coloured dot or circle.
  • FIG. 1 shows the iPhone 4 held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12 but before activation of hardware elements 10, 13, 14, 16, 18, 22, 24 of the iPhone 4
  • FIG. 2B shows the iPhone 4 held in front of the display 44 of the PC 6 after
  • the home/touch ID button 12 is graphically represented by a green coloured dot or circle 51 to signify 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 coloured dots or circles 52 to signify that the corresponding hardware element 10, 14, 16, 18, 22, 24 has not yet been activated.
  • a cursor 54 of the display 44 when a cursor 54 of the display 44 is positioned over the yellow coloured dot or circle 52 corresponding to the power key 10, the display 44 displays a text bubble 56 identifying the functionality of the power key 10 of the iPhone 4 with the words “Power key”.
  • the cursor 54 of the display 44 is positioned over any of the other coloured dots or circles 51 , 52 corresponding to any of the other hardware elements, the display 44 displays a text bubble identifying the functionality of the corresponding hardware element.
  • 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 ringbuffer 32 of the iPhone 4 at 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 iPhone 4 from over-writing any information in the debug log 34 stored in the ringbuffer 32 before the processor 40 can read the information.
  • 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 ringbuffer 32 of the iPhone 4 by executing an “idevicesyslog” command.
  • the processor 40 reads only the information from the debug log 34 stored in the ringbuffer 32 at one instant in time which is new or additional to the information which the processor 40 reads from the debug log 34 at a preceding instant in time. By proceeding in this way, there is no need for the processor 40 to repeatedly read the whole debug log 34 at each instant in time.
  • the processor 40 uses the information which is repeatedly read from the debug log 34 to construct and maintain an event history for the iPhone 4 which includes an event history of each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24.
  • the event history for the iPhone 4 may also include any errors or warnings which the OS of the iPhone 4 has encountered or generated during execution of the computer program 46.
  • the processor 40 repeatedly 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 element 10, 12, 13, 14, 16, 18, 22, 24.
  • the processor 40 repeatedly executes a “grep” command for each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 of the iPhone 4 to 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 element 10, 12, 13, 14, 16, 18, 22, 24.
  • FIG. 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 coloured dot or circle 52 shown in FIG. 2A to the green coloured dot or circle 51 shown in FIG. 2B to signify 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.
  • FIG. 3A the iPhone 4 is shown held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, and the silent mode switch 18 but before activation of the proximity sensor 22 and the touchscreen 24 of the iPhone 4, whereas FIG. 3B shows the iPhone 4 held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, the silent mode switch 18 and the proximity sensor 22, but before activation of the touchscreen 24.
  • FIG. 3B shows the iPhone 4 held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, the silent mode switch 18 and the proximity sensor 22, but before activation of the touchscreen 24.
  • each of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, and the silent mode switch 18 is graphically represented by a corresponding green coloured dot or circle 51 to signify that these hardware elements have already been activated
  • the proximity sensor 22 is graphically represented by a yellow coloured dot or circle 52 to signify that the proximity sensor 22 has not yet been activated
  • the touchscreen 24 is graphically represented by a group of yellow coloured dots or circles 52 to signify that the corresponding regions of the touchscreen 24 have not yet been activated.
  • 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 ringbuffer 32 of the iPhone 4.
  • the processor 40 uses the information read from the debug log 34 to construct and maintain an event history for the iPhone 4.
  • the processor 40 determines the status of 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 the yellow coloured dot or circle 52 shown in FIG. 3A to a green coloured dot or circle 51 as shown in FIG.
  • the processor 40 determines that the proximity sensor 22 of the iPhone 4 has been activated based on the event history in the same way 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 FIGS. 2A and 2B.
  • FIG. 4A, 4B and 4C illustrate the sequential activation of different regions of the touchscreen 24 of the iPhone 4, the detection of the activation of the different regions of the touchscreen 24 by the processor 40 of the PC 6, and how the processor 40 updates the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 to show the live status of hardware elements 10, 12, 13, 14, 16, 18, 22, 24 of the iPhone 4 on the display 44 of the PC 6.
  • the processor 40 determines that the different regions of the touchscreen 24 of the iPhone 4 have been activated based on the event history in the same way 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 FIGS. 2A and 2B.
  • FIGS. 5A, 5B and 5C illustrate the activation of the accelerometer 13 of the iPhone 4 by rotating the iPhone 4 though approximately 90° from a “portrait orientation” to a “landscape orientation”, the detection of the activation of the accelerometer 13 by the processor 40 of the PC 6, and how the processor 40 updates the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 to show the live status of hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone 4 on the display 44 of the PC 6 together 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 hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone 4 have been activated with the iPhone 4 in a “portrait orientation”.
  • the processor 40 determines that the accelerometer 13 of the iPhone 4 has detected the re-orientation of the iPhone 4 from the “portrait orientation” to the “landscape orientation” and updates the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 so fast that the iPhone 4 does not even have time to complete the re-orientation of the image displayed on the touchscreen 24 of the iPhone 4 from “portrait” to “landscape”, thereby illustrating the real-time nature of the method of determining the status of the iPhone 4.
  • the processor 40 may detect the status, activation and/or operation of any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 and update the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 accordingly using a method which is essentially identical to the methods described above with reference to FIGS. 2A - 5C. In this way, the processor 40 may determine whether or not any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 are operating in a predetermined manner.
  • the processor 40 may determine whether or not any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 are 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 elements 10, 12, 13, 14, 16, 18, 22, 24.
  • the processor 40 may determine whether or not the iPhone 4 is operating in a predetermined manner. For example, the processor 40 may determine whether or not the iPhone 4 is operating in a predetermined manner which corresponds to at least one of correct, normal, expected, default and desired operation of the iPhone 4 and/or operation of the iPhone 4 in compliance with one or more predetermined criteria. Such methods may be useful for diagnosing faults or problems with the iPhone 4.
  • the methods for use in determining the status of the iPhone 4 described above with reference to FIGS. 2A - 5C do not require the installation and/or execution of a diagnostic application on the iPhone 4 and can therefore be used even when it is not technically possible to install and/or execute a diagnostic application on the iPhone 4 e.g. as a consequence of lack of memory available on the iPhone 4.
  • 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 iPhone 4 and/or a manufacturer of the OS of the iPhone 4, which restrictions may prohibit the installation and/or execution of a third-party diagnostic application on the iPhone 4.
  • the methods described above can still be applied even if the iPhone 4 has 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 iPhone 4 from navigating to, or executing, a diagnostic application and/or which may prevent a user of the iPhone 4 from inputting and/or receiving instructions from the iPhone 4.
  • the processor 40 may cause the display 44 of the PC 6 to display information for guiding or prompting a user of the iPhone 4 to perform one or more actions in relation to the iPhone 4.
  • the processor 40 may cause the display 44 of the PC 6 to display information for guiding or prompting a user of the iPhone 4 to activate or operate an input element of the iPhone 4.
  • the method may comprise repeatedly reading information from the debug log 34 stored in the ringbuffer 32 of the iPhone 4 after the display 44 of the PC 6 has displayed the information for guiding or prompting the user to perform one or more actions in relation to the iPhone 4.
  • the method may comprise using the information read from the debug log 34 to construct and maintain an event history for the iPhone 4.
  • the method may comprise determining whether the one or more actions have been performed in relation to the iPhone 4 based on the event history.
  • the processor 40 may cause the display 44 of the PC 6 to sequentially display information which sequentially guides or prompts a user of the iPhone 4 to sequentially perform a plurality of actions in relation to the iPhone 4.
  • the method may comprise repeatedly reading the information from the debug log 34 stored in the ringbuffer 32 of the iPhone 4 after the display 44 of the PC 6 has displayed the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the iPhone 4.
  • the method may comprise determining whether each one of the plurality of actions has been performed in relation to the iPhone 4 based on the event history.
  • 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.
  • the mobile electronic device may comprise at least one of a microphone, an image sensor and a speaker.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Signal Processing (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Telephone Function (AREA)
  • Debugging And Monitoring (AREA)

Abstract

A method for use in determining a status of a mobile electronic device, comprises repeatedly reading information from a debug log stored in a ringbuffer of the mobile electronic device, repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device, and repeatedly determining the status of the mobile electronic device based on the event history. The method may be used for determining a status of a mobile electronic device and, in particular though not exclusively, for use in determining a status of one or more hardware elements of a mobile phone, a smartphone, a tablet and/or a laptop. A system and a computer program for use in determining a status of a mobile electronic device are also disclosed.

Description

DETERMINING A STATUS OF A MOBILE ELECTRONIC DEVICE
FIELD
The present disclosure relates to a system, method, and computer program for use in determining a status of a mobile electronic device and, in particular though not exclusively, for use in determining a status of one or more hardware elements of a mobile phone, a smartphone, a tablet and/or a laptop.
BACKGROUND
It is known to install a diagnostic application on a mobile electronic device which, when executed by a processor of the mobile electronic device, may be used to verify whether the mobile electronic device is operating in an expected or desired manner. Such diagnostic applications may receive information indirectly from the OS of the mobile electronic device via the application programming interfaces (APIs) of the OS, which information relates to at least one of the status, the activation and/or the operation of one or more hardware inputs of the mobile electronic device. For example, such diagnostic applications may receive information indirectly from the OS of the mobile electronic device via APIs of the OS, which information relates to at least one of the status, the activation and/or the operation of one or more controls, one or more push buttons, a touchscreen, one or more sensors and the like of the mobile electronic device.
However, in some circumstances, it may not be technically possible to install and/or execute a diagnostic application on a mobile electronic device e.g. as a consequence of lack of memory available on the mobile electronic device. Additionally or alternatively, the installation and/or execution of a third-party diagnostic application on a mobile electronic device may be prohibited by a manufacturer of the mobile electronic device and/or a manufacturer of the OS of the mobile electronic device. Also, in some circumstances, the mobile electronic device may have 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 mobile electronic device from navigating to, or executing, a diagnostic application and/or which may prevent a user of the mobile electronic device from inputting and/or receiving instructions from the mobile electronic device. SUMMARY
According to an aspect of the present disclosure there is provided a method for use in determining a status of a mobile electronic device, the method comprising: repeatedly reading information from a debug log stored in a ringbuffer of the mobile electronic device; repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device; and repeatedly determining the status of the mobile electronic device based on the event history.
Such a method for use in determining the status of a mobile electronic device does not require the installation and/or execution of a diagnostic application on the mobile electronic device and can therefore be used even when it is not technically possible to install and/or execute a diagnostic application on the mobile electronic device e.g. as a consequence of lack of memory available on the mobile electronic device. Such a method for use in determining the status of the mobile electronic device 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, such a method for use in determining the status of the mobile electronic device may avoid any restrictions imposed by the manufacturer of the mobile electronic device and/or a manufacturer of an OS of the mobile electronic device, which restrictions may prohibit the installation and/or execution of a third-party diagnostic application on the mobile electronic device. Furthermore, such a method can still be applied even if the mobile electronic device has 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 mobile electronic device from navigating to, or executing, a diagnostic application and/or which may prevent a user of the mobile electronic device from inputting and/or receiving instructions from the mobile electronic device.
Repeatedly determining the status of the mobile electronic device may comprise repeatedly determining whether or not the mobile electronic device is operating in a predetermined manner.
The operation of the mobile electronic device in the predetermined manner may correspond to at least one of correct, normal, expected, default and desired operation of the mobile electronic device and/or operation of the mobile electronic device in compliance with one or more predetermined criteria. The method may comprise reading information from the debug log stored in the ringbuffer at 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 an operating system of the mobile electronic device from over-writing any information in the debug log stored in the ringbuffer before the information can be read.
The method may comprise repeatedly reading information from the debug log at regular intervals.
The method may comprise reading at any one instant in time only such information from the debug log stored in the ringbuffer which is new or additional to the information read from the debug log at a preceding instant in time. The method may comprise identifying such information that is new or additional based on a time stamp of the corresponding entry in the debug log. The method may comprise reading the information from the debug log stored in the ringbuffer only at such instants in time when new information is added to the debug log stored in the ringbuffer. The method may comprise identifying such instants in time when new information is added to the debug log stored in the ringbuffer based on metadata of the debug log maintained by the OS of the mobile electronic device.
The method may comprise repeatedly identifying one or more entries in, or portions of, the event history which are associated with at least one of the status, the activation and/or the operation of a hardware element of the mobile electronic device.
The method may comprise repeatedly determining the status of the hardware element based on the identified one or more entries in, or portions of, the event history.
Repeatedly identifying the one or more entries in, or portions of, the event history which are associated with at least one of the status, the activation and/or the operation of the hardware element may comprise repeatedly 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 status, the activation and/or the operation of the hardware element.
The method may comprise repeatedly parsing the identified one or more entries in, or portions of, the event history. The method may comprise repeatedly determining the status of the hardware element based on the one or more parsed entries in, or portions of, the event history.
Determining the status of the hardware element may comprise determining whether or not the hardware element is operating in a predetermined manner. The operation of the hardware element in the predetermined manner may correspond 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.
The hardware element may comprise at least one of a transducer, a component, and a device.
The hardware element may comprise an input element. The hardware element may comprise output element.
The hardware element may comprise 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 touchscreen.
The hardware element may comprise at least one of an indicator, a display, a speaker, a user interface and a touchscreen.
The method may comprise setting, controlling or enabling the mobile electronic device so that an operating system of the mobile electronic device writes information relating to the operation of the mobile electronic device 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 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 method may comprise using an external processing resource which is external to the mobile electronic device to repeatedly read information from the debug log stored in the ringbuffer of the mobile electronic device. The method may comprise using the external processing resource to cause an external display which is external to the mobile electronic device to repeatedly display information representative of the determined status of the mobile electronic device.
The method may comprise using the external processing resource to cause the external display to display information for guiding or prompting a user of the mobile electronic device to perform one or more actions in relation to the mobile electronic device. The one or more actions to be performed in relation to the mobile electronic device may comprise setting, controlling or enabling the mobile electronic device or activating or operating an input element of the mobile electronic device. Further, the one or more actions to be performed in relation to the mobile electronic device may comprise setting, controlling or enabling the mobile electronic device or activating or operating an input element of the mobile electronic device so as to increase a level of detail of the information relating to the operation of the mobile electronic device.
The method may comprise repeatedly reading information from the debug log stored in the ringbuffer of the mobile electronic device after the external display has displayed the information for guiding or prompting the user to perform one or more actions in relation to the mobile electronic device. The method may comprise repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device. The method may comprise repeatedly determining whether the one or more actions have been performed in relation to the mobile electronic device based on the event history.
The method may comprise using the external processing resource to cause the external display to sequentially display information on the external display to sequentially guide or prompt a user of the mobile electronic device to sequentially perform a plurality of actions in relation to the mobile electronic device.
The method may comprise repeatedly reading information from the debug log stored in the ringbuffer of the mobile electronic device after the external display has displayed the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the mobile electronic device. The method may comprise repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device. The method may comprise repeatedly determining whether each one of the plurality of actions has been performed in relation to the mobile electronic device based on the information read from the debug log. The external processing resource and/or the external display may be part of an external computing resource such as a PC which is external to the mobile electronic device and which is configured for communication with the mobile electronic device.
The external computing resource may be configured for communication with the mobile electronic device via one or more wires or a cable such as a USB cable connected between the external computing resource and the mobile electronic device.
The mobile electronic device may comprise a mobile phone, a smartphone, a tablet or a laptop.
According to an aspect of the present disclosure there is provided a method for use in determining a status of a mobile electronic device.
The method may comprise repeatedly reading information from a debug log stored in a ringbuffer of the mobile electronic device.
The method may comprise repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device.
The method may comprise repeatedly determining the status of the mobile electronic device based on the event history.
According to an aspect of the present disclosure there is provided a system for use in determining a status of a mobile electronic device, the system comprising an external processing resource which is external to the mobile electronic device, wherein the external processing resource is configured for communication with the mobile electronic device and is configured to perform any of the methods described above.
According to an aspect of the present disclosure there is provided a computer program for use in determining a status of a mobile electronic device, the computer program being configured so that, when executed by an external processing resource external to the mobile electronic device, the external processing resource performs any of the methods described above.
It should be understood that any one or more of the features of any one of the preceding aspects of the present disclosure may be combined with any one or more of the features of any of the other preceding aspects of the present disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
A system, method and computer program for use in determining a status of a mobile electronic device will now be described by way of non-limiting example only with reference to the following drawings of which: FIG. 1A is a schematic of a mobile electronic device and a system for use in determining a status of the mobile electronic device;
FIG. 1 B is a schematic of the mobile electronic device and system of FIG. 1 A showing internal components of the mobile electronic device and system of FIG. 1 A;
FIG. 2A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before the activation of a power key of the mobile electronic device;
FIG. 2B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of the power key of the mobile electronic device;
FIG. 3A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before the activation of a proximity sensor of the mobile electronic device;
FIG. 3B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of the proximity sensor of the mobile electronic device;
FIG. 4A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before the activation of a touchscreen of the mobile electronic device;
FIG. 4B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of one region of the touchscreen of the mobile electronic device;
FIG. 4C shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time after the activation of five different regions of the touchscreen of the mobile electronic device; FIG. 5A shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time before rotation of the mobile electronic device from a portrait orientation to a landscape orientation;
FIG. 5B shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time just after rotation of the mobile electronic device from a portrait orientation to a landscape orientation; and
FIG. 5C shows the mobile electronic device of FIG. 1 A held in front of a display of a PC displaying a graphical representation of the mobile electronic device at an instant in time just after the instant in time corresponding to FIG. 5B but before completion of the re-orientation of the image displayed on a touchscreen of the mobile electronic device from portrait to landscape.
DETAILED DESCRIPTION OF THE DRAWINGS
Referring initially to FIG. 1 A, there is shown a system generally designated 2 for use in determining a status of a mobile electronic device in the form of an iPhone 4. The system 2 includes a PC 6 and a cable 8 which connects the PC 6 to the iPhone 4. The iPhone 4 includes a plurality of hardware elements in the form of a plurality of input elements and a plurality of output elements. Specifically, 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 touchscreen 24. The smartphone 4 includes output elements in the form of the touchscreen 24.
As shown in FIG. 1 B, the iPhone 4 further includes a processing resource in the form of a processor 30. The iPhone 4 further includes a ringbuffer 32 which stores a debug log 34. One of ordinary skill in the art will understand that, in use, the processor 30 runs an iOS operating system (OS).
The PC 6 includes a processing resource 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 a method as described below. In use, with the iPhone 4 configured in normal mode, the OS of the iPhone 4 repeatedly receives information relating to the status, activation and/or operation of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 and writes the received information to the debug log 34 stored in the ringbuffer 32 via the syslog relay service. As will be described in more detail below, when the iPhone 4 is connected to the PC 6 via the cable 8 and the processor 40 of the PC 6 executes the computer program 46, the processor 40 of the PC 6 repeatedly reads information from the debug log 34 stored in the ringbuffer 32 of the iPhone 4, the processor 40 repeatedly uses the information read from the debug log 34 to construct and maintain an event history for the iPhone 4, and the processor 40 repeatedly determines a status of the smartphone 4 based on the event history.
For example, FIG. 2A shows the iPhone 4 held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12 but before activation of hardware elements 10, 13, 14, 16, 18, 22, 24 of the iPhone 4, whereas FIG. 2B shows the iPhone 4 held in front of the display 44 of the 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 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, which graphical representation 50 includes a graphical representation of each hardware element 10, 12, 14, 16, 18, 22, 24 by way of a corresponding coloured dot or circle. For example, as shown in FIG. 2A, the home/touch ID button 12 is graphically represented by a green coloured dot or circle 51 to signify 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 coloured dots or circles 52 to signify that the corresponding hardware element 10, 14, 16, 18, 22, 24 has not yet been activated. As shown in FIG. 2A, when a cursor 54 of the display 44 is positioned over the yellow coloured dot or circle 52 corresponding to the power key 10, the display 44 displays a text bubble 56 identifying the functionality of the power key 10 of the iPhone 4 with the words “Power key”. Similarly, when the cursor 54 of the display 44 is positioned over any of the other coloured dots or circles 51 , 52 corresponding to any of the other hardware elements, the display 44 displays a text bubble identifying the functionality of the corresponding hardware element.
As will be 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 ringbuffer 32 of the iPhone 4 and determines the status of 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 the yellow coloured dot or circle 52 shown in FIG. 2A to a green coloured dot or circle 51 as shown in FIG. 2B to signify 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.
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 ringbuffer 32 of the iPhone 4 at 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 iPhone 4 from over-writing any information in the debug log 34 stored in the ringbuffer 32 before the processor 40 can read the 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 ringbuffer 32 of the iPhone 4 by executing an “idevicesyslog” command. The processor 40 reads only the information from the debug log 34 stored in the ringbuffer 32 at one instant in time which is new or additional to the information which the processor 40 reads from the debug log 34 at a preceding instant in time. By proceeding in this way, there is no need for the processor 40 to repeatedly read the whole debug log 34 at each instant in time. The processor 40 uses the information which is repeatedly read from the debug log 34 to construct and maintain an event history for the iPhone 4 which includes an event history of each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24. The event history for the iPhone 4 may also include any errors or warnings which the OS of the iPhone 4 has encountered or generated during execution of the computer program 46.
The processor 40 repeatedly 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 element 10, 12, 13, 14, 16, 18, 22, 24. For example, the processor 40 repeatedly executes a “grep” command for each of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 of the iPhone 4 to 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 element 10, 12, 13, 14, 16, 18, 22, 24. The processor 40 repeatedly determines the status of each hardware element 10, 12, 13, 14, 16, 18, 22, 24 from the corresponding entries in, portions of, or lines of code of, the event history identified during the search. For example, the processor 40 repeatedly determines the status of each hardware element 10, 12, 13, 14, 16, 18, 22, 24 by repeatedly parsing the corresponding lines of code of the event history identified during the search. The processor 40 causes the display 44 of the PC 6 to repeatedly update the graphical representation 50 of the iPhone 4 including the graphical representations of each hardware element 10, 12, 13, 14, 16, 18, 22, 24 according to the determined status of each hardware element 10, 12, 13, 14, 16, 18, 22, 24. At the instant in time corresponding to FIG. 2B, the only hardware element 10, 12, 13, 14, 16, 18, 22, 24 which has changed status relative to the instant time corresponding to FIG. 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 coloured dot or circle 52 shown in FIG. 2A to the green coloured dot or circle 51 shown in FIG. 2B to signify 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.
Referring now to FIG. 3A, the iPhone 4 is shown held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, and the silent mode switch 18 but before activation of the proximity sensor 22 and the touchscreen 24 of the iPhone 4, whereas FIG. 3B shows the iPhone 4 held in front of the display 44 of the PC 6 after activation of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, the silent mode switch 18 and the proximity sensor 22, but before activation of the touchscreen 24. As shown in FIG. 3A, each of the home/touch ID button 12, the power key 10, the volume down button 14, the volume up button 16, and the silent mode switch 18 is graphically represented by a corresponding green coloured dot or circle 51 to signify that these hardware elements have already been activated, whereas the proximity sensor 22 is graphically represented by a yellow coloured dot or circle 52 to signify that the proximity sensor 22 has not yet been activated. Similarly, the touchscreen 24 is graphically represented by a group of yellow coloured dots or circles 52 to signify that the corresponding regions of the touchscreen 24 have not yet been activated.
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 ringbuffer 32 of the iPhone 4. The processor 40 uses the information read from the debug log 34 to construct and maintain an event history for the iPhone 4. The processor 40 determines the status of 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 the yellow coloured dot or circle 52 shown in FIG. 3A to a green coloured dot or circle 51 as shown in FIG. 3B to signify that the OS of the iPhone 4 has detected activation of the proximity sensor 22 and that the proximity sensor 22 is therefore functioning correctly. One of skill in the art will understand that the processor 40 determines that the proximity sensor 22 of the iPhone 4 has been activated based on the event history in the same way 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 FIGS. 2A and 2B.
Similarly, FIG. 4A, 4B and 4C illustrate the sequential activation of different regions of the touchscreen 24 of the iPhone 4, the detection of the activation of the different regions of the touchscreen 24 by the processor 40 of the PC 6, and how the processor 40 updates the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 to show the live status of hardware elements 10, 12, 13, 14, 16, 18, 22, 24 of the iPhone 4 on the display 44 of the PC 6. One of skill in the art will understand that the processor 40 determines that the different regions of the touchscreen 24 of the iPhone 4 have been activated based on the event history in the same way 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 FIGS. 2A and 2B.
FIGS. 5A, 5B and 5C illustrate the activation of the accelerometer 13 of the iPhone 4 by rotating the iPhone 4 though approximately 90° from a “portrait orientation” to a “landscape orientation”, the detection of the activation of the accelerometer 13 by the processor 40 of the PC 6, and how the processor 40 updates the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 to show the live status of hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone 4 on the display 44 of the PC 6 together 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 hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone 4 have been activated with the iPhone 4 in a “portrait orientation”. FIG. 5B shows the iPhone 4 and the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 after hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone 4 have been activated but just after the iPhone 4 has been oriented in a “landscape orientation”. At the instant of time corresponding to FIG. 5B, the processor 40 of the PC 6 has not yet had sufficient time to update the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6. FIG. 5C shows the iPhone 4 and the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 at an instant in time just after the instant in time corresponding to FIG. 5B and after the hardware elements 10, 12, 14, 16, 18, 22, 24 of the iPhone 4 have been activated, after the iPhone 4 has been oriented in a “landscape orientation” and after the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 has been updated, but before completion of the re-orientation of the image displayed on the touchscreen 24 of the iPhone 4 from “portrait” to “landscape”. One of skill in the art will understand that the processor 40 determines that the accelerometer 13 of the iPhone 4 has detected the re-orientation of the iPhone 4 from the “portrait orientation” to the “landscape orientation” based on the information read from the debug log 34 in essentially the same way 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 FIGS. 2A and 2B. Moreover, as may be appreciated from FIG. 5C, the processor 40 determines that the accelerometer 13 of the iPhone 4 has detected the re-orientation of the iPhone 4 from the “portrait orientation” to the “landscape orientation” and updates the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 so fast that the iPhone 4 does not even have time to complete the re-orientation of the image displayed on the touchscreen 24 of the iPhone 4 from “portrait” to “landscape”, thereby illustrating the real-time nature of the method of determining the status of the iPhone 4.
Although not described above, one of ordinary skill in the art will understand that when the program 46 is executed by the processor 40, the processor 40 may detect the status, activation and/or operation of any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 and update the graphical representation 50 of the iPhone 4 on the display 44 of the PC 6 accordingly using a method which is essentially identical to the methods described above with reference to FIGS. 2A - 5C. In this way, the processor 40 may determine whether or not 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 or not any of the hardware elements 10, 12, 13, 14, 16, 18, 22, 24 are 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 elements 10, 12, 13, 14, 16, 18, 22, 24.
The processor 40 may determine whether or not the iPhone 4 is operating in a predetermined manner. For example, the processor 40 may determine whether or not the iPhone 4 is operating in a predetermined manner which corresponds to at least one of correct, normal, expected, default and desired operation of the iPhone 4 and/or operation of the iPhone 4 in compliance with one or more predetermined criteria. Such methods may be useful for diagnosing faults or problems with the iPhone 4.
It should be understood that the methods for use in determining the status of the iPhone 4 described above with reference to FIGS. 2A - 5C do not require the installation and/or execution of a diagnostic application on the iPhone 4 and can therefore be used even when it is not technically possible to install and/or execute a diagnostic application on the iPhone 4 e.g. as a consequence of lack of memory available on the iPhone 4. 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 iPhone 4 and/or a manufacturer of the OS of the iPhone 4, which restrictions may prohibit the installation and/or execution of a third-party diagnostic application on the iPhone 4. Furthermore, the methods described above can still be applied even if the iPhone 4 has 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 iPhone 4 from navigating to, or executing, a diagnostic application and/or which may prevent a user of the iPhone 4 from inputting and/or receiving instructions from the iPhone 4.
In a variant of the method for use in determining the status 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 for guiding or prompting a user of the iPhone 4 to perform one or more actions in relation to the iPhone 4. For example, the processor 40 may cause the display 44 of the PC 6 to display information for guiding or prompting a user of the iPhone 4 to activate or operate an input element of the iPhone 4. The method may comprise repeatedly reading information from the debug log 34 stored in the ringbuffer 32 of the iPhone 4 after the display 44 of the PC 6 has displayed the information for guiding or prompting the user to perform one or more actions in relation to the iPhone 4. The method may comprise using the information read from the debug log 34 to construct and maintain an event history for the iPhone 4. The method may comprise determining whether the one or more actions have been performed in relation to the iPhone 4 based on the event history.
The processor 40 may cause the display 44 of the PC 6 to sequentially display information which sequentially guides or prompts a user of the iPhone 4 to sequentially perform a plurality of actions in relation to the iPhone 4. The method may comprise repeatedly reading the information from the debug log 34 stored in the ringbuffer 32 of the iPhone 4 after the display 44 of the PC 6 has displayed the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the iPhone 4. The method may comprise determining whether each one of the plurality of actions has been performed in relation to the iPhone 4 based 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.

Claims

1. A method for use in determining a status of a mobile electronic device, the method comprising: repeatedly reading information from a debug log stored in a ringbuffer of the mobile electronic device; repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device; and repeatedly determining the status of the mobile electronic device based on the event history.
2. A method as claimed in claim 1 , wherein repeatedly determining the status of the mobile electronic device comprises repeatedly determining whether or not the mobile electronic device is operating in a predetermined manner.
3. A method as claimed in claim 2, wherein the operation of the mobile electronic device in the predetermined manner corresponds to at least one of correct, normal, expected, default and desired operation of the mobile electronic device and/or operation of the mobile electronic device in compliance with one or more predetermined criteria.
4. A method as claimed in any preceding claim, comprising reading information from the debug log stored in the ringbuffer at 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 an operating system of the mobile electronic device from over writing any information in the debug log stored in the ringbuffer before the information can be read.
5. A method as claimed in any preceding claim, comprising repeatedly reading information from the debug log at regular intervals.
6. A method as claimed in any preceding claim, comprising reading only information from the debug log stored in the ringbuffer at one instant in time which is new or additional to the information read from the debug log at a preceding instant in time.
7. A method as claimed in any preceding claim, comprising: repeatedly identifying one or more entries in, or portions of, the event history which are associated with at least one of the status, the activation and/or the operation of a hardware element of the mobile electronic device; and repeatedly determining the status of the hardware element based on the identified one or more entries in, or portions of, the event history.
8. A method as claimed in claim 7, wherein repeatedly identifying the one or more entries in, or portions of, the event history which are associated with at least one of the status, the activation and/or the operation of the hardware element comprises repeatedly 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 status, the activation and/or the operation of the hardware element.
9. A method as claimed in claim 7 or 8, comprising: repeatedly parsing the identified one or more entries in, or portions of, the event history; and repeatedly determining the status of the hardware element based on the one or more parsed entries in, or portions of, the event history.
10. A method as claimed in any one of claims 7 to 9, wherein determining the status of the hardware element comprises determining whether or not the hardware element is operating in a predetermined manner.
11 . A method as claimed in 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 operation of the hardware element and/or operation of the hardware element in compliance with one or more predetermined criteria.
12. A method as claimed in 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 touchscreen, an indicator, a display, and a speaker.
13. A method as claimed in any preceding claim, comprising setting, controlling or enabling the mobile electronic device so that an operating system of the mobile electronic device writes information relating to the operation of the mobile electronic device to the debug log stored in the ringbuffer of the mobile electronic device.
14. A method as claimed in any preceding claim, comprising: 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; and/or setting, controlling or enabling the mobile electronic device so as to cause the operating system of the mobile electronic device to perform verbose logging.
15. A method as claimed in any preceding claim, wherein the mobile electronic device comprises an iOS device or an iOS operating system and the method comprises using the syslog relay service when the mobile electronic device is in normal mode.
16. A method as claimed in any preceding claim, wherein the mobile electronic device comprises an Android device or an Android operating system and the method comprises enabling USB debugging.
17. A method as claimed in any preceding claim, comprising using an external processing resource which is external to the mobile electronic device to repeatedly read information from the debug log stored in the ringbuffer of the mobile electronic device.
18. A method as claimed in claim 17, comprising using the external processing resource to cause an external display which is external to the mobile electronic device to repeatedly display information representative of the determined status of the mobile electronic device.
19. A method as claimed in claim 18, comprising using the external processing resource to cause the external display to display information for guiding or prompting a user of the mobile electronic device to perform one or more actions in relation to the mobile electronic device, for example wherein the one or more actions to be performed in relation to the mobile electronic device comprise activating or operating an input element of the mobile electronic device.
20. A method as claimed in claim 18 or 19, comprising: repeatedly reading information from the debug log stored in the ringbuffer of the mobile electronic device after the external display has displayed the information for guiding or prompting the user to perform one or more actions in relation to the mobile electronic device; repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device; and repeatedly determining whether the one or more actions have been performed in relation to the mobile electronic device based on the event history.
21. A method as claimed in any one of claims 18 to 20, comprising using the external processing resource to cause the external display to sequentially display information on the external display to sequentially guide or prompt a user of the mobile electronic device to sequentially perform a plurality of actions in relation to the mobile electronic device.
22. A method as claimed in claim 21 , comprising: repeatedly reading information from the debug log stored in the ringbuffer of the mobile electronic device after the external display has displayed the information for guiding or prompting the user to perform each one of the plurality of actions in relation to the mobile electronic device; repeatedly using the information read from the debug log to construct and maintain an event history for the mobile electronic device; and repeatedly determining whether each one of the plurality of actions has been performed in relation to the mobile electronic device based on the information read from the debug log.
23. A method as claimed in any preceding claim, wherein the mobile electronic device comprises a mobile phone, a smartphone, a tablet or a laptop.
24. A system for use in determining a status of a mobile electronic device, the system comprising an external processing resource which is external to the mobile electronic device, wherein the external processing resource is configured for communication with the mobile electronic device and is configured to perform the method of any preceding claim.
25. A computer program for use in determining a status of a mobile electronic device, the computer program being configured so that, when executed by an external processing resource external to the mobile electronic device, the external processing resource performs the method of any one of claims 1 to 23.
EP20768359.0A 2019-09-24 2020-09-14 Determining a status of a mobile electronic device Pending EP4035014A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB201913773A GB201913773D0 (en) 2019-09-24 2019-09-24 Determining a status of a mobile electronic device
PCT/EP2020/075635 WO2021058310A1 (en) 2019-09-24 2020-09-14 Determining a status of a mobile electronic device

Publications (1)

Publication Number Publication Date
EP4035014A1 true EP4035014A1 (en) 2022-08-03

Family

ID=68425604

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20768359.0A Pending EP4035014A1 (en) 2019-09-24 2020-09-14 Determining a status of a mobile electronic device

Country Status (5)

Country Link
US (1) US12212703B2 (en)
EP (1) EP4035014A1 (en)
JP (1) JP7689517B2 (en)
GB (1) GB201913773D0 (en)
WO (1) WO2021058310A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4091060B1 (en) 2020-10-30 2023-12-06 Google LLC Systems and methods of debugging delivery of content items
CN113220648B (en) * 2021-05-25 2025-08-05 广州绿怡信息科技有限公司 Audio function detection method and device

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8910049B2 (en) * 2010-08-20 2014-12-09 Hewlett-Packard Development Company, L.P. User-initiated mode for remote support
US9020463B2 (en) 2011-12-29 2015-04-28 The Nielsen Company (Us), Llc Systems, methods, apparatus, and articles of manufacture to measure mobile device usage
US9514208B2 (en) * 2012-10-30 2016-12-06 Vekatachary Srinivasan Method and system of stateless data replication in a distributed database system
US10149116B1 (en) * 2017-01-27 2018-12-04 Allstate Insurance Company Early notification of driving status to a mobile device
FI128356B (en) * 2017-02-24 2020-04-15 Piceasoft Oy Method and apparatus for determining the condition of an electronic device
US10559283B2 (en) * 2017-03-20 2020-02-11 Paypal, Inc. Automated user device damage remediation
US10218697B2 (en) * 2017-06-09 2019-02-26 Lookout, Inc. Use of device risk evaluation to manage access to services
CN108763020A (en) 2018-05-23 2018-11-06 郑州云海信息技术有限公司 It is a kind of fall disk capture the method and monitor card of storage management card daily record automatically
US11228910B2 (en) * 2019-01-25 2022-01-18 V440 Spó£Ka Akcyjna Mobile communication device and method of determining security status thereof

Also Published As

Publication number Publication date
GB201913773D0 (en) 2019-11-06
WO2021058310A1 (en) 2021-04-01
US20220377165A1 (en) 2022-11-24
JP7689517B2 (en) 2025-06-06
JP2022551424A (en) 2022-12-09
US12212703B2 (en) 2025-01-28

Similar Documents

Publication Publication Date Title
CN105659194B (en) Fast worktodo for on-screen keyboard
KR101453703B1 (en) Automated controls for sensor enabled user interface
JP5330769B2 (en) Electronics
CN103828336B (en) For the method and apparatus triggering teledata typing interface
US20090174663A1 (en) Dynamically configurable keyboard for computer
CN103533448B (en) The cursor control method and cursor control device of intelligent television
US9563393B2 (en) Information processing method and electronic device
US10095328B2 (en) Virtual input device system
KR20130041629A (en) Method and apparatus for displaying icons on mobile terminal
US12212703B2 (en) Determining a status of a mobile electronic device
CN106933567B (en) A Graphical User Interface GUI System
EP3227785A1 (en) Playback and automatic execution of a process to control a computer system
KR20030081743A (en) System and method for remote examination of personal hand-held terminal
KR101364376B1 (en) Method and apparatus for inputting user terminal with touch screen
EP2360578A1 (en) A method for detecting user screens in mobile devices working under symbian operating system
EP3525089B1 (en) Graphical user interface (gui) system
JP2008061246A (en) Remote management system and method for portable electronic device
KR101464190B1 (en) Method and apparatus for controling smart device for prevention of intoxication of kids user
US20190265874A1 (en) Panel control system and editing method thereof
US10009450B1 (en) Detecting non-touch applications
US11249732B2 (en) GUI controller design support device, system for remote control and program
CN111078024A (en) Method for dynamically adjusting keyboard output signal
US10564732B1 (en) Method of providing virtual function keys based on an application
KR100966606B1 (en) Methods for restricting input by interlocking databases, computing devices, and computer-readable recording media
KR102087208B1 (en) Mnemonic based method for gui test automation and apparatus using the same

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220412

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250313