OA20039A - Device detection and recording systems and methods. - Google Patents

Abstract

The system and methods described herein may detect and register devices. One or more processors receive a device identifier of a first device. The device identifier of the first device is authorized in response to performing a search in a first set of databases using the device identifier. The processors receive a record of an event corresponding to the device identifier, the record including the device identifier, a first value associated with the device identifier, and a first event identifier identifying the event. The processors store a first entry identifying the device identifier, the first value, the first event identifier, a specification of the first device, and a first state indicating that the first device is authorized. The processors assign the device identifier of the first device to a first group of the plurality of groups. The processors provide data corresponding to the first device and the first state.

Description

[0001] As the number of mobile devices and other smart devices connecting to telecommunications networks increases, there is a growing need to ensure that these devices are registered and authorized to access telecommunications networks. Through an effective registration and authorization process, entities, such as governments, network providers, and others, can identify unauthorized devices connecting to these networks and take certain measures to limit their access.

SUMMARY

[0002] The present disclosure relates to systems and methods for device detection and registration. According to one aspect, a method for device detection and registration is provided. The method may include receiving, from a client associated with a first entity, a device identifier of a first device. The method may include transmitting, to the first entity, an instruction indicating that the device identifier of the first device is authorized in response to performing a search in a first set of databases using the device identifier. The method may include receiving, from the first entity, a record of an event corresponding to the device identifier, the record comprising the device identifier, a first value related to the device identifier, and a first event identifier that identifies the event. The method may include storing, in the first set of databases, a first entry that identifies the device identifier, the first value, the first event identifier, a specification of the first device, and a first state indicating that the first device is authorized. The first set of databases may include a plurality of second device identifiers corresponding to a plurality of second devices. Each second device identifier of the plurality of second device identifiers may be assigned to a respective group of multiple groups.

Each device identifier of the first group may be permanently authorized to access one or more networks across one or more mobile network operators. The method may include providing, to a first system that maintains a second set of databases for a first mobile network operator, data corresponding to the first entry that identifies the device identifier, the first value, the first event identifier, the specification of the first device, and the first state. The second set of databases may be used by the first mobile network operator to respond to requests to verify one or more device identifiers corresponding to one or more respective devices connected to a first network of the first mobile network operator.

[0003] The method may include receiving, from the first system, data corresponding to a second device identifier of a second device, the second device identifier not included in the first set of databases. The data may correspond to the second device identifier stored in the second set of databases. The method may include updating the first set of databases to include a second entry comprising the data corresponding to the second device identifier of the second device. The method may include assigning, to the second entry corresponding to the second device identifier, a second state different from the first state. The method may include assigning the second device identifier to a second group of the plurality of groups or to a third group of the plurality of groups. Each device identifier included in the second group may be temporarily authorized to access one or more networks through one or more mobile network operators. Each device identifier included in the third group may be blocked from accessing the network(s) through the mobile network operator(s).

[0004] The method may include providing, to a second system maintaining a third set of databases for a second mobile network operator, data corresponding to the second entry. The third set of databases may be used by the second mobile network operator to respond to requests to verify one or more device identifiers respectively corresponding to one or more devices connected to a second network of a second mobile network operator.

[0005] The method may include identifying a first time corresponding to a second event when the second device accesses the first network of the first mobile network operator. The method may include updating, in response to determining a predetermined time that has elapsed since the first time, the second state of the second entry corresponding to the second device identifier to a third state different from the second state and the first state. The method may include assigning the second device identifier to the third group of the plurality of groups.

[0006] The method may include the predetermined duration based on a policy. The policy may be generated by a second entity.

[0007] The method may include the device identifier included in the first entry being a first device identifier of the first device. The method may include determining that the first device connected to the first network of the first mobile network operator at a first time. The method may include receiving, from the first system, data corresponding to a second device identifier of a second device. The data may correspond to the second device identifier stored in the second database set. The method may include determining that the second device identifier of the second device matches the first identifier included in the first entry. The second device connected to the second network of the second mobile network operator at the first time. The method may include determining that the third device identifier of the second device does not match a device identifier included in the first entry. The method may include assigning, in response to determining that the third device identifier of the second device does not match the device identifier included in the first entry, a label to the first entry indicating that the first device corresponds to a cloned device.

[0008] The method may include assigning, in response to determining that the third device identifier of the second device does not match the device identifier included in the first entry, the second device identifier of the second device to a second group of the plurality of groups, or to a third group of the plurality of groups. Each device identifier included in the second group may be temporarily allowed to access the one or more networks through the one or more mobile network operators. Each device identifier included in the third group may be prevented from accessing the one or more networks through the one or more mobile network operators.

[0009] The method may include providing, to the first system, the data corresponding to the first entry based on a time-based update policy.

[0010] The method may include providing, to a plurality of second systems, the data corresponding to the first input such that the first system and each second system of the plurality of second systems include the first input.

[0011] The method may include the device identifier being at least one identifier having an International Mobile Equipment Identity (IMEI), an International Mobile Subscriber Identity (IMSI), or a Mobile Multi-Service Digital Network Number (MSISDN).

[0012] The method may include receiving data corresponding to a second device identifier of a second device, the second device identifier included in the first database set and assigned a second state different from the first state. The method may include determining, from the received data corresponding to the second device identifier, a second value and a second event identifier that identifies a second event. The method may include updating, in response to determining that the second value and the second event identifier satisfy a state update policy, the second state of the second device identifier to the first state. The method may include assigning, in response to updating the second state to the first state, the second device identifier to the first group of the plurality of groups and removing the second device identifier from the second group of the plurality of groups.

[0013] The method may include receiving data corresponding to a third device identifier from a third device. The method may include determining that the third device identifier corresponds to an unauthorized device. In response to determining that the third device identifier corresponds to an unauthorized device, the method may include storing.

in the first database set, a second entry that identifies the third device identifier and a second status indicating that the third device is unauthorized. The method may include assigning the third device identifier to a second group of the plurality of groups or to a third group of the plurality of groups. Each device identifier included in the second group is temporarily authorized to access the one or more networks through the one or more mobile network operators, and each device identifier included in the third group is prevented from accessing the one or more networks through the one or more mobile network operators.

[0014] The method may include receiving data corresponding to a third device identifier of a third device. The method may include determining that the third device identifier corresponds to at least one of i) a duplicate device identifier, ii) a false device identifier, iii) a false statement of specifications or functions due for the third device, or iv) an indication that the transaction event identifying the third device was not processed. The method may include storing, in the first set of databases, a second entry identifying the third device identifier and a second state indicating that the third device is unauthorized. The method may include assigning the third device identifier to one of the second group of the plurality of groups or a third group of the plurality of groups. Each device identifier included in the second group is temporarily permitted to access the network(s) through the mobile network operator(s), and each device identifier included in the third group is prevented from accessing the network(s) through the mobile network operator(s).

[0015] The present disclosure further relates to a device detection and registration system. The method includes one or more processors configured by machine-readable instructions. The one or more processors may receive, from a client associated with a first entity, a device identifier of a first device. The one or more processors may transmit, to the first entity, an instruction indicating that the device identifier of the first device is authorized in response to performing a search in a first set of databases using the device identifier. The one or more processors may receive, from the first entity, a record of an event that matches the device identifier. The record may include the device identifier, a first value related to the device identifier, and a first event identifier that identifies the event. The one or more processors may store, in the first set of databases, a first entry that identifies the device identifier, the first value, the first event identifier, a specification of the first device, and a first state indicating that the first device is authorized. The first set of databases may include a plurality of second device identifiers corresponding to a plurality of second devices. Each second device identifier of the plurality of second device identifiers may be assigned to a respective one of the plurality of groups. The one or more processors may assign the device identifier of the first device to a first one of the plurality of groups. Each device identifier of the first group may be permanently authorized to access one or more networks through one or more mobile network operators. The one or more processors may provide, to a first system maintaining a second set of databases for a first mobile network operator, data corresponding to the first input identifying the device identifier, the first value, the first event identifier, the specification of the first device, and the first state. The second set of databases may be used by the first mobile network operator to respond to requests to verify one or more device identifiers corresponding to one or more respective devices connected to a first network of the first mobile network operator.

[0016] The one or more processors may receive, from the first system, data corresponding to a second device identifier of a second device. The second device identifier may not be included in the first set of databases. The data corresponding to the second device identifier may be stored in the second set of databases. The one or more processors may update the first set of databases to include a second entry comprising the data corresponding to the second device identifier of the second device. The one or more processors may assign the second entry corresponding to the second device identifier a second state different from the first state. The one or more processors may assign the second device identifier to a second group of the plurality of groups or to a third group of the plurality of groups. Each device identifier may be included in the second group temporarily authorized to access the one or more networks through the one or more mobile network operators. Each device identifier may be included in the third group blocked from accessing the network(s) through the mobile network operator(s).

[0017] The one or more processors may provide, to a second system maintaining a third set of databases for a second mobile network operator, data corresponding to the second entry. The third set of databases may be used by the second mobile network operator to respond to requests to verify one or more device identifiers corresponding to one or more respective devices connected to a second network of the second mobile network operator.

[0018] The one or more processors may identify a first time corresponding to a second event when the second device accesses the first network of the first mobile network operator. The one or more processors may update, in response to determining a predetermined time that has elapsed since the first time, the second state of the second input corresponding to the second device identifier to a third state different from the second state and the first state. The one or more processors may assign the second device identifier to the third group of the plurality of groups. The predetermined time may be based on a policy. The policy may be generated by a second entity of the one or more processors.

[0019] The device identifier included in the first entry may be a first device identifier of the first device. The one or more processors may receive, from the first system, data corresponding to the second device identifier of a second device. The data may correspond to the second device identifier stored in the second database set. The one or more processors may determine that the second device identifier of the second device matches the first device identifier included in the first entry. The one or more processors may determine that a third device identifier of the second device does not match the device identifier included in the first entry. The one or more processors may assign, in response to determining that the third device identifier of the second device does not match the device identifier included in the first entry, a label to the first entry indicating that the first device corresponds to a cloned device.

[0020] The present disclosure further relates to a non-transitory computer-readable storage medium having instructions incorporated therein, the instructions being executable by one or more processors. The one or more processors may receive, from a client associated with a first entity, a device identifier of a first device. The one or more processors may transmit, to the first entity, an instruction indicating that the device identifier of the first device is authorized in response to performing a search in a first set of databases using the device identifier. The one or more processors may receive, from the first entity, a record of an event corresponding to the device identifier. The record may include the device identifier, a first value related to the device identifier, and a first event identifier that identifies the event. The one or more processors may store, in the first database set, a first entry that identifies the device identifier, the first value, the first event identifier, a specification of the first device, and a first state indicating that the first device is authorized. The first database set may include a plurality of second device identifiers corresponding to a plurality of second devices. Each second device identifier of the plurality of second device identifiers may be assigned to a respective one of the plurality of groups. The one or more processors may assign the device identifier of the first device to a first one of the plurality of groups. Each device identifier of the first group may be permanently authorized to access one or more networks through one or more mobile network operators. The one or more processors may provide, to a first system that maintains a second set of databases for a first mobile network operator, data corresponding to the first entry that identifies the device identifier, the first value, the first event identifier, the specification of the first device, and the first standard. The second set of databases may be used by the first mobile network operator to respond to requests to verify one or more device identifiers corresponding to one or more respective devices connected to a first network of the first mobile network operator.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] FIG. 1A illustrates a data processing system for aggregating device records to one or more databases according to embodiments of the present disclosure.

[0022] FIG. 1B illustrates a connected implementation of the device detection and registration system for aggregating device registrations to one or more databases according to embodiments of the present disclosure.

[0023] FIG. 1C illustrates an exemplary network implementation of the data processing system for aggregating device records to one or more databases according to embodiments of the present disclosure.

[0024] FIG. 2A illustrates an implementation of the device detection and registration system with an equipment identity register installed at the mobile network operator.

[0025] FIG. 2B illustrates a packet flow corresponding to the implementation shown in FIG. 2A.

[0026] FIG. 2C illustrates an implementation of the device detection and registration system without an equipment identity register.

