Apparatus, method, and at least one non-transitory computer readable storage medium for claim management device lockout

Abstract

To perform a device lockout update action.SOLUTION: A method includes: receiving client device event data objects comprising a case initiation request; transmitting electronic data signals configured to cause an electronic lockout of the client device to a client device; transmitting case confirmation data to a device protection program management system, the case confirmation data being based at least in part on a client device fault data object or a client device loss data object; and, in a circumstance in which a claim status update data object is received from the device protection program management system, performing a device lockout update action based on the claim status update data object.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Embodiments of the present disclosure relate generally to managing electronic lockout of devices to enable a limited set of functionality, and specifically to managing electronic lockout of devices based on processing of claims associated with client devices by a device protection program management system. [Background technology]

[0002] Devices are often misplaced, stolen, or otherwise lost. Restricting access to such devices is desirable to prevent access to data stored on the device. In addition, preventing access to some of the device's full functionality can further reduce the possibility of unauthorized users acquiring and continuing to use the device, thereby unduly eliminating the need for unauthorized users to acquire their own devices for legitimate use. Such access prevention is also desirable in situations where a device is damaged and presented for repair or replacement. However, in situations where a device is locked, the device must be effectively managed to lock and / or unlock at the appropriate time. Improperly unlocking a device may provide unauthorized access to the device by users not intended and / or otherwise unauthorized to access the device. Improper locking of a device can cause user frustration for the legitimate owner and / or possessor, including situations where a user requests device lockout in connection with a loss and / or damage claim and later finds the device or changes their mind and keeps the device. In many cases, systems for managing device lockouts, managing claims associated with devices, and / or managing the initiation of such claims increase the difficulty of performing efficient and / or effective management of electronic lockouts as claims are processed. Applicant has discovered that current implementations of secure device lockout management are problematic. Through hard work, ingenuity, and innovation, Applicant has solved many of these identified problems by developing what is embodied in the present disclosure, as detailed below. Summary of the Invention [Problem to be solved by the invention]

[0003] In general, embodiments of the present disclosure include apparatus, computer-implemented methods, and computer program products for secure device lockout management. Other implementations of one or more alternative illuminator assemblies and / or alternative illuminated image devices will be, or become, apparent to one of ordinary skill in the art upon review of the following figures and detailed description. It is intended that all such additional implementations be included herein within the scope of this disclosure and protected by the following claims. [Means for solving the problem]

[0004] According to one aspect of the present disclosure, a computer-implemented method for secure device lockout management is provided. The computer-implemented method may be executed using any combination of computing devices embodied in various hardware, software, firmware, and / or combinations thereof, as described herein. In at least one exemplary embodiment, the exemplary computer-implemented method includes receiving a device charge request indication, the device charge request indication being associated with a client device, and the client device being associated with a feature lockout state. The exemplary computer-implemented method further includes initiating a charge associated with the client device based on the device charge request indication. The exemplary computer-implemented method further includes causing a feature lockout state of the client device to be set to a locked out state. The exemplary computer-implemented method further includes processing the charge to determine whether to approve the charge. The exemplary computer-implemented method further includes causing an update of the feature lockout state of the client device based on a determination of whether to approve the charge.

[0005] Additionally or alternatively, in some embodiments of the exemplary computer-implemented method, causing the feature lockout state of the client device to be set to a locked state includes sending a device lockout request to a manufacturer system associated with the client device, the device lockout request configured to cause the manufacturer system to set the feature lockout state of the client device to the locked state.

[0006] Additionally or alternatively, in some embodiments of the exemplary computer-implemented method, causing the feature lockout state of the client device to be set to a locked state includes sending a device lockout request to a third party system associated with the client device, the third party system including a carrier system configured to, in response to receiving the device lockout request, cause the manufacturer system to set the feature lockout state of the client device to the locked state.

[0007] Additionally or alternatively, in some embodiments of the exemplary computer-implemented method, processing the claim to determine whether to continue the client device in a locked-out state includes receiving user billing information associated with the claim within a first timestamp interval and processing the user billing information to approve the claim associated with the user billing information, and updating the feature lockout state of the client device based on the determination of whether to continue the client device in a locked-out state includes leaving the feature lockout state of the client device set to a locked-out state.

[0008] Additionally or alternatively, in some embodiments of the exemplary computer-implemented method, processing the billing to determine whether to continue the client device in a locked-out state includes receiving user billing information associated with the billing within a first timestamp interval and processing the user billing information to reject the billing associated with the user billing information, and updating the feature lockout state of the client device based on the determination of whether to continue the client device in a locked-out state includes setting the feature lockout state of the client device to an unlocked state.

[0009] Additionally or alternatively, in some embodiments of the exemplary computer-implemented method, processing the bill to determine whether to continue the client device in a locked-out state includes determining that user billing information associated with the bill has not been received within a first timestamp interval, and causing an update of the feature lockout state of the client device based on the determination of whether to continue the client device in a locked-out state includes causing the feature lockout state of the client device to be set to an unlocked state.

[0010] According to yet another aspect of the present disclosure, a computer program product for secure device lockout management is provided. In at least one exemplary embodiment of the computer program product, the computer program product includes 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, is configured to perform the computer-implemented method of any of the computer-implemented methods of the exemplary embodiments described above.

[0011] According to yet another aspect of the present disclosure, an apparatus for secure device lockout management is provided. In at least one exemplary embodiment, the apparatus includes at least one processor and at least one non-transitory memory. The at least one non-transitory memory includes computer-coded instructions stored therein. The computer-coded instructions, when executed by the at least one processor, configure the apparatus to perform any of the computer-implemented methods of the exemplary embodiments described above. Alternatively, or additionally, in some embodiments, the apparatus includes means configured to perform each step of any of the computer-implemented methods described above.

[0012] According to yet another aspect of the present disclosure, a second computer-implemented method for secure device lockout management is provided. The second computer-implemented method may be executed using any combination of computing devices embodied in various hardware, software, firmware, and / or combinations thereof, as described herein. In at least one exemplary embodiment, the second exemplary computer-implemented method includes receiving case confirmation data from a trusted third-party provider, the case confirmation data being associated with a client device identifier of the client device. The second exemplary computer-implemented method further includes causing rendering of a graphical user interface to a user, the graphical user interface including a request to enter user case information. The second exemplary computer-implemented method further includes receiving the user case information using the graphical user interface. In a situation where the user case information is received within a threshold claim initiation period, the method further includes initiating a claim based on the case confirmation data and the user case information, sending a claim creation notification data object to the trusted third-party provider, the claim creation notification data object including computer program instructions configured to cause a continuation of the electronic lockout of the client device, and receiving claim requirement data from at least one user device associated with the client device, the claim requirement data being based on a predefined rule set associated with a device protection program.In circumstances where claim requirement data is received within a threshold claim completion period, the method includes: in circumstances where the claim requirement data does not satisfy a predefined rule set, sending a claim rejection notification data object to the trusted third party provider, the claim rejection notification data object including computer program instructions configured to cause a termination of an electronic lockout of the client device; and in circumstances where the claim requirement data satisfies the predefined rule set, sending a claim approval notification data object to the trusted third party provider, the claim rejection notification data object including computer program instructions configured to cause a continuation of the electronic lockout of the client device.

[0013] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method further includes comparing the billing requirement data to a predefined rule set to determine whether the billing requirement data satisfies the predefined rule set.

[0014] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method further includes terminating processing of the case confirmation data in a situation where user case data is not received from at least one user device within a threshold claim initiation period.

[0015] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method further includes extracting a device identifier from the case confirmation data.

[0016] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method includes identifying an authentication token from the case confirmation data and utilizing the authentication token to retrieve third-party case data from a trusted third-party provider, wherein the third-party case data includes at least a device identifier.

[0017] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the computer-implemented method further includes: Additionally or alternatively, in situations where the billing requirement data is received within the billing requirement time threshold, comparing the billing requirement data with a predefined rule set to determine whether the billing requirement data satisfies the predefined rule set, the method further including approving the claim in situations where the billing requirement data satisfies the predefined rule set; Additionally or alternatively, in situations where the billing requirement data does not satisfy the device's predefined rule set, denying the claim.

[0018] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method further includes, in circumstances where the billing requirement data is not received within the billing requirement time threshold, terminating processing of the bill and sending a billing cancellation notification data object to the trusted third party provider, wherein the billing cancellation notification data object is configured to cause the trusted third party provider to terminate the electronic lockout of the client device.

[0019] According to yet another aspect of the present disclosure, a second computer program product for secure device lockout management is provided. In at least one exemplary embodiment of the second computer program product, the second computer program product includes 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, is configured to perform any of the second computer-implemented methods of the second exemplary embodiments described above.

[0020] According to yet another aspect of the present disclosure, a second apparatus for secure device lockout management is provided. In at least one exemplary embodiment, the second apparatus includes at least one processor and at least one non-transitory memory. The at least one non-transitory memory includes computer-coded instructions stored therein. The computer-coded instructions, when executed by the at least one processor, configure the second apparatus to perform any of the computer-implemented methods of the second exemplary embodiment described above. Alternatively or additionally, in some embodiments, the second apparatus includes means configured to perform each step of any of the computer-implemented methods described above.

[0021] According to yet another aspect of the present disclosure, a third computer-implemented method for secure device lockout management is provided. The third computer-implemented method may be executed using any combination of computing devices embodied in various hardware, software, firmware, and / or combinations thereof, as described herein. In at least one exemplary embodiment, the third exemplary computer-implemented method includes receiving a client device event data object associated with the client device, the client event data object including a case initiation request. The third exemplary computer-implemented method further includes transmitting an electronic data signal to the client device configured to cause an electronic lockout of the client device. The third exemplary computer-implemented method further includes transmitting case confirmation data to a device protection program management system, the case confirmation data being based at least in part on the client device failure data object or the client device loss data object. The third exemplary computer-implemented method further includes, in circumstances where a claim status update data object is received from the device protection program management system, performing a device lockout update action based at least on the claim status update data object.

[0022] Additionally or alternatively, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method further includes starting a drop dead timer of a predetermined period and sending an electronic data signal to the client device configured to cause an termination of an electronic lockout of the client device in a situation where a claim status update data object is not received from the device protection program management system within the predetermined period or a claim rejection notification data object is received from the device protection program management system within the predetermined period.

[0023] Additionally or alternatively, in some embodiments of the third exemplary computer-implemented method, performing a device lockout update action based on a billing status update data object includes terminating an electronic lockout in a situation where the billing status update data object includes a billing rejection notification data object, and continuing an electronic lockout of the client device in a situation where the billing status updated data object includes a billing approval notification data object.

[0024] Additionally or alternatively, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method further includes, in response to receiving a client device event data object, storing at least a portion of information associated with at least one of the client device event data objects, wherein the portion of information includes at least a client device identifier of the client device; receiving a case information request from the device protection program management system; in response to receiving the case information request, retrieving a portion of the case information; and in response to the case information request, transmitting the portion of the case information to the device protection program management system.

[0025] Additionally or alternatively, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method further includes receiving a billing cancellation notification data object from the device protection program management system and terminating the electronic lockout of the client device.

[0026] Additionally or alternatively, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method further includes receiving user case information associated with the client device and transmitting the user case information to a device protection program management system.

[0027] According to yet another aspect of the present disclosure, a third computer program product for secure device lockout management is provided. In at least one exemplary embodiment of the third computer program product, the third computer program product includes 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, is configured to perform any of the computer-implemented methods of the third exemplary embodiments described above.

[0028] According to yet another aspect of the present disclosure, a third apparatus for secure device lockout management is provided. In at least one exemplary embodiment, the third apparatus includes at least one processor and at least one non-transitory memory. The at least one non-transitory memory includes computer-coded instructions stored therein. The computer-coded instructions, when executed by the at least one processor, configure the third apparatus to perform any of the computer-implemented methods of the third exemplary embodiment described above. Alternatively, or in addition, in some embodiments, the second apparatus includes means configured to perform each step of any of the computer-implemented methods described above.

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

[0030] [Figure 1] 1 illustrates a block diagram of a system that may be specially configured within which embodiments of the present disclosure may operate. [Figure 2A] FIG. 1 shows a block diagram of an example device that may be specially configured in accordance with at least one example embodiment of the present disclosure. [Figure 2B]FIG. 10 shows a block diagram of yet another example device that may be specially configured in accordance with at least one example embodiment of the present disclosure. [Figure 3] 1 illustrates an example operation of an example process for secure device lockout management, in accordance with at least one example embodiment of the present disclosure. [Figure 4A] 10 illustrates additional operations of an exemplary process for secure device lockout management, particularly for causing a feature lockout state of a client device to be set to a locked out state, in accordance with at least one exemplary embodiment of the present disclosure. [Figure 4B] 10 illustrates additional operations of an exemplary process for secure device lockout management, particularly for causing a feature lockout state of a client device to be set to a locked out state, in accordance with at least one exemplary embodiment of the present disclosure. [Figure 5] FIG. 10 illustrates additional operations of an exemplary process for secure device lockout management, in accordance with at least one exemplary embodiment of the present disclosure, particularly for processing a claim to determine whether to approve the claim and, based on a determination of whether to approve the claim, triggering an update of a feature lockout state of a client device. [Figure 6A] FIG. 10 illustrates additional operations of an exemplary process for secure device lockout management, in accordance with at least one exemplary embodiment of the present disclosure, particularly for processing a claim to determine whether to approve the claim and, based on a determination of whether to approve the claim, triggering an update of a feature lockout state of a client device. [Figure 6B] FIG. 10 illustrates additional operations of an exemplary process for secure device lockout management, in accordance with at least one exemplary embodiment of the present disclosure, particularly for processing a claim to determine whether to approve the claim and, based on a determination of whether to approve the claim, triggering an update of a feature lockout state of a client device. [Figure 7]1 illustrates example operations of an example detailed process for secure device lockout management, particularly based on information from a trusted third-party provider, in accordance with at least one embodiment of the present disclosure. [Figure 8] 10 illustrates additional operations of an exemplary detailed process for secure device lockout management, particularly for handling claims as timeouts based on lack of user action, in accordance with at least one exemplary embodiment of the present disclosure. [Figure 9] 10 illustrates additional operations of an exemplary detailed process for secure device lockout management, particularly for processing received billing requirements data and setting appropriate lockout states, in accordance with at least one exemplary embodiment of the present disclosure. [Figure 10] 1 illustrates an example operation of secure device lockout management, particularly for device lockout state verification, in accordance with at least one example embodiment of the present disclosure. [Figure 11] 10 illustrates operation of yet another example process for secure device lockout management, in accordance with at least one example embodiment of the present disclosure. [Figure 12] 10 illustrates additional operations of an exemplary process for secure device lockout management, particularly for terminating an electronic lockout based on a drop dead timer, in accordance with at least one exemplary embodiment of the present disclosure. [Figure 13] 10 illustrates additional operations of an example process for secure device lockout management, particularly for performing device lockout update actions based on at least a billing status update data object, in accordance with at least one example embodiment of the present disclosure. [Figure 14] 10 illustrates additional operations of an exemplary process for secure device lockout management, particularly for providing information to a device protection program management system, in accordance with at least one exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0031] Embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings in which some, but not all, embodiments of the present disclosure are illustrated. 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; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout. Overview The device protection program management system can be configured to manage one or more device protection programs associated with various client devices, such as wireless devices. Using the device protection program, a user can register or subscribe a client device to the device protection program, so that if the client device is lost or stolen, the user can obtain a new device by submitting a claim using the device. In this regard, a claim can be initiated and / or processed using the device protection program management system for a request to replace, repair, and / or otherwise maintain a client device. In this regard, successful processing of a claim can allow, involve, and / or cause the performance of such action associated with the device.

[0032] A user may enroll in the device protection program through a trusted third party. For example, a user may purchase a client device from a device manufacturer and similarly enroll in the device protection program with the device manufacturer. The device manufacturer may control systems that are able to access one or more client devices, such as to obtain device information associated with the client device, information associated with applications installed or associated with the client device, and information associated with the client device's status or performance. Additionally, the device manufacturer's system may be configured to "lock out" a client device so that the client device is inoperable or unable to access functionality associated with the device. A lockout may prevent unauthorized or fraudulent users from using a device that has been reported lost or stolen, or that has been marked as damaged, inoperable, and / or the like.

[0033] A trusted third party, such as a device manufacturer, may authenticate a user using one or more authentication processes. For example, the trusted third party may require that the user provide user authentication credentials (e.g., username and password) and authenticate using two-factor authentication.

[0034] After a user authenticates with a trusted third party, such as a device manufacturer, the user can initiate a new third-party case by providing a loss indication associated with a client device that is subject to a device protection program, which indicates that the client device (e.g., a mobile phone) is not owned by the user. Thus, the trusted third party can generate a third-party case associated with the client device and the indication.

[0035] In some cases, performance of exchanges pursuant to the device protection program is handled using a device protection program management system of the device protection program provider. Thus, information is passed between the device protection program management system and a trusted third party (e.g., a device manufacturer) to enable the device protection program provider to process billing associated with the client device and to avoid unduly restricting the user's use of the client device in order to enhance and ensure user security and privacy.

[0036] For example, when a user (e.g., a client owner of a client device) initiates a third-party case, for example, using a device manufacturer's interface, the device manufacturer can provide a user authentication token along with a third-party case identifier to the device protection program management system. The user authentication token can be used to verify that the user initiating the claim has been authenticated with the device manufacturer. Thus, embodiments of the present disclosure enhance user security and user privacy by enabling the device protection program management system to identify and track claims initiated at the device manufacturer without requiring the device manufacturer to directly provide user authentication information. The user authentication token and third-party case identifier may enable the device protection program management system to retrieve information about the client device and, in some embodiments, verify that the client device is protected by one or more device protection programs using the device identifier.

