Apparatus, method, and computer program product for lockout of a request management device

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 to a client device configured to cause an electronic lockout of the client device; transmitting case confirmation data to a device protection program management system, where the case confirmation data is 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 generally relate to electronic lockout of a device to enable a limited set of functions, specifically, management of electronic lockout of a device based on processing of claims associated with a client device by a device protection program management system.

Background Art

[0002] Devices are often left behind, stolen, or otherwise lost. Restricting access to such devices is desirable to prevent access to the data stored on the device. In addition, preventing access to some of all of the functions of the device can further reduce the likelihood that an unauthorized user will obtain and continue to use the device, thereby improperly precluding the need for an unauthorized user to obtain their own device for legitimate use. Such access prevention is similarly desirable in situations where the device is damaged and submitted for repair or replacement. However, in situations where the device is locked, the device must be effectively managed to lock and / or unlock it at the appropriate time. Improperly unlocking the device can provide unauthorized access to the device by users who did not intend and / or are not otherwise permitted to access it. Improper locking of the device can cause dissatisfaction among legitimate owners and / or possessors, including situations where the user requests a device lockout in connection with a loss and / or damage claim and later finds the device or changes their mind and keeps the device as is. In many cases, systems for managing device lockouts, managing claims associated with the device, and / or managing the initiation of such claims increase the difficulty of performing efficient and / or effective management of electronic lockouts when the claims are being processed. The applicant has found problems with the current implementations of secure device lockout management. Through incorporated efforts, ingenuity, and innovation, the applicant has solved many of these identified problems by developing what is embodied in the present disclosure detailed below. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0003] Generally, embodiments of the present disclosure include an apparatus, a computer-implemented method, and a computer program product for secure device lockout management. Other implementations of one or more alternative lighting assemblies and / or alternative lighting imaging devices will be apparent or will become apparent to those skilled in the art by considering the following figures and detailed description. It is intended that all such additional implementations be included within the scope of the present disclosure and be protected by the following claims.

Means for Solving the Problems