[0027] FIG. 3A illustrates a method of detecting and registering an apparatus according to embodiments of the present disclosure.

[0028] FIG. 3B illustrates a flow for detection and recording according to embodiments of the present disclosure.

[0029] FIG. 4 illustrates an implementation stack for the identity registration system.

[0030] FIG. 5A illustrates a device type assignment code analyzed by the device detection and registration system.

[0031] FIG. 5B illustrates data extracted from the device type assignment code for analysis by a device detection and registration system.

[0032] FIG. 6 illustrates a simplified block diagram of a representative server system 600 and client computing system 6I4 used to implement certain embodiments of the present disclosure.

DESCRIPTION DF I \ll I El

[0033] As a reading of the description of the various embodiments of the present invention below, the descriptions of the specification sections and their respective contents may be helpful:

Section A describes the device detection and recording systems;

Section B describes the process and workflow of a device detection and registration system implementation;

Section C describes a network environment and a computing environment useful for practicing embodiments of the present invention;

A. DEVICE DETECTION AND RECORDING SYSTEMS

[0034] Counterfeit, stolen, cloned, and fraudulent devices are widespread, posing a regulatory and security challenge for mobile operators and telecommunications authorities. The difficulty in differentiating counterfeit devices from genuine devices leads to difficulties in regulating network access. Counterfeit devices may have fake, redundant, or unauthorized device identifiers. In addition, the number of unauthorized devices, including devices with invalid device identifiers, is increasing, causing numerous problems related to mobile networks (interference, congestion, etc.) and the economy given the massive expansion of black market activity. These devices could also avoid payments, resulting in a loss of tax revenue for governments. Even if one network attempts to manage all these devices, the large number of networks within a jurisdiction would create data conflicts due to the lack of a centralized management system.

[0035] Therefore, a detection and registration system as described herein can solve the problems related to the management of connected devices. Regulatory authorities can control telecommunications systems by deploying the systems and methods described herein to detect and register devices to prevent their counterfeits from accessing one or more telecommunications networks and to improve the security of the telecommunications network(s). The device detection and registration system also ensures and facilitates connection to one or more global or worldwide databases, such as a GSMA database, which store device data to detect counterfeit or fake devices and ensure compliance of devices accessing telecommunications networks with national and international standards.

[0036] The device detection and registration system may be configured to include various subsystems or components. In some embodiments, the system may include a centralized identity registration system that may communicate with the plurality of local identity systems that may be deployed at each mobile network operator operating in a jurisdiction. The centralized identity registration system may provide a portal or interface through which entities, such as importers or distributors, may register communication devices imported into the jurisdiction or sold in the jurisdiction. The centralized identity registration system may determine whether the communication devices to be registered are authentic by comparing the device identifiers of those devices to one or more lists or databases. The centralized identity registration system may further determine whether those devices are duplicates, fakes, or counterfeits based on details about the devices, such as the device identifiers or device specifications of the devices. The centralized identity registration system may also collect taxes and customs duties from these devices. The centralized identity registration system may include the devices in a centralized database. The centralized identity registration system may store information about the devices in a centralized database and may assign each device identifier of each device to a whitelist, graylist, or blacklist in the centralized database. The whitelist may include genuine devices with paid taxes and therefore permanently authorized to access mobile network operators' networks. The graylist may include devices that are temporarily authorized to access networks in accordance with one or more policies established by the entity managing the centralized identity registration system. The blacklist may include devices prevented from accessing mobile network operators' networks. These devices may be devices identified as fake, duplicate, counterfeit, or devices for which taxes have not been paid and whose grace periods have been used up. It is contemplated that one or more additional lists may be generated for different restrictions, and that device identifiers may be assigned to any of the additional lists. For example, device identifiers assigned to a particular additional list may be prohibited from making international calls. In some embodiments, different restrictions may be applied to devices included in different lists. The data included in the centralized database may be replicated or shared with local databases maintained on the local identity systems. In this manner, when a device connects to a mobile network operator's network, the mobile network operator may verify whether the device is authorized or not from the mobile network operator's local identity system.

[0037] The centralized database may also include the devices based on information obtained by the local identity system(s). In some situations, the devices may connect to a mobile network operator's network without having been registered through the centralized identity registration system. For example, a person who has traveled from abroad may use their phone to connect to the network. In such a situation, the device first connects to the network before the person registers the device in the centralized identity registration system. In such situations, the local identity system may check a status of the device identifier in the local identity system. Depending on the status of the device identifier, the local identity system may apply certain restrictions on the device's rights to access the network. Further, the local identity system 10 may provide the device identifier to the centralized identity registration system so that the centralized identity registration system can determine whether the device is authentic or whether the device is duplicate or counterfeit. Depending on the authenticity of the device, the centralized identity registration system may take certain actions and assign the device identifier of the device to either the whitelist, or the graylist or the blacklist in the centralized database.

[0038] The present disclosure relates to systems and methods for device detection and registration. Referring now to FIGS. 1A, 1B, and 1C, FIG. 1A illustrates a device detection and registration system 100. FIG. 1B illustrates a connected implementation of the device detection and registration system for aggregating device information and including the devices in one or more databases. FIG. 1C illustrates an exemplary network implementation of the data processing system for aggregating device registrations to one or more databases. The device detection and registration system 100 may include the identity registration system 102. The identity registration system 102 may include a collector module 104, an authorization module 106, and a central identity registration (CIR) database 108. The device detection and registration system 100 may include one or more mobile network operators I 15a-115n (generally referred to as mobile network operators 115). One or more identification systems 110a-110n (generally referred to as local identification system 110) may be installed on or controlled and managed by mobile network operators 115. The local identification systems 110a-112n may include local identity registration databases 112a—112n (generally referred to as local identity registration (LIR) database 112) and identification system modules 114a-114n (generally referred to as identification system module 114). The device detection and registration system 100, the identity registration system 102, the collector module 104, the authorization module 106, the local identification system 110, and the identification system modules 114 may be any script, file, program, application, set of instructions, or computer-executable code that is configured to perform the functionalities described herein. Additional details relating to each of the components described above are provided below.

[0039] The identity registration system 102 may be configured to manage the status and authorization of electronic communication devices for connection to one or more telecommunications networks in a jurisdiction. The identity registration system 102 may be configured to provide a platform through which importers may provide a list of electronic devices for authorization to connect to the one or more telecommunications networks. The identity registration system 102 may further be configured to determine the authenticity of the electronic devices included in the list, as well as to determine whether taxes related to the electronic devices included in the list have been paid. In some embodiments, the identity registration system 102 may be configured to collect unpaid taxes or other duties, fees, or amounts related to the electronic devices. After authorization, the identity registration system 102 may store information about each electronic device in the CIR database 108, including information about amounts paid for the device as well as device identifier information used to determine the authenticity of the device. The identity registration system 102 may further be configured to classify or group each of the electronic devices into one or more groups or lists. These lists may be used to determine whether the electronic device is authorized to access the telecommunications network(s). In some embodiments, the lists may include a whitelist, a graylist, and a blacklist. Additional details about these lists and restrictions or permissions relating to these lists are provided herein.

[0040] In some embodiments, the identity registration system 102 may provide a user interface through which importers can pay taxes on devices they have imported and request authorization for the devices to access one or more networks. In some embodiments, the collector module 104 may first receive a request by the importer to pay taxes on a list of devices to be registered. The collector module 104 may then determine, from a list of devices, an amount to be collected from the importer based on one or more collection policies. In some embodiments, the collector module 104 may communicate with the authorization module 106 to determine the amount to be collected based on authentication of the devices. The collector module 104 may provide the calculated amount to the importer for collection, and in response may receive a payment from the importer. In some embodiments, the importer may have already paid taxes or may pay taxes through another portal, in which case, the importer may provide a reference identifier indicating that the taxes have been paid. The collector module 104, after receiving the payment or proof of payment, may generate a collection status for each device (or device identifier) indicating that the taxes on the device have been paid. The authorization module 106 may determine the authenticity of the device and assign a device authentication status (or device identifier) indicating whether the device is genuine, original, duplicate, or fake. Depending on the collection status and the authentication status, the identity registration system 102 may assign the device identifier to a particular group of the plurality of groups in the CIR database 108. The plurality of groups may include a whitelist group, a graylist group, and a blacklist group. Device identifiers in the whitelist can permanently access the network, identifiers in the graylist can temporarily access the network, and device identifiers in the blacklist cannot access the network. Additional details regarding this system are provided below.

[0041] As briefly mentioned above, the identity registration system 102 may receive, from a client linked to a first entity, a device identifier of a first device. The client may be a client device of a first entity such as an importer or distributor of electronic devices. In some embodiments, the identity registration system 102 may provide a user interface 124, through which the identity registration system 102 may receive a list of electronic devices from a client device of a first entity that wants to authorize or register the electronic devices. In some embodiments, the first entity may access a portal provided by the identity registration system 102 through a client device, and provide the list of electronic devices to be registered or authorized through a user interface provided by the portal.

The list of electronic devices may include a list of device identifiers that identify electronic devices. The device identifier may include a Subscriber Identity Module (SIM) card number or an International Mobile Equipment Identity (IMEI) number. Different versions of IMEI may be supported, such as 14, 15, and 16-digit IMEIs.

[0042] The collector module 104 of the identity registration system 102 may be configured to receive payment for the identity identifiers included in the list of identity identifiers that the first entry requests to authorize. The collector module 104 may process payments received from the first entry and, in response to processing the payment for each device identifier included in the list, assign a collection status to the device identifier of the device. The collection status 108 may be a tag, one or more bits, or any other indicator that may be used by the collector module 104 or the identity registration system 102 to determine that payment for the device has been received and processed. The collector module 104 may include payment data for each device. For each device brought into a jurisdiction, the collector module 104 may process or collect tax and duty payments, either for importation or for personal use. The jurisdiction may be a region, a country, or a predetermined area. The collector module 104 may receive data from a device such as its device identifier. The collector module 104 may receive a single device or a batch of devices. The collector module 104 may receive data from the importer such as their authorization entity ID number, name, company name, date, device model, and device identifier. The collector module 104 may receive payments through the user interface 124. In response to the collector module 104 processing payment for a list of devices, the collector module 104 may transmit the collection status 108 of the device list or device identifiers of the devices to the authorization module 106.

[0043] The authorization module 106 may be configured to check whether a device identifier of a device corresponds to either a non-duplicate original device, a device having a duplicate device identifier, or a device having a fake device identifier. The authorization module 106 may determine that a device is original if the device identifier is unique and also found in the global database of device identifiers maintained by a standards organization. In some embodiments, the authorization module may determine that a device is original if the device identifier is readable by a mobile network operator, generated by a legitimate manufacturer or regulatory entity, and capable of being processed by the mobile network operator. The authorization module 106 may determine that the device identifier is duplicate if the device identifier is identical to another device identifier currently connected to the network. For example, for a first device and a second device connected to the network, the authorization module 106 may determine that the two devices are duplicates if the device identifier of the first device is the same as the device identifier of the second device, but a SIM number or phone number of the first device differs from the SIM number or phone number of the second device. In some embodiments, the authorization module 106 may determine that a device has a duplicate device identifier if the device identifier matches another device identifier already stored in the CIR database 108 in case the device is registered by an importer through the identity registration system 102. The authorization module 106 or the identity registration system 102 may determine that the two devices are duplicate if the device identifier of the first device is the same as the device identifier of the second device, but the phone number of the first device differs from the phone number of the second device.

[0044] The authorization module 106 or the identity registration system 102 may determine that the device is fake if the device identifier is not found in the global database of 10 device identifiers maintained by the standards organization, or if the device specifications associated with the device identifier do not match the device specifications of the device (such as the device type assignment code) when verified by the authorization module 106. It should be noted that the authorization module 106 may apply one or more rules or policies to determine whether a device is genuine, duplicate, or fake.

