Remote verification of mobile device status

Abstract

In various implementations, an acceptable state of the mobile device may be determined based on a remote verification of the state of the mobile device. A method for verifying a mobile device may include a user requesting verification of the mobile device, performing diagnostics on the mobile device, receiving a security data object associated with the mobile device by a system, and / or determining that the mobile device has a security feature that is either disabled or enabled. If the security feature of the mobile device is enabled or disabled, the system may configure a GUI to prompt the user to disable the security feature. Or, the system may configure a GUI to display an acceptable state if the security feature is disabled.

Description

[Technical field]

[0001] Embodiments of the present disclosure generally relate to systems, methods, and apparatus relating to remote verification of a state of a mobile device, which may include performing one or more diagnostics on the mobile device and / or verifying the state of security features on the mobile device. [Background technology]

[0002] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Application No. 17 / 643,442, filed December 9, 2021, entitled "Remote Verification of State of a Mobile Device," which is incorporated herein by reference in its entirety. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] U.S. Pat. No. 10,332,249 [Patent Document 2] U.S. Pat. No. 1,081,0732 Summary of the Invention [Problem to be solved by the invention]

[0004] Mobile devices, such as smartphones, watches, tablets, and other computing devices, are often in transit or otherwise difficult to locate on demand in a predictable manner. Thus, checking the condition of such mobile devices is rendered unpredictable and often must be delayed until the user ships or hands the device to a testing site or other collection location. Such delays may cause further problems (e.g., bricking) of the mobile device or otherwise delay receipt of time-sensitive data regarding the status of the mobile device. Through applied effort, ingenuity, and innovation, Applicant has solved many of these identified problems by developing solutions embodied by embodiments of the present invention described in detail below. [Means for solving the problem]

[0005] In general, embodiments of the present disclosure comprise a system, an apparatus, a computer-implemented method, a computer-readable storage medium, and a computer program product for remote verification of a state of a mobile device. Other implementations of remote verification of a state of a mobile device will be, or will become, apparent to one of ordinary skill in the art upon review of the following figures and detailed description. All such additional implementations contained within this specification are intended to be within the scope of this disclosure and protected by the following claims.

[0006] According to some embodiments of the present disclosure, a computer-executable method for remotely verifying a condition of a mobile device may be provided. The method may include receiving a request for verification of a condition of the mobile device, and causing the mobile device, via a processor of the mobile device, to perform at least one diagnostic based on the request. Based on the request, the method includes receiving at least one security data object associated with the mobile device, determining that the at least one security data object indicates that a security feature associated with the at least one security data object is enabled, and rendering a graphical user interface (GUI) for a user of the mobile device configured to facilitate disabling of the security feature.

[0007] According to some embodiments, a method for remotely verifying a condition of a mobile device may include an embodiment in which at least one diagnostic may include a crack detection routine comprising: instructing a user of the mobile device to point a front camera of the mobile device at a reflective surface; capturing an image of the mobile device with the front camera; and analyzing the image to determine if a crack is present or transmitting the image from the mobile device for analysis.

[0008] According to some embodiments, a method for remotely verifying a state of a mobile device may include an embodiment in which the at least one diagnostic may include an internal diagnostic test.

[0009] According to some embodiments, a method for remotely verifying a state of a mobile device may include an embodiment in which receiving at least one security data object may include querying at least one external system and receiving the at least one security data object from the external system.

[0010] According to some embodiments, a method for remotely verifying a state of a mobile device may include an embodiment in which a security data object is transmitted from the mobile device or from an external system to a remote verification system.

[0011] According to some embodiments, a method of remotely verifying a state of a mobile device may include transmitting an indication of an unacceptable condition of the mobile device upon detecting one or more of at least one diagnostic failure and at least one security data object indicating that a security feature associated with the at least one security data object is enabled.

[0012] According to some embodiments, a method for remotely verifying a status of a mobile device may include displaying a prompt on the mobile device, the prompt requesting input of a serial number of the mobile device, displaying a prompt, receiving an identification data object associated with the mobile device, and determining that the identification data object matches the serial number.

[0013] According to some embodiments, a method for remotely verifying a state of a mobile device may include configuring the mobile device based on a security data object, where the security data object may be maintained by a provider system. According to some embodiments, a method for remotely verifying a state of a mobile device may include an embodiment in which the security data object is configured to be updated to indicate that security features are disabled after authentication credentials are entered into the mobile device or into a second interface of a second device that accesses an account associated with a user of the mobile device.

[0014] According to some embodiments, a method for remotely verifying a state of a mobile device may include receiving an updated security data object indicating that security features are disabled, determining an acceptable condition of the mobile device based on the updated security data object, and transmitting computer readable instructions from a remote verification server configured to facilitate a transfer of the mobile device from a user to a third party. In some embodiments, the remote verification server may be configured to determine the acceptable condition and facilitate the transfer of the mobile device from the user to a third party without requiring identifying information associated with the user or the third party.

[0015] According to some embodiments, a method for remotely verifying a state of a mobile device may include receiving an updated security data object indicating that security features are disabled, determining an acceptable state of the mobile device based on the updated security data object, and changing an indication of the acceptable state of the mobile device to an unacceptable condition after a predetermined threshold time has elapsed.

[0016] According to some embodiments, a method for remotely verifying a state of a mobile device may include receiving an updated security data object indicating that a security feature is disabled and transmitting an indication of an acceptable state of the mobile device.

[0017] According to some embodiments, a method for remotely verifying a state of a mobile device may include receiving a pass indication that the mobile device has passed at least one diagnostic prior to transmitting an indication of an acceptable state of the mobile device. According to some embodiments, a method for remotely verifying a state of a mobile device may include receiving a pass indication that the mobile device has passed at least one diagnostic prior to receiving at least one security data object associated with the mobile device.

[0018] According to some embodiments, a method for remotely verifying a state of a mobile device may include rendering instructions for performing a transaction on the mobile device based on an acceptable state.

[0019] According to some embodiments, at least one computer readable storage medium for remote verification of a mobile device may be provided. The computer program product may include at least one non-transitory computer readable storage medium having computer program code stored thereon. The computer program code is configured, upon execution on at least one processor, for: receiving a request to verify a state of a mobile device, and, based on the request, causing the mobile device to perform at least one diagnostic via a processor of the mobile device, and, based on the request, receiving at least one security data object associated with the mobile device; transmitting an indication of an acceptable state of the mobile device, in an instance where a status of at least one of the security data objects indicates that a security feature associated with at least one of the security data objects is disabled; transmitting an indication of an invalidity of the mobile device, in an instance where a status of at least one of the security data objects indicates that a security feature associated with at least one of the security data objects is enabled; and causing rendering of a graphic user interface for a user of the mobile device configured to display at least the acceptable state of the mobile device or the indication of an invalidity of the mobile device.

[0020] According to some embodiments, at least one computer-readable storage medium for remote verification of a mobile device may include an embodiment in which performing at least one diagnostic comprises directing a user of the mobile device to point a front-facing camera of the mobile device toward a reflective surface, capturing an image of the mobile device with the front-facing camera, and analyzing the image to determine if a crack is present or transmitting the image from the mobile device for analysis.

[0021] According to some embodiments, at least one computer-readable storage medium for remote validation of a mobile device may include an embodiment in which the at least one diagnostic may include an internal diagnostic test.

[0022] According to some embodiments, at least one computer-readable storage medium for remote verification of a mobile device may include an embodiment in which receiving at least one security data object may include querying at least one external system and receiving the at least one security data object from the external system.

[0023] According to some embodiments, at least one computer-readable storage medium for remote verification of a mobile device may comprise an embodiment in which a security data object is transmitted from the mobile device or from an external system to a remote verification system.

[0024] According to some embodiments, the computer program code may be configured, upon execution by the at least one processor, to transmit an indication of an unacceptable state of the mobile device upon detecting one or more of: a failure of at least one diagnostic; or at least one security data object indicating that a security feature associated with the at least one security data object is enabled.

[0025] According to some embodiments, the computer program code, upon execution by at least one processor, may be configured to cause a prompt to be displayed on the mobile device, the prompt may include steps of requesting input of a serial number of the mobile device, receiving an identification data object associated with the mobile device, and determining that the identification data object matches the serial number.

[0026] According to some embodiments, the computer program code, upon execution on the at least one processor, may be configured to configure the mobile device with a security data object, the security data object being maintained by the provider system. According to some embodiments, a computer program product for remote validation of a mobile device may include an embodiment in which the security data object is configured to be invalidated after authentication credentials are entered into the mobile device or into a second interface of a second device having access to an account associated with a user of the mobile device.

[0027] According to some embodiments, the computer program code, upon execution on at least one processor, may be configured to: receive an updated security data object indicating that security features are disabled; determine an acceptable state of the mobile device based on the updated security data object; and transmit computer readable instructions from a remote verification server configured to facilitate a transfer of the mobile device from a user to a third party.

[0028] According to some embodiments, the remote verification server may be configured to determine an acceptable state and facilitate the transfer of the mobile device from a user to a third party without requiring identifying information associated with the user or the third party.

[0029] According to some embodiments, the computer program code, when executed with at least one processor, may be configured to: receive an updated security data object indicating that a security feature is disabled; determine an acceptable state of the mobile device based on the updated security data object; and change an indication of the acceptable state of the mobile device to an unacceptable state after a predetermined threshold time has elapsed.

[0030] According to some embodiments, the computer program code may be configured, upon execution by the at least one processor, to transmit an indication of an acceptable state of the mobile device upon receiving an updated security data object indicating that the security feature is disabled.

[0031] According to some embodiments, the computer program code, in execution with the at least one processor, may be configured to receive a passing indication that the mobile device has passed at least one diagnostic prior to transmitting an indication of an acceptable state of the mobile device. According to some embodiments, the computer program code, in execution with the at least one processor, may be configured to receive a passing indication that the mobile device has passed at least one diagnostic prior to receiving at least one security data object associated with the mobile device.

[0032] According to some embodiments, the computer program code may be configured, upon execution with at least one processor, to cause rendering of instructions for executing a transaction on the mobile device based on the permissible states.

[0033] According to some embodiments, at least one computer-readable storage medium for remote verification of a mobile device may include an embodiment in which the computer program code may be contained on a software development kit (SDK). According to some embodiments, the software development kit SDK may be applied to one or more mobile devices.

[0034] According to some embodiments of the present disclosure, a system for remote verification of a mobile device may be provided, which may include a processor of the mobile device configured to receive a request for verification of the mobile device. The processor may comprise: causing the mobile device to perform at least one diagnostic based on the request; receiving at least one security data object associated with the mobile device based on the request; and transmitting an indication of an acceptable state of the mobile device in an instance where a status of the at least one security data object indicates a security feature associated with the at least one security data object is disabled. In an instance where a status of the at least one security data object indicates a security feature associated with the at least one security data object is enabled, transmitting the indication of the disabled mobile device and rendering a graphical user interface for a user of the mobile device configured to display at least the acceptable state of the mobile device or the indication of the disabled mobile device.

[0035] According to some embodiments, a system may include any apparatus or computer-readable storage medium configured to perform any method or otherwise configured and structured in accordance with various embodiments herein.

[0036] Having thus described embodiments of the present disclosure in general terms, reference is now made to the accompanying drawings, which are not necessarily drawn to scale. [Brief description of the drawings]

[0037] [Figure 1] 1 is a block diagram of an example mobile device remote verification server computing device structured in accordance with at least one example embodiment of the present disclosure. [Diagram 2]1 is a block diagram of an exemplary client computing device structured in accordance with at least one exemplary embodiment of the present disclosure. [Diagram 3] FIG. 1 illustrates an example architecture system for providing remote verification of a state of a mobile device in accordance with at least one example embodiment of the present disclosure. [Figure 4] 1 illustrates example operations of an example process for remote verification of a state of a mobile device in accordance with at least one example embodiment of the present disclosure. [Diagram 5] FIG. 1 illustrates an example process for remote verification of a state of a mobile device, and in particular, example operations of an example process for performing internal diagnostics on the mobile device and / or determining security capabilities of the mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 6] 1 illustrates an example process for remote verification of a state of a mobile device, and in particular additional operations for execution of internal diagnostic operations on the mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 7] FIG. 1 illustrates an example process for remote verification of a state of a mobile device, and in particular additional operations for execution of a screen crack detection routine on a mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 8] 1 illustrates an example process for remote verification of a state of a mobile device, and in particular additional operations for detection of security capabilities of the mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 9] FIG. 13 illustrates an example process for remote verification of a state of a mobile device, specifically additional operations for determining enabled security features of the mobile device and configuring the mobile device to disable security features, in accordance with at least one example embodiment of the present disclosure. [Figure 10]FIG. 1 illustrates an example mobile device performing screen crack detection in accordance with at least one example embodiment of the present disclosure. [Figure 11] FIG. 2 illustrates an example mobile device performing screen crack detection, and specifically, detecting cracks on the screen of the mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 12] 1 illustrates an example mobile device during execution of an internal hardware diagnostic operation on the mobile device in accordance with at least one example embodiment of the present disclosure. [Figure 13] 1 illustrates an example mobile device illustrating entry of a serial number associated with the mobile device in accordance with at least one example embodiment of the present disclosure. [Figure 14] 1 illustrates an example mobile device showing an input area for a telephone number associated with the mobile device in accordance with at least one example embodiment of the present disclosure. [Figure 15] 1 illustrates an example mobile device illustrating a graphical user interface configured to facilitate disabling security features in accordance with at least one example embodiment of the present disclosure. [Figure 16] FIG. 1 illustrates an example mobile device illustrating a graphical user interface (GUI) configured to display acceptable states of the mobile device based on remote verification of the state of the mobile device, and in particular diagnostic results associated with the mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 17] FIG. 1 illustrates an example mobile device that indicates an acceptable state of the mobile device based on remote verification of the state of the mobile device, specifically shipping information associated with the mobile device, in accordance with at least one example embodiment of the present disclosure. [Figure 18] 1 illustrates an example mobile device illustrating a graphical user interface configured to facilitate remote verification of a state of the mobile device in accordance with at least one example embodiment of the present disclosure. [Figure 19] FIG. 1 illustrates an example mobile device illustrating a graphical user interface configured to facilitate remote verification of a state of the mobile device, the graphical user interface illustrating example permissions for access to the mobile device and its circuitry in accordance with at least one example embodiment of the present disclosure. [Figure 20] 1 illustrates an example mobile device showing options for input of one or more mobile device diagnostics for user selection for remote verification of the state of the mobile device in accordance with at least one example embodiment of the present disclosure. [Figure 21] FIG. 1 illustrates an example graphical user interface configured to facilitate a screen crack detection routine, in which instructions for the screen crack detection routine may be shown, in accordance with at least one example embodiment of the present disclosure. [Figure 22] FIG. 1 illustrates an example graphical user interface configured to facilitate a screen crack detection routine, where instructions for the screen crack detection routine may include instructions to point the screen of the mobile device towards a mirror, in accordance with at least one example embodiment of the present disclosure. [Diagram 23] FIG. 13 illustrates an example screen of a mobile device depicting upside-down instructions for viewing in a mirror in accordance with a screen crack detection routine described herein in accordance with at least one example embodiment of the present disclosure. [Figure 24] FIG. 1 illustrates an example screen shot of a mobile device indicating that the mobile device should remain steady while facing a mirror for capture by the mobile device's front camera, in accordance with at least one example embodiment of the present disclosure. [Diagram 25] FIG. 1 illustrates an example screen shot of a mobile device showing a test pattern for capture by a camera of the mobile device and processing to determine whether a crack is present, in accordance with at least one example embodiment of the present disclosure. [Figure 26]FIG. 13 illustrates an example of a graphical user interface configured to facilitate a remote verification process in which an indication of a passed screen crack detection routine is shown in accordance with at least one example embodiment of the present disclosure. [Figure 27] FIG. 1 illustrates an example graphical user interface configured to facilitate diagnosis comprising a touch screen surface test in accordance with at least one example embodiment of the present disclosure. [Figure 28] FIG. 1 illustrates an example graphical user interface comprising a test pattern configured to encourage one or more screen touch inputs associated with a surface square of a screen surface test in accordance with at least one example embodiment of the present disclosure. [Figure 29] FIG. 1 illustrates an example graphical user interface configured to indicate success (pass) of a screen surface test in accordance with at least one example embodiment of the present disclosure. [Diagram 30] FIG. 1 illustrates an example graphical user interface configured to facilitate battery charging connection testing in accordance with at least one example embodiment of the present disclosure. [Diagram 31] 1 illustrates an example graphical user interface configured to facilitate Bluetooth® connection testing in accordance with at least one example embodiment of the present disclosure. [Diagram 32] FIG. 1 illustrates an example graphical user interface configured to facilitate Wi-Fi connection testing in accordance with at least one example embodiment of the present disclosure. [Diagram 33] FIG. 1 illustrates an example graphical user interface configured to facilitate disabling security features of a mobile device in accordance with at least one example embodiment of the present disclosure. [Diagram 34]FIG. 1 illustrates an example graphical user interface configured to facilitate disabling of a security feature of a mobile device, where the security feature is disabled in a settings page associated with the mobile device, in accordance with at least one example embodiment of the present disclosure. [Diagram 35] FIG. 1 illustrates an example graphical user interface configured to facilitate disabling of a security feature of a mobile device, where the security feature is disabled, in accordance with at least one example embodiment of the present disclosure. [Diagram 36] FIG. 1 illustrates an exemplary graphical user interface configured to facilitate disabling a security feature of a mobile device, the graphical user interface comprising instructions to facilitate disabling the security feature, and the graphical user interface configured to indicate that a remote verification process is checking the status of the security feature, in accordance with at least one exemplary embodiment of the present disclosure. [Figure 37] FIG. 1 illustrates an example graphical user interface configured to facilitate disabling a security feature of a mobile device, the graphical user interface configured to indicate that the security feature is enabled, in accordance with at least one example embodiment of the present disclosure. [Figure 38] 1 illustrates an example graphical user interface configured to indicate that security features of a mobile device are disabled, in accordance with at least one example embodiment of the present disclosure. [Figure 39] 1 illustrates an example graphical user interface configured to facilitate input of an indication of liquid crystal breakage into a mobile device in accordance with at least one example embodiment of the present disclosure. [Diagram 40] 1 illustrates an example graphical user interface configured to facilitate input of an indication of physical damage to a mobile device in accordance with at least one example embodiment of the present disclosure. [Diagram 41] FIG. 1 illustrates an example graphical user interface of a mobile device that indicates an acceptable state of the mobile device based on remote verification of the state of the mobile device, and in particular, a graphical user interface configured to indicate a trade-in value of the mobile device, in accordance with at least one example embodiment of the present disclosure. [Diagram 42] FIG. 1 illustrates an example graphical user interface of a mobile device that indicates an acceptable state of the mobile device based on remote verification of the state of the mobile device, and in particular, a graphical user interface configured to indicate an upgrade of the mobile device, in accordance with at least one example embodiment of the present disclosure. [Diagram 43] FIG. 1 illustrates an example graphical user interface of a mobile device indicating an unacceptable state of the mobile device based on remote verification of the state of the mobile device, and in particular a graphical user interface configured to indicate an ineligible upgrade of the mobile device in response to one or more failed diagnostics, in accordance with at least one example embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0038] DETAILED DESCRIPTION OF THE DRAWINGS The present disclosure will now be described in more detail with reference to the accompanying drawings, in which some, but not all, embodiments of the present disclosure are shown. Indeed, embodiments of the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, but rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements.