[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 claim request instruction, the device claim request instruction being associated with a client device, and the client device being associated with a functional lockout state. The exemplary computer-implemented method further includes initiating a claim associated with the client device based on the device claim request indication. The exemplary computer-implemented method further includes causing the functional lockout state of the client device to be set to a lockout state. The exemplary computer-implemented method further includes processing the claim to determine whether to approve the claim. The exemplary computer-implemented method further includes causing an update to the functional lockout state of the client device based on the determination of whether to approve the claim.

[0005] In addition to, or alternatively to, in some embodiments of the exemplary computer-implemented method, setting the functional lockout state of the client device to the lockout state includes sending a device lockout request to a manufacturer system associated with the client device, the device lockout request being configured to cause the manufacturer system to set the functional lockout state of the client device to the lockout state.

[0006] In addition to, or alternatively to, in some embodiments of the exemplary computer-implemented method, setting the functional lockout state of the client device to the lockout 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 cause the manufacturer system to set the functional lockout state of the client device to the lockout state in response to receiving the device lockout request.

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

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

[0009] In addition to, or alternatively to, in some embodiments of the exemplary computer-implemented method, processing a claim to determine whether to continue the lockout state of the client device includes determining that user claim information associated with the claim has not been received within a first timestamp interval, and causing an update to the functional lockout state of the client device based on a determination of whether to continue the lockout state of the client device includes setting the functional lockout state of the client device 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 storing computer program code. The computer program code is configured to execute any of the computer-implemented methods of the exemplary embodiments described above when executed on at least one processor.

[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 configure the apparatus to perform any of the computer-implemented methods of the exemplary embodiments described above during execution by the at least one processor. 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 verification data from a trusted third-party provider, the case verification data being associated with a client device identifier of a client device. The second exemplary computer-implemented method further includes causing a rendering of a graphical user interface to the user, the rendering including a request to input user case information. The second exemplary computer-implemented method further includes receiving the user case information using the graphical user interface. In the situation where the user case information is received within a threshold claim start period, the method includes starting a claim based on the case verification data and the user case information, sending a claim creation notification data object including computer program instructions configured to cause continuation of an electronic lockout of the client device to a trusted third-party provider, 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 a situation where claim requirement data is received within a threshold claim completion period, this method involves transmitting a claim rejection notification data object to a trusted third-party provider in a situation where the claim requirement data does not meet a predefined rule set, the claim rejection notification data object including computer program instructions configured to cause an end to the electronic lockout of the client device, and transmitting a claim approval notification data object to a trusted third-party provider in a situation where the claim requirement data meets the predefined rule set, the claim rejection notification data object including computer program instructions configured to cause a continuation of the electronic lockout of the client device.

[0013] In addition to or instead of this, in some exemplary embodiments of a second exemplary computer-implemented method, the second computer-implemented method further includes comparing the claim requirement data with a predefined rule set to determine whether the claim requirement data meets the predefined rule set.

[0014] In addition to or instead of this, in some exemplary embodiments of a second exemplary computer-implemented method, the second computer-implemented method further includes ending the processing of case confirmation data in a situation where no user case data is received from at least one user device within a threshold claim start period.

[0015] In addition to or instead of this, in some exemplary embodiments of a second exemplary computer-implemented method, the second computer-implemented method further includes extracting a device identifier from the case confirmation data.

[0016] In addition to, or instead of, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method includes identifying an authentication token from case verification data and retrieving third-party case data from a trusted third-party provider using the authentication token, where the third-party case data includes at least a device identifier.

[0017] In addition to, or instead of, in some exemplary embodiments of the second exemplary computer-implemented method, the computer-implemented method further includes. In addition to, or instead of, in a situation where claim requirement data is received within a claim requirement time threshold, further including comparing the claim requirement data with a predefined rule set to determine whether the claim requirement data meets the predefined rule set, and the method further includes approving the claim in a situation where the claim requirement data meets the predefined rule set. In addition to, or instead of, rejecting the claim in a situation where the claim requirement data does not meet the predefined rule set of the device.

[0018] In addition to, or instead of, in some exemplary embodiments of the second exemplary computer-implemented method, the second computer-implemented method further includes ending the processing of the claim and sending a claim cancellation notification data object to a trusted third-party provider in a situation where claim requirement data is not received within the claim requirement time threshold, and the claim cancellation notification data object is configured to cause the trusted third-party provider to end 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 in which computer program code is stored. The computer program code is configured to execute any of the second computer-implemented methods of the exemplary embodiments described above during execution by at least one processor.

[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 configure the second apparatus to execute any of the computer-implemented methods of the second exemplary embodiments described above during execution by at least one processor. Alternatively, or in addition, in some embodiments, the second apparatus includes means configured to execute each step of any of the second 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 can be implemented 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 a client device, the client event data object including a case start request. The third exemplary computer-implemented method further includes transmitting an electronic data signal to a 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 at least partially based on a client device failure data object or a client device loss data object. The third exemplary computer-implemented method further includes performing a device lockout update action based at least on a claim status update data object in a situation where the claim status update data object is received from the device protection program management system.

[0022] In addition to or alternatively, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method further includes starting a drop-dead timer for a predetermined period and transmitting an electronic data signal configured to cause an end of the 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] In addition to, or instead of, in some embodiments of the third exemplary computer-implemented method, performing a device lockout update action based on a claim status update data object includes ending an electronic lockout in a situation where the claim status update data object includes a claim rejection notification data object, and continuing an electronic lockout of a client device in a situation where the claim status updated data object includes a claim approval notification data object.

[0024] In addition to, or instead of, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method includes storing at least a portion of information associated with at least one of the client device event data objects in response to receiving a client device event data object, where a portion of the information includes 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, and transmitting a portion of the case information to the device protection program management system in response to the case information request.

[0025] In addition to, or instead of, in some embodiments of the third exemplary computer-implemented method, the computer-implemented method further includes receiving a claim cancellation notification data object from a device protection program management system and ending an electronic lockout of the client device.

[0026] In addition to, or instead of, 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 storing computer program code. The computer program code is configured to execute any of the computer-implemented methods of the third computer-implemented method of the exemplary embodiments described above when executed on at least one processor.

[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 configure the third apparatus to execute any of the computer-implemented methods of the third exemplary embodiment described above when executed on at least one processor. Alternatively, or in addition, in some embodiments, the second apparatus includes means configured to execute each step of any of the third computer-implemented methods described above.

[0029] Although embodiments of the present disclosure have been described in general terms thus far, reference is now made to the accompanying drawings, which are not necessarily drawn to scale.

Brief Description of the Drawings

[0030]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4A

Figure 4B

Figure 5

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0031] Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings in which some, but not all, embodiments of the disclosure are shown. In fact, the embodiments of the 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 A 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 a 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, the claim can be initiated and / or processed using the device protection program management system for a request to replace, repair, and / or otherwise maintain the client device. In this regard, upon successful processing of the claim, such actions associated with the device may be permitted, accompanied, and / or caused to be performed.

[0032] The user can register with the device protection program through a trusted third party. For example, the user can purchase a client device from a device manufacturer and, similarly, register with the device protection program using the device manufacturer. The device manufacturer can control a system that can 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 status or performance of the client device. Further, the device manufacturer's system can be configured to "lock out" the client device such that the client device is inoperable or unable to access functions associated with the device. The lockout can prevent an unauthorized or malicious user from using a device that has been reported lost or stolen, or a device that has been shown as damaged, inoperable, and / or the like.

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

[0034] After the user is authenticated by 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 the client device that is the subject of the device protection program, which indicates that the client device (e.g., a mobile phone) is not in the user's possession. Thus, the trusted third party can generate a third-party case associated with the client device and the indication.

[0035] In some cases, the execution of an exchange according to a device protection program is processed using a device protection program management system of a provider of the device protection program. Thus, information is passed between the device protection program management system and a trusted third party (e.g., a device manufacturer) so that the provider of the device protection program can process claims associated with the client device to enhance and guarantee the user's security and privacy, and not unduly restrict the user's use of the client device.

[0036] For example, when a user (e.g., the client owner of the client device) initiates a third-party case using, for example, an interface of a device manufacturer, the device manufacturer can provide a user authentication token to the device protection program management system along with a third-party case identifier. Using the user authentication token, it can be verified that the user who initiated the claim is authenticated using 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 the third-party case identifier may enable the device protection program management system to retrieve information regarding the client device and, in some embodiments, to verify using a device identifier that the client device is protected by one or more device protection programs.

[0037] The device protection program management system may also associate a trusted third party, such as a device manufacturer, with one or more authentication elements such as IP addresses, entity tokens, and / or the like, and the device protection program management system can be used to confirm that a new third-party case identifier is associated with the device manufacturer. In this way, 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 recognition of the trusted third party. The device protection program management system may be configured to store claim / case information associated with the third-party case identifier and can store user authentication tokens for future communication with the trusted third party.

[0038] When the device protection program manages claim generation and processing, the device protection program may cause a trusted third party to lock out the client device in response to user information indicating a desire to continue claims provided within a predefined period. 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 invalidate the lockout and allow access to the client device. For example, when a device manufacturer initiates a new third-party case and sends a 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 start 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] Next, the user may be presented with an interface of the device protection program management system and may be allowed to submit a claim, which may be generated based at least in part on the user's input to the device protection program management system. Next, the device protection program management system may start a claim generation limit time (e.g., 24 hours). If the user does not continue with the claim (e.g., completes the claim generation process and enters all the necessary information) and the claim limit time elapses, 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 a reliable third party to have the reliable third party terminate the lockout of the client device and return the device to a functional form (e.g., since no claim has been submitted, it is considered that the user no longer wishes to replace the device that was lost or stolen). During the start of the claim and before the claim is completed, the user may provide an account, payment, affidavit related to the incident, statement of facts, or other information necessary to complete the claim. When the information is complete and the user approves the continuation of the device protection program management system, the claim may be submitted and considered generated.

[0040] If the claim is submitted and approved, the device protection program management system may continue with the fulfillment of the claim. The fulfillment of the claim may result in decision events that may include acceptance of the claim (e.g., issuance of a replacement device), rejection of the claim (e.g., rejection of the replacement), and / or termination of the claim due to inactivity. Thus, the device protection program management system may send one or more status signals so that, for example, when a new device is delivered to the user, the device manufacturer may continue to lock out the client device indefinitely. If the claim is submitted and rejected or terminated due to inactivity, the device protection program management system may determine that the claim is fraudulent and may terminate the lockout of the client device by the device manufacturer.

[0041] By authenticating the user using an authentication token or equivalent information provided by a reliable third party, the device protection program management system of the embodiment enables authentication without the need for disclosure of the user's authentication qualification information, thereby strengthening user privacy. Further, the device protection program management system of the embodiment strengthens user security by locking out or enabling the client device according to the billing status, so that malicious actors cannot access client devices that have been duly determined to be lost or stolen, reducing the risk of improper conduct against the device protection program management system and reliable third parties. Also, when the billing is not in progress either through user selection or system error, the access to the client device is restored using multiple checkpoints between systems, so that the user is not unduly restricted from the device.

[0042] Accordingly, embodiments of the present disclosure generate, manage, and / or process claims in a secure manner while maintaining appropriate device functionality for the corresponding client device. For example, in some embodiments, when a user reports that the client device has been lost or stolen and initiates a third-party case through a trusted third-party provider, the client device is locked out so that a malicious user (e.g., a thief or malicious finder of the device) cannot access the client device, thereby enhancing the user's privacy and reducing improper behavior. However, if the user abandons the claim or cancels the claim through a claim cancellation interface provided through the device protection program management system, a claim cancellation request at a call center, etc., the device protection program management system of the embodiment provides a notification to a trusted third-party resource and is configured to cause the trusted third-party resource to return the device to a functional form. Further, by utilizing a threshold claim start period and / or a claim limit time, embodiments of the present disclosure detect that the user has abandoned the case and / or associated claims and no longer continues the claim, and enable a trusted third-party resource to return the device to a functional form to reduce the possibility that the user is inappropriately or improperly locked out of the device. Accordingly, embodiments of the present disclosure utilize a specific information flow between separate systems and entities to provide an active user claim management experience while enhancing the user's security and maintaining the user's privacy. Definition The term "secure device lockout management" refers to a process at the special hardware, firmware, and / or software level to prevent access to some or all functions 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 functions of a client device by one or more communicable systems described herein, such as 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 registering and / or maintaining one or more client devices with one or more associated device protection programs, and / or receiving and / or processing data associated with one or more claims associated with a client device registered with a device protection program. In addition to or instead of this, 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 and are controlled by a second entity different from a first entity that communicates with and controls a device protection program management system. In some embodiments, a trusted third-party provider is configured to communicate with a client device to control at least an electronic lockout of the client device, or at least communicate with a second trusted third-party provider 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, manufacture, and / or creation of the hardware, software, and / or firmware that embodies a client device. In some embodiments, for example, a manufacturer system is controlled by a mobile device manufacturer entity and is embodied by one or more computing devices 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 associated with providing a cellular phone and / or data connection service to one or more client devices registered for one or more services provided using a carrier system and / or one or more associated systems controlled by a carrier entity. In some embodiments, a carrier system is controlled by a carrier entity and is embodied by one or more computing devices configured to communicate with at least a device protection program management system.

[0047] The term "device" refers to hardware, firmware, and / or software that embodies a computer providing special and / or general computing functions 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 registered in at least one device protection program managed using a device protection program management system. In at least one exemplary context, the term "client device" refers to a mobile device (such as a smartphone) registered 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, the client device identifier is embodied by one or more numerical, 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, numerical data representations, and the like.

[0050] The term "user device" refers to a device that can communicate with at least a third-party provider and / or a device protection program management system on one or more communication networks. In some embodiments, the user device is utilized to access a third-party provider and / or a device protection program management system in order to perform one or more actions for initiating and / or executing claims 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 that is configured to perform a limited set of functions. In some embodiments, the electronic lockout of the client device is initiated by communication between the client device and one or more remote systems, such as a trusted provider system and / or a device protection program management system. In some embodiments, during the electronic lockout of the client device, the client device is capable of receiving at least one signal to terminate the electronic lockout and / or of performing at least one permitted limited functional action(s).

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

[0053] The term "functional lockout state" refers to an electronic data value indicating whether an electronic lockout is currently affecting a client device. In some embodiments, for example, the functional lockout state of a client device refers to electronic data managed by the client device, and in some embodiments, this 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 indicating that the client device is in an electronic lockout state and is thus associated with restricted functionality.

[0055] The term "device lockout request" refers to electronically generated data related to setting the functional lockout state of a client device to a lockout state. In this regard, a device lockout request initiates an electronic lockout of the client device. In some embodiments, the device lockout request is generated and / or sent 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 locked-out client device.

[0056] The term "unlock state" associated with a client device refers to a second unique electronic data value indicating that the client device is not in an electronic lockout state. The term "device unlock request" refers to electronically generated data related to setting the functional lockout state of a client device 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 sent 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 display" refers to data received, for example, from a user device or a third-party provider by a device protection program management system, indicating a request to initiate the generation and / or processing of a claim associated with the client device. In some embodiments, the device protection program management system receives data representing a device claim request display indirectly from the user device through a third-party provider in response to the submission of information from the user device to the third-party provider.

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

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

[0060] The term "pending status" refers to an electronic data value indicating that a claim has been sent 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. In addition to or instead of this, for claims in a pending state, in some embodiments, the device protection program management system is configured to enable one or more actions for submitting additional data and / or cancelling the processing of the claim.

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

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

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

[0064] The term "timeout status" refers to another electronic data value indicating 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 the timeout status.

[0065] The term "claim status update data object" refers to an electronically managed data object representing the 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 sent to a third party when the device protection program management system updates the claim status of the claim.

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

[0067] The term "billing permission notification data object" refers to an electronically managed data object generated by a device protection program management system and / or sent from the device protection program management system to a third-party provider, and the data object represents the setting of the billing status of a bill to an approval status.

[0068] The term "billing rejection notification data object" refers to an electronically managed data object generated by a device protection program management system and / or sent from the device protection program management system to a third-party provider, and the data object represents the setting of the billing status of a bill to an approval status.

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

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

[0071] The term "case verification data" refers to data received by a device protection program management system from a third-party provider and / or a user device, which includes user-submitted data used to generate a claim for a client device under the corresponding device protection program. In some exemplary embodiments, the case verification 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 a request. In at least one exemplary context, the case verification data represents an exemplary device claim request display.

[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, the authentication token includes data indicating that the third-party provider has successfully verified the identity of a user associated with the submitted data using one or more authentication processes. In some embodiments, the third-party provider generates and / or provides the authentication token to the device protection program management system for use when confirming that the user's identity is valid and / or when accessing and / or retrieving information stored by the third-party provider. In some embodiments, the authentication token includes an algorithm and / or cryptographic information for verifying 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 sent from a device protection program management system to a third-party provider, representing a request for at least some of the information maintained by the third-party provider that is associated with data submitted by a user in order to initiate a claim. In some embodiments, the case information request includes an authentication token associated with the third-party provider, such that the third-party provider can use the authentication token to verify the identity of the device protection program management system and / or to identify information retrieved and / or sent in response to the request.

[0074] The term "third-party case data" refers to information stored by a third-party provider that is associated with a request submitted by a user in order 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 a claim from the third-party provider using stored data associated with the claim, such as an authentication token of the third-party provider.

[0075] The term "user case information" refers to information submitted by a user in order 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 the 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 user case information directly from the user device. In other embodiments, the device protection program management system is configured to receive user case information indirectly through the third-party provider.

[0076] The term "device protection program" refers to electronically managed data representing a series of support and / or protection actions for one or more devices. In this regard, in some embodiments, the device protection program defines one or more situations in which the owner and / or possessor of the device can receive, at no cost and / or at a low cost, device replacement, repair, and / or other support. In some embodiments, the device protection program is represented by a predefined set of rules for receiving one or more enforcement actions associated with the device protection program.

[0077] The term "predefined set of rules" 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 set of rules embodies the device protection program such that a claim initiated in relation to the device protection program is approved in situations where the data submitted in relation to the claim satisfies some or all of the predefined set of rules. Examples of predefined rules within the predefined set of rules include, but are not limited to, the user submitting data within a predetermined time stamp interval, specific data being submitted by the user (e.g., sufficient loss or damage event information), and / or the submitted data including specific data values (e.g., the damage event being within a predetermined set of target data values).

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

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

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

[0081] The term "threshold claim completion period" refers to the timestamp interval during which a user needs to submit claim requirement data to the device protection program management system in order to enable complete processing of a started claim. In some embodiments, the device protection program is configured to set the claim status of a started claim to a predefined status, such as a timeout status, in a situation 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 claim 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 start request" refers to data sent from a third-party provider to the device protection program management system to indicate that a user has requested the start of a claim associated with a client device. In some embodiments, the case start request includes at least case confirmation data for use in generating the claim.

[0084] The term "client device failure data object" refers to electronically managed data representing information associated with a reduction and / or impairment of the operation of a client device. In some embodiments, a client device failure data object includes one or more data values submitted by a user that describe a reduction and / or impairment of the client device.

[0085] The term "client device loss data object" refers to electronically managed data representing information associated with a stolen, lost, and / or otherwise inaccessible client device. In some embodiments, a client device loss 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 time stamp interval tracked by a third-party provider or associated system and / or a device protection program management system or associated system, and represents the period during which a user needs to submit sufficient data to enable complete processing of a claim. In some embodiments, upon completion of the drop dead timer (i.e., the timer expires without receiving sufficient data), the third-party provider and / or the device protection program management system is configured to terminate the electronic lockout of the client device. System Architecture FIG. 1 shows 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 each other over one or more networks, such as 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, whereby the device protection program management system 102 may be unable to communicate directly with and / or access the client device 106. In addition to, or instead of, this, in some embodiments, one or more systems are configured to communicate with the 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 can communicate directly with the device protection program management system 102 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 communication network 110.

[0088] The client device 106 can be associated, such as being registered in a device protection program associated with the device protection program management system 102. For example, in some embodiments, the user can use a trusted third - party provider 108 to open a third - party case when the client device 106 is lost or stolen, and the user can use the trusted third - party provider 108 to subscribe / register the client device 106 to the device protection program so that the user can submit a claim for a new client device using the device protection program management system 102. In some embodiments, both the user device 104 and the client device 106 can be associated with a single user. Alternatively, or in addition, the user device 104 can 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 can register the client device 106 with a device protection program that targets loss and theft of the client device 106. The trusted third-party provider 108 can be configured to communicate with the user device 104 to authenticate the user associated with the user device 104. In a particular example, the trusted third-party provider 108 can utilize one or more authentication processes to securely authenticate the user, such as 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. Accordingly, the trusted third-party provider 108 can 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 the user with a case - start interface. For example, the trusted third - party provider 108 may be configured to generate and / or provide a case - start interface that displays all client devices and / or user devices associated with the user so that the trusted third - party provider can start a third - party case associated with the client device 106 that the user has lost or stolen. In response to a lost indication associated with the client device 106, for example, in response to user engagement with the "Lost Device" component associated with a particular client device in the case - start interface, the trusted third - party provider 108 is configured to start a new third - party case associated with the client device. The trusted third - party provider 108 can identify third - party case information associated with the third - party case, such as the device identifier associated with the client device 106, previous cases, and / or the number of previous cases started by the user associated with the authenticated third - party user account, and / or the like.

[0091] In addition to and / or instead of this, in response to receiving a lost indication, the trusted third - party provider 108 can be configured to access the client device 106 directly and / or indirectly using a manufacturer system such as the 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, the trusted third - party provider 108 may obtain a device identifier (e.g., International Manufacturer Equipment Identity (IMEI), Internet One or more from a group including a Protocol (IP) address, alphanumeric identifier, etc., previous case information (e.g., the number of third-party cases opened associated with a specific client device and / or user), device location resource information (e.g., whether access to the device location application is enabled associated with the client device, whether the user attempted to access the device location application to find the client device, the last time the user accessed the device location resource to find the device, etc.) can be extracted, identified, and / or otherwise retrieved. In addition to or instead of this, in some embodiments, the third-party case information includes location information, status information of each application associated with the client device, stored data information, etc., associated with the client device 106 associated with the case when the user initiated the third-party case, such that the third-party case information functions as a snapshot of all the information present on the client device 106 when the user initiated the third-party case.

[0092] Furthermore, the reliable third-party provider 108 can be configured to switch a lockout function associated with the client device 106. Due to the lockout function, for example, the client device may become inaccessible, inoperable, or otherwise non-functional. In some embodiments, the reliable third-party provider 108 can be configured to initiate a lockout of the client device 106 when receiving a lost indication or when receiving an indication of the user's approval and intent to claim the lost device.

[0093] The device protection program management system 102 is configured to generate, manage, and / or enforce one or more claims associated with the device protection program. For example, at the start of a new third-party case, a trusted third-party provider can send a third-party case confirmation to the device protection program management system 102 to indicate that a new third-party case associated with a specific third-party case identifier has been 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 can 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 can receive both the third-party case identifier and the authentication token from the trusted third-party provider 108, whereby the device protection program management system 102 can verify that the case has been initiated by a legitimate user of the trusted third-party provider system 108 without accessing or requesting the user's user authentication credentials for accessing the trusted third-party provider system 108.

[0094] The device protection program management system 102 can also be configured to continue or end the lockout of a client device 106 associated with a given third-party case. For example, a trusted third-party provider 108 can lock out the client device 106 when a third-party case is initiated by an authenticated user, whereby the lockout ends after a predetermined period (e.g., 24 hours) without further notification and / or status updates from the device protection program management system 102. In some embodiments, when a billing generation process is initiated and the process is delivered from a 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 billing start period (e.g., 24 hours), the device protection program management system 102 may send a signal to the trusted third-party provider 108 to continue the lockout, for example, by sending a billing 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 claims associated with third-party cases that utilize the received information. In some embodiments, the claim period begins as soon as the claim is generated and being processed by the device protection program management system 102. During the claim period, the user has a limited time, e.g., a determined or pre-determined 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, such that the user may be required to submit additional claim information to proceed with the claim. If the claim information is not received within the claim deadline, the device protection program management system 102 may determine that the user has abandoned the claim and may cancel the claim due to insufficient action. The device protection program management system 102 may send a notification, such as a claim cancellation notification, to the reliable third-party provider 108 that is configured to end the lockout and return the client device 106 to a functional state.

[0096] At any point in time, if the user affirmatively indicates that they want to cancel a claim and / or corresponding third-party case by submitting one or more data requests directly through, for example, the device protection program management system 102 and / or indirectly through a 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 a claim either during the claim generation process or during claim processing before the claim is fulfilled, through their interaction with a cancellation user interface component provided by the device protection program management system 102. The user can do so, for example, after starting a claim but then finding the client device 106. Thus, the device protection program management system 102 can cause the trusted third-party provider 108 to terminate the lockout of the client device 106 and return the client device to a functional state. In some embodiments, the device protection program management system 102 can terminate the lockout directly or indirectly through a trusted third-party provider 108, through one or more transmissions to the third-party manufacturer system 112.

[0097] When all claim information is received during the execution process, the device protection program management system 102 can be configured to approve or reject the claim. For example, the device protection program management system approves or rejects the claim based on third-party case information, user case information, and / or claim parameters or associated conditions. If the claim is approved, the device protection program may send a notification to the trusted third-party provider 108 to update the third-party case status with the trusted third-party provider 108 and may continue to lock out the client device 106 with the trusted third-party provider 108. After approving the claim, the device protection program management system 102 can execute 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, the 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 can continue permanently.

[0098] Alternatively, the device protection program management system 102 may reject the claim based on third-party case information, user case information, and / or claim parameters or associated requirements. Thus, in some embodiments, the device protection program management system 102 is configured to end the lockout associated with the client device with the trusted third-party provider 108 in response to rejecting the claim, for example, by sending a notification to the trusted third-party provider 108. Exemplary devices of the present disclosure The device protection program management system 102 can be embodied by one or more computing systems such as the device 200 shown in FIG. 2A. As shown in FIG. 2A, the device 200 can 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 can be configured to execute the operations described below using one or more of the modules 202-210.

[0099] These components are described in terms of functional limitations, but it should be understood that certain implementations necessarily include 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 can utilize the user utilization of the same processor, network interface, storage medium, etc. to execute their respective associated functions, and thus do not require duplicate hardware for each module. Therefore, it should be understood that the use of the terms "module" and / or "circuit" as used herein with respect to the components of the device 200 includes specific hardware configured to execute the functions associated with a particular module as described herein.

[0100] In addition to, or instead of, this, the terms "module" and "circuit" should be understood broadly to include hardware, and in some embodiments, software and / or firmware for configuring the hardware. For example, in some embodiments, "module" and / or "circuit" may include a processing circuit, a storage medium, a network interface, input / output devices, etc. In some embodiments, other elements of device 200 may provide or supplement the functions of a particular module. For example, processor 202 can provide processing functionality, memory 204 can provide storage functionality, communication module 208 can provide network interface functionality, and so on.

[0101] In some embodiments, processor 202 (and / or a coprocessor, or any other processing circuitry that assists or is otherwise associated with the processor) may communicate with memory 204 via a bus for passing information between components of the device. Memory 204 may be non-transitory and may include, for example, 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). Memory 204 may be configured to store information, data, content, applications, instructions, etc. to enable device 200 to perform various functions according to exemplary embodiments of the present disclosure.

[0102] Processor 202 may be embodied in any one of a number of ways and may include, for example, one or more processing devices configured to execute independently. In addition to, or instead of, this, the processor may include one or more processors configured in tandem using a bus to enable independent execution of instructions, pipelines, and / or multithreading. The use of the terms “processor,” “processing module,” and “processing circuit” 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 to, this, processor 202 may be configured to execute hard-coded functionality. Thus, regardless of whether it is configured by hardware or software means, or a combination thereof, processor 202 can represent an entity (e.g., one physically embodied in circuitry) that, while being configured accordingly, can perform operations according to embodiments of the present disclosure. Alternatively, as another example, where the processor is embodied as an executor of software instructions, the instructions may specifically configure the processor to perform the algorithms and / or operations described herein when the instructions are executed.

[0104] As an example of a context, the processor 202 may be configured to generate, process, and / or execute one or more claims associated with a client device. In this regard, the processor 202 may be configured to enable the device 200 to process received data for the purpose of determining whether to approve and / or reject a started claim. In addition to, or alternatively to, this, in some embodiments, the processor 202 is configured to cause the initiation of an electronic lockout and / or cause the termination of an electronic lockout of the client device, for example using one or more transmissions. In addition to, or alternatively to, this, in some embodiments, the processor 202 is configured such that a user can register the client device with a device protection program, initiate a claim associated with the device protection program of the client device, cancel an existing claim, and / or unregister from the device protection program. In some embodiments, the processor 202 is configured to automatically cause the initiation of an electronic device lockout and / or automatically cause the termination of an electronic device lockout when a claim is started, processed, and / or completed.

[0105] In some embodiments, apparatus 200 may include an input / output module 206 embodied in hardware, software, firmware, or combinations thereof, and thus communicate with processor 202 to provide outputs to a user and, in some embodiments, receive displays of user input. The input / output module 206 may include a user interface and may include a display (e.g., for rendering one or more user interfaces). The user interface may include a web user interface, a mobile application, a desktop application, a linked or networked client device, a kiosk, and the like. In some embodiments, the input / output module 206 may also include a keyboard, a mouse, a joystick, a touch screen, a touch area, soft keys, a microphone, a speaker, or other input / output mechanisms. The processor and / or a user interface module including the processor, such as 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 a memory accessible to the processor (e.g., memory 204 and / or the like).

[0106] In addition to, or alternatively to, this, in some embodiments, the apparatus 200 includes a communication module 208. The communication 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 between a network and / or other devices, circuits, or modules that communicate with the apparatus 200. In this regard, the communication module 208 may include, for example, a network interface to enable communication with a wired or wireless communication network. For example, the communication module 208 may include one or more network interface cards, antennas, buses, switches, routers, modems, and support hardware and / or software, or any other device suitable for enabling communication over a network. Additionally or alternatively, the communication interface may include circuitry for interacting with an antenna(s) to effect transmission of signals via the antenna(s), or for processing reception of signals received via the antenna(s).

[0107] In addition to, or alternatively to, in at least some embodiments, the apparatus 200 includes a device lockout management module 210. In some such embodiments, the device lockout management module 210 is embodied in any of software, hardware, firmware, and / or combinations thereof. In this regard, the device lockout management module 210 can be embodied by any means for enabling registration to / from a device protection program. In addition to, or alternatively to, the device lockout management module 210 can be embodied by any means for enabling initiation of billing for a client device associated with a device protection program, processing of billing for the client device, and / or execution of billing for the client device in response to such processing. In some embodiments, in addition to, or alternatively to, the device lockout management module 210 is configured to cause initiation and / or termination of electronic lockout of a client device when a billing associated with the client device is initiated and / or processed. In some such embodiments, for example, the device lockout management module 210 is configured to perform one or more device lockout update actions including generating and / or sending one or more requests to a third-party provider to initiate and / or terminate electronic lockout of a client device by setting an appropriate functional lockout status, but is not limited thereto. In addition to, or alternatively to, in at least some embodiments, the device lockout management module 210 is configured to, for example, retrieve a device function status of a client device using communication with a third-party provider, confirm that the status is appropriately set, and / or perform an action based on the received device function status.In some embodiments, it should be understood that 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 modules 202-210 may share hardware to eliminate duplicate hardware requirements. Additionally or alternatively, in some embodiments, one or more of modules 202-210 may be combined such that a single module includes means configured to perform the operations of two or more of modules 202-210. For example, in at least one embodiment, device lockout management module 210 and processor 202 are combined into a module embodied in a processing circuit. Additionally or alternatively, one or more of modules 202-210 may be embodied by two or more sub-modules, which may be communicable, operate in conjunction, or be separate.

[0109] Trusted third-party provider 108 and / or 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 processor 252, memory 254, input / output module 256, communication module 258, and 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 components similarly named can 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 can perform similar functions with respect to apparatus 250. For example, in this regard, similar to the functions described with respect to apparatus 200 of FIG. 2A, processor 252 may provide similar processing functions to apparatus 250, memory 254 may provide similar memory storage functions to apparatus 250, input / output module 256 may provide similar input / output, display, and / or interaction functions to apparatus 250, and / or communication module 258 may provide similar networking, interface, and / or communication functions to apparatus 250. For the sake of brevity, repeated disclosure is omitted.

[0111] In some such embodiments, the third-party case lockout management module 260 is embodied in any of software, hardware, firmware, and / or combinations thereof. In this regard, the device lockout management module 210 can be embodied by any means for initiating and / or managing a third-party case associated with information submitted by a user, providing one or more interfaces to a user device associated with the user, transmitting data to and / or processing data received from a device protection program management system, initiating an electronic lockout of a client device, and / or terminating an electronic lockout of a client device. In some such embodiments, the third-party case lockout management module 260 can 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 can update a locally managed third-party case based on one or more claim status update notification data objects (e.g., claim cancellation notification data objects, claim approval notification data objects, and / or the like) received from the device protection program management system. In addition to or instead of this, the third-party case lockout management module 260 can set the functional lockout state of the corresponding client device to an appropriate value based on data received from the device protection program management system, and can include means configured to, for example, initiate an electronic lockout of the client device, continue the electronic lockout, and / or terminate the electronic lockout. Further, during the processing of a claim, the third-party case lockout management module 260 can generate, track, and / or otherwise manage one or more timers associated with the initiation and / or processing of the claim, such as one or more drop-dead timers utilized to determine whether the client device should be unlocked when the third-party case and / or the corresponding claim has been determined to be abandoned.In some embodiments, it should be understood that 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 modules 252-260 may share hardware to eliminate duplicate hardware requirements. Additionally or alternatively, in some embodiments, one or more of modules 252-260 may be combined such that a single module includes means configured to perform the operations of two or more of 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 modules 252-260 may be embodied by two or more sub-modules, which may be communicable, operate in conjunction, or be separate. Exemplary Secure Device Lockout Management Flow FIG. 3 shows exemplary operations of an exemplary process for secure device lockout management, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system embodied by, for example, the device 200 described and explained above. The device 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as described and explained below. For example, in at least some embodiments, the device 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

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

[0114] In some embodiments, the device claim request indication is associated with a client device. For example, in this regard, the device claim request indication can represent a user request to initiate a claim associated with the client device. In some such embodiments, the device claim request indication can include a client device identifier, such as an IMEI or other unique identifier. In addition to, or instead of, this, in some embodiments, the client device is associated with a functional lockout state. The functional lockout state can indicate whether the client device is currently associated with restricted functionality, such as being controlled by a manufacturer system associated with the client device. In some embodiments, for example, in a situation where there are no previously initiated claims for the client device, the client device can be in an unlocked state (e.g., the value of the functional lockout state can represent the unlocked state), and thus the functionality of the client device is not restricted.

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

[0116] In block 306, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, to cause the client device to set its functional lockout state to the lockout state. In some embodiments, by setting the functional lockout state to the lockout state, the apparatus 200 is configured to cause the initiation of an electronic lockout of the client device such that the functionality becomes inaccessible or a limited subset of the functionality remains accessible. By locking out such functionality, the apparatus 200 improves the data security associated with the client device while at least partially minimizing the potential for the user to be adversely affected due to the device being damaged and / or proven to no longer be in the user's possession by the user having initiated a claim. The apparatus 200 can be configured to cause the functional lockout state to be set to the lockout state in any of a number of ways, including, for example, using one or more transmissions to a third-party provider. Non-limiting exemplary processes for setting the functional lockout state are shown and described below with respect to FIGS. 4A and 4B.

[0117] In block 308, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for processing a claim and determining whether to approve the claim. In some such embodiments, to process a claim, the apparatus 200 is configured to compare received information submitted by a user and associated with the claim against various requirements under a related device protection program associated with the claim, for example, embodied by a predefined set of rules. In this regard, the apparatus 200 may request that the user submit additional data to determine whether to approve or reject the claim based on the predefined set of rules. In addition to or instead of this, the apparatus 200 may be configured to determine, for example, as illustrated and described below with respect to FIG. 6A, whether the user actively cancels the claim during processing. In addition to or instead of this, the apparatus 200 may be configured to determine, for example, as illustrated and described below with respect to FIG. 6B, whether processing of the claim times out based on one or more timestamp intervals.

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

[0119] FIG. 4A shows additional operations of an exemplary process for secure device lockout management, particularly for setting the functional lockout state of a client device to a locked-out state, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system embodied by the apparatus 200 described and explained above. The 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 described and explained below. For example, in at least some embodiments, the apparatus 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or the client device.

[0120] In some embodiments, one or more of the operations shown with respect to FIG. 4A occur in addition to and / or instead of one or more of the operations 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. In addition to or instead of this, as depicted, in some embodiments, upon completion of the operations depicted with respect to FIG. 4A, the flow returns to block 308 as depicted and described with respect to FIG. 3. In other embodiments, it should be understood that one or more other processes and / or sub-processes may begin after and / or upon completion of one or more of the operations depicted and described with respect to FIG. 4A.

[0121] At block 402, apparatus 200 includes means such as device lockout management module 210, communication module 208, input / output module 206, processor 202, and / or the like, or combinations 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 functional lockout state of the client device to a lockout state. In this regard, upon transmitting the device lockout request to the manufacturer system, an electronic lockout of the client device is initiated. It should be understood that in some embodiments, the device lockout request is transmitted over any of a number of communication networks, such as, for example, 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 communication network, such as the Internet, and / or a second communication network to set the functional lockout state of the client device. For example, in at least one exemplary embodiment, the device lockout request causes the manufacturer system to generate and / or transmit to the client device a request to set the functional lockout state of the client device to the lockout state. In this regard, in at least some embodiments, the request transmitted from the manufacturer system to the client device is specially configured based on the functional lockout state, i.e., the desired value of the lockout state, or otherwise includes data indicating that the functional lockout state is to be set to the lockout state.

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

[0124] In some embodiments, one or more of the operations shown with respect to FIG. 4B occur in addition to and / or instead of one or more of the 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. In addition to or instead of this, as depicted, in some embodiments, upon completion of the operations depicted with respect to FIG. 4B, the flow returns to block 308 as depicted and described with respect to FIG. 3. In other embodiments, it should be understood that one or more other processes and / or sub-processes may begin after and / or upon completion of one or more of the operations depicted and described with respect to FIG. 4B.

[0125] At block 452, apparatus 200 includes means such as device lockout management module 210, communication module 208, input / output module 206, processor 202, and / or the like, or combinations thereof, for transmitting a device lockout request to a third-party system associated with the client device, where the third-party system includes a carrier system. In some embodiments, the carrier system communicates with a manufacturer system associated with the client device, where the manufacturer system is capable of communicating with the client device to set the functional lockout state to a desired value, such as a locked-out state. In some embodiments, apparatus 200 and the carrier system communicate over one or more communication networks (s), such as the Internet. In addition to or instead of this, 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, such as the Internet, and / or one or more other communication networks.

[0126] In some embodiments, the carrier system is configured to cause the manufacturer system to set the functional lockout state of the client device to a lockout state in response to receiving a device lockout request. 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 to the manufacturer system one or more specially configured requests corresponding to the device lockout request. In this regard, when a device lockout request is sent to the carrier system, an electronic lockout of the client device is indirectly initiated through the manufacturer system. The electronic lockout is indirectly controlled by the device 200 through communication with one or more third-party systems.

[0127] FIG. 5 shows additional operations of an exemplary process for secure device lockout management to process claims to determine whether to approve the claims and, based on the determination of whether to approve the claims, cause an update to the functional lockout state of the client device, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system implemented by, for example, the device 200 described and explained above. The device 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as described and explained below. For example, in at least some embodiments, the device 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

[0128] In some embodiments, one or more of the operations shown with respect to FIG. 5 occur in addition to and / or instead of one or more of the operations of another process. For example, as depicted, in some embodiments, FIG. 5 begins after block 306, as depicted and described with respect to FIG. 3. In addition to or instead of this, as depicted, in some embodiments, upon completion of the operations described with respect to FIG. 5, the flow returns to another operation of the associated process. In other embodiments, it should be understood that one or more other processes and / or sub-processes may begin after and / or upon completion of one or more of the operations described and explained with respect to FIG. 5.

[0129] In block 502, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for receiving user claim information associated with a claim within a first time stamp interval. The user claim information can embody one or more data values for use in processing the claim, such as evidence data and / or descriptive data associated with the claim. For example, some or all of the user claim information can include data describing an event leading to the claim (e.g., a description of how a device was damaged, lost, stolen, etc.), data associated with subsequent actions taken by the user in response to the event (e.g., whether one or more device location information applications were launched), and / or the like. In some embodiments, for example, the first time stamp interval embodies a threshold claim start period during which the user claim information is received to enable processing of the claim. In some embodiments, the apparatus 200 stores and / or otherwise pre-determines the first time stamp interval. Alternatively, or in addition, in some embodiments, the apparatus 200 determines the first time stamp interval based on received data and / or otherwise data accessible to the apparatus 200, such as, 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, of previously received data associated with the claim to be processed.

[0130] In decision block 504, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for determining whether to approve a claim. In some embodiments, the determination of whether to approve a claim is based at least on 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 a user device. In addition to or instead of this, the determination may be based at least on a device protection program associated with the claim, a device protection program represented by a predefined rule set. For example, in this regard, the predefined rule set can define the data values that need to exist in the data received to approve a claim. Thus, in some embodiments, the apparatus 200 is configured to compare some or all of the user claim information and / or previously received data with a 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, if one or more of the rules within the predefined rule set are satisfied, the claim is determined to be approved. In some other embodiments, if the apparatus 200 determines that all of the rules within the predefined rule set are satisfied, the claim is determined to be approved.

[0131] In some embodiments, in a situation where the device 200 determines that the claim is not approved, the flow proceeds to any block 506. In any block 506, 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 combinations thereof, for setting the claim status of the claim to a rejection status. In this regard, the rejection 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 rejection status indicates that at least one rule of a predefined set of rules is not satisfied, or in other embodiments, that all rules of a predefined set of rules are not satisfied. Accordingly, the claim is not fulfilled. In this regard, the user may not receive a new device, a replacement device, a repair, a discounted device, etc. In some embodiments, for example, in a situation where the device 200 determines that a claim should not be approved based on the processing of previously received data and / or the comparison of the data with a predefined set of rules, the claim status of the claim is set to a rejection status, where, for example, such processing and / or comparison(s) indicate unauthorized and / or other actions that are not subject to the device protection program.

[0132] In block 508, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, to cause the functional lockout state of the client device to be set to an unlocked state. In some embodiments, by setting the functional lockout state to an unlocked state, the apparatus 200 is configured to cause the termination of the electronic lockout of the client device such that the client device returns to a fully accessible state. By enabling access to the full set of functions, the apparatus 200 prevents access to the client device for a limited time while a claim is being processed and, when it is confirmed that the client device has been removed from legitimate ownership (e.g., loss is confirmed or it is sent back for repair and / or replacement under a device protection program), the client device returns to full functionality for use by the user in the situation in which it is found and / or owned, thus minimizing the likelihood that the user is locked out of functions in situations where the user desires access to such functions.

[0133] Device 200 can be configured to set the functional lockout state to the 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 a device unlock request and / or transmit it 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 functional lockout state to the 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 a device unlock request and / or transmit it 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 functional lockout state of the client device to the unlocked state.

[0134] In some embodiments, the device unlock request is embodied by and / or 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 functional lockout state of the client device can be set permanently with respect to the submitted claim and, thus, can remain in the unlocked state until a new claim is initiated for the client device (if initiated). Thus, the third-party provider can cancel a timer or other pending action with respect to the processing of the claim and / or close out an internally stored case associated with the claim rejected by device 200.

[0135] Returning to decision block 504, in some embodiments, if the device 200 determines that the claim is approved, the flow proceeds to any block 510. At any block 510, 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 combinations thereof, to set 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 set of rules is satisfied, or in other embodiments, all rules of a predefined set of rules are satisfied. Accordingly, the claim proceeds to be fulfilled. In this regard, the 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 a situation where the device 200 determines that a claim should be approved based on the processing of previously received data and / or the comparison of the data with a predefined set of rules, the claim status of the claim is set to the approved status, where such processing and / or comparison(s) indicate actions subject to the device protection program.

[0136] In block 508, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, to keep the functional lockout state of the client device set to the locked state. In some embodiments, by setting the functional lockout state to the locked state, the apparatus 200 is configured to continue the electronic lockout of the client device such that the client device remains configured to be accessible only to a restricted set of functions. By continuing the electronic lockout, the apparatus 200 prevents access to the client device in situations where, for example, the device has been determined to be out of the possession of a legitimate user and / or removed from the possession of a legitimate user, such as for purposes of replacing and / or repairing the client device (e.g., when loss or theft of the client device has been confirmed and / or when it is returned for repair and / or replacement under a device protection program). In this regard, in situations where the received data sufficiently indicates that the client device is not in the possession of a legitimate user, the apparatus 200 is configured to render the client device inaccessible.

[0137] The device 200 can be configured in any of a number of ways such that the functional lockout state remains set to the lockout state. In some embodiments, the device 200 does not perform operations that would cause the client device to remain in the lockout state. Instead of or in addition to this, in some embodiments, the device 200 is configured to send one or more transmissions to a third-party provider to keep the functional lockout state of the client device set to the lockout state. In this regard, in some embodiments, the device 200 generates and / or sends a claim approval notification data object to keep the functional lockout state of the client device set to the lockout state. The claim approval notification data object can 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 lockout state if it has not already been set. In this regard, the third-party provider can generate and / or send one or more transmissions to the client device to set the functional lockout state to the lockout state if the third-party provider determines that the client device has not previously been successfully set to the lockout state. In addition to or instead of this, in some embodiments, the third-party provider does not perform an action in situations where the client device is determined to have previously been set to the lockout state. In addition to or instead of this, in some embodiments, the device 200 sends data, such as for example a claim approval notification data object, to the third-party provider to cause the third-party provider to update an internal case that the third-party provider manages to an approved status and / or otherwise close the internal case associated with the client device as approved by the device 200.

[0138] Figure 6A shows additional operations of an exemplary process for secure device lockout management to process claims to determine whether to approve a claim and, based on the determination of whether to approve the claim, cause an update to the functional lockout state of a client device, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system embodied by, for example, the device 200 described and explained above. The device 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations as described and explained below. For example, in at least some embodiments, the device 200 communicates with at least one third party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

[0139] In some embodiments, one or more of the operations shown with respect to Figure 6A occur in addition to and / or instead of one or more of the operations of another process. For example, as described, in some embodiments, Figure 6A begins after block 306 as described and explained with respect to Figure 3. In addition or alternatively, as described, in some embodiments, upon completion of the operations described with respect to Figure 6A, the flow returns to another operation of the associated process. In other embodiments, it should be understood that one or more other processes and / or sub-processes can begin after and / or upon completion of one or more of the operations described and explained with respect to Figure 6A.

[0140] In block 602, apparatus 200 includes means such as device lockout management module 210, communication module 208, input / output module 206, processor 202, and / or the like, or combinations thereof, for receiving a claim termination request initiated by a user. In some embodiments, the claim termination request indicates that the user desires to abort and / or otherwise cancel a started 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 a particular device protection program, client device, and / or the like to be canceled. In at least some exemplary contexts, the claim termination request is initiated in situations such as where the user has changed their mind regarding claim submission or has found a lost device. It should be understood that the user may decide to terminate a claim for any of a number of reasons.

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

[0142] In any block 604, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for setting the claim status of the claim to a cancel status. In this regard, the cancel status indicates that the claim was not fully processed but was terminated by the user through user interaction. In at least one exemplary context, the cancel status indicates that the user has found the lost device and / or has decided to keep the damaged device rather than exchange and / or repair the device through a device protection program. In this regard, in some embodiments, the cancel status may indicate that, for example, the client device should return to a state where all functions are accessible because the user may own the client device and desire to utilize such functions.

[0143] In block 606, the apparatus 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 combinations thereof, to set the functional lockout state of the client device to an unlocked state. In some embodiments, by setting the functional lockout state to an unlocked state, the apparatus 200 is configured to cause the end of the electronic lockout of the client device such that the client device returns to a fully accessible state. By enabling access to the full set of functions of the client device, the apparatus 200 prevents access to the client device for a limited time while a claim is being processed and, when it is shown by the user that the claim is not being continued (e.g., using receipt of a claim end request initiated by the user), the client device returns to a fully accessible state such that the user can continue to use the client device with reduced interruptions. Similarly, by setting the functional lockout state to an unlocked state in response to a request initiated by the user, the apparatus 200 is configured to lock out some or all of the functions of the client device while the user indicates that there is at least a possibility that the client device is inaccessible to legitimate users, thus protecting against access by unauthorized and / or malicious users.

[0144] Device 200 can be configured to cause the functional lockout state to be set to the unlocked state in any of a number of ways, for example, via one or more transmissions to a third-party provider. For example, in some embodiments, device 200 is configured to generate a device unlock request and / or transmit it 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 functional lockout state to the 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 a device unlock request and / or transmit it 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 functional lockout state of the client device to the unlocked state.

[0145] In some embodiments, the device unlock request is embodied by and / or transmitted together with a claim cancellation notification data object. The claim cancellation notification data object can indicate to a third-party provider, such as a carrier system or a manufacturer system, that the claim has been fully processed. In this regard, the functional lockout state of the client device can be permanently set with respect to the submitted claim and thus can remain in the unlocked state until a new claim is initiated for the client device (if initiated). Thus, the third-party provider can cancel a timer or other pending action with respect to the processing of the claim and / or terminate an internally stored case associated with the claim of the client device that has been cancelled by the user in response to a transmission from device 200.

[0146] Figure 6B shows additional operations of an exemplary process for secure device lockout management to process claims to determine whether to approve a claim, and to cause an update to the functional lockout state of a client device based on the determination of whether to approve the claim, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system embodied, for example, by the apparatus 200 described and explained above. The 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 described and explained below. For example, in at least some embodiments, the apparatus 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

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

[0148] In block 652, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for determining that user request information associated with a claim has not been received within a first timestamp interval. In some embodiments, the first timestamp interval embodies a threshold case information period during which user request information is received to enable processing of the claim. In some embodiments, the apparatus 200 stores and / or otherwise pre-determines the first timestamp interval, for example, based 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 the user request information for the claim must be received within five days after the claim is initiated. Alternatively, or in addition, in some embodiments, the apparatus 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 otherwise data accessible to the apparatus 200, such as the claim type of the claim, the device protection program associated with the claim, the user settings associated with the user account of the claim, and / or the like. In some embodiments, the apparatus 200 may be configured to schedule a task for performing such a determination, for example, after the first timestamp interval has elapsed at the start of the claim. Alternatively, or in addition, in some embodiments, the apparatus 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 request information has been received if the current timestamp exceeds the first timestamp interval.

[0149] In any block 654, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for setting the claim status of a claim to a timeout status. In this regard, the timeout status indicates that the claim was aborted due to no user action regarding the claim, rather than being fully processed. In at least one exemplary context, the timeout status indicates that the user has abandoned continuing the fulfillment of the claim, whether intentionally or not. In this regard, in some embodiments, the timeout status may indicate that the client device should return to a state where all functions are accessible, for example, if the user has obtained the client device again or otherwise decided to retain the client device and wishes to utilize such functions, the user will be able to access such functions.

[0150] In block 656, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, to set the functional lockout state of the client device to an unlocked state. In some embodiments, by setting the functional lockout state to the unlocked state, the apparatus 200 is configured to cause the termination of the electronic lockout of the client device such that the client device returns to a fully accessible state. By enabling access to the full set of functions of the client device, the apparatus 200 prevents access to the client device for a limited time during which the user may be performing the task of providing data to the apparatus 200 for processing, and when a certain time stamp interval (predetermined or determined as a first time stamp interval) elapses, the apparatus 200 determines that the user is likely to have abandoned the claim and returns the client device to a fully accessible state, so that if the user has decided to obtain the client device again or otherwise continue to own the client device and has forgotten or otherwise ignored the claim that was initiated, the user can reduce the interruption and continue to use the client device. Similarly, by setting the functional lockout state to the unlocked state after the first time stamp interval, the apparatus 200 is configured to lock out some or all of the functions of the client device for at least a time sufficient for the user to submit the necessary data to the apparatus 200 for processing, and thus the client device is not unlocked at a time too early when it may be exposed to use by an unauthorized owner and / or malicious user, such as during a proper time frame for data submission.

[0151] Device 200 can be configured to cause the functional lockout state to be set to the unlocked state in any of a number of ways, for example, via one or more transmissions to a third-party provider. For example, in some embodiments, device 200 is configured to generate a device unlock request and / or transmit it 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 functional lockout state of the client to the 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 a device unlock request and / or transmit it 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 functional lockout state of the client device to the unlocked state.

[0152] In some embodiments, the device unlock request is embodied by and / or transmitted along with a billing timeout notification data object. The billing timeout notification data object can indicate to a third-party provider, such as a carrier system or manufacturer system, that the billing was not fully processed or was cancelled but aborted because it was determined to be abandoned by the initiating user. In this regard, the functional lockout state of the client device can be permanently set with respect to the submitted billing and thus can remain in the unlocked state until a new billing is initiated for the client device (if initiated). Thus, the third-party provider can end a timer or other pending action with respect to the processing of the billing and / or abort the internally stored case associated with the billing of the client device that timed out by the user based on the last transmission from device 200. Exemplary detailed secure device lockout management flow Figures 7, 8, 9, and 10 illustrate exemplary operations of an exemplary detailed process for secure device lockout management according to at least one embodiment of the present disclosure, particularly based on information from a particularly reliable third-party provider. In some embodiments, the described operations are performed, for example, by a device protection program management system embodied by the device 200 described and explained above. The device 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations as described and explained below. For example, in at least some embodiments, the device 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

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

[0154] In some embodiments, the case confirmation 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, in addition to or instead of this, the apparatus 200 may receive an authentication token, indicating that a 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 using one or more authentication processes. In a particular exemplary context, the trusted third - party provider requires the user to provide one or more user authentication credentials and then uses two - factor or multi - factor authentication (e.g., an email message, SMS, or text message to the associated user device, etc.) to verify the identity. The authentication token may be signed by the third - party provider so that embodiments of the present disclosure can verify the authentication token, for example, using public - key cryptography, and verify that the authentication token was issued by a trusted third - party provider. To enhance security, some embodiments perform additional security checks. For example, in some embodiments, the embodiment system associates the trusted third - party provider with one or more IP addresses, and the embodiment system is configured to verify that the received third - party case information was issued by a trusted third - party provider.

[0155] In any block 704, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations 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 that utilize a third-party case identifier. For example, in some embodiments the system utilizes 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 device identifiers (e.g., International Manufacturer Equipment Identity (IMEI), Internet Protocol (IP) address, 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 in association with the client device, whether the user attempted to access the device location application to find the client device, the last time the user accessed the device location resource to find the device, etc.). In addition to or instead of this, in some embodiments the third-party case information includes location information, status information of 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, whereby the third-party case information functions as a snapshot of all the information present on the client device at the time the user initiated the third-party case.Some embodiments are further configured to store a third - party case identifier and / or, alternatively, store invoice information associated with the third - party case identifier, such that the invoice information can be retrieved using the third - party case identifier. In addition to or instead of this, some embodiments store all, or part, or third - party case information such that the third - party case information can be retrieved using the third - party case identifier.

[0156] In some embodiments, obtaining third - party case information is based on a previously received third - party case identifier. In this regard, minimal information (e.g., the third - party case identifier and / or an authentication token) can be passed from a trusted third - party provider to the device 200 in a first communication between the trusted third - party provider and the device 200, for example, using a redirect of the user device from the trusted third - party provider to the device 200 and while rendering a user interface associated with access to the functions of the device 200 on the user device. By transmitting minimal information, the communication time between the trusted third - party provider and the device 200 is improved, and the receipt and start of processing of the third - party case identifier(s) is minimized. In addition to or instead of this, by minimizing the amount of information transmitted at an initial stage, the information can be protected at a basic level of security in an encrypted manner, and the risk of significant vulnerabilities due to exposing important data with basic security measures can be minimized. The device 200 can then retrieve the third - party case information using a security - enhanced process, e.g., one or more APIs provided by a 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 first case confirmation information, the overall data security of the process is improved by reducing the likelihood of successful interference by a malicious user. In some further embodiments, the third - party case information is received together with the case confirmation information at a previous step, e.g., block 702.

[0157] In any block 706, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for identifying a client device identifier associated with third-party case information. In this regard, the client device identifier can uniquely identify the client device on which the user initiated the claim start 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 from case confirmation information received in a previous step, e.g., block 702. In some such embodiments, the apparatus 200 is configured to extract and / or otherwise analyze the client device identifier from the case confirmation information.

[0158] In any block 708, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for transmitting a case reception response to a trusted third-party provider. In some embodiments, the case reception response causes the trusted third-party provider to initiate a lockout of the client device, or otherwise maintain a potential lockout of the client device initiated by the trusted third party when the user acknowledges that the device has been lost or stolen and the user desires fulfillment of the claim, prior to transmitting case confirmation information, such that the client device is inoperable or otherwise inaccessible until a future status change indicating that access to the device should be restored (e.g., a claim status update notification data object) is transmitted by the 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 unresponsive or non-responsive to user engagement indefinitely.

[0159] In block 710, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for determining whether user case information is received within a threshold claim start period. In some embodiments, the case reception response is also configured to present to the user an interface configured and / or provided by the apparatus 200 to initiate a claim start process, for example, by submitting user case information using a user device. For example, the user may be provided with, redirected to, or otherwise have access to a user case information collection interface configured to enable the user to input and / or submit user claim information. The user claim information includes, in some embodiments, at least one or more from a group including a date of an event (e.g., when a client device was lost or stolen), a description of the event, user event 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 can only be maintained in an accessible state for a determined or pre-determined threshold claim start period if no claim associated with the third-party case is filed, for example, for using the device 200 to submit information. For example, in the system of a particular embodiment, the device 200 may provide a function that enables a user to access the submitted user case information associated with the received third-party case information, within a limited time that waits for the user to submit the first user case information to open the third-party case. In at least one exemplary embodiment, the threshold claim start period represents one day (24 hours). In a situation where the device 200 determines that the user has not submitted user case information within the threshold claim start period, the device 200 can send information to cause a reliable third-party provider to close the case. In this regard, based on the lack of action by the user, the device 200 can determine that the user is no longer proceeding with the fulfillment of the claim associated with the client device using the device 200. In some embodiments, also, the device 200 may be configured to delete or otherwise make inaccessible information associated with the third-party case being closed, such as the third-party case identifier and / or third-party case information associated with the third-party case identifier. Thus, if user case information is not received within the threshold claim start period, a reliable third party can end the lockout associated with the client device so that the client device returns to a functional form. Alternatively or in addition to this, in some embodiments, the device 200 can cause a reliable third-party provider to end the lockout associated with the client device, for example, through one or more transmissions described herein. For example, in at least one embodiment, the device 200 is configured to send a device unlock request and / or a claim timeout notification data object, and / or a similar data object to a reliable third-party provider to cause a lockout of the client device.In some embodiments, when the browser is closed or the session with the device 200 is otherwise terminated, the device 200 determines that user case information has not been received within a threshold claim start period and can thus transmit information to cause the case to be terminated and / or the client device to be unlocked without submitting a claim. In some embodiments, a trusted third-party provider can maintain its own timer, such as 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 the device 200 provides an indication that the claim has started successfully, the trusted third-party provider automatically causes the end of the client device's lockout.

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

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

[0163] In block 716, the apparatus 200 includes means such as, for example, a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for generating a claim based at least in part on received case confirmation information and / or received user case information. For example, a client device may subscribe to or otherwise register with a device protection program associated with specific claim parameters and / or requirements embodied by a predefined set of rules. In some such embodiments, a client device may subscribe to multiple device protection programs, each of which may target any number of claim types. In this regard, user case information and / or information received from a trusted third-party provider may include device protection program identifiers, claim types, and / or the like. In some embodiments, based on the various information provided, a claim may be generated in relation to an 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, the claim may be approved if the claim parameters meet the requirements of the device protection program as described herein. In some embodiments, if the values provided for the claim parameters are incomplete or insufficient, the apparatus 200 may otherwise reject the claim or request additional information.

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

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

[0166] In some embodiments, the claims 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 indicating that the user must submit one or more claim waivers, claim forms, etc. associated with the claim. In addition to, or instead of, this, in some embodiments, the claim requirement data may indicate that the user must provide supplementary claim information to the device 200 in order to enable the claim to be fully processed.

[0167] In some embodiments, the device 200 is configured in relation to a claim completion period associated with receiving claim requirement data from the user after claim generation. For example, in some embodiments, if the user does not submit all the claim requirement data to the device 200 within a determined or pre-determined threshold claim completion period (e.g., 30 days), the device 200 is configured to abort the claim because the action by the user is insufficient. Thus, in some embodiments, the device 200 transmits a notification data object, such as a claim timeout notification data object, to a reliable third-party provider. In some embodiments, the claim timeout notification data object is configured to cause the reliable third-party provider to set the case status associated with the third-party case to a case cancellation 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 the case cancellation / timeout status, the reliable third-party provider may then terminate the lockout of the client device associated with the case so that the client device returns to a functional state.

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

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

[0170] Figure 8 shows additional operations of an exemplary detailed process for secure device lockout management for processing a claim as a timeout, particularly based on the absence of user action, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system embodied, for example, by the device 200 described and explained above. The device 200 can communicate with one or more other devices, systems, servers, and / or the like to perform one or more of the operations, as described and explained below. For example, in at least some embodiments, the device 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

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

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

[0173] In block 804, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for transmitting 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 a trusted third-party provider to terminate a lockout from a client device. For example, as described herein, the claim timeout notification data object can be configured to cause a trusted third-party provider to communicate directly with a client device, such as when the trusted third-party device embodies a manufacturer system. In addition to or instead of this, in some embodiments, the claim timeout notification data object is configured to communicate with a manufacturer system configured to set a functional lockout state of a client device using one or more communications to a trusted third-party provider. In addition to or instead of this, in some embodiments, the apparatus 200 is configured to transmit a claim timeout notification data object to cause a trusted third-party provider to set one or more case statuses of a third-party case associated with a claim to a timeout status.

[0174] Figure 9 shows additional operations of an exemplary detailed process for secure device lockout management, in particular for processing received claim requirement data and setting an appropriate lockout state, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system implemented, for example, by the device 200 depicted and described above. The device 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, the device 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

[0175] In some embodiments, one or more of the operations shown with respect to Figure 9 occur in addition to and / or instead of one or more of the operations 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. In addition to or instead of this, as depicted, in some embodiments, upon completion of the operations described 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 and / or upon completion of one or more of the operations described and explained with respect to Figure 9.

[0176] In block 902, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for determining whether a claim is admissible or, in other words, approved. In some embodiments, the apparatus 200 is configured to determine whether a claim is admissible 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, the apparatus 200 is configured to compare claim requirement data with a predefined set of rules embodying a device protection program to determine whether the claim requirement data meets the predefined set of rules. In some such situations, the apparatus 200 is configured to determine that a claim is admissible in a situation where the claim requirement data meets the predefined set of rules embodying a device protection program, and otherwise determine that the claim is not admissible.

[0177] In some embodiments, in the situation where the apparatus determines that the claim is allowable, the flow proceeds to any block 908. In any block 908, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for approving the claim. In addition to, or instead of, this, in at least some exemplary embodiments, the apparatus 200 is configured to perform one or more operations to satisfy the claim. For example, the apparatus 200 can set a claim status associated with the claim indicating that the claim has been approved, such as by setting the claim status to an approved status value. In addition to, or instead of, this, the apparatus 200 can initiate one or more actions associated with sending a replacement device to the user, for example, using a system and / or a warehouse associated with the apparatus 200, or using a reliable third-party provider and / or an associated system. In addition to, or instead of, this, to fulfill the claim, the apparatus 200 can, for example, provide information to the user using a user device associated with the user, enabling the user to initiate an exchange, repair, and / or similar process with respect to the client device from which the claim was submitted.

[0178] In block 910, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for transmitting the 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 continued electronic lockout of the client device. In some embodiments, the claim approval notification data object is configured to cause a 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 receipt of the claim approval notification and / or in response to an update of the case status to a third-party case indicating that the claim has been approved, the trusted third-party provider can continue to lock out the client device associated with the case, whereby the client device remains permanently inoperable, non-functional, or otherwise inaccessible. In some embodiments, no action is required to continue the lockout of the client device. In other embodiments, one or more requests are sent directly or indirectly to the client device, e.g., through the manufacturer system, to keep the client device in a permanently locked-out state.

[0179] Returning to block 902, in a situation where it is determined that the claim is not approvable, the flow continues to any block 904. In some embodiments, the claim can be determined not to be approvable in a situation where the processed data is insufficient, fraudulent, or otherwise determined to be non-approveable. For example, the apparatus 200 can be configured to determine that the claim is non-approveable because the submitted claim requirement data does not meet the claim requirements represented by a predefined rule set of the device protection program.

[0180] In any block 904, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for rejecting a claim. For example, the apparatus 200 can set a claim status associated with a claim indicating that the claim has been rejected, for example, by setting the value of the claim status to a claim rejection status. In this regard, the claim rejection status can indicate that the claim has been fully processed and will not be performed. In this regard, the rejected claim status can further indicate that the client device will not be repaired and / or replaced based on the device protection program, and thus, in order to minimize data inaccessibility and / or user dissatisfaction, it may be best to unlock the functions of the client device.

[0181] In block 906, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or a combination thereof, for transmitting a claim rejection notification data object case to a trusted third-party provider. In some embodiments, the claim rejection notification data object is configured to cause a trusted third-party provider to terminate an electronic lockout from the client device. In some embodiments, the claim rejection notification data object is configured to cause a trusted third-party provider to set a case status associated with the third-party case to a value such as "Claim Denied" indicating that a claim associated with the third-party case has been rejected. In response to receipt of the claim rejection notification data object and / or in response to an update of the case status to a status indicating that a claim associated with the third-party case has been rejected, the trusted third-party provider can end the lockout of the client device associated with the case, whereby the client device returns to an appropriately functioning state.

[0182] During processing as shown in FIGS. 7, 8, and 9, it should be understood that the apparatus can be configured to receive a cancellation initiated by the user of the initiated claim. In this regard, the apparatus 200 can be configured to provide a process as illustrated and described with respect to FIG. 6A in parallel with one or more operations as depicted and described with respect to FIGS. 7, 8, and / or 9. In addition to or instead of this, in some embodiments, the process as depicted and described with respect to FIG. 6A occurs after one or more of the blocks executed in the process depicted and described with respect to FIGS. 7, 8, and / or 9.

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

[0184] In some embodiments, the apparatus 200 cancels a claim, for example, by setting a claim status to a claim cancellation status as described, and / or causes cancellation of a corresponding third-party case, for example, through one or more transmissions to a reliable third-party provider. In some embodiments, upon completion of a claim and / or a third-party case, the apparatus 200 deletes, cancels, and / or otherwise makes inaccessible all stored information associated with the claim and / or the third-party case, and / or causes a reliable third party to delete, cancel, and / or otherwise make inaccessible all stored information associated with the third-party case. In addition to or instead of this, in some embodiments, the apparatus causes an end to an electronic lockout of a client device associated with a claim upon cancellation of the claim by a user. Exemplary Operations for Device Lockout Status Verification FIG. 10 shows exemplary operations of secure device lockout management, particularly for device lockout status verification, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a device protection program management system implemented by the apparatus 200 described and explained above. The 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 described and explained below. For example, in at least some embodiments, the apparatus 200 communicates with at least one third-party provider, such as a carrier system and / or a manufacturer system, and / or a client device.

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

[0186] In block 1002, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for sending at least one request intended to cause the apparatus to set the functional lockout state of the client device to the intended functional lockout state. In some embodiments, the operations occur as described in one or more blocks of another process described herein, for example, block 310 of FIG. 3, block 402 of FIG. 4A, block 452 of FIG. 4B, blocks 508 and / or 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 send such transmissions to cause the initiation and / or termination of an electronic lockout of the client device. For example, if the intended functional lockout state represents a lockout state, such a transmission can be intended to cause the initiation of an electronic lockout. Similarly, if the intended functional lockout state represents an unlocked state, such a transmission can be intended to cause the termination of an electronic lockout.

[0187] In some exemplary contexts, such transmissions may be ineffective due to any of a number of errors. For example, in at least one exemplary context, the transmission may not reach the third-party provider due to an incomplete and / or broken connection between device 200 and the third-party provider. Instead of, or in addition to, this, in at least some exemplary contexts, the transmission may not reach the manufacturer system due to an incomplete and / or broken connection between a third-party provider, such as a carrier system, and the manufacturer system. In addition to, or instead of, this, furthermore, in at least some exemplary contexts, the transmission may not reach the 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 functional lockout state of the client device, the client device may not be successfully set to the intended functional lockout state based on an attempt to transmit at least one request.

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

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

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

[0191] In decision block 1010, the apparatus 200 includes means such as a device lockout management module 210, a communication module 208, an input / output module 206, a processor 202, and / or the like, or combinations thereof, for determining whether the current data value represents an intended functional lockout state. In at least one exemplary context, the current data value of the functional lockout state of the client device indicates whether the electronic device is currently under the influence of an electronic lockout. For example, in at least one exemplary context, the current data value may represent the lockout state in a situation where the client device is currently under the influence of an electronic lockout. Similarly, in at least one exemplary context, the current data value may represent the unlocked state in a situation where the client device is not currently under the influence of an electronic lockout. In this regard, in some embodiments, the apparatus 200 may be configured to compare the current data value of the client device received at block 1008 with the value of the intended functional lockout state to determine whether the current data value represents the intended functional lockout state. In some such embodiments, in a situation where the current data value represents the intended functional lockout state, the apparatus 200 determines that the intended functional lockout state is properly set. Similarly, in some such embodiments, in a situation where the current data value does not represent the intended functional lockout state, the apparatus 200 determines that the intended functional lockout state is not properly set.

[0192] In a situation where the apparatus 200 determines that the current data value represents the intended functional lockout state and / or the intended functional lockout state is properly set, the flow may end. Alternatively, in at least one exemplary embodiment, the apparatus 200 can perform one or more additional actions based on the determination. For example, in at least one embodiment, the apparatus 200 can mark one or more indicators indicating that the apparatus 200 has verified the current functional lockout state of the client device as correct.

[0193] When returning to decision block 1010, in situations where the device 200 determines that the current data value does not represent the intended functional lockout state and / or the intended functional lockout state is not properly set, the flow can proceed to block 1012. At block 1012, the device 200 includes means such as the device lockout management module 210, communication module 208, input / output module 206, processor 202, and / or the like, or combinations thereof, for sending at least one second request intended to cause the setting of the functional lockout state of the client device to the intended functional lockout state. In this regard, the at least one second request can represent a second attempt to be executed by the device 200 when setting the intended functional lockout state. In this regard, the device 200 can similarly attempt to send the at least one second request to a third-party provider such as a carrier system and / or a manufacturer system that communicates with the client device, for example, over one or more communication networks. After sending and / or sending the at least one second request, the flow can return to any block 1004. In some such embodiments, the time stamp interval of the status request may increase (e.g., multiplied by a factor such as two or otherwise increased uniformly) each time it repeats. In this regard, the flow can continue through the cycles embodied by the various depicted and described blocks until, for example, at decision block 1010, the device 200 determines that the current data value of the functional lockout state of the client device represents the intended functional lockout state. In this regard, the device 200 may be configured to ensure that the client device has been set to the intended functional lockout state, thereby confirming that the electronic lockout is initiated if desired and terminated if not desired.Therefore, the apparatus 200 can reduce the possibility that the client device remains in an inappropriate functional lockout state, for example, in a situation where the electronic lockout has not been properly set due to an error, reducing the chance for an unauthorized user to access the functions of the client device, and / or reducing the frustration of the user being locked out from functions via the client device in a situation where the electronic lockout has not been properly terminated due to an error. The described and illustrated process provides such advantages without additional processing by the client device, thus saving the computing resources of the client device. Exemplary Secure Device Lockout Management Flow Executed by a Third-Party Provider FIG. 11 shows an exemplary process for secure device lockout management according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a third-party provider system, such as a carrier system and / or a manufacturer system, embodied by, for example, the apparatus 250 described and illustrated above. The 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 described and illustrated below. For example, in at least some embodiments, the 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, apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for receiving a client device event data object associated with a client device, and the client event data object includes a case start 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 transmit a client device event data object to initiate a claim process associated with the client device. In some embodiments, the client device event data object includes, for example, one or more client device failure 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 start request includes at least a client device identifier associated with the client device such that, for example, apparatus 250 can uniquely associate the received data with a particular client device using the client device identifier. In addition to or instead of this, in some embodiments, apparatus 250 is configured to generate a third-party case in response to the case start request, for example, based at least on the received client device event data object. In addition to or instead of this, in some embodiments, apparatus 250 is configured to authenticate a user associated with the received client device event data object. For example, in some embodiments, apparatus 250 is configured to provide one or more user authentication processes that enable apparatus 250 to verify the identity of the user.Non-limiting examples of such processes include login using user qualification information (e.g., username and password), verification through a device associated with a known user (e.g., two-factor authentication via a separate device or channel), or combinations thereof.

[0195] In block 1104, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for transmitting an electronic data signal to the client device. The electronic data signal may be specially 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 functional lockout state of the client device to a lockout state. In some exemplary contexts, it should be understood that the electronic data signal is transmitted directly to the client device, for example, via one or more communication 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, for example, using a manufacturer system configured to cause an electronic lockout. In some such embodiments, the electronic data signal may be transmitted to the manufacturer system, for example, through one or more APIs.

[0196] In block 1106, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or a combination thereof, for sending case confirmation data to a device protection program management system. In some such embodiments, the case confirmation data is at least partially based 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, the client device identifier, the claim type, the device protection program identifier, and / or a combination thereof. In this regard, the claim type may be based on whether a corresponding client device failure data object or client device loss data object was received from the user such that the corresponding claim type is sent within the case confirmation data. In some such embodiments, the claim confirmation data may be used by the device protection program management system when initiating a claim associated with the client device.

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

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

[0199] Figure 12 shows additional operations of an exemplary process for secure device lockout management, particularly for ending an electronic lockout based on a drop dead timer, according to 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 maker system, embodied by, for example, the apparatus 250 described and explained above. The 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 described and explained below. For example, in at least some embodiments, the 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 maker system.

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

[0201] In block 1202, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or a combination thereof, for starting a drop dead timer for a predetermined period. In this regard, the drop dead timer may represent the time stamp interval until it is determined that the case has been abandoned. To minimize the impact when the user abandons the case, for example, if the user forgets a pending case and later recovers a device that has been lost or stolen, the client device needs to unlock and enable the functions of the client device to be accessed by the user. Thus, in some embodiments, the predetermined period may be specifically determined based on a reasonable time that allows the user to submit initial user case information for starting a claim. In some embodiments, the predetermined period represents the threshold claim start period of an associated device protection program management system.

[0202] In block 1204, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or a combination thereof, for determining that no claim status update has been received within a predetermined period. In this regard, the apparatus 250 may be configured to track, for example, a drop-dead timer that performs periodic checks to determine whether a claim status update has been received from the device protection program management system. In addition to or instead of this, 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 when the drop-dead timer expires (e.g., after a predetermined period). If a claim status update notification data object is received within a predetermined period (e.g., before the drop-dead timer expires), the apparatus may be configured to cancel and / or end the drop-dead timer. In this regard, in some embodiments, the apparatus 250 determines that no claim status update notification data object has been received within a predetermined period without cancellation and / or other termination by the apparatus 250 after the drop-dead timer has expired. This determination may indicate that the user has abandoned the initiation of a claim via the device protection program management system.

[0203] In block 1206, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for transmitting an electronic data signal to a 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 functional lockout state of the client device to an unlocked state. By ending the electronic lockout of the client device, the client device returns to its normal functions, whereby the user can access such functions and abandon the initiation and / or processing of the claim. Restoration of such functions is advantageous for protecting access to the data of the client device in the event of loss or otherwise being removed from the possession of a legitimate user, but if the user locates or otherwise decides to retain the client device and thus abandons the claim, the user desires access to utilize such functions of the client device. In some exemplary contexts, it is to be understood that the electronic data signal is transmitted directly to the client device, for example, via one or more communication 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, for example, using a manufacturer system configured to cause an electronic lockout. In some such embodiments, the electronic data signal can be transmitted to the manufacturer system, for example, through one or more APIs.

[0204] Figure 13 shows additional operations of an exemplary process for secure device lockout management for executing a device lockout update action, particularly based on at least claim status update data objects, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a third-party provider system such as a carrier system and / or a manufacturer system, embodied, for example, by the apparatus 250 described and explained above. The 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 described and explained below. For example, in at least some embodiments, the 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 operations shown with respect to Figure 13 occur in addition to and / or instead of one or more of the operations of another process. For example, as described, in some embodiments, Figure 13 begins after block 1108 as described and explained with respect to Figure 11. In addition to or instead of this, as described, in some embodiments, upon completion of the operations described with respect to Figure 13, the flow ends. Instead of or in addition to this, in other embodiments, it should be understood that one or more other processes and / or sub-processes may begin after and / or upon completion of one or more of the operations described and explained with respect to Figure 13.

[0206] In block 1302, apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for determining the value of the received claim status update notification data object. In this regard, the value of the received claim status update notification data object may represent the type of the received claim status update notification. In this regard, 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 illustrated, in a situation where apparatus 250 determines that the claim status update notification data object includes a claim rejection notification data object, the flow continues to block 1304. In block 1304, apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for terminating the electronic lockout of the client device. For example, in some embodiments, to terminate the electronic lockout of the client device, apparatus 250 is configured to transmit one or more specially configured electronic data signals to the client device to set the functional lockout state of the client device to an unlocked state. In this regard, apparatus 250 may be configured to terminate the electronic lockout directly through communication with the client device, for example, in a situation where apparatus 250 embodies a manufacturer system, or indirectly through communication with the manufacturer system, for example, in a situation where apparatus 250 embodies a carrier system.

[0208] In addition to, or alternatively to, optionally, in some embodiments, the flow proceeds to block 1304 in a situation where the claim status update notification data object includes a claim cancellation notification data object. In this regard, the claim cancellation notification data object indicates that the user has actively cancelled a claim that was initiated, and further indicates that the user has found a client device that was lost and / or stolen and / or has otherwise decided to retain the client device. In such a situation, ending the electronic lockout of the client device enables the restoration of the functions of the client device for the user to access.

[0209] In a situation where the device 250 determines that the claim status update notification data object includes the claim permission notification data object, the flow proceeds to block 1306. In block 1206, the device 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for continuing the electronic lockout of the client device. In this regard, by continuing the electronic lockout, the accessible functions of the client device remain restricted. For example, since the replacement and / or repair of the client device is permitted, it must be removed from the user's possession. In this regard, by continuing the electronic lockout of the client device, the device 250 strengthens the security of the data accessible using the client device by preventing access to the data and other functions by unauthorized, otherwise unintended, and / or malicious users. As described herein, it should be understood that in some embodiments, the device 250 does not perform additional steps for continuing the electronic lockout of the client device. Instead of or in addition to this, the device 250 can update the case status associated with the claim to indicate that the claim has been finally resolved and that the functional lockout state of the client device remains permanent. In addition to or instead of this, the device 250 can transmit one or more electronic data signals to the client device using one or more other third-party providers (plural), for example, using a manufacturer device, either directly or indirectly.

[0210] Figure 14 shows additional operations of an exemplary process for secure device lockout management, particularly for providing information to a device protection program management system, according to at least one exemplary embodiment of the present disclosure. In some embodiments, the described operations are performed by a third-party provider system, such as a carrier system and / or a manufacturer system, embodied by, for example, the apparatus 250 depicted and described above. The 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, the 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 operations shown with respect to Figure 14 occur in addition to and / or instead of one or more of the operations of another process. For example, as depicted, in some embodiments, Figure 14 begins after block 1102, as depicted and described with respect to Figure 11. In some embodiments, for example, as depicted, when the operations depicted and described with respect to Figure 14 are complete, the flow returns to one or more of the operations depicted with respect to Figure 11. In addition or alternatively, as depicted, in some embodiments, at the completion of the operations depicted with respect to Figure 14, the flow ends. Alternatively or in addition, in other embodiments, it should be understood that one or more other processes and / or sub-processes can begin after and / or at the completion of one or more of the operations depicted and described with respect to Figure 14.

[0212] In block 1402, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a 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, a portion of the stored information includes at least the client identifier of the client device. In some embodiments, the apparatus 250 creates and stores a third-party case, including at least a portion of the information, in one or more data stores managed by the apparatus 250, for example. In this regard, the third-party case may include information associated with the processing of the information received by the user and may be generated 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 apparatus 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 apparatus 250 has successfully verified the identity of the user through one or more authentication processes.

[0213] In block 1404, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or a combination thereof, for receiving a case information request from a device protection program management system. The case information request may include one or more identifiers, such as a third-party case identifier, when the user retrieves information utilized by the device protection program management system to initiate 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. In addition to or instead of this, in some embodiments, the case information request includes an authentication token transferred from the apparatus 250 to the device protection program management system.

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

[0215] In block 1408, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or a combination thereof, for transmitting a portion of the case information to a device protection program management system. In some embodiments, a portion of the case information is transmitted to the device protection program management system in response to the case information request. Such case information can 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., for generating a claim) and / or for processing a claim (e.g., for determining whether a claim satisfies a predetermined set of rules that embody a device protection program).

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

[0217] In any block 1412, the apparatus 250 includes means such as a third-party case lockout management module 260, a communication module 258, an input / output module 256, a processor 252, and / or the like, or combinations thereof, for sending a use case to a device protection program management system. In this regard, the use case information can be sent 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 a specific third-party case identifier. The use case information can be processed by the device protection program management system, for example, for use in initiating a claim based on the use case information. In this regard, the use case information can include a claim type, a device protection program identifier, and / or the like. In some embodiments, in addition to or instead of this, it should be understood that the device protection program management system can be caused to store the use case information for future processing by transmission. Upon receiving the use case information, the device protection program can generate a claim and / or access data sufficient to initiate processing of the claim. In some such embodiments, the apparatus 250 can return to one or more operations as shown in FIG. 11, for example, to process a claim status notification data object subsequently received 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 in this specification can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, or combinations of one or more of them, including the structures disclosed in this specification and their structural equivalents.

[0218] Embodiments of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, hardware, or combinations of one or more of them that include the structures disclosed in this specification and their structural equivalents. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs encoded on at least one computer storage medium for execution by, or to control the operation of, a data processing apparatus, i.e., as one or more modules of computer program instructions. Alternatively, or in addition, the program instructions can be encoded in an artificially generated propagated signal, e.g., an electrical, optical, or electromagnetic signal generated by a machine that encodes information / data for transmission to a suitable receiver apparatus for execution by an information / data processing apparatus. The computer storage medium can be, or can 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 them. Further, the computer storage medium can be, but need not be, a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or can be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0219] The operations described in this specification can be implemented as operations executed by an information / data processing apparatus on information / data stored on or received from one or more computer-readable storage devices.