[0045] In response to the authorization module 106 verifying that the device is original, the authorization module 106 may transmit instructions or notify the collector module that the device is original. The collector module 104 may then either request payment for the device or process payment for the device. In response to the collector module 104 processing the payment for the device, the authorization module 106 or the identity registration system 102 may assign an authorization status 116 to the device identifier of the device and assign the device identifier to the whitelist maintained in the CIR database 108. The authorization status 116 may be a tag, one or more bits, or any other indicator that can be used by the authorization module 106 or the identity registration system 102 to indicate that the device is authentic and original. In some embodiments, the identity registration system 102 may transmit to the first entity one or more instructions indicating that the device identifier of the first device is authorized. The authorization module 106 may not assign the authorization status 116 to devices that are either fake or duplicate.

[0046] In response to the authorization module 106 verifying that the device is duplicate, the authorization module 106 may transmit instructions or notify the collector module that the device is duplicate. In response to the authorization module 106 verifying that the device is duplicate, the authorization module 106 or the identity registration system 102 may assign the device identifier of the duplicate device to either a graylist or a blacklist maintained in the CIR database 108. In some embodiments, depending on policies established by the entity managing the identity registration system 102, the device identifier of the duplicate device may be assigned to the whitelist for a predetermined duration.

[0047] In response to the authorization module 106 verifying that the device is fake, the authorization module 106 may transmit instructions or notify the collector module 104 that the device is fake. In response to the authorization module 106 verifying that the device is fake, the authorization module 106 or the identity registration system 102 may assign the device identifier of the duplicating device to either a gray list or a black list maintained in the CIR database 108.

[0048] Devices that are fake or duplicate may be identified and processed in accordance with jurisdictional specifications. In some embodiments, the authorization module 106 or the identity registration system 102 may assign the device to a graylist or a blacklist depending on the length of time the device lacked the authorization status 116 (i.e., the device is duplicate or fake). For example, a duplicate or fake device may be authorized to access networks 15 for a predetermined amount of time before the device is permanently blocked from accessing the networks and flagged as an illegal device.

[0049] In situations where the authorization module 106 determines that a device identifier is original, the authorization module 106 may transmit the authorization status 116 of the device identifier to the collector module 104. The collector module 104 may receive the authorization status 116. The collector module 104 may transmit a response to the authorization module 106 with the collection status 118 of the device. In some implementations, the collector module 104 generates the collection status 118 to comply with regulations when the device identifier is identified as original.

[0050] In response to the collector module 104 receiving the payment for a device identifier or for a list of device identifiers, the collector module 104 may generate an event record. The event record may correspond to a transaction event indicating the payment for the device identifier. The event record may include the device identifier, a tax and duty payment amount related to the device identifier, and a first event identifier identifying the transaction event. The first event identifier may be a reference, such as the transaction number or identifier, of the payment. The collector module 104 may store the relevant tax and duty amount paid for the device identifier.

In some embodiments where the importer or distributor has made payment for the device identifiers through a separate payment system, the identity registration system 102 may receive an event record of the transaction sent by the importer or distributor via the user interface. In some embodiments, the identity registration system 102 may generate the transaction event record using data received from the first entity via the user interface.

[0051] In some embodiments, the collector module 104 may detect a fraudulent or incorrect transaction. In such situations, the collector module 104 may report the device identifier corresponding to the fraudulent or incorrect transaction. For example, the collector module 104 may clear the collection status 118 for a particular device identifier. The collector module 104 may compare the relevant amount of taxes and duties paid for the device with the expected amount of taxes and duties for the device. The collector module 104 may clear the collection status 118 for a particular device identifier in response to determining that the amount paid does not match the expected amount of taxes and duties for the device. The collector module 104 may transmit the device identifier, the relevant amount of taxes and duties paid, and the transaction reference numbers to the authorization module 106.

[0052] In response to the collector module 104 and the authorization module 106 verifying the device identifier and any payments associated with the device identifier, the authorization module 106 or the identity registration system 102 may store the data relating to the device identifier in the CIR database 108. The CIR database 108 may communicate with the authorization module 106 and the collector module 104. Both the authorization status 116 and the collection status 118 may be transmitted to the CIR database 108 through the CIR database data link 120. The CIR database 108 may receive the authorization status 116 and the collection status 118 from the authorization module 106 and the collector module 104. The CIR database 108 may receive the data from the authorization module 106 and the collector module 104 through the data link 120 of the CIR database. The data linked to the device identifier in the CIR database may include the device identifier, the authorization status 116 of the device identifier, and the collection status 118 of the device identifier. In some embodiments, the identity registration system 102 may store for each device identifier included in the list of device identifiers provided by the importer or distributor a corresponding entry in the CIR database. The input may include the device identifier, the amount of taxes paid, the corresponding event identifier, a specification of the device, and the authorization status indicating that the device is authorized. In some embodiments, for each device, the CIR database 108 may store the device identifier, the relevant amount of taxes and duties paid, and the transaction reference numbers generated by the collector module 104. In some embodiments, for each device, the identity registration system 102 may store, in the CIR database 108, an indication that the device is original, duplicate, or fake, device specification data, and an indication whether the device's taxes and duties have been paid.

[0053] The identity registration system 102 may assign each device identifier stored in the CIR database 108 to at least one of the plurality of groups. The identity registration system 102 may assign the device identifiers based on whether the device is original, duplicate, or fake, and whether the taxes for those devices have been paid. The first group of the plurality of groups may be a group of device identifiers defined on the white list. Each device identifier in the first group may be permanently authorized to access one or more networks through one or more mobile network operators. The second group may be a gray list and include device identifiers that are temporarily authorized to access the network(s). The device identifiers in the gray list may be authorized to access a network for a certain period. The third group can be a blacklist and include device identifiers that are permanently blocked from accessing the network(s).

[0054] As shown in FIGS. 1A and 1B, the identity registration system 102 may communicate with a local identification system 110 of each of the mobile network operators 115.

The local identification system 110 may be installed on the mobile network operator 115. The local identification system 110 may include the L1R database 112 and the identification system module 114. The local identification system 110 may provide networking services to the devices. In response to determining that a device is accessing the network of a mobile network operator 115 linked to the local identification system 110, the local identification system 110 may determine whether the device may register with the mobile network operator to maintain access to the network.

[0055] Each local identification system 110 may be configured to receive information relating to one or more device identifiers from the identity registration system 102. The LIR database 112 and the CIR database 108 may communicate through the LIR database queries - CIR databases 122a-122n (generally referred to as the LIR database queries - CIR databases 122). The LIR database queries - CIR databases

122 is configured to share data via a communication channel. The communication channel may be a connected AP!, direct database replication between the CIR database 108 and the LIR database 112, or a data stream between the CIR database 108 and the LIR database 112. In some embodiments, the LIR database query - CIR databases 122 may communicate across two or more 1 Gigabyte switches for redundant port connectivity. A switch may be a 1 Gigabyte switch, a 2

Gigabyte or any other switch capable of transferring data between the CIR database 108 and the LIR database 112. The identity registration system 102 may transmit the device-related data from the CIR database 108 to the LIR database 112 through the LIR database query - CIR databases 122. In some embodiments, the CIR database 108 and the LIR database 112 may be configured to exchange information periodically or may maintain a direct real-time connection so that any changes in the CIR database 108 may be shared with one or more LIR databases and vice versa.

[0056] In some embodiments, the CIR database 108 of the identity registration system 102 and each LIR database 112 may be configured to store device-related information such that the LIR database 112 may maintain at least a portion of the information maintained in the CIR database 108. In some embodiments, the portion of the information may include data relating to device identifiers related to the mobile network operator 115 associated with a particular LIR database 112. In some embodiments, the LIR database 112 may be configured to maintain all of the information maintained in the CIR database 108. Each LIR may maintain a list of device identifiers and assign each device identifier to a whitelist, graylist, or blacklist. The list to which each device identifier is assigned is determined from the CIR 108 database.

[0057] In some embodiments, the identity registration system 102 may parse the device identifier 208 against the LIR database 112. For example, the device registration system 102 may receive, from the first system, data corresponding to a second device identifier of a second device, the data corresponding to the second identifier being stored in the second set of databases. The first set of databases may be the CIR database 108, and the second set of databases may be the LIR database 112.

[0058] As described above, the device detection and registration system 100 may receive device identifiers from importers or distributors through the identity registration system 102 to register devices corresponding to the device identifiers with the identity registration system 102. The device detection and registration system 100, however, may also receive device identifiers from devices that connect to one or more networks of the mobile network operators 115. Such devices may not be registered at the time the devices are imported or sold. Therefore, the device detection and registration system 100 is configured to register such devices when it detects that such devices are accessing the network(s).

[0059] A device may access a mobile network operator's network 115 that is associated with a local identification system 110 in communication with the identity registration system 102. In response to the device accessing the network, the device may be discovered by the local identification system 110 of the mobile network operator 115. For example, a device not registered with the collector module 104 of the identity registration system 102 will be discovered by the local identification system 110 when the device attempts to connect to the mobile network operator's network. In some implementations, the local identification system 110 may detect the device when the device connects to the mobile network operator's network 115.

[0060] The identification system module 114 of the local identification system 110 may receive a request to verify a device identifier of the device. In response to the device 20 connecting to the network, the request may be forwarded over the network to the local identification system 110 of the mobile network operator 115. The identification system module 114 may search the LIR database 112 for the device identifier. The identification system module 114 may search the LIR database 112 for the device identifier and determine that the device identifier is assigned to a whitelist, a graylist, or a blacklist. As described above, the LIR database 112 is communicatively coupled to the CIR database 108 and receives the assignment of device identifiers from the CIR database 108. In some embodiments, if the device identifier is not included in the LIR database 112, the identification system module 114 may be configured to assign the device identifier to a whitelist, or a graylist, or a blacklist. In some embodiments, the identification system module 114 may be configured to determine which list to assign the device identifier to based on one or more policies. In some embodiments, the policy(ies) may be provided to the identification system module 114 by the identity registration system 102. Thus, instead of the identification system module 114 sending a request to the identity registration system 102 to determine which list to assign the device identifier to, the identification system module 114 may determine based on one or more policies. Depending on which list the device identifier is assigned to, the local identification system 110 will manage the device's ability to access the network 115. Upon assigning the device identifier to a particular list, the LIR database 112 may communicate the assignment to the CIR database 108 so that the CIR database 108 also includes the device in the appropriate list. The CIR database 108 may then share the update of the suitable list with one or more LIR databases 112 following the update of the CIR database 108. FIGS. 2A-2C provide further details about the assignment of device identifiers in the CIR database 108 or the LIR database 112.

[0061] Additionally, in case the device identifier is not included in the LIR database 112 or the CIR database 108, the local identification system 110 may process the device identifier and update the LIR database 112 with the device detected by the local identification system. The data stored in the LIR database 112 may then be shared or communicated with the CIR database 108, so that the CIR database is also updated to include the device identifier processed by the local identification system 110. The data transmitted from the LIR database 112 to the CIR database 108 may include details regarding the device identifier, including one or more secondary device identifiers, for example, a SIM card number or a telephone number in addition to the device specification information. The identity registration system 102 may analyze the data relating to the device identifier and include the device identifier in the CIR database 108 using the data received from the LIR database 112 to determine whether any other restrictions or permissions may be assigned to the device identifier. It may also determine the assignment of the device identifier to a list other than the white, gray, or black lists, based on additional data received by the identity registration system 102.

[0062] Due to the systems and methods described herein, the present disclosure describes systems capable of enforcing compliance with the regulations of a jurisdiction and ensuring the collection of payments incurred on all devices entering the country. The system can process payments for all devices that enter the country, either through importation or for personal use. The system can authorize devices based on an authorization process and classify them based on data obtained by the system. The device validation data can be distributed to mobile network operators. Using the device data, the mobile network operators can then ensure that the mobile devices comply with the rules and regulations of the jurisdiction.

[0063] Referring now to FIGs. 2A-2C, FIG. 2A illustrates an implementation comprising the LIR database 12, the local identification system 110, an identification system module 114, a mobile network operator 115, a device 200, a network 204, and an equipment identity register 206 installed on the mobile network operator 115. In some embodiments, the equipment identity register 206 may be installed by a third party entity unrelated to the entity managing the identity registration system 102. FIG. 2B illustrates a packet flow corresponding to the implementation shown in FIG. 2A of the device detection and registration system 100 with an equipment identity register 206 installed on the mobile network operator 115. The equipment identity register 206 may include information about the device identifier indicating whether the device identifier corresponds to a stolen, fake, or genuine device. The equipment identity register 206 may maintain a separate group of lists comprising the device identifiers. The group of lists may include the white list, the gray list, or the black list.

