Systems, methods, apparatus, and computer program products for managing and synchronizing independent computing resources

Abstract

To provide a system, a device, a method, and a computer program product for managing and synchronizing an independent computing resource.SOLUTION: A method manages and / or synchronizes computing resources, data, etc. to and from various independent third-party systems while handling transmission errors that occur during synchronization, manages the synchronization of subscriber profiles between various systems, for example, the method manages computing resources for processing one or more outstanding actions of various types by scaling an executed process instance on the basis of the action queue length and the minimum queue length threshold and / or the maximum queue length threshold.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates generally to systems, methods, and apparatus for device protection program management, and more particularly to parallel operation of independent computing systems while reducing synchronization errors and computational inefficiencies. [Background technology]

[0002] Various computing systems, such as those associated with device protection program management, need to communicate and synchronize bulk data with one or more third-party computing systems while allowing convenient access to subscribers and operating efficiently. Additionally, communication errors received in response to failed transmissions between various systems can cause the systems to terminate or not function efficiently. Applicant has identified several deficiencies and problems associated with such systems. Solutions, including embodiments of the present disclosure, solve many of these identified problems, many examples of which are described in detail herein. Summary of the Invention

[0003] Generally, embodiments of the disclosure provided herein include systems, methods, apparatus, and computer program products for managing and synchronizing independent computing resources. Additionally, at least some embodiments are provided for processing actions for managing and synchronizing independent computing resources in a robust and / or efficient manner. Other systems, apparatus, methods, and computer program products, and similar functionality, will be or become apparent to one with skill in the art upon examination of the following figures and detailed description. All such additional systems, apparatus, methods, computer program products, and functionality are intended to be included within this description, be within the scope of this disclosure, and be protected by the following claims.

[0004] According to one aspect of the present disclosure, a first exemplary system for detecting a network communication synchronization error is provided. In at least one exemplary embodiment, the first exemplary system includes at least one processor and at least one memory, the at least one memory including computer-coded instructions stored therein. When executed by the at least one processor, the computer-coded instructions are configured to cause the first exemplary system to receive an enrollment management request including a subscriber data object indicating a device protection program and including a subscriber identifier data object. The first exemplary system is further configured to transmit a third-party enrollment status request data object to the third-party device management system, the third-party enrollment status request data object being associated with the subscriber identifier data object. The first exemplary system is further configured to receive a third-party enrollment status response data object from the third-party device management system, the third-party enrollment status response data object including third-party enrollment status data. The first exemplary system is further configured to compare the third-party enrollment status response data object data with second enrollment status data within the system. The first exemplary system is further configured to detect the network communication synchronization error based on a difference between the third-party enrollment status data and the enrollment status within the device protection program management system. The first exemplary system is further configured to initiate a system synchronization event based on the network communication synchronization error.

[0005] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, the registration management request data object includes a registration subscription request or a registration cancellation request data object, and to cause the system to initiate a system synchronization event, the system is configured to identify a DPPMS subscriber profile data object based on the subscriber identifier data object and update the DPPMS subscriber profile data object based on the third-party registration status response data object.

[0006] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, the system is configured to compare the third-party registration status data with the second registration status data in real time.

[0007] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, the registration management request data object includes a registration subscription request, and the identified third-party registration status indicates that the third-party device management system does not include a third-party subscriber profile data object associated with the subscriber identifier data object, and the system is configured to transmit a third-party subscriber registration request data object to the third-party device management system configured to cause the third-party device management system to create a third-party subscriber profile data object associated with the subscriber identifier data object, to initiate a system synchronization event.

[0008] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, where the identified third-party registration status indicates that the registration management request data object includes a registration cancellation request data object and that the third-party device management system includes a third-party subscriber profile data object associated with the subscriber identifier data object, the system is configured to transmit to the third-party device management system a third-party subscriber cancellation request data object configured to cause the third-party device management system to cancel the third-party subscriber profile data object associated with the subscriber identifier data object to initiate a system synchronization event.

[0009] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, the system is further configured to: attempt to transmit a third-party registration management request data object to the third-party device management system; receive a transmission error in response to the attempt to transmit the third-party registration management request data object to the third-party device management system, the transmission error indicating an error in communicating with the third-party device management system; identify an error classification associated with the transmission error, wherein the error classification comprises a retryable error; determine a request retry time; after the request retry time has elapsed, transmit a second third-party registration status request data object to the third-party device management system; receive a second third-party registration status response data object from the third-party device management system; analyze the second third-party registration status response data object in real time to identify a second third-party registration status associated with the subscriber identifier data object; and initiate a second system synchronization event based on the second identified third-party registration status data.

[0010] Additionally or alternatively, some exemplary implementations of the first exemplary system include: In an embodiment, the third-party device management system includes a second third-party device management system, and the system is configured to receive a registration management request from the first third-party device management system.

[0011] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, the system is further configured to identify a third-party device management system based on the subscriber identifier data object.

[0012] Additionally or alternatively, in some exemplary embodiments of the first exemplary system, the system is further configured to: receive a queue length associated with an action queue, the action queue including at least a third-party registration status request; identify a queue length threshold; identify a queue relationship based on the queue length and the queue length threshold; determine that the queue relationship satisfies the queue length threshold; identify an executed action process instance set including at least one executed action process instance; and update the executed action process instance set based on the queue length.

[0013] According to another aspect of the present disclosure, a first exemplary computer-implemented method for detecting a network communication synchronization error is provided. The computer-implemented method includes operations performed by computing hardware, software, firmware, and / or combinations thereof, as described herein. In at least one exemplary embodiment, the first exemplary computer-implemented method includes receiving an enrollment management request including a subscriber data object indicating a device protection program and including a subscriber identifier data object. The first exemplary computer-implemented method further includes transmitting a third-party enrollment status request data object to a third-party device management system, the third-party enrollment status request data object being associated with the subscriber identifier data object. The first exemplary computer-implemented method further includes receiving a third-party enrollment status response data object from the third-party device management system, the third-party enrollment status response data object further including third-party enrollment status data. The first exemplary computer-implemented method further includes comparing the third-party enrollment status response data object data with second enrollment status data within the system. The first exemplary computer-implemented method further includes detecting the network communication synchronization error based on a difference between the third-party enrollment status data and the enrollment status within the device protection program management system. The first exemplary computer-implemented method further includes initiating a system synchronization event based on the network communication synchronization error.

[0014] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, the registration management request data object includes a registration subscription request or a registration cancellation request data object, and initiating the system synchronization event includes identifying a DPPMS subscriber profile data object based on the subscriber identifier data object and updating the DPPMS subscriber profile data object based on the third-party registration status response data object.

[0015] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, comparing the third-party registration status data with the second registration status data is performed in real time.

[0016] Additionally or alternatively, in certain exemplary embodiments of the first exemplary computer-implemented method, the registration management request data object includes a registration subscription request, the identified third-party registration status indicates that the third-party device management system does not include a third-party subscriber profile data object associated with the subscriber identifier data object, and initiating the system synchronization event includes transmitting to the third-party device management system a third-party subscriber registration request data object configured to cause the third-party device management system to create a third-party subscriber profile data object associated with the subscriber identifier data object.

[0017] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, the registration management request data object includes a registration cancellation request data object, the identified third-party registration status indicates that the third-party device management system includes a third-party subscriber profile data object associated with the subscriber identifier data object, and initiating the system synchronization event includes transmitting to the third-party device management system a third-party subscriber cancellation request data object configured to cause the third-party device management system to cancel the third-party subscriber profile data object associated with the subscriber identifier data object.

[0018] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, the computer-implemented method further includes attempting to transmit a third-party registration management request data object to the third-party device management system; receiving a transmission error in response to the attempt to transmit the third-party registration management request data object to the third-party device management system, the transmission error indicating an error in communicating with the third-party device management system; identifying an error classification associated with the transmission error, wherein the error classification comprises a retryable error; determining a request retry time; after the request retry time has elapsed, transmitting a second third-party registration status request data object to the third-party device management system; receiving a second third-party registration status response data object from the third-party device management system; analyzing the second third-party registration status response data object in real time to identify a second third-party registration status associated with the subscriber identifier data object; and initiating a second system synchronization event based on the second identified third-party registration status data.

[0019] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, the third-party device management system includes a second third-party device management system, and receiving the registration management request is from the first third-party device management system.

[0020] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, the computer-implemented method further includes identifying the third-party device management system based on the subscriber identifier data object.

[0021] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer-implemented method, the computer-implemented method includes receiving a queue length associated with an action queue, the action queue including at least a third-party registration status request; identifying a queue length threshold; identifying a queue relationship based on the queue length and the queue length threshold; and determining whether the queue relationship exceeds the queue length threshold. determining that the queue length satisfies the set of action process instances to be executed, identifying a set of action process instances to be executed that includes at least one action process instance to be executed, and updating the set of action process instances to be executed based on the queue length.

[0022] According to another aspect of the present disclosure, a first exemplary computer program product for detecting a network communication synchronization error is provided. In at least one exemplary embodiment, the first exemplary computer program product includes at least one non-transitory computer-readable storage medium carrying computer program instructions, which, when executed on a processor, are configured to receive a registration management request indicating a device protection program and including a subscriber data object including a subscriber identifier data object. The first exemplary computer program is further configured to transmit a third-party registration status request data object to the third-party device management system, the third-party registration status request data object being associated with the subscriber identifier data object. The first exemplary computer program is further configured to receive a third-party registration status response data object from the third-party device management system, the third-party registration status response data object including third-party registration status data. The first exemplary computer program is further configured to compare the third-party registration status response data object data with second registration status data within the system. The first exemplary computer program is further configured to detect the network communication synchronization error based on a difference between the third-party registration status data and the registration status within the device protection program management system. The first exemplary computer program is further configured to initiate a system synchronization event based on the network communication synchronization error.

[0023] Additionally or alternatively, in certain exemplary embodiments of the first exemplary computer program product, the registration management request data object includes a registration subscription request or a registration cancellation request data object, and initiating the system synchronization event includes identifying a DPPMS subscriber profile data object based on the subscriber identifier data object and updating the DPPMS subscriber profile data object based on the third-party registration status response data object.

[0024] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer program product, comparing the third-party enrollment status data with the second enrollment status data is performed in real time.

[0025] Additionally or alternatively, in certain exemplary embodiments of the first exemplary computer program product, the registration management request data object includes a registration subscription request, the identified third-party registration status indicates that the third-party device management system does not include a third-party subscriber profile data object associated with the subscriber identifier data object, and initiating the system synchronization event includes transmitting to the third-party device management system a third-party subscriber registration request data object configured to cause the third-party device management system to create a third-party subscriber profile data object associated with the subscriber identifier data object.

[0026] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer program product, the registration management request data object includes a registration cancellation request data object, and a third party associated with the subscriber identifier data object. The identified third-party registration status indicates that the third-party device management system includes a party subscriber profile data object, and initiating the system synchronization event includes transmitting to the third-party device management system a third-party subscriber cancellation request data object configured to cause the third-party device management system to cancel the third-party subscriber profile data object associated with the subscriber identifier data object.

[0027] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer program product, the computer program product further includes attempting to transmit a third-party registration management request data object to the third-party device management system; receiving a transmission error in response to the attempt to transmit the third-party registration management request data object to the third-party device management system, the transmission error indicating an error in communicating with the third-party device management system; identifying an error classification associated with the transmission error, wherein the error classification comprises a retryable error; determining a request retry time; after the request retry time has elapsed, transmitting a second third-party registration status request data object to the third-party device management system; receiving a second third-party registration status response data object from the third-party device management system; analyzing the second third-party registration status response data object in real time to identify a second third-party registration status associated with the subscriber identifier data object; and initiating a second system synchronization event based on the second identified third-party registration status data.

[0028] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer program product, the third-party device management system includes a second third-party device management system, and receiving the registration management request is from the first third-party device management system.

[0029] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer program product, the computer program product further includes computer program instructions for identifying a third-party device management system based on the subscriber identifier data object.

[0030] Additionally or alternatively, in some exemplary embodiments of the first exemplary computer program product, the computer program product further includes computer program instructions for receiving a queue length associated with an action queue, the action queue including at least a third-party registration status request; identifying a queue length threshold; identifying a queue relationship based on the queue length and the queue length threshold; determining that the queue relationship satisfies the queue length threshold; identifying an executed action process instance set including at least one executed action process instance; and updating the executed action process instance set based on the queue length.

[0031] According to one aspect of the present disclosure, a second exemplary system for detecting network communication synchronization errors is provided. In at least one embodiment including computer-coded instructions on at least one memory, the computer-coded instructions, when executed by at least one processor, configure the system to attempt to transmit a third-party registration management request data object from the system to a third-party device management system. The second exemplary system detects a transmission error associated with the attempted transmission to the third-party device management system, the transmission error indicating the occurrence of at least one error during the attempted transmission. The second exemplary system is further configured to: identify an error classification associated with the transmission error; identify an error handling instruction set based on the error classification; and execute the error handling instruction set.

[0032] Additionally or alternatively, some exemplary embodiments of the second exemplary system are configured to identify a trained error classification machine learning model and to identify the error classification using the trained error classification machine learning model.

[0033] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, the system is configured to identify an escalation queue and add the retryable error to the escalation queue to execute the identified error classification retryable error and error handling instruction set.

[0034] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, the identified error classification is a retryable error, and to execute the set of error handling instructions, the system is configured to identify a maximum retry threshold, identify a number of retry attempts, determine a retry relationship between the maximum retry threshold and the number of retry attempts, determine that the retry relationship satisfies the maximum retry threshold, determine a requested retry time, and add the failed transmission to a request queue and attempt to retransmit the failed transmission after the requested retry time has elapsed.

[0035] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, to determine the request retry time, the system is configured to update the request retry time based on a number of retry attempts. Additionally or alternatively, in some exemplary embodiments of the second exemplary system, to determine the request retry time, the system is configured to update the request retry time based on an exponential backoff.

[0036] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, the identified error classification includes an escalation error, and the system is configured to add the failed transmission to a transmission queue to execute the error handling instruction set.

[0037] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, the identified error classification identified from the error classification set is an escalation error, and the system is configured to transmit an error escalation request to a third-party error handling system to execute the error handling instruction set.

[0038] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, the system is further configured to: receive a queue length associated with an action queue associated with the third-party registration status request data object; identify a queue length threshold; identify a queue relationship based on the queue length and the queue length threshold; determine that the queue relationship satisfies the queue length threshold; identify an executed action process instance set including at least one executed action process instance; and update the executed action process instance set based on the queue length.

[0039] According to another aspect of the present disclosure, a second exemplary computer-implemented method for detecting network transmission errors, the computer-implemented method may be implemented via the computing hardware, software, and / or firmware described herein. A second exemplary computer-implemented method is provided in at least some embodiments for: attempting to transmit a third-party registration management request data object to a third-party device management system; detecting a transmission error associated with the attempted transmission to the third-party device management system, the transmission error indicating the occurrence of at least one error during the attempted transmission; identifying an error classification associated with the transmission error; identifying an error handling instruction set based on the error classification; and executing the error handling instruction set.

[0040] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, identifying the error classification includes identifying a trained error classification machine learning model and identifying the error classification using the trained error classification machine learning model.

[0041] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, for an identified error classifying a retryable error, executing the error handling instruction set includes identifying an escalation queue and adding the retryable error to the escalation queue.

[0042] Additionally or alternatively, in some exemplary embodiments of the second exemplary system, the identified error classification is a retryable error, and executing the set of error handling instructions includes identifying a maximum retry threshold, identifying a number of retry attempts, determining a retry relationship between the maximum retry threshold and the number of retry attempts, determining that the retry relationship satisfies the maximum retry threshold, determining a requested retry time, and adding the failed transmission to a request queue and attempting to retransmit the failed transmission after the requested retry time has elapsed.

[0043] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, determining the request retry time includes updating the request retry time based on the number of retry attempts. Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, determining the request retry time includes updating the request retry time based on an exponential backoff.

[0044] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the identified error classification includes an escalation error, and executing the set of error handling instructions includes adding the failed transmission to a transmission queue.

[0045] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the identified error classification identified from the set of error classifications is an escalation error, and executing the set of error handling instructions includes transmitting an error escalation request to a third-party error handling system.

[0046] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the computer-implemented method may further include receiving a queue length associated with an action queue associated with the third-party registration status request data object; identifying a queue length threshold; identifying a queue relationship based on the queue length and the queue length threshold; determining that the queue relationship satisfies the queue length threshold; and executing an executed action process including at least one executed action process instance. and updating the set of action process instances to be executed based on the queue length.

[0047] According to another aspect of the present disclosure, a second exemplary computer program product for detecting network transmission errors is provided. In at least one exemplary embodiment, the second exemplary computer program product includes computer program instructions configured for attempting to transmit a third-party registration management request data object to a third-party device management system. The second computer program product is further configured for detecting a transmission error associated with the attempted transmission to the third-party device management system, the transmission error indicating the occurrence of at least one error during the attempted transmission. The second computer program product is further configured for identifying an error classification associated with the transmission error. The second computer program product is further configured for identifying an error handling instruction set based on the error classification. The second computer program product is further configured for executing the error handling instruction set.

[0048] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, identifying the error classification includes identifying a trained error classification machine learning model and identifying the error classification using the trained error classification machine learning model.

[0049] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, for an identified error classifying a retryable error, executing the error handling instruction set includes identifying an escalation queue and adding the retryable error to the escalation queue.

[0050] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, the identified error classification is a retryable error, and executing the set of error handling instructions includes identifying a maximum retry threshold; identifying a number of retry attempts; determining a retry relationship between the maximum retry threshold and the number of retry attempts; determining that the retry relationship satisfies the maximum retry threshold; determining a requested retry time; and adding the failed transmission to a request queue and attempting to retransmit the failed transmission after the requested retry time has elapsed.

[0051] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, determining the request retry time includes updating the request retry time based on the number of retry attempts. Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, determining the request retry time includes updating the request retry time based on an exponential backoff.

[0052] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, the identified error classification includes an escalation error, and executing the set of error handling instructions includes adding the failed transmission to a transmission queue.

[0053] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer program product, the identified error classification identified from the set of error classifications is an escalation error, and executing the set of error handling instructions includes transmitting an error escalation request to a third-party error handling system.

[0054] Additionally or alternatively, in some exemplary embodiments of the second exemplary computer-implemented method, the computer-implemented method further includes receiving a queue length associated with an action queue associated with the third-party registration status request data object, identifying a queue length threshold, identifying a queue relationship based on the queue length and the queue length threshold, determining that the queue relationship satisfies the queue length threshold, identifying an executed action process instance set including at least one executed action process instance, and updating the executed action process instance set based on the queue length.

[0055] According to yet another aspect of the present disclosure, a third exemplary system for fulfilling a billing request for an unregistered device is provided. The third exemplary system is configured by computer-coded instructions to receive a billing data object associated with a subscriber identifier data object, the billing data object including a device identification data object. The third exemplary system is further configured to query a device protection program subscriber database associated with the system for a subscriber profile data object associated with the subscriber identifier data object. The third exemplary system is further configured to receive result data indicating that the device protection program database does not contain the subscriber profile data object. The third exemplary system is further configured to transmit a third-party registration status request to a third-party device management system, the third-party registration status request data object including a subscriber identifier data object and a device identification data object. The third exemplary system is further configured to receive a third-party registration status response data object from the third-party device management system indicating a third-party registration status associated with the subscriber identifier data object, the third-party registration status indicating a third-party subscriber profile data object stored in the third-party device management system. The third exemplary system is further configured to initiate a set of billing processing instructions associated with the billing data object without the subscriber profile data object.

[0056] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, the system is further configured to identify an anti-fraud instruction set including at least one anti-fraud event for obtaining real-time device information, and to execute the anti-fraud instruction set.

[0057] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, the system is further configured to: receive a queue length associated with an action queue, the action queue including at least a subset of the request data objects; identify a queue length threshold; identify a queue relationship based on the queue length and the queue length threshold; determine that the queue relationship satisfies the queue length threshold; identify an executed action process instance set including at least one executed action process instance; and update the executed action process instance set based on the queue length.

[0058] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, the billing data object is received from the first third-party device management system and the third-party registration status request is transmitted to the second third-party device management system. Additionally or alternatively, in some exemplary embodiments of the third exemplary system, the system is further configured to identify the third-party device management system based on the subscriber identifier data object.

[0059] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, a billing data object is received from a first third-party device management system, including a third-party carrier device management system or a third-party vendor device management system, and a third-party registration status request is transmitted to a second third-party device management system, the billing data object including a billing type identifier data object, and the system further comprises: in a situation where the billing type identifier data object represents a lost device claim or a stolen device claim, obtaining a device location application status associated with the device location application, the device location application status indicating that the device location application is accessible; and in a situation where the claim type identifier data object represents a device damage claim, obtaining a device location application status associated with the device location application and determining that the device location application status is set to a lost state, the claim processing instruction set being initiated in response to determining that the device lost status is set to a lost state; and in a situation where the claim type identifier data object represents a device damage claim, obtaining a device location application status associated with the device location application and determining that the device location application status indicates that the device location application is inaccessible, the claim processing instruction set being initiated in response to determining that the device location application status indicates that the device location application is inaccessible.

[0060] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, a billing data object is received from a first third-party device management system including a third-party carrier device management system or a third-party vendor device management system, a third-party registration status request is transmitted to a second third-party device management system, the billing data object includes a billing type identifier data object, and the system is further configured to: in a situation where the billing type identifier data object represents a lost device claim or a stolen device claim, obtain a device location application status associated with the device location application, wherein the device location application status indicates that the device location application is inaccessible, and the set of billing processing instructions is initiated in response to a determination that the device location application status indicates that the device location application is inaccessible; and in a situation where the billing type identifier data object represents a device damage claim, obtain a device location application status associated with the device location application and determine that the device location application status indicates that the device location application is inaccessible, and the set of billing processing instructions is initiated in response to a determination that the device location application status indicates that the device location application is inaccessible.

[0061] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, a claim data object is received from a first third-party device management system, including a third-party manufacturer device management system, and a third-party registration status request is transmitted to a second third-party device management system, the claim data object includes a claim type identifier data object, and the system is configured to: and in a situation where the claim type identifier data object represents a device damage claim, obtaining a device location application status associated with the device location application and determining that the device location application status indicates that the device location application is inaccessible, the claim processing instruction set being initiated in response to a determination that the device location application status indicates that the device location application is inaccessible.

[0062] Additionally or alternatively, in some exemplary embodiments of the third exemplary system, the system is further configured to receive a transmission error that causes the system to not store the subscriber profile data object in the device protection program database. Additionally or alternatively, in some exemplary embodiments of the third exemplary system, the system is further configured to initiate a system synchronization event based on the third-party registration status response data object.

[0063] According to another aspect of the present disclosure, a third exemplary computer-implemented method for fulfilling claims for unregistered devices is provided. The third exemplary computer-implemented method includes operations performed by computing hardware, software, firmware, and / or combinations thereof, as described herein. In some embodiments, the computer-implemented method includes operations performed by the third exemplary apparatus described above. For example, in at least one embodiment, a third exemplary computer-implemented method includes at least receiving a billing data object associated with a subscriber identifier data object, the billing data object including a device identification data object, querying a device protection program subscriber database associated with the system for a subscriber profile data object associated with the subscriber identifier data object and receiving result data indicating the device protection program database does not contain the subscriber profile data object, transmitting a third-party registration status request to a third-party device management system, the third-party registration status request data object including the subscriber identifier data object and the device identification data object, receiving a third-party registration status response data object from the third-party device management system indicating a third-party registration status associated with the subscriber identifier data object, the third-party registration status indicating a third-party subscriber profile data object stored in the third-party device management system, and initiating a billing processing instruction set associated with the billing data object without the subscriber profile data object. Additionally or alternatively, the third exemplary computer-implemented method may include any of the above-described operations performed by any of the third exemplary apparatus embodiments configured.

[0064] According to another aspect of the present disclosure, a third exemplary computer program product for fulfilling claims for unregistered devices is provided. The third exemplary computer program product includes computer program instructions stored on at least one non-transitory computer-readable storage medium. In some embodiments, the third exemplary computer program product is configured to perform the operations performed by the third exemplary apparatus described above. and initiating a billing processing instruction set associated with the billing data object without the subscriber profile data object. For example, in at least one embodiment, a third exemplary computer program product is configured for at least receiving a billing data object associated with a subscriber identifier data object, the billing data object including a device identification data object; querying a device protection program subscriber database associated with the system for a subscriber profile data object associated with the subscriber identifier data object and receiving result data indicating the device protection program database does not contain the subscriber profile data object; transmitting a third-party registration status request to the third-party device management system, the third-party registration status request data object including the subscriber identifier data object and the device identification data object; receiving a third-party registration status response data object from the third-party device management system indicating a third-party registration status associated with the subscriber identifier data object, the third-party registration status indicating a third-party subscriber profile data object stored in the third-party device management system; and initiating a billing processing instruction set associated with the billing data object without the subscriber profile data object. Additionally or alternatively, the third exemplary computer program product may be configured for any of the above-described operations performed by any of the third exemplary apparatus embodiments configured.