[0220] The term "data processing apparatus" includes, by way of example, any kind of apparatus, device, and machine for processing data, including a programmable processor, a computer, a system-on-chip, or a plurality or combination of the foregoing. The apparatus can include dedicated logic circuitry, such as, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit). The apparatus can also include, in addition to hardware, code for creating an execution environment for the computer program in question, such as, for example, processor firmware, a protocol stack, a repository management system, an operating system, a cross-platform runtime environment, a virtual machine, or code for constructing one or more combinations thereof. The apparatus and the execution environment can implement various 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 languages, declarative languages, or procedural languages, and can be deployed in any form, including as a stand-alone program or included 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. The program may be stored in a part 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 that store 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, either located at one site or distributed across multiple sites and interconnected by a communication network.

[0222] The processes and logical flows described in this specification can be executed by one or more programmable processors executing one or more computer programs to perform actions by operating on input information / data to produce output. Suitable processors for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and one or more processors of any kind of digital computer. In general, a processor receives instructions and information / data from a read only memory or a random access memory or both. Essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. In general, a computer also includes, or is operatively coupled to for the purpose of receiving information / data from and transferring information / data to, one or more mass storage devices for storing data, such as, magnetic disks, magneto-optical disks, or optical disks. However, a computer need not have such devices. Suitable devices for storing computer program instructions and information / data include, by way of example, all forms of non-volatile memory, media, and memory devices, such as, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices, magnetic disks, e.g., internal hard disks or removable disks, magneto-optical disks, e.g., CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. In this regard, the processes and logical flows described in this specification, and / or various combinations and sub-combinations of the actions described and depicted, can embody one or more computer implemented processes, one or more computer program products, and / or one or more specially configured apparatuses according to the present disclosure.

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

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