[0064] As shown in FIGS. 2A and 2B, the local identification system 110 is communicatively coupled to both the equipment identity register 206 and the identity registration system 102. In such implementations, upon connection of a device to the network 110, the network generates a device verification request 210 that is transmitted to the local identification system 110. To determine the assigned list of device identifier 208, the identification system module 114 may submit an equipment identity register query 212 to the equipment identity register 206, and a separate database query 216 to the LIR database 112. The equipment identity register query 212 and the database query 216 may include the device identifier 208. The equipment identity register 206 may look up the identifier of device 208 and may respond to the equipment identity register query 212 with an equipment identity register response 214. The equipment identity register response 214 may indicate that the device identifier 208 is on the whitelist, graylist, blacklist, or unknown list as managed by the equipment identity register 206. Similarly, the identification system module 114 may look up the device identifier 208 in the LIR database 112 and receive a database response 218 to the database query 216. The LIR database 112 stores the list assignments of the device identifier 208. For example, the identity registration system 102 may receive, from the first system, data corresponding to the second device identifier of a second device, the data corresponding to the second identifier device being stored in the second set of databases. The first set of databases may be the CIR database 108, and the second set of databases may be the LIR database 112. The LIR database 112 may transmit the data associated with the plurality of device identifiers to the CIR database 108 through the LIR database query - CIR databases 122. The database response 218 may indicate that the device identifier 208 is on the whitelist, graylist, blacklist, or unknown list as managed by the LIR database 112 and the CIR database 108. Similarly, the identity registration system 102 may look up the device identifier 208 and may respond to the database query 2016 with a database response 218. The database response 218 may indicate that the device identifier 208 is whitelisted, greylisted, blacklisted or unknown listed as managed by the CIR 108 database.

[0065] In some embodiments, the LIR database 112 may be configured to provide a database response 218 in response to either a database query 216 or any other query transmitted from the identification system module 114. Although the database response 218 was generated based on the device connected to the network, the response 218 may be generated in response to a query generated because the mobile number associated with the device has been changed or a device identifier associated with the network 204 has been changed.

[0066] To determine a device state 220 based on a device identity register response 214 and a database response 218, the local identification module 114 may compare the device identity register response 214 to the database response 218. If the device identity register response 214 and the database response 218 are identical, then the local identification module 114 may assign a device state 220 based on either response in accordance with the priority policy. The local identification module 114 may then transmit the device state 220 to the network 204.

[0067] The priority policy may include one or more rules by which the correct device state is determined. In fact, if there is a difference between the device identity register response 214 and the database response 218, the identification system module 114 may prioritize the device identity register response 214 over the database response 218 based on the priority policy. For example, if the device identity register response 214 indicates that the device identifier is graylisted and the database response 218 indicates that the device identifier is whitelisted, the identification system module 114 may determine that the device state 220 of the device identifier 208 is graylisted, i.e., the device should be treated as if it were graylisted.

[0068] In some embodiments, the identification system module 114 may prioritize the database response 218 over the device identity registry response 214 based on the priority policy. For example, if the device identity registry response 214 indicates that the device identifier is graylisted and the database response 218 indicates that the device identifier is whitelisted, the identification system module 114 may determine that the device status 220 of the device identifier 208 is whitelisted, i.e., the device should be treated as if it were whitelisted.

[0069] In some embodiments, the priority policy may include rules for prioritizing a blacklist over a graylist, and a graylist over a whitelist. For example, if the equipment identity registry response 214 indicates that the device identifier is graylisted and the database response 218 indicates that the device identifier is whitelisted, the identification system module 114 may determine that the device state 220 of the device identifier 208 is graylisted, i.e., the device should be treated as if it were graylisted.

[0070] The priority policy may be defined by the identity registration system 102, an operator, an authorization agency, an authorization entity, or a payment agency. In some embodiments, the priority policy may be stored on each local information system 110 for use by the respective identification system module I 14 and may be provided by the identity registration system 102.

[0071] Referring to FIG. 2C, and as a brief overview, there is shown an implementation of the device detection and registration system 100 without the equipment identity register 206 shown in FIGs. 2A and 2B. The implementation includes the CIR database 108, the mobile network operator 115 including the local identification system 110, a device 200, a network 204, and an identification system module 114. Unlike the implementations described in FIGs. 2A and 2B, in this implementation, the identification system module 114 transmits a database query 216 to the LIR database 112 and determines the device state 220 based on the database response 218 without relying on the information maintained in the equipment identity register 206 shown in FIGs. 2A and 2B. The identification system module 114 can then transmit the device status 220 to the network 204, and the local identification system 110 can transmit a notification 224 based on the device status

220 to device 200. Device state 220 may include the list designation, such as whitelist, graylist, blacklist, or unknown, of device identifier 208.

[0072] The device detection and registration system 100 may be configured for a two-phase implementation. The first phase may correspond to an observation period during which the device detection and registration system 100 monitors network activity across multiple mobile network operator networks, and implements some network restrictions on devices accessing the network(s), without waiting for data collection to end during the observation period. The second phase may correspond to an enforcement period during which the device detection and registration system 100 continues monitoring network activity across multiple mobile network operator networks, and implements further restrictions, based on data collected during the observation period and the enforcement period, on the devices. A device identifier 208 may be assigned to the various network restrictions during the observation period and the enforcement period. The duration of the observation period may be defined by the authorizing entity for the registration of each device 200 within a jurisdiction. The observation period may last one or more months. Once the observation period is completed, the enforcement period may begin and may last until the authorizing entity decides to terminate the services provided by the device detection and registration system 100. Thus, during the observation and enforcement periods, when the device 200 connects to the network 204, the identification system module 114 receives a device verification request 210 from the network 204.

[0073] The identity registration system 102 collects data associated with each device 200 connected to each mobile network operator 115 during the observation period. The data obtained during the observation period may supplement existing data, such as data obtained from the collector module 104. The observation period is used to collect data on each device 200 connected to each network 204. During the observation period, the identity registration system 102 detects and registers devices via each network 204. However, the system may be configured to block or limit devices determined not to be in compliance with one or more policies during the observation period, without waiting for the data collection to complete during the observation period. Data may be collected from each network 204 by the identity registration system 102 through the local identification system. The length of the observation period and the restrictions and blocks during the observation period may be determined by the authorizing entity for the registration of each device 200 within a jurisdiction. The observation period may last one or more months.

[0074] During the observation period, the identity registration system 102 may, from each LIR database 112 of the respective local identity systems 110 of the mobile network operators 115, collect data on each device identifier 208 based on an observation policy. The observation policy may comprise a set of rules that may determine whether and how data may be collected from the device identifier 208. The observation policy may be based on GSMA standards or regulatory standards. If data may be collected from the device identifier 208 and the device identifier 208 is compatible with the network 204, then the identity registration system 102 assigns the device identifier 208 to a whitelist. During the observation period, each identification system module 114 will populate and record each device identifier 208 that is connected to the corresponding network 204. Each respective identification system module 114 may also receive a history of each device identifier 208 that has connected to the corresponding network 204 over a period of time. The period of time may be several months or several years. The identification system module 114 may access data related to the device identifier 208 via the network 204. Importers may provide a list of each device identifier 208 for each device 200 imported into an area or country before the start of the observation period.

[0075] During the observation period, the identification system module 114 analyzes each device identifier 208 by submitting a database query 216. The identification system module 114 may submit the database query 216 in response to receiving a device verification request 210. In some embodiments, the device verification request 210 is received when the device 200 connects to a network 204, changes its mobile number, or changes its identifier with the network 204. Following the submission of a database query 216, the identification system module 114 determines a database response 218 indicating that the device identifier 208 is on a particular list based on the observation policy and data collected on that device identifier 208. This is similar to the process described in FIGs. 2A2C.

[0076] During the observation period, the identity registration system 102 or the local identification system 110 of the corresponding network to which the device connects may assign the device identifier 208 to the white list if the device identifier 208 has an authorization state 116 and a collection state 118. The identity registration system 102 or the local identification system 110 may assign the device identifier 208 to the white list if the device identifier 208 does not have an authorization state 116. The identity registration system 102 or the local identification system 110 may also assign the device identifier 208 to the white list if the device identifier 208 is duplicate but not currently connected to any network 204. In some embodiments, the registration system identity system 102 or the local identification system 110 may assign the device identifier 208 to the blacklist if the device identifier 208 does not have an authorization status 116, is duplicated and currently connected to one of the networks 204. For example, a first combination including the device identifier 208 linked to a first MSISDN may be assigned to the whitelist, but a second combination of the device identifier 208 linked to a second MSISDN will be assigned to the blacklist. Assigning the second combination to the blacklist may prevent the device identifier 208 linked to the second MSISDN from accessing the network 204.

[0077] The identity registration system 102 or the local identification system 110 may assign the device identifier 208 to the white list if the device identifier 208 has a zero or null value and is not authentic.

[0078] The identity registration system 102 or the local identification system 110 may assign the device identifier 208 to the white list if the device identifier 208 does not have a collection status 118.

[0079] In some embodiments, the identity registration system 102 or the local identification system I 10 may assign the device identifier 208 to the gray list if the device identifier 208 does not have an authorization status I 16 and is not authentic. The identity registration system 102 or the local identification system 110 may assign the device identifier 208 to the gray list if the device identifier 208 does not have an authorization status I 16 and is duplicate.

[0080] If the device identifier 208 data is unavailable or cannot be collected, then the identity registration system 102 or the local identification system 110 matches the device identifier 208 to a secondary device identifier of the device 200. For example, the identity registration system 102 matches the International Mobile Equipment Identity (IMEI) and the International Mobile Subscriber Identity (IMSI) of the SIM card inserted in the device 200, and this new IMS1-IME1 pair will be assigned to the gray list. The secondary device identifier may allow the identity registration system 102 or the local identification system 110 to identify the device 200 if its device identifier 208 is unavailable. For example, the IMS1 allows the identity registration system 102 or the local identification system 110 to properly identify the device 200, in particular when its 1MEI is common for non-standard mobile devices, such as

00000000000000. If a device 200 has a plurality of device identifiers, each device identifier 208 may be detected and stored in the identity registration system 102. Each device identifier 208 may be stored in the identity registration system 102. The identity registration system 102 may receive the data corresponding to the plurality of device identifiers for each of the plurality of devices. The plurality of device identifiers may be received by the CIR database 108 from the L1R database 112 in response to a database query 216.

[0081] The identity registration system 102 may analyze the plurality of device identifiers. The identity registration system 102 may determine that each of the plurality of device identifiers corresponds to at least i) a duplicate device identifier, ii) a false device identifier, iii) a false statement of specifications or functions due for the third device, or iv) an indication that the transaction event identifying the third device was not processed. A duplicate device identifier is assigned to more than one device. A false device identifier may not be compatible with the network or the device. A false statement of specifications may specify invalid parameters of the device. A false statement of specifications may be caused by a false type assignment code. A false declaration of functions may be a form of invalid authorization provided to the collector module 104. An indication that the transaction event was not processed may be based on the device identifier not receiving the collection status 116.

[0082] The identity registration system 102 may analyze whether each of the plurality of device identifiers is authentic, duplicate, assigned an authorization status 116, or assigned a collection status 118. The identity registration system 102 may store, across the databases, an entry identifying the device identifier and a status indicating that the device is authorized. The identity registration system 102 may store the entry and status in the CIR database 108. The identity registration system 102 may store an indication that the device 200 is unauthorized in the CIR database 108. In some embodiments, the identity registration system 102 may store, in the CIR database 108, an entry identifying the device identifier and a status indicating that the device is unauthorized in response to determining that the device identifier matches at least one of i) the duplicate device identifier, ii) the fake device identifier, iii) the misrepresentation of device specifications, or iv) the indication that the transaction event identifying the device was not processed. The identity registration system 102 may perform the analysis through the CIR database 108, the collector module 104 and the authorization module 106, as described in FIGS. 1 A-1 C.