[0065] According to yet another aspect of the present disclosure, a fourth exemplary system is provided, including at least one processor and at least one memory with computer-coded instructions for execution. In at least one exemplary embodiment, the fourth exemplary system is configured to receive a queue length associated with an action queue via the computer-coded instructions. The fourth exemplary system is further configured to identify a queue length threshold. The fourth exemplary system is further configured to identify a queue relationship based on the queue length and the queue length threshold. The fourth exemplary system is further configured to determine that the queue relationship satisfies the queue length threshold. The fourth exemplary system is further configured to identify an executed action process instance set including at least one executed action process instance. The fourth exemplary system is further configured to update the executed action process instance set based on the queue length.

[0066] Additionally or alternatively, in some exemplary embodiments of the fourth exemplary system, the queue length threshold includes a queue length maximum threshold, the queue relationship includes a maximum queue relationship, and the system is further configured to: identify a number of executed instances associated with the set of executed action process instances; identify an action process instance count maximum value; determine a maximum process instance relationship based on the number of executed instances and the action process instance count maximum threshold; and determine that the maximum process instance relationship satisfies the action process instance count maximum threshold; and execute a new action process instance and add the new action process instance to the set of executed action process instances to cause the system to update the set of executed action process instances.

[0067] Additionally or alternatively, in some exemplary embodiments of the fourth exemplary system, the queue length threshold includes a queue length minimum threshold, the queue relationship includes a minimum queue relationship, and the system further includes identifying a number of executed instances associated with the set of executed action process instances, and generating an action process instance counter. the system is further configured to: identify a minimum action process instance count value; determine a minimum process instance relationship based on the number of executed instances and the action process instance count minimum value; and determine that the minimum process instance relationship satisfies the action process instance count minimum value; and the system is configured to terminate a selected executed action process instance from the set of executed action process instances to cause the system to update the set of executed action process instances.

[0068] Additionally or alternatively, in some exemplary embodiments of the fourth exemplary system, to update the set of executed action process instances, the system is configured to: identify an action type associated with at least one unprocessed action in the action queue, where the action type is associated with a first action priority; identify an executed action process instance including an executed process thread configured to process a second action type associated with a second action priority, where the first action priority is determined to be a higher priority than the second action priority; purge the process thread from the executed action process instance; and execute a new process thread for the executed action process instance, where the new process thread is configured to process unprocessed actions associated with the first action type.

[0069] According to another aspect of the present disclosure, a fourth exemplary computer-implemented method is provided. The fourth exemplary computer-implemented method includes operations performed by computing hardware, software, firmware, and / or combinations thereof, as described herein. In some embodiments, the computer-implemented method includes operations performed by the fourth exemplary apparatus described above. For example, in at least one embodiment, the fourth exemplary computer-implemented method includes at least receiving a queue length associated with an action queue, identifying a queue length threshold, identifying a queue relationship based on the queue length and the queue length threshold, determining that the queue relationship satisfies the queue length threshold, identifying an executed action process instance set including at least one executed action process instance, and updating the executed action process instance set based on the queue length. Additionally or alternatively, the fourth exemplary computer-implemented method may include any of the operations described above performed by any of the above-described embodiments of the fourth exemplary apparatus.

[0070] According to another aspect of the present disclosure, a fourth exemplary computer program product is provided. The fourth exemplary computer program product includes computer program instructions stored on at least one non-transitory computer-readable storage medium. In some embodiments, the fourth exemplary computer program product includes computer program instructions configured to perform the operations performed by the fourth exemplary apparatus described above. For example, in at least one embodiment, the fourth exemplary computer program product is configured to at least receive a queue length associated with an action queue, identify a queue length threshold, identify a queue relationship based on the queue length and the queue length threshold, determine that the queue relationship satisfies the queue length threshold, identify an executed action process instance set including at least one executed action process instance, and update the executed action process instance set based on the queue length. Additionally or alternatively, the fourth exemplary computer program product may be configured to perform the operations performed by the fourth exemplary apparatus. It may be configured for any of the above operations to be performed by the embodiment. [Brief explanation of the drawings]

[0071] [Figure 1] 1 illustrates an exemplary system in which embodiments of the present disclosure may operate. [Figure 2] 1 illustrates a block diagram of a system that may be specially configured within which embodiments of the present disclosure may operate. [Figure 3] 1 illustrates a block diagram of an apparatus that may be specially configured in accordance with an exemplary embodiment of the present disclosure. [Figure 4A] 1 illustrates a flowchart depicting operations performed according to an example exemplary embodiment of the present disclosure. [Figure 4B] 1 illustrates a flowchart depicting operations performed according to an example exemplary embodiment of the present disclosure. [Figure 4C]1 illustrates an example data flow diagram depicting a system and operation for registration synchronization according to an example embodiment of the present disclosure. [Figure 5] 1 illustrates a flowchart depicting operations performed in accordance with an exemplary embodiment of the present disclosure. [Figure 6] 1 illustrates a flowchart depicting operations performed in accordance with an exemplary embodiment of the present disclosure. [Figure 7] 1 illustrates a block diagram depicting modules specially configured in accordance with an exemplary embodiment of the present disclosure. [Figure 8A] 1 illustrates a flowchart depicting operations performed in accordance with an exemplary embodiment of the present disclosure. [Figure 8B] 1 illustrates a flowchart depicting operations performed in accordance with an exemplary embodiment of the present disclosure. [Figure 9] 1 illustrates a block diagram of a system that may be specially configured within which embodiments of the present disclosure may operate. DETAILED DESCRIPTION OF THE INVENTION

[0072] Embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings in which some, but not all, embodiments of the present disclosure are illustrated. Indeed, embodiments of the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout.

[0073] Overview A device protection program protects subscribers when their devices are damaged, broken, lost, stolen, or otherwise affected. While many third parties may offer enrollment in one or more device protection programs, not all third parties also fulfill or otherwise process all claims associated with the device protection program. Thus, while a third party may enroll new subscribers associated with one or more device protection programs, such third parties rely on a device protection program management system (DPPMS) controlled by a provider entity to proactively enforce claims. In some embodiments, a provider entity associated with a DPPMS can provide supplemental device protection in addition to the protection provided by the third party, which may require a high degree of coordination between the computing systems of the DPPMS and the computing systems of the primary device protection provider. As described herein, the inventors have developed a method for maintaining synchronization and consistency of independent computing systems and eliminating redundant or unnecessary tasks associated with managing multiple independently operated computing systems and databases, including DPPMS and third-party systems. We have identified several solutions to the problem of requiring a large number of updates and processing operations with frequent changes without placing undue strain on individual systems.

[0074] The DPPMS can interact with one or more third-party systems, each associated with a third-party entity. The corresponding third-party entity may indicate a level of control over the subscriber device (e.g., software only, software and hardware, firmware, etc.). Some third-party systems are associated with, for example, a mobile carrier, in which case the mobile carrier controls only the specific software and / or firmware associated with the subscriber device. Other third-party systems are associated with, for example, a device manufacturer, in which case the device manufacturer controls the software, firmware, and / or hardware associated with the subscriber device. Some third-party systems include a third-party device management system configured to maintain subscriber profile data objects associated with subscribers associated with or enrolled in one or more device protection programs via the third-party device management system. Users may subscribe new or existing devices to the device protection program and / or cancel enrollment in the device protection program for one or more currently enrolled subscriber devices. The third-party device management system may then communicate with the DPPMS to provide one or more enrollment management request data objects associated with the subscriber changes that occurred via the third-party device management system. In other embodiments, a user may subscribe and / or cancel enrollment in the Device Protection Program directly through the DPPMS or through a second, third-party device management system. For example, subscription or cancellation may occur through a carrier system and be communicated from the carrier system to the manufacturer system (or vice versa) before being forwarded to the DPPMS.The enrollment management request data object can be used to synchronize subscriber enrollment data between the DPPMS and one or more third party systems, each of which can independently maintain one or more data objects associated with devices and subscribers.

[0075] In some embodiments, one or more third-party systems are configured to receive device incident data from subscribers (e.g., information indicating a loss, theft, damage, or another event of interest associated with a subscriber device). Subscribers may report incidents either directly to the DPPMS or through a third-party system. For example, subscribers may report incidents through a reporting interface (e.g., a web interface or mobile application) associated with the third-party system or through a call center request. Some third-party systems are configured to authenticate users associated with reported incidents. For example, the third-party system may authenticate users by requiring the user to provide a username and password, followed by authentication utilizing a predetermined two-factor authentication method. The third-party system may provide information indicating that the user has successfully authenticated to the DPPMS, for example, in the form of a third-party user identity authentication token. The third-party user identity authentication token may be included as part of the third-party case information associated with the third-party case to verify that the user who reported the device incident associated with the third-party case has been successfully authenticated by the third party.

[0076] In response to a reported incident, a third party, such as a device manufacturer, may initiate a third-party case associated with the reported incident, for example, via a third-party device management system such as a Device Manager profiling system. Thus, the third-party device management system may obtain, receive, and / or otherwise store information associated with a reported incident, a subscriber device, a subscriber, etc. In some embodiments, the information may be stored so as to be accessible in association with a third-party case. The third-party device management system may, for example, obtain real-time device information associated with a subscriber device and store the real-time device information in a third-party case.

[0077] The DPPMS may receive an enrollment management request data object from a third-party device management system associated with a new and / or canceled subscriber, or from a second third-party device management system associated with the first third-party device management system and the DPPMS. For example, the first third-party device management system may be a manufacturer system associated with a particular mobile device type of mobile device, and the second third-party device management system may be a carrier system for receiving subscription registrations and cancellations associated with those mobile devices. The enrollment management request data object may indicate a new subscriber who registered via a third-party device management system and include information associated with the new subscriber to the device protection program, such as a subscriber profile data object, a subscriber device identifier, a subscriber name (if present), a subscriber contact information, etc. Additionally or alternatively, the enrollment management request data object indicating a new subscriber who registered via a third-party device management system may include a third-party identity authentication token for use in verifying that the third-party device management system successfully authenticated the subscriber.

[0078] Alternatively, the enrollment management request data object indicating that the subscriber canceled enrollment in the device protection program via a third-party device management system may include information associated with the canceled subscriber to the device protection program, such as a subscriber profile data object, a subscriber identifier data object that uniquely identifies the subscriber device identifier, etc. Additionally or alternatively, the enrollment management request data object indicating that the subscriber canceled enrollment via a third-party device management system may include a third-party identity authentication token for use in verifying that the third-party device management system successfully authenticated the subscriber.

[0079] An example DPPMS includes one or more action queues for storing pending actions and / or requests received from third-party systems, such as third-party device management systems. Based on the received enrollment management request data object, the DPPMS may identify and execute an enrollment protocol that includes an instruction set associated with the enrollment management request data object.

[0080] In an exemplary system, the DPPMS receives enrollment management request data objects from a particular third-party device management system at one or more predetermined times (e.g., at a particular time on a particular day of the week each week). Accordingly, the DPPMS may store the received enrollment management request data objects in an action queue. The DPPMS may execute and maintain one or more action processes, where each action process includes one or more executing process threads configured to process unprocessed actions (e.g., enrollment management request data objects) from the action process queue.