[0225] A computing system can include a client and a server. The client and the server are generally remote from each other and typically interact via a communication network. The relationship between the client and the server is created by computer programs that are executed on respective computers and have a client-server relationship with each other. In some embodiments, the server transmits information / data (e.g., HTML pages) to the client device (e.g., for the purpose of displaying the information / data to a user who interacts with the client device and receiving user input). Information / data generated on the client device (e.g., as a result of user interaction) can be received by the server from the client device.

[0226] This specification includes many specific implementation details, but these are not intended to limit the scope of any disclosure or what may be claimed, and should be construed as describing features specific to particular embodiments of a particular disclosure. The specific features described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment can also be implemented separately in multiple embodiments or in any suitable sub-combination. Further, features are described above as acting in a particular combination and even if initially claimed as such, one or more features from the claimed combination can in some cases be excised from the combination, and the claimed combination can be directed to a sub-combination or a variation of a sub-combination.

[0227] Similarly, the operations are depicted in the drawings in a particular order, but this should not be construed as requiring that the operations be performed in the particular order shown or in a sequential order, or that all of the illustrated operations be performed, to achieve the desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Further, 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, particular 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 may be performed in a different order and still achieve the desired result. In addition, the processes depicted in the accompanying drawings do not necessarily require the particular order or sequential order shown to achieve the desired result. 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 those portions. 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, wherein the device claim request indication is associated with a client device and the client device is associated with a functional lockout state; initiating a claim associated with the client device based on the device claim request indication; To set the functional lockout state of the client device to the lockout state, processing the claim to determine whether to approve the claim, causing an update of the functional lockout state of the client device based on a determination of whether to approve the claim, a computer-implemented method comprising.