[0037] The device protection program management system may also associate a trusted third party, such as a device manufacturer, with one or more authentication factors, such as an IP address, an entity token, and / or the like, which the device protection program management system can utilize to verify that a new third-party case identifier is associated with the device manufacturer. In this manner, the trusted third party is responsible for authentication, and the device protection program management system can trust the authentication performed by the trusted third party based on the trusted third party's recognition. The device protection program management system may be configured to store claim / case information associated with the third-party case identifier and can store a user authentication token for future communications with the trusted third party.

[0038] When the device protection program manages claim generation and processing, the device protection program may have the trusted third party lock out the client device in response to user information provided within a predefined period indicating a desire to continue with the claim. In some embodiments, if the device protection program management system does not confirm receipt and acceptance of the user authentication token and third-party case identifier, the trusted third party can override the lockout and allow access to the client device. For example, when a device manufacturer initiates a new third-party case and sends the user authentication token and third-party case identifier to the device protection program management system, the device manufacturer may maintain the lockout for a threshold claim initiation period (e.g., 24 hours) unless the device protection program management system indicates that the user authentication token and third-party case identifier have been confirmed and accepted (e.g., the device protection program management system may confirm that the token and identifier are valid and / or that the client device is protected by the device protection program). If a confirmation signal is sent from the device protection program management system to the trusted third party, the trusted third party can maintain the lockout and wait for a further status signal from the device protection program management system, and the device protection program management system can initiate the claim generation process.

[0039] The user may then be presented with an interface of the device protection program management system and allowed to submit a claim, which may be generated based at least in part on the user's input into the device protection program management system, which may then initiate a claim generation time limit (e.g., 24 hours). If the user does not proceed with the claim (e.g., complete the claim generation process and enter all required information) and the claim time limit has elapsed, the device protection program management system may determine that the user has abandoned the claim, and the device protection program management system may send a status signal to the trusted third party to have the trusted third party end the client device lockout and return the device to functioning (e.g., because the claim has not been submitted, it is assumed that the user no longer desires a replacement for the lost or stolen device). During the initiation of the claim, but before the claim is completed, the user may provide account, payment, incident-related affidavits, statements of fact, or other information necessary to complete the claim. Once the information is complete and the user authorizes the device protection program management system to proceed, the claim may be considered submitted and generated.

[0040] If the claim is submitted and approved, the device protection program management system may proceed with claim fulfillment. The fulfillment of the claim may result in a decision event, which may include claim acceptance (e.g., issuing a replacement device), claim denial (e.g., denying the replacement), and / or termination of the claim for lack of activity. Thus, the device protection program management system may send one or more status signals to, for example, allow the device manufacturer to continue the client device lockout indefinitely when a new device is delivered to the user. If the claim is submitted and denied or terminated for inactivity, the device protection program management system may determine that the claim is fraudulent and cause the device manufacturer to terminate the client device lockout.

[0041] By authenticating users utilizing authentication tokens or equivalent information provided by a trusted third party, embodiment device protection program management systems enhance user privacy by enabling authentication without requiring the disclosure of user authentication credentials. Furthermore, embodiment device protection program management systems enhance user security by locking out or functioning client devices depending on claim status, thereby preventing malicious actors from accessing client devices that have been legitimately determined to be lost or stolen, reducing the risk of fraud for the device protection program management system and trusted third parties. Furthermore, by using multiple checkpoints across systems to restore access to client devices when claims are not progressing, either through user selection or system error, users are not unduly restricted from their devices.

[0042] Thus, embodiments of the present disclosure generate, manage, and / or process claims in a secure manner while maintaining proper device functionality for the corresponding client device. For example, in some embodiments, when a user loses a client device or reports it stolen and initiates a third-party case through a trusted third-party provider, the client device is locked out to prevent a malicious user (e.g., a thief or malicious finder of the device) from accessing the client device, thereby enhancing user privacy and reducing fraud. However, if the user abandons the claim or cancels the claim via a claim cancellation interface provided through the device protection program management system, a call center claim cancellation request, etc., an embodiment device protection program management system is configured to provide a notification to the trusted third-party resource and have the trusted third-party resource return the device to functional form. Furthermore, utilizing threshold claim initiation periods and / or claim time limits, embodiments of the present disclosure enable the trusted third-party resource to return the device to functional form when the user detects that the user has abandoned the case and / or associated claim and no longer pursues the claim, reducing the likelihood of the user being improperly or unjustifiably locked out of the device. Thus, embodiments of the present disclosure utilize specific information flows between separate systems and entities to provide a positive user billing management experience while enhancing user security and maintaining user privacy. The term "secure device lockout management" refers to specialized hardware, firmware, and / or software level processes for preventing access to some or all of the functionality of an electronic device, such as a user device, server, system, etc. In some embodiments, secure device lockout management refers to a process for preventing access to some or all of the functionality of a client device by one or more communicable systems described herein, e.g., a device protection program management system and at least one trusted third-party provider.

[0043] The term "device protection program management system" refers to any number of computing devices embodied in hardware, software, firmware, and / or combinations thereof to perform one or more actions associated with enrolling and / or maintaining enrollment of one or more client devices with one or more associated device protection program(s), and / or one or more actions associated with receiving and / or processing data associated with one or more claims associated with client devices enrolled in a device protection program. Additionally or alternatively, in some embodiments, the device protection program management system is configured to perform one or more actions for secure device lockout management, as described herein.

[0044] The terms “trusted third party provider” and “third party provider” refer to one or more servers, systems, or other computing hardware that communicate with the device protection program management system and that is controlled by a second entity different from the first entity that controls the device protection program management system. In some embodiments, the trusted third party provider is configured to communicate with at least the client device to control an electronic lockout of the client device, or at least communicates with a second trusted third party provider that is configured to communicate with the client device to control an electronic lockout of the client device.

[0045] The term "manufacturer system" refers to an example of a trusted third-party provider that controls a manufacturer entity associated with the production, manufacturing, and / or creation of the hardware, software, and / or firmware that embodies a client device. In some embodiments, for example, the manufacturer system is embodied by one or more computing devices controlled by a mobile device manufacturer entity and configured to communicate with at least a client device, another trusted third-party system, a device protection program management system, and / or any combination thereof.

[0046] The term "carrier system" refers to an example of a trusted third-party provider that controls a carrier entity and is associated with providing cellular and / or data connectivity services to one or more client devices that are registered for one or more services offered using the carrier system and / or one or more associated systems controlled by the carrier entity. In some embodiments, the carrier system is embodied by one or more computing devices controlled by the carrier entity and configured to communicate with at least the device protection program management system.

[0047] The term "device" refers to hardware, firmware, and / or software that embodies a computer that provides specialized and / or general computing functionality for use by a user of the device. The term "owner" refers to the legitimate owner of the device, who may or may not be the user of the device. Non-limiting examples of user devices include laptops, desktops, mobile phones, smartphones, tablets, personal digital assistants, smart home devices, and customized computing hardware.

[0048] The term "client device" refers to a device enrolled in at least one device protection program managed using the device protection program management system. In at least one example context, the term "client device" refers to a mobile device (e.g., a smartphone) enrolled in an accidental damage protection program.

[0049] The term "client device identifier" refers to one or more data values ​​that uniquely identify a client device. In some embodiments, a client device identifier is embodied by one or more numeric, alphanumeric, and / or alphabetic identifiers embodied in any of a number of computer data value types. For example, in at least one exemplary context, non-limiting examples of client device identifiers include one or more data values ​​encoded using the American Standard Code for Information Interchange (ASCII) encoding standard, the Unicode encoding standard, a numeric data representation, or the like.

[0050] The term "user device" refers to a device capable of communicating with at least a third-party provider and / or a device protection program management system over one or more communications networks. In some embodiments, the user device is utilized to access the third-party provider and / or the device protection program management system to perform one or more actions to initiate and / or fulfill a claim associated with the client device. In some embodiments, for example, the user device is a second device owned by the same owner as the client device associated with the claim.

[0051] The term "electronic lockout" refers to a state of a client device in which the client device is configured to perform a limited set of functions. In some embodiments, the electronic lockout of a client device is initiated by communication between the client device and one or more remote systems, e.g., a trusted provider system and / or a device protection program management system. In some embodiments, during an electronic lockout of a client device, the client device is at least capable of receiving one or more signals to terminate the electronic lockout and / or is capable of performing at least one permissible limited functionality action(s).

[0052] The term "device lockout update action" refers to one or more actions performed by the device protection program management system to initiate, modify, and / or terminate an electronic lockout of at least one client device. In at least some embodiments, a device lockout update action includes, but is not limited to, setting a feature lockout state of a client device to initiate and / or terminate an electronic lockout of the client device.

[0053] The term "feature lockout status" refers to an electronic data value that represents whether an electronic lockout is currently affecting a client device. In some embodiments, for example, the feature lockout status of a client device refers to electronic data managed by the client device, which in some embodiments can be retrieved by one or more remote systems using one or more requests.

[0054] The term "lockout state" associated with a client device refers to a first unique electronic data value that indicates that the client device is in an electronic lockout state and is therefore associated with limited functionality.

[0055] The term "device lockout request" refers to electronically generated data associated with setting the feature lockout status of a client device to a locked state. In this regard, the device lockout request initiates an electronic lockout of the client device. In some embodiments, the device lockout request is generated and / or transmitted from a device protection program management system to one or more third-party providers, such as carrier systems and / or manufacturer systems, that communicate directly or indirectly with the client device to be locked out.

[0056] The term "unlocked state" associated with a client device refers to a second unique electronic data value that indicates that the client device is not in an electronic lockout state. The term "device unlock request" refers to electronically generated data associated with setting a client device's feature lockout state to an unlocked state. In this regard, the device unlock request ends the electronic lockout of the client device. In some embodiments, the device lockout request is generated and / or transmitted from a device protection program management system to one or more third-party providers, such as a carrier system and / or a manufacturer system, that communicate directly or indirectly with the client device to be unlocked.

[0057] The term "device claim request indication" refers to data received by the device protection program management system, for example, from a user device or a third-party provider, indicating a request to initiate generation and / or processing of a claim associated with a client device. In some embodiments, the device protection program management system receives data representing the device claim request indication from the user device indirectly through a third-party provider in response to submission of information from the user device to the third-party provider.

[0058] The term "claim" refers to electronic data managed by the device protection program management system that represents a request to replace, repair, and / or modify a client device based on the client device's associated device protection program.

[0059] The term "claim status" refers to an electronically managed data parameter within and / or associated with a claim, the value of which indicates whether the claim has been processed and / or fulfilled in accordance with the corresponding device protection program. In at least one example context, the value of the claim status represents, but is not limited to, a pending status, an approved status, a denied status, a canceled status, and / or a timeout status, as described herein. In some embodiments, the device protection program is configured to perform a limited subset of actions on a claim based on the claim's corresponding claim status.

[0060] The term "pending status" refers to an electronic data value that represents a claim that has been submitted but has not yet been fully processed using the device protection program management system. In some embodiments, the pending status indicates that further processing of the claim requires the submission of additional data. Additionally or alternatively, for a pending claim, in some embodiments, the device protection program management system is configured to enable one or more actions to submit additional data and / or cancel processing of the claim.

[0061] The term "approval status" refers to another electronic data value that represents that a claim has been submitted, fully processed, and approved for fulfillment with the device protection program management system (i.e., the claim is "approved"). In some embodiments, for a claim in approved status, the device protection program management system is configured to enable one or more actions to fulfill the claim. In some embodiments, once a claim is set to approved status, the device protection program prevents cancellation of the claim.

[0062] The term "denied status" refers to another electronic data value that represents a claim that has been submitted, fully processed, and not approved for fulfillment through the device protection program management system (i.e., the claim has been "denied"). In some embodiments, for claims in denied status, the device protection program management system prevents cancellation of the claim.

[0063] The term "cancellation status" refers to another electronic data value that represents that a claim has been canceled by a user using the device protection program management system. In some embodiments, the device protection program management system is configured to allow for more actions to cancel a claim while the claim has not yet been fully processed, for example, at least when in "pending status."

[0064] The term "timeout status" refers to another electronic data value that represents that a request has been generated but no additional data has been received within the required timestamp interval. In some embodiments, the device protection program management system is configured to automatically perform one or more actions to set the claim status to a timeout status.

[0065] The term "claim status update data object" refers to an electronically managed data object that represents a value of the claim status of a claim. In some embodiments, the claim status update data object is generated by the device protection program management system and / or otherwise transmitted to a third party when the device protection program management system updates the claim status of a claim.

[0066] The term "claim creation notification data object" refers to an electronically managed data object generated by the device protection program management system and / or transmitted from the device protection program management system to a third-party provider, the data object representing the generation and / or storage of a claim by the device protection program management system.

[0067] The term "claim authorization notification data object" refers to an electronically managed data object generated by and / or transmitted from the device protection program management system to a third-party provider, the data object representing the setting of the claim's billing status to an approved status.

[0068] The term "claim denial notification data object" refers to an electronically managed data object generated by and / or transmitted from the device protection program management system to a third-party provider, the data object representing the setting of the claim status of the claim to an approved status.

[0069] The term "claim cancellation notification data object" refers to an electronically managed data object generated by and / or transmitted from the device protection program management system to a third-party provider, the data object representing the setting of the claim status of a claim to a canceled status.

[0070] The term "claim timeout notification data object" refers to an electronically managed data object generated by and / or transmitted from the device protection program management system to a third-party provider, the data object representing the setting of the claim status of a claim to a timeout status.

[0071] The term "case confirmation data" refers to data received by the device protection program management system from a third-party provider and / or a user device, including user-submitted data for use in generating a claim for a client device under a corresponding device protection program. In some exemplary embodiments, the case confirmation data includes some or all of the data received by a third-party provider associated with a user request to initiate a claim for a client device and / or third-party provider-generated data associated with such request. In at least one exemplary context, the case confirmation data represents an exemplary device claim request representation.

[0072] The term “authentication token” refers to electronically managed data representing a user identity verified by a third-party provider. In this regard, in some embodiments, an authentication token includes data indicating that the third-party provider has successfully verified the identity of a user associated with submitted data using one or more authentication processes. In some embodiments, the third-party provider generates the authentication token and / or provides it to the device protection program management system for use in verifying that the user's identity is valid and / or in accessing and / or retrieving information stored by the third-party provider. In some embodiments, the authentication token includes algorithmic and / or cryptographic information that validates the token with respect to the third-party provider that generated it and / or one or more users or user accounts verified by the third-party provider.

[0073] The term "case information request" refers to electronically managed data transmitted from the device protection program management system to a third-party provider and represents a request for at least some of the information maintained by the third-party provider associated with the user-submitted data to initiate a claim. In some embodiments, the case information request includes an authentication token associated with the third-party provider so that the third-party provider can use the authentication token to verify the identity of the device protection program management system and / or identify the information to be retrieved and / or transmitted in response to the request.

[0074] The term "third-party case data" refers to information stored by a third-party provider associated with a request submitted by a user to initiate a claim associated with a client device. In some embodiments, the device protection program management system is configured to retrieve third-party case data related to the claim from the third-party provider using stored data associated with the claim, e.g., an authentication token of the third-party provider.

[0075] The term "user case information" refers to information submitted by a user to complete the initiation of a claim associated with a client device. In some embodiments, the device protection program management system receives initial information, such as third-party case data, from a third-party provider and then receives user case information associated with the third-party case data from the user device. In some embodiments, the device protection program management system is configured to receive the user case information directly from the user device. In other embodiments, the device protection program management system is configured to receive the user case information indirectly through a third-party provider.

[0076] The term "device protection program" refers to electronically managed data representing a set of support and / or protection actions for one or more devices. In this regard, in some embodiments, a device protection program defines one or more circumstances under which a device may be replaced, repaired, and / or otherwise supported at no cost and / or a reduced cost to the device owner and / or holder. In some embodiments, a device protection program is represented by a predefined rule set for receiving one or more implementation actions associated with the device protection program.

[0077] The term "predefined rule set" refers to a number of electronically executed comparison actions, decision actions, and / or data check actions associated with one or more claims that must be satisfied for the claim to be approved. In some embodiments, the predefined rule set embodies the device protection program such that a claim initiated in connection with the device protection program is approved in situations where data submitted in connection with the claim satisfies some or all of the predefined rule set. Examples of predefined rules within the predefined rule set include, but are not limited to, data checks that a user submits data within a predetermined timestamp interval, that specific data is submitted by a user (e.g., sufficient loss or damage event information), and / or that the submitted data contains specific data values ​​(e.g., a damage event is within a predetermined set of target data values).

[0078] The term "claim requirement data" refers to user-submitted data associated with a particular claim for comparison with one or more rules in a predefined rule set representing a device protection program.

[0079] The term "timestamp interval" refers to a period of time embodied by one or more timestamps. In some embodiments, a timestamp interval is embodied by a start timestamp and an end timestamp.

[0080] The term "threshold claim initiation period" refers to the timestamp interval within which a user must submit user case information to the device protection program management system to initiate a claim associated with the third-party case data.

[0081] The term "threshold claim completion period" refers to the timestamp interval within which a user must submit claim requirement data to the device protection program management system to allow for full processing of an initiated claim. In some embodiments, the device protection program is configured to set the claim status of an initiated claim to a predefined status, e.g., a timeout status, in circumstances where claim requirement data is not received for the claim within the threshold claim completion period.

[0082] The term "client device event data object" refers to data received from a user device associated with a client device that indicates a user request to initiate a billing associated with the client device. In some embodiments, the client device event data object is received from the user device by a third-party provider.

[0083] The term "case initiation request" refers to data sent from a third-party provider to a device protection program management system to indicate that a user has requested the initiation of a claim associated with a client device. In some embodiments, the case initiation request includes at least case confirmation data for use in generating the claim.