[0083] The device registration system 102 may assign each device 200 in a white list to a plurality of categories. The device registration system 102 will assign the device identifier 208 having an authorization status 116 to the first category. If the device identifier 208 does not have an authorization status 116 because the device identifier 208 is not authentic, the identity registration system 102 will assign the device identifier 208 to the second category. If the device identifier 208 does not have an authorization status 116 because the device identifier 208 is duplicate, the identity registration system 102 will assign the device identifier 208 to the third category. The device registration system 102 may search for each device 200 in the second category or third category of the network 204 to which the device identifier 208 is bound or connected, and may block the device identifier 208 from other networks. Each device 200 in the second category or third category may be notified by the identity registration system 102 that it is restricted to the network 204 currently in use. After the end of the observation period, an enforcement period begins, during which the device registration system 102 may assign the device identifier 208 to a list as a result of data collected during the observation period or the enforcement period.

[0084] During the enforcement period, the identity registration system 102 or the local identification system 100 may assign the device identifiers 208 to the whitelist, graylist, or blacklist maintained in the CIR database 108 and the LIR database 112. The identity registration system 102 may assign identifiers of devices registering through the authorization module and the collector module in accordance with one or more policies similar to the policies used to assign the identifiers of devices registering during the observation period. In some embodiments, some device identifiers may be assigned to the whitelist during the observation period, but during the enforcement period, device identifiers with the same authentication state or the same collection state may be assigned to the graylist or the blacklist. Similarly, during the enforcement period, the local identification system 110 may be configured to assign the device identifiers of the devices connected to their respective networks to either the white list, the gray list, or the black list if the device identifier is not found in the LIR database 112 of the local identification system 110. The device identifiers assigned to the white list, or the gray list, or the black list by the local identification system 110 may later be reassigned to a different list by the identity registration system 102 based on certain events. For example, a device identifier may be assigned to the gray list if taxes for the device have not been paid. After a certain period, the device identifier may be assigned to the black list if taxes are still unpaid after a predetermined duration. Device identifier 5 may be assigned to the whitelist when the identity registration system 102 determines that taxes for the device have been paid.

[0085] During the application period, the identity registration system 102 or a corresponding local identification system 110 analyzes each device identifier 208 and assigns it to a list. If the device identifier 208 does not have an authorization status 116, the identity registration system 102 or the corresponding local identification system 110 will assign the device identifier 208 to the gray list or the black list. In some embodiments, the identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 without authorization status 116 to the whitelist for a first device 200 and to the associated blacklist for all subsequent devices having the same device identifier 208. The identity registration system 102 or the corresponding local identification system 110 may be unable to assign a false or null device identifier 208, so a secondary device identifier linked to the device identifier 208 will be assigned to the list. The identity registration system 102 may remove the assignment to the graylist or blacklist of the device identifier 208 when the device identifier 208 receives an authorization status 116.

[0086] The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the gray list if the device 200 is fake, inauthentic, does not have an authorization state 116 and does not have a collection state 118. The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the white list if the device identifier 208 has an authorization state 116, a collection state 118 and if the device 200 has not been used on any network 204. The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the white list if the device identifier 208 has a state authorization status 116, a collection status 118, and a usage history on a network 204. The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the gray list if the device identifier 208 has an authorization status 116, does not have a collection status 118, and has a collection status request 118. The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the gray list if the device identifier 208 has an authorization status 116, does not have a collection status 118, and if the device identifier 208 is active on a network 204. The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the gray list if the device identifier 208 has an authorization status 116, does not have a collection status 118, and if the device identifier 208 is active on a network 204. 110 correspondent may assign device identifier 208 to the grey list if device identifier 208 does not have an authorization status I 16 due to a genuine but duplicate device identifier.

[0087] The identity registration system 102 or the corresponding local identification system 110 may analyze a device 200 connected to a network 204 and having a device status 220 on a white list or a gray list, and remove the authorization status 116 from the device identifier 208 after determining that the device identifier 208 is duplicated. The identity registration system 102 or the corresponding local identification system 110 may then assign the device identifier 208 to the gray list or the black list.

[0088] The identity registration system 102 or the corresponding local identification system 110 may analyze a device 200 connected to a network 204 and having a device status 220 indicating that the device identifier 208 is on a white list or a gray list, and remove the authorization status 15 116 from the device identifier 208 after determining that the device identifier 208 is false. The identity registration system 102 or the corresponding local identification system 110 may assign the device identifier 208 to the gray list or the black list.

[0089] The identity registration system 102 or the corresponding local identification system 110 may analyze a device 200 that attempts to connect to the network 204, and in response to the device identifier 208 not having an authorization status 116 because the device identifier 208 is false, assign the device identifier 208 to the gray list or the black list.

[0090] The identity registration system 102 may analyze a device identifier 208 that was assigned to the whitelist or graylist during the observation period. In response to determining that the device identifier 208 is duplicate, the identity registration system 102 may remove the authorization status 116 from the device identifier 208. The identity registration system 102 may then assign the device identifier 208 to the graylist.

[0091] In some implementations, during the application period, the identity _registration system 102 or the corresponding local identification system 110 may analyze a device 200 that attempts to connect to a network 204 and may determine that the device identifier 208 does not have an authorization status 116 because the device identifier 208 is duplicate. The identity registration system 102 or the corresponding local identification system 110 may then assign the device identifier 208 to the gray list.

[0092] By analyzing the device identifier 208 at different times, the identity registration system 102 may change or assign the device identifier 208 according to a time-based policy. For example, the identity registration system 102 may identify a first time corresponding to an event where the device accesses the network 204 of the mobile network operator 115. The identity registration system 102 may then assign the device identifier 208 to the gray list when the device identifier 208 has an authorization state 116 but does not have a collection state 118 at the first time. The identity registration system 102 may then assign the device identifier 208 to the black list in response to determining that a predetermined amount of time has elapsed since the first time.

[0093] The predetermined duration is based on a policy. The policy may be generated by an operator, an authorization agency, an authorization entity or a payment agency, among others. In some embodiments, the policy may be generated by an entity managing the CIR database. In some embodiments, the policy may be generated by the ministry of finance, telecommunications, or any other organization authorized by the government to establish a policy according to which devices are allowed to access the network. In some embodiments, the policy may be generated by a regulator, an importer, or a government agency. The identity registration system may transmit data indicating a time period during which the device 200 will be assigned to the gray list before the device identifier 208 is assigned to the black list unless the device identifier 208 of the device 200 obtains a collection status 108 or an authorization status 116. As described above, the device identifier 208 of the device 200 may obtain the collection status 118 after payment of taxes or by complying with the regulations of the authorizing entity. The device identifier 208 of the device 200 may obtain the authorization status 116 in response to payment at a distributor, network provider, or other entity responsible for collecting payments. The identity registration system may transmit data indicating the period of time available to the device 200 to obtain the collection status 118 or the authorization status 116. In some implementations, the period available to the device 200 to obtain the collection status 118 or the authorization status 116 may be 90 days. In some implementations, the period available to the device 200 to obtain the collection status 118 may be 1 day, 2 days, 3 days, 4 days, 5 days, 6 days, 7 days, 10 days, days, 20 days, 30 days, 45 days, 60 days, 75 days, 90 days, 120 days, 150 days, 180 days, or even 365 days or more.

[0094] However, it should be noted that this period may be set based on policy and may vary from 1 hour to 1 year or more. The identity registration system 102 may determine the time indicating when a reminder will be sent to obtain the collection status 118 or the authorization status 116. In some implementations, the local identification system 110 may be configured to send the reminder 30 days, 7 days, or 1 day before the device 200 is assigned to the blacklist.

[0095] The identity registration system 102 may detect cloned or duplicate devices by analyzing secondary device identifiers. For example, secondary device identifiers may be phone numbers associated with the device, SIM card numbers, an International Mobile Subscriber Identity (IMSI), or a Mobile Subscriber Multi-Service Digital Network (MSISDN) number, among others. Cloned devices are devices having at least one device identifier, such as the device's IME1 number, that matches the 1MEI number of another device. To detect a cloned device, the identity registration system 102 may determine that two devices with the same IM1 number are connected to one or more networks at the same time. In particular, the identity registration system 102 may determine that a second device identifier of a second device matches a first device identifier of a first device. Since two devices are linked to the same device identifier, the identity registration system 102 may compare the secondary device identifiers of the two devices having the same device identifier. The identity registration system 102 may determine that a third device identifier of a different type of the second device does not match a device identifier of the first device. The identity registration system 102 may determine that a single IMEI number is linked to two devices having different secondary device identifiers indicating that one of the devices with the IMEI number is cloned or duplicate. The identity registration system 102 may then assign a label indicating that one of the two devices corresponds to a cloned or duplicate device. In some embodiments, the identity registration system 102 may assign a label indicating that the second device corresponds to a cloned or duplicate device in response to determining that the second device is cloned.

[0096] If the identity registration system 102 determines that the device is cloned, the identity registration system 102 may generate a notification to be transmitted to at least one of the two devices having the cloned device identifier 208 to have the device verified. The identity registration system 102 may then assign the device to a graylist or a blacklist. In some embodiments, the device may be assigned to a graylist for a predetermined duration to give the user of the device the opportunity to verify or review the device. If the device is not verified or reviewed after a predetermined duration, the identity registration system 102 may assign the device to the blacklist, thereby preventing the device from accessing the network(s) 15.

[0097] Since the data related to the device identifier 208 may change, the identity registration system 102 may rescan the device identifier 208. The identity registration system 102 may rescan the device identifier 208 of the device 200 when the device 200 connects to a network 204, changes its mobile number, or changes its identifier with the network 204. In some implementations, the identity registration system 102 may rescan the device identifier 208 every second, minute, hour, day, week, month, or any other frequency.

[0098] The identity registration system 102 may transmit a notification 224, through the local identification system 110, to the appliance 200 based on the data related to the appliance identifier 208. In some embodiments, the local identification system 110 may be configured to transmit the notification without receiving instructions from the identity registration system 102. The notification 224 may include the appliance status 220. The appliance 220 receives and displays the notification 224.

The notification 224 may include the name of the device 200, its device identifier 208, its authorization status 116, its collection status 118, and its network usage history for each network 204. The notification 224 may include a request for the device 200 to verify the name of the device 200 and its device identifier 208. The device status 220 may include time and network data.

204 corresponding to the previous use of the device 200. The notification 224 may include a request for the device 200 to obtain a collection status 118. In some implementations, the notification 224 may alert the device 200 that the device 200 is active on a plurality of networks, and thus has a duplicate device identifier 208. The notification may include instructions for this device to obtain a different mobile number or be assigned to a blacklist for being duplicate. The notification 224 may include data explaining how the device 200 could be converted to the blacklist if it does not have an authorization status I 16 or a collection status I 18. If the identity registration system 102 determines that the device identifier 208 of the device is cloned, the notification 224 may include instructions that the device 200 linked to the device identifier 208 should be examined by a store, a network provider 30 or a mobile network operator 115.

[0099] By implementing the device detection and registration system 100, the identity registration system 102 may be configured to generate and provide information related to devices accessing the mobile network operator(s) network(s) 115. In some embodiments, the user interface 124 provided by the identity registration system 102 may receive a view and statistics on devices in the country (e.g., percentage on whitelist), collection status 118, authorization status 116, authenticity, duplicates, financial reports, and pre-authorization and authorization reports. The user interface 124 may provide a list of whitelisted devices connected to a network 204, whitelisted devices not connected to a network, devices according to their authorization status 116, duplicate devices. devices by authenticity, 10 traded devices, devices previously seen by each network and their usage history.

The user interface 124 may also provide a list of blacklisted devices, graylisted devices, collection status data 118, and imported devices organized by date, importer, device type, or device model. Devices with a collection status 118 may be grouped by collection status, importer, device type, or device model. Each device 200 with an authorization status 116 may be grouped by authenticity status, importer, device type, or device model. All reports must include the device identifiers analyzed by the identity registration system 102, as well as time-based reports of those device identifiers indicating when those devices were analyzed by the identity registration system 102.