[0039] <Definition> As used herein, the term "request" refers to a computer transmission to initiate one or more computer functions. In some embodiments, a "request" may be a device-to-device transmission (e.g., a message sent from a first computing device to a second computing device) that is generated at one device and sent to another device (e.g., via a network, a wired connection, a wireless connection, etc.). In some embodiments, a "request" may be a transmission within a single device (e.g., a transmission from a first circuit or routine to a second circuit or routine). In various exemplary embodiments discussed herein, a "request" may be sent from a mobile device to a validation circuit external to the mobile device. In various exemplary embodiments discussed herein, a "request" may be sent internally within the mobile device to perform various functions of the mobile device. In various exemplary embodiments discussed herein, a "request" may be sent from a third party computing device to the mobile device with or without validation circuitry. A "request" may be generated by dedicated hardware, firmware, and / or software level processing.

[0040] As used herein, the term "verifying the state of the mobile device" refers to specialized hardware, firmware, and / or software level processing to perform specific diagnostics of the computing device and / or to verify the state of security features of the mobile device, such as by detecting whether the security features are enabled or disabled. In some embodiments, such "diagnostics" may include, but are not limited to, one or more of a screen crack detection routine or internal diagnostics. In some embodiments, the "verifying the state of the mobile device" may be performed at least in part by the mobile device and / or in some embodiments, the "verifying the state of the mobile device" may be performed at least in part by another computing device. As used herein, the term "state of the mobile device" refers to electronic data values ​​associated with the output of the verification processing, comprising outputs of "acceptable state of the mobile device" and "unacceptable state of the mobile device."

[0041] As used herein, the term "acceptable condition" refers to electronic data values ​​representing a state of the mobile device where one or more predefined acceptable conditions have been met. In some embodiments, the "acceptable condition" may constitute an output of a diagnostic where a GUI (Graphical User Interface) is configured to display the results of one or more diagnostics. As used herein, the term "unacceptable condition" refers to electronic data values ​​representing a state of the mobile device where one or more predefined acceptable conditions have not been met. In some embodiments, the "unacceptable condition" may constitute the opposite and / or converse of an acceptable condition and may indicate that the state of the mobile device does not meet one or more conditions of the acceptable condition.

[0042] As used herein, the term "security data object" refers to electronic data values ​​associated with security features of a computing device (e.g., a mobile device). In some embodiments, a "security data object" may include, but is not limited to, an indication of whether a security feature is enabled or disabled. In some embodiments, a "security data object" is housed locally on a computing device and / or in some embodiments, a security data object may be housed on another computing device.

[0043] As used herein, the term "security feature" refers to at least one specialized hardware, firmware, and / or software level security function associated with a computing device. In some embodiments, "security feature" includes, but is not limited to, specialized hardware, firmware, and / or software level processing to prevent unauthorized access to some or all of the functions of a mobile device, providing access to the location of the mobile device (either in real time or at some time prior to the present), preventing the wipe or reset of the memory of the mobile device, configuring the mobile device with password protection, face recognition, or thumbprint recognition, configuring privacy settings on the mobile device to allow or disallow access to certain data transmitted to or from the mobile device over a communications network to certain recipients, and other security data objects currently understood in the art for such electronic devices. In some embodiments, the "security feature" may comprise a security feature provided by an OEM, carrier, or other provider. In some embodiments, the "security feature" may comprise the FindMy® iPhone® feature associated with an Apple® iPhone®. In some embodiments, the "security features" may include Findmy Device, Google Security, or similar security features for Android, Windows, or other known devices and operating systems, as would be understood by one of ordinary skill in the art in light of this disclosure.In some embodiments, a "security feature" may comprise any security feature associated with a mobile device, including, but not limited to, a security feature capable of disabling the mobile device (i.e., "bricking" the mobile device) upon the occurrence of one or more trigger conditions, and / or a security feature capable of preventing possession, operation, and / or access to, or other use or enjoyment of, the mobile device by any person (e.g., any person other than a user authorized by the security feature or any person who requires a password entry before access). The security features and their associated specialized hardware, firmware, and / or software may be located locally on the mobile device and / or remotely on one or more other computing devices, and the mobile device may communicate with such other devices, e.g., via a communications network.

[0044] As used herein, the term "crack detection routine" refers to at least one specialized hardware, firmware, and / or software diagnostic process for determining external damage to a mobile device, including, but not limited to, screen cracks, camera cracks, and any other surface damage of the mobile device. In some embodiments, the crack detection routine captures an image of the screen of the mobile device (e.g., taking a picture with a camera facing forward toward a reflective surface such as a mirror) or captures an image of the back of the mobile device (e.g., taking a picture with a camera housed on the back of the mobile device while the camera is facing a reflective surface), and transmits one or more images to a processor (either a local processor on the mobile device or an external processor on another device via a communication network). The processor analyzes the one or more images. An agent associated with the external device returns an indication of an invalid indication, an unacceptable condition, or an acceptable condition based on the presence of a crack in the image.

[0045] As used herein, the term "internal diagnostics" refers to diagnostic processing of at least one specialized hardware, firmware, and / or software to determine the operational state and / or performance of any portion of a computing device, or any non-peak condition of the computing device (e.g., slow execution time of internal software, applications, etc.). In some embodiments, the output of the "internal diagnostics" may provide suggestions to a user of the mobile device to improve the performance of the mobile device. In some embodiments, at least a portion of the "internal diagnostics" may be contained and executed locally on the mobile device and / or data generated from the internal diagnostics may be transmitted to an external device, such as a remote validation server, for processing.

[0046] As used herein, the term "authentication credentials" refers to any authentication-related process, data field, and / or input that comprises a data input and / or stored data value that is associated with a user account and / or device and that can be configured to allow access to certain functionality of a computing device.

[0047] As used herein, the term "identification data object" refers to one or more items of electronic data that can be used to identify a computing device as associated with a particular user of the computing device (e.g., a unique identifier). For example, an identification data object may comprise a text string, a numeric character, an alphabetic character, an alphanumeric code, an ASCII character, a pointer, an IP address, a MAC address, a memory address, other unique identifier, or a combination thereof.

[0048] As used herein, the term "provider system" refers to one or more servers, computing systems, or other computing systems associated with a provider. A "provider system" may communicate with a mobile device to enable the provider to provide security functionality to the mobile device over a communications network. In some embodiments, security functionality of the mobile device may be maintained by the provider system external to the mobile device.

[0049] <Overview> In various embodiments, the state of the one or more mobile devices, comprising determining an acceptable state of the one or more mobile devices, is determined locally (on the mobile device) or remotely (via a remote verification server and / or via a web browser). In some embodiments, the acceptable state may confirm functionality of the device. In some embodiments, the acceptable state may determine that the mobile device is serviceable and / or operable by a third party (e.g., a service center may perform further diagnostics or other functions on the mobile device without bricking the phone or disabling additional security features). In some embodiments, the acceptable state may enable a user or owner of the mobile device to accept (e.g., initiate a transaction) a trade-in offer for the mobile device. In various embodiments, the acceptable state of the mobile device may be rendered based on one or more diagnostics (including at least one of an internal diagnostic and / or a screen crack detection routine) performed on the mobile device and / or a remote verification that one or more security features have been disabled on the mobile device. In some embodiments, the state verification, or a portion thereof comprising one or more diagnostics, may be performed via a web browser by code executed via the browser.

[0050] In some embodiments, a mobile device may be equipped with security features that prevent tampering, conversion, or use of the mobile device by unauthorized parties. However, these security features often lack the ability to distinguish between unauthorized users and authorized users who have not been properly onboarded to the mobile device's software, especially when an authorized user is unable to provide the necessary authorization (e.g., situations in which the mobile device has been sold, traded in, turned over to a service center, or otherwise properly given to a third party for use).

[0051] In some implementations, the acceptable state may be rendered only if one or more security features of the mobile device are determined to be disabled. If the remote verification server and / or remote verification circuitry determines that the one or more security features are not disabled, the systems described herein may configure the GUI of the mobile device to disable the one or more security features.

[0052] In some implementations, the methods and systems described herein may be used to diagnostically test security-enabled mobile devices and ensure the functional continuity of the mobile device by disabling security features before they are permitted for use by a third party (e.g., a warehouse trade-in organization that acts as an intermediary between a mobile device seller and a mobile device buyer or end user / buyer of the mobile device).

[0053] In some embodiments, if one or more security features are determined to be enabled on the mobile device, an invalid indication may cause the GUI to instruct the user to disable the security feature (e.g., by rendering an automatic button / input configured to trigger the disablement and / or by rendering instructions to the user). In some embodiments, the invalid indication may be generated upon a determination (e.g., by a processor of one or more of the devices 100, 200) that a security feature of the mobile device is enabled. The invalid indication may be maintained indefinitely to allow a user to correct the indicated problem and / or abandon the process. In some embodiments, a user of the mobile device may disable a security feature of the mobile device such that an acceptable state of the mobile device is generated and the invalid indication is removed. In some embodiments, the invalid indication is removed upon disabling the security feature and the acceptable state may be triggered by detection of the removal of the invalid indication and / or one or more additional triggers (e.g., detection of completion of an internal diagnostic such as a cracked screen detection and / or an internal hardware diagnostic). The disabled indication may allow time for the detected problem with the mobile device to be disabled (e.g., security features are disabled) or otherwise corrected before an unacceptable state (e.g., if the problem is not resolved satisfactorily in time or if the device is not in compliance with the requirements for an acceptable state) or an acceptable state (e.g., if the device is in compliance with the requirements for an acceptable state) is returned. In some embodiments, the disabled indication may indicate that the mobile device is not configured for use by third parties.

[0054] In some embodiments, the user may have a limited or unlimited time to disable the security feature to return an acceptable state. In some embodiments, the remote verification process of the mobile device's state may be paused when the security feature is detected as enabled (e.g., directly after the security feature is detected as disabled or after one or more diagnostics are performed on the mobile device) to allow the user to disable the security feature before the generation of an acceptable state is returned, and the verification process may remain paused until a condition (state) is satisfied or the process is otherwise terminated (e.g., by uninstalling the application, force-closing the application, etc.). In some implementations, if the security feature is still enabled after the security feature is disabled to generate an acceptable state, various embodiments may be configured to generate an unacceptable state. For example, if the security feature of the mobile device is not disabled and / or other detected problems of the mobile device are not corrected, the unacceptable state is returned. The GUI of the mobile device may be configured to terminate the remote verification process such that the user is prevented from completing the process or must restart the process. In some embodiments, the remote verification process of the mobile device's state may be performed multiple times (e.g., infinite times) on the mobile device. In some embodiments, the remote verification of the mobile device's state may allow the mobile device to be processed by the remote verification process of the mobile device's state until an acceptable state is returned. In some embodiments, the external device (e.g., the provider system 305 and / or the remote verification system 307) may limit the number of times the mobile device may be processed by the remote verification process of the mobile device's state.In some embodiments, the remote verification process may comprise a carrier profile having parameters established by one or more carriers (e.g., mobile carriers) that use the remote verification process, which may include optional limits on timeouts and retry counts for the remote verification process that may be selected by participating carriers. In some embodiments, the diagnostics and / or security data object and security feature analysis may be performed at least in part remotely (e.g., via a web browser). In some embodiments, the diagnostics and / or security data object and security feature analysis may be performed at least in part locally (e.g., via an installed application).

[0055] In some embodiments, the remote verification of the state of the mobile device process may configure the GUI of the mobile device to indicate the reason for the unacceptable state (e.g., as shown with respect to FIG. 43). For example, the remote verification of the state of the mobile device process may configure the GUI of the mobile device to show the results of a diagnostic (e.g., an internal diagnostic and / or a screen crack detection routine) to a user. In such an embodiment, the configured GUI may indicate a particular failure of the mobile device of the diagnostic and, via the configured GUI, may show instructions to the user to return to an acceptable state by correcting (fixing) the diagnostic causing the unacceptable state. In some embodiments, the user may correct the mobile device's battery life, the mobile device's screen, the mobile device's camera, the mobile device's microphone, and / or another such cause of one or more failure outputs of a diagnostic executed on the mobile device. In some embodiments, a failure of one or more diagnostics (e.g., an internal diagnostic and / or a screen crack detection routine) may nevertheless be configured to cause the mobile device's GUI to return to an acceptable state if the failure is not a failure of a necessary component for an acceptable state. For example, in some embodiments, failure of one or more diagnostics of a remote verification process of the mobile device's condition on the mobile device may result in a lower trade-in value, but may result in an acceptable status of the remote verification process of the mobile device's condition.

[0056] In some embodiments, the unacceptable state may trigger a fail-safe to prevent the device from being sold, shipped, used, or accepted by a third party (e.g., any transaction involving the mobile device may fail). In some implementations, if the security features are disabled and the GUI is configured to indicate an acceptable state, the user may have a predetermined threshold time to accept an offer associated with the third party (e.g., drop-off, shipping, or trade-in of services). If the offer is not accepted within the predetermined threshold time, the acceptable state may be terminated (e.g., by a processor associated with one or more of the devices 100, 200). The GUI may be configured to display the unacceptable state due to inaction by the user, with the status of the device being returned to an unacceptable state. In some embodiments, the user may be permitted to redo a diagnostic (e.g., internal diagnostics and / or screen crack detection). In some embodiments, at least a portion of the internal diagnostics may be redo. In some embodiments, the internal diagnosis may not stop subsequent downstream processing (e.g., devaluing the device or notifying the device of required services rather than prohibiting processing entirely), which may result in no need to redo the internal diagnosis in the event of a failure or other negative result.

[0057] <System architecture example> The present disclosure provides various embodiments of system architectures related to remote verification of a state of a mobile device. FIG. 1 illustrates an exemplary apparatus (e.g., a server configured to direct verification) for verifying a state of a mobile device, comprising a processor 101, a memory 103, an input / output circuit 104, a communication circuit 105, and a remote verification circuit 102. FIG. 2 illustrates an example of an apparatus for verifying a state of a mobile device, comprising a processor 201, a memory 203, an input / output circuit 204, a communication circuit 205, and a diagnostic circuit 202. The apparatuses 100 and 200 of FIGS. 1-2 can be configured to perform operations as described below using one or more of the circuit components 101-105 and 201-205 embodied in software, hardware, or a combination of software and hardware. Although some components are described at least in part with respect to functional features provided by such components, it should be understood that a particular implementation necessarily involves the use of specific hardware. It should also be understood that some of the components described herein may include similar or common hardware. For example, two described components may perform related functions by using the same processor, network interface, storage medium, etc. (0002) As used herein, the term "circuitry" refers to (a) a hardware-only circuit implementation (e.g., implementation in analog and / or digital circuitry), (b) a combination of a circuit and a computer program product comprising software and / or firmware instructions stored on one or more computer-readable memories that cooperate to cause an apparatus to perform one or more functions described herein, and (c) a circuit that requires software or firmware for operation even when the software or firmware is not physically present, such as, for example, a microprocessor(s) or a portion of a microprocessor(s). This definition of "circuitry" applies to all uses of the term herein, including any claims. As a further example, as used herein, the term "circuitry" also includes implementations that are configured with one or more processors and / or portions thereof and associated software and / or firmware.

[0058] For example, use of the term "circuitry" as used herein with respect to components of devices 100 and 200 should therefore be understood to include specific hardware and associated software configured to perform functions associated with the particular component as described herein. Circuitry should be understood broadly to include hardware and may include processing circuitry, storage media (e.g., non-transitory memory comprising at least some computer program instructions that may define at least some software), network interfaces (e.g., network 301), input / output devices, etc. In some embodiments, other elements of devices 100 and 200 may provide or supplement the functionality of a particular component. For example, processors 101 and 201 may provide processing functionality to other components, memories 103 and 203 may provide storage functionality to other components, and communication circuits 105 and 205 may provide network interface functionality to other components.

[0059] In some embodiments, the processors 101 and 201 (and / or co-processors, or any other processing circuitry supporting or otherwise associated with the processors or devices) can communicate with the memories 103 and 203 via a bus for passing information between components of the devices. The memories 103 and 203 may be non-transitory and include, for example, one or more volatile and / or non-volatile memories. For example, the memories may be electronic storage devices (e.g., computer-readable storage media). The memories 103 and 203 may be configured to store information, data, content, software, applications, instructions, etc. to enable the devices 100 and 200 to perform various functions according to exemplary embodiments of the present disclosure.

[0060] Processors 101 and 201 may be embodied in any one of a myriad of ways, and may, for example, include one or more processing devices configured to execute independently. Additionally or alternatively, processors 101 and 201 may comprise one or more processors configured in tandem via a bus to enable independent execution, pipelining, and / or multithreading of instructions. Use of the terms "processor" and "processing circuitry" may be understood to include, but is not limited to, a single-core processor, a multi-core processor, multiple processors within a device, and / or a remote or "cloud" processor.

[0061] In an exemplary embodiment, the processors 101 and 201 may be configured to execute other computer-coded instructions stored in the memories 103 and 203 or accessible to the processors. Alternatively, or in addition, the processors 101 and 201 may be configured to execute hard-coded functions. Thus, whether configured by hardware or software methods or a combination thereof, the processors 101 and 201 may represent entities (e.g., physically embodied in circuits) capable of performing operations according to embodiments of the present disclosure while configured accordingly. Alternatively, as another example, if the processor is embodied as an executor of software instructions, the instructions may specifically configure the processor to perform the algorithms and / or operations described herein when the instructions are executed.

[0062] In some embodiments, devices 100 and 200 may include input / output circuitry 104 and 204, embodied in hardware, software, firmware, or combinations thereof, which in turn communicate with processors 101 and 201 to provide output to a user and, in some embodiments, receive an indication of user input. Input / output circuitry 104 and 204 may comprise a user interface (e.g., a GUI and / or various other tactile, visual, auditory, or other interfaces for enabling a user to interact with and / or receive information from the device) and include a display (e.g., for rendering one or more user interfaces). The user interface may comprise a web user interface, a mobile application interface, a desktop application interface, or the like. In some embodiments, the user interface may be operated by a linked or networked client device (e.g., a mobile device), a kiosk, or the like. In some embodiments, input / output circuitry 104 and 204 may include software configured to enable capture and / or output of signals and other information to and from a user. In some embodiments, input / output circuitry 104 and 204 may also comprise hardware such as a keyboard, mouse, joystick, display, touch screen, touch area, soft keys, camera, microphone, speaker, or other input / output mechanisms. Processors 101 and 201 may be configured to control one or more functions of one or more user interface elements via computer program instructions (e.g., software and / or firmware) stored on memory accessible to the processor (e.g., memories 103 and 203, etc.).