[0230] B. Causing the functional lockout state of the client device to be set to the lockout state is including sending a device lockout request to a manufacturer system associated with the client device, the device lockout request being configured to cause the manufacturer system to set the functional lockout state of the client device to the lockout state, the computer-implemented method of Embodiment A.

[0231] C. Causing the functional lockout state of the client device to be set to the lockout state is including 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 cause the manufacturer system to set the functional lockout state of the client device to the lockout state in response to receiving the device lockout request, the computer-implemented method of Embodiment A or B.

[0232] D. Processing the claim to determine whether to continue the lockout state of the client device is receiving user claim information associated with the claim within a first time stamp interval, processing the user claim information to approve the claim associated with the user claim information, including causing an update of the functional lockout state of the client device based on a determination of whether to continue the locked-out client device, A computer-implemented method according to any of embodiments A to C, including leaving the functional lockout state of the client device in the locked-out state.

[0233] E. Processing a claim to determine whether to continue the lockout state of the client device, including receiving user claim information associated with the claim within a first timestamp interval, and processing the user claim information to reject the claim associated with the user claim information, wherein updating the functional lockout state of the client device is caused based on a determination of whether to continue the locked-out client device. A computer-implemented method according to any of embodiments A to D, including setting the functional lockout state of the client device to the unlocked state.