[0081] For example, in an exemplary system, the DPPMS may start one or more action instance processes configured to process unprocessed actions stored in the action queue. An action instance process may be configured to process a single unprocessed action type (e.g., The data object may be configured to process a variety of pending action types (e.g., pending entitlement management request data objects, pending claims, etc.) or pending action types (e.g., pending entitlement management request data objects, pending claims, etc.).

[0082] Additionally or alternatively, the example embodiment DPPMS is configured to manage third-party cases by creating, maintaining, and processing claims corresponding to the third-party cases. For example, the DPPMS may receive third-party case information from a third-party system, such as a device manufacturer system or a mobile carrier system. Additionally, the DPPMS may receive user case information associated with the third-party case (e.g., date of incident, user description of the incident, etc.).

[0083] The DPPMS may use the third-party case information and the user case information to generate a claim associated with the third-party case. The claim may include some or all of a combination of the third-party case information and the user case information. In some embodiments, the DPPMS may add the claim to an action queue for fulfillment. The action queue for processing the claim and the action queue for processing the enrollment management request data object may be separate. Additionally or alternatively, the DPPMS may include one or more action process instances for processing the claim from the corresponding action queue.

[0084] The DPPMS may receive new third-party cases from one or more third-party systems. For example, the DPPMS may communicate with one or more device manufacturer systems and one or more mobile carrier systems. Each third-party system may be configured to initiate a new third-party case in response to an incident report submitted by a user, for example, via an interface associated with the third-party system. Additionally or alternatively, a third-party system, such as a device manufacturer system, may be configured to perform user authentication. Thus, in some embodiments, the DPPMS is configured to receive user authentication information, such as a user authentication token, as part of the third-party case information or in addition to a transmission of the third-party case information. The user authentication information may be used to verify that the third-party system has authenticated the third-party resource.

[0085] After receiving the third-party case information, the DPPMS may be configured to receive user case information associated with the third-party case. For example, a user may enter information about the incident (e.g., incident date, incident time, incident description, etc.) via an interface generated by the DPPMS or an associated system. In some embodiments, the DPPMS generates a claim based on the third-party case information and the user case information.

[0086] The DPPMS may then store the request for processing and fulfillment in an action queue. The DPPMS may initiate and / or maintain one or more executed action processing instances configured to process outstanding claims. The DPPMS may include one or more modules and / or subsystems configured to identify a fraud risk associated with the claim. Based at least on the fraud risk, the claim may be approved (if deemed not fraudulent) or rejected (if deemed fraudulent).

[0087] Alternatively or additionally, in some embodiments, the DPPMS may identify claim requirements associated with a given claim. Each claim requirement may require further action by the user. For example, the claim requirements for a given claim may include user approval of one or more disclaimers associated with the claim. In some embodiments, the DPPMS may All information associated with a claim, such as user requirements, must be received within a predetermined claim completion period (e.g., 30 days). If the claim requirements, and / or other information associated with the claim, are not received from the user within the predetermined claim completion period, the DPPMS may automatically close the claim due to lack of action.

[0088] When the DPPMS approves, rejects, or closes a claim, the DPPMS may be configured to set a corresponding claim status associated with the claim. For example, if a claim is approved, the DPPMS may set the corresponding claim status of the claim to "approved." Alternatively, if a claim is rejected or closed due to lack of action, the DPPMS may set the corresponding claim status of the claim to "rejected" or "closed," respectively.

[0089] In some embodiments, the DPPMS is configured to cause one or more third-party systems to update third-party cases based on configured claim statuses. The DPPMS may be controlled by a particular entity, such as a provider entity, which may create, control, or otherwise utilize the DPPMS for many of the functions associated with a device protection program to ensure that such systems process claims in a robust and efficient manner while verifying that the claims are not fraudulent.

[0090] In an exemplary aspect, for example, the DPPMS manages device protection programs for devices, such as insurance, warranties, etc. for mobile devices. In such a situation, the DPPMS communicates with one or more third-party systems, e.g., a first third-party system such as a carrier system and a second third-party system such as a manufacturer system, to manage registered subscribers to various device protection programs. A user may manage subscriptions to device protection programs fulfilled through the DPPMS or an associated entity. By enrolling in a device subscription program, a user may submit a claim associated with the device protection program in exchange for one or more fees if a device covered by the device protection program is damaged, lost, stolen, or the like (e.g., a reduced ability to access the device or another event resulting in other malfunction). The DPPMS and / or associated systems process the claim and can either fulfill the claim (e.g., provide a new device, repair an existing device, etc.) or deny the claim as fraudulent or unfulfillable (e.g., the user is not covered by the event).

[0091] In such a situation, the DPPMS performs the necessary fulfillment action in response to a legitimate user request. The DPPMS may perform an inquiry to determine whether the user is enrolled in the Device Protection Program at the time of the claim. However, users may enroll in the Device Protection Program at various times, including upon purchase of the device, upon a specific event, or in some other circumstance as desired, and may similarly cancel enrollment at a specific time or alternatively at any time of their choosing. Furthermore, users may enroll in or cancel enrollment in the Device Protection Program either through a carrier system, a manufacturer system, or directly through the DPPMS. Therefore, the subscriber database maintained by the DPPMS may not be up-to-date at the time the DPPMS determines whether and / or how to fulfill a received claim.

[0092] Thus, the DPPMS may build and maintain a database of subscriber profile data objects separate from the third party systems with which it interfaces, with each subscriber profile data object being enrolled in at least one device protection program. The DPPMS may manage subscriber profile data objects to register and / or cancel registrations. The DPPMS communicates with one or more third-party systems, such as one or more third-party device management systems, to determine third-party registration status associated with the subscriber profile data objects and to receive registration management request data objects (e.g., new subscriber registration requests or new subscriber cancellation requests) from the one or more third-party device management systems. The subscriber profile data objects may be associated with human subscribers, subscriber devices, and / or both.

[0093] However, the subscriber profile data objects in the DPPMS may not accurately match the enrollment status with respect to the corresponding third-party subscriber profile data objects stored in the third-party system. When a new subscriber enrolls in or cancels enrollment in a device protection program via a third-party device management system, the DPPMS may not be updated until later. In this regard, one or more third-party device management systems may retain enrollment management request data objects to avoid constantly utilizing significant network and other computing resources for communicating with the DPPMS. For example, some third-party device management systems may transmit new enrollment management request data objects to the DPPMS in batches, such as once a week at a specific time. Thus, when a user changes their enrollment status with respect to a device protection program (e.g., newly subscribes or cancels), the corresponding DPPMS may not reflect this status until the third-party device management system notifies the DPPMS of the new enrollment management request data object, for example, via a batch transmission of the new enrollment management request data object.

[0094] Inter-system communication failures can further pose problems in ensuring that the DPPMS accurately reflects subscriber registrations. Transmission errors, including signaling errors and errors in processing received registration requests, can cause the third-party device management system to fail to update the DPPMS based on information received from the third-party device management system without detecting that such errors have occurred. In particular, during device protection program registration, for example, one or more third-party device management systems may transmit registration management request data objects to the DPPMS to update a database, list, or other data store of subscriber profile data objects. However, the DPPMS may fail to receive the transmission, for example, due to a network failure or network interface failure of a component of the DPPMS. Additionally or alternatively, a transmission error can occur if the DPPMS is unable to process the received transmission due to corrupted or inconsistent data. In such a situation, the third-party device management system may not or may be unable to detect the error and may continue to operate under the assumption that the DPPMS properly updated its registration database but that such update was unsuccessful. Therefore, the subscriber profile data objects maintained by the DPPMS and the third-party device management system may become unsynchronized, and the system may be unable to detect such a situation.

[0095] If the DPPMS does not reflect the proper enrollment status associated with a subscriber to the Device Protection Program, the DPPMS may improperly process claims or other transactions associated with the Device Protection Program. For example, if the DPPMS includes a subscriber profile data object associated with a subscriber to the Device Protection Program who canceled the subscriber's enrollment in the Device Protection Program via a third-party device management system, the DPPMS may improperly fulfill claims. Alternatively, if the DPPMS does not reflect the proper enrollment status associated with a subscriber to the Device Protection Program, the DPPMS may improperly fulfill claims. Failure to include the object may result in improper non-fulfillment of claims if the subscriber is enrolled in a device protection program through a third-party device management system.

[0096] Accordingly, various embodiments of the present disclosure relate to methods, computer program products, and systems for subscriber registration management via a DPPMS configured to verify subscriber registration status with a third-party device management system in real time. Specifically, some embodiments of the present disclosure are configured to transmit a registration status request to a third-party device management system, receive a third-party registration status response data object from the third-party device management system, and analyze the third-party registration status response data object to identify a third-party registration status or subscriber identifier data object associated with the subscriber in real time. Additionally, some embodiments are configured to initiate a system synchronization event based on the identified third-party registration status. Thus, embodiments of the present disclosure provide a solution to improper synchronization between a DPPMS and one or more third-party device management systems.

[0097] Unlike traditional server-client or master-slave architectures, the DPPMS separates control of data between network systems. The DPPMS does not automatically trust previously stored data or data previously stored by other third-party device management systems networked with the DPPMS. Due to the nature of data transmissions to the DPPMS, certain transmissions from third-party device management systems may be trusted and used to update the DPPMS, its subsystems, or other third-party device management systems.

[0098] Additionally, due to the nature of receiving batch transmissions, the system may inefficiently utilize processing resources based on the amount of outstanding actions (e.g., claims, registration management request data objects, etc.). During batch transmissions, outstanding actions may be placed in action queues for processing. However, sufficient resources may not be allocated to process the maintenance action process instances configured to process the outstanding actions in each action queue, which may result in wait times for processing outstanding actions longer than the target processing time. Thus, the DPPMS may function inefficiently. Similarly, in some situations, such as when the action queue length is short, an action queue may be allocated more processing resources than necessary. In such situations, processing resources are wasted, leading to overall system inefficiency.

[0099] Accordingly, various embodiments of the present disclosure relate to methods, computer program products, and systems for utilizing a scaling service to manage one or more process instances associated with an action queue. Some embodiments of the present disclosure are configured to update a set of executed action process instances based on a queue length and an identified queue relationship. For example, some embodiments update the set of executed action process instances by identifying a maximum queue relationship based on a queue length and a queue length maximum threshold, and executing a new action process instance including at least one processing thread configured to process unprocessed actions stored in the action queue based on the maximum queue relationship. Additionally or alternatively, some embodiments update the set of executed action process instances by identifying a minimum queue relationship based on a queue length and a queue length minimum threshold, and terminating selected executed action process instances from the set of executed action process instances based on the minimum queue relationship. Thus, embodiments of the present disclosure provide a solution to DPPMS processing resource inefficiencies. provide.

[0100] Additionally, transmissions between the DPPMS and third-party systems may fail. Such transmission failures may result from loss of connection, power outages, or other technical and / or communication-based errors. The DPPMS may receive a transmission error in response to the failed transmission. Without a robust means of handling received transmission errors, the DPPMS may continue to become out of sync with one or more third-party device management systems and / or function inefficiently.

[0101] Accordingly, various embodiments of the present disclosure relate to methods, computer program products, and systems for robustly handling a received transmission error by a DPPMS in response to a failed transmission to a third-party device management system. Some embodiments are configured to receive the transmission error, identify an error classification associated with the transmission error, and identify an error handling instruction set associated with the error classification, the error handling instruction set including at least one error handling event, and execute the error handling instruction set to initiate the at least one error handling event. In some embodiments, the error classification is from the identified error classification set, which may include a “retryable error” classification and an “escalation error” classification. Exemplary embodiments are configured to, if the transmission error is classified as a retryable error, at least: identify a maximum retry threshold; identify a number of retry attempts; determine a retry relationship between the maximum retry threshold and the number of retry attempts; determine that the retry relationship satisfies the maximum retry threshold; determine a requested retry time; and add the failed transmission to a request queue for retransmission after the requested retry time has elapsed. Additionally or alternatively, exemplary embodiments are configured to add a transmission error to an escalation queue if the transmission error is classified as an escalation error. Thus, embodiments of the present disclosure improve DPPMS error handling.

[0102] As described above, the DPPMS may manage subscriber registrations associated with one or more device protection programs and may manage claims associated with one or more device protection programs. For example, a subscriber to a device protection program may submit a claim regarding a subscriber device that is damaged, lost, stolen, or otherwise affected. In some circumstances, the claim may be fraudulent. For example, a subscriber may submit a claim that a subscriber device has been stolen. If the claim is legitimate, the claim may be associated with the corresponding device protection program and fulfilled (e.g., the subscriber may be provided with a replacement device). However, if the claim is fraudulent (e.g., the subscriber has access to the device), the DPPMS should not fulfill the claim. While the DPPMS may utilize information that is known when the claim is received or being processed, such information may be insufficient to enable the DPPMS to determine whether the claim is fraudulent.

[0103] Accordingly, various embodiments of the present disclosure relate to methods, computer program products, and systems for executing an anti-fraud protocol including an instruction set in response to receiving a claim. The system of some embodiments identifies an anti-fraud protocol including an instruction set for at least one anti-fraud event based on real-time device information. The system of some embodiments retrieves real-time device information associated with a subscriber device associated with the claim. For example, some embodiments retrieve information associated with a device location application, the device location application configured to allow a user to receive a subscriber device location upon access. In the system of embodiments, the anti-fraud protocol retrieves information associated with a subscriber device associated with the claim, e.g., from a third-party device management system, from a third-party device management system. and real-time device information events capturing recent device location application usage to determine whether an attempt was made to locate a subscriber device associated with the device. Some embodiment systems are configured to make fraud determinations (e.g., determine whether a charge is fraudulent or not) based at least on the real-time device information.

[0104] definition As used herein, the terms “data,” “content,” “information,” and similar terms may be used interchangeably to refer to data that may be captured, transmitted, received, displayed, and / or stored in accordance with various exemplary embodiments. Accordingly, the use of such terms should not be taken to limit the spirit and scope of the present disclosure. Furthermore, when a computing device is described herein as receiving data from another computing device, it will be understood that the data may be received directly from the other computing device or indirectly via one or more intermediate computing devices, such as, for example, one or more servers, relays, routers, network access points, base stations, etc., sometimes referred to herein as a “network.” Similarly, when a computing device is described herein for transmitting data to another computing device, it will be understood that the data may be transmitted directly to the other computing device or indirectly via, for example, one or more intermediate computing devices, such as, for example, one or more servers, relays, routers, network access points, base stations, etc.

[0105] The term "device protection program" refers to a coverage or protection program for one or more user devices (e.g., subscriber devices as defined herein). A device protection program may facilitate device replacement, repair, or other fulfillment options in response to damage, failure, and / or loss of a subscriber device. A device protection program may allow a subscriber to repair, replace, or otherwise modify a subscriber device at a fixed percentage frequency at predetermined intervals (e.g., monthly or yearly) to restore the device to a working condition or to submit a claim to replace the device. In some cases, a device protection program may include primary or supplemental insurance, extended warranties, or other coverage for potential loss or failure of a device. In some embodiments, a device protection program may cover multiple devices associated with a single user.

[0106] The term "subscriber device" refers to an electronic computing device, component, or system associated with a user who is enrolled or currently enrolled in an associated device protection program. In some embodiments, a subscriber device is associated with one or more identifiers that uniquely identify the subscriber device, including, but not limited to, a DPPMS management identifier, an International Mobile Equipment Identity (IMEI), a serial number, and a subscriber identity module (SIM) number. Examples of subscriber devices include one of the following devices associated with a device protection program: a personal device, an enterprise device, a mobile phone (such as a smartphone), a personal computer, a laptop computer, a tablet, a consumer electronics device, a network device, an automobile, etc.

[0107] The term "subscriber identifier data object" refers to a text string, numeric value, code, or other data type that includes a unique identifier associated with a particular subscriber profile data object subscribed to a device protection program and / or a particular device subscribed to a device protection program. An exemplary subscriber identifier data object is a unique identifier associated with a particular subscriber device and / or a particular device that is subscribed to a device protection program. an alphanumeric string associated with the subscription. In some embodiments, the subscriber identifier data object is at least one from the group including an IMEI, an Internet Protocol address (IP or IP number), other device identifier, a randomly generated numeric and / or alphanumeric unique identifier, etc. In some embodiments, the subscriber identifier data object further includes:

[0108] The term “subscriber information” refers to data or information that may be used by the device protection program management system that is associated with a subscriber device and / or subscriber user associated with a particular device protection program. The subscriber information may include a subscriber identifier data object, a subscriber name, subscriber contact information, etc. In some embodiments, the subscriber information is associated only with a particular subscriber device or with a particular group of subscriber devices and does not include any information regarding the corresponding subscriber user (e.g., the human owner and / or controller of the subscriber device(s)). In some such embodiments, a received billing data object associated with a subscriber device may require supplemental information that identifies the user associated with the subscriber device. In another exemplary embodiment, the subscriber information includes a subscriber identifier data object that uniquely identifies a subscriber and / or subscriber device associated with a device protection program.

[0109] The term “subscriber profile data object” refers to a stored set of information containing information regarding a subscription to a device protection program associated with a user or a particular subscriber device. In some embodiments, a subscriber profile data object includes one or more of the following: an entity or username, one or more contact information identifiers (e.g., email, phone number, address, etc.), a device type, a device identifier (e.g., IMEI), a subscriber identifier data object, a subscription identifier, or other subscriber information. A subscriber profile data object includes information for analysis when a billing data object associated with the subscriber profile data object is received (e.g., a billing data object requesting repair and / or replacement of a subscriber device associated with the subscriber profile data object). In some embodiments where the subscriber profile data object identifies only a subscriber device (or subscriber device group), additional information associated with the submitted billing data object may be required to facilitate processing. For example, in some embodiments, in situations where a billing data object is submitted through a claims processing call center system, at least the invoice information and shipping information associated with the billing data object must be submitted for processing. Additionally or alternatively, in some embodiments, in situations where a billing data object is submitted via a web portal (e.g., submitted by a user via a client device), at least information identifying the particular owner of the subscriber device, billing information, shipping information, and / or additional billing information may be transmitted via the web portal for processing.

[0110] The term "registration management request data object" refers to data or information received by a device protection program management system to modify a subscriber profile data object. An exemplary registration management request data object represents a request to create a new subscriber profile data object associated with a selected device protection program in the device protection program management system. In some embodiments, an exemplary registration management request data object includes a "registration subscription request data object," which represents a request to register a new subscriber associated with a selected device protection program. In some embodiments, the registration subscription request data object includes at least (1) a device identifier (e.g., IMEI, MSN, MEID, etc.), and / or (2) a subscriber profile identifier (e.g., account number). and such information can be used to identify a particular subscriber profile data object for processing a future submitted claim data object(s). In another example, an exemplary enrollment management request data object represents a request to cancel a registered DPPMS subscriber profile data object associated with a selected device protection program at a device protection program management system. For example, in some embodiments, an exemplary enrollment management request data object includes a registration cancellation request data object, which represents a request to cancel a registered subscriber associated with a selected device protection program. In some embodiments, the enrollment management request data object includes subscriber information identifying the corresponding subscriber profile data object. In some embodiments, the enrollment management request data object includes subscriber information identifying the corresponding subscriber device.

[0111] The terms “device protection program management system” and “DPPMS” refer to a hardware and / or software system, or combination of hardware and software, controlled by a provider entity and configured to facilitate a device protection program, and may be configured to communicate and synchronize with one or more third-party systems. The device protection program management system may perform one or more of subscriber registration of DPPMS subscriber profile data objects associated with the device protection program, fraud prevention of claims associated with the device protection program, and / or fulfillment of subscriber claims associated with the device protection program. In exemplary embodiments, the device protection program management system includes at least an enrollment management subsystem, a fraud prevention subsystem, and a fulfillment subsystem. In some embodiments, the device protection program management system includes a payment subsystem and / or a policy subsystem. In some embodiments, the DPPMS includes or is in communication with a payment subsystem or equivalent service. In some embodiments, the DPPMS includes a payment system as one of the subsystems of the enrollment management subsystem, the fraud prevention subsystem, or the fulfillment subsystem. In some embodiments, the DPPMS includes a policy subsystem or equivalent service as one of the subsystems of the enrollment management subsystem, the fraud prevention subsystem, or the fulfillment subsystem.

[0112] The term "DPPMS subscriber profile data object" refers to a subscriber profile data object, or equivalent information, stored in the DPPMS, a subsystem within the DPPMS, or an associated data store. In an exemplary embodiment, one or more databases are configured to store DPPMS subscriber profile data objects in a particular format, the stored information set including information regarding subscriptions to device protection programs associated with users or client devices.

[0113] The term "third-party device management system" refers to a hardware and / or software system managed by a third party that is configured to provide third-party information and / or services. In some exemplary aspects, for example, the third-party system is configured to store, retrieve, access, and / or otherwise manage at least one subscriber profile data object. In some embodiments, the third-party profiling system is a subsystem within the third-party device management system for managing subscriber profile data objects. In some embodiments, the third-party device management system may be configured to store, retrieve, access, and / or otherwise manage information equivalent to a third-party subscriber profile data object. In some embodiments, the DPPMS communicates with the third-party device management system, or multiple third-party device management systems, by using an application program interface (API). It is configured as follows.

[0114] The term "third-party subscriber profile data object" refers to a subscriber profile data object or equivalent information stored in a third-party device management system. An exemplary third-party subscriber profile data object is a carrier subscriber profile data object maintained by a mobile carrier when a new user device is purchased and the user enrolls in a device protection program through the mobile carrier.

[0115] It should be understood that in some embodiments, multiple systems store multiple instances of a single subscriber profile data object, or multiple profile data objects associated with a subscriber or subscriber device. For example, in some embodiments, the DPPMS and a third party may each have profiles associated with a particular subscriber or subscriber device, e.g., multiple protection programs associated with the same device (e.g., warranties and extended warranties provided by a manufacturer, or insurance coverage provided by a provider entity via the DPPMS). In some embodiments, a third party may store subscriber profile data objects that are unrelated to a protection product (e.g., a carrier that provides wired or wireless communication service to a subscriber device, or a retailer that stores customer information associated with a subscriber device). Furthermore, in some embodiments in which multiple systems store multiple instances of a single subscriber profile data object, each instance is stored in a format that is independent of the formats of the other instances. For example, in an exemplary embodiment, the DPPMS stores a DPPMS subscriber profile data object associated with a selected subscription to a device protection program, and the third-party device management system stores a third-party subscriber profile data object associated with the same subscription to the device protection program. In this exemplary embodiment, the DPPMS subscriber profile data objects may be stored according to a first profile format, and the third-party subscriber profile data objects may be stored according to a second profile format.

[0116] The term "third-party registration status" refers to data or information that indicates whether a third-party subscriber profile data object exists in a third-party device management system. In some embodiments, the third-party registration status indicates whether a particular third-party profile associated with particular identification information (e.g., subscriber information) exists in a third-party device management system.

[0117] The term "third-party registration status request data object" refers to data or information sent by the DPPMS to a third-party device management system requesting identification of whether the third-party device management system contains a stored profile data object associated with a particular subscriber identifier data object. A particular third-party registration status request data object causes the third-party device management system to query a third-party profile database for the associated third-party subscriber profile data object. In some embodiments, multiple attempts to transmit the third-party registration status request data object are made, with each attempt being identifiable based on the number of attempts associated with the transmission (e.g., a first third-party registration status request data object, a second third-party registration status request data object, a third third-party registration status request data object, etc.).

[0118] The term "Third Party Registration Status Response Data Object" refers to a Third Party

[0014] This refers to data or information sent by a third-party device management system to a DPPMS in response to a third-party registration status request data object that includes a third-party registration status. In some embodiments, the third-party registration status response data object includes a third-party subscriber profile data object or equivalent information associated with the third-party registration status request data object.

[0119] The term "third-party subscriber registration request data object" refers to data or information sent by the DPPMS to a third-party device management system and configured to cause the third-party device management system to create or update a third-party subscriber profile data object based on the third-party subscriber registration request data object. In some embodiments, the third-party subscriber registration request data object includes subscriber information and causes the third-party device management system to create or update a third-party subscriber profile data object based on the subscriber information. In some embodiments, multiple attempts to transmit the third-party subscriber registration request data object are made, with each attempt being identifiable based on the number of attempts associated with the transmission (e.g., a first third-party subscriber registration request data object, a second third-party subscriber registration request data object, a third third-party subscriber registration request data object, etc.).

[0120] The term "third-party subscriber registration response" refers to data or information sent by a third-party device management system to a DPPMS in response to a third-party subscriber registration request data object that indicates whether the third-party device management system successfully created a third-party subscriber profile data object.

[0121] The term "third-party subscriber cancellation request data object" refers to data or information sent by the DPPMS to a third-party device management system and configured to cause the system to cancel, such as by deleting, a third-party subscriber profile data object. In some embodiments, the third-party subscriber registration request data object includes subscriber information and causes the third-party device management system to identify and delete the third-party subscriber profile data object associated with the subscriber information.

[0122] The term "third-party subscriber cancellation response" refers to data or information sent by a third-party device management system to a DPPMS in response to a third-party subscriber registration request data object that indicates whether the third-party device management system successfully canceled the third-party subscriber profile data object.

[0123] The term "third-party registration management request data object" generally refers to a third-party subscriber registration request data object, a third-party subscriber cancellation request data object, or data or information equivalent to either request.

[0124] The term "third-party registration management response" generally refers to a third-party subscriber registration response, a third-party subscriber cancellation response, or data or information equivalent to either response.

[0125] The term "transmission error" refers to incomplete, unreadable, corrupted, or inaccurate communication between the DPPMS and a third-party system. An exemplary transmission error is an incomplete or corrupted third-party subscriber registration request data object between the DPPMS and a third-party device management system. Another exemplary transmission error is an incomplete or corrupted third-party subscriber registration request data object between the DPPMS and a third-party device management system. An incomplete third-party subscriber cancellation request data object between S and the third-party device management system. Other non-limiting examples of transmission errors include a third-party system error (e.g., indicating the third-party system is unable to receive and / or respond to the request), a protection program duplication error (e.g., indicating the subscriber is already registered with the device protection program or an associated device protection program when the subscriber registration request is sent in association with the device protection program), a request processing error (e.g., indicating the transmitted request data object could not be processed at this time), and / or a request timeout error (e.g., indicating the response signal associated with the request data object has not been received for longer than a request timeout threshold).

[0126] The term "third-party subscriber cancellation response" refers to data or information sent by a third-party device management system to a DPPMS in response to a third-party subscriber registration request data object that indicates whether the third-party device management system successfully canceled the third-party subscriber profile data object.

[0127] The term "third-party subscriber registration error" refers to data or information received by the DPPMS in response to a third-party subscriber registration request data object that indicates that transmission of the third-party subscriber registration request data object to the third-party device management system was unsuccessful, incomplete, or otherwise unsuccessful.

[0128] The term "transmission error data object" refers to data or information received by the DPPMS in response to a transmission error indicating that a previously attempted transmission to a third-party system failed. In some embodiments, the DPPMS receives the transmission error in response to transmitting a third-party registration status request data object. In some embodiments, the DPPMS receives the transmission error data object in response to a third-party subscriber registration request data object. In some embodiments, the transmission error includes information indicative of the transmission error, such as information identifying the particular third-party registration status request data object that failed or the particular third-party subscriber registration request data object that failed. In some embodiments, the transmission error data object is generated by the DPPMS in response to the DPPMS detecting a transmission error when sending information to or receiving information from the third-party system. For example, a transmission error data object may be generated if a third-party system initiates communication with the DPPMS but the message is incomplete or insufficient information is received.

[0129] The term "error classification set" refers to one or more predefined error classifications with which a received error may be associated. Exemplary error classification sets include "retryable errors" and "escalation errors." In a particular example, errors identified as retryable errors are associated with a first set of error handling instructions (e.g., determine a request retry time and attempt subsequent transmission of the failed request after the retry time has elapsed), and escalation errors are associated with a second set of error handling instructions (e.g., transmit an error report to a specific subsystem of the DPPMS or a third-party system for manual intervention).

[0130] The term "error classification data object" refers to an identifier associated with an error received by the DPPMS that identifies the error type and a corresponding set of error handling instructions that represent an error handling protocol. In an exemplary embodiment, a particular error classification is: The first class identifies retryable errors, and the second class identifies escalation errors.

[0131] The term "request retry time" refers to the amount of time that must elapse between subsequent transmission attempts, such as a third-party registration status request data object or a third-party subscriber registration request data object, in response to a retryable error received after a failed transmission from the DPPMS to a third-party device management system.

[0132] The term "retry attempts" refers to the number of attempted or failed transmissions of a request between the DPPMS and the third-party device management system. In an exemplary embodiment, the DPPMS tracks the number of retry attempts, such that the number of failed transmissions is identifiable using the number of retry attempts.

[0133] The term "retry maximum threshold" refers to the maximum number of retransmission attempts allowed in response to a particular retryable error. In an exemplary embodiment, the DPPMS sets a determinable retry maximum threshold (e.g., a retry maximum of 10) so that the DPPMS may not attempt to retransmit a failed transmission beyond the retry maximum threshold.

[0134] The term “retry relationship” refers to a comparison or other relationship between the number of retry attempts and a retry threshold. In some embodiments, the retry relationship is associated with a “retry relationship result data object,” which refers to electronically managed data, e.g., a Boolean data value, indicating whether the DPPMS has determined that the retry relationship is satisfied. In some embodiments, the retry relationship is embodied by a “retry max relationship” that represents a comparison between the retry attempt count and a retry max threshold, such that the corresponding retry relationship result data object indicates that the relationship is satisfied if the retry attempt count is less than the retry max threshold or is less than or equal to the retry max threshold. In another particular example, the retry relationship is embodied by a “retry min relationship” that represents a comparison between the retry attempt count and a retry min threshold, such that the corresponding retry relationship result data object indicates that the relationship is satisfied if the retry attempt count is greater than the retry max threshold or is greater than or equal to the retry max threshold.

[0135] The term “error handling instruction set” refers to computer code instructions and / or electronic data that represent one or more actions that the DPPMS performs in response to receiving an error in response to an attempted transmission to a third-party device management system. In some embodiments, different error handling instruction sets are each associated with a different error classification. In some embodiments, the error handling instruction set defines a retry protocol that includes one or more attempts to retry a failed transmission. For example, in an exemplary embodiment, the requested retry time is determined by an exponential backoff, and the requested retry time for a subsequent transmission attempt is determined by doubling the previous requested retry time (e.g., waiting 5 minutes before retransmission attempt number 1, waiting 10 minutes before retransmission attempt number 2, waiting 20 minutes between retransmission attempt number 3, and waiting 40 minutes between retransmission attempt number 4). Alternatively or additionally, another error handling instruction set includes determining a maximum retry threshold. For example, in some embodiments, the DPPMS is configured to determine a maximum retry threshold and track the number of retry attempts according to the identified error handling instruction set, such that a retry relationship can be determined based on the number of retry attempts and the maximum retry threshold. In exemplary embodiments, the DPPMS is configured to determine whether the retry relationship satisfies a retry maximum threshold. For example, in exemplary embodiments, the retry relationship satisfies a retry maximum threshold when the number of retry attempts is equal to the retry maximum threshold. In some embodiments, the error handling instruction set may define an error handling protocol that includes various actions that are variable and dependent on the DPPMS and / or third-party systems. In some embodiments, the server load may be The error handling protocol may be used to determine the action taken in the error handling protocol depending on whether any system is saturated or whether the response time from any system is too long. In some embodiments, the third party system may instruct the DPPMS to set or change the error handling protocol.

[0136] The term "error handling event" refers to a data transmission, data transformation, or other action performed by the DPPMS as part of an initiated error handling instruction set. In some embodiments, a particular error handling instruction set embodies multiple error handling events that define an error handling protocol for responding to a retryable error received in response to a failed transmission (e.g., a third-party subscriber registration error received in response to a failed third-party subscriber registration request data object). An exemplary error handling instruction set represents the following error handling events: [1] identifying a maximum retry threshold; [2] identifying a number of retry attempts; [3] determining a retry relationship based on the number of retry attempts and the maximum retry threshold; [4] determining whether the retry relationship satisfies the maximum retry threshold (e.g., by comparing whether the number of retry attempts is equal to the identified maximum retry threshold); and if not, [5] retransmitting the failed transmission; or if so, [6] adding the retryable error to an error escalation queue.

[0137] The term "escalation queue" refers to a set of stored transmission errors, such as escalated errors and / or retryable errors that have been escalated according to a set of error handling instructions. In some embodiments, the escalation queue is stored in a data store associated with the DPPMS. In some embodiments, the DPPMS creates and manages an escalation queue configured to store one or more third-party transmission errors. In some embodiments, the escalation queue stores the third-party transmission errors until a determined time at which the DPPMS transmits the third-party transmission errors or equivalent information to one or more third-party error handling systems. In some embodiments, the escalation queue stores the third-party transmission errors until a human operator performs a manual action associated with the third-party transmission error.

[0138] The term "error escalation request" refers to data or information sent by a DPPMS to an error handling subsystem of the DPPMS, an error handling system associated with the DPPMS, or a third-party error handling system. In some embodiments, the DPPMS transmits the error escalation request in an error handling event as part of a set of error handling instructions executed and / or initiated in response to receiving an escalation error. In some embodiments, the DPPMS transmits the error escalation request in an error handling event as part of a set of error handling instructions when the number of retry attempts equals a maximum retry threshold.

[0139] The term "third-party case" refers to a set of information generated, obtained, and / or otherwise accumulated by a third-party system in response to a device incident associated with a subscriber device. For example, a user may report a loss incident (e.g., a lost or stolen subscriber device) to a third-party system. In an exemplary system, the third-party system generates a third-party case associated with the subscriber device and the loss incident. In some embodiments, the third-party case includes "third-party case information." Third-party case information refers to information stored in or associated with the third-party case. In an exemplary embodiment, the case information includes a third-party case identifier, a subscriber identifier data object and / or subscriber device identifier, a subscriber name, a subscriber report type, and / or a third-party case identifier. In addition, in some embodiments, the third-party case information includes subscriber authentication information to verify that the third-party system authenticated the user reporting the device incident.

[0140] The terms “claim data object” and “claim” refer to electronic management data including a set of information generated or received by a DPPMS associated with a request for compensation for a subscriber device in response to a loss or policy incident associated with a device protection program. In some embodiments, the claim data object includes at least (1) device identification information and / or a corresponding subscription profile associated with a particular subscriber device, (2) a timestamp of the date of loss, and (3) a claim type (e.g., loss, theft, accidental damage, mechanical breakdown, etc.). In some embodiments, the claim data object further includes (1) third-party case information associated with a corresponding third-party case, and / or (2) additional subscription information, a subscription profile, or a subscription profile identifier. In some embodiments, the claim data object is received directly through the DPPMS, for example, via a web portal accessed by a user via a client device. In some embodiments, the claim data object is generated after the DPPMS receives user case information associated with the received third-party case information. The claim data object may be associated with a request for compensation, repair, or replacement of a subscriber device.

[0141] The term "billing information" refers to data related to a bill being generated in association with a device protection program. Additionally, in some embodiments, the billing information includes information associated with the bill, a subscriber associated with the bill, subscriber information associated with the bill, a subscriber device associated with the bill, etc. In an exemplary embodiment, the billing information includes at least third-party case information received from a third-party system.

[0142] The term "claims processing protocol" refers to one or more actions performed to execute, process, or fulfill a claim. In some embodiments, the DPPMS, or a fulfillment subsystem of the DPPMS, is configured to identify a claims processing protocol associated with the claim and / or claim information. Additionally or alternatively, in some embodiments, the DPPMS (e.g., the fulfillment subsystem of the DPPMS) is configured to execute the claims processing protocol.

[0143] The term "device information" refers to data, information, etc. associated with a subscriber device, one or more components of a subscriber device, and / or usage of a subscriber device. Examples of device information include one or more device identifiers, serial numbers, component identifiers or serial numbers, device model or manufacturing information, etc. Further examples of device information include location data associated with a subscriber device, application access information (e.g., the last recorded run of a particular application), subscriber device settings, etc.

[0144] The term "real-time" refers to obtaining specific information at a desired time or in response to a request for immediate or near-immediate use of the data (e.g., within a predetermined time frame, e.g., within 5 seconds, within 1 minute, etc.). In some embodiments, device information may be obtained in real time, referred to as "real-time device information." In some embodiments, the DPPMS obtains real-time device information from a third-party device management system, which is configured to (1) identify the real-time device information by contacting the subscriber device in real time, or (2) 2) is configured to obtain and store some or all of the real-time device information from the subscriber device at a time prior to, for example, when, a third-party device management system is notified of a billing associated with the subscriber device.

[0145] In some embodiments, real-time device information includes device identification information obtained in real time, such as a device identifier, a MAC address, an IP address, etc. Alternatively, or in addition, in other embodiments, real-time device information refers to information associated with the usage of a subscriber device (e.g., whether one or more apps were accessed, when one or more apps were accessed, whether one or more location settings were enabled on the subscriber device, etc.).

[0146] For example, in some embodiments, the device location application is accessible from the second user device, and the device location application is configured to provide a location associated with the subscriber device. Thus, in some embodiments, the real-time device information includes a device location application status indicating whether the device location application was enabled when the user submitted the incident to the third-party device management system or DPPMS. In some embodiments, the device lost application is accessible from the second user device, and the device lost application is configured to disable some or all functionality associated with the subscriber device and / or display information associated with the subscriber (e.g., contact information), and restore functionality associated with the device lost application status by setting a device lost status indicating that the subscriber device is lost and / or by setting a device lost status indicating that the subscriber device is not lost. Thus, in some embodiments, the real-time device information includes a device lost status associated with the device lost application. It should be understood that in some embodiments, the device lost application and the device location application are provided via a single software application, web module, or the like.

[0147] Additionally or alternatively, in some embodiments, real-time device information refers to information associated with a subscriber device and / or previous incidents reported by associated with the associated subscriber. For example, real-time device information includes an open repair list associated with the subscriber device (including currently pending repairs associated with the subscriber device), a remaining list of incidents, and / or a previous replacement status (indicating whether the subscriber device was previously replaced, such as via a third-party device management system or billing associated with a DPPMS).

[0148] The term "anti-fraud protocol" refers to one or more actions taken by a DPPMS or a subsystem within the DPPMS (e.g., an anti-fraud subsystem) in response to receiving billing information. An anti-fraud protocol includes one or more actions designed to detect fraudulent billing information. A particular example of an anti-fraud protocol includes one or many anti-fraud events.