[0084] The term "client device fault data object" refers to electronically managed data that represents information associated with reduced operation and / or damage to a client device. In some embodiments, a client device fault data object includes one or more data values ​​submitted by a user that describe the reduced operation and / or damage to a client device.

[0085] The term "client device lost data object" refers to electronically managed data representing information associated with a stolen, lost, and / or otherwise inaccessible client device. In some embodiments, the client device lost data object includes one or more data values ​​submitted by a user that describe the theft, loss, and / or inaccessibility of the client device.

[0086] The term "drop dead timer" refers to a timestamp interval tracked by a third party provider or associated system and / or device protection program management system or associated system, representing the period of time during which a user must submit sufficient data to allow full processing of a claim. In some embodiments, upon completion of the drop dead timer (i.e., the timer expires without sufficient data being received), the third party provider and / or device protection program management system is configured to terminate the electronic lockout of the client device. System Architecture 1 illustrates a block diagram of an exemplary system in which embodiments of the present disclosure may operate. As shown, the exemplary system includes a device protection program management system 102, a trusted third-party provider 108, a user device 104, and a client device 106. In some embodiments, the trusted third-party provider 108 embodies a device manufacturer system. Alternatively, or in addition, in some embodiments, the trusted third-party provider 108 embodies a carrier system. In some embodiments, the exemplary system further includes a third-party manufacturer system 112.

[0087] The device protection program management system 102, the trusted third-party provider 108, the user device 104, and the client device 106 may be configured to communicate with one another over one or more networks, such as a network 110. In some embodiments, to enhance user security, the client device 106 may be configured to communicate only with the trusted third-party provider 108 over the network 110, thereby preventing the device protection program management system 102 from directly communicating with and / or accessing the client device 106. Additionally or alternatively, in some embodiments, one or more systems are configured to communicate with a third-party manufacturer system 112. In some such embodiments, the third-party manufacturer system 112 is configured to communicate with the client device 106, for example, to initiate and / or terminate an electronic lockout of the client device that embodies a client device lockout. In some such embodiments, the third-party manufacturer system 112 may communicate with the device protection program management system 102 directly or indirectly through communication with the trusted third-party provider 108. In some such embodiments, the third-party manufacturer system 112 is configured to communicate with the trusted third-party provider 108 and / or the device protection program management system 102 using one or more communication networks, such as the communication network 110.

[0088] The client device 106 may be enrolled in, or otherwise associated with, a device protection program associated with the device protection program management system 102. For example, in some embodiments, a user may subscribe / register the client device 106 to the device protection program with a trusted third-party provider 108 so that if the client device 106 is lost or stolen, the user can open a third-party case with the trusted third-party provider 108, which allows the user to submit a claim for a new client device with the device protection program management system 102. In some embodiments, both the user device 104 and the client device 106 may be associated with a single user. Alternatively, or additionally, the user device 104 may be accessed to log in to a user account associated with the device protection program, the device protection program management system 102, and / or the client device 106.

[0089] In some embodiments, the trusted third party provider 108 is configured to initiate a third-party case associated with a device protection program associated with the client device. For example, a user may enroll the client device 106 in a device protection program that covers loss and theft of the client device 106. The trusted third party provider 108 may be configured to communicate with the user device 104 to authenticate a user associated with the user device 104. In particular examples, the trusted third party provider 108 may utilize one or more authentication processes to securely authenticate a user, for example, authenticating a received username and password, performing multi-factor authentication on the user device 104 or a second user device using a text or SMS message, and / or performing multi-factor authentication via an email profile associated with the user device. Thus, the trusted third party provider 108 may identify an authenticated third-party user account associated with the trusted third party provider 108.

[0090] After authenticating the user, the trusted third party provider 108 can provide a case initiation interface to the user. For example, the trusted third party provider 108 may be configured to generate and / or provide a case initiation interface displaying all client devices and / or user devices associated with the user so that the user can initiate a third-party case associated with the stolen or lost client device 106. In response to a loss indication associated with the client device 106, for example, in response to user engagement with a “Lost Device” component of the case initiation interface associated with a particular client device, the trusted third party provider 108 is configured to initiate a new third-party case associated with the client device. The trusted third party provider 108 may identify third-party case information associated with the third-party case, for example, a device identifier associated with the client device 106, previous cases, and / or the number of previous cases initiated by a user associated with the authenticated third-party user account, and / or the like.

[0091] Additionally and / or alternatively, in response to receiving a loss indication, trusted third-party provider 108 may be configured to access client device 106, directly and / or indirectly using a manufacturer system, such as third-party manufacturer system 112, to extract, identify, and / or obtain information from and / or associated with the client device in real time. For example, trusted third-party provider 108 may access a device identifier (e.g., International Manufacturer Equipment Identity (IMEI), Internet The third-party case information may extract, identify, and / or otherwise retrieve one or more from a group including the client device's IP address, alphanumeric identifier, previous case information (e.g., the number of third-party cases opened associated with a particular client device and / or user), device location resource information (e.g., whether access to a device location application is enabled associated with the client device, whether the user attempted to access a device location application to locate the client device, the last time the user accessed a device location resource to locate the device, etc.). Additionally or alternatively, in some embodiments, the third-party case information may include location information, status information for each application associated with the client device, stored data information, etc., associated with the client device 106 associated with the case at the time the user initiated the third-party case, such that the third-party case information serves as a snapshot of all information present on the client device 106 at the time the user initiated the third-party case.

[0092] Additionally, the trusted third party provider 108 may be configured to toggle a lockout feature associated with the client device 106. The lockout feature may cause, for example, the client device to become inaccessible, inoperable, or otherwise non-functional. In some embodiments, the trusted third party provider 108 may be configured to initiate a lockout of the client device 106 upon receiving a loss indication or upon receiving a user's approval and indication of intent to claim the lost device.

[0093] The device protection program management system 102 is configured to generate, manage, and / or fulfill one or more claims associated with the device protection program. For example, upon initiation of a new third-party case, the trusted third-party provider may send a third-party case confirmation to the device protection program management system 102 to indicate that the new third-party case associated with a particular third-party case identifier was initiated by an authenticated user. In some embodiments, the trusted third-party provider provides authentication to the device protection program management system 102. For example, after initiating a new third-party case, the trusted third-party provider may send an authentication token to the device protection program management system 102, where the authentication token indicates that the trusted third-party provider 108 has successfully authenticated the user associated with the new third-party case. Thus, the device protection program management system 102 may receive both the third-party case identifier and the authentication token from the trusted third-party provider 108, thereby enabling the device protection program management system 102 to verify that the case was initiated by a legitimate user of the trusted third-party provider system 108 without accessing or requiring the user's user authentication credentials to access the trusted third-party provider system 108.

[0094] The device protection program management system 102 may also be configured to continue or terminate the lockout of a client device 106 associated with a given third-party case. For example, the trusted third-party provider 108 may lock out a client device 106 upon initiation of a third-party case by an authenticated user, whereby the lockout terminates after a predetermined period of time (e.g., 24 hours) has elapsed without further notification and / or status updates from the device protection program management system 102. In some embodiments, when a claim generation process is initiated and handed over from the trusted third party to the device protection program management system 102, the device protection program management system 102 is configured to receive user case information from the user, and if the user case information is received within a threshold claim initiation period (e.g., 24 hours), the device protection program management system 102 may signal the trusted third-party provider 108 to continue the lockout, for example, by sending a claim creation notification data object to the trusted third-party provider 108.

[0095] In some embodiments, the device protection program management system 102 is also configured to create a claim associated with the third-party case utilizing the received information. In some embodiments, the claim period begins as soon as the claim is generated and processed by the device protection program management system 102. During the claim period, the user has a limited time, e.g., a determined or predetermined period (e.g., 30 days), to complete the claim. In some embodiments, after the claim is generated and the user requests a replacement device, additional claim requirements and / or claim parameters may be identified by the device protection program management system 102, resulting in the user having to submit additional claim information to proceed with the claim. If the claim information is not received within the claim time limit, the device protection program management system 102 can determine that the user has abandoned the claim and terminate the claim due to insufficient action. The device protection program management system 102 can send a notification, such as a claim cancellation notice, to the trusted third-party provider 108 configured to cause the trusted third-party provider 108 to end the lockout and return the client device 106 to functioning.

[0096] If, at any point, the user affirmatively indicates that they wish to cancel the claim and / or corresponding third-party case, for example, through submitting one or more data requests directly through the device protection program management system 102 and / or indirectly through the trusted third-party provider 108, the lockout of the client device 106 can also be terminated. For example, the user can indicate that they are canceling the claim either during the claim generation process or during claim processing before the claim is fulfilled through engagement with a cancel user interface component provided by the device protection program management system 102. The user may, for example, initiate the claim but then locate the client device 106 before doing so. Thus, the device protection program management system 102 can instruct the trusted third-party provider 108 to terminate the lockout of the client device 106 and return the client device to a functional form. In some embodiments, the device protection program management system 102 can terminate the lockout through one or more transmissions to the third-party manufacturer system 112, either directly or indirectly through the trusted third-party provider 108.

[0097] Once all claim information is received during the fulfillment process, the device protection program management system 102 may be configured to approve or deny the claim. For example, the device protection program management system approves or denies the claim based on third-party case information, user case information, and / or claim parameters or associated matters. If the claim is approved, the device protection program may cause the trusted third-party provider 108 to update the third-party case status, such as by sending a notification to the trusted third-party provider 108, and may cause the trusted third-party provider 108 to continue locking out the client device 106. After approving the claim, the device protection program management system 102 may fulfill the claim and provide a new device to the user associated with the client device 106. Thus, by keeping the client device 106 electronically locked out, embodiments herein enhance user security by preventing malicious third-party actors from accessing the user device 104 after a theft or loss. In some embodiments, after approving the claim, the electronic lockout of the client device 106 may continue permanently.

[0098] Alternatively, the device protection program management system 102 may deny the claim based on the third-party case information, the user case information, and / or the claim parameters or associated requirements. Accordingly, in some embodiments, the device protection program management system 102 is configured to cause the trusted third-party provider 108 to terminate the lockout associated with the client device in response to denying the claim, for example, by sending a notification to the trusted third-party provider 108. The device protection program management system 102 may be embodied by one or more computing systems, such as the device 200 shown in Figure 2A. As shown in Figure 2A, the device 200 may include a processor 202, a memory 204, an input / output module 206, a communication module 208, and a device lockout management module 210. The device 200 may be configured to perform the operations described below using one or more of the modules 202-210.

[0099] Although these components are described in terms of functional limitations, it should be understood that particular implementations necessarily involve 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 modules may utilize the same processor, network interface, storage medium, etc., to perform their associated functions, thereby avoiding the need for duplicate hardware in each module. Thus, use of the terms "module" and / or "circuitry" as used herein with respect to components of device 200 should be understood to include specific hardware configured to perform the functions associated with the particular module as described herein.

[0100] Additionally or alternatively, the terms "module" and "circuitry" should be broadly understood to include hardware, and in some embodiments, software and / or firmware for configuring hardware. For example, in some embodiments, a "module" and / or "circuitry" may include processing circuitry, storage media, network interfaces, input / output devices, etc. In some embodiments, other elements of apparatus 200 may provide or supplement the functionality of a particular module. For example, processor 202 may provide processing functionality, memory 204 may provide storage functionality, communication module 208 may provide network interface functionality, etc.

[0101] In some embodiments, the processor 202 (and / or a coprocessor, or any other processing circuitry assisting or otherwise associated with the processor) may communicate with the memory 204 via a bus for passing information between components of the device. The memory 204 may be non-transitory, e.g., may include one or more volatile and / or non-volatile memories. In other words, for example, the memory may be an electronic storage device (e.g., a computer-readable storage medium). The memory 204 may be configured to store information, data, content, applications, instructions, etc. to enable the device 200 to perform various functions in accordance with exemplary embodiments of the present disclosure.

[0102] The processor 202 may be embodied in any one of numerous ways, and may, for example, include one or more processing devices configured to execute independently. Additionally or alternatively, the processor may include one or more processors configured in tandem with a bus to enable independent execution of instructions, pipelines, and / or multithreads. Use of the terms "processor," "processing module," and "processing circuitry" may be understood to include single-core processors, multi-core processors, multiple processors within a device, and / or remote or "cloud" processors.

[0103] In an exemplary embodiment, processor 202 may be configured to execute computer-coded instructions stored in memory 204 or otherwise accessible to the processor. Alternatively, or in addition, processor 202 may be configured to execute hard-coded functionality. Thus, whether configured by hardware or software methods, or a combination thereof, processor 202 may represent an entity (e.g., physically embodied in circuitry) that, when configured accordingly, can perform operations according to embodiments of the present disclosure. Alternatively, as another example, if the processor is embodied as an executor of software instructions, the instructions, when executed, may specifically configure the processor to perform the algorithms and / or operations described herein.

[0104] As an example context, processor 202 may be configured to generate, process, and / or fulfill one or more claims associated with a client device. In this regard, processor 202 may be configured to enable apparatus 200 to process received data for purposes of determining whether to approve and / or deny an initiated claim. Additionally or alternatively, in some embodiments, processor 202 is configured to trigger the initiation of an electronic lockout and / or trigger the termination of an electronic lockout of a client device, for example, with one or more transmissions. Additionally or alternatively, in some embodiments, processor 202 is configured to enable a user to enroll a client device in a device protection program, initiate a claim associated with the device protection program for the client device, cancel an existing claim, and / or unenroll from the device protection program. In some embodiments, processor 202 is configured to automatically trigger the initiation of an electronic device lockout and / or automatically trigger the termination of an electronic device lockout upon the initiation, processing, and / or completion of a claim.

[0105] In some embodiments, device 200 may include an input / output module 206, embodied in hardware, software, firmware, or a combination thereof, which in turn communicates with processor 202 to provide output to a user and, in some embodiments, receive a display of user input. Input / output module 206 may include a user interface and may include a display (e.g., for rendering one or more user interfaces). User interfaces include web user interfaces, mobile applications, desktop applications, linked or networked client devices, kiosks, etc. In some embodiments, input / output module 206 may also include a keyboard, mouse, joystick, touch screen, touch area, soft keys, microphone, speaker, or other input / output mechanism. A processor and / or a user interface module including a processor, for example, processor 202, may be configured to control one or more functions of one or more user interface elements through computer program instructions (e.g., software and / or firmware) stored in memory accessible to the processor (e.g., memory 204, and / or the like).

[0106] Additionally or alternatively, in some embodiments, device 200 includes a communications module 208. Communications module 208 may be any means, such as a device or circuit embodied in either hardware or a combination of hardware and software, configured to receive and / or transmit data to and from a network and / or other devices, circuits, or modules in communication with device 200. In this regard, communications module 208 may include, for example, a network interface for enabling communication with a wired or wireless communications network. For example, communications module 208 may include 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, communications interface may include circuitry for interacting with antenna(s) to cause transmission of signals via the antenna(s) or for processing reception of signals received via the antenna(s).

[0107] Additionally or alternatively, in at least some embodiments, apparatus 200 includes a device lockout management module 210. In some such embodiments, device lockout management module 210 is embodied in any of software, hardware, firmware, and / or combinations thereof. In this regard, device lockout management module 210 may be embodied in any manner to enable enrollment in and / or de-enrollment from a device protection program. Additionally or alternatively, device lockout management module 210 may be embodied in any manner to enable initiation of charges against a client device associated with a device protection program, processing of charges against the client device, and / or fulfillment of charges against the client device responsive to such processing. In some embodiments, additionally or alternatively, device lockout management module 210 is configured to trigger initiation and / or termination of an electronic lockout of a client device when a charge associated with the client device is initiated and / or processed. In some such embodiments, for example, the device lockout management module 210 may be configured to perform one or more device lockout update actions, including, but not limited to, generating and / or sending one or more requests to a third-party provider to initiate and / or terminate an electronic lockout of the client device by setting an appropriate feature lockout status. Additionally or alternatively, in at least some embodiments, the device lockout management module 210 is configured to retrieve the device feature status of the client device, for example, using communications with the third-party provider, to verify that the status is set appropriately, and / or to perform an action based on the received device feature status.It should be understood that in some embodiments, the device lockout management module 210 may include a separate processor, a specially configured field programmable gate array (FPGA), or a specially configured application specific integrated circuit (ASIC).

[0108] In some embodiments, one or more of the modules 202-210 may share hardware, eliminating duplicate hardware requirements. Additionally or alternatively, in some embodiments, one or more of the modules 202-210 may be combined, such that a single module includes means configured to perform the operations of two or more of the modules 202-210. For example, in at least one embodiment, the device lockout management module 210 and the processor 202 are combined into a module embodied in processing circuitry. Additionally or alternatively, one or more of the modules 202-210 may be embodied by two or more sub-modules, which may be in communication with, operate in conjunction with, or separate from one another.

[0109] The trusted third-party provider 108 and / or the third-party manufacturer system 112 may also be embodied by one or more computing systems, such as device 250 shown in FIG. 2B. As shown in FIG. 2B, device 250 may include a processor 252, a memory 254, an input / output module 256, a communications module 258, and a third-party case lockout management module 260. Device 250 may be configured to perform the operations described below using one or more of modules 252-260.

[0110] It should be understood that similarly named components may be embodied in similar hardware, software, and / or firmware as the components depicted and described with respect to FIG. 2A . In this regard, the components may perform similar functions with respect to device 250. For example, in this regard, processor 252 may provide similar processing functionality for device 250, memory 254 may provide similar memory storage functionality for device 250, input / output module 256 may provide similar input / output, display, and / or interaction functionality for device 250, and / or communication module 258 may provide similar networking, interface, and / or communication functionality for device 250, similar to the functionality described with respect to device 200 of FIG. 2A . Repetitive disclosure is omitted for the sake of brevity.

[0111] In some such embodiments, the third-party case lockout management module 260 is embodied in software, hardware, firmware, and / or a combination thereof. In this regard, the device lockout management module 210 may be embodied in any manner to initiate and / or manage third-party cases associated with user-submitted information, provide one or more interfaces to user devices associated with users, transmit data to a device protection program management system, and / or process data received from the device protection program management system, and initiate and / or terminate electronic lockouts of client devices. In some such embodiments, the third-party case lockout management module 260 may be configured to perform certain actions based on data received from the device protection program management system. For example, the third-party case lockout management module 260 may update locally managed third-party cases based on one or more claim status update notification data objects (e.g., a claim cancellation notification data object, a claim approval notification data object, and / or the like) received from the device protection program management system. Additionally or alternatively, third-party case lockout management module 260 may include means configured to set a feature lockout status of a corresponding client device to an appropriate value based on data received from the device protection program management system, e.g., initiate an electronic lockout, continue an electronic lockout, and / or terminate an electronic lockout of the client device. Further, during the processing of a claim, third-party case lockout management module 260 may be configured to generate, track, and / or otherwise manage one or more timers associated with the initiation and / or processing of a claim, e.g., one or more drop-dead timers utilized to determine whether to unlock a client device when a third-party case and / or corresponding claim is determined to be abandoned.It should be understood that in some embodiments, the third-party case lockout management module 260 may include a separate processor, a specially configured field programmable gate array (FPGA), or a specially configured application-specific integrated circuit (ASIC).

[0112] In some embodiments, one or more of the modules 252-260 may share hardware, eliminating duplicate hardware requirements. Additionally or alternatively, in some embodiments, one or more of the modules 252-260 may be combined, such that a single module includes means configured to perform the operations of two or more of the modules 252-260. For example, in at least one embodiment, the third-party lockout management module 260 and the processor 252 are combined into a module embodied in a processing circuit. Additionally or alternatively, one or more of the modules 252-260 may be embodied by two or more sub-modules, which may be in communication with, operate in conjunction with, or be separate. Exemplary Secure Device Lockout Management Flow 3 illustrates example operations of an example process for secure device lockout management in accordance with at least one example embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied, for example, by apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0113] In block 302, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for receiving a device billing request indication. In some embodiments, the device billing request indication is received from a third-party provider, e.g., an associated carrier system and / or a manufacturer system. In this regard, the third-party provider may enable the user to initiate the process of initiating a new billing through a device protection program with which the user has registered the associated device (e.g., a device protection program for the device registered to the user). Alternatively, or in addition, in some embodiments, the device billing request indication is received directly from a user device associated with the user. In this regard, the user may utilize the user device to communicate directly with the device 200 to initiate the billing process, thus avoiding the use of a third-party provider.