[0234] F. Processing a claim to determine whether to continue the lockout state of the client device, including determining that no user claim information associated with the claim has been received within a first timestamp interval, wherein updating the functional lockout state of the client device is caused based on a determination of whether to continue the locked-out client device. A computer-implemented method according to any of embodiments A to E, including setting the functional lockout state of the client device to the unlocked state.

[0235] A computer program product for secure device lockout management, the computer program product including at least one non-transitory computer-readable storage medium storing computer program code, the computer program code being configured to execute a method according to any of embodiments A to F when executed on at least one processor.

[0236] H. An apparatus for secure device lockout management, the apparatus including means for performing any of the methods of Embodiments A - F. I. A computer - implemented method for secure device lockout management, receiving case verification data from a trusted third - party provider, the case verification data being associated with a client device identifier of a client device; causing a rendering of a graphical user interface to a user, the rendering including a request for the user to input user case information; receiving user case information using the graphical user interface, wherein in a situation where the user case information is received within a threshold claim start period, the method starting a claim based on the case verification data and the user case information; sending a claim creation notification data object including computer program instructions configured to cause a continuation of an electronic lockout of the client device, to a trusted third - party provider; 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, wherein in a situation where the claim requirement data is received within a threshold claim completion period, the method sending, in a situation where the claim requirement data does not meet the predefined rule set, a claim rejection notification data object including computer program instructions configured to cause an end of the electronic lockout of the client device, to a trusted third - party provider; In a situation where claim requirement data satisfies a predefined rule set, transmitting a claim approval notification data object to a trusted third-party provider, the transmitting including computer program instructions configured such that a claim rejection notification data object causes continuation of an electronic lockout of a client device.