[0149] The term "anti-fraud event" refers to a data transmission, data transformation, or other action that the DPPMS or a subsystem within the DPPMS (e.g., an anti-fraud subsystem) performs as part of an anti-fraud protocol. An exemplary specific anti-fraud protocol includes the following anti-fraud events: [1] obtaining real-time device information associated with the most recent device location application usage from a subscriber device; and [2] identifying whether the real-time device information is within an acceptable device location threshold. In an exemplary embodiment, the anti-fraud event includes obtaining, in real time from the subscriber device or a system linked to the subscriber device, the latest usage information of a software application configured to locate the subscriber device, determining a relationship between the latest usage information and the device location threshold, and identifying whether the real-time obtained usage information meets the device location threshold.

[0150] The terms "action process" and "action process instance" refer to a microservice, software module instance, etc., executed or managed by the DPPMS or a sub-module within the DPPMS that is configured to fulfill or otherwise process a particular type of incoming request transmitted from a third-party system. An exemplary action process is an instance of a software module configured to process one or more new registration requests received from a third-party system, such as a mobile carrier system. In some embodiments, the action process executes in one or more process threads configured to process one or more outstanding actions stored in one or more action queues.

[0151] Multiple action process instances ("action processes") can be running in parallel at a given time. Thus, the term "number of running instances" refers to the total number of action processes running.

[0152] The terms "process thread(s)" or "thread(s)" refer to one or more streams of tasks executing simultaneously or semi-simultaneously on a single computing instance or on multiple computing instances, e.g., one or more processors, or one or more processors distributed across one or more servers associated with one or more processing modules within a processor. An exemplary process thread is configured to complete a registration request transmitted from a third-party system. In some embodiments, an executed action process includes one or more process threads for completing requests transmitted to the action process. In some embodiments, an action process is associated with a "process thread count maximum" that represents the total number of process threads that can be executed and associated with a particular action process. The term "process thread count" refers to the total number of process threads executed in or otherwise associated with a particular action process.

[0153] The term "action queue" refers to a set of pending requests received by one or more third-party systems to be processed by one or more action processes. An exemplary action queue is configured to store registration requests transmitted to the DPPMS by third-party systems, such as third-party device management systems. Action queues are associated with a queue length, which refers to the number of pending requests present in the corresponding action queue.

[0154] The term "queue relationship" refers to a specific mathematical or algorithmic comparison between a queue length and a queue length threshold. A queue relationship is associated with a "queue relationship result data object," which refers to electronically managed data, e.g., a Boolean data value, indicating whether the DPPMS has determined that the queue relationship is satisfied. In a particular example, a queue relationship is embodied by a "maximum queue relationship" that represents a comparison between a queue length and a queue length maximum threshold, such that the corresponding queue relationship result data object indicates that the relationship is satisfied if the queue length is less than or equal to the maximum queue threshold. In another particular example, a queue relationship is embodied by a "minimum queue relationship" that represents a comparison between a queue length and a queue length minimum threshold, such that the corresponding queue relationship result data object indicates that the relationship is satisfied if the queue length is greater than the minimum queue threshold. If the minimum cue threshold is less than or equal to the minimum cue threshold, the corresponding cue relationship result data object will indicate that the relationship is satisfied.

[0155] The term “queue length threshold” refers to a number that, when met, triggers the DPPMS to update the action process instance set for a particular action queue’s queue length queue relationship. In a particular example, the queue length threshold is a “queue length maximum threshold” and represents the maximum queue length for which the action process instance set needs to be updated. In some embodiments, the maximum queue relationship meets the queue length maximum threshold when the queue length exceeds the queue length maximum threshold. In some embodiments, when the maximum queue relationship meets the queue length maximum threshold, such as by exceeding the queue length maximum threshold, a new action process instance is executed by the DPPMS and / or added to the action process instance set. In a particular example, the queue length threshold is a “queue length minimum threshold” and represents the minimum queue length for which the action process instance set needs to be updated. In some embodiments, the minimum queue relationship meets the queue length minimum threshold when the queue length is less than the queue length minimum threshold. In some embodiments, when the minimum queue relationship meets the queue length minimum threshold, such as when the queue length is less than the queue length minimum threshold, the selected action process instance is terminated from the action process instance set to be executed.

[0156] In some embodiments, the queue length threshold, queue length minimum threshold, and / or queue length maximum threshold are each determined, identified, or otherwise set numbers (e.g., 20). In some embodiments, the queue length maximum threshold and queue length minimum threshold are set to equivalent numbers. In some embodiments, the queue length maximum threshold and queue length minimum threshold are set to unequal numbers. For example, in certain embodiments, the queue length minimum threshold is less than the queue length maximum threshold (e.g., a queue length minimum threshold of 20 and a queue length maximum threshold of 100). In some embodiments, the queue length minimum threshold is zero so that the action process instance to be executed is scaled down once all outstanding actions in the action queue are resolved.

[0157] The term "action process instance count maximum" refers to the maximum number of action processes that may be initialized and executed at one time. In an exemplary embodiment, each action process is associated with a number of API transactions to be executed, and the action process instance count maximum is set according to the maximum number of API transactions allowed per unit time for all executed action processes, or all executed actions associated with a particular action queue or outstanding actions of a particular type.

[0158] The term "action process instance count minimum" refers to the minimum number of action processes that may be initialized and running at one time. Some embodiments determine an action process instance count minimum. In some embodiments, the action process instance count minimum is predetermined.

[0159] The term "maximum process instance relationship" refers to a mathematical or algorithmic comparison between the number of executed instances and an action process instance count maximum threshold. The maximum process instance relationship is associated with electronically managed data, e.g., a "maximum process instance relationship result data object," which refers to a Boolean data value indicating whether the DPPMS determined that the maximum process instance relationship was satisfied. In some embodiments, the maximum process instance relationship is a comparison that satisfies the action process instance count maximum if the corresponding number of executed instances is less than or equal to or less than the action process instance count maximum.

[0160] The term "minimum process instance relationship" refers to a mathematical or algorithmic comparison between the number of executed instances and an action process instance count minimum threshold. The maximum process instance relationship is associated with electronically managed data, e.g., a "minimum process instance relationship result data object," which refers to a Boolean data value indicating whether the DPPMS determined that the minimum process instance relationship was met. In some embodiments, the process instance relationship is a comparison where the action process instance count minimum threshold is met if the corresponding number of executed instances is greater than the action process instance count minimum value.

[0161] The term "system synchronization event" refers to one or more actions performed by one or more subsystems within the DPPMS or DPPS to synchronize one or more DPPMS subscriber profile data objects according to a third-party subscriber profile data object. For example, in an exemplary embodiment, the DPPMS is configured to identify a third-party subscriber profile data object and a DPPMS subscriber profile data object that contain inconsistent information, and synchronize the DPPMS subscriber profile data object based on the information in the third-party subscriber profile data object. Alternatively or additionally, in another exemplary embodiment, the DPPMS is configured to identify a third-party device management system that canceled a third-party subscriber profile data object associated with a subscriber identifier based on a received third-party registration status response data object, and cancel the DPPMS subscriber profile data object associated with the subscriber identifier data object. In some embodiments, the system synchronization event includes transmitting one or more registration management requests. For example, in some embodiments, the DPPMS transmits a third-party subscriber registration request data object or a third-party subscriber cancellation request data object to synchronize a third-party device management system. In other embodiments, the DPPMS updates one or more subscriber profiles, or the subscriber profiles of one or more subsystems, during a system synchronization event.

[0162] System Architecture The methods, apparatus, systems, and computer program products of the present disclosure may be embodied by any of a variety of devices in a variety of system architectures. For example, the methods, apparatus, systems, and computer program products of the exemplary embodiments may be embodied by one or more network devices, such as servers or other entities, configured to communicate with one or more devices, such as subscriber devices, third-party devices, and one or more third-party servers. Exemplary embodiments include various networked devices operating as servers. Additionally or alternatively, the methods, apparatus, systems, and / or computer program products of the exemplary embodiments may be embodied by one or more software modules configured to perform some or all of the operations disclosed and executed herein and executed on one or more hardware modules or systems, such as one or more servers connected to a network.

[0163] In this regard, Figure 1 is a block diagram illustrating a simplified exemplary system in which embodiments of the present disclosure may operate. Specifically, the system includes a device protection program management server 102 and third-party device management systems 118A-118C. Each third-party device management system may be connected to at least the device protection program management server 102 via a network, such as a communications network 116.

[0164] The device protection program management server 102 may be associated with a number of circuit modules 104-114. In some embodiments, each of the modules 104-114 is embodied by hardware that communicates with the device protection program management server 102 and is specially configured to perform the operations associated with the particular module. In some example systems, some of the modules 104-114 are embodied by software running on a second server or hardware component that is configured to communicate with the device protection program management server 102.

[0165] The device protection program management server 102 may be configured to perform various tasks associated with managing subscriptions to device protection programs, such as by utilizing one or more software and / or hardware modules. The device protection program management server 102 may be configured to store and / or maintain a data store of subscribers associated with various device protection programs. A subscriber may be a person associated with one or more devices or the particular device itself. Registration subscriptions and / or cancellation requests associated with a subscriber may be received directly from one or more users and / or subscribing devices, such as client devices 120, or from one or more third-party servers. For example, the device protection program management server 102 may be configured to register new subscribers associated with a device protection plan. Additionally, for example, the device protection program management server 102 may be configured to cancel subscribers associated with a device protection plan.

[0166] The device protection program management server 102 may be configured to communicate with one or more third-party device management systems configured for registration and / or management of third-party subscriber profile data objects, such as third-party device management systems 118A-118C (e.g., via a third-party profiling system associated with the third-party device management systems or a subsystem of the third-party device management systems). In some systems, the device protection program management server 102 may communicate with the third-party device management systems to verify, validate, receive, and / or synchronize registration status associated with one or more subscribers. For example, the third-party device management systems 118A-118C may each independently receive registration subscription request and / or registration cancellation request data objects associated with one or more device protection programs. Each third-party device management system may be associated with purchasing and / or protecting devices. For example, the third-party device management systems may include systems controlled by device vendors, device manufacturers, mobile carriers, or other entities that register users and / or devices with one or more device protection programs implemented by a provider entity associated with the device protection program management server 102.

[0167] The device protection program management server 102 may additionally provide synchronization and / or processing of registration subscription request data object(s) and / or registration cancellation request data object(s). For example, the device protection program management server may communicate with one or more other subsystems and / or components to synchronize subscriber profile(s) and / or corresponding information managed by each subsystem so that each of the subsystems may perform one or more actions associated with the stored information. For example, the device protection program management server 102 may synchronize subscriber profile registration data, along with third-party subscriber profile data, with payment systems and / or billing systems (not shown) to ensure such information is current and consistent. By synchronizing such systems, the device protection program management server 102 , allowing the systems to communicate to verify a particular subscriber's enrollment when billing occurs associated with the device protection program. In this regard, the device protection program management server 102 and / or third-party device management systems may utilize such synchronized data for purposes of verifying enrollment in the device protection program and to initiate the performance of appropriate services.

[0168] When a new device or device controller is subscribed to a device protection program through a third-party entity, the third-party device management system may be configured to manage the registration and reflect the subscriber associated with the corresponding third party in the list. Accordingly, the device protection program management server 102 may be configured to communicate with each third-party device management system to maintain a data store of all subscribers registered through all of the third parties. In other words, the device protection program management server 102 may communicate with each of the third-party device management systems 118A-118C to cancel and / or remove a subscriber from the subscriber data store associated with the device protection program management server 102 when the subscriber cancels through the third party, and / or may communicate with each of the third-party device management systems 118A-118C to add a new subscriber to the subscriber data store associated with the device protection program management server 102 when the new subscriber registers through the third-party system.

[0169] Examples of processes and operations performed in association with subscriber registration management are discussed further herein. Accordingly, the foregoing description is intended to provide an illustrative overview, and is not intended to limit the scope or spirit of embodiments of the present disclosure.

[0170] In some embodiments, the device protection program management server 102 of the DPPMS may be configured to perform various tasks associated with managing claims associated with device protection programs, utilizing means such as one or more software and / or hardware modules. The device protection program management server 102 may be configured, for example, to process one or more claims associated with one or more device protection programs. For example, a subscriber may utilize a client device to submit a claim associated with a device protection management program, through a third-party system, or directly to the device protection program management server 102. The device protection program management server 102 may then maintain an action queue configured to store one or more actions performed in association with the claim.

[0171] The device protection program management server 102 may be associated with means, such as modules 104-114, to perform the operations described above and further herein. For example, the registration module 104, or means embodying the registration module 104, may be configured to perform registration subscription and / or cancellation. In some embodiments herein, the registration module 104, or means embodying the registration module 104, includes a self-healing sub-module, such as a self-healing framework 110, configured to perform operations associated with maintaining a subscriber data store by communicating with one or more third-party device management systems.

[0172] Additionally or alternatively, the fraud prevention module 106, or means embodying the registration module 104, may be configured to perform one or more operations to analyze a claim to determine whether the claim is fraudulent, as described further herein. For example, in some embodiments, the fraud prevention module 106 is configured to identify an anti-fraud protocol and perform one or more anti-fraud steps in accordance with the anti-fraud protocol.

[0173] Additionally or alternatively, the fulfillment module 108, or means embodying the fulfillment module 108, may be configured to perform one or more actions to fulfill a submitted claim associated with a device protection program. For example, in some embodiments, the fulfillment module 108 is configured to execute one or more fulfillment events associated with the device protection program in response to a claim.

[0174] Additionally or alternatively, the error classification module 112, or a means for embodying the error classification module 112, may be configured to perform one or more operations to identify a transmission error. For example, when the device protection program management server 102 fails or loses connection to a third-party device management system, the device protection program management server 102 may receive a transmission error. The error classification module 112 may identify an error classification associated with the received transmission error and / or perform one or more actions based on the identified error classification. In particular embodiments, the error classification module 112 may be configured to perform one or more operations described below with respect to FIGS. 9 and 10.

[0175] Additionally or alternatively, workflow management module 114, or a means embodying workflow management module 114, may be configured to perform one or more operations for maintaining one or more action queues. For example, workflow management module 114 may be configured to manage an action queue of defaulted claims, an action queue of pending new registration subscription requests, and an action queue of pending cancel registration request data objects. In some embodiments, workflow management module 114 may manage one or more action processes configured to perform one or more operations associated with managing the corresponding action queues. In particular embodiments, workflow management module 114 may be configured to perform one or more operations described below with respect to FIGS. 6, 7A, and 7B.

[0176] In some embodiments, the device protection program management server 102 may be associated with one or more other subsystems for various or specialized purposes. For example, in some embodiments, the device protection program management server 102 may communicate with or be otherwise associated with a DPPMS payment subsystem for managing payment profiles, transaction information, and / or other payment processing information associated with enrolled subscribers. Additionally or alternatively, in some embodiments, the device protection program management server 102 may communicate with or be otherwise associated with a DPPMS policy subsystem for managing policy profiles, policy rules and / or requirement information, or other device protection policy information associated with enrolled subscribers. Additionally or alternatively, in some embodiments, the device protection program management server 102 may communicate with or be associated with a DPPMS inventory subsystem for managing an inventory of replacement devices (e.g., client devices that are not being used and / or are not configured for use) that may be provided to facilitate fulfillment of claims associated with a device protection program.

[0177] 2 illustrates a block diagram of an exemplary system that may be specifically configured in accordance with an embodiment of the present disclosure. Specifically, the depicted system includes a DPPMS 202, a third-party system 216, a third-party system 222, and client devices 228, 230, and 232. Each of these devices is configured to communicate over a network 234.

[0178] Client devices 228, 230, and 232 may be embodied by any computing device known in the art that may include one or more processors, memory, and communication interfaces for interacting with a network. Information received from client devices 228, 230, and 232 may be provided in various forms and via various methods. For example, client devices 228, 230, and 232 may be laptop computers, smartphones, netbooks, tablet computers, wearable devices, etc., including any of the devices described herein, and data may be provided and received via various modes of data transmission provided by these consumer devices. In some systems, one or more of client devices 228, 230, and 232 may be subscriber devices according to embodiments described herein. In other embodiments, client devices 228, 230, and 232 may be other devices controlled by subscriber users enrolled in at least one device protection program via DPPMS 202. In some embodiments, one or more of client devices 228, 230, and 232 may be utilized to transmit billing, registration subscription request, registration cancellation request data objects, etc. to a third party system, such as third party system 216 or 222, and / or to DPPMS 202. In an exemplary system, a client or user device may be both a subscriber device and a device utilized to transmit billing.

[0179] Third party systems 216 and 222 may be configured to perform at least one or more operations associated with enrolling in and / or canceling enrollment in a device protection program. As illustrated, each third party system may include a third party server, such as third party servers 218 and 224, and a third party database, such as third party databases 220 and 226. In some embodiments, the third party systems may be configured to perform additional operations, such as, for example, utilizing the third party server and third party database, an enrollment status check to determine whether a given subscriber is enrolled through a third party.

[0180] Third party servers, such as third party servers 218 and 224, may be configured to enable third party systems, such as third party systems 216 and 222, to communicate with a network, such as network 234. Each third party system may be configured to utilize a corresponding third party server to communicate with one or more client devices, such as client devices 228, 230, and 232. Additionally or alternatively, the third party systems may utilize a corresponding third party server to communicate with DPPMS 202.

[0181] Each third-party server may also be associated with, connected to, or otherwise in communication with a corresponding third-party database, such as third-party databases 220 and 226. The third-party database may be integrated with or separate from the corresponding server. In some systems, the third-party database may store at least subscriber information for one or more subscribers associated with the third-party system. For example, each subscriber registered through the third-party system may be associated with subscriber information stored in the third-party database such that the third-party system is configured to function as a third-party device management system. Additionally or alternatively, the third-party server may utilize the corresponding third-party database to perform the following functions in response to requests received from client devices, such as client devices 228, 230, and 232 (e.g., subscriber devices): , or may be configured to perform operations in response to one or more requests received from DPPMS 202. Specifically, a client device may register with the device protection program via third party system 222 through communication with third party server 224, which may register the user, storing the subscriber information, using third party database 226. Third party system 222 may communicate this new subscriber information to DPPMS 202 using third party server 224 and third party database 226, such as in response to a third party subscriber registration request data object.

[0182] Third-party databases 226 may each be embodied as a data storage device, such as network-attached storage (NAS) device(s), or as a separate database server(s). Third-party databases 220 and 226 may each include user data, subscriber data, subscriber information, subscriber identifier data objects, subscriber device information, or other data, among other data. It will be readily understood that each of third-party databases 220 and 226 may be a single database, multiple databases, or a combination of several components configured to store information. In some embodiments, each type of data and / or information stored may reside in a separate storage component.

[0183] The DPPMS, or DPPMS 202, may include various means for performing the myriad actions associated with device protection program management, such as subscriber registration, subscriber cancellation, error handling, billing management, etc. Accordingly, the DPPMS 202 may include various software and / or hardware submodules configured to perform one or more operations described herein. For example, as illustrated, the DPPMS 202 may include an enrollment management subsystem 204, a fraud prevention subsystem 206, and a fulfillment subsystem 208. Additionally or alternatively, one or all of the subsystems may be configured to communicate with one or more data stores, such as data store 210. As described herein, the circuits and subsystems of the DPPMS 202, in conjunction with software that configures the devices to perform the operations described herein, may be collectively embodied in one or more physical devices, causing the devices to operate locally or remotely relative to the provider entity.

[0184] The enrollment management subsystem 204 may include means, such as software and / or hardware, configured to perform various tasks associated with managing subscriber and / or subscriber device enrollment in the device protection program. For example, the enrollment management subsystem 204 may be configured to facilitate subscription to the device protection program in cooperation with other subsystems and / or the data store 210. In other words, the enrollment management subsystem 204 may be configured to facilitate adding newly insured and / or enrolled subscribers and / or subscriber devices to a list and / or stored data ledger of registered subscribers and / or subscriber devices in cooperation with other subsystems and / or the data store 210. The enrollment functionality may be applied in both a first situation for new subscriber enrollment, where a subscriber is added to a third-party device management system and to the DPPMS, and a second situation for synchronization between the DPPMS and a third-party device management system in the event of a discrepancy between the two systems. Additionally, the enrollment management subsystem 204 may include means, such as software and / or hardware, configured to perform cancellation of enrollment from the device protection program. In other words, the enrollment management subsystem 204, in conjunction with other subsystems and / or the data store 210, retrieves subscriber and / or subscriber device information from the device protection program in which the subscriber and / or subscriber device is currently enrolled. The system may be configured to facilitate cancellation of a registration. In some embodiment systems, registration subscription and / or cancellation may occur due to user communication with a third-party system, such as communication between a client device 228, 230, or 232 and one or more of the third-party systems 216 and 222. For example, a user may communicate with the third-party system 216 via the client device 228 (e.g., a mobile device) to register for the device protection program via the third-party system (e.g., via a mobile device carrier associated with the mobile device), which may then communicate with the DPPMS 202 to communicate that a new subscriber has registered. Additionally or alternatively, for cancellation, a user may communicate with the third-party system 216 via the client device 228 (e.g., a mobile device) to cancel a registration associated with the device protection program via the third-party system (e.g., a mobile device carrier associated with the mobile device), which may then communicate with the DPPMS 202 to identify that the user has canceled their subscription to the device protection program. The registration management subsystem 204 may be configured to perform other operations to maintain an accurate subscriber and / or subscriber device list so that registered subscribers and / or subscriber devices are identified in association with the particular device protection program with which they are registered and subsequent billing can be processed appropriately (e.g., via fulfillment, etc.).

[0185] The anti-fraud subsystem 206 may include means, such as software and / or hardware, configured to detect fraudulent claims associated with a device protection program. For example, the anti-fraud subsystem 206 may be configured to identify and execute an anti-fraud protocol in response to receiving a claim or claim information. The anti-fraud subsystem may execute in conjunction with the fulfillment subsystem and / or the registration subsystem to detect fraudulent activity in the claim fulfillment and / or registration process. The anti-fraud protocol may include one or more anti-fraud events, each of which may affect the fraudulent claim determination of the anti-fraud subsystem 206. In certain exemplary systems, the anti-fraud subsystem 206 is configured to execute certain anti-fraud events by obtaining real-time device information associated with or from the subscriber device to determine actions taken by the user with respect to the subscriber device.

[0186] For example, the fraud prevention subsystem 206 may obtain real-time device information from a third-party device management system via one or more APIs in response to a claim submission or an indication of fraudulent activity. For example, the fraud prevention subsystem 206 may communicate with a third-party device management system via one or more APIs to obtain real-time device information captured from a subscriber device when a claim is reported to the DPPMS or the third-party device management system.