[0114] In some embodiments, a device charge request indication is associated with the client device. For example, in this regard, the device charge request indication may represent a user request to initiate a charge associated with the client device. In some such embodiments, the device charge request indication may include a client device identifier, such as an IMEI or other unique identifier. Additionally or alternatively, in some embodiments, the client device is associated with a feature lockout state. The feature lockout state may represent whether the client device is currently associated with restricted functionality, for example, as controlled by a manufacturer system associated with the client device. In some embodiments, for example, in situations where no charge has previously been initiated for the client device, the client device may be in an unlocked state (e.g., the value of the feature lockout state may represent an unlocked state), such that the functionality of the client device is not restricted.

[0115] At block 304, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for initiating a billing associated with the client device based on the device billing request indication. In some embodiments, the apparatus 200 is configured to determine whether the client device is associated with one or more device protection program(s). In some such embodiments, the apparatus 200 is configured to determine the device protection program(s) based on one or more identifiers previously received, for example, using the device billing request indication. In situations where the apparatus 200 determines that the client device is enrolled in at least one device protection program, or in particular, a requested device protection program identifier using previously received data, the apparatus 200 may be configured to generate and / or store a billing associated with the client device. In some embodiments, to initiate a billing, the apparatus 200 may request that the user provide information in addition to the information received using the device billing request indication, for example, as described herein with respect to the following figures.

[0116] At block 306, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for causing the feature lockout state of the client device to be set to a locked state. In some embodiments, by setting the feature lockout state to a locked state, the device 200 is configured to trigger the initiation of an electronic lockout of the client device, such that features are inaccessible or a limited subset of features remains accessible. By locking out such features, the device 200 can improve data security associated with the client device while at least partially minimizing the possibility that a user may be adversely affected by a claim initiated by the user, resulting in damage to the device and / or proof that the device is no longer in the user's possession. The device 200 may be configured to cause the feature lockout state to be set to a locked state in any of a number of ways, including, for example, using one or more transmissions to a third-party provider. A non-limiting example process for setting a feature lockout state is shown and described below with respect to FIGS. 4A and 4B.

[0117] In block 308, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for processing the claim and determining whether to approve the claim. In some such embodiments, to process the claim, the device 200 is configured to compare received information submitted by a user and associated with the claim with various requirements under the associated device protection program associated with the claim, e.g., as embodied by a predefined rule set. In this regard, the device 200 may require the user to submit additional data to determine whether to approve or deny the claim based on the predefined rule set. Additionally or alternatively, the device 200 may be configured to determine whether the user actively cancels the claim during processing, e.g., as illustrated and described below with respect to FIG. 6A. Additionally or alternatively, the device 200 may be configured to determine whether processing of the claim times out based on one or more timestamp intervals, e.g., as illustrated and described below with respect to FIG. 6B.

[0118] At block 310, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, to cause an update of the client device's feature lockout state based on a determination of whether to approve the charge. In some embodiments, for example, the apparatus 200 keeps the feature lockout state locked if the charge is determined to be approved and / or updates the feature lockout state to an unlocked state in situations where the charge is determined to be denied. Non-limiting examples of such updates are illustrated and described below with respect to FIG. 5. Similarly, in some embodiments, the apparatus 200 can perform one or more actions to update the client device's feature lockout state to a locked state in situations where the charge times out and / or is canceled during processing, for example, as described below with respect to FIGS. 6B and 6A, respectively.

[0119] 4A illustrates additional operations of an exemplary process for secure device lockout management, particularly for setting a feature lockout state of a client device to a locked state, in accordance with at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0120] In some embodiments, one or more of the acts depicted with respect to FIG. 4A occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, FIG. 4A begins after block 304 as depicted and described with respect to FIG. 3. Additionally or alternatively, as depicted, in some embodiments, upon completion of the acts depicted with respect to FIG. 4A, flow returns to block 308 as depicted and described with respect to FIG. 3. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to FIG. 4A and / or upon completion of the acts depicted and described with respect to FIG. 4A.

[0121] At block 402, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for transmitting a device claim request to a manufacturer system associated with the client device. In some embodiments, the device lockout request is configured to cause the manufacturer system to set the function lockout state of the client device to a locked state. In this regard, transmitting the device lockout request to the manufacturer system initiates an electronic lockout of the client device. It should be appreciated that in some embodiments, the device lockout request is transmitted over any of a number of communications networks, for example, over the Internet.

[0122] The manufacturer system may be associated with the hardware, software, and / or firmware of the client device. For example, the manufacturer system may embody a computing system controlled by the creator of some or all of the software, hardware, and / or firmware that embodies the client device. In some such embodiments, the manufacturer system may be configured to communicate with the client device over the same communications network, e.g., the Internet, and / or a second communications network, to set the feature lockout state of the client device. For example, in at least one exemplary embodiment, a device lockout request causes the manufacturer system to generate and / or send to the client device a request to set the feature lockout state of the client device to a locked state. In this regard, in at least some embodiments, the request sent from the manufacturer system to the client device includes data indicating that the feature lockout state is specially configured or otherwise set to a locked state based on the feature lockout state, i.e., the desired value of the lockout state.

[0123] 4B illustrates additional operations for an exemplary process for secure device lockout management, particularly for setting a feature lockout state of a client device to a locked state, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0124] In some embodiments, one or more of the operations depicted with respect to FIG. 4B occur in addition to and / or instead of one or more operations of another process. For example, as depicted, in some embodiments, FIG. 4B begins after block 304 as depicted and described with respect to FIG. 3. Additionally or alternatively, as depicted, in some embodiments, upon completion of the operations depicted with respect to FIG. 4B, flow returns to block 308 as depicted and described with respect to FIG. 3. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the operations depicted and described with respect to FIG. 4B and / or upon completion of the operations depicted and described with respect to FIG. 4B.

[0125] At block 452, the device 200 includes means, such as the device lockout management module 210, the communication module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for sending a device lockout request to a third party system associated with the client device, the third party system including a carrier system. In some embodiments, the carrier system is in communication with a manufacturer system associated with the client device, where the manufacturer system can communicate with the client device to set the feature lockout state to a desired value, e.g., a locked out state. In some embodiments, the device 200 and the carrier system communicate over one or more communication network(s), such as the Internet. Additionally or alternatively, the carrier system and the manufacturer system, and / or the manufacturer system and the client device, may be configured to communicate over one or more communication networks, e.g., the Internet, and / or one or more other communication networks.

[0126] In some embodiments, the carrier system is configured to, in response to receiving the device lockout request, cause the manufacturer system to set the feature lockout state of the client device to a locked state. For example, in at least some embodiments, the device lockout request is configured to cause the carrier system to send one or more corresponding requests to the manufacturer system. In some embodiments, the carrier system is configured to generate and / or send one or more specially configured requests to the manufacturer system that correspond to the device lockout request. In this regard, sending the device lockout request to the carrier system initiates an electronic lockout of the client device indirectly through the manufacturer system. The electronic lockout is indirectly controlled by the apparatus 200 through communication with one or more third-party systems.

[0127] 5 illustrates additional operations of an exemplary process for secure device lockout management, in accordance with at least one exemplary embodiment of the present disclosure, particularly for processing a claim to determine whether to approve the claim and, based on a determination of whether to approve the claim, triggering an update of the client device's feature lockout state. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0128] In some embodiments, one or more of the acts depicted with respect to Figure 5 occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, Figure 5 begins after block 306 as depicted and described with respect to Figure 3. Additionally or alternatively, as depicted, in some embodiments, upon completion of an act depicted with respect to Figure 5, flow returns to another act of the associated process. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to Figure 5 and / or upon completion of an act depicted and described with respect to Figure 5.

[0129] At block 502, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for receiving user billing information associated with a claim within a first timestamp interval. The user billing information may embody one or more data values ​​for use in processing the claim, such as evidential data and / or descriptive data associated with the claim. For example, some or all of the user billing information may include data describing the events leading to the claim (e.g., a description of how the device was damaged, lost, stolen, etc.), data associated with subsequent actions taken by the user in response to the events (e.g., whether one or more device location applications were launched), and / or the like. In some embodiments, for example, the first timestamp interval embodies a threshold claim initiation period within which user billing information is received to enable processing of the claim. In some embodiments, the device 200 stores and / or otherwise predetermines the first timestamp interval. Alternatively, or in addition, in some embodiments, device 200 determines the first timestamp interval based on previously received data associated with the claim to be processed, including, but not limited to, received data and / or data otherwise accessible to device 200, such as, for example, a claim type of the claim, a device protection program associated with the claim, user settings associated with the user account of the claim, and / or the like.

[0130] At decision block 504, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for determining whether to approve the claim. In some embodiments, the determination of whether to approve the claim is based on at least the received user claim information and / or previously received data, such as case confirmation information, third-party case data, and / or the like, from a third-party system and / or the user device. Additionally or alternatively, the determination may be based on at least a device protection program associated with the claim, the device protection program being represented by a predefined rule set. For example, in this regard, the predefined rule set may define required data values ​​to be present in the received data in order to approve the claim. Thus, in some embodiments, the device 200 is configured to compare some or all of the user claim information and / or previously received data with the predefined rule set to determine whether the predefined rule set is satisfied (e.g., the data includes values ​​that satisfy each rule of the predefined rule set). In some embodiments, a claim is determined to be authorized if one or more of the rules in the predefined rule set are satisfied. In some other embodiments, the device 200 determines that a claim is authorized if it determines that all of the rules in the predefined rule set are satisfied.

[0131] In some embodiments, in situations where the device 200 determines that the claim is not approved, flow proceeds to optional block 506. In optional block 506, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for setting the claim status of the claim to a denied status. In this regard, the denied status indicates that the received information associated with the claim does not meet the requirements of the associated device protection program. For example, in some embodiments, the denied status indicates that at least one rule of a predefined rule set has not been met, or in other embodiments, that all rules of a predefined rule set have not been met. Thus, the claim will not be fulfilled. In this regard, the user may not receive a new device, a replacement device, a repair, a discounted device, etc. In some embodiments, the claim status of the claim is set to a denied status, for example, in situations where the device 200 determines that the claim should not be approved based on processing of previously received data and / or comparison of the data to a predefined rule set, e.g., where such processing and / or comparison(s) indicate fraudulent and / or other behavior not subject to the device protection program.

[0132] At block 508, device 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for causing the feature lockout state of the client device to be set to an unlocked state. In some embodiments, by setting the feature lockout state to an unlocked state, device 200 is configured to cause an end of the electronic lockout of the client device such that the client device returns to a fully accessible state. By allowing access to the full feature set, device 200 prevents access to the client device for a limited time while a claim is processed, and once the client device is confirmed to remain out of legitimate possession (e.g., confirmed lost or returned for repair and / or replacement under a device protection program), the client device returns to full functionality for use by the user in situations where it is found and / or in possession, thereby minimizing the possibility of a user being locked out of functionality in situations where the user desires access to such functionality.

[0133] Device 200 may be configured to cause the feature lockout state to be set to an unlocked state in any of a number of ways, including, for example, via one or more transmissions to a third-party provider. For example, in some embodiments, device 200 is configured to generate and / or transmit a device unlock request to a manufacturer system associated with the client device. In this regard, in some embodiments, the device unlock request is configured to cause the manufacturer system to set the client's feature lockout state to an unlocked state. Alternatively, or in addition, in some embodiments, device 200 is configured to communicate with a manufacturer system associated with the client device to generate and / or transmit the device unlock request to a carrier system or other third-party provider. In this regard, in some embodiments, the device unlock request is configured to cause the carrier system or other third-party provider to transmit one or more other requests to the manufacturer system, where the requests cause the manufacturer system to set the client's feature lockout state to an unlocked state.

[0134] In some embodiments, the device unlock request is embodied in and / or otherwise transmitted along with a claim rejection notification data object. The claim rejection notification data object can indicate to a third-party provider, such as a carrier system or manufacturer system, that the claim has been fully processed. In this regard, the client device's feature lockout state can be set permanently with respect to the submitted claim and thus remain in an unlocked state until a new claim is initiated for the client device (if one is initiated). Accordingly, the third-party provider can cancel timers or other pending actions with respect to the processing of the claim and / or abort internally stored cases associated with the client device's claim that was rejected by apparatus 200.

[0135] Returning to decision block 504, in some embodiments, in situations where device 200 determines that the claim is approved, flow proceeds to optional block 510. In optional block 510, device 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for setting the claim status of the claim to an approved status. In this regard, the approved status indicates that the received information associated with the claim meets the requirements of the associated device protection program. For example, in some embodiments, the approved status indicates that at least one rule of a predefined rule set has been satisfied, or in other embodiments, that all rules of a predefined rule set have been satisfied. Thus, the claim proceeds to be fulfilled. In this regard, device 200 can perform one or more additional actions to enable the user to receive a new device, a replacement device, a repair, a discounted device, etc. In some embodiments, for example, in situations where device 200 determines that a claim should be approved based on processing of previously received data and / or comparison of the data to a predefined rule set, the claim status of the claim is set to an approved status, e.g., where such processing and / or comparison(s) indicates behavior that is subject to the device protection program.

[0136] At block 508, device 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for causing the function lockout state of the client device to remain set to a locked state. In some embodiments, by setting the function lockout state to a locked state, device 200 is configured to maintain an electronic lockout of the client device such that the client device remains configured to be accessible only to a limited set of functions. By maintaining the electronic lockout, device 200 prevents access to the client device in situations where the device is determined to be no longer in the possession of the legitimate user and / or is removed from the possession of the legitimate user, for example, for purposes of replacing and / or repairing the client device (e.g., when the client device is confirmed lost or stolen and / or is returned for repair and / or replacement under a device protection program). In this regard, device 200 is configured to render the client device inaccessible in situations where the received data sufficiently indicates that the client device is not in the possession of the legitimate user.

[0137] The device 200 may be configured to cause the feature lockout state to remain set to the locked state in any of a number of ways. In some embodiments, the device 200 does not perform any action that causes the client device to remain in the locked state. Alternatively, or additionally, in some embodiments, the device 200 is configured to send one or more transmissions to the third-party provider to cause the feature lockout state of the client device to remain set to the locked state. In this regard, in some embodiments, the device 200 generates and / or sends a claim approval notification data object to the third-party provider to cause the feature lockout state of the client device to remain set to the locked state. The claim approval notification data object may indicate to the third-party provider that the claim has been successfully processed and approved, and that the client device should be updated to the locked state if it has not already been set to the locked state. In this regard, the third-party provider may generate and / or send one or more transmissions to the client device to set the feature lockout state to the locked state if the third-party provider determines that the client device was not previously successfully set to the locked state. Additionally, or alternatively, in some embodiments, the third-party provider does not perform any action in circumstances where it determines that the client device was previously set to the locked state. Additionally or alternatively, in some embodiments, device 200 may send data, such as, for example, a claim approval notification data object, to the third-party provider to update the internal case managed by the third-party provider to an approved status and / or otherwise terminate the internal case associated with the client device as approved by device 200.

[0138] 6A illustrates additional operations of an exemplary process for secure device lockout management, in accordance with at least one exemplary embodiment of the present disclosure, particularly for processing a claim to determine whether to approve the claim and, based on the determination of whether to approve the claim, triggering an update of the client device's feature lockout state. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0139] In some embodiments, one or more of the acts depicted with respect to FIG. 6A occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, FIG. 6A begins after block 306 as depicted and described with respect to FIG. 3. Additionally or alternatively, as depicted, in some embodiments, upon completion of an act depicted with respect to FIG. 6A, flow returns to another act of the associated process. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to FIG. 6A and / or upon completion of an act depicted and described with respect to FIG. 6A.