[0063] Additionally or alternatively, in some embodiments, the devices 100 and 200 comprise communication circuitry 105 and 205. The communication circuitry 105 and 205 may be any means, such as devices or circuitry embodied in either hardware or a combination of hardware and software, configured to receive and / or transmit data from / to a network and / or any other device or circuitry that communicates with the devices 100 and 200. In this regard, the communication circuitry 105 and 205 may comprise a network interface, for example, to enable communication with a wired or wireless communication network (e.g., Bluetooth, WLAN, LAN, cellular, fiber, etc.). For example, the communication circuitry 105 and 205 may comprise one or more network interface cards, antennas, buses, switches, routers, modems, and supporting hardware and / or software, or any other devices suitable for enabling communication over a network. Additionally or alternatively, the communications circuits 105 and 205 may include circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or to process reception of signals received via the antenna(s).

[0064] The memories 103 and 203 may be any suitable local or network storage device(s) configured to store some or all of the information described herein. In addition to the various software components described herein, the memories 103 and 203 may be configured to store, for example, data sets, diagnostic indicators (e.g., output of internal diagnostics executed on the mobile device), screen crack detection results (e.g., output of a screen crack detection routine), and security feature results (e.g., security data objects indicating the activation or deactivation of security features associated with the mobile device 310). As such, the memory 103 may include, for example, one or more database systems, back-end data servers, network databases, cloud storage devices, and the like. While the memories 103 and 203 are illustrated and described herein as a single memory system so as not to unnecessarily overcomplicate the present disclosure, one of ordinary skill in the art will appreciate in light of the present disclosure that any number of connections, arrays, or any number of memories in a device may be used.

[0065] In some embodiments, the device 100 may include a remote verification circuit 102. In some embodiments, the remote verification circuit 102 is embodied in any of software, hardware, firmware, and / or combinations thereof. In this regard, the remote verification circuit 102 comprises software, hardware, firmware, and / or combinations thereof that are specifically configured to facilitate remote verification of the status of a mobile device (e.g., the device 200). In some embodiments, enrollment in the remote verification program may consist of a user downloading an application associated with the remote verification program locally on the mobile device or externally on a computing device associated with the mobile device (e.g., a computing device having remote access to the mobile device with a wired or wireless connection). In some embodiments, enrolling in the remote verification program may comprise a user accessing an external computing system (e.g., device 100) via a web browser or other remote communication software on device 200, or via another computing system (e.g., another computing device associated with the user), to register without installing new software on device 200 (e.g., by accessing existing functionality associated with device 100, 200) or to have device 200 download (e.g., via deep linking) an application associated with the remote verification program. In some embodiments, unenrolling from the remote verification program may include locally deleting the remote verification program on the mobile device (e.g., deleting the app).

[0066] In some embodiments, the remote verification process of the mobile device's state may be initiated by a user selecting an input on a GUI configured to indicate a request to perform a remote verification of the mobile device's state, for example, on a GUI such as that shown in FIG. 18 as configured GUI 1800. For example, the GUI may be configured to request an input by the user (e.g., via a "continue" button 1803) to initiate a remote verification process of the mobile device's state. In some embodiments, the configured GUI 1800 may indicate how the user may perform one or more diagnostics and may include instructions and / or a roadmap of a process such as a screen crack detection routine (e.g., in 1801, the configured GUI may indicate to the user that the user needs a mirror to perform a screen crack detection routine). In some embodiments, the configured GUI 1800 may indicate a predetermined threshold time during which the user may act after receiving an indication of an acceptable state from the remote verification process of the mobile device's state, and the GUI 1800 may provide the necessary information before initiating the verification process. For example, and as shown at 1802, a user may have 24 hours to take the mobile device to a particular location (e.g., a store or a location for shipping the mobile device) before an unacceptable status is returned due to inaction by the user.

[0067] In some embodiments, the remote verification process of the mobile device state may include facilitating the display of one or more extended permission approvals accepted by a user of the mobile device before one or more diagnostics are initiated on the mobile device. For example, the remote verification process of the mobile device state may require the mobile device to be connected to at least one of Wi-Fi, Bluetooth, the Internet, and / or Long Term Evolution (LTE), which may be displayed as a configured GUI similar or identical to the GUI of FIG. 19, such as GUI 1900 of indicators 1901. In some embodiments, the remote verification process of the mobile device state may include one or more permissions accepted by a user before one or more diagnostics are initiated on the mobile device, such as permissions to access at least one of Bluetooth, the mobile device camera, and / or Wi-Fi, as shown at 1902 in FIG. Enhanced permissions may be granted by selecting a button (e.g., button 1903) on GUI 1900 that may use mobile device OS permission functionality to render a subsequent interface menu for granting the requested permissions.

[0068] In some embodiments, the remote verification process of the mobile device's status may be initiated by a user entering into a GUI an identification data object, such as an IMEI number or phone number, associated with the mobile device whose status is to be verified. In some embodiments, the identification data object may be transmitted over a network from the mobile device 310 local to the provider system 305 or from the remote verification system 307 to the provider system 305. In some embodiments, the remote verification system 307 and / or the provider system 305 may match the identification data object entered by the mobile device's user with identification data objects stored in either the provider system 305 storage subsystem linked to the mobile device and / or the remote verification system 307 storage subsystem. In some embodiments, a new identification data object may be created based on the identification data object entered by the user (e.g., in instances where the device has no existing data). In some embodiments, the identification data object may be user agnostic and may only be stored in association with the device (e.g., the user may be irrelevant when the device is verified). In some embodiments, an identification data object may be manually entered by a user (e.g., by image capture, filling in blanks, etc.) and a second identification data object may be transmitted from the mobile device from memory (e.g., an encoded IMEI from the mobile device software). Comparing the two identification data objects confirms that the user is sending a verification request for the same device they own, and by verifying that the request is authentic, authentication can be provided without requiring verification of the user's identity or an existing account or data set stored in the verification system 307.

[0069] In some embodiments, the stored identification data object may be stored in a policy (e.g., a warranty policy, a carrier plan policy, etc.) linked to the user and / or the mobile device itself and may be used to provide one or more services related to the verification, such as warranty repair. In some embodiments, if the identification data object entered by the user does not match a stored identification data object associated with and stored in the provider system and / or the remote verification system, the remote verification process of the mobile device's state may stop, thereby terminating the remote verification process of the mobile device's state. In some embodiments, if the identification data object entered by the user does not match a stored identification data object stored and associated with the mobile device in the provider system and / or the remote verification system, the remote verification process of the mobile device's state may pause and the GUI of the mobile device may be configured to request a new input by the user of the correct identification data object. In some embodiments, the remote verification of the mobile device's state may allow the user an unlimited number of entries of identification data objects before continuing with the remote verification of the mobile device's state (e.g., processing the mobile device using one or more diagnostics and / or determining whether security features are enabled or disabled, etc.). In some embodiments, the remote verification process of the state of the mobile device may limit the user to a certain number of entries of the identification data object before terminating the remote verification process. In some embodiments, the remote verification circuit 102 may be embodied with any means for allowing initiation of one or more remote verification requests to perform a remote verification of the state of the mobile device. In some embodiments, the remote verification circuit 102 may be configured to verify the state of security features on the mobile device.In some embodiments, additionally or alternatively, the remote verification circuit 102 is configured to cause termination of security functionality on the mobile device as a request to execute a remote verification condition of the mobile device that has been initiated and / or processed. In some such embodiments, for example, the remote verification circuit 102 may be configured to perform one or more diagnostics on the mobile device, including, but not limited to, generating and / or transmitting one or more security data objects associated with the mobile device and determining whether security functionality associated with the mobile device is enabled or disabled. In some embodiments, the remote verification circuit 102 may be configured to cause signals, computer program instructions, and / or other information to be transmitted to and / or from the mobile device. In some embodiments, the remote verification circuit 102 may be configured to cause signals, computer program instructions, and / or other information associated with the mobile device to be transmitted to and / or from one or more third-party computing devices (e.g., in instances where verification of the state of the mobile device is requested or reported to a third party, in instances where verification of the state of the mobile device requires querying a third-party system, and / or the like).

[0070] In some embodiments, the apparatus 200 comprises a diagnostic circuit 202. In some such embodiments, the diagnostic circuit 202 is embodied in any of software, hardware, firmware, and / or combinations thereof. In this regard, the diagnostic circuit 202 may be embodied in any means for enabling initiation and / or execution of diagnostics executed on the mobile device, processing of diagnostic indicators (e.g., output of diagnostics executed on the mobile device), storage of diagnostic indicators of the mobile device, and / or transmission of diagnostic indicators to one or more servers (including an internal server or an external server of the mobile device) and / or the device (e.g., a remote verification server 307 or a provider system 305). In some such embodiments, for example, the diagnostic circuit 202 may be configured to perform one or more diagnostics of the mobile device, including, but not limited to, verification of the state of security features associated with the mobile device, crack detection routines (described in more detail below), and / or internal diagnostic tests (described in more detail below). Additionally or alternatively, in at least some embodiments, the diagnostic circuitry 202 is configured to obtain conditions of the mobile device, such as the mobile device model type, mobile device storage capacity, mobile device software capabilities, and other such information of the mobile device, for example, via communication with a provider system (e.g., as shown at 305 in FIG. 3 ), and verify that the mobile device is operating at a predetermined capacity to pass the diagnostic test(s) performed by the diagnostic circuitry 202.

[0071] In some embodiments, one or more of the components of the devices 100 and 200 may share hardware, eliminating duplication of hardware requirements. Additionally or alternatively, in some embodiments, one or more components (e.g., 101, 102, 103, 104, 105; 201, 202, 203, 204, 205) may be embodied as a single element such that the single element comprises means configured to perform the operations of two or more components (e.g., 101, 102, 103, 104, 105; 201, 202, 203, 204, 205). For example, in at least one embodiment, the remote verification circuitry 102 and the processor 101 are combined into a processing circuit. For example, in at least one embodiment, the diagnostic circuitry 202 and the processor 201 may also be combined into a component embodied in a processing circuit. Additionally or alternatively, one or more of the circuits (e.g., 101, 102, 103, 104, 105; 201, 202, 203, 204, 205) may be embodied with two or more sub-circuits that are communicatively linked and separate.

[0072] FIG. 3 illustrates an exemplary system architecture according to various embodiments of the present disclosure. The system architecture may include a network 301, one or more mobile devices 310A, 310B, ..., 310N (hereinafter collectively referred to as 310), a provider system 305, and a remote verification system 307. The mobile devices 310 may be communicatively connected to the provider system 305 and / or the remote verification system 307 via the network 301. The mobile devices 310 include electronic devices such as smartphones, watches, tablets, e-readers, laptops, or other devices. In some embodiments, the mobile devices 310 may comprise the circuitry shown and described with respect to the device 200 of FIG. 2. In some embodiments, the remote verification system 307 is comprised of the circuitry shown and described with respect to the device 100 of FIG. 1. In some embodiments, the provider system 305 may be comprised of the circuitry shown and described with respect to at least the processor 101, the memory 103, the input / output circuitry 104, and / or the communication circuitry 105 of the device 100 of FIG. 1. The mobile device may include hardware and / or software components capable of taking external images of itself (e.g., one or more cameras configured to capture a reflection of the device in a mirror), components capable of locking the mobile device (e.g., security feature(s) of the mobile device), and components capable of running diagnostics on the mobile device (e.g., one or more internal diagnostic programs). A remote verification system 307 may be communicatively connected to the provider system 305 and the mobile device 310 via the network 301. In some embodiments, the remote verification system 307 may be the apparatus 100 shown and described with respect to FIG. 1. In some embodiments, the remote verification system 307 may comprise a remote verification circuit (described in more detail below) used to perform remote verification of the status of the mobile device(s) 310.For clarity, FIG. 3 depicts only remote verification system 307, provider system 305, network 301, and mobile device 310, but for purposes of this disclosure, it is understood and will be appreciated that there may be numerous additional iterations of each, or any other systems and computing devices associated with the systems, apparatus, and methods disclosed herein.

[0073] Network 301 may include one or more wired and / or wireless communication networks, including, for example, a wired or wireless local area network (LAN), a personal area network (PAN), a metropolitan area network (MAN), a wide area network (WAN), etc., as well as any hardware, software, and / or firmware for implementing the one or more networks (e.g., network routers, switches, hubs, etc.). For example, network 301 may include cellular (e.g., mobile devices), mobile broadband, Long Term Evolution (LTE), GSM / EDGE, UMTS / HSPA, IEEE 802.11, IEEE 802.16, IEEE 802.20, WiFi, and / or WiMax networks. Additionally, network 301 may include a public network, such as the Internet, a private network, such as an intranet, or any combination thereof, and may utilize a variety of currently available or later developed networking protocols, including, but not limited to, TCP / IP-based networking protocols.

[0074] The remote verification system 307 can receive data from, transmit data to, and communicate with the mobile device 310 and the provider system 305 over one or more networks 301. The remote verification system 307 can utilize, generate, store, process, request, transmit, modify, and otherwise use and track data sets received from the mobile device 310, diagnostic indicators (e.g., output of internal diagnostics run on the mobile device), screen crack detection results (e.g., output of a screen crack detection routine), and security feature results (e.g., security data objects associated with enabling or disabling security features associated with the mobile device 310), among others.

[0075] The remote verification system 307 may comprise circuitry, one or more networked processors, etc., configured to perform some or all of the server-based processing described herein, and may be any suitable network server and / or other type of processing device. In some embodiments, the remote verification system 307 may comprise circuitry as described herein (e.g., with respect to the device 100 shown in FIG. 1 ) configured to send indicators to the mobile device(s) 310, the provider system 305, and / or another third party device to instruct the respective devices / systems to perform diagnostics, and to receive data and information related to determining whether the mobile device(s) are in an acceptable state. In some embodiments, some or a portion of the verification processing disclosed herein may be performed locally on the mobile device(s) and / or remotely on the remote verification system 307, the provider system 305, and / or another third party device without departing from the scope of the present disclosure.

[0076] In some embodiments, the remote verification system 307 may function as a unified "cloud" with respect to the mobile device 310 and the provider system 305. The remote verification system 307 may comprise multiple servers performing interconnected and / or distributed functions. To avoid unnecessarily overcomplicating the present disclosure, the remote verification system 307 is shown and described herein as a single remote verification system, but those skilled in the art will appreciate in light of the present disclosure that any number of servers and / or similar computing devices may be used. In some embodiments, and with reference to FIG. 1, the remote verification system 307 may comprise a processing circuit 100, a processor 101, a memory 103, an input / output circuit 104, a communication circuit 105, and a remote verification circuit 102 for facilitating various functions described herein, which functions may be embodied as hardware, software, or a combination of hardware and software. As described herein, the processing circuit 100 may be comprised of one or more processors 101, which may comprise local, networked, or remote processors, or other processing means known in the art.

[0077] Example Data Flows and Operations 4 shows a flow chart according to an example method 400 for providing remote verification of a mobile device's status when security features are enabled, according to some example embodiments. In this regard, FIG. 4 illustrates operations that may be performed at and / or by a remote verification system 307 (e.g., computing device 100, etc.) and / or through cooperation with one or more computing devices 100 and / or 200 comprising mobile device(s) 310. The operations illustrated and described with respect to FIG. 4 may be performed by, with the assistance of, and / or under the control of, for example, one or more of the devices discussed herein (e.g., devices 100 and / or 200) comprising processor 101, memory 103, communication circuitry 105, remote verification circuitry 102, or input / output circuitry 104, processor 201, memory 203, communication circuitry 205, diagnostic circuitry 202, and input / output circuitry 204. In some embodiments, processes that require operation of the mobile device 310 (e.g., a subset of diagnostic tests that are instantiated on the mobile device and / or require hardware or software feedback from the mobile device) are executed on the mobile device. In some embodiments, processes that are executed remotely from the mobile device (e.g., a request for verification of the state of the mobile device initiated by a remote server when the mobile device is not available for testing) may be executed on or by one or more remote equipment(s) separate from the mobile device being verified (e.g., via the provider system 305, the remote verification system 307, or another third party device). Other processes that are wholly or partially device independent (e.g., a process for obtaining or requesting metadata associated with the mobile device from a third party server) may be executed on any of the aforementioned devices.

[0078] In block 401, the apparatus 100 and / or 200 includes means, such as the remote verification circuitry 102 and / or diagnostic circuitry 202, the communication circuitry 105 and / or 205, the input / output circuitry 104 and / or 204, the memory 103 and / or 203, and the processor 101 and / or 201, or a combination thereof, so that it can receive a request for verification of the state of the mobile device from a user of the mobile device. In some embodiments, the request for verification may be triggered by the user selecting a particular input on the GUI of the mobile device (e.g., the input may include a visual representation of a button shown on the mobile device interface, such as a "Start" button or a "Continue" button), or an input on the GUI of a computing device associated with the mobile device, if remote. In some embodiments, the request for verification may be triggered by the user opening and interacting with an application (e.g., an app) associated with the remote verification program on the mobile device, or on a computing device associated with the mobile device, if remote. In some embodiments, the request for verification may be triggered by a third party computing device requesting verification of the state of the mobile device. In some embodiments, the third party request may occur after a user of the mobile device requests diagnostics to be performed on the mobile device to initiate or complete a remote verification process on the mobile device. For example, a user or third party may initiate a "trade-in," "resale," "warranty," "insurance purchase," "protection program enrollment," or similar function that may require verification of the status of the mobile device, and the mobile device, another device associated with the user, or a device associated with a third party (e.g., provider) may initiate the request for verification as part of the requested function.Upon initiation, either directly on the mobile device or via a third party device or browser, the request may be sent to a remote verification circuit 102 in the device or to a remote verification system 307 that may operate in conjunction with the mobile device to determine the state of the mobile device (e.g., an invalid indicator of the mobile device, an unacceptable indicator, or an acceptable state of the mobile device). In some embodiments, the verification process may be initiated and / or executed via a web browser or other remote operation instead of or in addition to being determined locally. For example, in some embodiments, at least a portion of the verification process may be configured with code executed on the mobile device, and in some embodiments, at least a portion of the verification process may be configured with code executed via a web browser with or without verification code executed on the local device. In some embodiments, the local (e.g., app) and / or remote (e.g., web browser) based verification GUI may include a skinned interface configured to express one or more third party design languages. Additionally or alternatively, at least a portion of the verification process may be configured with code executed via one or more remote servers, as described herein.