[0187] In some embodiments, the fraud prevention subsystem 206 obtains a device location application status from the third-party device management system in real time, which may indicate whether the device location application was enabled when the incident was reported. The fraud prevention subsystem 206 may utilize the device location application status to determine to reject the claim as a fraud risk based on at least the device location application status and the third-party identity associated with the third-party device management system. For example, in some embodiments, if the third-party device management system is a device manufacturer system (e.g., an OEM system), the device location application status may indicate that the device location application is not enabled (and Thus, if the location of the subscriber device cannot be determined using the device location application, the fraud prevention subsystem 206 may deny the claim based on fraud risk.

[0188] In some embodiments, the fraud prevention subsystem 206 obtains a device loss status from the third-party device management system in real time, indicating whether a device loss application was utilized to set the device loss status to lost before the incident was reported. In some embodiments, the fraud prevention subsystem 206 determines a fraud risk associated with the claim based on at least the device loss status, and / or at least the device loss status and the device location application status. In an example embodiment, if the third-party device management system from which the claim originated is the device manufacturer, the fraud prevention subsystem 206 may discontinue approving the claim if the device location application status indicates that the device location application is enabled but the corresponding device loss status is not set to lost mode. In some embodiments, the device loss status may be stored by a system and / or database associated with the device loss application and may be accessed by the fraud prevention subsystem 206 to identify the device loss status. In some such embodiments, the device loss status may be obtained in real time from the system and / or database.

[0189] In some embodiments, the fraud prevention subsystem 206 may determine the allowability of a claim based on the third-party identity associated with the third-party device management system, the claim type (e.g., loss claim, theft claim, damage claim, etc.), the device location application status, and the device lost status. For example, in some embodiments, if the third-party identity associated with the third-party device management system from which the claim originated is a mobile carrier system and the associated claim is a loss or theft claim, the associated claim may be approved only if the device location application status indicates that the device location application is inaccessible. Alternatively or additionally, for example, if the third-party identity associated with the third-party device management system from which the claim originated is a device manufacturer and the associated claim is a loss or theft claim, the associated claim may similarly be approved only if (1) the device location application status indicates that the device location application is inaccessible, or (2) the device location application status indicates that the device location application is accessible and the device lost status is set to lost. Additionally or alternatively, in some embodiments, regardless of the third-party identity associated with the third-party device management system from which the claim occurred, if the associated claim is a damage claim, the associated claim may be approved only if the device location application status indicates that the device location application is inaccessible.

[0190] In some embodiments, the fraud prevention subsystem 206 may be configured to communicate with one or more third-party device management systems to identify whether a subscriber device associated with a pending billing data object is associated with pending third-party billing data or a fulfilled third-party billing data object managed by the third-party device management system. In this regard, the fraud prevention subsystem 206 may be configured to analyze such data in situations where the fraud prevention subsystem 206 analyzes such data, for example, when a subscriber device is maintained through two separate systems. In situations where data acquired in real time at the time of processing the billing data object to determine that the subscriber device is associated with one or more pending billing data objects, or where such data acquired and analyzed in real time indicates that a previous billing data object associated with the subscriber device has already been fulfilled, the anti-fraud subsystem 206 may reject and / or mark the unprocessed billing data object for further review due to potential fraud. Additionally or alternatively, the anti-fraud subsystem 206 may be configured to communicate with one or more third-party device management systems to identify whether the subscriber device is associated with one or more repair and / or replacement actions performed by a third-party entity associated with the third-party device management system(s). In this regard, the anti-fraud subsystem 206 may be configured to acquire and analyze such data in real time during processing of the billing data object by the fulfillment subsystem 208 and / or one or more associated subsystems, for example, to reject and / or mark the unprocessed billing data object for further review due to potential fraud in situations where the acquired data indicates that the subscriber device has already been serviced and should no longer be owned by the associated user.

[0191] In some embodiments, the fraud prevention subsystem 206 retrieves an open repair list in real time from a third-party device management system, the repair list including currently pending repairs associated with the subscriber device. Thus, utilizing the open repair list, the fraud prevention subsystem may determine whether the subscriber has already initiated a claim associated with the subscriber device via the third-party device management system. In some embodiments, the fraud prevention subsystem 206 is configured to deny a claim after determining, based on the open repair list retrieved in real time, that the subscriber device is already associated with an open claim.

[0192] In some embodiments, the fraud prevention subsystem 206 retrieves a remaining incident list from the third-party device management system in real time, including incidents available for consumption. The available incidents for consumption may define the number of claim types allowed under a particular device protection program within a specific time interval. For example, the remaining incident list may include one or more claim types that remain available and / or have previously been processed under the device protection program in which the subscriber profile is enrolled. In an exemplary aspect, the device protection program may allow an enrolled subscriber to submit a first number of claim data objects of a first claim type (e.g., unlimited machine breakdown claims) and a second number of claim data objects of a second claim type (e.g., two accidental damage claims) over a predefined time interval, such as 24 months. It should be understood that the device protection program may include a limit on any of an unlimited number of claim types, for example, in some embodiments, a third number of claim data objects of a third claim type (e.g., four loss claims). In this regard, the remaining incident list may indicate the number of claim data objects of a particular claim type that have been processed by the third-party device management system. The fraud prevention subsystem 206 may analyze the remaining incident list to determine whether the newly submitted claim data object exceeds the allowed claim data objects processed for the associated claim type under the device protection program. If the fraud prevention subsystem 206 determines that the claim data object is to be processed based on the remaining incident list, the fraud prevention subsystem 206 adjusts the remaining incident list (e.g., by decrementing the remaining instance count of the remaining incident list associated with the newly received claim data object), stores the updated remaining incident list, and / or notifies the third-party device management system of the updated remaining incident list. The fraud prevention subsystem 206 may utilize real-time data analysis to enhance fraud detection, for example, by obtaining and analyzing the remaining incident list in real time as billing data objects are processed, to identify when a subscriber enrolled in a device protection program attempts to process two billing data objects in violation of the device protection program for which the subscriber is enrolled.

[0193] Additionally or alternatively, the fraud prevention subsystem 206 may analyze the remaining incident list to route the received claim data object to the appropriate system. For example, the fraud prevention subsystem 206, alone or in cooperation with the fulfillment subsystem 208, may determine whether a newly submitted claim data object of a particular claim type should be forwarded to a third-party system, such as a third-party device management system, for processing or processed by the DPPMS 202 based on the corresponding device protection program with which the subscriber is enrolled. In an exemplary aspect, the device protection program may define a claim routing rule set, such as the number of claim data objects of a particular type to be processed by each system (e.g., the first two accidental damage claim data objects are processed by the third-party device management system, and all subsequent accidental damage claim data objects are processed by the DPPMS). The fraud prevention subsystem 206 and / or the fulfillment subsystem 208 may analyze the remaining incident list to determine whether the claim data object should be routed to a third-party device management system based on the claim routing rule set.

[0194] In some embodiments, the fraud prevention subsystem 206 obtains, from the third-party device management system, a previous replacement status in real time indicating whether the subscriber device was previously associated with a claim and replaced via the DPPMS and / or the third-party device management system. Accordingly, in some embodiments, the fraud prevention subsystem 206 is configured to identify, based on the previous replacement status, that the subscriber device associated with the claim has already been replaced via a previous claim by a third-party provider entity associated with the third-party device management system or by the DPPMS. In some embodiments, the fraud prevention subsystem 206 is configured to reject a received claim associated with an already replaced subscriber device as being associated with a fraud risk.

[0195] In some embodiments, the fraud prevention subsystem 206 may utilize a combination of the received information to identify fraud risk. In some embodiments, if the fraud prevention subsystem 206 determines that the claim is fraudulent based on the identified fraud risk, the fraud prevention subsystem 206 may deny the claim or have the claim denied in some other manner, such as by another subsystem.

[0196] The fulfillment subsystem 208 may include a means, such as software and / or hardware, configured to receive claims and perform the necessary actions (e.g., one or more fulfillment events) to fulfill the claims. In other words, the fulfillment subsystem 208 may perform one or more steps toward resolving claims associated with a lost, damaged, stolen, or otherwise affected subscriber device that must be repaired, replaced, or otherwise action taken to restore device functionality to the subscriber. For example, to process, track, and / or otherwise complete claims, the fulfillment subsystem 208 may communicate with one or more associated subsystems of the DPPMS and / or one or more third-party systems to avoid fraud and synchronize between systems, and the fulfillment subsystem 208 may operate in conjunction with the fraud prevention subsystem 206 and / or the enrollment management subsystem 204.

[0197] The DPPMS, in some embodiments, includes additional DPPMS subsystems (not shown) for various other specific functionality and / or data management. For example, in some embodiments, the DPPMS includes a DPPMS Payment System. Additionally or alternatively, in some embodiments, the DPPMS includes a DPPMS Policy System. Additionally or alternatively, in some embodiments, one or more of the DPPMS subsystems are further embodied by one of the following subsystems: Enrollment Management Subsystem 204, Fraud Prevention Subsystem 206, and / or Fulfillment Subsystem 208, or a combination thereof.

[0198] Data store 210 and individual component databases, such as DPPMS subscriber profile data object database 212, connectivity database 214, and error handling database 215, may each be embodied as a data storage device, such as network-attached storage (NAS) device(s), or as a separate database server(s). Additionally, each of these components may include specific or general data related to subscribers and / or subscriber devices, connectivity to third-party systems (such as third-party device management systems), transmission error classification and / or handling, and the like. For example, in an exemplary system, DPPMS subscriber profile data object database 212 may include, among other data, user data, subscriber data, subscriber information, subscriber identifier data objects, subscriber device information, or other data. Furthermore, in an exemplary system, connectivity database 214 may include, among other data, third-party system data, third-party system identifiers, third-party system IP addresses, or other data. Furthermore, in an exemplary system, error handling database 215 may include error logs, error classification data, error codes, or other data. Data store 210 may be configured to retrieve data from one or more of these component databases and communicate and / or transmit the received data to one or more component subsystems, such as enrollment management subsystem 204, fraud prevention subsystem 206, and fulfillment subsystem 208. It will be readily understood that data store 210, and / or each of DPPMS subscriber profile data object database 212, connectivity database 214, and / or error handling database 215 may be a single database, multiple databases, or a combination of several components configured to store information. In some embodiments, each type of data and / or information may be stored in a separate storage component.

[0199] The DPPMS 202 may be embodied by one or more computing systems, such as one or more of the DPPMS devices 300 shown in FIG. 3. As illustrated in FIG. 3, the device 300 may include a processor 302, a memory 304, an input and / or output module 306, a communications module 308, a data store management module 310, a registration module 312, a fulfillment module 314, a fraud module 316, and an error module 318. The device 300 may be configured to perform some or all of the operations described above with respect to the DPPMS of FIGS. 1 and 2 and below with respect to FIGS. 4A-10. While these components 302-318 are described with respect to functional limitations, it should be understood that specific implementations necessarily involve the use of specific hardware. It should also be understood that some of these components 302-318 may include similar or common hardware. For example, two modules may both utilize the use of the same processor, network interface, storage medium, etc. to perform their associated functions such that duplicate hardware is not required for each module.

[0200] Thus, the terms "module" and "modules" used herein in reference to components of a device Users of the terms "module" and "circuitry" include specific hardware configured to perform the functions associated with the particular module and / or circuitry being described. Of course, the terms "module" and "circuitry" should be understood broadly to include hardware, and in some embodiments, circuitry and / or modules may also include software for configuring the hardware. For example, in some embodiments, a "module" and / or "circuitry" may include processing circuitry, storage media, a network interface, input and / or output devices, etc. In some embodiments, other elements of apparatus 30 may provide or supplement the functionality of a particular module(s). For example, processor 302 may provide processing functionality, memory 304 may provide storage functionality, communications module 308 may provide network interface functionality, etc.

[0201] Indeed, it should be understood that in some embodiments, one or more modules may be associated with separate devices, servers, and / or associated computing hardware that may communicate with one or more of the other modules of apparatus 300. For example, in some embodiments, registration module 312 is included in and / or embodied by a separate computing device, which in some embodiments includes memory, a processor, an input / output module, a communications module, a data store management module, and / or any combination thereof, that function similarly to the similarly named components described with respect to apparatus 300. The computing device of separate registration module 312 may be specially configured, e.g., via hardware, software, or a combination thereof, to implement one or more action process instances for performing and / or processing actions related to registration. Additionally or alternatively, in some embodiments, fulfillment module 314 is included in and / or embodied by a separate computing device that also includes memory, a processor, an input / output module, a communications module, a data store management module, and / or any combination thereof. The computing device of the separate fulfillment module 314 may be specially configured, e.g., via hardware, software, or a combination thereof, to embody one or more action process instances for executing and / or processing actions related to fulfillment. Additionally or alternatively, in some embodiments, the fraud module 316 is included in and / or embodied by a separate computing device that also includes memory, a processor, an input / output module, a communications module, the data store management module 310, and / or any combination thereof.The computing devices of the separate fraud module 316 may be specially configured, for example, via hardware, software, or a combination thereof, to embody one or more action process instances for performing and / or processing fraud-related actions. Each of the separate devices may be specially configured to run one or more applications, or portions thereof, for performing functionality as described herein.

[0202] Additionally or alternatively, in some embodiments, error module 318 is included in and / or embodied by a separate computing device that also includes memory, a processor, an input / output module, a communication module, and / or any combination thereof. In still other embodiments, error module 318 is included in and / or shared by one or more of the separate devices. In this regard, each of the separate devices may be configured to perform some or all of the error handling functions described herein with respect to error module 318, utilizing independent or shared components.

[0203] Each separate computing device may, in some embodiments, be embodied by multiple subcomponents, subdevices, subsystems, etc. For example, in some embodiments, each separate computing device includes a variety of distributed, specially configured cloud servers and / or data stores. In some embodiments, one or more of the computing devices is specially configured to execute action processing instances, as described below with respect to FIG. 7. The subcomponents, subdevices, and / or subsystems of each separate computing device may be able to communicate with each other, for example, via one or more direct connections and / or one or more networks. Additionally or alternatively, in some embodiments, each separate computing device may be able to communicate with each of the other separate computing devices.

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

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

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

[0207] In some embodiments, device 300 may include an input and / or output module 306 that communicates with processor 302 to provide output to a user associated with device 300, and in some embodiments, may receive indications from the user. Input and / or output module 306 may include a device display that may include a user interface, and may include a web user interface, a mobile application, a client device, etc. In some embodiments, input and / or output module 306 may include a keyboard, a mouse, a joystick, a touchscreen, a couch area, soft keys, a microphone, a speaker, or other input and / or output mechanism. The processor and / or user interface circuitry comprising the processor may operate by executing computer program instructions (e.g., a keyboard, a joystick, a touchscreen, a touchscreen, a touchscreen, a touchscreen, soft keys, a microphone, a speaker, or other input and / or output mechanism) stored in memory accessible to the processor (e.g., memory 304, etc.). , software and / or firmware) to control one or more functions of one or more user interface elements.

[0208] The communications module 308 may be any means, such as a device, module, or circuitry embodied in either hardware or a combination of hardware and software, configured to receive and / or transmit data to and from a network and / or any other device, circuitry, or module in communication with the apparatus 300. In this regard, the communications module 308 may include, for example, a network interface for enabling communication with a wired or wireless communications network. For example, the communications module 308 may include one or more network interface cards, antennas, buses, switches, routers, modems, and supporting hardware and / or software or any other devices suitable for enabling communication over a network. Additionally or alternatively, the communications module 308 may include circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or to process reception of signals received via the antenna(s). These signals may be transmitted by device 300 using any of several wireless personal area network (PAN) technologies, such as Bluetooth® v1.0-v3.0, Bluetooth Low Energy (BLE), infrared radio (e.g., IrDA) FREC, ultra-wideband (UWB), inductive radio transmission, etc. Additionally, it should be understood that these signals may be transmitted using Wi-Fi, near field communication (NFC), worldwide interoperability for microwave access (WiMAX), or other proximity-based communication protocols.

[0209] In some embodiments, the communications module 308 may facilitate communications with one or more client devices and / or subscriber devices, and / or one or more third party systems and / or third party device management systems, as illustrated in Figures 1 and 2. For example, the communications module 308 may facilitate transmitting information requests and / or responses to client devices and / or third party systems, and / or receiving information requests and / or responses from client devices and / or third party systems.

[0210] Data store management module 310 may be any means for facilitating communication with and / or management of a data store associated with device 300. For example, device 300 may manage a data store including (1) a subscriber list, (2) a third-party system connectivity list, and (3) an error handling data list. Data store management module 310 may be configured to identify data within these lists and / or add, cancel, delete, or otherwise manage one or more of these lists. In some embodiments, data store management module 310 may be associated with one or more of processor 302, registration module 312, fulfillment module 314, fraud module 316, and / or error module 318 to accomplish specific data store management operations associated with the operations performed by each of modules 312-318.

[0211] The registration module 312 may be embodied by any hardware and / or software means that facilitates adding, canceling, and otherwise managing subscribers associated with one or more device protection programs. In some embodiments, the registration module 312 includes hardware and / or software that embodies the registration management subsystem 204, as illustrated in FIG. 2. For example, the registration module 312 may cooperate with the data store management module 310, the processor 302, etc. to register subscriber information with subscriber devices. The registration module 312 may be configured to register a new subscriber with a device protection program, such as by adding the subscriber information to a subscriber list associated with the new subscriber and / or subscriber device, to identify the corresponding device protection program with which the new subscriber has enrolled. Additionally or alternatively, the registration module 312, in cooperation with the data store management module 310, the processor 302, etc., may be configured to cancel an existing subscriber from a device protection program, such as by marking the subscriber information in the subscriber list associated with a canceled device protection program, erasing the subscriber information associated with the canceled device protection program from the subscriber list, or performing an action such that the subscriber information indicates cancellation of the device protection program.

[0212] The registration module 312, in cooperation with the processor 302, the communications module 308, etc., may also communicate with one or more third party systems, such as one or more third party device management systems, to facilitate synchronization with the third party device management systems. For example, the registration module 312 may be configured to transmit a third party registration status request data object and receive a third party registration status response data object indicating a registration status associated with a subscriber or subscriber device in the third party device management system. Additionally or alternatively, the registration module 312 may be configured to transmit a third party registration management request data object and receive a third party registration management response indicating whether the subscriber, subscriber device, or subscriber information was successfully added to the third party device management system.

[0213] In some embodiments, the registration module 312 may manage an outstanding registration action queue. Additionally or alternatively, in some embodiments, the registration module 312 may create, execute, delete, allocate, or otherwise manage one or more action processes associated with the outstanding registration action queue, such that action processes controlled by the registration module 312 process registration management request data objects from the outstanding registration action queue or otherwise perform steps for processing registration management request data objects. As the length of the outstanding registration action queue increases, the registration module 312 may be configured to execute additional threads over currently executing action processes or execute new action processes to increase the rate at which outstanding registration actions, such as received but unprocessed registration management request data objects, are removed from the outstanding registration action queue and processed, in accordance with certain embodiments described herein. Additionally or alternatively, according to certain embodiments described herein, the registration module 312 may be configured to reduce the number of running threads in a particular executed action process or terminate an executed action process when the outstanding registration action queue meets a lower value, e.g., the number of outstanding registration management request data objects is below a particular lower threshold.

[0214] The fulfillment module 314 may be embodied by any hardware and / or software means that facilitates receiving and / or fulfilling received claims associated with a device protection program. In some embodiments, the fulfillment module 314 includes hardware and / or software that embodies the fulfillment subsystem 206, as illustrated in FIG. 2 . For example, the fulfillment module 314 may cooperate with the processor 302, the data store management module 310, etc. to identify a device protection program associated with a claim received from a subscriber, and / or identify and execute a claim processing protocol that includes an instruction set associated with the device protection program. In some embodiments, the fulfillment module 314 may manage an outstanding claim action queue. Additionally or alternatively, in some embodiments, the fulfillment module 314 may manage a queue of pending claim actions. 4 may create, execute, delete, allocate, or otherwise manage one or more action processes associated with an outstanding claim action queue such that action processes controlled by the fulfillment module process claim requests from the outstanding claim action queue or otherwise perform steps to fulfill claim requests. As the length of the outstanding claim action queue increases, the registration module 314 may be configured, according to certain embodiments described herein, to execute additional threads through currently executing action processes or execute new action processes to increase the rate at which outstanding claims are removed from the outstanding registered action queue and fulfilled. Additionally or alternatively, according to certain embodiments described herein, the fulfillment module 314 may be configured to reduce the number of executing threads in a particular executed action process or terminate an executed action process when the outstanding claim action queue reaches a lower threshold.

[0215] In some embodiments, the fulfillment module 314 is configured, alone or in conjunction with one or more subsystems, to perform one or more device acquisition processes in response to processing the claim data object. For example, the fulfillment module 314 may transmit one or more device acquisition signals to one or more third-party systems, such as a third-party device management system, for the purpose of replenishing device inventory. In certain exemplary aspects, the fulfillment module 314 can automatically generate and / or transmit a device acquisition signal to a third-party system in response to fulfilling the claim data object and providing a particular device associated with the claim data object, which causes the provision of a new device to the device inventory managed by the fulfillment module 314 or an associated subsystem. In some embodiments, the device acquisition signal is received by the third-party system to prompt a third-party entity (e.g., a device manufacturer) associated with the third-party system to provide a new device that conforms to the particular device specifications associated with the device provided to the registered subscriber in response to their claim. Additionally or alternatively, the fulfillment module 314 may automatically obtain and / or process billing data associated with a newly obtained device, for example, by obtaining the billing data from a third-party system used to obtain the device and storing the billing data for processing by the fulfillment module 314 and / or an associated billing management subsystem. In certain exemplary aspects, for example, a billing data object can be processed, and the fulfillment module 314 may automatically initiate provision of a replacement device (e.g., a mobile device having the same model, memory size, and / or other specifications of the subscriber device for a particular device protection program) to the subscriber user in response to the received and processed billing data object.Continuing with this exemplary aspect, in some embodiments, the fulfillment module 314 may additionally or alternatively transmit a device acquisition signal to a third party system associated with the replacement device (e.g., a third party system managed by the manufacturer of the replacement device) to automatically initiate the provision of a new device having the same device specifications as the replacement device, thus automatically replenishing the inventory of devices that match these device characteristics.

[0216] It should be understood that in some embodiments, the action process performed associated with fulfillment and the action process performed associated with other actions, such as registration, may be separate. In other embodiments, the action process performed associated with fulfillment and the action process performed associated with other actions, such as registration, may be shared, such that a single action process performed may perform both registration and fulfillment actions. Similarly, in some embodiments, a single combined action queue may perform both outstanding registration actions and outstanding fulfillment actions. While in some embodiments, certain action queues may be dedicated only to outstanding registered actions, and certain action queues may be dedicated only to outstanding fulfillment actions. Each action queue may be associated with one or more executed processing instances configured to process actions of a particular type from one or more corresponding action queues that contain actions of that type. Additionally or alternatively, the fulfillment module 314 may be configured to manage one or more scaling services configured to scale the number of executed action process instances associated with one or more action queues, as described below.

[0217] The fraud module 316 may be embodied by any hardware and / or software means that facilitates identifying or otherwise detecting fraudulent claims associated with a subscriber to a device protection program. In some embodiments, the fraud module 316 includes hardware and / or software embodying the fraud prevention subsystem 206, as illustrated in FIG. 2. For example, the fraud module 316, in conjunction with the processor 302, the data store management module 310, etc., may identify an anti-fraud protocol including an instruction set associated with the device protection program for which the subscriber submitted the claim. Additionally or alternatively, the fraud module 316 may be configured to execute one or more anti-fraud events, such as one or more anti-fraud events associated with the identified anti-fraud protocol. The fraud module 316 may be configured, for example, to extract real-time data associated with or directly from a subscriber device. For example, the fraud module 316 may be configured to retrieve real-time device information from a third-party device management system via one or more APIs. Examples of real-time device information include device location application status, device lost status, an open repair list, and / or an incident remaining list. In some embodiments, the fraud module 316 utilizes one or more portions of the real-time device information to determine a fraud risk associated with a received claim and / or reject or approve the claim for fulfillment accordingly.

[0218] The error module 318 may be embodied by any hardware and / or software means capable of receiving a transmission error, classifying the transmission error, and / or providing subsequent error handling associated with the transmission error. The error module 318 may communicate and / or operate in conjunction with one or more modules from the registration module 312, fulfillment module 314, fraud module 316, and / or communication module 308 group to identify a transmission error resulting from a failed attempted transmission to a third-party system, such as a third-party device management system. The transmission error may be received, for example, in response to a failure to connect to the third-party system, a loss of connection to the third-party system during, before, or after transmitting information to the third-party system, or in response to transmitting information to the third-party system. In an exemplary embodiment, the error module 318 may be configured to identify an error classification set including one or more error classifications.

[0219] Each error classification may be associated with one or more sets of error handling instructions. In some embodiments, the error handling instruction sets may be identified based on a set of business rules for identifying or otherwise determining the error classification. For example, the error module 318 may maintain one or more error configurations for use in determining an error classification associated with a received transmission error. In some embodiments, each error configuration may include a particular set of business rules that, if met, indicate that the error classification is associated with a transmission error. Additionally or alternatively, in some embodiments, the error classification may be identified based on a set of business rules for identifying or otherwise determining the error classification. The error processing instruction set may be identified based on one or more algorithmic learning models, statistical learning models, and / or machine learning models for identifying the error classification. For example, in some embodiments, the error classification may be identified using a myriad of machine learning implementations. In some exemplary aspects, an unsupervised learning model may be used to identify the error classification. In other exemplary aspects, a supervised learning model may be used to identify the error classification.

[0220] In some such embodiments, the algorithmic, statistical, and / or machine learning models utilize various inputs. For example, in some embodiments, inputs used for error classification include information associated with transmission errors, preferences associated with the DPPMS, preferences associated with a third-party device management system, etc. In some embodiments, the algorithmic, statistical, and / or machine learning models may additionally or alternatively utilize other information associated with billing, the subscriber, the DPPMS, or the third-party device management system.

[0221] In some embodiments, errors may be classified based on various error classifications within an error classification set. For example, the error classification set may include an error classification for "retryable errors" and an error classification for "escalation errors." Retryable errors may be associated with an error handling instruction set that represents an error handling protocol that includes one or more error handling events, such as returning a failed transmission to a queue to attempt a subsequent transition, waiting a retry time, and determining a retry time to wait before placing the failed transmission in a queue for a subsequent transmission. In some embodiments, a retry time may be identified based on the number of failed transmission attempts. For example, a retry time may initially be identified as a base length of time, such as 5 minutes, upon the first failed transmission. For each subsequent failed transmission, the retry time may double, such that the retry time after the second failed transmission is 10 minutes, the retry time after the third failed transmission is 20 minutes, the retry time after the third failed transmission is 40 minutes, and so on. In other embodiments, a different relationship may be used to identify a retry time based on the number of transmissions. In still other embodiments, the relationship may be used to identify a retry time that does not utilize the number of transmissions, such as by always waiting a predetermined length of time.