[0140] At block 602, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for receiving a user-initiated claim termination request. In some embodiments, the claim termination request indicates a user's desire to abort and / or otherwise cancel an initiated claim that is currently pending or being processed. In this regard, in some embodiments, the claim termination request includes at least a claim identifier and / or other data identifying the particular device protection program, client device, and / or the like to be canceled. In at least some example contexts, the claim termination request is initiated in situations such as a user changing their mind about submitting a claim or locating a lost device. It should be understood that a user may decide to terminate a claim for any of a number of reasons.

[0141] In some embodiments, apparatus 200 is configured to receive claims termination requests directly using a user device. For example, in some embodiments, a user may communicate with apparatus 200 using a user device to access one or more user interfaces for submitting claims termination requests. For example, the user may access one or more web pages and / or other native application functionality, whereby apparatus 200 provides data associated with such interfaces, e.g., in response to user interaction with the rendered interface(s), for submitting the user-initiated claims termination request.

[0142] In optional block 604, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for setting the billing status of the bill to a canceled status. In this regard, the canceled status indicates that the billing has not been fully processed but has been terminated by the user through user interaction. In at least one exemplary context, the canceled status indicates that the user has decided to keep the damaged device rather than finding the lost device and / or replacing and / or repairing the device through a device protection program. In this regard, in some embodiments, the canceled status may indicate that the client device should return to a state where all functionality is accessible, for example, because the user may want to own the client device and utilize such functionality.

[0143] At block 606, device 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for causing the feature lockout state of the client device to be set to an unlocked state. In some embodiments, by setting the feature lockout state to an unlocked state, device 200 is configured to cause an termination of an electronic lockout of the client device such that the client device returns to a fully accessible state. By allowing access to the full feature set of the client device, device 200 prevents access to the client device for a limited time while a bill is being processed, and upon a user indication that the bill is not proceeding (e.g., via receipt of a user-initiated billing termination request), the client device returns to a fully accessible state such that the user can continue to utilize the client device with reduced interruptions. Similarly, by setting the feature lockout state to an unlocked state in response to a user-initiated request, device 200 is configured to lock out some or all functionality of the client device, at least during the time the user indicates that the client device may be inaccessible to legitimate users, thereby protecting against access from unauthorized and / or malicious users.

[0144] Device 200 may be configured to cause the feature lockout state to be set to an unlocked state in any of a number of ways, such as through one or more transmissions to a third-party provider. For example, in some embodiments, device 200 is configured to generate and / or transmit a device unlock request to a manufacturer system associated with the client device. In this regard, in some embodiments, the device unlock request is configured to cause the manufacturer system to set the client's feature lockout state to an unlocked state. Alternatively, or in addition, in some embodiments, device 200 is configured to communicate with a manufacturer system associated with the client device to generate and / or transmit the device unlock request to a carrier system or other third-party provider. In this regard, in some embodiments, the device unlock request is configured to cause the carrier system or other third-party provider to transmit one or more other requests to the manufacturer system, where the requests cause the manufacturer system to set the client's feature lockout state to an unlocked state.

[0145] In some embodiments, the device unlock request is embodied in and / or otherwise transmitted along with a billing cancellation notification data object. The billing cancellation notification data object can indicate to a third-party provider, such as a carrier system or manufacturer system, that the bill has been fully processed. In this regard, the client device's feature lockout state can be set permanently with respect to the submitted bill and thus remain in an unlocked state until a new bill is initiated for the client device (if one is initiated). Accordingly, the third-party provider can cancel timers or other pending actions with respect to the processing of the bill and / or abort internally stored cases associated with the client device's bill that was canceled by the user in response to a transmission from apparatus 200.

[0146] 6B illustrates additional operations of an exemplary process for secure device lockout management, in accordance with at least one exemplary embodiment of the present disclosure, particularly for processing a claim to determine whether to approve the claim and, based on a determination of whether to approve the claim, triggering an update of the client device's feature lockout state. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0147] In some embodiments, one or more of the operations depicted with respect to FIG. 6A occur in addition to and / or instead of one or more operations of another process. For example, as depicted, in some embodiments, FIG. 6B begins after block 306 as depicted and described with respect to FIG. 3. Additionally or alternatively, as depicted, in some embodiments, upon completion of an operation depicted with respect to FIG. 6B, flow returns to another operation of the associated process. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the operations depicted and described with respect to FIG. 6B and / or upon completion of an operation depicted and described with respect to FIG. 6B.

[0148] At block 652, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for determining that user billing information associated with a claim was not received within a first timestamp interval. In some embodiments, the first timestamp interval embodies a threshold case information period during which user billing information is received to allow processing of the claim. In some embodiments, the apparatus 200 stores and / or otherwise predetermines the first timestamp interval based, for example, on the timestamp at which the claim was initiated. In one exemplary context, the first timestamp interval represents a five-day timestamp interval, such that user billing information for the claim must be received within five days of the claim being initiated. Alternatively or additionally, in some embodiments, device 200 determines the first timestamp interval based on received data and / or data otherwise accessible to device 200, such as previously received data associated with the claim to be processed, including, but not limited to, the claim type of the claim, a device protection program associated with the claim, user settings associated with the user account of the claim, and / or the like. In some embodiments, device 200 may be configured to schedule a task to perform such a determination after the first timestamp interval has elapsed, for example, at the start of the claim. Alternatively or additionally, in some embodiments, device 200 may be configured to perform one or more checks at various timestamp intervals (e.g., every X seconds, minutes, hours, days, weeks, and / or the like) to determine whether user billing information has been received if the current timestamp exceeds the first timestamp interval.

[0149] In optional block 654, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for setting the claim status of the claim to a timeout status. In this regard, the timeout status indicates that the claim has not been fully processed, but rather has been aborted due to a lack of user action regarding the claim. In at least one exemplary context, the timeout status indicates that the user has abandoned, whether intentionally or not, continuing to pursue the claim. In this regard, in some embodiments, the timeout status may indicate that the client device should return to a state in which full functionality is accessible, e.g., if the user reacquires or otherwise decides to keep the client device and desires to utilize such functionality, the user will be able to access such functionality.

[0150] At block 656, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for causing the feature lockout state of the client device to be set to an unlocked state. In some embodiments, by setting the feature lockout state to an unlocked state, the device 200 is configured to cause an end of the electronic lockout of the client device such that the client device returns to a fully accessible state. By allowing access to the full feature set of the client device, the device 200 prevents access to the client device for a limited time during which the user may be working to provide data to the device 200 for processing; after a timestamp interval (e.g., predetermined or determined as a first timestamp interval), the device 200 determines that the user has likely abandoned the request and returns the client device to a fully accessible state so that the user can continue to utilize the client device with reduced interruption if the user reacquires or otherwise decides to remain in possession of the client device and forgets about or otherwise ignores the initiated request. Similarly, by setting the feature lockout state to an unlocked state after the first timestamp interval, device 200 is configured to lock out some or all functionality of the client device for at least a period of time sufficient for the user to submit the required data to device 200 for processing, so that the client device is not unlocked prematurely, such as during a reasonable time frame for data submission, when the client device may be exposed to use by an unauthorized owner and / or malicious user.

[0151] Device 200 may be configured to cause the feature lockout state to be set to an unlocked state in any of a number of ways, such as through one or more transmissions to a third-party provider. For example, in some embodiments, device 200 is configured to generate and / or transmit a device unlock request to a manufacturer system associated with the client device. In this regard, in some embodiments, the device unlock request is configured to cause the manufacturer system to set the client's feature lockout state to an unlocked state. Alternatively, or in addition, in some embodiments, device 200 is configured to communicate with a manufacturer system associated with the client device to generate and / or transmit the device unlock request to a carrier system or other third-party provider. In this regard, in some embodiments, the device unlock request is configured to cause the carrier system or other third-party provider to transmit one or more other requests to the manufacturer system, where the requests cause the manufacturer system to set the client's feature lockout state to an unlocked state.

[0152] In some embodiments, the device unlock request is embodied in and / or otherwise transmitted with a billing timeout notification data object. The billing timeout notification data object can indicate to a third-party provider, e.g., a carrier system or manufacturer system, that the billing was not fully processed or was canceled but was aborted because it was determined to have been abandoned by the initiating user. In this regard, the client device's feature lockout state can be set permanently with respect to the submitted billing and thus remain in an unlocked state until a new billing is initiated for the client device (if initiated). Thus, the third-party provider can terminate timers or other pending actions with respect to processing of the billing and / or abort internally stored cases associated with the client device's bills that were last timed out by the user based on transmission from the device 200. Exemplary Detailed Secure Device Lockout Management Flow 7, 8, 9, and 10 illustrate example operations of an example detailed process for secure device lockout management, particularly based on information from a trusted third-party provider, in accordance with at least one embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0153] At block 702, device 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for receiving case confirmation from a trusted third party provider. In some embodiments, the trusted third party provider is embodied by a carrier system that communicates with device 200. In yet other embodiments, the trusted third party provider is embodied by a manufacturer system that communicates with device 200. It should be understood that, as described herein, device 200 can receive information from the trusted third party provider over one or more communications networks, for example, over the Internet.

[0154] In some embodiments, the case verification information includes at least a third-party case identifier associated with the client device. In some embodiments, the third-party case identifier uniquely identifies corresponding third-party case information stored by a trusted third party. In some embodiments, the device 200 may additionally or alternatively receive an authentication token indicating that the trusted third-party provider has successfully authenticated a user associated with the third-party case identifier. In some embodiments, the trusted third-party provider is configured to authenticate the user utilizing one or more authentication processes. In a particular exemplary context, the trusted third-party provider requires that the user provide one or more user authentication credentials and then verify their identity using two-factor or multi-factor authentication (e.g., an email message, SMS, or text message to an associated user device, etc.). The authentication token may be signed by the third-party provider such that embodiments of the present disclosure can validate the authentication token using, for example, public key cryptography, and verify that the authentication token originated from the trusted third-party provider. To enhance security, some embodiments perform additional security checks. For example, in some embodiments, an embodiment system associates a trusted third-party provider with one or more IP addresses, and the embodiment system is configured to verify that received third-party case information originates from the trusted third-party provider.

[0155] In optional block 704, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for retrieving some or all of the third-party case information from a trusted third-party provider and / or from one or more local or networked storage locations utilizing a third-party case identifier. For example, some embodiment systems utilize an application programming interface (API) to request some or all of the third-party case information associated with a particular third-party case identifier from a trusted third-party provider. The third-party case information, in some embodiments, includes one or more from a group including a device identifier (e.g., an International Manufacturer Equipment Identity (IMEI), an Internet Protocol (IP) address, an alphanumeric identifier, etc.), previous case information (e.g., the number of third-party cases opened associated with a particular client device and / or user), device location resource information (e.g., whether access to a device location application is enabled associated with the client device, whether the user attempted to access a device location application to locate the client device, the last time the user accessed a device location resource to locate the device, etc.). Additionally or alternatively, in some embodiments, the third-party case information includes location information, status information for each application associated with the client device, stored data information, etc., associated with the client device associated with the case at the time the user initiated the third-party case, thereby serving as a snapshot of all information present on the client device at the time the user initiated the third-party case.Some embodiments are further configured to store the third-party case identifier and / or otherwise store the billing information associated with the third-party case identifier such that the billing information is retrievable using the third-party case identifier. Additionally or alternatively, some embodiments store all, some, or all of the third-party case information such that the third-party case information is retrievable using the third-party case identifier.

[0156] In some embodiments, retrieving the third-party case information is based on a previously received third-party case identifier. In this regard, minimal information (e.g., a third-party case identifier and / or an authentication token) may be passed from the trusted third-party provider to the device 200 in a first communication between the device 200 and the trusted third-party provider, for example, during a connection established using redirection of a user device from the trusted third-party provider to the device 200 and rendering a user interface associated with accessing device 200's functionality on the user device. Sending minimal information improves communication time between the trusted third-party provider and the device 200 and minimizes the receipt and initiation of processing of the third-party case identifier(s). Additionally or alternatively, minimizing the amount of information transmitted initially can provide a baseline level of security by protecting the information in an encrypted manner, minimizing the risk of significant vulnerabilities due to exposing sensitive data with basic security measures. The device 200 can then retrieve the third-party case information using a security-enhanced process, for example, using one or more APIs provided by the trusted third-party provider. In some such embodiments, where the device is configured to retrieve third-party case information from a trusted third-party provider after receiving the initial case confirmation information, the overall data security of the process is improved by reducing the likelihood of successful subversion by a malicious user. In yet some other embodiments, the third-party case information is received along with the case confirmation information in a previous step, e.g., at block 702.

[0157] In optional block 706, apparatus 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for identifying a client device identifier associated with the third-party case information. In this regard, the client device identifier may uniquely identify the client device from which the user initiated the claim initiation process. Some embodiments are configured to extract the client device identifier from the third-party case information. Alternatively, or in addition, in some embodiments, the client device identifier is identified in a previous step, e.g., from the case confirmation information received in block 702. In some such embodiments, apparatus 200 is configured to extract and / or otherwise parse the client device identifier from the case confirmation information.

[0158] In optional block 708, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for sending a case receipt response to the trusted third-party provider. In some embodiments, the case receipt response is configured to cause the trusted third-party provider to initiate a client device lockout or otherwise maintain a client device lockout that may have been initiated by the trusted third party when the user acknowledged that the device was lost or stolen and that the user wishes to settle the claim prior to transmission of the case confirmation information, thereby rendering the client device inoperable or otherwise inaccessible until a future status change (e.g., a claim status update notification data object) indicating that access to the device should be restored is sent by an embodiment device protection program management system to the trusted third-party provider. For example, the trusted third-party provider can lock out the client device by configuring the client device to display a user interface that is unavailable for user engagement or unavailable for response indefinitely.

[0159] In block 710, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for determining whether user case information is received within a threshold claim initiation period. In some embodiments, the case receipt response is also configured to present to the user, e.g., with a user device, an interface configured and / or provided by the device 200 to initiate the claim initiation process by submitting user case information. For example, the user may be provided, redirected, or otherwise accessed to a user case information collection interface configured to allow the user to input and / or submit user claim information. The user claim information, in some embodiments, includes at least one or more from a group including an incident date (e.g., when the client device was lost or stolen), an incident description, user incident response information, user information, payment information, and / or the like.

[0160] In some embodiments, a third-party case associated with a given third-party case identifier may only remain accessible for submission using device 200 for a determined or predetermined threshold claim initiation period if no claim associated with the third-party case is submitted. For example, in certain system embodiments, device 200 may provide functionality that allows a user to access submitted user case information associated with received third-party case information for a limited time, pending the user's initial submission of user case information, to open the third-party case. In at least one exemplary embodiment, the threshold claim initiation period represents one day (24 hours). In situations where device 200 determines that a user has not submitted user case information within the threshold claim initiation period, device 200 may transmit information to the trusted third-party provider to close the case. In this regard, device 200 may determine, based on a lack of action by the user, that the user is no longer pursuing the fulfillment of a claim associated with the client device using device 200. In some embodiments, device 200 may also be configured to delete or otherwise make inaccessible information associated with the terminated third-party case, such as the third-party case identifier and / or the third-party case information associated with the third-party case identifier. Thus, if user case information is not received within a threshold claim initiation period, the trusted third party can terminate a lockout associated with the client device such that the client device returns to a functional form. Alternatively, or additionally, in some embodiments, device 200 can terminate a lockout associated with the client device to the trusted third-party provider, for example, through one or more transmissions described herein. For example, in at least one embodiment, device 200 is configured to send a device unlock request and / or a claim timeout notification data object, and / or similar data object, to the trusted third-party provider to cause a lockout of the client device.In some embodiments, upon closing the browser or otherwise terminating a session with device 200, device 200 may determine that user case information has not been received within a threshold claim initiation period and therefore may send information to cause the case to be dropped and / or the client device to be unlocked without submitting a claim. In some embodiments, the trusted third party provider may maintain its own timer, e.g., a drop dead timer, to wait for confirmation from the device protection program management system that a claim has been generated. In some such embodiments, if the drop dead timer expires before device 200 provides an indication that the claim has been successfully initiated, the trusted third party provider automatically causes the termination of the client device lockout.

[0161] Alternatively, in some example contexts, apparatus 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for receiving user case information submitted by a user, as described, for example, at block 712. In some embodiments, for example, the apparatus receives user case information from a user device using user interaction by the user with a user case information collection interface for inputting such user case information. For example, in some embodiments, the user case information may include a device protection policy identifier and / or other associated information, client device information, a claim type to use for the generated claim, and / or the like. In some such cases, the user case information may include all remaining information necessary to generate a claim using apparatus 200 and / or additional information useful for generating and / or initiating initial processing of the claim.

[0162] At block 714, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for identifying a device protection program associated with at least the client device identifier. Additionally or alternatively, in some embodiments, the apparatus 200 may be configured to identify the device protection program based on received user case information submitted by a user. For example, in some embodiments, the user case information submitted by the user may include a device protection program identifier selected by the user for use in generating the claim. Additionally or alternatively, in some embodiments, information previously received from a trusted third-party provider may be used to identify the device protection program. For example, the case confirmation information and / or the third-party case information may include a device protection program identifier associated with the claim to be generated. The identified device protection program may be embodied by a predefined rule set that defines the targets provided by the device protection program. In this regard, the device protection program may define various parameters that the received information associated with the claim must meet in order for the apparatus 200 to approve the claim.