[0100] The user interface I24 may provide time-based reports over a user-customizable period of time. The user interface I24 may create user accounts or user groups (e.g., a group administrator or a customer support group) for the user interface 124 with different access rights and various privileges. Some user accounts may change the list to which the device identifier is assigned, such as changing the list from blacklist to whitelist. Some user accounts may modify device data such as the device identifier. The user interface 124 records all user activities in log files by IP address, actions, and time.

B. PROCESS AND WORKFLOW OF A DEVICE DETECTION AND RECORDING SYSTEM IMPLEMENTATION

[0101] FIG. 3A illustrates a method for detecting and registering a device according to embodiments of the present disclosure. The method may include at least two device detection and registration processes 200. The first process, described in steps 302-316, includes detection of the device by the identity registration system 102. The second process, described in steps 318-330, relates to detection of the device 200 by a mobile network operator 115. With respect to the first process, the method 300 includes identifying a device 200 via the identity registration system 102 (step 302). The identity registration system 102 verifies the device identifier 208 (step 304). The identity registration system 102 examines the device identifier 108 for an authorization state 116 (step 306). If the device identifier 208 has an authorization state 116, then the identity registration system 102 examines the device identifier 208 for a collection state 118 (step 308). If the device identifier 208 has a collection state 118, then the identity registration system 102 assigns the device identifier 208 to a whitelist (step 310). If the device identifier 208 does not have an authorization state 116 or if the device identifier 208 does not have a collection state 118, then the identity registration system 102 assigns the device identifier to a graylist or a blacklist (step 312). The CIR database 108 stores the assignments to the whitelist, graylist, or blacklist (step 314). The identity registration system 102 transmits the CIR database 108 to the LIR database 112 (step 316). With respect to the second process, the method 300 includes linking the device 200 to the mobile network operator 115 (step 318). The local identification module 110 of the mobile network operator 115 examines the device identifier 208 (step 320). The identification system module 114 of the local identification module 110 searches for the device identifier 208 in the LIR database 112 (step 322). The identification system module 114 returns a device status 220 (step 324). If the device status 220 is a blacklist, then the mobile network operator 115 prohibits the device 220 linked to the device identifier 208 from connecting to the network 204 (step 326). If the device status 220 is a graylist, then the mobile network operator 115 temporarily allows the device identifier 208 to connect (step 328). If the device state 220 is whitelisted, then the mobile network operator 115 allows the device identifier 208 to connect to the network 204 (step 330). If the device state 220 is unknown, then the identity registration system 102 re-analyzes the device identifier 208 (step 304). If the device state 220 of the device identifier 208 indicates that the device identifier is whitelisted, graylisted, or blacklisted, then the mobile network operator re-examines the device identifier 208 for updates (step 332).

[0102] The device 200 may be detected through the identity registration system 102 (step 302). The collector module 104 may first discover the device 200. For example, the collector module 104 may receive a list of device identifiers of a client device from an importer or distributor or any other entity that is attempting to register device identifiers of imported devices. In some embodiments, a user may access a portal or user interface of the identity registration system 102 to register their device.

[0103] The identity registration system 102 examines the device identifier 208 (step 304). The identity registration system 102 may check a subscriber identity module (SIM) card number, an International Mobile Equipment Identity (IMEI), or a Mobile Subscriber Multi-Service Digital Network (MS1SDN) number. Different IMEI versions may be supported, such as 14-, 15-, and 16-digit IMEIs. The identity registration system 102 may examine the device identifier for a collection status I I 8, an authorization status I 16, and to check whether the device identifier is fake or duplicate. The identity registration system may examine the CIR database to see if the device identifier already exists in the CIR database. A device identifier may exist in the CIR database if the identity registration system 102 has previously added the device identifier to the CIR database as a result of the device identifier registering (or attempting to register) with the identity registration system. Alternatively, the device identifier may exist in the CIR database if the registration system 102 has previously added the device identifier to the CIR database as a result of a device having the device identifier connecting to one or more mobile network operator networks in communication with the identity registration system 102.

[0104] The identity registration system 102 examines the device identifier 208 for an authorization status 116 (step 306). The authorization module 106 may determine whether the device identifier 208 is authentic, not fake. A genuine device identifier is readable by a mobile network operator, generated by a legitimate manufacturer or regulatory entity, and capable of being processed by the mobile network operator. The authorization module 106 may determine whether the device identifier 208 is unique and non-duplicate. The authorization module 106 may transmit an authorization status I 16 to the collector module 104. The authorization module 106 may determine that the device identifier is unique and non-duplicate if the device identifier does not exist in the CIR database. Authorization status may mean that the device has a device identifier that has matched a device identifier included in a standards database, such as a database maintained by the GSM standards organization, and that the device identifier does not already exist in the CIR database in association with another device.

[0105] If the device identifier 208 has an authorization status 116, the identity registration system 102 may also examine to determine if the device identifier 208 has a collection status 118 (step 308). The collection status may indicate that taxes and duties for the device have been paid. For each device brought into a jurisdiction, the collector module 104 may process or collect tax and duty payments, either by importation or for personal use. The jurisdiction may be a region, a country, or a predetermined area. The collector module 104 may receive data from a device such as its device identifier. The collector module 104 may receive a single device or a batch of devices. The collector module 104 may receive data from the importer such as their authorization entity ID number, name, company name, date, device model, and device identifier. In some implementations, the collector module 104 may transmit the device identifier, the relevant amount of taxes and duties paid, and the transaction reference numbers to the authorization module 106. [0106] The identity registration system 102 may assign the device identifier 208 to a whitelist (step 310) upon determining that the device has been authorized and the taxes and duties have been paid. Devices having device identifiers included in the whitelist are permanently authorized to access the network(s) unless the device is later determined to be duplicate, fake, or non-compliant.

[0107] The identity registration system 102 assigns the device identifier 208 to a graylist or a blacklist (step 312) following a determination that the device is unauthorized and does not have the taxes and duties paid. The identity registration system 102 may use one or more policies to determine whether the device will be assigned to a graylist or a blacklist. The policies may be defined by a government entity, one or more mobile network operators, or other entities. Devices having device identifiers assigned to the graylist may temporarily be allowed to access the network(s). Devices having device identifiers assigned to the blacklist are prevented from accessing the network(s). Devices having device identifiers assigned to the graylist may be assigned to the blacklist and vice versa after a period of time defined by the policy(ies).

[0108] Still referring to FIG. 3A, the identity registration system 102 may store the device identifiers and an indication of the list (whitelist, graylist, or blacklist) to which the device identifier is assigned in the CIR database 108 (step 314). The CIR database 108 may store that the device identifier 208 is assigned to the whitelist, graylist, or blacklist.

[0109] The identity registration system 102 may transmit the data included in the CIR database 108 to the LIR database 112 (step 316). The LIR database 112 and the CIR database 108 may communicate through the LIR database queries - CIR databases 122a-122n (generally referred to as LIR database queries - CIR databases 122). The CIR database 108 may maintain separate lists for device identifiers that are classified in the white list, the gray list or the black list. The database 112 may receive lists from the CIR database 108. The data transmitted from the CIR database may be stored in the LIR database (step 322) such that the LIR database may either replicate the CIR database or include a portion of the data from the CIR database. With this architecture, devices connected to the mobile network operator's networks are able to be authorized to access the mobile network operator's network based on the data stored in the respective LIR, thereby reducing the number of requests transmitted to the CIR database of each of the mobile network operators' local identification systems.

[0110] Still referring to FIG. 3A, in case a device connects to a mobile network operator network 115, the flow may start at step 318. The device connects to a mobile network operator network 115 (step 318). For example, an undeclared device with the collector module 104 of the identity identifier system 102 may connect to the mobile network operator network 115. The identification system module 114 of the local identification system 110 may receive the device identifier. In some embodiments, the identification system module 114 of the local identification system 110 may receive the device identifier in an IMEI check function request or a device verification request 210.

[0111] The local identification system 110 of the mobile network operator 115 examines the device identifier 208 (step 320) following receipt of the device identifier of the device connected to the network. In some embodiments, the identification system module 114 may send the request to the identity registration system 102 to look up the device identifier of the device attempting to connect to the local identification system 110. The identification system module 114 may look up the device identifier in the LIR database 112. The LIR database 112 may respond to the identification system module 114 with the list on which each device identifier is located. Each device identifier may be on the white list, the gray list, the black list, or the unknown list.

[0112] The local identification system I I0 returns a device state 220 (step 324). As described with respect to FIGs. 2A-2B, the local identification system 110 may compare the equipment identity register response 2I4 to the database response 218. If the equipment identity register response 214 and the database response 218 are identical, then the local identification system 110 may transmit the device state 220 to the network 204. If there is a difference between the equipment identity register response 214 and the database response 218, the local identification system 110 may use the priority policy to choose the device state 220. As described with respect to FIG. 2C, the identification system module 114 may determine a device status 220 based on the database response 218. If the database response 218 indicates that the device identifier is on an unknown list, then the identity registration system searches the CIR database 108 for the device identifier as shown in steps 304-314.

[0113] If the device state 220 of the device identifier 208 linked to the device 200 is on the blacklist, then the mobile network operator 115 of the network 204 prohibits the device 200 linked to the device identifier 208 from accessing the network (step 326). If the device state 220 is on the graylist, then the mobile network operator 115 of the network 204 may allow the device 200 linked to the device identifier 208 to temporarily access the network 204 (step 328). If the device state 220 is on the whitelist, then the mobile network operator 115 of the network 204 may allow the device 200 linked to the device identifier 208 to connect to the network 204 (step 330).

[0114] If the device status 220 of the device identifier 208 is on the white list, gray list, or black list, the identification system module 114 of the mobile network operator 115 periodically re-analyzes the device identifier 208 based on changes that may occur in the CIR database or the LIR database (step 332). Depending on the updated information, the identity registration system 102 may change the list to which the device identifier 208 is assigned. The update may occur at a predetermined time, or at predetermined intervals, for example every hour or every day. In some implementations, the update may occur in real time. The update may occur through the query of CIR databases - LIR databases 122. In some implementations, the identity registration system 102 may re-analyze the device identifier 208 of the device 200 when the device 200 connects to a network 204, changes its mobile number, or changes its identifier with the network 204.

[0115] Referring to FIG. 3B, illustrated is a flow for device detection and registration according to embodiments of the present disclosure. A device 200 is imported into the flow 352, as shown in step 302. Next, the identity registration system 102 determines a collection status 118 of a device identifier 208 of the device 200 in the flow 354, as shown in steps 304 and 308. Next, the identity registration system 102 determines an authorization status 116 for the device identifier 208 of the device 200 in the flow 356, as shown in step 306. In the exemplary flows 354 and 356, the device identifier 208 receives both the collection status 118 and the authorization status 116, thus the identity registration system 102 assigns the device identifier 208 to the whitelist as shown in step 310. In flow 358, the CIR database 108 stores the collection status 118, the authorization status 116, and the assignment of the device identifier 208, as shown in step 314. In flow 360, the CIR database 108 transmits the assignment of the device identifier 208 to the LIR database 112 as shown in step 316. The LIR database 112 stores the assignment of the device identifier 208 of the device 200 in flow 362, as shown in step 322. In the exemplary flow 364, following the submission of the identification system module 114 of a database query 216 to look up the device identifier 208 in the LIR database 112, and then determining a database response 218 indicating that the device identifier 208 is whitelisted, the identification system module 114 may determine the device state 220 of the device identifier as whitelisted, as shown in step 324. Finally, following the determination of the device state 220 indicating that the device identifier 208 is whitelisted, the device may receive services from the network in the flow 366, as shown in step 330. Then, the device state 220 of the device identifier 208 may be re-analyzed in the flow 362 or re-assigned in the flow 364, as shown in step 332.