[0237] J. The computer-implemented method further includes comparing claim requirement data with a predefined rule set to determine whether the claim requirement data satisfies the predefined rule set, the computer-implemented method of Embodiment I.

[0238] K. The computer-implemented method further includes ending processing of case confirmation data in a situation where user case data is not received from at least one user device within a threshold claim start period, the computer-implemented method of any of Embodiments I-J.

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

[0240] M. The computer-implemented method further includes identifying an authentication token from case confirmation data and retrieving third-party case data from a trusted third-party provider using the authentication token, the third-party case data including at least a device identifier, the computer-implemented method of any of Embodiments I-L.

[0241] N. The computer-implemented method, in a situation where claim requirement data is received within a claim requirement time threshold, further includes comparing claim requirement data with a predefined rule set to determine whether the claim requirement data satisfies the predefined rule set, The method further includes approving a claim in a situation where the claim requirement data meets a predefined rule set, The method further includes rejecting a claim in a situation where the claim requirement data does not meet a predefined rule set of the device, the computer-implemented method according to any one of embodiments I to M.

[0242] O. The computer-implemented method includes ending the processing of a claim in a situation where the claim requirement data is not received within the claim requirement time threshold; and sending a claim cancellation notification data object to a trusted third-party provider, the claim cancellation notification data object being configured to cause the trusted third-party provider to end the electronic lockout of the client device, the computer-implemented method according to any one of embodiments I to N.