[0079] In some embodiments, when a request for verification of the state of the mobile device is received, the operation may continue at block 402 with the mobile device performing one or more diagnostics. In some embodiments, at block 408, the apparatus 100, 200 may then determine whether the mobile device passed the diagnostics according to various embodiments discussed herein. Additionally or alternatively, when a request for verification of the state of the mobile device is received, at block 403, the remote verification system 307 and / or the remote verification circuit 102 may receive at least one security data object associated with the mobile device. In some embodiments, the security data object may be stored locally on the mobile device, or the security data object may be stored on another system, such as a provider system (e.g., memory associated with the provider system 305). For example, when a security feature is first enabled, the mobile device may send an indication that the security feature is enabled to another system, such as the provider system, which may be stored as a data object in memory for future retrieval without direct interaction with the mobile device. In some embodiments, security data objects indicating the status of security features are stored external to the mobile device (e.g., in a provider system 305 such as an Apple server for storing the FindMy® iPhone® feature) and a separate program (e.g., Apple® Global Services Exchange (GSX)) can be used to disable the externally stored security features. In some embodiments, the remote verification system 307 can query a verification API (application programming interface) such as Apple® GSX to access the security features of the mobile device.A user of a mobile device may enable and / or disable a security feature on a mobile device by sending a request to an external server (e.g., Apple's GSX) that contains a data object related to the security feature before sending a security data object of the security feature comprising an indication of enablement or disablement to the mobile device and / or a remote verification system. The security feature may be toggled before sending a security data object of the security feature comprising an indication of enablement or disablement to the mobile device and / or a remote verification system for remote verification of the state of the mobile device and / or mobile device processes. In some embodiments, the mobile device and / or the remote verification system may send computer-executable instructions to a verification API (e.g., associated with a third party server) to cause the third party server to disable the security feature. In some embodiments, as discussed herein, a security data object that controls the state of a security feature may instead be contained on the mobile device such that the setting can be changed locally.

[0080] When a request to verify the state of the mobile device is received, the remote verification system 307 and / or the remote verification circuit 102 may determine whether a security feature of the security data object (e.g., a security feature associated with the mobile device) is enabled. In some embodiments, the remote verification system 307 and / or the remote verification circuit 102 may determine whether the mobile device is jailbroken or rooted (e.g., whether the software / hardware of the mobile device has been bypassed to allow a user to control certain core functions of the mobile device), which may serve as a threshold for the processing described herein (e.g., if the device is jailbroken or rooted, processing does not proceed). In some embodiments, the remote verification system 307 and / or the remote verification circuit 102 may determine the age of the mobile device as well as the predetermined warranty period for the mobile device. In some such embodiments, if the remote verification system 307 and / or the remote verification circuitry 102 determines that the mobile device is within the predetermined warranty period, a data object comprising an indication that the mobile device is within the warranty period may be transmitted to another system, such as a provider system, which may store the indication as a data object in memory for future retrieval without directly interacting with the mobile device. In some embodiments, if the age of the mobile device indicates that the mobile device is outside the predetermined warranty period, processing of one or more diagnostic and security data objects may not be processed by the remote verification system 307.

[0081] At block 404, the depicted process determines that the security feature associated with the security data object is enabled. In some embodiments, if a request to verify the mobile device state is received to determine that the security feature is enabled, then at step 405, the remote verification system 307 or the remote verification circuitry 102 renders a GUI configured to facilitate disabling of the security feature, which may be displayed locally on the mobile device or remotely from the mobile device on an alternative user interface (e.g., an iPad, computer, etc., which may be associated with the same user of the mobile device or the mobile device itself). In some embodiments, step 405 may be completed without receiving a security data object associated with the mobile device. For example, the GUI may be configured to facilitate automatically disabling the security feature of the mobile device without a real-time indication from the remote verification system 307 or the remote verification circuitry 102 indicating that the security feature is enabled.

[0082] In some embodiments, steps 402, 403, 404, and 405 may be rendered sequentially such that when a verification request is received regarding a mobile device condition at 401, the remote verification system causes the mobile device to perform a diagnosis at 402. After the mobile device performs a diagnosis at block 402, the remote verification system receives at least one security data object associated with the mobile device at block 403. After the remote verification system receives at least one security data object associated with the mobile device at 403, at step 404, the remote verification system 307 and / or the remote verification circuitry 102 may determine that a security feature of the security data object is enabled at block 404. After the remote verification system 307 and / or the remote verification circuitry 102 determines that a security feature of the security data object is enabled at block 405, the remote verification system 307 and / or the remote verification circuitry 102 may render a GUI configured to facilitate disabling of a security feature.

[0083] In some embodiments, steps 402, 403, 404, and 405 may be triggered sequentially when a verification request is received in the mobile device state at 401, such that the remote verification system causes the mobile device to receive at least one security data object associated with the mobile device. After the remote verification system receives at least one security data object associated with the mobile device at 403 in step 404, the remote verification system 307 and / or the remote verification circuit 102 may determine that a security feature of the security data object is enabled in block 404. After the remote verification system 307 and / or the remote verification circuit 102 determines that a security feature of the security data object is enabled in block 405, the remote verification system 307 and / or the remote verification circuit 102 may render a GUI configured to facilitate disabling the security feature. In some embodiments, once the security feature is disabled, processing may then proceed to perform diagnostics in 402. In some embodiments, the system holds processing and refuses to proceed until the security feature is disabled. At block 403, after the mobile device performs the diagnostics at block 402, the remote verification system may render a GUI configured to display the value of the mobile device (e.g., trade-in value). In some embodiments, the diagnostic(s) may be performed prior to or in parallel with the verification and disabling of security features.

[0084] In some embodiments, if the security feature is enabled, the remote verification may fail and an indication of an unacceptable state may be sent. In some embodiments, if the security feature is enabled, a disabled indication is sent (e.g., from the remote verification system 307 and / or the remote verification circuitry 102 to the mobile device), the user of the mobile device has been instructed to disable the security feature to return to an acceptable state, and the remote verification process of the state of the mobile device is paused or stopped until the security feature is determined to be disabled (e.g., the process is stopped until an indication to disable the security feature is received). If the security feature is disabled, the remote verification of the state of the mobile device may return an "acceptable state" of the mobile device, assuming other criteria are also met, without resuming the remote verification process (e.g., performing diagnostic(s) and / or determining that the security features of the mobile device are enabled or disabled). In some embodiments, the acceptable state of the mobile device may be limited to a predetermined threshold time, and if the predetermined threshold time has elapsed without further processing via the remote verification process, the remote verification process may time out even in instances where the mobile device has met all the necessary states (conditions) for an acceptable state. For example, if the remote verification process times out of an acceptable state of the mobile device (after a predefined threshold time), the remote verification process may be resumed upon resumption by the user / third party at step 401. In some embodiments, once the acceptable state of the mobile device times out (i.e., after a predefined threshold time has elapsed), an unacceptable state may be rendered via the GUI.

[0085] In some embodiments, the remote verification process may be performed in whole or in part via an application (i.e., an "app") downloaded to the mobile device to be stored locally on the mobile device. For example, the remote verification process may be performed by a service-related app (e.g., an application designed to provide services to users of the mobile device, such as trade-in services, warranty services, insurance services, etc.) downloaded onto the mobile device such that the remote verification program may access local data within the mobile phone after receiving authorization to access such data or may otherwise interrogate portions of the mobile device to request necessary data. In some embodiments, the remote verification program executed via the mobile device app is continuously running on the mobile device and may continuously collect data based on historical and real-time diagnostic data generated by diagnostics performed on the mobile device. In some embodiments, the remote verification of the state of the mobile device process may store (either locally on the mobile device or externally via transmission of data over a network to an external storage subsystem associated with the application) an analysis of the mobile device based on one or more historical and current diagnostic(s) performed on the mobile device by the remote verification of the state of the mobile device process of the mobile device. In some embodiments, the remote verification system 307 may store historical data associated with the mobile device comprising one or more previous diagnostics performed on the mobile device and / or current diagnostics performed on the mobile device during a current process of remote verification of the mobile device's state. In some embodiments, the historical data may include normal operating data (e.g., battery life, storage capacity, etc.) saved over time from the mobile device.In some embodiments, the remote verification system 307 and / or the provider system 305 can query historical data and / or current data stored in the remote verification system 307 to determine past failures of the mobile device, past instances of fraud, and / or past instances of failure of one or more diagnoses of the mobile device. In some embodiments, the storage of historical and current data of the mobile device in the remote verification system 307 may include an identification data object associated with the mobile device (e.g., an IMEI number, a phone number, and / or an analytical identifier associated with a particular mobile device) to identify and match the current mobile device and / or the current remote verification process using the correct identification data object with the stored historical and current data of the mobile device in the remote verification system. As described herein, in some embodiments, the identification data object may be associated with the device only, the user only, or both.

[0086] In some embodiments, the remote verification process may be performed at least partially outside the mobile device. In some embodiments, the remote verification process may be performed in whole or in part on an information system accessible via the Internet (e.g., the Web). For example, software associated with the remote verification program may be installed and executed on a computing device accessible to the mobile device via network 301. In some embodiments, the remote verification program may not require a download and may only require that the mobile device (or a computing device associated with the mobile device) access a webpage or website and authorize the webpage or website to access data associated with the mobile device.

[0087] In some embodiments, the remote verification process may comprise a combination of functions performed locally on the mobile device and functions performed externally. For example, in some embodiments, diagnostic or other data collection processes that must be performed on the mobile device or that are otherwise performed or enabled to be performed on the mobile device may be performed remotely based on electronic communication with the mobile device, while processes that utilize one or more of these types of data (e.g., analysis of the data and / or coordination with third party systems) may be performed remotely based on electronic communication with the mobile device. In some embodiments, an external computing device may direct or instruct one or more diagnostic or other data collection processes that may then be executed on the mobile device.

[0088] In some embodiments, software associated with the remote verification program may be packaged in a software development kit (SDK) for use in creating applications of the remote verification program on a particular platform. For example, the remote verification program may be regenerated on a particular platform, such as Android®, iOS®, and other such platforms known in the art. The software development kit SDK package may be configured with libraries of the remote verification program, code samples, procedures, and guides for users of the software development kit SDK to develop their own remote verification program apps.

[0089] In some embodiments, if the security data object indicates that a security feature on the mobile device is enabled, the remote verification may cause the security feature of the security data object to be disabled in step 406. In some embodiments, after block 406, the remote verification system may determine an acceptable state of the mobile device in block 407 once the security feature of the security data object has been disabled on the mobile device. In some embodiments, such disabling of the security feature may be performed locally (e.g., on the mobile device) or remotely (e.g., on another computing device associated with the mobile device via an account associated with the user of the mobile device).

[0090] In some embodiments, the GUI may be configured to facilitate disabling security features of the mobile device at step 406, as seen in the exemplary embodiment of FIG. 15. In the depicted embodiment, the GUI 1500 shows information about the mobile device on which the software is installed, including the make, type, model, and storage of the mobile device, as seen at 1501. In some embodiments, the GUI 1500 may show instructions 1507 for disabling security features of the mobile device. In some embodiments, the GUI 1500 may include an input, as shown at 1504, consisting of a visual representation of a button shown on the mobile device interface, such as a “Proceed” button, to proceed with remote verification of the mobile device's status. In some embodiments, the GUI 1500 may display written instructions to enable a user to manually disable security features. In some embodiments, the GUI 1500 may facilitate programmatic or semi-programmatic disabling of security features. For example, the user may select "Continue" or another input, and software associated with the GUI may then open a settings application, which allows the user to access an enable / disable security feature screen to disable the security feature (e.g., semi-programmatically). In some embodiments, security settings in the operating system of the mobile device may limit the degree of setting changes and interface options that may be programmatically accessed without user input, and the systems and software disclosed herein may be configured to tailor the disable process to bring the user as close to the correct interface as possible within the limitations of the operating system. In some embodiments, an authentication prompt may be displayed in connection with any of the aforementioned disable processes, requiring the user to verify their identity (e.g., a password, fingerprint, facial recognition, a passcode such as a pin, or other authentication) before disabling the security feature.In some embodiments, once the security features are disabled, the GUI may be configured to show a "Proceed" button 1504 (e.g., as shown in FIG. 15), which may be selected to configure the GUI as shown, for example, in FIG. 16. For example, if a user selects input 1504 and it is determined that the security features are disabled, the GUI may be configured to show a post-acceptance state, such as the exemplary GUI shown in FIG. 16, which is described in more detail below. In some embodiments, the GUI may be configured to have an input configured to display offers for any subsequent steps of analysis, maintenance, or other operations related to the mobile device or the mobile device based on the disabling of the security features.

[0091] In some embodiments, the remote verification process of the mobile device's state may include a GUI configured to indicate that the security features are being checked or verified to ensure that the security features are disabled, such as a dynamic graphic indicating that the security features are being checked as shown at 3602. In some embodiments, the remote verification process of the mobile device's state may configure the GUI of the mobile device in a manner similar or identical to that shown in GUI 3600 of FIG. 36. In some embodiments, GUI 3600 may include a link to obtain or otherwise access to display a help page to instruct the user to disable the security features of the mobile device. In some embodiments, GUI 3600 includes a button (e.g., "recheck" (check again) button 3605) to recheck the state of the security features in instances in which the security features were determined to be enabled, where the security features may be rechecked an infinite number of times during the remote verification process of the mobile device's state.

[0092] In some embodiments, the GUI may be configured to indicate that the security feature is still enabled after checking the status of the security feature via a search for a security data object, as shown in GUI 3700 of FIG. 37. In some embodiments, GUI 3700 may be configured with a pop-up window with one or more options to continue the remote verification process of the mobile device's state. For example, the pop-up window of FIG. 37, or another similar display, may be configured with an input for the user to select with an indication that the security feature is still enabled and with the ability to return to a previous step in the remote verification process of the mobile device's state (e.g., "back" button 3702), and / or with an input to continue an attempt to disable the security feature (e.g., "continue" button 3703), which may be configured to direct the user to a settings menu or other process to disable the security feature, according to various embodiments discussed herein. In some embodiments, the GUI may be configured to indicate that the security feature has been disabled. For example, GUI 3800 of FIG. 38 may indicate that the security feature has been disabled by a graphic and / or text, as shown at 3801. Following display of indicator 3801, GUI 3800 may redirect to the next step in the verification process or may display a button to allow the user to continue, according to various embodiments described herein.

[0093] In some embodiments, the GUI may be configured to facilitate disabling the security features of the mobile device at step 406, as seen in the exemplary embodiment of FIGS. 33-35. In some embodiments, the GUI 3300 may show instructions 3301 to allow a user to disable the security features of the mobile device. In some embodiments, the GUI 3300 may include a link (e.g., link 3302) to open the settings of the mobile device to at least semi-programmatically disable the security features of the mobile device. In some embodiments, the GUI 3300 may include an input, such as the input shown at 3303, consisting of a visual representation of a button shown on the mobile device interface, such as a "continue" button, to continue with the remote verification of the mobile device's state. In some embodiments, the user may have selected link 3302 to proceed to the settings of the mobile device, and the GUI may be configured to display GUI 3400. In some embodiments, the GUI of 3400 may include an indication that the security features are enabled (e.g., "on"), such as the security feature indication of 3401. In some embodiments, the settings page of GUI 3400 may include one or more types of security features, such as a smart lock (e.g., 3402) and / or a SIM card lock (e.g., 3403). In some embodiments, the security features may be disabled by a toggle button, such as shown at 3501 in GUI 3500 of FIG. 35, following a selection in a menu (e.g., GUI 3400). In some embodiments, the user may select the security features to be enabled or disabled using a toggle, button, and / or binary switch (e.g., toggle 3501).

[0094] In some embodiments, the diagnostic test(s) of block 402 may be configured with external diagnostics, such as a screen crack detection routine (described in more detail below) or a digitizer / touch screen test (described in more detail below), and / or internal diagnostics (described in more detail below).

[0095] <Diagnostic Test> 5 shows a flow chart according to an example method 500 for providing remote verification of a mobile device's status according to some example embodiments. The operations shown and described with respect to FIG. 5 may be performed by, with the assistance of, and / or under the control of, for example, one or more of the devices discussed herein (e.g., devices 100 and / or 200) including processor 101, memory 103, communication circuitry 105, remote verification circuitry 102, or input / output circuitry 104, processor 201, memory 203, communication circuitry 205, diagnostic circuitry 202, and input / output circuitry 204. In some embodiments, processing requiring operation of the mobile device 310 (e.g., a subset of diagnostic tests instantiated on the mobile device and / or requiring hardware or software feedback from the mobile device) is performed on the mobile device. In some embodiments, operations that are performed remotely from the mobile device (e.g., a request for verification of a mobile device's state initiated by a remote server when the mobile device is unavailable for inspection) may be performed on or by one or more remote device(s) separate from the mobile device being verified (e.g., via the provider system 305, the remote verification system 307, or another third party device). Other operations that are wholly or partially device independent (e.g., a process for retrieving or requesting metadata associated with a mobile device from a third party server) may be performed on any of the aforementioned devices.

[0096] In block 501, the device 100 and / or 200 includes means such as the remote verification circuit 102 and / or diagnostic circuit 202, the communication circuit 105 and / or 205, the input / output circuit 104 and / or 204, the memory 103 and / or 203, and the processor 101 and / or 201, or a combination thereof, and can receive a verification request for a mobile device status of the mobile device from a user of the mobile device, or from some communication generated by the mobile device, or by the remote verification system 307. The request can be sent to the remote verification circuit 102 in the device, or to the remote verification system 307 that works in combination with the mobile device to provide an invalid indication of the mobile device, to provide an unacceptable status of the mobile device, and / or to provide an acceptable status of the mobile device. For example, in some embodiments, a user can initiate a claim, trade-in, or other transaction with a third party (e.g., a provider system) and / or the remote verification system, and can then communicate with each of the devices and systems described herein to initiate the remote verification process. The user may initiate the process via the mobile device (e.g., by downloading an app such as the service-related app described above), via other communication to a party identified herein (e.g., via a web browser or other communication interface on another computer), or via direct communication with a party (e.g., by visiting a retailer or calling a helpline and initiating a remote verification process from the retailer's / helpline's computing system). In some embodiments, a third party computing system (e.g., a computing system associated with a party identified herein, which may include a retailer of the mobile device) may determine the eligibility of the mobile device for the process(es) described herein based on an identification data object associated with the mobile device. In some embodiments, the identification data object may include the IMEI number of the mobile device.In some embodiments, the process(es) described herein may be device and / or user agnostic, such as allowing a user to initiate a remote verification of a mobile device without an existing account or to initiate a verification of the mobile device's eligibility for participation in the process(es). In such embodiments, the remote verification system may return an acceptable or unacceptable status and provide the results to a third party computing system for a determination of eligibility and / or next steps. In some embodiments, eligibility may be verified manually. In block 502, and in some embodiments, once a request for verification regarding the mobile device's status is received, the operation may continue in block 502 to have the mobile device perform diagnostic(s). Blocks 501 and 502 may operate substantially similarly to blocks 402 and 408 of FIG. 4. In some embodiments, the diagnostic test(s) of block 502 of FIG. 5 may include a screen crack detection routine and / or internal diagnostics according to any of the embodiments described herein or combinations thereof. FIG. 6 illustrates a flow chart according to an exemplary method for performing internal diagnostics according to some exemplary embodiments. FIG. 7 illustrates a flow chart of an example method for performing a screen crack detection routine according to some example embodiments.