[0163] At block 716, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for generating a claim based at least in part on the received case confirmation information and / or the received user case information. For example, a client device may be subscribed to or otherwise registered with a device protection program associated with particular claim parameters and / or requirements embodied by a predefined rule set. In some such embodiments, a client device may subscribe to multiple device protection programs, each of which may cover any number of claim types. In this regard, the user case information and / or information received from the trusted third-party provider may include a device protection program identifier, a claim type, and / or the like. In some embodiments, based on the various information provided, a claim may be generated in association with the identified device protection program, whereby the claim includes parameters whose values ​​are provided by the user. In some embodiments, for a claim associated with a particular device protection program, if the claim parameters meet the requirements of the device protection program, as described herein, the claim may be approved. In some embodiments, if the values ​​provided for the claim parameters are incomplete or insufficient, the device 200 may otherwise reject the claim or request more information.

[0164] At block 718, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for generating and / or transmitting a claim creation notification data object case to the trusted third-party provider. In some embodiments, the claim creation notification data object is configured to indicate that a user has successfully initiated a claim associated with the third-party case. In some such embodiments, the claim creation notification data object may cause the trusted third-party provider to terminate one or more timers for claim initiation, e.g., one or more drop-dead timer(s) associated with the termination of the client device lockout. In this regard, if the trusted third-party provider does not receive information from the device 200 and / or if the notification data object indicates that the device 200 has not received user case information within a threshold claim initiation period (e.g., within 24 hours after the trusted third party sends case confirmation information to the device protection program management system), the trusted third-party provider may be configured to automatically terminate the client device lockout associated with the third-party case after the drop-dead timer has expired, such that the client device is returned to functional form. Additionally or alternatively, in some embodiments, the claim creation notification data object is configured to cause a trusted third party provider to update the status of a case stored by the trusted third party provider, e.g., to provide the status of the claim to a user using the trusted third party provider.

[0165] The claim creation notification data object may be configured to cause the trusted third party to change a case status associated with a third-party case, stored and / or otherwise managed by the trusted third-party provider, from a case received status, such as "Case Received," to a claim created status, such as "Claim Created." The trusted third party provider may, as illustrated, change the case status to Case Created along with transmission of case confirmation information and / or third-party case information to device 200. Alternatively, or in addition, in some embodiments, the trusted third-party provider is configured to set the case status of a third-party case to a Case Received status when it receives a case receipt response from the device 200 confirming that the third-party provider has sent case confirmation information to the device 200. Thus, if the device 200 determines that a claim has not been submitted (e.g., if a time period has expired or if the system determines that it is not interested in the claim) and / or unless the case status is updated within a threshold claim initiation period, the lockout of client devices associated with the third-party case may end or otherwise terminate. According to at least some example embodiments of the present disclosure, the device 200 can have the trusted third-party provider set the case status to a Claim Created status, indicating that the device 200 has associated with and / or otherwise generated a claim based on the third-party case. In this regard, device lockout of client devices associated with the third-party case is initiated and / or maintained during claim processing and fulfillment.

[0166] In some embodiments, the claim and / or the identified device protection program are associated with claim requirement data that embodies parameters representing information required by the user. For example, a particular claim may be associated with claim requirement data that indicates that the user must submit one or more claim disclaimers, claim forms, etc. associated with the claim. Additionally or alternatively, in some embodiments, the claim requirement data may indicate that the user must provide supplemental claim information to device 200 to enable the claim to be fully processed.

[0167] In some embodiments, device 200 is configured with a claim completion period associated with receiving claim requirement data from a user after claim generation. For example, in some embodiments, if a user does not submit all claim requirement data to device 200 within a determined or predetermined threshold claim completion period (e.g., 30 days), device 200 is configured to terminate the claim due to insufficient action by the user. Accordingly, in some embodiments, device 200 sends a notification data object, such as a claim timeout notification data object, to the trusted third party provider. In some embodiments, the claim timeout notification data object is configured to cause the trusted third party provider to set a case status associated with the third-party case to a case closed status or case timeout status, such as "Case Closed For Lack of Activity." In response to receiving the claim timeout notification data object and / or in response to the case status being updated to a case closed / timeout status, the trusted third party provider may then terminate the lockout of the client device associated with the case such that the client device returns to a functional state.

[0168] In some embodiments, a user may cancel and / or affirmatively release a claim and / or third-party case during processing. In this regard, a claim may be canceled before the claim is fully processed by apparatus 100. For example, in some embodiments, apparatus 200 is configured to enable such affirmative cancellation of one or more claims as described herein, e.g., as described and / or depicted with respect to FIG. 8 below.

[0169] At block 720, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for receiving billing requirement data from a user within a threshold billing completion period. In this regard, the apparatus 200 is configured to determine whether the billing requirement data, if received, is received within the threshold billing completion period. In at least one exemplary embodiment, in a situation where the billing requirement data is received from a user within the threshold billing completion period, flow proceeds to block B, e.g., as depicted and described with respect to FIG. 9. Alternatively, or additionally, in at least one exemplary embodiment, in a situation where the billing requirement data is not received from a user within the threshold billing completion period, flow proceeds to block A, e.g., as depicted and described with respect to FIG. 8.

[0170] 8 illustrates additional operations of an exemplary detailed process for secure device lockout management, particularly for processing claims as timeouts based on lack of user action, in accordance with at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0171] In some embodiments, one or more of the acts depicted with respect to Figure 8 occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, Figure 8 begins at block A as depicted and described with respect to Figure 7. Additionally or alternatively, as depicted, in some embodiments, upon completion of the acts depicted with respect to Figure 8, the flow returns to Figure 7 or the flow ends as depicted and described. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to Figure 8 and / or upon completion of the acts depicted and described with respect to Figure 8.

[0172] In optional block 802, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for terminating a claim due to insufficient action. In some embodiments, to terminate a claim due to insufficient action, the apparatus 200 is configured to set the claim status of the claim to a claim timeout status. In this regard, the claim timeout status represents the final status of the claim, such that the claim has been successfully processed based on an action (or more specifically, an insufficient action) by the user.

[0173] At block 804, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for sending a claim timeout notification data object case to a trusted third-party provider. In some embodiments, the claim timeout notification data object is configured to cause the trusted third-party provider to terminate a lockout from the client device. For example, as described herein, the claim timeout notification data object can be configured to cause the trusted third-party provider to communicate directly with the client device, such as when the trusted third-party device embodies a manufacturer system. Additionally or alternatively, in some embodiments, the claim timeout notification data object can be configured to cause the trusted third-party provider to communicate with a manufacturer system configured to set a feature lockout state for the client device using one or more communications. Additionally or alternatively, in some embodiments, the apparatus 200 is configured to send the claim timeout notification data object to cause the trusted third-party provider to set one or more case statuses of third-party cases associated with the claim to a timeout status.

[0174] 9 illustrates additional operations of an exemplary detailed process for secure device lockout management, particularly for processing received billing requirements data and setting an appropriate lockout state, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied by, for example, apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0175] In some embodiments, one or more of the acts depicted with respect to Figure 9 occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, Figure 9 begins at block B as depicted and described with respect to Figure 7. Additionally or alternatively, as depicted, in some embodiments, upon completion of the acts depicted with respect to Figure 9, the flow returns to Figure 7 or the flow ends as depicted and described. It should be understood that in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to Figure 9 and / or upon completion of the acts depicted and described with respect to Figure 9.

[0176] In block 902, apparatus 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for determining whether a claim is acceptable, or in other words, approved. In some embodiments, apparatus 200 is configured to determine whether a claim is acceptable based on one or more from a group including user case information, third-party case information, claim parameters, claim requirement data, and / or the like. For example, in at least one exemplary embodiment, apparatus 200 is configured to compare the claim requirement data with a predefined rule set embodying a device protection program to determine whether the claim requirement data satisfies the predefined rule set. In some such situations, apparatus 200 is configured to determine that the claim is acceptable in situations where the claim requirement data satisfies the predefined rule set embodying the device protection program, and to determine that the claim is not acceptable otherwise.

[0177] In some embodiments, in situations where the device determines that the claim is acceptable, flow proceeds to optional block 908. In optional block 908, device 200 includes means for approving the claim, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof. Additionally or alternatively, in at least some exemplary embodiments, device 200 is configured to perform one or more actions to satisfy the claim. For example, device 200 can set a claim status associated with the claim to indicate that the claim has been approved, such as by setting the claim status to an approved status value. Additionally or alternatively, device 200 can initiate one or more actions associated with sending a replacement device to the user, e.g., using a system and / or warehouse associated with device 200, or using a trusted third-party provider and / or associated system. Additionally or alternatively, to fulfill a claim, the apparatus 200 may, for example, provide information to the user using a user device associated with the user to enable the user to initiate a replacement, repair, and / or the like process for the client device that submitted the claim.

[0178] At block 910, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for transmitting a claim approval notification data object case to a trusted third-party provider. In some embodiments, the claim approval notification data object is configured to cause the trusted third-party provider to set a case status associated with the third-party case to a claim determination status, such as “Claim Authorized,” indicating that the claim associated with the third-party case has been approved. In response to receiving the claim approval notification and / or a case status update to the third-party case indicating that the claim has been approved, the trusted third-party provider can continue the lockout of the client device associated with the case, thereby maintaining the client device in a permanently inoperable, non-functional, or otherwise inaccessible state. In some embodiments, no action is required to continue the lockout of the client device. In other embodiments, one or more requests are sent to the client device, for example, directly or indirectly through a manufacturer system, to keep the client device in a permanently locked-out state.

[0179] Returning to block 902, in situations where the claim is not determined to be acceptable, flow continues to optional block 904. In some embodiments, a claim may be determined to be unacceptable in situations where the processed data is insufficient, fraudulent, or otherwise determined to be unacceptable. For example, apparatus 200 may be configured to determine that a claim is unacceptable because the submitted claim requirement data does not meet the claim requirements expressed by a predefined rule set of the device protection program.

[0180] In optional block 904, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for denying a claim. For example, the device 200 may set a claim status associated with the claim to indicate that the claim has been denied, such as by setting the value of the claim status to a claim denied status. In this regard, a claim denied status may indicate that the claim has been fully processed and will not be fulfilled. In this regard, a claim denied status may further indicate that the client device will not be repaired and / or replaced pursuant to a device protection program; therefore, it may be best to unlock the functionality of the client device to minimize data inaccessibility and / or user frustration.

[0181] At block 906, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for transmitting a claim denial notification data object case to a trusted third party provider. In some embodiments, the claim denial notification data object is configured to cause the trusted third party provider to terminate an electronic lockout from the client device. In some embodiments, the claim denial notification data object is configured to cause the trusted third party provider to set a case status associated with the third party case to a value, such as “Claim Denied,” indicating that the claim associated with the third party case has been denied. In response to receiving the claim denial notification data object and / or updating the case status to a status indicating that the claim associated with the third party case has been denied, the trusted third party provider can terminate the lockout of the client device associated with the case, thereby returning the client device to a properly functioning state.

[0182] It should be understood that during processing such as that shown in Figures 7, 8, and 9, the device may be configured to receive a user-initiated cancellation of an initiated billing. In this regard, the device 200 may be configured to provide a process such as that depicted and described with respect to Figure 6A in parallel with one or more operations such as those depicted and described with respect to Figures 7, 8, and / or 9. Additionally or alternatively, in some embodiments, a process such as that depicted and described with respect to Figure 6A occurs after one or more of the blocks performed in the process depicted and described with respect to Figures 7, 8, and / or 9.

[0183] In some embodiments, for example, apparatus 200 includes means, such as device lockout management module 210, communications module 208, input / output module 206, processor 202, and / or the like, or a combination thereof, for providing one or more interfaces to a user, e.g., directly on a user device associated with the user and / or indirectly using a trusted third-party provider, to initiate the cancellation of an existing charge. In this regard, the interface(s) may include a cancel request component configured to enable selection for cancellation of an initiated charge and / or submission of the cancellation to apparatus 200. In some embodiments, the cancel request component is responsive to user engagement with the cancel request component (e.g., a cancel request button rendered using a web interface or an application interface). Alternatively or additionally, in some embodiments, a user can cancel a charge using user interaction with one or more call center systems associated with apparatus 200, such as via a call center-generated charge cancellation request, etc.

[0184] In some embodiments, device 200 is configured to cancel the claim, e.g., by setting the claim status to a claim canceled status as described, and / or cause cancellation of the corresponding third-party case, e.g., through one or more transmissions to a trusted third-party provider. In some embodiments, upon termination of the claim and / or third-party case, device 200 may be configured to delete, cancel, and / or otherwise make inaccessible all stored information associated with the claim and / or third-party case, and / or cause a trusted third party to delete, cancel, and / or otherwise make inaccessible all stored information associated with the third-party case. Additionally or alternatively, in some embodiments, the device causes termination of an electronic lockout of the client device associated with the claim upon cancellation of the claim by the user. Exemplary Operation of Device Lockout State Validation 10 illustrates example operations of secure device lockout management, particularly for device lockout state verification, according to at least one example embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a device protection program management system embodied, for example, by apparatus 200 depicted and described above. Apparatus 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 200 communicates with at least one third-party provider, e.g., a carrier system and / or a manufacturer system, and / or a client device.

[0185] In some embodiments, the actions depicted with respect to FIG. 10 are performed in addition to and / or in parallel with one or more of the other actions depicted and described herein, e.g., in FIGS. 3-10. Alternatively, or additionally, in some embodiments, one or more of the actions depicted and described with respect to FIG. 10 occur in addition to and / or in place of one or more actions of another process. For example, in some embodiments, the actions depicted with respect to FIG. 10 begin after one or more blocks for setting a feature lockout state for a client device and / or otherwise initiating and / or terminating an electronic lockout of a client device. Some or all of the actions depicted and described with respect to FIG. 10 may occur in addition to and / or in place of one or more actions of another process described herein. For example, at least block 1002 can include and / or replace one or more other actions described for initiating and / or terminating an electronic lockout of a client device.

[0186] In block 1002, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for transmitting at least one request intended to cause the setting of a feature lockout state of a client device to an intended feature lockout state. In some embodiments, the operations occur as described in one or more blocks of another process described herein, e.g., block 310 of FIG. 3 , block 402 of FIG. 4A , block 452 of FIG. 4B , block 508 and / or block 512 of FIG. 5 , block 606 of FIG. 6A , and / or block 656 of FIG. 6B . In this regard, the apparatus 200 can generate and / or transmit such a transmission to cause the initiation and / or termination of an electronic lockout of the client device. For example, if the intended feature lockout state represents a locked out state, such a transmission may be intended to cause the initiation of an electronic lockout. Similarly, if the intended functional lockout state represents an unlocked state, such a transmission may be intended to cause an end to the electronic lockout.

[0187] In some example contexts, such a transmission may be ineffective due to any of a number of errors. For example, in at least one example context, a transmission may fail to reach a third-party provider due to an incomplete and / or broken connection between device 200 and the third-party provider. Alternatively, or in addition, in at least some example contexts, a transmission may fail to reach a manufacturer system due to an incomplete and / or broken connection between a third-party provider, such as a carrier system, and the manufacturer system. Additionally, or alternatively, in at least some example contexts, a transmission may fail to reach a client device due to an incomplete and / or broken connection between the manufacturer's system and the client device. Due to any of the above reasons and / or other errors in the transmission and / or processing of the transmission by any system involved in setting the client device's feature lockout state, the client device may not be successfully set to the intended feature lockout state based on an attempt to send at least one request.

[0188] In optional block 1004, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for scheduling a status request action based on a status request timestamp interval. In this regard, the status request timestamp interval may represent a period of time until the status request action is performed. In some such embodiments, the status request action may include one or more actions for receiving a current value of the feature lockout state of the client device, as described herein. For example, the status request action may include one or more operations described herein, such as those described below with respect to block 1006. In this regard, the apparatus 200 may wait until the status request timestamp interval has elapsed to perform the status request action.

[0189] At block 1006, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for transmitting a lockout status request associated with the client device. In some embodiments, the lockout status request is transmitted to a third-party provider, such as a manufacturer system, in communication with the client device. In this regard, the lockout status request may cause the third-party provider to communicate with the client device and retrieve a value of the device lockout status of the client device. Alternatively, or in addition, in some embodiments, the lockout status request is transmitted to a third-party provider, such as a carrier system, in communication with a manufacturer system configured to communicate with the client device. In this regard, the lockout status request may cause the third-party provider to transmit one or more requests to the manufacturer system, which may be specially configured to retrieve a value of the device lockout status of the client device. It should be understood that the various systems may be configured to communicate over any number of communications networks. For example, in some embodiments, apparatus 200, third-party providers, manufacturer systems, and / or client devices may each communicate over an Internet connection and / or over one or more cellular networks, private networks, and / or the like.

[0190] At block 1008, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for receiving data representing a current data value of a feature lockout status of a client device. In some such embodiments, the data representing the current data value of the feature lockout status may be received in response to the lockout status request sent at block 1006. In some such embodiments, the current data value of the feature lockout status of the client device may be parsed from the received response data. The data representing the current data value of the feature lockout status of the client device may embody different values ​​based on whether the client device is currently affected by an electronic lockout.

[0191] At decision block 1010, the apparatus 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for determining whether a current data value represents an intended feature lockout state. In at least one exemplary context, the current data value of the client device's feature lockout state indicates whether the electronic device is currently affected by an electronic lockout. For example, in at least one exemplary context, the current data value may represent a locked state in situations where the client device is currently affected by an electronic lockout. Similarly, in at least one exemplary context, the current data value may represent an unlocked state in situations where the client device is not currently affected by an electronic lockout. In this regard, in some embodiments, the apparatus 200 may be configured to compare the client device's current data value received at block 1008 with the value of the intended feature lockout state to determine whether the current data value represents the intended feature lockout state. In some such embodiments, in situations where the current data value represents the intended feature lockout state, device 200 determines that the intended feature lockout state has been successfully set. Similarly, in some such embodiments, in situations where the current data value does not represent the intended feature lockout state, device 200 determines that the intended feature lockout state has not been successfully set.