[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 storing computer program code, the computer program code being configured to execute the method according to any one of embodiments I to O when executed on at least one processor, the computer program product.

[0244] Q. An apparatus for secure device lockout management, the apparatus including means for executing the method according to any one of embodiments I to O. R. A computer-implemented method for secure device lockout management, receiving a client device event data object associated with a client device, the client event data object including a case start request; and sending an electronic data signal configured to cause an electronic lockout of the client device to the client device. To send case confirmation data to a device protection program management system, where the case confirmation data is at least partially based on a client device failure data object or a client device loss data object, and In a situation where a claim status update data object is received from a device protection program management system, to perform a device lockout update action based at least on the claim status update data object, and a computer-implemented method including the above.

[0245] S. The computer-implemented method further includes Starting a drop-dead timer for a predetermined period, and In a situation where a claim status update data object is not received from the device protection program management system within a predetermined period, or a claim rejection notification data object is received from the device protection program management system within a predetermined period, to send an electronic data signal configured to cause the termination of the electronic lockout of the client device to the client device, and a computer-implemented method of Embodiment R further including the above.

[0246] T. Performing a device lockout update action based on a claim status update data object includes In a situation where the claim status update data object includes a claim rejection notification data object, terminating the electronic lockout, and In a situation where the claim status updated data object includes a claim approval notification data object, continuing the electronic lockout of the client device, and a computer-implemented method of any of Embodiments R to S including the above.

[0247] U. The computer-implemented method includes Storing at least a portion of information associated with at least one of the client device event data objects in response to receiving the client device event data objects, wherein a portion of the information includes at least the client device identifier of the client device. Receiving a case information request from a device protection program management system. Extracting a portion of the case information in response to receiving the case information request. Further including transmitting a portion of the case information to the device protection program management system in response to the case information request. A computer-implemented method according to any of embodiments R to T.

[0248] V. The computer-implemented method further includes Receiving a claim cancellation notification data object from a device protection program management system. Ending the electronic lockout of the client device. A computer-implemented method according to any of embodiments R to U.

[0249] W. The computer-implemented method further includes Receiving user case information associated with the client device. Transmitting the user case information to the device protection program management system. A computer-implemented method according to any of embodiments R to V.

[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 storing computer program code, the computer program code being configured to execute a method according to any of embodiments R to W when executed by at least one processor.

[0251] An apparatus for secure device lockout management, the apparatus including means for performing any of the methods of embodiments R - W. Many modifications of the embodiments described herein and other embodiments will come to mind to those of skill in the art in light of the teachings presented in the foregoing description and the related drawings. For example, any combination of some or all of the subroutines and sub - processes described herein may be claimed, either individually or in combination, without departing from the scope and spirit of the present disclosure. Accordingly, it is to be understood that the embodiments are not to 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. Specific terms are used herein, but 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, the one or more non-transitory memories storing 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; in response to determining that the additional data related to initiation of the claim has not been received within the threshold claim initiation period, causing a termination of the electronic lockout of the client device; A device that performs the above function.

2. To trigger the initiation of the electronic lockout of the client device, the apparatus: (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) sending a second electronic signal to a carrier system associated with the client device, the carrier system in response to receiving the second electronic signal, causing initiation of the electronic lockout; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, the manufacturer system in response to receiving the third electronic signal, causing initiation of the electronic lockout; The apparatus of claim 1 ,

3. To cause an end of the electronic lockout of the client device, the apparatus: (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 an end of the electronic lockout in response to the carrier system receiving the second electronic signal; or (c) sending a third electronic signal to a manufacturer system associated with the client device, and in response to the manufacturer system receiving the third electronic signal, causing an end of the electronic lockout; The apparatus of claim 1 ,

4. To receive the device billing request indication sent from the third party provider system, the apparatus includes: receiving the device billing request indication from a carrier system associated with the client device; or receiving the device claim 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 an 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; 2. The apparatus of claim 1.

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

2. 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; in response to determining that the additional data related to initiation of the claim has not been received within the threshold claim initiation period, causing a termination of the electronic lockout of the client device; 4. A computer-implemented method comprising:

9. Triggering the initiation of the electronic lockout of the client device includes: (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) sending a second electronic signal to a carrier system associated with the client device, the carrier system in response to receiving the second electronic signal, causing initiation of the electronic lockout; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, the manufacturer system in response to receiving the third electronic signal, causing initiation of the electronic lockout; The computer-implemented method of claim 8 , further comprising one of:

10. Causing an end of the electronic lockout of the client device includes: (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 an end of the electronic lockout in response to the carrier system receiving the second electronic signal; or (c) sending a third electronic signal to a manufacturer system associated with the client device, and in response to the manufacturer system receiving the third electronic signal, causing an end of the electronic lockout; The computer-implemented method of claim 8 , further comprising one of:

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

12. Detecting that the additional data related to the claim has not been received within the threshold claim initiation time 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 an 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 associated with 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 being configured to cause one or more processors to: 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; in response to determining that the additional data related to initiation of the claim has not been received within the threshold claim initiation period, causing a termination of the electronic lockout of the client device; 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) sending a second electronic signal to a carrier system associated with the client device, the carrier system in response to receiving the second electronic signal, causing initiation of the electronic lockout; or (c) transmitting a third electronic signal to a manufacturer system associated with the client device, the manufacturer system in response to receiving the third electronic signal, causing initiation of the electronic lockout; 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 an end of the electronic lockout in response to the carrier system receiving the second electronic signal; or (c) sending a third electronic signal to a manufacturer system associated with the client device, and in response to the manufacturer system receiving the third electronic signal, causing an end of the electronic lockout; 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 may cause 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 claim 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 to, upon execution of the computer program code, 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 an 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