[0222] The error module 318 can identify an escalation error handling protocol including an instruction set associated with an escalation error, and the escalation handling protocol can include one or more error handling events. An exemplary error handling protocol can be defined by an error handling instruction set, including adding escalation errors and / or transmission errors, including failed transmissions, to an escalation queue. For example, the escalation queue can be a queue of transmission errors and / or associated failed transmissions that are transmitted or otherwise communicated to an error handling system and / or a third-party processing system for processing. In some embodiments, the transmission errors and / or associated failed transmissions are transmitted to a third-party error handling system associated with a third-party entity that controls or is otherwise associated with the third-party system that communicated and / or associated with the received transmission error. In an exemplary system, the third-party system that was the intended recipient of the failed transmission is also the third-party system to which the escalated error is transmitted. In other systems, the escalated error and / or corresponding failed transmission are transmitted to a third-party error handling system for electronic processing by the third-party error handling system. Alternatively or additionally, the escalated error may be transmitted to and / or handled by a human operator.

[0223] In some embodiments, the error module 318 is configured to determine an error configuration associated with a transmission error. The error configuration may include at least an error code, an error classification, and / or an associated maximum retry threshold. In some embodiments, the error module is associated with an error configuration service such that the error module 318 may utilize the error configuration service to identify the error configuration.

[0224] Having described certain components of the exemplary embodiment devices and systems involved in the present disclosure, certain exemplary operations performed by embodiments of the present disclosure are described below in conjunction with FIGS.

[0225] Exemplary Process Operation 4A and 4B illustrate example operations performed in a process for self-healing registration based on a received registration management request data object. Specifically, FIG. 4A illustrates example operations for self-healing registration based on a received registration subscription request, and FIG. 4B illustrates example operations for self-healing registration based on a received registration cancellation request data object. The operations illustrated in FIGS. 4A and 4B may be performed by various devices and / or apparatuses in a networked system, such as DPPMS apparatus 300 configured to communicate with one or more third-party systems, such as third-party device management systems and / or client devices, such as subscriber devices. While the operations discussed below are described with respect to DPPMS apparatus 300, it should be understood that the operations may be performed by various devices similar to or different from DPPMS apparatus 300 and / or using substitute components from DPPMS apparatus 300 within the scope of this disclosure.

[0226] Additionally or alternatively, in some embodiments, the DPPMS device 300 may be configured to synchronize one or more subscriber profile(s) based on a registration notification received from a particular third-party device management system. For example, one or more particular third-party device management systems may be trusted to be associated with a device protection program. In an exemplary aspect, for example, the third-party device management system may be associated with providing device protection program services to registered subscribers. A new registration received by the third-party device management system should be used to synchronize the device 300 and / or subsystems within the device 300 without subsequent verification. In such a situation, the device 300 may receive, from the third-party device management system, one or more registration subscription notifications associated with the newly registered third-party subscriber profile and / or one or more registration cancellation notifications associated with the newly canceled third-party subscriber profile. The received registration subscription notification(s) and / or registration cancellation notification(s) may be used by device 300 to perform one or more synchronization events, e.g., to synchronize one or more DPPMS subscriber profiles for device 300 or one or more subsystems of device 300. In some embodiments, device 300 may utilize some or all of the information contained in the received notification to identify associated data for use in such synchronization events (e.g., the notification may include one or more device identifiers, such as a device serial number, for use in identifying and / or obtaining one or more additional device identifiers for processing, such as an IMEI).