[0192] In situations where device 200 determines that the current data values ​​represent the intended feature lockout state and / or that the intended feature lockout state has been successfully set, the flow may end. Alternatively, in at least one exemplary embodiment, device 200 may perform one or more additional actions based on the determination. For example, in at least one embodiment, device 200 may mark one or more indicators that represent that device 200 has verified the client device's current feature lockout state as correct.

[0193] Returning to decision block 1010, in situations where the device 200 determines that the current data values ​​do not represent the intended feature lockout state and / or that the intended feature lockout state has not been successfully set, flow may proceed to block 1012. In block 1012, the device 200 includes means, such as the device lockout management module 210, the communications module 208, the input / output module 206, the processor 202, and / or the like, or a combination thereof, for transmitting at least one second request intended to cause the setting of the client device's feature lockout state to the intended feature lockout state. In this regard, the second at least one request may represent a second attempt performed by the device 200 in setting the intended feature lockout state. In this regard, the device 200 may similarly attempt to transmit the second at least one request over one or more communications networks to a third party provider, such as a carrier system and / or a manufacturer system, that communicates with the client device. Upon and / or after sending the second at least one request, flow may return to optional block 1004. In some such embodiments, the timestamp interval for the status request may be increased with each iteration (e.g., multiplied by two or another factor, increased uniformly, etc.). In this regard, flow may continue through the cycle embodied by the various depicted and described blocks until, for example, at decision block 1010, device 200 determines that the current data value of the client device's feature lockout state represents the intended feature lockout state. In this regard, device 200 may be configured to reliably determine that the client device has been set to the intended feature lockout state, thereby ensuring that the electronic lockout is initiated if desired or terminated if not.Thus, device 200 can provide advantages in reducing the likelihood that a client device will remain in an inappropriate feature lockout state, e.g., reducing the opportunity for an unauthorized user to access a client device's features in situations where an electronic lockout has not yet been successfully set due to an error, and / or reducing user frustration due to the user being locked out of features via the client device in situations where an electronic lockout has not yet been successfully terminated due to an error. The depicted and described process provides such advantages without additional processing by the client device, thus conserving computing resources on the client device. Exemplary Secure Device Lockout Management Flow Performed by a Third-Party Provider 11 illustrates an example process for secure device lockout management in accordance with at least one example embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a third-party provider system, such as a carrier system and / or a manufacturer system, as embodied by apparatus 250 depicted and described above. Apparatus 250 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 250 communicates with a user device, a device protection program management system, a client device, and / or another third-party provider, such as a carrier system and / or a manufacturer system.

[0194] In block 1102, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for receiving a client device event data object associated with a client device, the client event data object including a case initiation request. In at least some embodiments, the client device event data object is received from a user device associated with a user. In this regard, the user can send the client device event data object to initiate a claims process associated with the client device. In some embodiments, the client device event data object includes, for example, one or more client device fault data objects indicating that the client device is damaged or otherwise defective and / or a client device loss data object indicating that the client device is lost, stolen, or otherwise physically inaccessible. In some embodiments, the case initiation request includes at least a client device identifier associated with the client device, such that, for example, the apparatus 250 can utilize the client device identifier to uniquely associate the received data with a particular client device. Additionally or alternatively, in some embodiments, device 250 is configured to generate a third-party case in response to a case initiation request, e.g., based on at least the received client device event data object. Additionally or alternatively, in some embodiments, device 250 is configured to authenticate a user associated with the received client device event data object. For example, in some embodiments, device 250 is configured to provide one or more user authentication processes that enable device 250 to verify the identity of a user.Non-limiting examples of such processes include logging in using user credentials (e.g., username and password), verifying through a device associated with a known user (e.g., two-factor authentication via a separate device or channel), or a combination thereof.

[0195] In block 1104, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for transmitting an electronic data signal to the client device. The electronic data signal may be specifically configured to trigger an electronic lockout of the client device. In this regard, in some embodiments, the electronic signal represents a request to set the function lockout status of the client device to a locked state. It should be understood that in some exemplary contexts, the electronic data signal is transmitted directly to the client device, e.g., via one or more communications networks between the apparatus 250 and the client device. Alternatively, or in addition, in at least one exemplary context, the electronic data signal is transmitted indirectly, e.g., using a manufacturer system configured to trigger the electronic lockout. In some such embodiments, the electronic data signal may be transmitted to the manufacturer system through one or more APIs, for example.

[0196] At block 1106, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for transmitting case confirmation data to the device protection program management system. In some such embodiments, the case confirmation data is based at least in part on a client device failure data object or a client device loss data object. In this regard, the case confirmation data may include some or all of the client device event data object received in the previous step and / or information generated based on the client device event data object. For example, in some embodiments, the case confirmation data includes one or more authentication tokens generated by the apparatus 250 after successfully authenticating a user associated with the received client device event data object, client device identifier, claim type, device protection program identifier, and / or combinations thereof. In this regard, the claim type may be based on whether a client device failure data object or a client device loss data object was received from the user, such that a corresponding claim type is transmitted within the case confirmation data. In some such embodiments, the claim confirmation data may be used by the device protection program management system in initiating a claim associated with the client device.

[0197] At block 1108, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for receiving a claim status update data object from the device protection program management system. In some embodiments, the claim status update data object represents whether the device protection program management system successfully initiated a claim associated with the case confirmation data. Alternatively, or in addition, in some embodiments, the claim status update data object represents whether the device protection program management system successfully processed the claim and / or whether the claim was denied or approved. Further, in some embodiments, the claim status update data object represents whether the claim timed out and / or was canceled by the user. It should be understood that the claim status update data object can embody one of numerous values, as described herein.

[0198] At block 1110, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for performing a device lockout update action based at least on the billing status update data object. In this regard, the apparatus 250 may be configured to perform an appropriate device lockout update action based on the value of the received billing status update data object. In at least one example context, the apparatus 250 is configured to terminate an electronic lockout of the client device or continue an electronic lockout of the client device to perform the device lockout update action. A non-limiting example process for performing a device lockout update action based on the billing status update data object is depicted and described herein with respect to FIG. 13 .

[0199] 12 illustrates additional operations of an exemplary process for secure device lockout management, particularly for terminating an electronic lockout based on a drop-dead timer, in accordance with at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a third-party provider system, such as a carrier system and / or a manufacturer system, as embodied by apparatus 250 depicted and described above. Apparatus 250 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 250 communicates with a user device, a device protection program management system, a client device, and / or another third-party provider, such as a carrier system and / or a manufacturer system.

[0200] In some embodiments, one or more of the acts illustrated with respect to Figure 12 occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, Figure 12 begins after block 1104 as depicted and described with respect to Figure 11. Additionally or alternatively, as depicted, in some embodiments, the flow ends upon completion of the acts depicted with respect to Figure 12. It should be understood that alternatively or additionally, in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to Figure 12 and / or upon completion of the acts depicted and described with respect to Figure 12.

[0201] In block 1202, the device 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for initiating a drop-dead timer of a predetermined period. In this regard, the drop-dead timer may represent a timestamp interval after which a case is determined to be abandoned. To minimize the impact of a user abandoning a case, for example, if a user forgets about a pending case and later recovers a lost or stolen device, the client device should be unlocked to allow the client device's functionality to be accessed by the user. Thus, in some embodiments, the predetermined period may be specifically determined based on a reasonable time within which a user can submit initial user case information to initiate a claim. In some embodiments, the predetermined period represents a threshold claim initiation period for an associated device protection program management system.

[0202] At block 1204, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for determining that a claim status update has not been received within a predetermined period of time. In this regard, the apparatus 250 may be configured to track a drop dead timer that, for example, performs periodic checks to determine whether a claim status update has been received from the device protection program management system. Additionally or alternatively, the apparatus 250 may be configured to perform a check to determine whether a claim status update notification data object has been received from the device protection program management system once the drop dead timer has elapsed (e.g., after a predetermined period of time). If a claim status update notification data object is received within the predetermined period of time (e.g., before the drop dead timer has elapsed), the apparatus may be configured to cancel and / or terminate the drop dead timer. In this regard, in some embodiments, the apparatus 250 determines that a claim status update notification data object has not been received within the predetermined period of time after the drop dead timer has elapsed without cancellation and / or other termination by the apparatus 250. This determination may indicate that the user has waived initiation of claims via the device protection program management system.

[0203] In block 1206, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for transmitting an electronic data signal to the client device, the electronic data signal being configured to cause an electronic lockout of the client device. In this regard, in some embodiments, the electronic signal represents a request to set the functionality lockout state of the client device to an unlocked state. Ending the electronic lockout of the client device restores the client device to its normal functionality, thereby allowing the user to access such functionality and abandon the initiation and / or processing of claims. Restoring such functionality is advantageous for protecting access to the client device's data in the event that it is lost or otherwise removed from the legitimate user's possession, but desires access to utilize such functionality of the client device if the user finds or otherwise decides to retain the client device, and therefore abandons the claim. It should be understood that in some exemplary contexts, the electronic data signal is transmitted directly to the client device, e.g., via one or more communications networks between the apparatus 250 and the client device. Alternatively or additionally, in at least one exemplary context, the electronic data signal is transmitted indirectly, e.g., using a manufacturer system configured to trigger an electronic lockout. In some such embodiments, the electronic data signal may be transmitted to the manufacturer system through one or more APIs, for example.

[0204] 13 illustrates additional operations of an exemplary process for secure device lockout management, particularly for performing device lockout update actions based on at least a billing status update data object, in accordance with at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a third-party provider system, such as a carrier system and / or a manufacturer system, as embodied by apparatus 250 depicted and described above. Apparatus 250 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 250 communicates with a user device, a device protection program management system, a client device, and / or another third-party provider, such as a carrier system and / or a manufacturer system.

[0205] In some embodiments, one or more of the acts depicted with respect to Figure 13 occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, Figure 13 begins after block 1108 as depicted and described with respect to Figure 11. Additionally or alternatively, as depicted, in some embodiments, the flow ends upon completion of the acts depicted with respect to Figure 13. It should be understood that alternatively or additionally, in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to Figure 13 and / or upon completion of the acts depicted and described with respect to Figure 13.

[0206] In block 1302, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for determining a value of a received claim status update notification data object. In this regard, the value of the received claim status update notification data object may represent a type of claim status update notification received. In this regard, the apparatus 250 may be configured to perform different actions based on the value of the received claim status update notification data object.

[0207] For example, as shown, in the situation where the device 250 determines that the claim status update notification data object includes a claim denial notification data object, flow continues to block 1304. At block 1304, the device 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for causing the client device to terminate an electronic lockout. For example, in some embodiments, to terminate an electronic lockout of a client device, the device 250 is configured to send one or more specially configured electronic data signals to the client device to set the client device's feature lockout state to an unlocked state. In this regard, the device 250 may be configured to terminate the electronic lockout through direct communication with the client device, e.g., in situations where the device 250 embodies a manufacturer system, or indirectly through communication with the manufacturer system, e.g., in situations where the device 250 embodies a carrier system.

[0208] Additionally or alternatively, optionally, in some embodiments, flow proceeds to block 1304 in situations where the billing status update notification data object includes a billing cancellation notification data object. In this regard, the billing cancellation notification data object indicates that a user has actively canceled an initiated billing and further indicates that the user has found a lost and / or stolen client device and / or otherwise decided to keep the client device. In such situations, ending the electronic lockout of the client device allows the user to restore functionality of the client device for access.

[0209] In situations where the device 250 determines that the claim status update notification data object includes a claim authorization notification data object, the flow proceeds to block 1306. In block 1206, the device 250 includes a means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for maintaining an electronic lockout on the client device. In this regard, maintaining an electronic lockout results in the accessible functions of the client device remaining limited, e.g., allowing replacement and / or repair of the client device before it leaves the user's possession. In this regard, by maintaining an electronic lockout on the client device, the device 250 enhances the security of data accessible using the client device by preventing access to data and other functions by unauthorized or otherwise unintended and / or malicious users. It should be understood that, as described herein, in some embodiments, the device 250 does not perform additional steps to maintain an electronic lockout on the client device. Alternatively or additionally, device 250 may update a case status associated with the claim to indicate that the claim has been finally resolved and that the client device's feature lockout state remains permanent. Additionally or alternatively, device 250 may transmit one or more electronic data signals to the client device, e.g., directly or indirectly, with one or more other third-party provider(s), e.g., manufacturer devices.

[0210] 14 illustrates additional operations of an exemplary process for secure device lockout management, particularly for providing information to a device protection program management system, in accordance with at least one exemplary embodiment of the present disclosure. In some embodiments, the depicted operations are performed by a third-party provider system, such as a carrier system and / or a manufacturer system, as embodied by apparatus 250 depicted and described above. Apparatus 250 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as depicted and described below. For example, in at least some embodiments, apparatus 250 communicates with a user device, a device protection program management system, a client device, and / or another third-party provider, such as a carrier system and / or a manufacturer system.

[0211] In some embodiments, one or more of the acts depicted with respect to FIG. 14 occur in addition to and / or instead of one or more acts of another process. For example, as depicted, in some embodiments, FIG. 14 begins after block 1102 as depicted and described with respect to FIG. 11. In some embodiments, for example, as depicted, upon completion of the acts depicted and described with respect to FIG. 14, the flow returns to one or more acts depicted with respect to FIG. 11. Additionally or alternatively, as depicted, in some embodiments, the flow ends upon completion of the acts depicted with respect to FIG. 14. It should be understood that alternatively or additionally, in other embodiments, one or more other processes and / or sub-processes may begin after one or more of the acts depicted and described with respect to FIG. 14 and / or upon completion of the acts depicted and described with respect to FIG. 14.

[0212] In block 1402, the device 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for storing at least a portion of the information associated with at least one of the client device event data objects. In some embodiments, the stored portion of the information includes at least a client identifier of the client device. In some embodiments, the device 250 creates and stores a third-party case including at least a portion of the information, for example, in one or more data stores managed by the device 250. In this regard, the third-party case may include information associated with processing of the information received by the user and may be generated along with a case identifier utilized to uniquely identify the third-party case. In some embodiments, the stored portion of the information further includes an authentication token generated by the device 250 in response to successfully verifying the identity of the user associated with the submitted information. In this regard, the authentication token may represent that the device 250 has successfully verified the identity of the user through one or more authentication processes.

[0213] At block 1404, the device 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for receiving a case information request from the device protection program management system. The case information request may include one or more identifiers, such as a third-party case identifier, for the user to retrieve information utilized by the device protection program management system to initiate a claim associated with the submitted information and / or process a claim associated with the submitted information. In this regard, the case information request may include a third-party case identifier for use in retrieving the corresponding information. Additionally or alternatively, in some embodiments, the case information request includes an authentication token that is transferred from the device 250 to the device protection program management system.

[0214] At block 1406, the device 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for retrieving a portion of the case information in response to receiving the case information request. For example, in at least some embodiments, the device 250 can query one or more data stores to retrieve the portion of the stored case information. In some such embodiments, the device 250 can be configured to query the data stores based on one or more identifiers, e.g., one or more third-party case identifiers, received with the case information request.

[0215] At block 1408, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for transmitting a portion of the case information to the device protection program management system. In some embodiments, the portion of the case information is transmitted to the device protection program management system in response to a case information request. Such case information may be transmitted to the device protection program management system to make such case information available to the device protection program management system when initiating a claim (e.g., to generate a claim) and / or for processing the claim (e.g., to determine whether the claim satisfies a predetermined rule set that embodies the device protection program).

[0216] At block 1410, the device 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for receiving user case information associated with a client device. In this regard, a user may submit user case information to the device 250 for association with an initiated claim. In some such embodiments, the device 250 may receive user case information from a user device associated with the user. In some such embodiments, the device 250 is configured to provide one or more interfaces to the user device that enable the user to input user case information into the device 250 and / or submit it for transmission. It should be understood that in other embodiments, the device protection program management system receives user case information directly, for example, using direct communication with the user device, as described herein.

[0217] In optional block 1412, the apparatus 250 includes means, such as the third-party case lockout management module 260, the communications module 258, the input / output module 256, the processor 252, and / or the like, or a combination thereof, for transmitting a user case to the device protection program management system. In this regard, the user case information may be transmitted to the device protection program management system along with a third-party case identifier and / or a claim identifier received by the apparatus 250 in a previous step and stored in association with the particular third-party case identifier. The user case information may be processed by the device protection program management system, for example, for use in initiating a claim based on the user case information. In this regard, the user case information may include a claim type, a device protection program identifier, and / or the like. It should be understood that in some embodiments, the transmission may additionally or alternatively cause the device protection program management system to store the user case information for future processing. Upon receiving the user case information, the device protection program may access sufficient data to generate a claim and / or initiate claim processing. In some such embodiments, the apparatus 250 may revert to one or more operations as shown in FIG. 11 to process a subsequently received billing status notification data object, for example, from the device protection program. Additional Implementation Details Although an exemplary processing system has been described above, implementations of the subject matter and functional operations described herein may be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in combinations of one or more of these.

[0218] Embodiments of the subject matter and operations described herein may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in a combination of one or more of these. Embodiments of the subject matter described herein may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on at least one computer storage medium for execution by or to control the operation of a data processing apparatus. Alternatively, or in addition, the program instructions may be encoded in an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal generated to encode information / data for transmission to a suitable receiver apparatus for execution by the information / data processing apparatus. The computer storage medium may be, or may be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of these. Furthermore, although a computer storage medium is not a propagated signal, the computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium may also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0219] The operations described herein may be implemented as operations performed by an information / data processing apparatus on information / data stored in one or more computer-readable storage devices or received from other sources.