[0097] FIG. 6 may be performed in and / or by example apparatus 100 and / or 200, as seen in FIG. 1 and FIG. 2, respectively. For example, the operations illustrated in and described with respect to FIG. 6 and FIG. 7 may be performed by, with the assistance of, and / or under the control of, one or more of apparatus 100 and / or 200, processor 101 and / or 201, communication circuitry, memory 103 and / or 203, input / output circuitry 104 and / or 204, remote verification circuitry 102, and / or diagnostic circuitry 202. In some embodiments, some or all of the operations illustrated in FIG. 6 may be initiated by remote verification system 307 (e.g., computing device 100, etc.) and / or by or through cooperation with one or more computing devices 100 and / or 200 comprising mobile device 310. For example, the diagnosis itself may in some embodiments be performed by the mobile device(s) in response to a command from the remote verification system and the results transmitted to the system for further analysis. Similarly, the operations illustrated in and described with respect to FIG. 7 may be performed by, with the assistance of, and / or under the control of, one or more of the devices 100 and / or 200, the processors 101 and / or 201, the communications circuitry, the memories 103 and / or 203, the input / output circuitry 104 and / or 204, the remote verification circuitry 102, and / or the diagnostic circuitry 202.

[0098] In some embodiments, the diagnostic(s) performed on the mobile device in block 402 / 502 may include internal diagnostics that may determine the state of one or more internal diagnostic indicators associated with one or more operational parameters of the mobile device. The operational parameters associated with the internal diagnostic indicators may be associated with operational categories of the mobile device (e.g., the operational parameters may include performance data associated with categories such as battery life, signals, processor, storage, audio, settings, commands, status updates, applications, physical damage to the mobile device, liquid damage to the mobile device, etc.). The actual measured operational parameters of the mobile device may be compared to acceptable values ​​for the same parameters to determine whether the mobile device passes the diagnostics for each parameter tested. The acceptable values ​​may be predetermined (e.g., stored in memory after empirical testing in a controlled environment) or may be determined by a computing system (e.g., device 100) by aggregating operational parameters from multiple other mobile devices. In some embodiments, the operating parameters of the associated internal diagnostic indicators may be compared to acceptable values ​​determined in the mobile device (e.g., the acceptable values ​​may be determined by the mobile device provider / manufacturer, a third party associated with the process, etc.). In some embodiments, the acceptable values ​​may be updated remotely from the mobile device by the provider system 305 and / or the remote validation system 307 and released immediately after an update (e.g., asynchronously) or at predetermined intervals along with other software and / or hardware updates in a standard release cadence. In some embodiments, the internal diagnostic tests may also include extracting background data of the mobile device, including the mobile device serial number, the make and model of the mobile device, the storage capabilities of the mobile device, and any other data contained in the mobile device specifications.In some embodiments, an operational category may refer to a single layer of data related to a mobile device. In some embodiments, an operational category may be configured with layers of data having one or more layers of data within the category (e.g., operational subcategories, further comprising a second layer of information within any operational category). For example, audio may be an operational category and call volume, ringer volume, music volume, alarm volume, system volume, Bluetooth, Bluetooth volume, or other volume of audio may be operational subcategories. For example, a battery operational category may be configured with the following operational subcategories: battery health, battery capacity, firmware health, battery status, performance, consumption, low battery, charging, charging alert, charging rate, discharging rate, battery charging type, battery charging rate, discharge on sleep, discharge on wake, average battery life, current battery life, battery usage, voltage, current, power, temperature, current level, or depletion level. As further examples, operational subcategories of the signal operational category include, but are not limited to, signal strength, noise, signal quality, average signal quality, receive strength signal index, reference signal received power, reference signal received quality, reference signal to noise ratio, cell ID, physical cell ID, and tracking area code.

[0099] In some embodiments, internal diagnostic indicators associated with one or more operational parameters may be generated and transmitted from the mobile device to a remote validation system 307 for storage and processing. For example, the remote validation system 307 may process the internal diagnostic indicators to return a data object comprising a pass (e.g., the internal diagnostic indicators and associated operational parameters are indicated as meeting an acceptable value) or fail (e.g., the internal diagnostic indicators and associated operational parameters are indicated as not meeting an acceptable value) score. In some embodiments, both the internal diagnostic indicators transmitted to the remote validation system 307 and the generated data object comprising the pass or fail score may be stored, such as in the memory 103. In some such embodiments, the associated data object of the past internal diagnostic indicators and the pass or fail score may be retrieved from the remote validation system 307 for later analysis. In some embodiments, the internal diagnostic indicators and / or the associated data object comprising the pass or fail score of the diagnostic indicator itself may be transmitted to the mobile device 310 and used for various downstream processing, including configuring a GUI of the mobile device with an indication that the mobile device has met an acceptable condition.

[0100] In some embodiments, the diagnostic(s) performed at block 402 / 502 may be performed remotely from the mobile device. For example, the remote validation system 307 or a system associated with the remote validation system 307 (e.g., an agent of the remote validation system 307) may determine the state of one or more internal diagnostic indicators associated with one or more operational parameters of the mobile device. For example, the remote validation system 307 or a system associated with the remote validation system 307 may receive the one or more internal diagnostic indicators and determine whether the operational parameters of the mobile device meet one or more tolerance values. The internal diagnostic indicators may comprise data indicative of diagnostic execution of an operational category and / or operational subcategory of the mobile device. The internal diagnostic indicators may comprise one or more data objects comprising data values, such as numeric values, messages, and / or other data values, associated with the performance of the mobile device in a particular operational category / subcategory (e.g., good, normal, bad, charging, discharging, operating, not operating). Additionally, the internal diagnostic indicators may comprise comparative performance based on a comparison of the data of the operational category or operational subcategory of the mobile device compared to one or more predefined tolerance values ​​for the operational category and / or subcategory of the mobile device. For example, an optimal battery life for a mobile device may be 12 hours and the predetermined tolerance for the operating category of battery life may be 50% or 6 hours. In the example where an internal diagnostic has been run on the mobile device and returned a battery life of 5 hours, the internal diagnostic indicator may return an indication that the mobile device has failed. Alternatively, if an internal diagnostic has been run on the mobile device and returned a battery life of 6.5 hours, the internal diagnostic indicator may return an indication that the mobile device is passing.

[0101] In some embodiments, the GUI may be configured to render an interface that requests or optionally requests a user of the mobile device to input an indication of whether the mobile device is free of a particular type of damage, such as liquid crystal damage (liquid damage) and / or physical damage (comprising screen or glass damage). In some embodiments, the configured GUI may request or optionally request a user of the mobile device to input an indication if the mobile device is free of liquid crystal damage, as shown, for example, in FIG. 39. This process may be performed in addition to or as an alternative to other diagnostic processes disclosed herein. For example, the configured GUI 3900 of FIG. 39 may include a selectable option that allows a user to input an indication of whether the device is "free of liquid crystal damage" (free from liquid crystal damage) at 3901 (e.g., the user may select a "yes" button at 3902 if the mobile device is free of liquid crystal damage and the user may select a "no" button at 3903 if the mobile device is not free of liquid crystal damage (i.e., has liquid crystal damage)). In some embodiments, the configured GUI may prompt or optionally prompt a user of the mobile device to input an indication of whether the mobile device is free of physical damage, as shown, for example, in Figure 40. For example, the configured GUI 4000 of Figure 40 may be configured with a prompt asking whether the device is "free of physical damage" at 4001 to provide an input for a user to confirm the physical damage status (e.g., if the mobile device is free of physical damage, the user may select the "Yes" button at 4001, and if the mobile device is not free of physical damage, the user may select the "No" button at 4001). This process may occur in addition to or as an alternative to other diagnostic processes disclosed herein.

[0102] In some embodiments, the GUI may be configured to prompt the user to enter background data associated with the mobile device, such as a serial number associated with the mobile device (e.g., IMEI number and / or phone number, etc.). The user may enter this serial number as an identification data object associated with the mobile device, which the apparatus 100 and / or 200 and / or the remote verification system 307 may compare to a correct serial number of the mobile device based on a separate identifier (e.g., the serial number may be listed in the provider system 305, which may be accessed over a network) to identify the mobile device. An exemplary GUI configured to request a serial number 1300 associated with a mobile device may be shown in FIG. 13. For example, the user may enter serial number data in text box 1301, and then the user may click on enter 1302 to proceed through a GUI configured to proceed with a remote verification process (e.g., the serial number verification may be a precursor to a remote verification process, such as the processes shown in FIGS. 4-5). In some embodiments, a GUI configured to request the serial number 1300 may include an input to cancel (e.g., input 1303) which, if selected, may return the user to the beginning of the remote verification process (e.g., block 401 of FIG. 4 and / or block 501 of FIG. 5). The serial number may be compared to serial numbers registered with the user and / or associated with the device the user purports to process (e.g., either a particular device or a type of device such as a particular make and model). In some embodiments, the remote verification may proceed only if the serial number is invalid or does not match, or an unacceptable status may be returned.

[0103] In some embodiments, the GUI may be configured to prompt the user to enter background data associated with the mobile device, such as a phone number associated with the mobile device and / or an IMEI associated with the mobile device. FIG. 14 illustrates an exemplary GUI configured to request a phone number 1400 associated with the mobile device. For example, a user may enter a phone number into text box 1401, after which the user may click input 1402 (e.g., a "Submit" button) to proceed through the GUI configured to proceed with a remote verification process (e.g., the phone number may be a precursor to a remote verification process of the state of the mobile device, such as the processes illustrated in FIGS. 4-5).

[0104] In some embodiments, current data of the mobile device associated with operational categories (e.g., battery, storage, capacity (volume), etc.) may be extracted from the mobile device and processed by the diagnostic circuitry 202 of FIG. 2. The diagnostic circuitry 202 of FIG. 2 may process the current data of the mobile device and compare the current data to acceptable values ​​of data of the operational category / subcategory to output one or more internal diagnostic data objects for the mobile device. The internal diagnostics of the mobile device may be configured with one or more internal diagnostic data objects associated with one or more operational categories and / or subcategories such that the internal diagnostics is an aggregate of each operational category and / or subcategory of the mobile device.

[0105] In some embodiments, if the diagnostic indicators meet (or exceed) an acceptable value for the operational category and / or subcategory, an indication may be generated that the mobile device has passed the internal diagnostics. In some embodiments, if the diagnostic indicators do not meet an acceptable value for the operational category and / or subcategory, an indication may be generated that the mobile device has failed the internal diagnostics. In some embodiments, the acceptable value may be a predetermined acceptable value programmed into the remote validation system 307 and / or the mobile device. In some embodiments, the acceptable value may be determined by aggregating data from multiple other mobile devices. For example, an average diagnostic indicator associated with a particular operational category or subcategory may be obtained from data collected from multiple other mobile devices. This average value (or a predetermined deviation therefrom, such as a 10% range above and below this value) may be used as the acceptable value. In some embodiments, the multiple other devices may be a group of devices that share similarities (e.g., the same make, model, etc.) with the mobile device being analyzed.

[0106] In some embodiments, a diagnostic circuit such as the diagnostic circuit 202 shown in FIG. 2 processes the mobile device's current data and may return one or more diagnostic indicators (e.g., internal diagnostic data objects) for the mobile device without comparing the diagnostic indicators to acceptable values ​​for the operational category / subcategory data. In some embodiments, the diagnostic indicators may be raw data and / or processed data from the mobile device. In some embodiments, the diagnostic circuit 202 may output one or more diagnostic indicators for transmission to the remote validation system 307 for processing. Upon receipt by the remote validation system 307, the remote validation system 307 may use the one or more diagnostic indicators to determine whether the mobile device meets acceptable values ​​associated with the tests associated with the one or more diagnostic indicators. In some embodiments, the remote validation system 307 may use the one or more diagnostic indicators to determine whether the mobile device is affected by any faults. In some embodiments, the remote validation system 307 may use the one or more diagnostic indicators to determine the value (e.g., trade-in value) of the mobile device. The remote verification system 307, in some embodiments, can process the particular age of the mobile device and one or more diagnostic indicators to generate a value for the mobile device (e.g., the older the mobile device, the lower the value; the older the mobile device and the lower the one or more diagnostic indicators, the lower the value; the lower the one or more diagnostic indicators, the lower the value; the newer the mobile device, the higher the value; the newer the mobile device and the higher the one or more diagnostic indicators, the higher the value; the higher the one or more diagnostic indicators, the higher the value, etc.). Once the mobile device value is generated by the remote verification system 307, the remote verification system 307 can transmit the value back to the mobile device 310 over the network 301. In some embodiments, the value may be used to configure a GUI for the mobile device to show the mobile device value to a user.The mobile device user may accept the mobile device values ​​and continue the remote verification process, or may resume the remote verification process after correcting one or more components of the mobile device associated with the one or more diagnostic indicators.

[0107] In some embodiments, such as blocks 402, 502, 601, and / or 701, a remote verification system 307 may be used to perform at least a portion of a diagnosis of a mobile device remotely. In some embodiments, current and / or historical data of the mobile device related to an operational category (e.g., battery, storage, capacity, etc.) is extracted from the mobile device and processed by the remote verification system 307, which may be configured with circuitry as shown with respect to the apparatus 100 of FIG. 1, including the equivalent of the processor 101 and / or 201, communication circuitry, memory 103 and / or 203, input / output circuitry 104 and / or 204, remote verification circuitry 102, and / or diagnostic circuitry 202. In some embodiments, once the current and / or historical data of the mobile device has been processed and compared to the permitted values ​​of data for the operational category / subcategory and an internal hardware diagnostic data object is generated, the internal hardware diagnostics (e.g., a collection of one or more internal hardware diagnostic data objects) may be transmitted back to the mobile device(s) 310 via the network 301.

[0108] FIG. 6 illustrates an exemplary embodiment of an internal diagnostic operation 600. For example, in block 601, the apparatus 100 and / or 200 includes means such as the remote verification circuit 102 and / or diagnostic circuit 202, the communication circuit 105 and / or 205, the input / output circuit 104 and / or 204, the memory 103 and / or 203, and the processor 101 and / or 201, or a combination thereof, for causing the mobile device to perform an internal diagnosis. In some embodiments, and in block 602, acceptable values ​​for the operational categories and / or subcategories are identified. In some embodiments, the acceptable values ​​are stored in a memory (e.g., a memory local to the mobile device and / or a memory local to the remote verification system). Once the acceptable values ​​for the operational categories and / or subcategories are identified, an internal diagnosis is performed on the mobile device to generate a diagnostic indicator, and then in block 603, the diagnostic indicator is compared with the acceptable values ​​for the operational categories and / or subcategories.

[0109] In some embodiments, the diagnostic indicators may include pre-existing data (e.g., either raw data or pre-processed data) on or associated with the mobile device that is obtained in association with running a diagnostic (e.g., making an API call for battery health information that may be predetermined by the mobile device and / or stored over time by the mobile device or a third party system associated with the mobile device). In some embodiments, the diagnostic indicators may include current or historical data associated with one or more operational categories or subcategories that may already exist or that may be generated in response to the diagnostic(s). In some embodiments, the diagnostic indicators may comprise results or other outputs of pre-programmed tests (e.g., running stress tests on the processor) stored on the mobile device that are executed in response to initiation of the diagnostic(s). In some embodiments, the diagnostic indicators may comprise data collected by the mobile device after initiation of the diagnostic(s) (e.g., tracking cellular reception after initiation of the diagnostic(s)). In some embodiments, generation of one or more diagnostic indicators may require enhanced permissions, and a prompt may be displayed to encourage a user of the mobile device to grant the mobile device the enhanced permissions prior to generation and / or acquisition of the diagnostic indicator (e.g., access to sensors and / or data not previously authorized by the user).

[0110] In some embodiments, the diagnostic test(s), such as the diagnostics of block 402 of FIG. 4 or block 502 of FIG. 5, may include a screen crack detection routine and / or one or more internal diagnostics. FIG. 7 shows a flow chart according to an exemplary method for performing a screen crack detection routine according to some exemplary embodiments. FIG. 7 may be performed in and / or by the exemplary devices 100 and 200 as seen in FIGS. 1 and 2, respectively. For example, the operations illustrated in and described with respect to FIG. 7 may be performed by, with the assistance of, and / or under the control of one or more of the devices 100 and / or 200, the processors 101 and / or 201, the communication circuits, the memories 103 and / or 203, the input / output circuits 104 and / or 204, the remote verification circuits 102, and / or the diagnostic circuits 202. For example, in some embodiments, at least steps requiring local operation (e.g., image capture) may be performed by a mobile device (e.g., device 200) and additional processing steps may be performed by either local or remote devices (e.g., devices 100, 200).