[0116] With reference to E1G. 4, the identity registration system 102 may represent the illustrated implementation stack. The identity registration system 102 may include the Business Intelligence layer. A user, regulator, or a controlling entity may connect to the identity registration system 102 through the Business Intelligence layer. The API layer may include the application server, REST API, and SFTP. The API layer may provide a web portal through which the user may communicate with the identity registration system 102. The portal may communicate with the identity registration system 102 through one or more APIs presented in one or more layers. The application server may include the user interface 124. The REST API may facilitate communication between the identity registration system 102 and the local identification system 110, and the modules described herein. SFTP, also known as SSH File Transfer Protocol, can establish a secure connection between the modules described herein. The system operators and other organizations layer may be the entity that manages the database 108. One or more entities may access the identity registration system 102, such as the government, ministries, distributor, or importer. The identity registration system 102 may include the logic rules and processes layer. The logic rules and processes layer may manage the device identifiers 208 and decide whether to assign them to the whitelist, blacklist, graylist, or unknown list. The identity registration system 102 may include modules designed to extract information from the components interacting with the identity registration system 102 from the devices. The device module may provide additional information about the device 200, such as the make and model. The GSM module may facilitate connection to the devices through a global system for mobile communications. The IME1 module may extract the 1ME1 data from a device 200 for the device identifier 208. The IMS! module may extract the 1MSI data from a device 200 for a device identifier 208 or a secondary device identifier. The MSISDN module may extract the MSISDN data from the device 200 for a device identifier 208, a secondary device identifier, or a third device identifier. The module may import information about the device 200, such as another device identifier, or specification information. The data processing engine may facilitate enterprise data management, for example by taking data processing pipelines, abstracting business logic, and processing the data in an optimized manner, in streaming or batch mode. on-premises or in the cloud. The CIR database 108 may store and record all activities performed in the implementation stack.

[0117] Referring now to FIG. 5A, illustrated is a Type Assignment Code (TAC) stream of the device analyzed by the device detection and registration system 100. A device 200 may include a TAC. The TAC is the initial 8-digit portion of the 15-digit IMEJ and 16-digit 1ME1SV codes used to uniquely identify wireless devices. In 502, the device 200 maps detailed device data based on the TAC. 504 illustrates the data obtained from the TAC. The TAC may be imported by the identity registration system 102. The TAC may be analyzed by a MIRS Bl analytical tool. The Type Assignment Code identifies a particular model (and often a revision) of wireless phone for use on a GSM, UMTS, or other wireless network employing 1ME1. The first two digits of the TAC form the Certification Authority Identifier. This indicates the GSMA-approved group that assigned the TAC. Both the old and new TACs uniquely identify a phone model, although some models may have more than one code, depending on the revision, manufacturing location, and other factors. At 506, the identity registration system 102 obtains and analyzes the device's TAC. The identity registration system 102 can analyze more than 100 data points associated with the 1 AC.

[0118] With reference to FIG. 5B, illustrated is the data extracted from the TAC of the device 200 for analysis by the device detection and registration system 100. The device map illustrates the information obtained from the device 200. The device map may include specifications and data related to the device such as model name, model number, model type, dimensions, weight, operating system, SIM, network, technology, main screen size, main screen resolution, central processing unit (CPU) cores, graphics processing unit (GPU) cores, random access memory (RAM) size, read-only memory size, solid state device (SSD), embedded multimedia controller (eMMC), Subscriber Identity Module (SIM) card size, adaptive network topology plus (ANT+), universal serial bus (USB) version, location technology, and mobile backhaul high definition (MHL).

C. COMPUTER SYSTEMS

[0119] Various operations described herein may be implemented on computer systems, which may have a generally conventional design. FIG. 6 illustrates a simplified block diagram of a representative server system 600 and client computer system 614 used to implement certain embodiments of the present disclosure. In various embodiments, server system 600 or similar servers may implement services or servers described herein. Device detection and registration system 100 and other systems described herein may be similar to server system 600.

[0120] The server system 600 may have a modular design comprising multiple modules 602 (e.g., blades in a blade server embodiment); while two modules 602 are illustrated, any number may be provided. Each module 602 may include one or more processors 604 and local storage 606.

[0121] One or more processors 604 may include a single processor, which may have one or more cores, or multiple processors. In some embodiments, one or more processors 604 may include a general-purpose primary processor, as well as one or more special-purpose coprocessors such as graphics processors, digital signal processors, or the like. In some embodiments, some or all of the processing units 604 may be implemented using custom circuitry, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuitry itself. In other embodiments, one or more processors 604 may execute instructions stored in local storage 606. Any type of processors in any combination may be included in one or more processors 604.

[0122] The local storage 606 may include volatile storage media (e.g., conventional DRAM, SRAM, SDRAM, or the like) and/or non-volatile storage media (e.g., magnetic or optical disk, flash memory, or the like). The storage media incorporated in the local storage 606 may be fixed, removable, or upgradeable at will. The local storage 606 may be physically or logically divided into several subunits such as system memory, read-only memory (ROM), and permanent memory. The system memory may be write-read memory or volatile write-read memory, such as dynamic random access memory. The system memory may store some or all of the instructions and data needed by one or more processors 604 at runtime. The ROM may store static data and instructions required by one or more processors 604. The permanent memory may be non-volatile read-write memory that can store instructions and data even when the module 602 is powered off. The term "storage medium" as used herein includes any medium where data can be stored indefinitely (subject to overwriting, electrical disturbance, loss of power, or otherwise) and does not include carrier waves and transient electronic signals propagating wirelessly or through wired connections.

[0123] In some embodiments, the local storage 606 may store one or more software programs to be executed by one or more processors 604, such as an operating system and/or programs implementing various server functions such as the functions of the device detection and registration system 100 of FIG. 1A or any other system described herein, or any other servers or systems associated with the device detection and registration system 100 of FIG. 1A.

[0124] “Software” generally refers to sequences of instructions that, when executed by one or more processors 604, cause the server system 600 (or portions thereof) to perform various operations, thereby defining one or more specific machine embodiments that execute and perform the operations of the software programs. The instructions may be stored as firmware residing in read-only memory and/or program code stored in a non-volatile storage medium that can be read into volatile working memory for execution by one or more processors 604. The software may be implemented as a single program or a collection of separate programs or program modules that interact at will. From the local storage 606 (or non-local storage described below), one or more processors 604 may retrieve program instructions to be executed and data to be processed in order to perform the various operations described above.

[0125] In some server systems 600, multiple modules 602 may be interconnected through a bus or other interconnect 608, forming a local area network that supports communication between the modules 602 and other components of the server system 600. The interconnect 608 may be implemented using multiple technologies, including server racks, hubs, routers, etc.

[0126] A wide area network (WAN) interface 610 may provide data communication capability between the local area network (interconnect 608) and a wider network, such as the Internet. Conventional or other business technologies may be used, including wired technologies (e.g., Ethernet, IEEE 802.3 standards) and/or wireless technologies (e.g., WI-FI, IEEE 802.11 standards).

[0127] In some embodiments, the local storage 606 is intended to provide working memory for one or more processors 604, providing rapid access to programs and/or data to be processed while reducing traffic on the interconnect 608. Storage of larger amounts of data may be provided over the local network by one or more mass storage subsystems ϋ12 that may connect to the interconnect 608. The mass storage subsystems 6I2 may be based on magnetic, optical, semiconductor, or other storage media. Direct-attached storage, storage networks, network-attached storage, and the like may be used. Any data store or other collection of data described herein as being produced, consumed, or maintained by a service or server may be stored in the mass storage subsystems 612. In some embodiments, additional data storage resources may be accessible through the WAN interface 610 (potentially with increased latency).

[0128] The server system 600 may operate in response to requests received via the WAN interface 610. For example, one of the modules 602 may implement a supervisory function and assign discrete tasks to other modules 602 in response to the received requests. Conventional work allocation techniques may be used. In processing the requests, the results may be returned to the requestor via the WAN interface 610. Such operation may be generally automated. Further, in some embodiments, the WAN interface 610 may connect multiple server systems 600 to each other, providing scalable systems capable of handling high volumes of activity. Conventional or other techniques for managing server systems and server farms (collection of cooperating server systems) may be used, including dynamic allocation and reallocation of resources.

[0129] The server system 600 may interact with multiple user-owned or user-managed devices across a wide area network such as the Internet. An example of a user-managed device is illustrated in FIG. 11 as a client computing system 614. The client computing system 614 may be implemented, for example, as a client device such as a smartphone, other mobile phone, tablet, wearable computing device (e.g., smart watch, glasses), desktop computer, laptop, and so on.

[0130] For example, the client computing system 614 may communicate through the WAN interface 610. The client computing system 614 may include conventional computing components such as one or more processors 616, storage device 618, network interface 620, user input device 622, user output device 624. The client computing system 614 may be a computing device implemented in several form factors, such as a desktop computer, a laptop computer, a tablet, a smartphone or other mobile computing device, a portable computing device, or others.

[0131] The processor 6I6 and storage apparatus 6I8 may be similar to one or more processors 604 and local storage 606 described above. Suitable apparatuses may be selected depending on the demands placed on the client computing systems 614; for example, the client computing system may be implemented as a "thin" client with limited processing capacity or as a high-power computing device. The client computing system 614 may be provisioned with program code executable by one or more processors 616 to enable various interactions with the server system 600 of a message management service, such as accessing messages, performing actions on the messages, and other interactions described above.

Some client computer systems 614 may also interact with a messaging service independently of the message management service.

[0132] The network interface 626 may provide a connection to a wide area network (e.g., the Internet), to which the WAN interface 6I0 of the server system 600 is also connected. In several embodiments, the network interface 620 may include a wired interface (e.g., Ethernet) and/or a wireless interface implementing various RF data communication standards such as Wi-Fi, Bluetooth, or cellular data network standards (e.g., 3G, 4G, LTE, etc.).

[0133] The user input device 622 may include any device (or devices) from which a user can send signals to a client computer system 6I4; the client computer system 6I4 may interpret the signals as indicating particular user requests or data. In various embodiments, the user input device 622 may include part of or all of a keyboard, touchpad, touchscreen, mouse, or other pointing device, scroll wheel, click wheel, thumbwheel, button, switch, keypad, microphone, and so on.

[0134] The user output apparatus 624 may include any apparatus from which a client computing system 6I4 can provide data to the user. For example, the user output apparatus 624 may include a display for displaying various image generating technologies, e.g., a liquid crystal display (LCD), a light emitting diode (LED), including organic light emitting diodes (OLED), a projection system, a cathode ray tube (CRT), or the like, as well as supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors, or the like). Some embodiments may include an apparatus such as a touchscreen that functions as both an input and output apparatus. In some embodiments, other user output apparatus 624 may be provided in addition to or instead of a display. Examples include indicator lights, speakers, touch-sensitive "display" devices, printers, and so on.

[0135] Some embodiments include electronic components such as microprocessors, storage, and memory that store computer program instructions in a computer-readable storage medium. Several features described in this specification may be implemented as processes defined as a set of program instructions encoded on a computer-readable storage medium. When these program instructions are executed by one or more processing units, they cause the one or more processors to perform various operations indicated in the program instructions. Examples of program instructions or computer code include machine code, as produced by a compiler, and files comprising higher-level code that are executed by a computer, electronic component, or microprocessor using an interpreter. With appropriate programming, one or more processors 604 and 616 may provide various features to the server system 600 and the client computing system 614, including any features described herein as being performed by a server, or client, or other features related to message handling services.

[0136] It should be noted that the server system 600 and the client computing system 614 are illustrative and that variations and modifications are possible. The computing systems used in connection with embodiments of the present disclosure may have other capabilities not specifically described herein. Furthermore, while the server system 600 and the client computing system 614 are described with reference to particular blocks, it should be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of components. For example, different blocks may exist without necessarily being located in the same installation, in the same server rack, or on the same motherboard. Furthermore, the blocks may not correspond to physically distinct components. The blocks may be configured to perform various operations, for example, by programming a processor or providing appropriate control circuitry, and several blocks may or may not be reconfigurable depending on the manner of initial configuration. Embodiments of the present disclosure may be embodied in a variety of devices including electronic devices implemented using a combination of circuitry and software.

[0137] Although the disclosure describes specific embodiments, those skilled in the art will recognize that many modifications are possible. For example, although specific examples of rules (including triggering conditions and/or resulting actions) and suggested rule generation processes are described, other rules and processes may be implemented. Embodiments of the disclosure may be made using a variety of computer systems and communication technologies including but not limited to specific examples described herein.