[0227] 4A, at block 402A, the apparatus 300 includes means for receiving a registration subscription request, such as the registration module 312, the processor 302, and the communication module 308. The registration subscription request may be, for example, a request from a currently unregistered device and / or an unregistered user to subscribe (or request) to a device protection program. In other words, it may indicate that a new subscriber associated with a particular device protection program has been added. In some embodiments, the received registration subscription request includes subscriber information for registering or otherwise processing the registration of a currently unregistered device with the device protection program. The received subscriber information may include a subscriber identifier data object that uniquely identifies a human subscriber or subscriber device associated with the device protection program. Examples of received subscriber identifier data objects include one or a combination of a subscriber name (e.g., a person's name or entity name), subscriber contact information, a subscriber device IP address, a subscriber device International Mobile Equipment Identity (IMEI) number, etc. In an exemplary embodiment, the registration subscription request includes an IMEI that uniquely identifies the client device to be subscribed to the device protection program. In some embodiments, the registration subscription request may be made directly at an interface of the DPPMS by the subscriber or a third party, or the registration subscription request may be transmitted to the DPPMS by a third party system that may be the same as or different from blocks 404A, 406A, 408A, 410A, 412A, 414A, and 416A. For example, in some embodiments, the request at block 402A may be transmitted by a third-party device management system associated with the wireless carrier or vendor from which the subscriber device was purchased, and the manufacturer system may be verified and synchronized in a subsequent block, which may be used to synchronize a second third-party device management system associated with the DPPMS (and / or a subsystem of the DPPMS) or other entity associated with the device manufacturer or device protection plan.

[0228] At block 404A, the apparatus 300 includes means for identifying a third-party device management system associated with the received registration subscription request, such as the registration module 312, the processor 302, or the data store management module 310. In some embodiments, the apparatus 300 may include means for extracting a third-party device management system identifier from the received registration subscription request. In other embodiments, the apparatus 300 may determine the third-party device management system identifier based on the received registration subscription request. The third-party device management system identifier may be utilized for transmission to the third-party device management system or for determining a communication protocol for communicating with the third-party device management system associated with the third-party device management system identifier. In a particular example, the third-party device management system may be associated with a third-party entity (e.g., a mobile carrier system, a device manufacturer, a sales system, etc.) through which the user or client device is newly subscribed to the device protection program.

[0229] At block 406A, the apparatus 300 includes means for transmitting a third-party registration status request data object to the third-party device management system, such as the registration module 312, the processor 302, or the communication module 308. The third-party registration status request data object may be configured to cause the third-party device management system to obtain and / or otherwise identify a third-party status associated with information in the registration subscription request, such as a subscriber identifier data object or other subscriber information. In an exemplary embodiment, the apparatus 300 may generate a third-party registration status request data object that determines whether a third-party subscriber profile data object exists that is associated with an extracted subscriber identifier data object, such as an IMEI.

[0230] At block 408A, the apparatus 300 includes means for receiving a third-party registration status response data object from the third-party device management system, such as the registration module 312, the processor 302, or the communication module 308. The status response data object may indicate the third-party registration status, such as whether a third-party subscriber profile data object exists that is associated with the information provided in the transmitted third-party registration status request data object. For example, if a third-party subscriber profile data object exists, the third-party registration status response data object may include the third-party subscriber profile data object, an information subset of the third-party subscriber profile data object (e.g., a portion of the third-party subscriber profile data object rather than the entire profile), or equivalent information of either the third-party subscriber profile data object or the information subset. Additionally or alternatively, the third-party registration status response data object may include a status flag associated with the third-party registration status, e.g., a bit flag where 0 indicates that the third-party subscriber profile data object does not exist in the third-party device management system and 1 indicates that the third-party subscriber profile data object does exist in the third-party device management system. Additionally or alternatively, in some embodiments, the third-party registration status response data object may identify and / or include information associated with the covered subscriber device, device status, protection program status (e.g., warranty status), subscription compensation timestamp(s) (e.g., the compensation interval spanning two timestamps), and / or registration contract information associated with the subscriber profile.

[0231] At decision block 410A, flow continues based on whether the received third-party registration status indicates that a third-party subscriber profile data object exists. In either case, device 300 may be configured to perform one or more system synchronization events based on the received third-party registration status. For illustrative purposes, blocks 412A and 416A provide two specific examples of system synchronization events.

[0232] If, at decision block 410A, the third-party registration status indicates that the third-party subscriber profile data object does not exist in the third-party device management system, flow continues to block 412A. At block 412A, the apparatus 300 includes means for performing a system synchronization event, specifically, transmitting a third-party subscriber registration request data object to the third-party device management system, such as the registration module 312, the processor 302, or the communication module 308. In some embodiments, the apparatus 300 also includes means for generating a third-party subscriber registration request data object and / or configuring a third-party registration request to cause the third-party device management system to create a third-party subscriber profile data object associated with the extracted subscriber information, such as a subscriber identifier data object. In other embodiments, the apparatus 300 determines, in other ways, a third-party subscriber registration request data object configured to cause the third-party device management system to create a third-party subscriber profile data object associated with the extracted subscriber information, such as a subscriber identifier data object. The generated or determined third-party subscriber registration request data object is then transmitted to the third-party device management system, such as via a network, etc.

[0233] At block 414A, the apparatus 300 includes means for receiving a third-party subscriber registration response, such as the registration module 312, the processor 302, or the communication module 308. The third-party subscriber registration response may include information, data, etc., indicating that the third-party device management system successfully created a third-party subscriber profile data object. The third-party subscriber registration response may include information indicating that a subsequent third-party registration status response data object associated with the extracted subscriber information, such as a subscriber identifier data object, will identify the created third-party subscriber profile data object. Thus, in some embodiments, apparatus 300 can then utilize subscriber information, such as a subscriber identifier data object, to retrieve the newly created third-party subscriber profile data object or retrieve the third-party registration status associated with the newly created third-party subscriber profile data object.

[0234] Returning to decision block 410A, if the third-party registration status indicates that a third-party subscriber profile data object exists, flow continues to block 416A. At block 416A, the apparatus 300 includes a means, such as the registration module 312, the processor 302, for performing a system synchronization event, specifically for updating a DPPMS subscriber profile data object based on the third-party subscriber profile data object. In particular examples, the apparatus 300 may include a means configured to update a DPPMS subscriber profile data object directly managed or otherwise controlled by the apparatus 300 based on the third-party subscriber profile data object or other received information. Alternatively, in some embodiments, the apparatus 300 may include a means configured to identify one or more subsystems associated with or otherwise in communication with the apparatus 300, and, for some or all of the identified subsystems, update or cause the update of a DPPMS subscriber profile data object associated with the identified subsystem. In particular examples, the apparatus 300 may identify a payment subsystem associated with the apparatus 300 and a policy subsystem associated with the apparatus 300. Subsequently, apparatus 300 may be configured to update or cause the updating of a first DPPMS subscriber profile data object associated with the payment subsystem and a second DPPMS subscriber profile data object associated with the policy subsystem. In some embodiments, apparatus 300 may be configured to update a DPPMS subscriber profile data object associated with a particular subsystem of apparatus 300 by creating or causing the creation of a new DPPMS subscriber profile data object associated with the identified DPPMS subsystem.In other embodiments, apparatus 300 may be configured to update DPPMS subscriber profile data objects associated with DPPMS subsystems by identifying DPPMS subscriber profile data objects associated with the subsystems and synchronizing the DPPMS subscriber profile data objects based on third-party subscriber profile data objects. In an exemplary system, apparatus 300 directly controls each subsystem independently and / or communicates with the subsystems such that each subsystem is controllable by the same provider entity.

[0235] It should be understood that the system synchronization events described above with respect to blocks 412A, 414A, and 416A are examples, and that alternative system synchronization events, or system synchronization events utilizing additional steps, may also be performed. For example, in some embodiments, block 416A may be performed after block 414A, such that one or more DPPMS subscriber profile data objects are updated after receiving a third-party subscriber registration response. Accordingly, the spirit and scope of the disclosure herein is not limited to the details of the example blocks illustrated in FIG. 4A .

[0236] Referring now to FIG. 4B, at block 402B, the apparatus 300 includes means for receiving a registration cancellation request data object, such as the registration module 312, the processor 302, or the communications module 308. The registration cancellation request data object may indicate, for example, that a user and / or client device is canceling their subscription to a device protection program (in other words, the subscriber will no longer be actively covered by the associated device protection program). In some embodiments, the received registration cancellation request data object includes subscriber information. The received subscriber information may include a subscriber identifier data object that uniquely identifies a human subscriber or subscriber device associated with the device protection program. Examples of received subscriber identifier data objects include one or a combination of the following: a subscriber name (e.g., a person's name or entity name), subscriber contact information, a subscriber device IP address, a subscriber device International Mobile Equipment Identity (IMEI) number, etc. In an exemplary embodiment, the registration cancellation request data object includes an IMEI that uniquely identifies a client device subscribed to the device protection program. Similar to the registration function of FIG. 4A, the cancellation request may be made in any manner.

[0237] At block 404B, the apparatus 300 includes means for identifying a third-party device management system associated with the received registration cancellation request data object, such as the registration module 312, the processor 302, or the data store management module 310. In some embodiments, the apparatus 300 may include means for extracting a third-party device management system identifier from the received registration cancellation request data object. In other embodiments, the apparatus 300 may determine the third-party device management system identifier based on the received registration cancellation request data object. The third-party device management system identifier may be utilized for transmission to the third-party device management system or may be utilized to determine a communication protocol for communicating with the third-party device management system associated with the third-party device management system identifier. In certain examples, the third-party device management system is associated with a third-party entity (e.g., via a mobile carrier system, a device manufacturer, a sales system, etc.) through which a subscriber, such as a user, and / or a client device, is subscribed to a device protection program.

[0238] At block 406B, the apparatus 300 includes means for transmitting a third-party registration status request data object to the third-party device management system, such as the registration module 312, the processor 302, or the communication module 308. The third-party registration status request data object may be configured to cause the third-party device management system to obtain and / or identify a third-party status associated with information in the registration subscription request, such as a subscriber identifier data object or other subscriber information. In an exemplary embodiment, the apparatus 300 may generate a third-party registration status request data object that determines whether a third-party subscriber profile data object exists that is associated with an extracted subscriber identifier data object, such as an IMEI.

[0239] At block 408B, the apparatus 300 includes means for receiving a third-party registration status response data object from the third-party device management system, such as the registration module 312, the processor 302, or the communication module 308. The third-party registration status response data object may indicate a third-party registration status, such as whether a third-party subscriber profile data object exists that is associated with the information provided in the transmitted third-party registration status request data object. For example, if a third-party subscriber profile data object exists, the third-party registration status response data object may indicate the third-party subscriber profile The third-party registration status response data object may include a file data object, an information subset of the third-party subscriber profile data object (e.g., a portion of the third-party subscriber profile data object rather than the entire profile), or equivalent information of either the third-party subscriber profile data object or the information subset. Additionally or alternatively, the third-party registration status response data object may include a status flag associated with the third-party registration status, e.g., a bit flag where 0 indicates that the third-party subscriber profile data object does not exist in the third-party device management system and 1 indicates that the third-party subscriber profile data object does exist in the third-party device management system.

[0240] Flow then continues to decision block 410B. At decision block 410B, flow continues based on whether the received third-party registration status indicates that a third-party subscriber profile data object exists. In either case, device 300 may be configured to perform one or more system synchronization events based on the received third-party registration status. For illustrative purposes, blocks 412B, 414B, and 416B provide two specific examples of system synchronization events.

[0241] At decision block 410B, if the third-party registration status indicates that a third-party subscriber profile data object exists in the third-party device management system, flow continues to block 412B. At block 412B, the apparatus 300 includes means for performing a system synchronization event, such as the registration module 312, the processor 302, or the communication module 308, and specifically for transmitting a third-party subscriber cancellation request data object to the third-party device management system. In some embodiments, the apparatus 300 also includes means for generating a third-party subscriber cancellation request data object and / or configuring a third-party registration request to cause the third-party device management system to cancel, which may include deleting or otherwise terminating a third-party subscriber profile data object associated with the extracted subscriber information, such as a subscriber identifier data object. In other embodiments, the apparatus 300 determines, in other ways, a third-party subscriber registration request data object configured to cause the third-party device management system to cancel, which may include deleting or otherwise terminating a third-party subscriber profile data object associated with the extracted subscriber information, such as a subscriber identifier data object. The generated or determined third-party subscriber cancellation request data object is then transmitted to the third-party device management system, such as over a network.

[0242] At block 414B, the apparatus 300 includes means for receiving a third-party subscriber cancellation response, such as the registration module 312, the processor 302, or the communications module 308. The third-party subscriber registration response may include information, data, etc., indicating that the third-party device management system successfully canceled the third-party subscriber profile data object. Accordingly, the third-party subscriber cancellation response may indicate that a subsequent third-party registration status response data object associated with the extracted subscriber information, such as a subscriber identifier data object, will indicate that there is no third-party subscriber profile data object present associated with the subscriber information.

[0243] At decision block 410B, if the third-party registration status indicates that the third-party subscriber profile data object does not exist in the third-party device management system, flow continues to block 416B. At block 416B, the device 300 may configure the registration module 312, the processor 302, or other components to perform a system synchronization event. , specifically, means for canceling one or more DPPMS subscriber profile data object(s). For example, apparatus 300 may include means configured to identify one or more DPPMS subsystems associated with apparatus 300, and, for some or all of the identified subsystems, cancel DPPMS subscriber profile data objects associated with the identified subsystems. In a particular example, apparatus 300 may identify a DPPMS payment subsystem associated with apparatus 300 and a DPPMS policy subsystem associated with apparatus 300. Subsequently, apparatus 300 may be configured to cancel a first DPPMS subscriber profile data object associated with the DPPMS payment subsystem and a second DPPMS subscriber profile data object associated with the DPPMS policy subsystem. In some embodiments, apparatus 300 may be configured to cancel DPPMS subscriber profile data objects associated with the DPPMS subsystems by canceling, erasing, or otherwise marking the DPPMS subscriber profile data objects associated with the subsystems as terminated. Thus, in some embodiments, after a system synchronization event, the DPPMS subscriber profile data object managed by device 300 and / or one or more subsystems of device 300 reflects the subscriber's cancellation from the Device Protection Program. In an exemplary system, device 300 and each associated subsystem are controlled by the same provider entity.

[0244] It should be understood that the system synchronization events described above with respect to blocks 412B, 414B, and 416B are examples, and that alternative system synchronization events, or system synchronization events utilizing additional steps, may also be performed. For example, in some embodiments, block 416B may be performed after block 414B, such that one or more DPPMS subscriber profile data objects are canceled after receiving a third-party subscriber cancellation response. Accordingly, the spirit and scope of the disclosure herein is not limited to the details of the example blocks illustrated in FIG. 4B.

[0245] FIG. 4C illustrates an example data flow diagram for registration synchronization according to an example embodiment of the present disclosure. The example data flow depicts operations performed by the DPPMS or subsystems of the DPPMS to synchronize subscriber profile(s) of the DPPMS and / or third-party device management systems. A particular service or operation in a particular service may be performed, executed, or simulated by the DPPMS or any subsystem within the DPPMS. For example, registration service 450C and / or cancellation service 452C may be performed by the DPPMS embodied by apparatus 300. Registration service 450C may be used to register an unregistered device with a device protection program. For example, a device identifier may be received associated with an unregistered device to register the corresponding unregistered device with one or more device protection programs.

[0246] For example, as illustrated, FIG. 4C depicts a registration service 450C. The registration service 450C may be performed, executed, or initiated by the DPPMS or any subsystem within the DPPMS to synchronize the DPPMS with a third party system based on a device identifier, subscriber identifier, etc. (e.g., a particular IMEI). Additionally or alternatively, in some embodiments, the registration service 450C may be performed, executed, or initiated by the DPPMS or any subsystem within the DPPMS to synchronize the DPPMS with a third party system based on a registration subscription request associated with a particular subscriber identifier, device identifier, etc. Similarly, FIG. 4C depicts a cancellation service 452C. The cancellation service 452C may be performed, executed, or initiated by the DPPMS or any subsystem within the DPPMS to synchronize the DPPMS with a third party system based on a registration subscription request associated with a particular subscriber identifier, device identifier, etc. The registration service 450C and / or cancellation service 452C may be performed, executed, or initiated by any subsystem within the DPPMS to synchronize the DPPMS with third party systems based on a device identifier, subscriber identifier, etc. Additionally or alternatively, in some embodiments, the cancellation service 452C may be performed, executed, or initiated by the DPPMS or any subsystem within the DPPMS to synchronize the DPPMS with third party systems based on a cancel subscription request associated with a particular subscriber identifier, device identifier, etc. In certain depicted embodiments, the registration service 450C and / or cancellation service 452C may synchronize one or more DPPMS subsystems 452C and / or third party device management systems 454C.

[0247] In an exemplary aspect, in some embodiments, the registration service 450C or the cancellation service 452C is initiated during the initiation of subscriber registration, billing fraud analysis, or billing processing protocols. For example, in some embodiments, the DPPMS may receive a billing data object associated with a device identifier data object. The device identifier data object may be associated with or represent a subscriber identifier data object for processing the billing data object. The DPPMS may query a device protection program subscriber device database for a subscriber profile data object associated with the subscriber identifier data object and receive result data indicating that the device protection program database does not contain the subscriber profile data object. In this regard, the registration service 450C or the cancellation service 452C may be initiated upon receipt and / or analysis of the result data.

[0248] Referring first to the registration service 450C, at block 402C, the apparatus 300 includes a means for receiving a device identifier, such as any one or combination of the registration module 312, the fulfillment module 314, the fraud module 316, the error module 318, the processor 302, etc. In some embodiments, the device identifier may be received from a third-party device management system, e.g., the third-party device management system 458C, that provides information for the registration of new subscribers. Alternatively, the apparatus 300 may receive the device identifier by identifying or obtaining the device identifier as part of a routine synchronization service. For example, the DPPMS or a subsystem within the DPPMS may synchronize the registration of all currently registered device identifiers at a particular interval (e.g., at a particular time daily, weekly, etc.).

[0249] At block 404C, the apparatus 300 includes means for receiving a registration status from a third-party device management system, such as any one or combination of the registration module 312, the fulfillment module 314, the fraud module 316, the error module 318, the processor 302, etc. As illustrated, for example, the registration status may be obtained from a third-party device management system 456C. The third-party device management system 456C may embody a particular third-party device management system associated with a device protection program for the device associated with the device identifier obtained at block 402C. For example, the third-party device management system 456C may embody a system, server, etc. associated with a device manufacturer. The third-party device management system 456C may store third-party subscriber profile data objects that are managed independently from the subscriber profile data objects stored by the DPPMS. In some embodiments, the apparatus 300 obtains the registration status by transmitting a registration status request to the third-party device management system.

[0250] The registration service 450C then determines the flow of operations based on the obtained registration status. For example, as depicted, if the obtained registration status indicates that the device identifier is registered with the third-party device management system 456C (e.g., indicates that an associated third-party subscriber profile data object exists), flow may continue at block 406C. In such a situation, the apparatus 300 includes means for synchronizing the DPPMS and / or one or more DPPMS subsystems based on the registration status received from the third-party device management system 456C, such as any one or combination of the registration module 312, the fulfillment module 314, the fraud module 316, the error module 318, the processor 302, etc. For example, the registration status may include a third-party subscriber profile data object or corresponding data, which may be used to synchronize a corresponding subscriber profile data object managed by the DPPMS and / or one or more subscriber profile data objects managed by one or more subsystems of the DPPMS. For example, the device 300 may synchronize each subscriber profile data object of the DPPMS subsystem 454C so that the information stored in each subscriber profile data object of the DPPMS subsystem 454C matches the information associated with the third-party subscriber profile data object.

[0251] Flow may alternatively continue from block 404C to block 408C if the registration status indicates that the device identifier is registered with the third-party device management system 456C (e.g., indicates that an associated third-party subscriber profile data object does not exist). In an exemplary embodiment, in such a situation, the apparatus 300 includes means for attempting to register the device identifier through the third-party device management system, such as any one or combination of the registration module 312, the fulfillment module 314, the fraud module 316, the error module 318, the processor 302, etc. In this regard, the apparatus 300 may transmit one or more requests, signals, etc. to attempt to have the third-party device management system 456C create a third-party subscriber profile data object associated with the device identifier. In response to such attempt(s), the apparatus 300 may receive confirmation information in return indicating that the third-party subscriber profile data object was successfully created or that one or more transmission error(s) occurred.

[0252] In some embodiments, the registration service 450C may be configured in association with an error handling system for classifying received error(s) and / or executing one or more associated error handling instruction sets. For example, the received errors may be classified and / or handled by one or more actions. The error handling actions may be performed and / or originated by the error handling system associated with the registration service 450C.

[0253] Additionally or alternatively, in some embodiments, the device identifier may be associated with a billing data object representing a user bill, which may include means for the device to initiate a billing instruction set. The billing instruction set may be initiated in parallel with one or more system synchronization events. In an exemplary aspect of a Mobile Device Pro, the billing instruction set may include one or more billing processing events for verifying the bill as not fraudulent, or for processing and / or transmitting information for servicing the mobile device, replacing the mobile device, etc. The billing instruction set may be initiated without a corresponding synchronized subscriber profile data object (which may be created and / or synchronized later).

[0254] In some embodiments, registration 450C may be performed by a trusted third-party device management system. In some such embodiments, the registration service 450C may receive a device identifier in the form of a registration subscription notification from the system, e.g., directly from the third-party device management system 456C instead of 458C. In some such embodiments, the registration service 450C may perform one or more system synchronization events without subsequent approval by the third-party device management system from which it was received. In this regard, in some such embodiments, the registration service 450C may proceed immediately to block 406C to synchronize the DPPMS and / or one or more DPPMS subsystems by registering new and / or existing subscription profile(s) with one or more new device protection programs identified by the received registration subscription notification.

[0255] Referring now to registration service 452C, at block 410C, apparatus 300 includes a means for receiving a device identifier, such as any one or combination of registration module 312, fulfillment module 314, fraud module 316, error module 318, processor 302, etc. In some embodiments, the device identifier may be received from a third-party device management system that provides information for new subscriber registrations. For example, third-party device management system 458C. Alternatively, apparatus 300 may receive the device identifier by identifying or obtaining the device identifier as part of a routine synchronization service. For example, the DPPMS or a subsystem within the DPPMS may synchronize canceled registrations of all device identifiers associated with newly canceled subscriber profile data objects at a specific interval (e.g., at a specific time daily, weekly, etc.).

[0256] At block 412C, the apparatus 300 includes means for receiving a registration status from a third-party device management system, such as any one or combination of the registration module 312, the fulfillment module 314, the fraud module 316, the error module 318, the processor 302, etc. As illustrated, for example, the registration status may be obtained from a third-party device management system 456C. The third-party device management system 456C may embody a particular third-party device management system associated with a device protection program for the device associated with the device identifier obtained at block 402C. For example, the third-party device management system 456C may embody a system, server, etc. associated with a device manufacturer. The third-party device management system 456C may store third-party subscriber profile data objects that are managed independently from the subscriber profile data objects stored by the DPPMS. In some embodiments, the apparatus 300 obtains the registration status by transmitting a registration status request to the third-party device management system.

[0257] The cancellation service 452C may then determine a flow of operations based on the obtained registration status. For example, as depicted, if the obtained registration status indicates that the device identifier is not registered by the third-party device management system 456C (e.g., indicates that an associated third-party subscriber profile data object does not exist), the flow may continue at block 414C. In such a situation, the apparatus 300 includes means for synchronizing the DPPMS and / or one or more DPPMS subsystems based on the registration status received from the third-party device management system 456C, such as any one or combination of the registration module 312, fulfillment module 314, fraud module 316, error module 318, processor 302, etc. For example, the apparatus 300 may identify one or more existing subscriber profile data objects managed by the DPPMS and / or one or more DPPMS subsystems, erase the subscriber profile data objects, mark each for erasure, or mark the subscriber profile data objects as registered. It can be marked as not available.

[0258] Flow may alternatively continue from block 412C to block 416C if the registration status indicates that the device identifier is registered with the third-party device management system 456C (e.g., indicates that an associated third-party subscriber profile data object does not exist). In such a situation, the apparatus 300 includes means for attempting to cancel the registered device identifier via the third-party device management system, such as any one or combination of the registration module 312, the fulfillment module 314, the fraud module 316, the error module 318, the processor 302, etc. In this regard, the apparatus 300 may transmit one or more requests, signals, etc. to the third-party device management system 456C to attempt to erase the third-party subscriber profile data object associated with the device identifier, mark it as unregistered, or otherwise indicate its cancellation. In response to such attempt(s), the apparatus 300 may receive confirmation information in return indicating that the third-party subscriber profile data object was successfully erased or canceled, or indicated as one or more transmission error(s).

[0259] In some embodiments, the cancellation service 452C receives the device identifier in the form of a registration cancellation notification from a trusted third-party device management system, e.g., directly from the third-party device management system 456C instead of 458C. In some such embodiments, the cancellation service 452C may perform one or more system synchronization events without subsequent approval by the third-party device management system from which it was received. In this regard, in some such embodiments, the cancellation service 452C may synchronize the DPPMS and / or one or more DPPMS subsystems by proceeding immediately to block 414C to cancel the corresponding registered subscription profile.

[0260] Error Classification and Handling FIG. 9 illustrates a block diagram of an exemplary system within which embodiments of the present disclosure may operate in accordance with the disclosure herein. Specifically, FIG. 9 illustrates an exemplary configuration in which embodiments of the present disclosure may receive, classify, and / or manage received transmission errors resulting from failed transmissions. As illustrated, the enrollment management subsystem 902 may communicate with an exemplary third-party device management system 912. The enrollment management subsystem 902 includes a number of services that may be embodied by a combination of hardware and / or software running on the hardware to facilitate error management and reporting, as described below. In some embodiments, the enrollment management system 902 may operate as a separate service that functions and can be maintained independently from one or more other services within the DPPMS, such that maintenance and troubleshooting can be performed on the enrollment management system without losing functionality to the rest of the DPPMS. In some embodiments, the enrollment management subsystem 902 operates with one or more executed action process instances, for example, as described with respect to FIG. 7.

[0261] In an exemplary embodiment, enrollment management subsystem 902 may be embodied by device 300 or one or more modules of device 300, such as enrollment module 312, processor 302, error module 318, etc. In other embodiments, enrollment management subsystem 902 may be a subsystem associated with device 300. In some embodiments, enrollment management subsystem 902 and / or one or more components of enrollment management subsystem 902 may be accessed and executed against a configured cloud system including one or more remote and / or "cloud" servers specially configured with the components described therein. Similarly, in some embodiments, fulfillment and / or One or more microservice subsystems for fraud prevention may similarly run on specially configured remote and / or cloud servers.

[0262] The enrollment management subsystem 902 may be configured to communicate with a third-party device management system 912 via a network 914. The third-party device management system may manage one or more third-party subscriber profile data objects associated with one or more subscribers enrolled in the device protection program via the third-party device management system. For example, the third-party device management system 912 may be configured to maintain a database or list including all third-party subscriber profile data objects enrolled in the device protection program via a third-party system or entity.

[0263] The enrollment management subsystem 902 may communicate with a third-party device management system 912 to verify, validate, or update one or more DPPMS subsystems, including one or more DPPMS subscriber profile data objects. For example, the enrollment management subsystem 902 may be configured to communicate with a third-party device management system 912 to receive a new enrollment management request data object and / or to validate a third-party enrollment status associated with an enrollment management request data object being processed.

[0264] As illustrated, the registration management subsystem 902 can include a registration processing microservice 904, an error handling service 908, an error configuration service 906, a data store 910, and a reporting solution 909. The registration processing microservice 904 can be configured to maintain an action queue configured to store unprocessed registration management request data objects. Additionally or alternatively, the registration processing microservice 904 can be configured to manage one or more action process instances configured to process unprocessed registration management request data objects from the action queue.

[0265] While processing outstanding actions, such as registration management request data objects, via registration processing microservice 904, registration management subsystem 902 may communicate with third-party device management systems 912 over network 914. Registration management subsystem 902 may be configured to transmit to third-party device management systems 912, for example, one or more from a group including a third-party registration status request data object, a third-party subscriber registration request data object, a third-party subscriber cancellation request data object, or other registration management request data objects.

[0266] However, due to a myriad of computing issues, including networking, communication, power, or other issues, a transmission may fail to be successfully received by and / or responded to by the third-party device management system 912. As a result of the failed transmission, the registration management subsystem 902 may identify, receive, or otherwise determine a transmission error resulting from the failed transmission. The failed transmission may result from a variety of different types of transmission errors, including, but not limited to, software failures, hardware failures, and / or third-party submission failures.

[0267] The error handling service 908 may be configured to identify, receive, or otherwise determine the occurrence of such transmission errors. Additionally or alternatively, in some embodiments, the error handling service 908 may be configured with error handling logic. In particular embodiments, the error handling logic associated with the error handling service 908 may be configured to associate transmission errors with error configurations. The concatenation may be used to classify a received transmission error and / or to identify one or more error handling actions to perform in response to the transmission error.

[0268] The error handling service 908 may be configured to utilize the error configuration service 906 to identify an error configuration based on a transmission error. For example, the error handling service 908 may identify an error code and / or error message included in or associated with the transmission error, where the error code, error message, or a combination thereof is used to identify the associated error configuration. The error configuration may be associated with or include at least the error code and / or error message of the associated transmission error and the error classification associated with the transmission error. In some embodiments, the error configuration may also include information associated with or identifying an error handling instruction set that embodies an error handling protocol. For example, in some embodiments, the error configuration may include a maximum retry threshold for use with the executed error handling instruction set.

[0269] The error handling logic may cooperate with the error configuration service 906 to identify, determine, or obtain an error handling instruction set that represents an error handling protocol that includes one or more error handling events. For example, the error handling service 908 may identify an error handling instruction set associated with information included in an error configuration or otherwise identified, such as an error classification associated with a transmission error.

[0270] The error handling service 908 may be configured to execute one or more error handling events based on the identified error handling instruction set. In a particular example where the error configuration indicates that the transmission error is a retryable error, the error handling service may be configured to identify whether the failed transmission has been retried beyond an associated maximum retry threshold, and if not, identify a required retry time, and send the failed transmission back to the transmission queue after the determined retry time. In another particular example where the error configuration indicates that the transmission error is an escalation error, the error handling service may be configured to add or otherwise insert the failed transmission into an escalation queue. The escalation queue may store one or more failed transmissions that require attention by a third-party entity or another third-party system for error handling. In some embodiments, the error handling service 908 may be configured to generate or identify one or more error reports associated with the transmission error.

[0271] The error handling service may utilize a data store 910 to store error reports and / or manage one or more action queues. In some embodiments, the data store 910 is configured to store error reports such that one or more users may engage the registration management subsystem to obtain the error reports via the reporting solution 909. For example, the reporting solution 909 may be configured to enable access to the data store 910. The reporting solution 909 may be configured to allow a user to escalate one or more transmission errors, such as escalation errors in an escalation queue, to a third-party entity. For example, the reporting solution 909 may be configured to enable escalation of a transmission error in an escalation queue by transmitting an error escalation request to the third-party device management system 912 or another third-party system associated with the third-party device management system 912, such as a third-party error system (not shown). In some embodiments, escalation errors in the escalation queue may be handled via one or more human operators, and the queue may be changed or otherwise updated via the reporting solution 909.

[0272] 5 illustrates operations in a simplified exemplary process for error classification and processing of transmission errors received by a DPPMS in accordance with the disclosure herein. The operations illustrated and described with respect to FIG. 5 may be performed by a DPPMS embodied by apparatus 300 that includes hardware and / or software embodying entitlement management subsystem 902 illustrated in FIG. 9 and described above. For example, in certain exemplary embodiments, entitlement module 312, error module 318, processor 302, communications module 308, data store management module 310, and / or combinations thereof may be configured to embody entitlement management subsystem 902 as described above with respect to FIG. 9.

[0273] At block 502, the apparatus 300 includes means, such as the error module 318, the processor 302, or the communications module 308, for receiving a third-party transmission error in response to a failed transmission to the third-party device management system. As a particular example, the DPPMS embodied by the apparatus 300 may transmit a third-party registration management request data object to the third-party device management system and lose connectivity or otherwise be unable to receive a corresponding third-party registration management response from the third-party device management system. Thus, without receiving such a response, the DPPMS embodied by the apparatus 300 may remain unaware as to whether the third-party device management system successfully performed the required action in response to the third-party registration management request data object.

[0274] At block 504, the apparatus 300 includes a means for identifying an error classification associated with the third-party transmission error, such as the error module 318, the processor 302, etc. In particular embodiments, the apparatus 300 may identify an error classification set including one or more error classifications and identify the error classification from the error classification set. Examples of the error classification set may include a "retryable error" and an "escalation error." In some embodiments, the apparatus 300 may identify the error classification based on the failed transmission, the third-party transmission error, subscriber information associated with the failed transmission, and / or various other factors. In some embodiments, the apparatus 300 includes a means for identifying an error configuration associated with the transmission error, such as the error module 318, the processor 302, etc. In some embodiments, the error configuration includes at least an error classification and a maximum retry threshold, each associated with the transmission error.

[0275] In an exemplary aspect, the error categories of “retryable error” and “escalation error” may include one or more subcategories. For example, the apparatus 300 may maintain an escalation error category that identifies a particular third-party error handling device intended to handle transmission errors. Examples of such error categories include, but are not limited to, a “point-of-sale escalation error” and a “manufacturer escalation error” for a particular subscriber device. A point-of-sale escalation error may indicate, for example, that poorly formatted, incomplete, or otherwise unusable or bad data has been received from a third-party system, such as a third-party device management system embodying a point-of-sale system. In this regard, a point-of-sale escalation error may be associated with an error configuration requiring escalation to a third-party error handling system, such as a system controlled by the carrier entity that transmitted the initial request, for manual intervention. A manufacturer escalation error may indicate, for example, that the request requires data obtainable from a third-party system associated with the manufacturer entity of the particular subscriber device, and the error may be associated with a configuration requiring escalation of the error to a third-party error handling system controlled by the third-party entity.

[0276] Similarly, the device 300 may maintain a retryable error classification associated with a particular error handling instruction set, where the error handling instruction set further defines an error handling protocol, e.g., if subsequent retries of a failed transmission are unsuccessful. Examples of such error classifications include, but are not limited to, a "system retryable error" and a "failure error after retry." A system retryable error may indicate that the field and / or data format of the transmission contains an error and may be continually retriable based on one or more retry protocols, such as using an exponential backoff. A failure error after retry, if not resolved through one or more retry attempts, may indicate that no action can be taken on the error and may be marked as ineligible or retried with a limited maximum retry threshold (e.g., one retry in some embodiments) before receiving a new failure error. A failure error may not be associated with a particular configuration that does not include any error handling instruction set, such that no action is required to handle such an error. For example, a failure error may be received that is associated with a subscriber device that cannot enroll in a particular device protection program.

[0277] At block 506, the apparatus 300 includes a means, such as the error module 318, the processor 302, etc., for identifying an error handling protocol defined by an error handling instruction set associated with the identified error classification. Each error classification may be associated with one or more error handling protocols, each including one or more error handling events. For example, an error handling protocol associated with a “retryable” error classification may include at least identifying a retry time, queuing the failed transmission for transmission after the retry time has elapsed, and waiting the retry time. For example, an error handling protocol associated with an “escalation” error classification may include inserting the transmission error into an escalation queue. In some embodiments, the apparatus 300 may access an error database, for example, via a data store, to identify the error handling protocol associated with the identified error classification.

[0278] At block 508, the apparatus 300 includes means for initiating one or more of the error handling events included in the identified error handling protocol, such as the error module 318, the processor 302, etc. For example, the apparatus 300 may include means configured to identify a retry time for a retryable error, place the failed transmission in a transmission queue for retransmission after the retry time has elapsed, and wait the retry time. The apparatus 300 may also include means configured to insert the transmission error into an escalation queue for an escalation error.

[0279] At block 510, the apparatus 300 includes means for generating an error report based on the received third-party transmission error, such as the error module 318, the processor 302, etc. The error report may include information and / or metadata related to the third-party transmission error, the error classification, an identified error handling instruction set, etc.

[0280] At block 512, the apparatus 300 includes a means for storing the generated report in an error database, such as the error module 318, the processor 302, etc. In some embodiments, a single data store is configured to store the error report along with all other stored data. In other embodiments, the error database is separate from other data types. The error report may be stored in association with information and / or metadata based on the received third-party transmission error, such that the error report may be retrieved when a subsequent third-party transmission error of the same type occurs and utilized to improve the efficiency of classifying and / or handling such transmission errors. In other embodiments, the error database serves as an error log of received errors. As such, an error report is generated and added to the error database.

[0281] A DPPMS, such as the DPPMS embodied by apparatus 300, may perform one or more of the operations illustrated in Figure 5 to process a transmission error received in response to an attempted transmission to a third-party system, such as a third-party device management system, for example, a transmission error received during the process illustrated by Figures 4A and 4B, or a transmission error received in connection with any other message or synchronization failure. Accordingly, Figure 6 illustrates an exemplary detailed process including operations that may be performed by a DPPMS, such as the DPPMS embodied by apparatus 300, configured for registration management and error handling to improve overall system robustness and efficiency.

[0282] At block 602, the apparatus 300 includes means, such as the error module 318, the processor 302, or the communications module 308, for receiving a third-party transmission error in response to a failed transmission to the third-party device management system. As described above, for example, the DPPMS embodied by the apparatus 300 may transmit a third-party registration management request data object to the third-party device management system and lose connectivity or otherwise be unable to receive a corresponding third-party registration management response from the third-party device management system.

[0283] At optional block 604, the apparatus 300 includes means, such as the error module 318, the processor 302, etc., for generating an error report based on the received third-party transmission error. At optional block 606, the apparatus 300 includes means, such as the error module 318, the processor 302, the data store management module 310, etc., for storing the generated error report in an error database. Thus, the error report may be recorded in the error database for future auditing and / or error handling. For example, a user may review one or more error reports for received but uncategorized errors and assign corresponding error configurations including user-determined error classifications and / or error handling instruction sets as appropriate for handling the transmission errors.

[0284] At block 608, the apparatus 300 includes a means for identifying an error classification associated with the third-party transmission error, such as the error module 318, the processor 302, etc. In the illustrated example, the error classification may be selected from an error classification set that includes at least a “retryable” error classification and an “escalation” error classification, as described above. In other embodiments, additional or alternative error classifications may be included in the error classification set. The error handling classification may be identified based on information and / or metadata associated with the transmission error and / or failed transmission. For example, in some embodiments, the apparatus 300 may extract an error identifier from the transmission error for use in identifying the transmission error. In other embodiments, the apparatus 300 may determine a transmission type associated with the failed transmission and utilize the transmission type, alone or in combination with other information, such as the error identifier, to determine the error classification.

[0285] At block 610, the apparatus 300 includes a means for identifying an error handling protocol associated with the identified error classification, such as the error module 318, the processor 302, etc. The error handling protocol may be represented by an instruction set for resolving the error. In some embodiments, the error handling protocol instruction set may include retry and / or escalation instructions, such as the exemplary protocol beginning at block 612. The identified error handling protocol may be based on the error classification determined at decision block 608, as illustrated. For example, as illustrated, an escalation error handling protocol may be identified in association with the escalation error classification, where the escalation error handling protocol is associated with at least one or more errors, such as at block 614. Alternatively, as illustrated, a retryable error handling protocol may be identified in association with the retryable error classification, where the retryable error handling protocol includes one or more error handling events, such as at least blocks 616-630 and 614.

[0286] Referring back to decision block 612, if the identified error classification is an escalation error (e.g., from an error configuration identified based on the error code and / or error message of the received transmission error), flow continues to block 614, which embodies a single error handling event during an escalation error handling protocol. At block 614, the third-party transmission error is added to an escalation queue. In some embodiments, the apparatus 300 is configured to manage the escalation queue and transmit errors in the escalation queue to one or more third-party servers. In some embodiments, the apparatus 300 may include means for transmitting the error to a third-party error handling system and also automatically receiving an escalation response from the third-party error handling system. In other embodiments, the escalation error in the escalation queue is resolved by manual intervention, such as by a human operator via a DPPMS, such as a DPPMS embodied by the apparatus 300, or by a human operator via a third-party error handling system. Although the escalation error handling protocol illustrated in FIG. 6 ends here, it should be understood that other escalation error handling protocols may include additional or alternative error escalation steps.

[0287] Returning again to decision block 612, if the error classification is determined to be a retryable error, flow continues to block 616 to implement the first error handling event in the illustrated error handling protocol associated with the retryable error embodied by blocks 616-630 and 614.

[0288] At block 616, the apparatus 300 includes means configured to identify a maximum retry threshold, such as the error module 318, the processor 302, etc. The maximum retry threshold defines the maximum number of retransmission attempts the apparatus 300 may perform for a particular transmission error. In some embodiments, all retryable errors may be associated with a predetermined maximum retry threshold. In other embodiments, the maximum retry threshold associated with a retryable error may be determined based on various factors, such as a current date timestamp, server load, escalation queue length, retransmission queue length, etc.

[0289] In some embodiments, the retry maximum threshold represents a timestamp interval that represents a particular length of time that the device 300 may continue to retry transmission of a failed transmission associated with a received transmission error. The length of time embodied by the retry maximum threshold may represent a predetermined timestamp interval that is set, for example, by a user of the device 300. Alternatively, or in addition, the retry maximum threshold may represent a timestamp interval that is determined by the device 300 based on one or more factors, such as a current date timestamp, server load, escalation queue length, retransmission queue length, etc.

[0290] At block 618, the apparatus 300 includes means for identifying the number of retry attempts, such as the error module 318, the processor 302, etc. In some embodiments, the apparatus 300 is configured to track a number of transmission attempts associated with a failed transmission, representing the number of retry attempts. Thus, in some embodiments, if the DPPMS embodied by the apparatus 300 has not yet attempted to retransmit a failed transmission, a retry attempt number of zero may be assigned. In other embodiments, the retry attempt number may represent the number of remaining retry attempts, such that the retry attempt number is set to a predetermined number (e.g., five retry attempts) and is decremented after each retry.

[0291] At block 620, the apparatus 300 includes means, such as the error module 318, the processor 302, for identifying a retry-related result data object based on the maximum retry threshold and the number of retry attempts. The retry-related result data object may be identified by comparing the maximum retry threshold and the number of retry attempts based on the retry relationship, or may be determined in other ways. For example, the retry-related result data object may indicate whether the retry attempt number is greater than (or greater than) the maximum retry threshold or less than (or less than) the maximum retry threshold.

[0292] Alternatively, in some embodiments, the retry attempt count represents the total time spent on retry attempts for a particular failed transmission. In this regard, the retry attempt count may be incremented by the wait time of the previous retry iteration (if any). In some embodiments, the apparatus 300 is configured to track the retry attempt count using, for example, one or more clocks and / or timers embodied in hardware and / or software. In still other embodiments, the apparatus 300 tracks the number of transmission attempts and uses the number of transmission attempts to determine the previous wait time for one or more previous retry attempts. In some such embodiments, the retry-related result data object may represent whether the retry attempt count exceeds a maximum retry threshold (e.g., whether the data indicating the total time spent on retries exceeds the maximum time allowed). In some embodiments, the retry-related result data object indicates that the maximum retry threshold is met when the number of retry attempts falls below the maximum retry threshold.

[0293] At decision block 622, the apparatus 300 includes means, such as the error module 318, the processor 302, etc., for determining whether the retry relationship result data object indicates that the retry relationship is satisfied. In some embodiments, for example, the retry relationship is satisfied when the number of retry attempts, as indicated by the retry relationship result data object, is less than a maximum retry threshold. In other embodiments, the retry relationship is satisfied when the number of retry attempts is greater than the maximum retry threshold (e.g., when the number of retry attempts is decremented and the maximum retry threshold is at zero or a boundary number).

[0294] For example, the retry maximum threshold represents a timestamp interval and the number of retry attempts represents the total time spent on all retry attempts, and in other embodiments, the retry relationship is satisfied when the number of retry attempts is less than (or less than or equal to) the retry maximum threshold indicated by the result data object of the retry relationship. In other embodiments, the retry relationship is satisfied when the number of retry attempts is greater than the retry maximum threshold (e.g., when the number of retry attempts is decremented based on the wait time).

[0295] If it is determined that the retry relationship is not satisfied, flow may continue at block 614. For example, if the retry relationship does not satisfy the maximum retry threshold, the retryable error may be escalated and placed in an escalation queue, as shown in block 614. In other embodiments, the retryable error may be reclassified as an escalation error before being added to the escalation queue.

[0296] Alternatively, if the retry relationship is determined to be satisfied, such as when the number of retry attempts incremented per transmission attempt is less than a maximum retry threshold, flow may continue at block 624. At block 624, the apparatus 300 includes a means for determining a requested retry time, such as the error module 318, the processor 302, etc. The retry time represents the amount of time the system must wait before attempting to retransmit a failed transmission. In some embodiments, the requested retry time is determined based on the number of retry attempts. For example, the requested retry time may be determined starting from a minimum retry time and associated with the previous attempt. The retry time may be based on an exponential backoff algorithm that doubles the requested retry time. For example, the minimum retry time may be set to 5 minutes, such that when the number of retry attempts is zero (e.g., the wait time before the first retry attempt), the device 300 determines the retry time to be 5 minutes. Subsequently, the retry time is doubled so that when the number of retry attempts is 1 (e.g., before the second retry attempt), the retry time is 10 minutes, and when the number of retry attempts is 2 (e.g., before the third retry attempt), the retry time is 20 minutes. In other embodiments, alternative algorithms or rules may be utilized to determine the retry time.

[0297] At block 626, the apparatus 300 includes means for waiting the determined retry time, such as the error module 318, the processor 302, etc. In some embodiments, the apparatus 300 may track the time elapsed since the previous transmission or retransmission attempt. The embodiment may continue to operate, such as by attempting another transmission and / or performing other operations, while waiting the retry time.

[0298] At block 628, the apparatus 300 includes a means for adding the failed transmission to a transmission queue, such as the error module 318, the processor 302, etc. The transmission queue may include outstanding requests to be transmitted to one or more third party systems, which the apparatus 300 may include means configured to process and transmit as identified above and below. After the failed transmission reaches the head of the queue, the DPPMS embodied by the apparatus 300 processes the failed transmission and attempts to transmit it again.

[0299] At decision block 630, the apparatus 300 includes means for determining whether the failed transmission was successfully retransmitted, such as the error module 318, the processor 302, or the communications module 308. If the transmission was unsuccessful, flow may return to block 618, in which case the number of retry attempts is incremented. In some embodiments, another third-party transmission error may be received and identified as a retryable error based on the previous error classification. Alternatively, in some embodiments, flow may return to block 602, and the other third-party transmission error may be reclassified to determine whether the subsequent third-party transmission error is also a retryable error or whether a new escalation error has occurred. Returning to decision 630, if the transmission was successfully transmitted, the process ends.

[0300] It will be appreciated that a DPPMS configured to perform the operations described with respect to FIG. 6 may effectively allocate processing resources, reduce the amount of unnecessarily escalating errors, and therefore improve completion times for processing actions such as enrollment management request data objects or claims.

[0301] It should also be understood that the error handling protocol illustrated in Figure 6 and the specific error handling events illustrated in Figure 6 are examples. Alternate error handling protocols may include alternative error handling events, different sequences of error handling steps, and / or additional error handling events. Accordingly, the spirit and scope of the disclosure herein is not limited to the details of the exemplary error handling protocol illustrated by blocks 612-630 and described above.

[0302] Example Scaling Service The DPPMS embodied by the device 300 may include means for processing one or more received and / or triggered actions and / or requests in connection with one or more of the systems, subsystems, and processes described herein. For example, a registration management request data object, claim, etc. may require processing by the DPPMS embodied by the device 300 to achieve a particular goal. For example, a registration subscription request may confirm registration with a third-party device management system and may be used to manage the DPPMS subscription. A registration cancellation request data object may require processing resources to create and / or add a subscriber profile data object to the DPPMS and / or cancel a DPPMS subscriber profile data object associated with one or more DPPMS subsystems associated with the DPPMS. A registration cancellation request data object may require processing to verify the cancellation from the third-party device management system and cancel a DPPMS subscriber profile data object associated with the DPPMS and / or cancel a DPPMS subscriber profile data object associated with one or more DPPMS subsystems. A claim may require processing to verify that the claim is not fraudulent (such as by executing an anti-fraud protocol) and execute a claim processing protocol. In some embodiments, the claim processing protocol includes a set of claim processing instructions that the device initiates in association with the claim data object of a particular claim.

[0303] Processing these actions may require significant processing resources and / or require a significant amount of time. In addition, in some embodiments, outstanding actions may be received in very large batches, such that the action queue of outstanding actions may rapidly expand from few or no actions in the action queue to a significant number of outstanding actions within a short period of time. For example, one or more of the third-party systems disclosed herein may transmit bulk requests (e.g., at predetermined times during the day), such that large batches of various activities must be processed quickly and without undue delay or burden on the subscriber or third parties. Accordingly, the DPPMS embodied by apparatus 300 may be configured with a scaling service, as illustrated in FIG. 7, to manage one or more action process instances associated with processing outstanding actions stored in the action queue.

[0304] Referring to FIG. 7 , an example system is shown that includes a scaling service 702, an action queue 716, and a set of action process instances, specifically, executed action process instances 704, 706, and 708. Each of the action process instances includes a set of executed process threads, such as executed process thread sets 710, 712, and 714. The scaling service 702 is associated with an action process instance count maximum value, or “max action processes,” equal to 3 in the illustrated example. The scaling service 702 is also associated with an action process instance count minimum value, or “min action processes,” equal to 1 as illustrated. Additionally or alternatively, the scaling service 702 may be associated with a process thread count maximum value. Each executed action process instance may include a number of process threads that is less than or equal to the process thread count maximum value, or in some embodiments, non-inclusively less than the process thread count maximum value. In some embodiments, each executed action process instance is initialized and / or otherwise executed with an initial number of threads based on the process thread count maximum value. The initial thread number of a newly executed action process instance may be equal to the process thread count maximum value.

[0305] Action queue 716 may be associated with one or more outstanding actions and / or outstanding action types or request types. For example, in particular embodiments, action queue 716 may be configured to maintain outstanding requests associated with a single request type, such as outstanding entitlement management request data objects. In another embodiment, action queue 716 may be configured to maintain outstanding requests associated with multiple request types, e.g., outstanding entitlement management request data objects, escalated error transmission requests, and / or other actions requiring processing.

[0306] Each of the executed action process instances 704, 706, and 708 may be configured to process one or more request types from the action queue 716. For example, the executed action process instance 704 may be configured to process an outstanding registration management request data object. Thus, the scaling service 702 may be configured to maintain a set of executed action process instances that includes at least the executed action process instances 704, 706, and 708.

[0307] Each executed action process instance may include an executed process thread set, such as executed process thread set 710 associated with executed action process instance 704. The executed action process instance utilizes each executed process thread to process outstanding actions from action queue 716 at a particular rate. For example, for executed action process instance 704, each executed process thread in executed process thread set 710 may be configured to process a particular number of outstanding actions per minute. Thus, as the number of executed process threads in a particular executed action process instance increases, the total action processing rate associated with the executed action process instance increases. In some embodiments, the executed process instance executes with a predefined number of process threads automatically configured to process outstanding actions associated with action queue 716 (e.g., the executed process threads are automatically configured to process outstanding registration management request data objects or another type of outstanding action type). It should be understood that the outstanding actions may be any of a myriad of computational tasks, network calls, data management actions, etc.

[0308] The scaling service 702 may be embodied by software or a combination of software and hardware controlled by or otherwise associated with one or more of the registration module 312, the fulfillment module 314, the fraud module 316, and / or the error module 318, which manage all executed process instances and allocate outstanding actions from the action queue 716 for processing by one of the executed action process instances, such as executed action process instance 704, 706, or 708. In particular, the scaling service 702 may be embodied by the device 300, or a combination of sub-modules within the device 300, along with corresponding software and / or a combination of hardware and software.

[0309] In particular embodiments, the scaling service 702 may be configured to identify a queue length associated with the action queue 716, where the action queue length represents the number of outstanding actions in the action queue 716 at a particular time. The scaling service 702 may be configured to execute a new action process instance, terminate an executed process instance, execute a new process thread in the executed action process instance, and / or terminate a process thread executed in the executed action process instance based on the queue length. For example, the scaling service 702 may be configured to receive or otherwise identify a queue length maximum threshold and / or a queue length minimum threshold. The scaling service 702, in some embodiments, may determine a maximum queue relation representing a comparison between the queue length and the queue length maximum threshold. In some embodiments, if the maximum queue relation meets the queue length maximum threshold, e.g., if the queue length exceeds the queue length maximum threshold, the scaling service 702 updates the set of executed action process instances. For example, if the maximum queue relation meets the queue length maximum threshold, e.g., by exceeding the queue length maximum threshold, the scaling service 702 updates the set of executed action process instances. In this case, if the maximum action process instance count has not been reached, the scaling service 702 may execute a new action process instance. For example, in the illustrated example of FIG. 7, the maximum allowed action process count has already been reached, so a new action process instance cannot be executed.

[0310] In some embodiments, computing resources may be reallocated between specialized action process instances depending on the priority value assigned to each outstanding action and the available unused computing resources. In an exemplary aspect, registration requests may be prioritized over cancellation requests, and if a large number of registration requests are received while the system is at the action process instance count maximum or process thread count maximum, the scaling service 702 may reallocate one or more threads from a specialized executed action process instance configured to process cancellation requests to a second specialized executed action process instance configured to process registration requests. It should be understood that process threads may be reallocated in any of a myriad of ways, for example, by clearing a first process thread and reinitializing a new second process thread.

[0311] Additionally or alternatively, for example, the scaling service 702 may, in some embodiments, determine a minimum queue relation representing a comparison between the queue length and a queue length minimum threshold. In some embodiments, if the minimum queue relation meets the queue length minimum threshold, such as when the queue length is less than the queue length minimum threshold, the scaling service 702 updates the set of action process instances to be executed. For example, if the minimum queue relation meets the queue length minimum threshold, such as when the queue length is less than the queue length minimum threshold, the scaling service 702 terminates the selected action process instance if the action process instance count minimum has not been reached. For example, in the particular embodiment depicted by the illustrated FIG. 7, the action process 708 may be selected and terminated such that the action process 708 stops processing and is removed from the set of action process instances to be executed.

[0312] Additionally or alternatively, for example, scaling service 702, in some embodiments, may manage the executed process thread set(s) for one or more executed action process instance(s) based on queue length. For example, in some embodiments, instead of scaling the executed action process instances, scaling service 702 may increase or decrease the number of executed process threads in the executed process thread set for one or more executed action process instances. For example, each executed action process instance may be associated with a maximum executed process thread count (e.g., five as illustrated) and / or a minimum executed process thread count (e.g., one executed process thread).

[0313] In some such embodiments, if the minimum queue relation result data indicates that the minimum process queue relation is met, such as when the queue length is less than a queue length minimum threshold, the scaling service 702 terminates the selected executed process thread from the selected action process instance if the minimum executed process thread count is not met (in an exemplary aspect, if multiple threads are executed). If the minimum executed process thread count is met for the selected action process instance, the scaling service 702 may select another executed action process instance and determine whether the executing process thread can be terminated for the newly selected executed action process instance. Each executed action process instance may select a different executed action process instance and terminate the execution process thread for each respective minimum executed process thread count. In situations associated with an executed process thread count that matches the thread count, the scaling service 702 may then attempt to terminate the executed action process instance according to the minimum process instance relationship, as described above. Alternatively, in some embodiments, the first selected action process instance may reduce the set of executed process threads of the first selected action process instance, and the first selected action process instance may then be terminated before the scaling service 702 terminates the executed process threads from another executed action process instance.

[0314] Similarly, in some embodiments, if the maximum queue relation result data indicates that the maximum queue relation is satisfied, the scaling service 702 may attempt to execute a new process thread in one of the executed action process instances before attempting to execute a new action process instance. For example, the scaling service 702 may select an action process instance to be executed and determine whether the selected executed action process instance satisfies (e.g., by being less than) a maximum executed process thread count. In situations where the executed process thread count of the selected action process instance satisfies the maximum executed process thread count for the selected action process instance, the scaling service 702 may execute the new process thread through the selected action process instance. In situations where the executed process thread count for the selected action process instance does not satisfy (e.g., by the executed process thread count being greater than or equal to the maximum executed process thread count for the selected action process instance), the scaling service 702 may select another executed action process instance to attempt to execute a new process thread. In a situation where each executed action process instance is associated with an executed process thread count that matches each respective maximum executed process thread count, the scaling service 702 may then attempt to start and / or otherwise execute new action process instances, as described above, depending on the maximum process instance relationship.In some embodiments, a process thread is executed and / or terminated for one selected action process instance at a time (e.g., a selected action process instance is scaled up in the thread until it is at a maximum and / or subsequently executes a new action process instance which becomes the newly selected action process instance for scaling, or scaled down in the thread until it is at a minimum and / or subsequently terminated, if any, before selecting a new executed action process instance for scaling down).

[0315] It should be understood that the number of executed instances, action process instance count maximum threshold, process thread count, and process thread count maximum threshold illustrated in Figure 7 are merely examples. Embodiments of the present disclosure may include different number of executed instances, action process instance count maximum threshold, process thread count, and / or process thread count maximum threshold.

[0316] In some embodiments, scaling service 702 is implemented as software associated with one or more computing devices, components, or subsystems, or a combination of hardware and software. In some embodiments, scaling service 702 is implemented as hardware configured to execute one or more software modules to perform the operations described below with respect to FIGS. 8A and 8B. The system is embodied by hardware means.

[0317] It should be understood that apparatus 300 and / or one or more other systems may implement one or more scaling services for scaling the myriad of executed action process instances associated with processing a variety of different outstanding actions. For example, in some embodiments, apparatus 300 may include a scaling service that manages a first action queue of outstanding registration actions and scales executed action process instances configured to process outstanding registration actions from the first action queue. Apparatus 300 may additionally include a scaling service that manages a second action queue of outstanding fulfillment actions and scales executed action process instances configured to process outstanding fulfillment actions from the second action queue. Apparatus 300 may additionally include a scaling service that manages a third action queue of outstanding fraudulent activities and scales executed action process instances configured to process outstanding fraudulent activities. Alternatively, in some embodiments, apparatus 300 may implement three scaling services, each configured to manage one of the aforementioned action queues and a corresponding set of executed action process instances, executed via one or more microservices described above.

[0318] In other embodiments, apparatus 300 may further divide the action queue for enhanced processing. For example, apparatus 300 may include a first scaling service that manages a first action queue of outstanding registration actions associated with a first third-party device management system (e.g., a mobile device carrier system associated with a first carrier) and a second scaling service that manages a second action queue of outstanding registration actions associated with a second third-party device management system (e.g., a mobile device carrier system associated with a second carrier). Similarly, apparatus 300 may include a first scaling service that manages a first action queue of outstanding fulfillment actions associated with billing data objects for the first third-party device management system (or alternatively, a different third-party device management system) and a second action queue of outstanding fulfillment actions associated with billing data objects for the second third-party device management system (or alternatively, a different third-party device management system). In this regard, apparatus 300 may scale the executed process instances to perform process actions for each type of outstanding action per third-party device management system (or alternatively, per third-party entity).

[0319] 8A and 8B illustrate operations for managing an executed action process instance configured to process unprocessed actions stored in an associated action queue, according to an embodiment of the present disclosure. For example, the operations depicted in FIGS. 8A and 8B may be performed by an embodiment of the present disclosure that includes hardware and / or software for executing scaling service 702. As a particular example, the operations illustrated in FIGS. 8A and 8B may be performed by apparatus 300 utilizing various hardware means for executing and / or otherwise maintaining a scaling service, such as scaling service 702. It should be understood that the blocks illustrated with respect to FIGS. 8A and 8B may be performed as depicted, or may be performed in a different order, with additional blocks, alternative blocks, and / or fewer blocks than depicted, in other embodiments.

[0320] At block 802, the device 300 may include a queue associated with the action queue, such as a registration module 312, a fulfillment module 314, a fraud module 316, a processor 302, etc. The apparatus 300 may include means for identifying a queue length maximum threshold. The action queue may be configured to store one or more outstanding actions, e.g., outstanding enrollment management request data objects, outstanding claims, and / or outstanding error escalation requests. The apparatus 300 may be configured to maintain or otherwise control one or more action queues associated with the outstanding actions. In some embodiments, the queue length maximum threshold is predetermined, such as by the apparatus 300. In some embodiments, the apparatus 300 is configured to determine the queue length maximum threshold based on various factors. For example, the apparatus 300 may determine the queue length maximum threshold based on server load, a queue length associated with the action queue, time, date, etc., or any combination thereof.

[0321] At block 804, the apparatus 300 includes a means for identifying a queue length associated with the action queue, such as the registration module 312, the fulfillment module 314, the fraud module 316, or the processor 302. In some embodiments, the apparatus 300 is configured to sum the number of unprocessed actions in the action queue to determine the queue length. In other embodiments, the apparatus 300 maintains the queue length as actions are processed from the action queue, such as by one or more executed action process instances, and as new unprocessed actions are inserted into the queue.

[0322] At block 806, the apparatus 300 includes means for identifying a maximum queue relation result data object based on the queue length and the queue length maximum threshold, such as the registration module 312, the fulfillment module 314, the fraud module 316, or the processor 302. The maximum queue relation result data may indicate whether a particular maximum queue relation is satisfied. The maximum queue relation may represent a comparison of the queue length with the queue length maximum threshold. Thus, in some embodiments, the maximum queue relation may be satisfied if the queue length is less than, equal to, or greater than the queue length maximum threshold.

[0323] At block 808, the apparatus 300 includes means for determining whether the maximum queue relation result data object indicates that the maximum queue relation is met, such as the registration module 312, the fulfillment module 314, the fraud module 316, or the processor 302. In a particular example, the maximum queue relation result data object indicates that the maximum queue is met if the queue length exceeds a queue length maximum threshold. In another exemplary embodiment, the maximum queue relation result data object indicates that the maximum queue is met if the queue length is equal to or exceeds a queue length maximum threshold. If the maximum queue relation is met, embodiments of the present disclosure may attempt to increase the total processing associated with the processing instances executed, such as by increasing the number of action process instances executed, as described below.

[0324] If the max queue relation result data object indicates that the max queue relation is satisfied, flow continues to block 810. At block 810, the apparatus 300 includes a means for identifying the number of executed instances, such as the registration module 312, the fulfillment module 314, the fraud module 316, or the processor 302. In some embodiments, the apparatus 300 is configured to maintain the number of executed instances as new action process instances are executed and as executed process instances are terminated. In some embodiments, the apparatus 300 is configured to maintain an executed process instance list including all executed process instances, and to identify the number of executed instances based on the executed process instance list.

[0325] At block 812, the device 300 includes a registration module 312, a fulfillment module 314, and The correct module 316 includes a means for identifying the action process instance count maximum value, such as the processor 302. In some embodiments, the action process instance count maximum value is predetermined, such as by the apparatus 300. In some embodiments, the apparatus 300 is configured to determine the action process instance count maximum value. The apparatus 300, in some embodiments, may determine the action process instance count maximum value based on various factors, such as server load, a queue length associated with the action queue, time, date, available processing resources, e...

Claims

1. A system configured to detect transmission errors, comprising at least one processor and at least one memory, said at least one memory comprising computer-coded instructions therein, said computer-coded instructions, when executed by said at least one processor, causing said system to: Attempting to transmit a third-party registration management request data object from the system to a third-party device management system; detecting a transmission error associated with the attempted transmission to the third-party device management system, the transmission error indicating the occurrence of at least one error during the attempted transmission; identifying an error classification associated with the transmission error, the error classification indicating a retryable error or an escalation error; identifying an error handling instruction set based on the error classification; and executing the error handling instruction set; The error handling instruction set includes at least: attempting to resend the third-party registration management request data object if the error classification indicates a retryable error; adding a third-party registration management request data object to an escalation queue if the error classification indicates an escalation error; Including, system.

2. To identify the error classification, the system: Identifying a trained error classification machine learning model; and identifying the error classification using the trained error classification machine learning model.

3. the identified error classification is a retryable error, and to execute the error handling instruction set, the system: identifying an escalation queue; and adding the retryable error to the escalation queue.

4. the identified error classification is a retryable error, and to execute the error handling instruction set, the system: identifying a maximum retry threshold; Identifying a number of retry attempts; determining a retry relationship between the maximum retry threshold and the number of retry attempts; determining that the retry relationship satisfies a maximum retry threshold; determining a request retry time; adding the failed transmission to a request queue and attempting to retransmit the failed transmission after the request retry time has elapsed.

5. To determine the request retry time, the system: The system of claim 4 , configured to update the requested retry time based on the number of retry attempts.

6. To determine the request retry time, the system: The system of claim 4 , configured to update the request retry time based on an exponential backoff.

7. The identified error classification includes an escalation error, and to execute the error handling instruction set, the system: The system of claim 1 , configured to add the failed transmission to a transmission queue.

8. The method of claim 7, wherein the identified error classification from the error classification set is an escalation error, and to execute the error handling instruction set, the system: configured to transmit the error escalation request to a third-party error handling system; The system of claim 1 .

9. The system comprises: receiving a queue length associated with an action queue associated with the third-party registration management request data object; identifying a queue length threshold; identifying a queue relationship based on the queue length and the queue length threshold; determining that the queue relationship satisfies the queue length threshold; identifying a set of executed action process instances including at least one executed action process instance; The system of claim 1 , further configured to: update the set of action process instances to be executed based on the queue length.

10. A computer-implemented method for detecting transmission errors, comprising: Attempting to transmit a third-party registration management request data object to a third-party device management system; detecting a transmission error associated with the attempted transmission to the third-party device management system, the transmission error indicating the occurrence of at least one error during the attempted transmission; identifying an error classification associated with the transmission error, the error classification indicating a retryable error or an escalation error; identifying an error handling instruction set based on the error classification; executing the error handling instruction set; The error handling instruction set includes at least: attempting to resend the third-party registration management request data object if the error classification indicates a retryable error; adding the third-party registration management request data object to an escalation queue if the error classification indicates an escalation error; Including, Computer-implemented methods.

11. identifying the error classification, Identifying a trained error classification machine learning model; and identifying the error classification using the trained error classification machine learning model.

12. the identified error classification is a retryable error, and executing the set of error handling instructions; identifying an escalation queue; and adding the retryable error to the escalation queue.

13. the identified error classification is a retryable error, and executing the set of error handling instructions; identifying a maximum retry threshold; Identifying a number of retry attempts; determining a retry relationship between the maximum retry threshold and the number of retry attempts; determining that the retry relationship satisfies a maximum retry threshold; determining a request retry time; adding the failed transmission to a request queue and attempting to retransmit the failed transmission after the request retry time has elapsed.

14. determining the request retry time; The computer-implemented method of claim 13 , further comprising updating the requested retry time based on the number of retry attempts.

15. determining the request retry time; The computer-implemented method of claim 13 , comprising updating the request retry time based on an exponential backoff.

16. the identified error classification includes an escalation error, and executing the set of error handling instructions; The computer-implemented method of claim 10 , further comprising adding the failed transmission to a transmission queue.

17. The method of claim 16, wherein the identified error classification from the set of error classifications is an escalation error, and executing the set of error handling instructions comprises: The computer-implemented method of claim 10 , further comprising transmitting the error escalation request to a third-party error handling system.

18. The computer-implemented method comprises: receiving a queue length associated with an action queue associated with the third-party registration management request data object; identifying a queue length threshold; identifying a queue relationship based on the queue length and the queue length threshold; determining that the queue relationship satisfies the queue length threshold; identifying a set of executed action process instances including at least one executed action process instance; The computer-implemented method of claim 10 , further comprising: updating the set of action process instances to be executed based on the queue length.

19. A computer program for detecting a transmission error, the computer program being executed by a processor, the computer program causing the processor to: Attempting to transmit a third-party registration management request data object to a third-party device management system; detecting a transmission error associated with the attempted transmission to the third-party device management system, the transmission error indicating the occurrence of at least one error during the attempted transmission; identifying an error classification associated with the transmission error, the error classification indicating a retryable error or an escalation error; identifying an error handling instruction set based on the error classification; executing the error handling instruction set; The method is configured to: The error handling instruction set includes at least: attempting to resend the third-party registration management request data object if the error classification indicates a retryable error; adding the third-party registration management request data object to an escalation queue if the error classification indicates an escalation error; Including, Computer program.

20. To identify the error classification, the computer program executing on the processor causes the processor to: Identifying a trained error classification machine learning model; identifying the error classification using the trained error classification machine learning model; and 20. The computer program of claim 19, further configured to:

21. The identified error classification is a retryable error, and the computer program executing on the processor to execute the error handling instruction set causes the processor to: identifying an escalation queue; adding the retryable error to the escalation queue; 20. The computer program of claim 19, further configured to:

22. The identified error classification is a retryable error, and the computer program executing on the processor to execute the error handling instruction set causes the processor to: identifying a maximum retry threshold; Identifying a number of retry attempts; determining a retry relationship between the maximum retry threshold and the number of retry attempts; determining that the retry relationship satisfies a maximum retry threshold; determining a request retry time; adding the failed transmission to a request queue and attempting to retransmit the failed transmission after the request retry time has elapsed; 20. The computer program of claim 19, further configured to:

23. The computer program executing on the processor to determine the requested retry time causes the processor to: updating the requested retry time based on the number of retry attempts; 23. The computer program of claim 22, further configured to:

24. The computer program executing on the processor to determine the requested retry time causes the processor to: updating the request retry time based on an exponential backoff; 23. The computer program of claim 22, further configured to:

25. The identified error classification includes an escalation error, and the computer program executing on the processor to execute the set of error handling instructions causes the processor to: Adding the failed transmission to a transmission queue 20. The computer program of claim 19, further configured to:

26. The computer program executed by the processor to execute the error handling instruction set, wherein the identified error classification identified from the error classification set is an escalation error, causes the processor to: Transmitting error escalation requests to a third-party error handling system 20. The computer program of claim 19, further configured to:

27. The computer program causes the processor to: receiving a queue length associated with an action queue associated with the third-party registration management request data object; identifying a queue length threshold; identifying a queue relationship based on the queue length and the queue length threshold; determining that the queue relationship satisfies the queue length threshold; identifying a set of executed action process instances including at least one executed action process instance; updating the set of action process instances to be executed based on the queue length; 20. The computer program of claim 19, further comprising computer program instructions further configured to:

Images