[0111] In some embodiments, the diagnostic(s) performed on the mobile device may include a screen crack detection routine, such as the process shown in Figure 7. For example, in block 701, the apparatus 100 and / or 200 and / or the remote verification system 307 includes means such as the remote verification circuit 102 and / or diagnostic circuit 202, the communication circuit 105 and / or 205, the input / output circuit 104 and / or 204, the memory 103 and / or 203, and the processor 101 and / or 201, or a combination thereof, and causes the mobile device 310 to initiate a screen crack detection routine (e.g., via the processor 201, the mobile device's camera, and / or additional mobile device components). After the screen crack detection routine is initiated, an image of the mobile device may be captured in block 702.

[0112] In some embodiments, image capture of a mobile device proceeds by instructing the user (e.g., via GUI text or visual instructions on the mobile device's screen) to place the mobile device in front of a mirror with the front side (e.g., screen) of the mobile device facing the mirror. The mobile device includes one or more front-facing cameras. A similar process can be used to capture an image of the rear side (e.g., back glass) of the mobile device with a rear-facing camera. An example of such an arrangement can be shown in FIG. 10, where a mobile device 1001 is placed in front of a mirror 1002, and a reflection of the front side 1003 of the mobile device is placed within the field of view of one or more front-facing cameras (not shown) of the mobile device for capture. In some embodiments, one or more images may be captured by the mobile device for analysis. In some embodiments, during image capture, a graphic, test pattern, code, or a blank screen may be displayed. In some embodiments, a second device (e.g., another mobile device or a separate camera) may be connected to the one or more devices (e.g., via a USB connection, Ethernet, etc.) and used to capture images.

[0113] In some embodiments, once an image of the mobile device is captured in block 702, the image may be reviewed by either the mobile device or an external computing system (e.g., provider system 305 or remote verification system 307) to determine if the image shows damage to the device (e.g., screen damage). In some embodiments, analysis of the image may include dividing the image of the front of the mobile device into portions to determine if the one or more portions show damage in blocks 703-704. In some embodiments, the algorithm may further determine if one or more portions adjacent to the portion showing damage also show damage. In some embodiments, a neural network or machine learning model may be trained to determine if one or more portions of the image show damage. In some embodiments, the neural network or machine learning model used to determine if the image has damage may be stored on the mobile device on local memory or may be stored outside the mobile device (e.g., provider system 305 and / or remote verification system 307). In some embodiments, the image of the mobile device may be transmitted to an external system (e.g., provider system 305 and / or remote verification system 307) for image analysis by the remote verification system or a system associated with the remote verification system. In some embodiments, the neural networks herein may include those used and described in U.S. Patent Application Publication No. 2012 / 0133639, issued on June 25, 2019 and entitled “SCREEN DAMAGE DETECTION FOR DEVICE,” which is incorporated by reference in its entirety.

[0114] Such neural networks and / or machine learning models may undergo and / or implement unsupervised training, supervised training, semi-supervised training, reinforcement learning, deep learning, and / or the like to analyze images of the mobile device and thus determine and utilize relationships for such screen crack prediction (e.g., when such mobile device exhibits damage). During training of such neural networks and / or machine learning models (e.g., artificial / convolutional neural networks, etc.), the neural network(s) and / or machine learning model(s) may be iteratively fed with a plurality of screen crack detection data such that the neural network(s) and / or machine learning model(s) may be configured to determine patterns between a plurality of parameters, values, and data points defined by the screen crack detection data and the screen crack prediction over time. In other words, the neural network(s) and / or machine learning model(s) may be configured to determine correlations or patterns associated with the image data (e.g., screen crack detection data) of the mobile device to determine a more accurate prediction of damage to the mobile device.

[0115] In some embodiments, as seen in FIG. 11, by pointing a mobile device 1101 in front of a reflective surface 1102, a screen crack 1104 may be shown in the reflection of the mobile device 1103. Once an image of the mobile device facing the mirror is captured, an internal diagnostic may return an indication that the mobile device is exhibiting screen damage in block 705. In some embodiments, an image of the mobile device's screen may be sent to an external system (e.g., provider system 305 and / or remote verification system 307) for image analysis by a remote system (e.g., a remote verification system or a system associated with the remote verification system). Additional examples of acceptable screen crack detection processes and other external device integrity checks are described in U.S. Patent Application Publication No. 2012 / 0133999, issued June 25, 2019, and entitled “Screen Damage Detection for Devices,” which is incorporated herein by reference in its entirety.

[0116] In some embodiments, a touch screen test such as that shown in FIG. 12 may be performed in addition to or instead of capturing an image of the mobile device to detect cracks in the screen. The touch screen test may include, for example, instructing the user to trace a test pattern on the screen with a finger to ensure that the entire touch surface of the screen is enabled, or instructing the user to paint the screen with a finger. For example, during a touch screen test, a user of the mobile device may be tasked with both testing the calibration of the touch screen of the mobile device and testing the screen for cracks that would prevent the user from accessing the entire touch screen (e.g., areas of the touch screen that cannot register physical contact) when filling the screen with pixel values ​​of the mobile device, or alternatively interacting with the touch screen test generally via the touch screen (e.g., being unable to select a particular area on the mobile device screen due to a crack in the screen). A touch screen defect may be detected, for example, when a user is unable to completely fill the screen because a portion of the screen cannot register touch input. In this manner, as with various other embodiments detailed herein, the touch screen can be verified remotely with only the user of the mobile device in physical contact with the mobile device.

[0117] In some embodiments, the screen crack detection routine may be embodied by the configuration GUIs of FIGS. 21-26 as configuration GUIs 2100-2600. In some embodiments, the screen crack detection routine may begin with the configuration GUI 2100, where one or more indicators may indicate to the user how to complete the screen crack detection routine. For example, the configuration GUI 2100 may indicate at 2101 that the user should point the mobile device (e.g., the screen of the mobile device) towards a mirror. In some embodiments, the configuration GUI 2100 may include instructions at 2102 to select a link to a video tutorial of how to complete the screen crack detection routine. In some embodiments, the configuration GUI 2100 may include instructions for the user to hold the mobile device a predetermined distance (e.g., 5 inches to 7 inches (12.7 cm to 17.78 cm)) from the mirror, such as instructions shown in the configuration GUI at 2103, and / or instructions for the user to show the mobile device to the mirror without obstructing any portion of the mobile device. In some embodiments, the configured GUI 2100 may include a button (e.g., a "Start" button at 2104) for a user to select on the configured GUI to advance the configured GUI to the next screen of the screen crack detection routine (e.g., FIG. 22). In some embodiments, the configured GUI 2100 may include a button (e.g., a "Skip" button 2105) for skipping the screen crack detection routine and proceeding to one or more other diagnostics in the process of remote verification of the mobile device's condition. The skip option is presented in instances where the user is either permitted to not run the crack detection routine or permitted to delay crack detection and proceed to other parts of the remote verification process.

[0118] In some embodiments, the screen crack detection routine may include another configured GUI, such as configured GUI 2200 of FIG. 22, to indicate that the user should point the mobile device screen towards the mirror (e.g., as indicated by a graphic on the configured GUI at 2202). In some embodiments, configured GUI 2200 may include one or more graphics and / or fiducials (e.g., 2201A, 2201B, 2201C, ..., 2201N) to align and recognize an image of the screen captured by the mobile device's camera. In some embodiments, the configured GUI of the screen crack detection routine may configure one or more indicators, such as text and / or graphics, backwards (e.g., reading from right to left) such that when the mobile device's screen is shown in a mirror, the text and / or graphics are shown forwards (e.g., reading from left to right). Such an embodiment may be illustrated in configured GUI 2300 of FIG. 23 as 2301 reading "calibrating" backwards. In some embodiments, the mobile device's front camera may automatically initiate inversion of text and / or screen crack detection image data such that if a fiducial or other graphic is detected in the camera data during the processing of FIG. 22 and / or FIG. 23, the mobile device seamlessly keeps the text readable by the user and initiates the crack detection process. In some embodiments, the mobile device's configured GUI may include instructing the user to hold the mobile device toward the mirror for a specified distance (e.g., 15 inches (38.1 cm)), as shown at 2302. In some embodiments, the mobile device's configured GUI for the screen crack detection routine may include an indication that some predetermined requirement has occurred (e.g., capture of an image having good image quality, successful calibration, a specified period of time, etc.).

[0119] In some embodiments, the screen crack detection routine includes a configured GUI that includes instructing the user to hold the mobile device still for a certain period of time (e.g., by using a graphic or text). The graphic may include a hand stamp as shown at 2401 in configured GUI 2400 of FIG. 24. For example, the hand graphic as shown at 2401 may be shown on the configured GUI (e.g., configured GUI 2500 of FIG. 25) until a test pattern, such as a color (e.g., white or green) and / or a light flash, is shown on the mobile device. The camera captures the test pattern (e.g., the green image of FIG. 25) to analyze the screen for cracks and other damage, and the image may be processed locally and / or sent to the remote verification system 307 for review. In some embodiments, the screen crack detection routine may include a configured GUI (e.g., configured GUI 2600 of FIG. 26) to indicate that in instances where the device passed the test, there were no screen cracks detected by the screen crack detection routine. For example, the configured GUI 2600 may be configured with text or a graphic indicating that no damage was detected to the screen of the mobile device, such as the text "NO CRACK DETECTED" at 2601. In some embodiments, the configured GUI 2600 may be configured to include a link to further details of the output of the screen crack detection routine, which may lead the user to another page of details of the screen crack detection routine, as shown at 2602. In some embodiments, the screen crack detection routine may be configured to include a link to allow the user of the mobile device to re-run the screen crack detection routine, as shown at 2603 of the configured GUI 2600; this option may be present only in the case of failure and may be present in both the case of failure and passing of the screen crack detection routine. In some embodiments, the screen crack detection routine may include a button (e.g., a "Continue" button at 2604) for the user to select on the configured GUI to proceed to the next step of the remote verification process.

[0120] In some embodiments, the diagnostics may comprise touch screen diagnostics (e.g., digitizer tests) as shown in FIGS. 27-29. In some embodiments, the touch screen diagnostics may include a configured GUI 2700 that explains the process to a user and requests one or more inputs by the user to initiate the touch screen diagnostics. For example, the configured GUI 2700 may be configured with indicators that instruct the user to tap, select, or swipe one or more grid squares on the configured GUI (e.g., configured GUI 2800 of FIG. 28) to determine that the mobile device's touch screen is operating properly at each grid square (e.g., detecting touch input at the location of a square may confirm operability of the touch screen at that location) and / or determine that one or more areas of the mobile device's touch screen are properly calibrated to receive user input. In some embodiments, the configured GUI 2700 includes a button (e.g., a "Begin" button, 2703) for initiating the touch screen diagnostics process that may advance the touch screen diagnostics process to a configured GUI similar or identical to configured GUI 2800 of FIG. 28. In some embodiments, the configured GUI 2700 of Figure 27 may include a button (e.g., a "Skip" button, 2704) for a user to select to skip the touch screen diagnostics and proceed to the next diagnostic in the remote verification process of the mobile device's state and / or proceed to the next processing step in the remote verification process of the mobile device's state. The skip option is presented either when the user is permitted to not run the test or when the user is permitted to delay the test and proceed to other parts of the remote verification process.

[0121] In some embodiments, when a user selects to initiate touch screen diagnostics (e.g., through selection of button 2703), configured GUI 2800 of FIG. 28 is displayed on the mobile device and may be configured with one or more grid squares (e.g., grid squares shown in 2801) for the user to select using the touch screen of the mobile device. In some embodiments, configured GUI 2800 may include a button (e.g., "skip step" button 2802) for the user to select to skip the touch screen diagnostics and proceed to the next processing step in the remote verification process of the mobile device's condition. In response to selection of an individual grid square 2801 in the embodiment shown in FIG. 28, a portion of an image, such as image 2901 shown in FIG. 29, may be displayed to visually indicate to the user that each grid square is functional and verified. In some embodiments, as the user selects each grid square of 2801 and each is verified, the configured GUI may return an indication that the touch screen diagnostics have passed, such as configured GUI 2900 of FIG. 29. In some embodiments, configured GUI 2900 may be configured with an image of a checkmark or other graphical indicator indicating that the touch screen diagnostics have passed. The completed graphic 2901 may also provide an intuitive confirmation to the user that the test has passed. In some embodiments, the size / number of grid squares may be selected based on the desired sensitivity of the test (e.g., preset number of pixels, preset number of screen fractions, or similar options), which may be configurable by the carrier or other provider directing or otherwise associated with the remote verification process. In some embodiments, the configured GUI 2900 may include a button (e.g., a "Next" button, 2902) that may be selected by the user to continue the remote verification of the mobile device process state to the next diagnostic and / or processing step.In some embodiments, the touch screen diagnostics may include a digitizer test (e.g., a pixel test) as described in U.S. Patent Application Publication No. 2019 / 0133934, entitled “SCREEN DAMAGE DETECTION FOR DEVICE,” filed May 7, 2019, and incorporated herein by reference in its entirety.

[0122] In the embodiment depicted in FIG. 5, the verification steps associated with the security features may proceed according to any embodiment disclosed herein (e.g., the flow depicted in FIG. 4 in an instance where the security features are enabled). In the depicted embodiment of FIG. 5, the security data object is depicted as indicating that the security features are disabled, which may not require further action by the user or computing device / mobile device, at least with respect to the security features. In some embodiments, referring to block 503, when the remote verification system 307 and / or the apparatus 100 and / or 200 receive at least one security data object associated with the mobile device, the remote verification system 307 or the remote verification circuit 102 may determine the status of the security features. In block 504, the security features of the security data object are determined to be disabled in the depicted embodiment, although FIG. 4 illustrates an example where the security features are not initially disabled. Upon receiving a request to verify the state of the mobile device at block 501, the remote verification system 307 or remote verification circuitry 102 may render a GUI configured to indicate an acceptable state of the mobile device at block 505, assuming other required criteria are also met for a predetermined threshold time. In some embodiments, steps 504 and 505 may occur sequentially such that the remote verification system 307 or remote verification circuitry 102 has determined that a security feature of the security data object is disabled at step 504, and then the remote verification system 307 or remote verification circuitry 102 renders a GUI configured to indicate an acceptable state of the mobile device at step 505, for a predetermined threshold time. As described herein, if the security feature is not disabled, the user may also be given a predetermined time to disable the security feature before an unacceptable state is determined.

[0123] In some embodiments, the verification step associated with FIG. 5 may also include determining whether the mobile device passed one or more diagnostics (e.g., screen crack detection and / or internal hardware diagnostics) at step 506. In some embodiments, the remote verification circuit 102 and / or the diagnostic circuit 202 may cause a GUI configured to indicate an acceptable state of the mobile device for a predetermined threshold time to be rendered at step 505 if the mobile device passed the diagnostic(s) at step 506. In some embodiments, only the security feature determines that an acceptable state is determined. In some embodiments, both the security feature and one or more diagnostics (e.g., screen crack detection and / or one or more internal hardware diagnostics) may each need to be verified (e.g., security feature disabled, no screen cracks (or a predetermined acceptable level of screen cracks)), and / or each diagnostic test may collectively be required to pass (e.g., by meeting a tolerance value) before an acceptable state is determined.

[0124] In some embodiments, the predetermined threshold time is a period of time selected before or at the time verification of the mobile device's state is requested. For example, the predetermined threshold time may represent a period of time for an acceptable state to remain valid (e.g., during the period of time that an offer associated with the mobile device is valid) and may comprise a unit of time including, but not limited to, milliseconds, minutes, hours, days, or any other unit of time. In some embodiments, the predetermined threshold time may be set externally to the mobile device using the remote verification circuitry 102 or the remote verification system 307 and then communicated to the mobile device 310 via the network 301. In some embodiments, the predetermined threshold time may be defined by an external condition, such as a time to accept a service, an offer, a remote connection, a trade-in, or any other interaction between the user of the mobile device and a third party system. In some embodiments, the predetermined threshold time may be pre-determined by a client of the remote verification system 307 before one or more diagnostics are performed, depending on the client of the remote verification system 307 (e.g., selectable by a provider of a carrier service using the remote verification system for a user / customer of the carrier service). The predetermined threshold time may be configured to configure the GUI of the mobile device to display a countdown or other indication of the time remaining of the predetermined threshold time, and the user may accept by continuing with the steps outlined in the GUI, or the user may reject by terminating the request of the verification circuit GUI or by allowing the predetermined threshold time to pass without further action on the part of the user. Once the predetermined threshold time has passed, a signal of the unacceptable condition may be transmitted from the mobile device over the network 301 to the remote verification system 307, which transmits a signal of the unacceptable condition to the remote verification circuit 102 in the mobile device. In some embodiments, the unacceptable condition may be transmitted from the remote verification system 307 (e.g., from a server in the remote verification system 307) to the mobile device.In such an embodiment, the remote verification system 307 may indicate that the predetermined threshold time has elapsed, or the remote verification system 307 may continuously indicate a countdown of the predetermined threshold time by continuously transmitting the predetermined threshold time to the mobile device in real time.

[0125] In some embodiments, the user may resume requesting verification of the mobile device's state after an acceptable state becomes unacceptable, either through inaction by the user or through an overt action by the user to reject the acceptable state (e.g., exiting the verification request circuit GUI (if this action is configured to trigger an unacceptable state), declining the offer, leaving a designated area, engaging in a virtual private network (VPN) or other network signal routing program, or performing an unacceptable action on the mobile device (e.g., powering off the device or uninstalling or blocking the verification software)). In some embodiments, the remote verification system 307 may store the data object and the acceptable state indicator in its memory or the remote verification circuit 102 may store the data object or the acceptable state indicator of the previous process in its memory (e.g., memory 103 of the device 100) so that the diagnosis(es) do not have to be rerun. In some embodiments, a second time period, a time function, must be determined to indicate that the diagnostic results have been saved and are still valid to avoid rerunning the diagnostic(s) on the mobile device. The time function may also be used to save the diagnostic results if the user stops the remote verification process described herein after the diagnostic test has been run but before the security feature is determined to be enabled or disabled. In some embodiments, any one or more of the tests and diagnostic processes described above may be used for one or more additional functions, such as determining the suitability of a protection program.

[0126] <Security function verification> 8 illustrates a flow chart according to an example method 800 for determining whether a security feature of a mobile device is enabled (e.g., a process that may be performed as part of the processes of FIG. 4 and / or FIG. 5). In this regard, FIG. 8 illustrates operations that may be performed by a remote verification system 307 (e.g., computing device 100, etc.) and / or in cooperation with one or more computing devices 100 and / or 200 comprising mobile device(s) 310. The operations illustrated and described with respect to FIG. 8 may be performed by, with the assistance of, and / or under the control of, one or more of the devices discussed herein (e.g., devices 100 and / or 200) comprising, for example, processor 101, memory 103, communication circuitry 105, remote verification circuitry 102, or input / output circuitry 104, processor 201, memory 203, communication circuitry 205, diagnostic circuitry 202, and input / output circuitry 204. In some embodiments, processes that require operation of the mobile device 310 (e.g., a subset of diagnostic tests that are instantiated on the mobile device and / or require hardware or software feedback from the mobile device) are executed on the mobile device. In some embodiments, processes that are executed remotely from the mobile device (e.g., a request for verification of the state of the mobile device initiated by a remote server when the mobile device is not available for testing) may be executed on or by one or more remote device(s) separate from the mobile device being verified (e.g., via the provider system 305, the remote verification system 307, or another third party device). Other processes that are wholly or partially device independent (e.g., a process that retrieves or requests metadata associated with the mobile device from a third party server) may be executed on any of the aforementioned devices.

[0127] In block 801, the remote verification server 307 and / or the mobile device(s) 310 (e.g., embodied as the apparatus 100 and / or 200) may include means such as the remote verification circuit 102 and / or diagnostic circuit 202, the communication circuit 105 and / or 205, the input / output circuit 104 and / or 204, the memory 103 and / or 203, and the processor 101 and / or 201, or a combination thereof, and may receive a security data object associated with the mobile device, which may include data indicating whether a security feature is enabled. The security data object may be requested from one or more locations where it may be stored, and the security data object may be requested by one or more apparatuses (e.g., the mobile device and / or the remote verification system) as discussed herein. For example, the mobile device itself (e.g., the apparatus 200) may construct a security data object indicating the status of the security feature. In some embodiments, a remote storage location may additionally or alternatively construct the security data object. For example, a third party system (e.g., provider system 305) may store a security data object indicating the status of a security feature. For example, in an embodiment in which "Find My iPhone" is used by the mobile device as a security feature, a server associated with the phone manufacturer (e.g., Apple) may be queried for the security data object. In block 802, apparatus 100 and / or 200, or a combination thereof, may determine whether one or more security features are enabled on the mobile device based on the security data object.

[0128] In some embodiments, if the security data object indicates that at least one security feature is enabled on the mobile device, a disabled indication of the mobile device may be sent / transmitted over a network, such as network 301, to a remote verification system 307 (e.g., apparatus 100). In some embodiments, the disabled indication may also be returned from the remote verification system 307 to the mobile device (e.g., over a network, such as network 301) in the form of a configured GUI for disclosing the disabled indication to a user of the mobile device along with rendering a configured GUI or other computer-executable instructions for disabling said security feature of the mobile device (e.g., FIG. 14). In some embodiments, the disabled indication may be a temporary state associated with the security feature during which the user is given time to disable the security feature prior to an indication of either an acceptable or unacceptable state.

[0129] In some embodiments, if the security data object indicates that the mobile device's security feature(s) are disabled on the mobile device, an indication of the mobile device's acceptable state may be sent to the remote verification system 307 (e.g., device 100), assuming other criteria for acceptability, if any, are also met (e.g., if diagnostics such as cracked screen detection are required, the diagnostics may also be determined to be acceptable prior to the determination of the acceptable state). In some embodiments, the acceptable state of the mobile device may also be sent back to the mobile device from the remote verification system 307 (e.g., device 100) in the form of a GUI configured to disclose the acceptable state of the mobile device (e.g., over a network such as network 301).

[0130] 9 illustrates a flow chart according to an example method 900 for configuring a mobile device to disable a security feature of the mobile device (e.g., in conjunction with the disable indicator 803 of FIG. 8). In this regard, FIG. 9 illustrates operations that may be performed by the mobile device 310, the remote verification system 307 (e.g., computing device 100, etc.), and / or in cooperation with one or more of computing devices 100 and / or 200. The operations illustrated and described with respect to FIG. 8 may be performed by, with the assistance of, and / or under the control of, one or more of the devices discussed herein (e.g., devices 100 and / or 200) including, for example, processor 101, memory 103, communication circuitry 105, remote verification circuitry 102, or input / output circuitry 104, processor 201, memory 203, communication circuitry 205, diagnostic circuitry 202, and input / output circuitry 204. In some embodiments, processes that require operation of the mobile device 310 (e.g., a subset of diagnostic tests that are instantiated on the mobile device and / or require hardware or software feedback from the mobile device) are executed on the mobile device. In some embodiments, processes that are executed remotely from the mobile device (e.g., a request for verification of the state of the mobile device initiated by a remote server when the mobile device is not available for testing) may be executed on or by one or more remote device(s) separate from the mobile device being verified (e.g., via the provider system 305, the remote verification system 307, or another third party device). Other processes that are wholly or partially device independent (e.g., a process that retrieves or requests metadata associated with the mobile device from a third party server) may be executed on any of the aforementioned devices.

[0131] Following receipt of the security data object, in block 901, the remote verification system 307 (e.g., such as the device 100) and / or the mobile device (e.g., the device 200), including means such as the remote verification circuitry 102 and / or the diagnostic circuitry 202, the communication circuitry 105 and / or the mobile device 310, the input / output circuitry 104 and / or the mobile device 310, the memory 103 and / or the mobile device 310, the processor 101 ... In some embodiments, if the security feature is determined to be enabled, the GUI of the mobile device may be configured to provide instructions to disable the security feature of the mobile device. In some embodiments, the user may be provided with a predetermined threshold time for the security feature to be disabled such that an acceptable state is returned, and if the security feature is not disabled within the predetermined threshold time, the disabled state may be converted to an unacceptable state.

[0132] In some embodiments, if it is determined that the security feature is enabled on the mobile device, at block 902, the mobile device 310 may be configured to disable the security feature. In some embodiments, the security data object may be configured to indicate that the security feature associated with the mobile device is enabled. The security feature(s) on the mobile device may be disabled locally (e.g., on the mobile device, a user may access the security feature and turn it off from an interface of the mobile device, such as a touch screen or keyboard / keypad) or externally (e.g., using an account associated with the user of the mobile device, such that the user may use another computing device to log into an account associated with the mobile device that may allow access to the security feature of the mobile device). For example, if the mobile device is associated with a user's account on a provider's system, a remote computing device (e.g., a personal computer, an iPad, another mobile device, or some other computing device that may communicate over a network) may be used to access the mobile device or an account associated with the mobile device (e.g., an account on the provider's system) and cause the remote disablement of the security feature. In some embodiments, a user may enter authentication credentials, such as a username and password, locally on the mobile device or on a second computing device to which the user has access to an account associated with the user of the mobile device and / or the mobile device itself.In some embodiments, a user's account is based on a phone number associated with the mobile device, whereby the user enters a phone number during a remote verification process of the mobile device's state, allowing the remote verification system and / or provider system to associate a current remote verification of the mobile device's state with one or more previous remote verifications of the mobile device's state previously performed using the same phone number. The account may be linked only to the mobile device, only to the user, and / or to both the user and the mobile device. In the above examples, the security features may be maintained locally and / or remotely (e.g., on the provider system) and updated at each location. In such embodiments, the provider system or other remote computing system has updated the mobile device and may send an indication of disabling the security features (e.g., via an updated security data object) back to the mobile device and / or remote verification system 307 to proceed with the process(es) described herein. For example, in examples where the security features are controlled by a provider system (e.g., provider system 305), the mobile device may determine the status of the security features and be required to communicate to the provider system to enable or disable the security features. In such examples, the security features may be disabled locally by instructing the mobile device, via interaction with the mobile device GUI, to request disabling from the provider system. Similarly, in such examples, the security features may be disabled externally by instructing a third party system (e.g., provider system 305) to disable the features, such as via remote verification system 307.In some embodiments, a security data object that may have previously indicated that a security feature was enabled may be updated to indicate that the security feature is disabled, and in response, an acceptable state may be determined based on satisfaction of other criteria, if any, as discussed herein.

[0133] After it is determined that the security feature has been disabled, the mobile device, and / or its GUI, may be configured to indicate an acceptable state if the security feature has been disabled, at block 903. In some embodiments, and after a predetermined threshold time has elapsed and there has been no affirmative indication that the security feature is still enabled or disabled, at block 904, the mobile device may be configured to return an unacceptable state of the mobile device.

[0134] In some embodiments described herein, a mobile device user may initiate the process of FIG. 4 and / or FIG. 5 (e.g., at block 401 or 501) by accessing a remote verification program on the mobile device or a computing device associated with the mobile device. Such mobile devices include those shown as 310 in FIG. 3. The remote verification program may be accessed through downloading an app, through accessing a web page or website, through an app created through a software development kit SDK means, or through accessing a provider system (e.g., accessing a web page associated with the provider). In some embodiments, the remote verification system 307 may direct at least a portion of the remote verification process. When the remote verification process is accessed, an API call or other computer executable instructions are provided from either the mobile device 310 or the remote verification system 307 to the provider system 305 and / or the mobile device 310 requesting the provider system 305 and / or the mobile device 310 to access security functionality of the mobile device to obtain and identify the status of the security data object. The security data object, as described herein, determines whether a security feature is disabled or enabled and can be used to indicate disabling of the security feature (e.g., via computer-executable instructions from the remote verification system 307 and / or the mobile device 310) prior to determining an acceptable or unacceptable state and prior to any downstream steps described herein. In some embodiments, the mobile device 310 and / or the remote verification system 307 can send computer-executable instructions configured to cause a GUI of the mobile device to indicate an acceptable state (i.e., the security data object indicates that the security feature is disabled) or an unacceptable / disabled state (i.e., the security data object indicates that the security feature is enabled).In some embodiments, security features of the mobile device may be stored external to the mobile device such that enabling and disabling of security features is controlled by sending requests from the mobile device to the provider system 310 (e.g., Apple®'s Find My® iPhone® feature may be stored in Apple® iCloud® outside of the mobile device itself). In some embodiments, security features may be stored locally on the mobile device.

[0135] In some embodiments, if the security data object indicates that the security feature is enabled, the GUI of the mobile device may be configured to show a disable indicator to disable the security feature. The user of the mobile device may then be prompted to disable the security feature, and / or the remote verification system 307 or the mobile device 310 may automatically disable the security feature. In some embodiments, once the security feature is disabled, computer executable instructions may be sent to the mobile device 310 and / or the remote verification system 307 indicating the disablement of the security feature. In some embodiments, the mobile device 310 and / or the remote verification system 307 may continuously or periodically recheck the state of the security data object to see if it has been disabled. The updated security data object may be processed (e.g., by the mobile device 310 and / or the remote verification system 307) to identify an acceptable state, and (e.g., if the security data object indicates that the security feature has been disabled) computer executable instructions may be sent (e.g., by the mobile device 310 and / or the remote verification system 307) to configure the GUI of the mobile device to show the acceptable state. In some embodiments, after determining an acceptable status, the remote verification system 307 and / or the mobile device 310 may proceed with downstream processing of the mobile device (e.g., sending an offer to the user for service, trade-in, etc.).

[0136] <Usage example> In one example use case, a user and / or a remote system may detect some defect or malfunction of a mobile device and trigger a mobile device repair workflow (e.g., servicing a warranty claim or out-of-warranty repair). The mobile device repair workflow may include one or more predefined requirements that must be met before a servicer will accept the mobile device for repair. For example, the predefined requirements may include requiring the disablement of security features to allow a service technician to access the mobile device's software and / or to facilitate replacement of the mobile device without locking or bricking the mobile device. In such an example use case, an "acceptable state" may be determined based on the satisfaction of the predefined requirements (e.g., determining that a security feature is disabled). In some embodiments, one or more additional diagnostic data points may be optionally collected (e.g., screen crack detection and internal diagnostics) to notify the remote validation system and repair technician that an existing defect (if any) of the mobile device has been detected without affecting the determination of an acceptable state (e.g., screen crack detection and internal diagnostics).

[0137] In one such example repair workflow, a system (e.g., a mobile device and / or a remote verification system according to various embodiments herein) may receive a request to verify the state of the mobile device in association with the repair workflow according to the processes of FIG. 4 and / or FIG. 5. The mobile device 310 may then perform a screen crack detection process (e.g., process 700 described with respect to FIG. 7), internal diagnostics (e.g., process 600 described with respect to FIG. 6), and verification of the state of security features (e.g., processes 800 and 900 described with respect to FIG. 8-9) in response to instructions from the local software and / or instructions from the remote verification system 307. If the security features are determined to be disabled, the repair workflow may proceed to transmitting an acceptable state, instructions for the user to transport (e.g., ship) the mobile device to a repair provider, and sending computer-executable instructions to the repair provider along with additional diagnostic data points from the screen crack detection and internal diagnostics.

[0138] In some embodiments, the remote verification system may facilitate one or more verification processes based on input provided by a user of the mobile device. For example, the user may report one or more issues or request a general health check (e.g., perform an extensive diagnostic check of the mobile device), such as via the GUI 2000 shown in FIG. 20, which may trigger a remote verification. In some embodiments, the remote verification system 307 and / or the mobile device may select one or more diagnostics based on information provided by the user in the GUI 2000. For example, the remote verification system 307 and / or the mobile device may select one or more diagnostics to run on the mobile device (e.g., screen crack detection, digitizer, battery diagnostics, diagnostics related to the microphone of the mobile device, etc.) based on user feedback. For example, the user may select from a menu of diagnostics comprising at least one of audio diagnostics, battery diagnostics, button diagnostics for hardware on the mobile device, camera diagnostics, connectivity diagnostics, display diagnostics, and sensor(s) diagnostics, such as the menu of diagnostics shown in FIG. 20 as configured GUI 2000 consisting of a diagnostics list 2002. Such a diagnostics menu may include indicators, such as 2001 indicators, for a user to select one or more diagnostics for the mobile device.

[0139] In some embodiments, when one or more diagnostics are performed on the mobile device via any process discussed herein, the remote verification process of the mobile device's status may configure the mobile device's GUI to indicate that one or more diagnostics are being performed and to explain the process as it progresses. For example, and as shown in FIG. 30, as configured GUI 3000, the mobile device's GUI may be configured to instruct the mobile device user to plug in the device as the battery diagnostic tests the connection of the charger and charging port to the mobile device, as instructed at 3001, and / or to ensure that the device is not inadvertently powered off during the verification process. In some embodiments, the configured GUI may show an image and / or graphic of the mobile device's charger being plugged into the mobile device, as in the graphic shown at 3002. In some embodiments, the configured GUI 3000 may include a button (e.g., "button" 3003) for the user to select to "skip" the battery diagnostic. The skip option may be presented either in instances where the user is permitted to not perform the diagnostic or in instances where the user is permitted to delay the diagnostic and proceed to other parts of the remote verification process.

[0140] In some embodiments, the remote verification process of the mobile device's state may configure the GUI of the mobile device to indicate that Bluetooth diagnostics are running on the mobile device, such as in the configuration GUI shown in FIG. 31 as configuration GUI 3100. In some embodiments, the configured GUI 3100 may include an indication that the remote verification of the state of the mobile device process is testing the mobile device's Bluetooth connectivity at 3101. In some embodiments, the configured GUI 3100 may be configured with a graphic and / or image indicating the type of diagnostics being run on the mobile device (e.g., graphic 3102 comprising a Bluetooth graphic). In some embodiments, the remote verification process of the mobile device's state may configure an indication of Wi-Fi diagnostics being run on the mobile device, such as by configuring the GUI of the mobile device to use a graphic indicating the type of diagnostics (e.g., graphic 3201 comprising a Wi-Fi graphic), as shown in configured GUI 3200 in FIG. 32. In some embodiments, the configured GUIs 3000, 3100, and 3200 of Figures 30, 31, and 32, respectively, may include an indication of the percentage of completion of one or more diagnostic processes selected by the user and / or selected by remote verification of the mobile device's status, such as the percentages shown at 3004, 3104, and 3204 of Figures 30, 31, and 32, respectively. In a diagnostic, the mobile device may be instructed to perform one or more functions related to the feature or function being tested and / or one or more data sets from the feature or function being tested may be collected to determine the functionality of the device. In some embodiments, the internal diagnostics of the mobile device may be instructed to perform pre-programmed diagnostics for each feature or function being tested, as described herein.In some embodiments, current and / or historical data related to the function or feature being tested may be collected to determine the functionality of the device (e.g., WiFi signal strength, transmit and receive rates in the case of WiFi testing, etc.).

[0141] In some embodiments, the user may select more general diagnostics to run on the mobile device or may indicate that a check should be run without an indication of a potential failure, such as a health check of the mobile device as shown at 2003 in the configured GUI 2000. In some embodiments, the configured GUI of FIG. 20 may further include a time for one or more diagnostics to be run and return one or more diagnostic outputs. For example, as shown at 2004, one or more diagnostics 2002 may take up to three minutes to complete for each diagnostic and / or all diagnostics selected by the user simultaneously. In some embodiments, the configured GUI 2000 may include a "continue" button (e.g., "button" 2005) that directs the user to one or more configured GUIs that show the results of the one or more diagnostics run on the mobile device. In some embodiments, the configured GUI 2000 may include a "back" button (e.g., "button" 2006) that directs the user to one or more configured GUIs that show the start of a remote verification process of the mobile device's status, such as those shown in FIGS. 13, 14, 18, and 19. In some embodiments, the aforementioned diagnostics may be performed in conjunction with one or more workflows described herein (e.g., trade-in or repair / warranty), or as a stand-alone function for diagnostic purposes. Although described with respect to a repair workflow, one of ordinary skill in the art will appreciate in light of this disclosure that the described process may also be used for other instances where a user must allow a third party to access the mobile device.

[0142] In another use case, a user may directly or indirectly send an indication of a registration renewal request to the remote verification system 307. The registration renewal request may be related to, for example, a trade-in, sale, gift, or other transfer of a mobile device from a user to a subsequent user or intermediate recipient. In combination with the non-user-based identification data objects discussed herein that can identify a mobile device based on one or more identifiers without requiring association with a specific user, a mobile device may be transferred to a third party without "bricking" the mobile phone or causing other impairment, and while allowing both users to remain anonymous (e.g., without providing user identification information other than the mobile device identification data object) and protect their data.

[0143] A mobile device registration update workflow (e.g., trade-in, etc., as described above) may include one or more predefined requirements that must be met before the registration update is completed and the mobile device transferred. For example, the predefined requirements may include requiring the disabling of security features to allow subsequent users or intermediate recipients to access the software on the mobile device without locking or bricking the mobile device. The predefined requirements may also include one or more diagnostics including screen crack detection and internal diagnostics. In some embodiments, the one or more diagnostics performed for a registration update workflow (e.g., trade-in, sale, or other disposition of the device to a third party) may be selected by one or more clients (e.g., the mobile device's carrier or other service provider, such as an OEM) associated with the remote verification system, such that one or more of the diagnostics result in a particular outcome (e.g., battery capacity is greater than or equal to 50%, no cracks are detected on the mobile device's screen, internal diagnostics return one or more other acceptable indicators, etc.). In some embodiments, the one or more diagnostics performed in a registration update workflow may be selected by one or more clients of the remote verification system, such that the one or more diagnostics determine the trade-in value or other status of the mobile device without completely stopping processing. The effect of each of the diagnostics and the set of diagnostics performed may be selected by the client and / or a third party (e.g., a first carrier offering a trade-in feature may select its own predefined diagnostics separately from a second carrier offering a second trade-in feature). In some embodiments, failure of one or more diagnostics on the mobile device may not stop the registration update workflow, but instead return a lower trade-in value (e.g., due to lower battery capacity, a cracked screen detected on the mobile device, etc.) or a higher trade-in value (e.g., due to higher battery capacity, a cracked screen detected on the mobile device, etc.).In such an exemplary use case, an "acceptable state" may be determined conditional on meeting certain requirements (e.g., security features are disabled, the screen is free of cracks or meets a minimum level of damage, and internal diagnostics determine acceptable / passed). In some embodiments, one or more additional diagnostic data points may be optionally collected without the additional diagnostic data points affecting the determination of an acceptable state. In some embodiments, the diagnostic test results may be provided to the client, a third party, or another designee without further processing.

[0144] In one such example workflow, a system (e.g., a mobile device and / or a remote verification system according to various embodiments herein) may receive a request to verify the status of the mobile device in association with the registration update workflow according to the processes of FIG. 4 and / or FIG. 5. The mobile device 310 may then perform a screen crack detection process (e.g., process 700 described with respect to FIG. 7), an internal diagnostic (e.g., process 600 described with respect to FIG. 6), and a verification of the status of the security features (e.g., processes 800 and 900 described with respect to FIG. 8-9) in response to instructions from the local software and / or instructions from the remote verification system 307. Upon determining that the security features are disabled, that the screen is crack-free or meets a minimum level of damage, and that the internal diagnostics are acceptable / pass, the registration update workflow may transmit an acceptable status. Upon receiving the acceptable status, the user may be provided with one or more downstream processing options. For example, the remote verification system 307 or an associated system may send the user (e.g., via a mobile device GUI) an offer for the user to trade in or otherwise dispose of the device.

[0145] In some embodiments, diagnostic data generated from diagnostics performed on the mobile device may be generated and / or received in parallel with receiving security data objects associated with the mobile device. For example, an acceptable state of the mobile device may be returned if the generated diagnostic data either meets or exceeds tolerance values ​​for operational category / subcategory data and / or a screen crack detection routine returns an indication that no screen cracks or damage to the surface of the mobile device were detected. In some embodiments, if an unacceptable state and / or an invalid indication is returned for the mobile device with respect to the diagnostic(s) performed on the mobile device, an acceptable state may still be generated if the security features of the mobile device are determined to be disabled. In some embodiments, the indication of an acceptable state may only require that the security features be determined to be disabled.

[0146] In some embodiments, an acceptable state may be returned only if a diagnostic has been performed and the generated diagnostic data meets or exceeds the tolerance values ​​for the operational category / subcategory data, the screen crack detection routine returns an indication that no screen cracks or damage to the surface of the mobile device have been detected, and the security features of the mobile device are determined to be disabled.

[0147] In some embodiments, at least a portion of the diagnostic data generated from diagnostic(s) executed on the mobile device may be generated using internal diagnostic(s) within the mobile device. For example, a mobile device may be equipped with dedicated hardware, firmware, and / or software diagnostic processes for determining the operational status and / or performance of any portion of the mobile device.

[0148] In some embodiments, diagnostic data generated from the diagnostic(s) performed on the mobile device may include the mobile device sending an internal diagnostic indication to an agent of the remote verification system to determine if the operating parameters meet one or more acceptable values. In some embodiments, at least a portion of the remote screen crack detection routine may also be performed external to the mobile device after the mobile device and / or secondary imaging device captures the image. For example, the remote screen crack detection routine may be performed by the remote verification system or a system associated with the remote verification system (e.g., an agent associated with the remote verification system) to transmit one or more raw or at least partially processed images of the mobile device from the mobile device over the network 301 to a remote server (e.g., provider system 305 and / or remote verification system 307) for processing. In some embodiments, the agent may return an indication of the results of the screen crack detection routine to the mobile device. In some embodiments, an acceptable state may be generated if the screen crack detection fails but the security features of the mobile device are determined to be disabled. In some embodiments, the indication of an acceptable state may only require that the security features are determined to be disabled and the acceptable state may require all or some additional diagnostic tests to pass.

[0149] In some embodiments, security features of the mobile device may be remotely controlled and / or disabled from the mobile device by sending one or more requests from the mobile device to a provider system and / or a remote verification system associated with the provider. For example, a user of the mobile device may access one or more settings within the mobile device (e.g., locally) and select a security feature to disable or enable from a settings menu. When a security feature is selected to be disabled locally by the user, a request may be sent from the mobile device to the provider system to disable the security feature contained and / or controlled within the provider system. In some embodiments, the provider system may send (e.g., forward) the request to an external server for disabling / enabling. In some embodiments, the provider system may send a signal back to the mobile device confirming that the security feature has been disabled. In some embodiments, an acceptable state of the mobile device may be determined when it is determined that the security feature has been disabled. In some embodiments, an acceptable state may be determined when it is determined that the security feature is disabled and at least one of the diagnostics described herein comprises an indication of an acceptable state.

[0150] In another exemplary use case, a user may directly or indirectly transmit an indication of registration for insurance purchase of a mobile device to the remote verification system 307 and / or the provider system 305. The indication of registration for insurance may comprise certain identification information of the user of the mobile device, mobile device data (e.g., age of the mobile device, IMEI number, storage capacity of the mobile device, etc.). In some embodiments, the remote verification system 307 and / or the provider system 305 may configure a registration renewal workflow comprising one or more predefined requirements that must be met before the registration for insurance is complete and the mobile device is covered. For example, the predefined requirements may comprise one or more diagnostics comprising screen crack detection and internal diagnostics. In such an exemplary use case, an "acceptable condition" may be determined based on the satisfaction of the predefined requirements (e.g., determining that the screen is not cracked or meets a maximum level of damage and that the internal diagnostics are acceptable / passing). In some embodiments, one or more additional diagnostic data points may be optionally collected without affecting the determination of the acceptable condition. In some embodiments, the acceptable state may only require that one or more diagnoses have been generated and sent to the remote verification system 307 and / or provider system 305, which may return the insurance policy after processing the one or more diagnoses.

[0151] In one such example workflow, a system (e.g., a mobile device, provider system, and / or remote verification system according to various embodiments herein) may receive a request for verification of a mobile device status in association with an enrollment renewal workflow according to the processes of FIG. 4 and / or FIG. 5. The mobile device 310 may then perform a screen crack detection process (e.g., process 700 described with respect to FIG. 7) and an internal diagnostic (e.g., process 600 described with respect to FIG. 6) in response to instructions from the local software and / or instructions from the remote verification system 307. If the screen is not cracked or meets a maximum level of damage and the internal diagnostic is determined to be acceptable / passed, the enrollment renewal workflow may transmit an acceptable status of the insurance policy. Upon receiving the acceptable status of the insurance policy, the user may be provided with one or more downstream processing options. For example, the remote verification system 307 or an associated system may transmit an offer to the user (e.g., via the mobile device GUI) for the user to accept the insurance policy of the mobile device.

[0152] <Example of GUI after acceptable state> 16 illustrates an example GUI (e.g., an interface that may be displayed following a determination of an acceptable state) configured to be rendered on a mobile device following an acceptable state that may present a user with an offer to purchase the mobile device (e.g., in connection with a trade-in or other transfer). Similarly, FIG. 17 illustrates an example GUI configured on a mobile device following an acceptable state that shows a shipping barcode following a process for transmitting the mobile device to a third party (e.g., a repair depot, trade-in, warranty claim, out-of-warranty repair, insurance claim, etc.) after a remote verification of the mobile device's state has been performed and an acceptable state has been determined.

[0153] With reference to FIG. 16, an exemplary GUI of a mobile device may be configured to indicate an acceptable state of the mobile device based on remote verification of the mobile device state as described herein. For example, the GUI 1600 indicating the acceptable state may be configured with data of the mobile device (e.g., text data, number data, etc.), such as manufacturer, model, and / or memory capabilities, as shown at 1601. The GUI indicating the acceptable state may also include a summary or overview of diagnostic(s) performed on the mobile device 1610, including results of internal diagnostics, disabling security features, and / or screen crack detection routines. In some embodiments, the GUI indicating the acceptable state 1600 may include inputs that a user may select to continue (proceed) trading in the mobile device at 1604 (e.g., the inputs may include visual representations of buttons shown on a mobile device interface, such as a “Proceed” button 1604, a “Return to Start” button 1605, a “Reject” button 1606, and any other such buttons described herein). In some embodiments, the GUI showing the acceptable state 1600 may include an input 1606 to “reject” the offer, terminating the remote verification process on the mobile device. In some embodiments, if the user selects the input (1606) to reject the offer, the GUI may be configured to indicate the start of the remote verification process at step 401, 501 of FIG. 4 or FIG. 5, respectively. In some embodiments, the GUI may be configured to have an input at 1605 to return to the start of the remote verification process (e.g., return to step 401 of FIG. 1). In some embodiments, if the offer has expired, the mobile device may be configured to terminate the transaction in the offer GUI after a predefined time interval. In some embodiments, the user may be required to enter further details into the configured GUI on the mobile device to complete the trade-in.

[0154] 17, a GUI configured to provide a user with a barcode for shipping of a mobile device may be presented in GUI 1700. The barcode may be generated based on the address of a third party receiving the device (e.g., a trade-in organization or an intermediary between the seller of the mobile device (current user) and a future purchaser of the mobile device (future user)).

[0155] In some embodiments, and as shown in FIG. 41, an exemplary GUI 4100 configured to provide a user with trade-in value and routing information for a user account is shown. The trade-in value shown at 4102 may comprise a value associated with a mobile device after one or more diagnostics have been performed on the mobile device to determine an acceptable state after security features have been indicated as disabled. In some embodiments, the trade-in value shown in GUI 4100 is associated with an indication of the type of mobile device being traded in at 4105 (e.g., iPhone, Android, etc.), and the trade-in value may further be associated with an indication of a mobile device identification data object, such as an IMEI number, shown at 4105. In some embodiments, GUI 4100 may include bank account routing information or other completion indications for the trade-in value of the mobile device, as shown at 4103. For example, the system may be configured to initiate a payment to a designated payment method once the mobile phone is received at a trade-in location (e.g., a warehouse associated with the trade-in entity) and the mobile terminal is verified against the identification data object. In some embodiments, the GUI 4100 can include a button (e.g., a "continue" button, 4104) for a user to select to proceed to the next step in the remote verification process of the mobile device's status. Such a next step in the remote verification process of the mobile device's status may be configured with a GUI configured to display a shipping label, such as that shown in FIG. 17. In some embodiments herein, the GUI may be configured to facilitate disposal and / or repair of the device by providing other relevant information in addition to or in lieu of the trade-in information, such as instructions to transfer the device to a third party or instructions to return the device to a particular location.

[0156] In some embodiments, and as shown in FIG. 42, a GUI configured to show a final screen of a remote verification process of the mobile device's status may include an indication that the mobile device has been approved for upgrade and / or trade-in. For example, GUI 4200 may be configured with a graphic and / or text (e.g., graphic and / or text as shown at 4201) indicating that the mobile device has passed one or more diagnostics and that security features have been determined to be disabled. In some embodiments, GUI 4200 may include a graphic and / or text (e.g., graphic and / or text as shown at 4202) indicating that the upgrade of the mobile device will only be completed if the mobile device is brought to a store and / or warehouse associated with the trade-in / upgrade entity. In some embodiments, GUI 4200 may include a link and / or button (e.g., button 4203) that, when selected, displays the mobile device on a satellite image and / or map and configures the GUI to generate a display of the nearest store and / or warehouse associated with the trade-in / upgrade entity for the user to bring the mobile device to. This process may include locating the mobile device and plotting the nearest trade-in location on a map for the user. In some embodiments, the GUI 4200 may include a button (e.g., a "Retake Test" button 4204) that may be selected by the user to resume a remote verification process of the mobile device's condition. In some embodiments, the GUI 4200 may include a button (e.g., an "Explore My Device" button 4205) that may be selected by the user to configure the mobile device's GUI to display one or more data objects associated with the mobile device that include one or more diagnostic results for the mobile device from one or more previously performed remote verification processes of the mobile device's condition.

[0157] In some embodiments, and as shown in FIG. 43, a GUI configured to display a final screen of a remote verification process of a mobile device's status may include an indication that the mobile device is unacceptable for upgrade and / or trade-in. For example, GUI 4300 may be configured with a graphic and / or text (e.g., a graphic and / or text as shown at 4301) indicating that the mobile device has failed at least one of the one or more diagnostics and the device has been rendered unacceptable (e.g., for trade-in). In some embodiments, GUI 4300 may include a graphic and / or text (e.g., a graphic and / or text as shown at 4302) indicating that one or more of the one or more diagnostics (e.g., in the depicted embodiment, the screen crack test, the touch screen test, and the battery health check) have passed (successfully). In some embodiments, the GUI 4300 may include a graphic and / or text (e.g., a graphic and / or text as shown in 4303) indicating that one or more of the one or more diagnostics (e.g., the Bluetooth test and the WiFi test in the depicted embodiment) have failed. Depending on criteria associated with the validation process, as described herein, a failed test may trigger an unacceptable condition. In some embodiments, the GUI 4300 may include a button (e.g., a “retest” (retake test) button 4304) that may be selected by a user to resume the remote validation process of the mobile device's condition (e.g., after enabling or otherwise correcting faults associated with Bluetooth and / or WiFi in the depicted embodiment).

[0158] It should be understood that implementations are not limited to the specific systems or processes described, which may, of course, vary. It should also be understood that the terminology used herein is for the purpose of describing particular implementations only, and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" include plural references unless the content clearly dictates otherwise. Thus, for example, reference to an "image" includes a combination of two or more images, and reference to a "graphic" includes different types and / or combinations of graphics.

[0159] Although the present disclosure has been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the present disclosure as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the specific embodiments of the processes, machines, manufacture, compositions of matter, means, methods, and steps described herein. As will be readily understood by those skilled in the art from the present disclosure, any currently existing or later developed processes, machines, manufacture, compositions of matter, means, methods, or steps that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein can be utilized in accordance with the present disclosure. It is therefore intended that the appended claims include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

1. 1. A computer-executable method for remotely verifying a state of a mobile device, the method comprising: receiving a request to verify the status of the mobile device; causing the mobile device, via a processor of the mobile device, to perform at least one diagnostic based on the request; receiving at least one security data object associated with the mobile device based on the request; determining that at least one of said security data objects indicates that a security feature associated with said at least one security data object is enabled; causing the rendering of a graphical user interface for a user of the mobile device configured to facilitate disabling the security feature; The method comprises:

2. At least one of the diagnostics comprises a crack detection routine, the crack detection routine comprising: prompting the user of the mobile device to aim a front-facing camera of the mobile device at a reflective surface; capturing an image of the mobile device using the front-facing camera; analyzing the image to determine if a crack is present or transmitting the image from the mobile device for analysis; Equipped with The method of claim 1.

3. At least one of the diagnostics comprises an internal diagnostic test. The method of claim 1.

4. The step of receiving at least one said security data object comprises: querying at least one external system; receiving at least one said security data object from said external system; Equipped with The method of claim 1.

5. the security data object is transmitted from the mobile device or from an external system to a remote verification system; The method of claim 1.

6. The method further comprises: at least one failure of said diagnosis; or at least one security data object indicating that the security feature associated with the at least one security data object is enabled; transmitting an indication of an unacceptable state of the mobile device upon detecting one or more of: The method of claim 1.

7. The method further comprises: displaying a prompt on the mobile device, the prompt requesting input of a serial number of the mobile device; receiving an identification data object associated with the mobile device; determining that the identification data object matches the serial number; Equipped with The method of claim 1.

8. the security data object is configured to be updated to indicate that the security features have been disabled after authentication credentials are entered into the mobile device or into a second interface of a second device having access to an account associated with the user of the mobile device. The method of claim 1.

9. The method further comprises: receiving an updated security data object indicating that the security feature has been disabled; determining an acceptable state of the mobile device based on the updated security data object; transmitting computer readable instructions from a remote verification server configured to facilitate a transfer of the mobile device from the user to a third party; Equipped with The method of claim 1.

10. the remote verification server is configured to determine the acceptable state and to facilitate the transfer of the mobile device from the user to the third party without requiring identification information associated with the user or the third party.

10. The method of claim 9.

11. The method further comprises: receiving an updated security data object indicating that the security feature has been disabled; determining an acceptable state of the mobile device based on the updated security data object; changing the indication of acceptable status of the mobile device to an unacceptable status after a predetermined threshold time has elapsed; Equipped with The method of claim 1.

12. The method further comprises: receiving an updated security data object indicating that the security feature has been disabled; transmitting an indication of an acceptable state of the mobile device; Equipped with The method of claim 1.

13. The method further comprises receiving a pass indication that the mobile device has passed at least one of the diagnostics prior to transmitting the indication of the acceptable state of the mobile device. The method of claim 12.

14. The method further comprises receiving the pass indication that the mobile device has passed at least one of the diagnostics prior to receiving the at least one security data object associated with the mobile device. The method of claim 13.

15. At least one non-transitory computer readable storage medium having computer program code stored thereon, the computer program code, when executed by at least one processor, receiving a request for verification of a state of the mobile device; causing the mobile device to perform at least one diagnostic via the processor of the mobile device based on the request; receiving at least one security data object associated with the mobile device based on the request; transmitting an indication of an acceptable state of the mobile device if a status of at least one of the security data objects indicates that a security feature associated with at least one of the security data objects is disabled; sending a disable indication for the mobile device if the status of at least one of the security data objects indicates that the security feature associated with at least one of the security data objects is enabled; causing the rendering of a graphical user interface for a user of the mobile device, the graphical user interface being configured to display at least the acceptable state of the mobile device or the invalid indicator of the mobile device; Equipped with At least one computer-readable storage medium.

16. The step of performing at least one of the diagnostics includes: instructing the user of the mobile device to aim a front-facing camera of the mobile device at a reflective surface; capturing an image of the mobile device using the front-facing camera; analyzing the image to determine if a crack is present or transmitting the image from the mobile device for analysis; Equipped with 16. At least one computer readable storage medium according to claim 15.

17. The step of receiving at least one said security data object comprises: querying at least one external system; receiving at least one said security data object from said external system; Equipped with 16. At least one computer readable storage medium according to claim 15.

18. the security data object is transmitted from the mobile device or from an external system to a remote verification system; 16. At least one computer readable storage medium according to claim 15.

19. The computer program code, when executed by at least one of the processors, failure of at least one of said diagnoses; or at least one security data object indicating that the security feature associated with the at least one security data object is enabled; transmitting an indication of an unacceptable state of the mobile device upon detecting one or more of:

16. At least one computer readable storage medium according to claim 15.

20. The computer program code, when executed by at least one of the processors, is configured to cause a prompt to be displayed on the mobile device, the prompt comprising: requesting input of a serial number of the mobile device; receiving an identification data object associated with the mobile device; determining that the identification data object matches the serial number; Equipped with 16. At least one computer readable storage medium according to claim 15.

21. the security data object is configured to be revoked after an authentication credential is entered into the mobile device or into a second interface of a second device having access to an account associated with the user of the mobile device.

21. At least one computer readable storage medium according to claim 20.

22. The computer program code comprises: receiving an updated security data object that, when executed by at least one of the processors, indicates that the security feature is disabled; determining the acceptable state of the mobile device based on the updated security data object; transmitting computer readable instructions from a remote verification server configured to facilitate a transfer of the mobile device from the user to a third party; 16. At least one computer readable storage medium according to claim 15.

23. the remote verification server is configured to determine the acceptable state and to facilitate a transfer of the mobile device from the user to the third party without requiring identification information associated with the user or the third party.

23. At least one computer readable storage medium as recited in claim 22.

24. The computer program code, when executed with at least one of the processors, receiving an updated security data object indicating that the security feature has been disabled; determining the permissible state of the mobile device based on the updated security data object; changing the indication of the acceptable state of the mobile device to an unacceptable state after a predetermined threshold time has elapsed; The method is configured to:

16. At least one computer readable storage medium according to claim 15.

25. the computer program code, in execution with at least one of the processors, is configured to: receive an updated security data object indicating that the security features are disabled, thereby transmitting the indication of the acceptable state of the mobile device.

16. At least one computer readable storage medium according to claim 15.

26. the computer program code, in execution with at least one of the processors, is configured to: receive a pass indication that the mobile device has passed at least one of the diagnostics prior to transmitting the indication of the acceptable state of the mobile device.

26. At least one computer readable storage medium according to claim 25.

27. The computer program code, in execution with at least one of the processors, is configured to receive the pass indication that the mobile device has passed at least one of the diagnostics prior to receiving at least one of the security data objects associated with the mobile device.

27. At least one computer readable storage medium according to claim 26.

28. The computer program code is contained on a software development kit (SDK) and can be applied to at least one or more mobile devices.

16. At least one computer readable storage medium according to claim 15.

29. 1. A system for remote verification of a mobile device, comprising: The system includes a processor of the mobile device, the processor comprising: receiving a request for validation of the mobile device; causing the mobile device to perform at least one diagnostic based on the request; receiving at least one security data object associated with the mobile device based on the request; transmitting an indication of an acceptable state of the mobile device if a status of at least one of the security data objects indicates that a security feature associated with at least one of the security data objects is disabled; sending a disable indication for the mobile device if the status of at least one of the security data objects indicates that the security feature associated with at least one of the security data objects is enabled; causing the rendering of a graphical user interface for a user of the mobile device, the graphical user interface being configured to display at least the acceptable state of the mobile device or the invalid indicator of the mobile device; The system comprises:

Images