[0220] The term "data processing apparatus" encompasses all kinds of apparatuses, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system-on-chip, or a plurality or combination of the foregoing. The apparatus may include special-purpose logic circuitry, such as an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, such as code that constructs processor firmware, a protocol stack, a repository management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The apparatus and execution environment may implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0221] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted, declarative, or procedural, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or information / data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer, or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0222] The processes and logic flows described herein can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input information / data and generating output. Processors suitable for executing computer programs include, by way of example, both general-purpose and special-purpose microprocessors and one or more processors of any type of digital computer. Generally, a processor receives instructions and information / data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for performing actions in accordance with the instructions and one or more memory devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices, such as magnetic, magneto-optical, or optical disks, for storing data, or is operatively coupled to receive information / data from or transfer information / data to them, or both. However, a computer need not have such devices. Devices suitable for storing computer program instructions and information / data include all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; and magneto-optical disks, e.g., CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry. In this regard, the processes and logic flows described herein, and / or various combinations and subcombinations of the depicted and illustrated operations, may embody one or more computer-implemented processes, one or more computer program products, and / or one or more specially configured apparatuses in accordance with the present disclosure.

[0223] To provide for user interaction, embodiments of the subject matter described herein may be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information / data to the user, and a pointing device, e.g., a mouse or trackball, through which the user can provide input to the computer. Other types of devices may also be used to provide for user interaction; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, speech, or tactile input. Additionally, the computer may interact with the user by sending and receiving documents to and from a device used by the user, e.g., by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

[0224] Embodiments of the subject matter described herein may be implemented in a computing system that includes a back-end component, e.g., an information / data server, or a middleware component, e.g., an application server, or a front-end component, e.g., a client computer having a graphical user interface or web browser through which a user can interact with an implementation of the subject matter described herein, or any combination of one or more such back-ends, middleware, or front-ends. The components of the system may be interconnected by any form or medium of digital information / data communication, e.g., a communications network. Examples of communications networks include local area networks (“LANs”) and wide area networks (“WANs”), inter-networks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0225] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of clients and servers arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits information / data (e.g., HTML pages) to client devices (e.g., for the purpose of displaying the information / data to a user interacting with the client device and receiving user input). Information / data generated at the client device (e.g., the results of user interaction) may be received from the client device at the server.

[0226] While this specification contains many specific implementation details, these should not be construed as limiting the scope of any disclosure or what may be claimed, but rather as describing features specific to particular embodiments of a particular disclosure. Certain features described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, even if features are described above as acting in a particular combination and initially claimed as such, one or more features from the claimed combination may, in some cases, be separated from the combination, and the claimed combination may be directed to subcombinations or variations of the subcombination.

[0227] Similarly, although operations are depicted in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular or sequential order shown, or that all of the illustrated operations be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0228] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous. Conclusion Many embodiments of the described subject matter may include all or portions of the systems, apparatus, methods, and / or computer program products described herein, or combinations of portions thereof. The subject matter described herein includes, but is not limited to, the following specific embodiments:

[0229] A. A computer-implemented method for secure device lockout management, comprising: receiving a device claim request indication, the device claim request indication being associated with a client device, the client device being associated with a feature lockout state; Initiating a charge associated with the client device based on the device charge request indication; setting a feature lockout state of the client device to a locked state; processing the claim to determine whether to approve the claim; and causing an update of the feature lockout state of the client device based on the determination of whether to approve the request.

[0230] B. Setting the feature lockout status of the client device to a locked state The computer-implemented method of embodiment A includes sending a device lockout request to a manufacturer system associated with the client device, the device lockout request configured to cause the manufacturer system to set a feature lockout state of the client device to a locked state.

[0231] C. Setting the feature lockout state of the client device to a locked out state The computer-implemented method of embodiment A or B, including a carrier system configured to send a device lockout request to a third party system associated with the client device, wherein the third party system is configured to cause the manufacturer system to set the feature lockout state of the client device to a locked state in response to receiving the device lockout request.

[0232] D. Billing processes the client device to determine whether to continue the lockout state. receiving user billing information associated with the bill within a first timestamp interval; processing the user billing information to approve a bill associated with the user billing information; causing an update of the feature lockout state of the client device based on a determination of whether to continue the client device in a locked-out state; The computer-implemented method of any of embodiments A-C, including causing the feature lockout state of the client device to remain set to a locked state.

[0233] E. Processing billing to determine whether to continue the client device lockout state receiving user billing information associated with the bill within a first timestamp interval; processing the user billing information to deny a bill associated with the user billing information; causing an update of the feature lockout state of the client device based on a determination of whether to continue the client device in a locked-out state; The computer-implemented method of any of embodiments A-D, including setting a feature lockout state of the client device to an unlocked state.

[0234] F. Processing billing to determine whether to continue the client device lockout state determining that user billing information associated with the bill has not been received within a first timestamp interval; causing an update of the feature lockout state of the client device based on a determination of whether to continue the client device in a locked-out state; The computer-implemented method of any of embodiments A-E, including causing a feature lockout state of a client device to be set to an unlocked state.

[0235] 10. A computer program product for secure device lockout management, the computer program product including at least one non-transitory computer-readable storage medium having computer program code stored thereon, the computer program code configured, when executing on at least one processor, to perform the method of any of embodiments A-F.

[0236] H. An apparatus for secure device lockout management, the apparatus comprising means for performing the method of any of embodiments A-F. I. A computer-implemented method for secure device lockout management, comprising: receiving case confirmation data from a trusted third party provider, the case confirmation data being associated with a client device identifier of the client device; causing the rendering of a graphical user interface to the user, the graphical user interface including a request to input user case information; receiving user case information using a graphical user interface, wherein in the situation where the user case information is received within a threshold claim initiation period, the method comprises: Initiating a claim based on the case confirmation data and user case information; transmitting a claim creation notification data object to a trusted third-party provider, the data object including computer program instructions configured to cause a continuation of the electronic lockout of the client device; receiving billing requirement data from at least one user device associated with the client device, the billing requirement data being based on a predefined rule set associated with the device protection program; and in a situation where the billing requirement data is received within a threshold billing completion period, the method further comprises: In the event that the claim requirement data does not satisfy a predefined set of rules, transmitting a claim denial notification data object to a trusted third-party provider, the claim denial notification data object including computer program instructions configured to cause a termination of said electronic lockout of the client device; and sending a claim approval notification data object to a trusted third-party provider in a situation where the claim requirement data satisfies a predefined rule set, the claim rejection notification data object including computer program instructions configured to cause a continuation of an electronic lockout of the client device.

[0237] J. A computer-implemented method comprising: The computer-implemented method of embodiment I, further comprising comparing the billing requirement data with a predefined rule set to determine whether the billing requirement data satisfies the predefined rule set.

[0238] K. A computer-implemented method comprising: The computer-implemented method of any of embodiments I-J, further comprising terminating processing of case confirmation data in the situation where user case data is not received from at least one user device within a threshold claim initiation period.

[0239] L. A computer-implemented method comprising: The computer-implemented method of any of embodiments I-K, further comprising extracting a device identifier from the case confirmation data.

[0240] M. A computer-implemented method comprising: Identifying an authentication token from the case confirmation data; The computer-implemented method of any of embodiments I-L, further comprising: utilizing the authentication token to retrieve third-party case data from a trusted third-party provider, wherein the third-party case data includes at least the device identifier.

[0241] N. The computer-implemented method, in the situation where the billing requirement data is received within the billing requirement time threshold, further comprising comparing the billing requirement data to a predefined rule set to determine whether the billing requirement data satisfies the predefined rule set; the method further comprising approving the claim in a situation where the claim requirement data satisfies a predefined rule set; The computer-implemented method of any of embodiments I-M, wherein the method further comprises rejecting the claim in situations where the claim requirement data does not satisfy a predefined rule set for the device.

[0242] O. A computer-implemented method comprising: terminating processing of a claim in the event that claim requirement data is not received within said claim requirement time threshold; The computer-implemented method of any of embodiments I-N, further comprising: sending a billing cancellation notification data object to a trusted third party provider, wherein the billing cancellation notification data object is configured to cause the trusted third party provider to terminate an electronic lockout of the client device.

[0243] P. A computer program product for secure device lockout management, the computer program product including at least one non-transitory computer-readable storage medium having computer program code stored thereon, the computer program code configured, when executing on at least one processor, to perform the method of any of embodiments I-O.

[0244] Q. An apparatus for secure device lockout management, the apparatus comprising means for performing the method of any of embodiments I-O. R. A computer-implemented method for secure device lockout management, comprising: receiving a client device event data object associated with the client device, the client event data object including a case start request; transmitting an electronic data signal to the client device configured to cause an electronic lockout of the client device; transmitting case confirmation data to a device protection program management system, the case confirmation data being based at least in part on the client device failure data object or the client device loss data object; and in a situation where a billing status update data object is received from a device protection program management system, performing a device lockout update action based at least on the billing status update data object.

[0245] S. A computer-implemented method comprising: starting a drop dead timer of a predetermined period; The computer-implemented method of embodiment R further includes sending an electronic data signal to the client device configured to cause termination of an electronic lockout of the client device in the event that a claim status update data object is not received from the device protection program management system within a predetermined period of time or a claim denial notification data object is received from the device protection program management system within a predetermined period of time.

[0246] T. Performing a device lockout update action based on the billing status update data object Ending the electronic lockout in a situation where the claim status update data object includes a claim denial notification data object; and continuing electronic lockout of the client device in situations where the claim status updated data object includes a claim approval notification data object.

[0247] U. A computer-implemented method comprising: In response to receiving the client device event data objects, storing at least a portion of information associated with at least one of the client device event data objects, the portion of information including at least a client device identifier of the client device; receiving a case information request from a device protection program management system; retrieving a portion of the case information in response to receiving the case information request; The computer-implemented method of any of embodiments R-T, further comprising: in response to the case information request, sending a portion of the case information to the device protection program management system.

[0248] V. A computer-implemented method comprising: receiving a billing cancellation notification data object from a device protection program management system; The computer-implemented method of any of embodiments R-U, further comprising: terminating an electronic lockout of the client device.

[0249] W. A computer-implemented method comprising: receiving user case information associated with the client device; The computer-implemented method of any of embodiments R-V, further comprising: sending the user case information to a device protection program management system.

[0250] X. A computer program product for secure device lockout management, the computer program product including at least one non-transitory computer-readable storage medium having computer program code stored thereon, the computer program code being configured, when executing on at least one processor, to perform the method of any of embodiments R-W.

[0251] Y. An apparatus for secure device lockout management, the apparatus including means for performing the method of any of embodiments R-W. Many modifications and other embodiments of the embodiments described herein will come to mind to one skilled in the art to which these embodiments pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. For example, any combination of some or all of the subroutines and subprocesses described herein may be claimed in combination or individually without departing from the scope and spirit of the present disclosure. It is to be understood, therefore, that the embodiments should not be limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. 1. An apparatus including one or more processors and one or more non-transitory memories, wherein the one or more non-transitory memories store computer-coded instructions that are executed by the one or more processors to cause the apparatus to: receiving a device charge request indication sent from a third party provider system external to the apparatus, the device charge request indication corresponding to a client device; In response to receiving the device claim request indication, causing initiation of an electronic lockout of the client device; initiating a charge associated with the client device based at least in part on the device charge request indication; detecting that no additional data associated with the claim has been received within a threshold claim initiation period; triggering a termination of the electronic lockout of the client device in response to determining that the additional data related to the initiation of the claim has not been received within the threshold claim initiation period; and A device that performs the following.

2. To trigger the initiation of the electronic lockout of the client device, the device: (a) sending a first electronic signal to the client device, the first electronic signal causing initiation of the electronic lockout at the client device; (b) transmitting a second electronic signal to a carrier system associated with the client device, causing the carrier system to initiate the electronic lockout in response to receiving the second electronic signal; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, causing the manufacturer system to initiate the electronic lockout in response to receiving the third electronic signal; The apparatus of claim 1 ,

3. To cause an end of the electronic lockout of the client device, the device: (a) sending a first electronic signal to the client device, the first electronic signal causing an end of the electronic lockout at the client device; (b) sending a second electronic signal to a carrier system associated with the client device and causing the termination of the electronic lockout in response to the carrier system receiving the second electronic signal; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, and causing the manufacturer system to terminate the electronic lockout in response to receiving the third electronic signal; The apparatus of claim 1 ,

4. To receive the device billing request indication sent from the third party provider system, the apparatus: receiving the device billing request indication from a carrier system associated with the client device; or receiving the device solicitation request indication from a manufacturer system associated with the client device; The apparatus of claim 1 ,

5. To detect that the additional data related to the claim has not been received within the threshold claim initiation period, the device: starting a drop dead timer associated with an interval defined by said threshold claim initiation period; performing a check to detect that the additional data associated with the claim has not been received due to the expiration of the drop dead timer; The apparatus of claim 1 ,

6. the additional data related to the claim includes case information corresponding to the claim; 10. The apparatus of claim 1.

7. and further configured, in response to determining that the additional data related to initiation of the billing has not been received within the threshold billing initiation period, to cancel the billing associated with the client device.

10. The apparatus of claim 1.

8. 1. A computer-implemented method comprising: receiving, by one or more processors, a device charge request indication sent from a third party provider system external to the one or more processors, the device charge request indication corresponding to a client device; In response to receiving the device claim request indication, causing initiation of an electronic lockout of the client device; initiating a charge associated with the client device based at least in part on the device charge request indication; detecting that no additional data associated with the claim has been received within a threshold claim initiation period; triggering a termination of the electronic lockout of the client device in response to determining that the additional data related to the initiation of the claim has not been received within the threshold claim initiation period; and 11. A computer-implemented method comprising:

9. Triggering the initiation of the electronic lockout of the client device comprises: (a) sending a first electronic signal to the client device, the first electronic signal causing initiation of the electronic lockout at the client device; (b) transmitting a second electronic signal to a carrier system associated with the client device, causing the carrier system to initiate the electronic lockout in response to receiving the second electronic signal; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, causing the manufacturer system to initiate the electronic lockout in response to receiving the third electronic signal; The computer-implemented method of claim 8 , comprising one of:

10. Triggering an end of the electronic lockout of the client device comprises: (a) sending a first electronic signal to the client device, the first electronic signal causing an end of the electronic lockout at the client device; (b) sending a second electronic signal to a carrier system associated with the client device and causing the termination of the electronic lockout in response to the carrier system receiving the second electronic signal; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, and causing the manufacturer system to terminate the electronic lockout in response to receiving the third electronic signal; The computer-implemented method of claim 8 , comprising one of:

11. receiving the device billing request indication sent from the third party provider system; receiving the device billing request indication from a carrier system associated with the client device; or receiving the device solicitation request indication from a manufacturer system associated with the client device; The computer-implemented method of claim 8 , comprising one of:

12. Detecting that the additional data related to the claim has not been received within the threshold claim initiation period includes: starting a drop dead timer associated with an interval defined by said threshold claim initiation period; performing a check to detect that the additional data associated with the claim has not been received due to the expiration of the drop dead timer; The computer-implemented method of claim 8 , comprising:

13. the additional data related to the claim includes case information corresponding to the claim; 9. The computer-implemented method of claim 8.

14. and canceling the billing associated with the client device in response to determining that the additional data related to initiation of the billing has not been received within the threshold billing initiation period.

9. The computer-implemented method of claim 8.

15. One or more non-transitory computer-readable storage media having computer program code stored thereon, the computer program code causing one or more processors to, when executed by the one or more processors, receiving, by the one or more processors, a device charge request indication sent from a third party provider system external to the one or more processors, the device charge request indication corresponding to a client device; In response to receiving the device claim request indication, causing initiation of an electronic lockout of the client device; initiating a charge associated with the client device based at least in part on the device charge request indication; detecting that no additional data associated with the claim has been received within a threshold claim initiation period; triggering a termination of the electronic lockout of the client device in response to determining that the additional data related to the initiation of the claim has not been received within the threshold claim initiation period; and One or more non-transitory computer-readable storage media that cause

16. To cause initiation of the electronic lockout of the client device, the computer program code may cause the one or more processors, upon execution of the computer program code, to: (a) sending a first electronic signal to the client device, the first electronic signal causing initiation of the electronic lockout at the client device; (b) transmitting a second electronic signal to a carrier system associated with the client device, causing the carrier system to initiate the electronic lockout in response to receiving the second electronic signal; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, causing the manufacturer system to initiate the electronic lockout in response to receiving the third electronic signal; The one or more non-transitory computer-readable storage media of claim 15 , further comprising:

17. To cause an termination of the electronic lockout of the client device, the computer program code may cause the one or more processors, upon execution of the computer program code, to: (a) sending a first electronic signal to the client device, the first electronic signal causing an end of the electronic lockout at the client device; (b) sending a second electronic signal to a carrier system associated with the client device and causing the termination of the electronic lockout in response to the carrier system receiving the second electronic signal; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, and causing the manufacturer system to terminate the electronic lockout in response to receiving the third electronic signal; The one or more non-transitory computer-readable storage media of claim 15 , further comprising:

18. To receive the device billing request indication sent from the third-party provider system, the computer program code causes the one or more processors, upon execution of the computer program code, to: receiving the device billing request indication from a carrier system associated with the client device; or receiving the device solicitation request indication from a manufacturer system associated with the client device; The one or more non-transitory computer-readable storage media of claim 15 , further comprising:

19. To detect that the additional data related to the claim has not been received within the threshold claim initiation time period, the computer program code may cause the one or more processors, upon execution of the computer program code, to: starting a drop dead timer associated with an interval defined by said threshold claim initiation period; performing a check to detect that the additional data associated with the claim has not been received due to the expiration of the drop dead timer; The one or more non-transitory computer-readable storage media of claim 15 , further comprising:

20. the additional data related to the claim includes case information corresponding to the claim; 16. One or more non-transitory computer-readable storage media as recited in claim 15.

Images