[0138] Embodiments of the present disclosure may be implemented using any combination of dedicated components and/or programmable processors and/or programmable devices. The various processes described herein may be implemented on the same processor or different processors in any combination. Where components are described as being configured to perform certain operations, such configuration may be accomplished, for example, by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Furthermore, although the embodiments described above may refer to specific hardware and software components, those skilled in the art will recognize that different combinations of hardware and/or software components may also be used, and that particular operations described as implemented in hardware may also be implemented in software or vice versa.

[0139] Computer programs incorporating various features of the present disclosure may be encoded and stored on various computer-readable storage media; suitable media include a magnetic disk or tape, an optical storage medium such as a compact disc (CD) or a DVD (digital versatile disc), flash memory, and other non-transitory media. The computer-readable media encoded with the program code may be packaged with a compatible electronic device, or the program code may be provided separately from the electronic devices (e.g., through downloading from the internet, or as a separately packaged computer-readable storage medium).

[0140] Thus, although the disclosure describes specific embodiments, it should be noted that the disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

Claims (20)

What is claimed is: 1. A method comprising: receive, by the processor(s), from a client linked to a first entity, a device identifier; transmitting, by the one or more processors, to the first entity, an instruction indicating that the device identifier of the first device is authorized in response to performing a search in a first set of databases using the device identifier; receiving, by the one or more processors, from the first entity, a record of an event corresponding to the device identifier, the record comprising the device identifier, a first value related to the device identifier and a first device identifier identifying the event; storing, by the one or more processors, in the first set of databases, a first entry identifying the device identifier, the first value, the first event identifier, a specification of the first device, and a first state indicating that the first device is authorized, the first set of databases comprising the plurality of second device identifiers corresponding to the plurality of second devices, each second device identifier of the plurality of second device identifiers being assigned to a respective group of the plurality of groups; assigning, by the one or more processors, the device identifier of the first device to a first group of the plurality of groups, each device identifier of the first group being permanently authorized to access one or more networks through one or more mobile network operators; and Providing, by the one or more processors, to a first system maintaining a second set of databases for a first mobile network operator, data corresponding to the first entity identifying the device identifier, the first value, the first event identifier, the specification of the first device, and the first state, the second set of databases being used by the first mobile network operator to respond to requests to verify one or more device identifiers corresponding to one or more respective devices connecting to a first mobile network operator. 2. The method of claim 1, further comprising: receiving by the one or more processors, of the first system, data corresponding to a second device identifier of a second device, the second device not included in the first database set, the data corresponding to the second device identifier stored in the second database device; updating, by the one or more processors, the first set of databases to include a second entry comprising data corresponding to the second device identifier of the second identifier; assigning, by the one or more processors, the second entry corresponding to the second device identifier, a second state different from the first state; and assigning, by the one or more processors, the second device identifier to one of the second group of the plurality of groups, or the third group of the plurality of groups, each device identifier included in the second group being temporarily authorized to access the network(s) through the one or more mobile network operators and each device identifier included in the third group being prevented from accessing the network(s) through the one or more mobile network operators. 3. The method of claim 2, further comprising: providing, by the one or more processors, to a second system maintaining a third set of databases for a second mobile network operator, data corresponding to the second input, the third set of databases being used by the second mobile network operator to respond to requests for verification of one or more device identifiers corresponding to one or more respective devices connecting to a second network of the second mobile network operator. 4. The method of claim 2, further comprising: identifying, by the processor(s), a first moment corresponding to a second event when the second device accesses the first network of the first mobile network operator; updating, by the one or more processors, in response to determining that a predetermined duration of time has elapsed from the first moment, of the second state of the second input corresponding to the second device identifier to a third state different from the second state and the first state; and assigning, by the one or more processors, the second device identifier to the third group of the plurality of groups. 5 5. The method of claim 4, wherein the predetermined duration is based on a policy, the policy being generated by a second entity of the one or more processors. 6. The method of claim 1, wherein the device identifier included in the first input is a device identifier of the first device, further comprising: 10 determining, by the one or more processors, that the first device has connected to the first network of the first mobile network operator at a first time; receiving, by the one or more processors, from the first system, data corresponding to a second device identifier, the data corresponding to the second identifier being stored in the second set of databases, the second device being connected to the second mobile network operator at the first time; determining, by the processor(s), that the second device identifier of the second device matches the first device identifier included in the first entry: determining that a third device identifier of the second device does not match a device identifier of the first device included in the first entry: and 20 assigning, by the one or more processors, in response to determining that the third device identifier of the second device does not match the device identifier included in the first entry, a label to a second entry indicating that the second device corresponds to a cloned device. 25 7. The method of claim 6, further comprising assigning, by the one or more processors, in response to determining that the third device identifier of the second device does not match the device identifier of the first device included in the first entry, the second device identifier of the second device to a second group of the plurality of groups or a third group of the plurality of groups, each device identifier included in the second group 30 being temporarily permitted to access the network(s) through the mobile network operator(s), and each device identifier included in the third group being prevented from accessing the network(s) through the mobile network operator(s). 8. The method of claim 1, wherein providing the first system with the data corresponding to the first input comprises providing, by the one or more processors, to the first system the data corresponding to the first input according to a time-based update policy. 9. The method of claim 1, further comprising providing, by the one or more processors, to a plurality of second systems, data corresponding to the first input such that the first system and each second system of the plurality of second systems include the first input. 10. The method of claim 1, wherein the device identifier is at least one of an International Mobile Equipment Identity (1ME1) number, an International Mobile Subscriber Identity (1MS1), or a Mobile Multi-Service Digital Subscriber Network (MSISDN) number. 11. The method of claim 1, further comprising: receiving, by the one or more processors, data corresponding to a second device identifier of a second device, the second device identifier being included in the first set of databases and assigned a second state different from the first state; determining, by the processor(s), from the received data corresponding to the second device identifier, a second value and a second event identifier identifying a second event; updating, by the one or more processors, in response to determining that the second value and the second event identifier satisfy a state update policy, the second state from the second identifier to the first state; and assigning, by the one or more processors, in response to updating the second state to the first state, the second device identifier to the first group of the plurality of groups, and removing the second device identifier from the second group of the plurality of groups. 12. The method of claim 1. further comprising: receive, by the processor(s), data corresponding to a third device identifier from a third device: determining, by the processor(s), that the third device identifier corresponds to an unauthorized device; in response to determining that the third device identifier corresponds to an unauthorized device, storing, by the one or more processors, in the first set of databases, a second entry identifying the third device identifier and a second state indicating that the third device is unauthorized; and assigning, by the one or more processors, the third device identifier to a second group of the plurality of groups or a third group of the plurality of groups, each device identifier included in the second group being temporarily authorized to access the one or more networks through the one or more mobile network operators, and each device identifier included in the third group being prevented from accessing the one or more networks through the one or more mobile network operators. 13. The method of claim 1, further comprising: receive by the processor(s) data corresponding to a third device identifier of a third device; determining, by the processor(s), that the third device identifier corresponds to at least i) a duplicate device identifier, ii) a false device identifier, iii) a false statement of specifications or functions due for the third device, or iv) an indication that the transaction event identifying the third device was not processed; in response to determining that the third device identifier corresponds to at least one of i) a duplicate device identifier, ii) a false device identifier, iii) a false statement of specifications or functions due for the third device, or iv) an indication that the transaction event identifying the third device was not processed, storing, by the one or more processors, in the first set of databases, a second entry identifying the third device identifier and a second state indicating that the third device is unauthorized; and assigning, by the one or more processors, the third device identifier to a second group of the plurality of groups or a third group of the plurality of groups, each device identifier included in the second group being temporarily authorized to access the one or more networks through the one or more mobile network operators, and each device identifier included in the third group being prevented from accessing the one or more networks through the one or more mobile network operators. 14. A system comprising: one or more processors configured by machine-readable instructions to: receive, from a client linked to a first entity, a device identifier of a first device; transmitting, to the first entity, an instruction indicating that the device identifier of the first device is authorized in response to performing a search in a first set of databases using the device identifier; receiving, from the first entity, a record of an event corresponding to the device identifier, the record comprising the device identifier, a first value associated with the device identifier, and a first event identifier identifying the event; storing, in the first database set, a first entry identifying the device identifier, the first value, the first device identifier, a specification of the first device, and a first state indicating that the first device is authorized, the first database set comprising a plurality of second device identifiers corresponding to the plurality of second devices, each second device identifier of the plurality of second device identifiers being assigned to a respective group of the plurality of groups; assigning the device identifier of the first device to a first group of the plurality of groups, each device identifier of the first group being definitively authorized to access one or more networks through one or more mobile network operators; and providing, to a first system maintaining a second set of databases for a first mobile network operator, data corresponding to the first enirec identifying the device identifier, the first value, the first device identifier, the specification of the first device and the first state, the second set of databases used by the first mobile network operator responding to requests for verification of one or more device identifiers corresponding to one or more respective devices connected to a first network of the first mobile network operator. 15. The system of claim 14, wherein the one or more processors are further configured to: receive, from the first system, data corresponding to a second device identifier of a second device, the second device identifier not being included in the first set of databases, the data corresponding to the second device identifier being stored in the second set of databases; updating the first database set to include a second entry comprising data corresponding to the second device identifier of the second device; assigning to the second entry corresponding to the second device identifier a second state different from the first state; and assigning the second device identifier to a second group of the plurality of groups or a third group of the plurality of groups, each device identifier included in the second group being temporarily authorized to access the network(s) through the mobile network operator(s), and each device identifier included in the third group being prevented from accessing the network(s) through the mobile network operator(s). 16. The system of claim 14, wherein the one or more processors are further configured to: provide, to a second system maintaining a third set of databases for a second mobile network operator, data corresponding to the second input, the third set of databases being used by the second mobile network operator to respond to requests to verify one or more device identifiers corresponding to one or more respective devices connected to a first network of the first mobile network operator. 17. The system of claim 15, wherein the one or more processors are further configured to: identify a first time corresponding to a second event when a second device accesses the first network of the first mobile network operator; updating, in response to determining that a predetermined time has elapsed since the first time, the second state of the second input corresponding to the second device identifier to a third state different from the second state and the first state; and assigning the second device identifier to the third group of the plurality of groups. 18. The system of claim 17, wherein the predetermined duration is based on a policy, the policy being generated by a second entity of the one or more processors. 19. The system of claim 14, wherein the device identifier included in the first input is a device identifier of a first device and wherein the one or more processors are further configured to: determining that the first device connected to the first network of the first mobile network operator at a first time; receiving, from the first system, data corresponding to a second device identifier of a second device, the data corresponding to the second device identifier being stored in the second set of databases, the second device connecting to the second network of the second mobile network operator at the first time; determining that the second device identifier of the second device matches the first device identifier included in the first entry; determining that the third device identifier of the second device does not match the device identifier of the first device included in the first entry; and assigning, in response to determining that the third device identifier of the second device does not match the device identifier included in the first entry, a label indicating that the second device corresponds to a cloned device. 20. A non-transitory computer-readable storage medium having embodied instructions, the instructions being executable by one or more processors to: receiving, from a client linked to a first entity, a device identifier of a first device; transmitting, to the first entity, an instruction indicating that the device identifier of the first device is authorized in response to performing a search in the first set of databases using the device identifier; receiving, from the first entity, a record of an event corresponding to the device identifier, the record comprising the device identifier, a first value related to the device identifier, and a first event identifier identifying the event; storing, in the first set of databases, a first entry identifying the device identifier, the first value, the first event identifier, a specification of the first device, and a first state indicating that the first device is authorized, the first set of databases comprising a plurality of second device identifiers corresponding to the plurality of second devices, each second device identifier of the plurality of second device identifiers being assigned to a respective group of the plurality of groups; 5 assigning the device identifier of the first device to a first group of the plurality of groups, each device identifier of the first group being permanently authorized to access one or more networks through one or more mobile network operators; and providing, to a first system maintaining a second set of databases for a mobile network operator, data corresponding to the first entry identifying the identifier 10 device, the first value, the first device identifier, the specification of the first device and the first state, the second set of databases being used by the first mobile network operator to respond to requests for verification of one or more device identifiers corresponding to one or more respective devices connected to a first network of the first mobile network operator.