BACKGROUND

[0001] Existing caller identification services can display the identification of a caller when a call is received on a receiver device. Existing caller identification services typically rely on the caller’s information being stored on the receiver’s device or transmitted over a network connection.

SUMMARY

[0002] The present disclosure relates to systems and methods for providing caller identification services. According to one aspect, a method can include receiving, from a mobile switch, a first request to identify a first entity initiating a call to a second entity. The first request can be generated responsive to receiving an indication that the second entity is a subscriber of a caller identification service. The method can include identifying, responsive to receiving the first request, an identity of the first entity via a lookup in one or more data sources. The method can include transmitting, a second request to a messaging service to transmit, to the second entity, a third request to display a message including the identity of the first entity on a display of a device of the second entity.

[0003] In some embodiments, the method can include transmitting, a fifth request to set a flag in a register responsive to a fourth request to subscribe the first entity to the caller identification service. The flag can be used to generate the indication that the first entity is a subscriber of the caller identification service. The method can include receiving an acknowledgment to the fifth request. The method can include adding the first entity to one or more second data sources responsive to receiving the acknowledgement.

[0004] In some embodiments, the method can include transmitting, a fifth request to set a flag in a register responsive to a fourth request to subscribe the second entity to the caller identification service. The flag can be used to generate the indication that the second entity is a subscriber of the caller identification service. In certain embodiments, the method can include receiving, an acknowledgment to the fifth request. The method can include adding the second entity to one or more second data sources responsive to receiving the acknowledgement.

[0005] In some embodiments, the method can include updating a subscriber profile of the second entity to include a flag indicating that the caller identification service is enabled for the second entity. The subscriber profile can be maintained on a register. The method can be configured to access the register via one or more communication protocols. In certain embodiments, the flag is a Terminating - CAMEL Subscription Information (T-CSI) flag. Receiving the first request can include receiving a CAMEL Application Part Initial Detection Point (CAP IDP) request to determine an identity of the first entity. In certain embodiments, the flag is a TICK flag. Receiving the first request can include receiving a Capability Set 1 (CS1+) Initial Detection Point (IDP) request to determine an identity of the first entity. [0006] In some embodiments, the method can include transmitting a response to the request to indicate that the request was successfully received. In some embodiments, the message is at least one of a Short Message Service (SMS) message including the name associated with the first entity or a push message including the name associated with the first entity. In some embodiments, the message includes an actionable object, which when actuated, causes the device of the second entity to store a contact record of the first entity on the device.

[0007] The present disclosure further relates to a system including one or more processors configured by machine- readable instructions. The one or more processors can receive, from a mobile switch, a first request to identify a first entity initiating a call to a second entity. The first request can be generated responsive to receiving an indication that the second entity is a subscriber of a caller identification service. The one or more processors can identify, responsive to receiving the first request, an identity of the first entity via a lookup in one or more data sources. The one or more processors can transmit, a second request to a messaging service to transmit, to the second entity, a third request to display a message including the identity of the first entity on a display of a device of the second entity.

[0008] In some embodiments, the one or more processors can transmit, a fifth request to set a flag in a register responsive to a fourth request to subscribe the first entity to the caller identification service. The flag can be used to generate the indication that the first entity is a subscriber of the caller identification service. The one or more processors can receive an acknowledgment to the fifth request. The one or more processors can add the first entity to one or more second data sources responsive to receiving the acknowledgement.

[0009] In some embodiments, the one or more processors can transmit, a fifth request to set a flag in a register responsive to a fourth request to subscribe the second entity to the caller identification service. The flag can be used to generate the indication that the second entity is a subscriber of the caller identification service. In certain embodiments, the one or more processors can receive, an acknowledgment to the fifth request. The one or more processors can add the second entity to one or more second data sources responsive to receiving the acknowledgement.

[0010] In some embodiments, the one or more processors can update a subscriber profile of the second entity to include a flag indicating that the caller identification service is enabled for the second entity. The subscriber profile can be maintained on a register. The one or more processors can access the register via one or more communication protocols. In certain embodiments, the flag is a Terminating - CAMEL Subscription Information (T-CSI) flag. Receiving the first request can include receiving a CAMEL Application Part Initial Detection Point (CAP IDP) request to determine an identity of the first entity. In certain embodiments, the flag is a TICK flag. Receiving the first request can include receiving a Capability Set 1 (CS1+) Initial Detection Point (IDP) request to determine an identity of the first entity.

[0011] In some embodiments, the one or more processors can transmit a response to the request to indicate that the request was successfully received. In some embodiments, the message is at least one of a Short Message Service (SMS) message including the name associated with the first entity or a push message including the name associated with the first entity. In some embodiments, the message includes an actionable object, which when actuated, causes the device of the second entity to store a contact record of the first entity on the device.

[0012] The present disclosure further relates to a non-transitory computer-readable storage medium having instructions embodied thereon, the instructions being executable by one or more processors. The one or more processors can receive, from a mobile switch, a first request to identify a first entity initiating a call to a second entity. The first request can be generated responsive to receiving an indication that the second entity is a subscriber of a caller identification service. The one or more processors can identify, responsive to receiving the first request, an identity of the first entity via a lookup in one or more data sources. The one or more processors can transmit, a second request to a messaging service to transmit, to the second entity, a third request to display a message including the identity of the first entity on a display of a device of the second entity.

[0013] According to another aspect, the present disclosure further describes a method for providing caller identification services. The method can include maintaining one or more data structures including a plurality of subscriber records corresponding to subscribers of a caller identification service. The method can also include receiving, from a network processor, responsive to a first entity initiating a call to a second entity, network traffic corresponding to the call. The method can also include identifying, from the network traffic, a first device identifier of the first entity and a second device identifier of the second entity. The method can also include determining, by performing a lookup in the one or more data structures, that the second entity associated with the second device identifier is a subscriber of the caller identification service. The method can also include identifying, using the first device identifier, an identity of the first entity via a lookup in one or more data structures. The method can also include transmitting, responsive to determining that the second entity is a subscriber and responsive to identifying the identity of the first entity, a first request to a messaging service to transmit, to the second entity, a second request to display a message including the identity of the first entity on a display of a device corresponding to the second device identifier associated with the second entity.

[0014] According to another aspect, the present disclosure further relates to a system including one or more processors configured by machine-readable instructions. The one or more processors can include maintaining one or more data structures including a plurality of subscriber records corresponding to subscribers of a caller identification service. The one or more processors can also include receiving, from a network processor, responsive to a first entity initiating a call to a second entity, network traffic corresponding to the call. The one or more processors can also include identifying, from the network traffic, a first device identifier of the first entity and a second device identifier of the second entity. The one or more processors can also include determining, by performing a lookup in the one or more data structures, that the second entity associated with the second device identifier is a subscriber of the caller identification service. The one or more processors can also include identifying, using the first device identifier, an identity of the first entity via a lookup in one or more data structures. The one or more processors can also include transmitting, responsive to determining that the second entity is a subscriber and responsive to identifying the identity of the first entity, a first request to a messaging service to transmit, to the second entity, a second request to display a message including the identity of the first entity on a display of a device corresponding to the second device identifier associated with the second entity.

BRIEF DESCRIPTIONS OF THE DRAWINGS

[0015] FIG. 1A displays an environment for providing caller identification services according to embodiments of the present disclosure.

[0016] FIG. 1B displays an embodiment of the environment for providing caller identification services.

[0017] FIG. 2A illustrates a database architecture including a local database maintained by a mobile network operator according to embodiments of the present disclosure.

[0018] FIG. 2B illustrates a database architecture including a centralized database and a plurality of local databases maintained by mobile network operators according to embodiments of the present disclosure.

[0019] FIG. 3 illustrates a method for providing caller identification service according to embodiments of the present disclosure.

[0020] FIG. 4A illustrates an operational flow corresponding to the method of FIG. 3.

[0021] FIG. 4B illustrates an embodiment of the operational flow corresponding to the method of FIG. 3.

[0022] FIG. 4C illustrates a flow for subscribing a device identifier to the caller identification services according to embodiments of the present disclosure.

[0023] FIG. 5A and FIG. 5B illustrate a user interface of the caller identification services according to embodiments of the present disclosure.

[0024] FIG. 6 illustrates a simplified block diagram of a representative server system and client computer system usable to implement certain embodiments of the present disclosure.

DETAILED DESCRIPTION

[0025] For purposes of reading the description of the various embodiments of the present invention below, the following descriptions of the sections of the specification and their respective contents may be helpful:

Section A describes systems and methods for providing caller identification services;

Section B describes a network environment and computing environment useful for practicing an embodiment of the present disclosure; A. SYSTEMS AND METHODS FOR PROVIDING CALLER IDENTIFICATION SERVICES

[0026] Existing caller identification services rely on information that is stored on the device of a recipient of a call. In such services, when a call is received by the device of the recipient, the phone number of the caller is matched to a contact record stored on the recipient device and the name associated with the contact record is displayed on the recipient device. There are a few problems that arise with such caller identification services. First, the contact record can include information stored by the recipient such that the identity of the caller may not be ascertained from the contact record itself. For instance, a father’s phone number can be stored in a contact record with the name “Dad.” Moreover, a person’s phone number may change over time. Such caller identification services may not be able to identify the caller if the caller is calling from a number not currently stored in the contact record on the recipient device.

In other existing caller identification services, caller identification information requires the recipient’s device to have access to a data connection via which the caller identification information can be received by the recipient’s device.

Such caller identification services are limited in their applicability based on the recipient’s device. For instance, the recipient’s device needs to be capable of installing an application, receiving data via a data or internet connection, or be in an area where the recipient device has a data connection.

[0027] The present solution addresses the technical challenges faced by the existing technological solutions by executing a caller identification service accessible to or executing on a mobile network operator that can detect a call to a recipient device, identify the caller of the call, and transmit to the recipient device, a notification to the recipient device identifying the caller of the call. Because the caller identification 5 n service can maintain records for a large number of phone numbers, including names associated with the phone numbers, the caller identification service can provide, via the mobile network operator, the caller’s identity to the recipient device even if the recipient device does not already have a contact record associated with the phone number of the caller.

[0028] According to one aspect, the present disclosure is directed to methods and systems for providing caller identification services. The system can include one or more processors configured by machine-readable instructions. The one or more processors can receive, from a mobile switch, a first request to identify a first entity, such as a caller, initiating a call to a second entity. The first request can be generated responsive to receiving an indication that the second entity, such as a recipient, is a subscriber of a caller identification service. The one or more processors can identify, responsive to receiving the first request, an identity of the caller via a lookup in one or more data sources. The one or more processors can then transmit, a second request to a messaging service to transmit, to the recipient, a third request to display a message including the identity of the caller on a display of a device of the recipient.

[0029] Referring now to FIG. 1A, FIG. 1A illustrates an environment 100 for providing caller identification services. The environment 100 can be configured to include various subsystems or components. The environment 100 can include a caller device 102 and a receiver device 104. The environment 100 further includes a mobile network operator 106. The mobile network operator 106 can include a mobile switch 108, a home location register 110, a caller identification system 112, and a messaging service 128. In some embodiments, the mobile switch 108 and the HLR 110 can be part of a core network processor (as shown in FIG. 1B as core network processor 111). The mobile switch 108 can be coupled to the home location register 110, the receiver device 104, and the caller identification system 112. The caller identification system 112 can include a call manager 114, a record manager 116, a local database 118 including one or more local subscriber records 120, and a message manager 126. Each local subscriber record 120 can include subscriber information about a particular subscriber, such as a name of the subscriber, a phone number or other device identifier, among others. In some embodiments, the local database 118 can receive updates to the one or more local subscriber records 120 via an offline synchronization process, for instance, by using a flash or hard drive update process. The local database 118 can be communicatively coupled to a central database 122. In some embodiments, the local database 118 retrieves data from the central database 122 via a network connection in real time. In some embodiments, the local database 118 can store the retrieved data. In certain embodiments, the local database 118 updates the stored data at predetermined intervals with data from the central database 122. The central database 122 can include one or more central subscriber records 124 and can synchronize data included in the central subscriber records 124 with corresponding local subscriber records 120 included in the local database 118. Each central subscriber record 124 can similarly include subscriber information about a particular subscriber. The messaging service 128 can transmit messages based on the information in the caller identification system 112 to the receiver device 104. Additional details relating to each of the components described above are provided below.

[0030] The caller device 102 is a telecommunications device that can communicate with the mobile switch 108. The caller device 102 can be associated with a user. The caller device 102 can include a device identifier assigned by the mobile network operator 106. The device identifier can be a MSISDN or a phone number. The caller device 102 can be any device capable of establishing a phone call.

[0031] The receiver device 104 can be a telecommunications device that can receive phone calls via the mobile network operator 106. The receiver device 104 can be associated with a user. The receiver device 104 can have a device identifier assigned by the mobile network operator 106. The device identifier can be a MSISDN or a phone number. The receiver device 104 can be any device capable of receiving a phone call. The receiver device 104 can be a device that can be configured to receive cellular data via a cellular data connection, such as a smartphone. The receiver device 104 can be a device that is not capable of receiving cellular data or data via a Wi-Fi connection, such as a feature phone or dumbphone. [0032] The mobile network operator (MNO) 106 can be a provider of communications services. The MNO 106 can include the mobile switch service (MSS) 108, the home location register (HLR) 110, the caller identification system 112, and the messaging service 128.

[0033] The mobile switch 108 can route communications between caller devices and recipient devices. The mobile switch 108 can be a mobile switching server (MSS) or an IP Multimedia Subsystem (IMS). The MSS 108 can route communications between the caller device 102 and the receiver device 104. In some embodiments, the MSS 108 is a signal transfer point that can route signaling messages between devices such as the caller device 102 and the receiver device 104. In some embodiments, the MSS 108 is a mobile switching center that routes calls, messages, or other communications services between devices such as the caller device 102 and the receiver device 104. For instance, the MSS 108 can route a call from caller device 102 to the receiver device 104. In particular, the MSS 108 can receive a call from the caller device 102. The MSS 108 can transmit the call from the caller device 102 to the receiver device 104. The MSS 108 can also query, via a MAP SRI request, the HLR 110 to check routing information and services.

[0034] The home location register 110 can be a database that contains details of each subscriber of the MNO 106. The HLR 110 can be in communication with the MSS 108. The HLR 110 can include IMSI/MSISDN pairs. The HLR 110 can include routing information for each device. For instance, the HLR 110 can store subscriber information that can be used by the MSS 108 to route calls. The HLR 110 can return the subscriber information to the MSS 108, which can route the calls based on the subscriber information and services. For instance, when the caller device 102 calls a receiver device 104, the MSS 108 can, while the caller device 102 is attempting to communicate with the receiver device 104, send the identification request to the CIS 112.

[0035] The caller identification system (CIS) 112 can be any script, file, program, application, set of instructions, or computer-executable code that is configured to perform the functionality described herein. The CIS 112 can also include one or more processors configured to execute the script, file, program, application, set of instructions, or computer-executable code that is configured to perform the functionality described herein. The CIS 112 can manage device identification for a specific MNO 106. The CIS 112 can be in communication with the mobile switch 108, the central database 122, and the messaging service 128. In some embodiments, the CIS 112 can be in communication with the core network processor 111. Accordingly, the CIS 112 can receive network traffic from the core network processor 111. The CIS 112 can be part of the mobile network operator 106. The CIS 112 can integrate with the HLR 110 associated with the MSS 108. The CIS 112 can integrate with the HLR 110 via INAP, HTTP, CS1 or any other protocol.

[0036] The CIS 112 can include the call manager 114. The call manager 114 of the CIS 112 can be configured to detect a phone call. The call manager 114 can detect a phone call from the caller device 102. The call manager 114 can detect the phone call based on receiving a notification from the MSS 108. In some embodiments, the call manager 114 can, responsive to receiving the notification, identify a caller device 102 that initiated a call to a receiver device 104. The call manager 114 can receive the identification request while the caller device 102 is calling the receiver device 104. In some embodiments, the identification request can be a CAMEL Application Part Initial Detection Point (CAP IDP) request to determine an identity of the caller device 102. In some embodiments, the call manager 114 can transmit a response to the identification request to indicate that the identification request was successfully received.

For instance, the call manager 114 can transmit, responsive to the identification request, a CAP CUE to the MSS 108.

In some embodiments, the identification request to determine an identity of the calling device 102 can include an Initial Detection Point (IDP) request or a request using any other protocol. For instance, the call manager 114 can receive a CAP IDP request from the MSS 108 to identify the caller device 102. The call manager 114 can receive the identification request via the MSS 108 or a Signaling Transfer Point (STP) via CAMEL protocol or any other protocol. In some embodiments, the call manager 114 can receive the identification request based on whether the receiver device 104 is a subscriber of the caller identification service provided by the CIS 112.

[0037] The CIS 112 can also include the record manager 116. The record manager 116 can be configured to create a local subscriber record 120 for each subscriber of the caller identification service 112. For instance, the subscriber can be the caller device 102 or the receiver device 104 or an entity, such as a person, associated with the caller device 102 or the receiver device 104. In some embodiments, the subscriber to the caller identification service can be a person or device that subscribes to services provided by the MNO on which the CIS 112 is executing. The caller device 102 or the receiver device 104 can subscribe to the caller identification service by sending a subscription request to the record manager 116 via a user interface or a message. The record manager 116 can receive the subscription request via the mobile switch 108 or the messaging service 128. Service staff of the CIS 112 can also subscribe devices to the caller identification service by generating the subscription requests. The record manager 116 can generate a local subscriber record 120 of each subscriber to the caller identification service. For instance, the record manager 116 can generate a local subscriber record 120 for a subscriber responsive to a subscription request to register a caller device 102 or a receiver device 104 for the caller identification service. Each local subscriber record 120 can include a name, a phone number, device information, or any other device identifier of the device. Each local subscriber record 120 can also include a flag indicating that the subscriber is a subscriber of the caller identification service. The CIS 112 or another entity can set or assign the flag to the local subscriber record 120 of the subscriber responsive to the CIS receiving a request to subscribe the device identifier or the entity associated with the device identifier to the caller identification service. The flag can be one or more bits or any other indicator that can be used by the CIS to determine or identify that the subscriber corresponding to the local subscriber record is a subscriber to the caller identification service. In some embodiments, the local subscriber record 120 can be a subscriber profile. [0038] The record manager 116 can receive the subscription requests via a variety of channels or protocols. For instance, the record manager 116 can receive the subscription request via a subscription channel. The record manager 116 can also receive the subscription request via a SMPP protocol. The record manager 116 can receive the subscription request via a SMPP gateway. The record manager 116 can receive the subscription request via a subscription channel such as SMS, unstructured supplementary service data (USSD), interactive voice response (IVR), web portal, or a mobile application. The record manager 116 can determine a charge amount for the caller identification service based on the MSISDN of the device. The record manager 116 can generate a billing request comprising a MSISDN of the subscriber and transmit the billing request to the charging system to charge the subscriber. The record manager 116 can transmit the billing request to a charging gateway with charging nodes via Camel, UCIP, or any other protocol. The record manager 116 can determine that the subscriber has been charged based on any supported protocol. The record manager 116 can create a local subscriber record 120 of the subscriber responsive to charging the subscriber for the caller identification service. In some embodiments, the record manager 116 can generate a flag request responsive to transmitting the billing request to the charging system to charge the subscriber. The record manager 116 can determine the service eligibility of the subscriber based on operator’s predetermined rules. Accordingly, integration with the operator can be through API, SS7 or any other communication type.

[0039] The record manager 116 can provision the HLR 110 to have the MSS 108 transmit an identification request to the CIS 112 to identify the caller device 102. In particular, the MSS 108 can transmit an identification request to the CIS 112 to identify the caller device 102 responsive to a flag set in the HLR 110. The record manager 116 can transmit a flag request to set the flag in the HLR 110. For instance, if the record manager 116 sets the flag in the HLR 110 to indicate that the receiver device 104 is a subscriber to the caller identification service, then the MSS 108 can transmit the identification request to the CIS 112 to identify the caller device 102. In some embodiments, the record manager 116 can transmit the flag request to set the flag in the HLR 110 responsive to the caller device 102 subscribing to the caller identification service. The flag can be used to indicate that the caller device 102 or the receiver device 104 is a subscriber of the caller identification service. Similarly, the record manager 116 can transmit the flag request to set the flag in the HLR 110 responsive subscribing the receiver device 104 to the caller identification service. The record manager 116 can receive, from the HLR 110, an acknowledgment to the flag request.

[0040] The record manager 116 can access the HLR 110 via one or more communication protocols. The record manager 116 can use the interface and the API exposed by HLR 110 to set the flag indicating that the caller identification service has been enabled for the subscriber. Similarly, when a subscriber is de-provisioned from the caller identification service, the record manager 116 can use the same API to remove the flag in the HLR 110. The record manager 116 can provision or de-provision the device identifier based on MSISDN via a SOAP or XML protocol. The record manager 116 can provision the HLR 110 based on MSISDN of the device. The record manager 116 can provision the device identifier based on MSISDN via a SOAP or XML protocol. The record manager 116 can provision the device identifier, such as the MSISDN, via HTTP, MML, DB hits via a provisioning gateway.

[0041] The record manager 116 can manage the flags in the HLR 110. The flag can be stored in a portion of memory on the HLR 110. Based on the flag, the MSS 108 can notify the CIS 112 about communications generated by the caller device 102. For instance, based on the flag set in the HLR 110, the MSS 108 can notify the CIS 112 about communications generated from the caller device 102 to the receiver device 104. In certain embodiments, the flag is a Terminating - CAMEL Subscription Information (T-CSI) flag. If the flag is the T-CSI flag, then whenever the caller device 102 places a call to the receiver device 104, the MSS 108 can send a CAP I DP request via CAMEL protocol to trigger the CIS 112. In certain embodiments, the flag is a TICK flag. For instance, the call detection handling can be based on the TICK flag set in the HLR 110. If the TICK flag is used, the MSS 108 can send a CS1 +IDP message to trigger the CIS 112. The triggering of the CIS 112 can notify the CIS 112 about communications generated by the caller device 102 and cause the CIS 112 to look up information about the caller device 102 to provide the identity of the caller device 102 to the receiver device 104.

[0042] The CIS 112 can include the local database 118 that is specific to each CIS 112. The local database 118 can maintain, for each subscriber of the caller identification service of the MNO, a local subscriber record 120 that includes the subscriber’s phone number or other contact identifier, a name, flag, or device information. In some embodiments, the record manager 116 can update the local subscriber record 120 of the receiver device 104 to indicate that the flag was set in the HLR 110 to indicate that the caller identification service is enabled for the receiver device 104. The CIS 112 can store the local subscriber record 120 in the local database 118. For instance, the CIS 112 can store the local subscriber record 120 for the caller device 102 or the receiver device 104. The local database 118 can synchronize each local subscriber record 120 with the central database 122 such that each local subscriber record 120 stored in the local database 118 is shared with the central database 122. The central database 122 can also store a central subscriber record 124. The central subscriber record 124 can correspond to information about a device identifier subscribed to the caller identification system. The central subscriber record 124 can correspond to the local subscriber record 120. Accordingly, each central subscriber record 124 maintained by the central database 122 can be synchronized with each local database 118. For instance, the data stored with the central database 122, including each central subscriber record 124 received from other local databases of other CIS maintained by other MNOs, can be shared with the local database 118. In certain embodiments, the central database 122 can synchronize data with any data source or database of any service or application. In particular, the central database 122 can synchronize each central subscriber record 124 with each local subscriber record 120 in the local database 118. Additional details regarding the central database 122 are provided below. [0043] The central database 122 can synchronize caller and subscriber information with more than one caller identification system 112. Now referring to FIG. 2A, FIG. 2A illustrates a database architecture including a local database 118 maintained by a mobile network operator 106 according to embodiments of the present disclosure. In some embodiments, the local database 118 can be updated using a flash or hard drive with updates to the one or more local subscriber records 120 stored on the local database 118. In some embodiments, the local database 118 can connect to one or more data sources and receive updates from the data sources. Now referring to FIG. 2B, FIG. 2B illustrates a database architecture including a centralized database, such as the central database 122, and a plurality of local databases, such as the local database 118 maintained by mobile network operators according to embodiments of the present disclosure. The central database 122 can synchronize data with one or more local databases 118a-118n (generally referred to as the local database 118) corresponding to one or more caller identification systems 112a-112n (generally referred to as caller identification system 112) of one or more mobile network operators 106a-106n (generally referred to as mobile network operator 106). In some embodiments, the central database 122 provides data to the local database 118 via a network connection in real time or at predetermined intervals.

[0044] Now referring back to FIG. 1A, the call manager 114 and the record manager 116 can store data in the local database 118 as the local subscriber record 120. For instance, the record manager 116 can add the caller device 102 to one or more caller identification service data sources responsive to receiving the acknowledgement to the flag request. The one or more caller identification service data sources can be the local database 118 or the central database 122. Similarly, the record manager 116 can add the receiver device 104 to one or more caller identification service data sources responsive to receiving the acknowledgement to flag request. The one or more caller identification service data sources can be the local database 118 or the central database 122.

[0045] The record manager can manage, add, update, or remove information associated with the caller device 102 or the receiver device 104 to the local database 118. For instance, the record manager 116 can manage the local database 118 via USSD gateway via FITTP, SOAP, or XML protocol. The record manager 116 can suspend or activate the device identifier, such as the MSISDN, with the caller identification service. The record manager 116 can subscribe the device identifier, such as the MSISDN, to the caller identification service and associate the subscription with a user, user information, bundle, service name, channel, channel option, or timestamp. A device identifier, for example the MSISDN, can be opted in or opted out of the caller identification service. For instance, if a device identifier is opted out of the caller identification service, then the CIS 112 can add the device identifier to a blacklist to avoid having information associated with the device identifier stored in the local database 118 or the central database 122. If the device identifier is opted in to the caller identification service, then the CIS 112 can add the device identifier to the whitelist to authorize the CIS 112 to store information associated with the device identifier in the local database 118 or the central database 122. [0046] The record manager 116 can provide subscription status, add subscriptions, remove subscriptions, or modify subscriptions. The record manager 116 can provide subscription status, add subscriptions, remove subscriptions, or modify subscriptions via a SMPP protocol. The record manager 116 can provide subscription status based on result of a lookup of the MSISDN of the device in the local database 118. The record manager 116 can query the local database 118 with the device identifier of the caller device 102 or the receiver device 104 to determine whether the caller device 102 or the receiver device 104 is subscribed to the caller identification service. Based on the query, the CIS 112 can determine the flags set in the HLR 110 for the queried device. In some embodiments, the records manager 116 determines if the flag set in the HLR 110 indicating that the subscriber is a subscriber of the caller identification service is accurate by checking whether the device identifier of the receiver device 104 is identified as a subscriber in a local subscriber record 120 including the device identifier. If the flag is not accurate, such as due to an error or synchronization issue between the HLR 110 and the local database 118, the records manager 116 can restrict or prevent the message manager 126 from transmitting a message identifying the caller device 102. Similarly, the CIS 112 can receive the identification request to identify the caller device 102 responsive to the record manager 116 indicating that the receiver device 104 is a subscriber of a caller identification service provided by the CIS 112.

[0047] The CIS 112 can identify device identifiers that subscribed to the caller identification service. The call manager 114 can identify, responsive to receiving the identification request, an identity of the caller device 102 via a lookup in one or more caller identification service data sources. The one or more caller identification service data sources can be the local database 118 or the central database 122. The call manager 114 can query the local database 118 or the central database 122. The call manager 114 can query the caller by MSISDN. The call manager 114 can retrieve a caller identifier of the caller device 102 from the local database 118 or the central database 122. The call manager 114 can identify the caller identifier of the caller device 102. When the call manager 114 identifies the caller device 102, the message manager 126 can notify the receiver device 104.

[0048] The CIS 112 can include the message manager 126. The message manager 126 can receive the identity of the caller device 102 from the local database 118 based on the identification request received by the call manager 114. The message manager 126 can forward the identity of the caller device 102 to the receiver device 104. The message manager 126 can transmit a message request to the messaging service 128 to transmit, to the receiver device 104, a display request to display the identity of the caller device 102 on a display of the receiver device 104. The message request can include the identity of the caller device 102. The display request can be a request to display a message having the identity of the caller device 102.

[0049] The MNO 106 can include the messaging service 128. The messaging service 128 can be a short message service center (SMSC) or any other network server. The message manager 126 can transmit the display request to identify the caller device 102 to the SMSC via a short message peer to peer (SMPP) protocol, USSD push, smart push, or push SMS. The SMPP can be a protocol for exchanging messages. The SMPP protocol can be v3.4. The message manager 126 can transmit the message request identifying the caller device 102 via the messaging service 128 having a SMPP gateway. The display request can include information identifying the caller device 102 and message objects to save the information. The message object can be a graphical object, button, or icon presented on a display screen of a mobile device. In some embodiments, the graphical object, button, or icon can be displayed within a mobile application executing on the mobile device.

[0050] Referring now to FIG. 1B, FIG. 1B illustrates an embodiment of the environment 100 similar to FIG. 1 A except that FIG. 1B depicts a core network processor 111 instead of the mobile switch 108 and the home location register 110. In some embodiments, the core network processor 111 includes the mobile switch 108 and the home location register 110. The functionality of the core network processor 111 is further described with respect to FIG. 4B. The core network processor 111 can route communications between caller devices and recipient devices. The core network processor 111 can route communications between the caller device 102 and the receiver device 104. In some embodiments, the core network processor 111 routes calls, messages, or other communications services between devices such as the caller device 102 and the receiver device 104. For instance, the core network processor 111 can route a call from caller device 102 to the receiver device 104. In particular, the core network processor 111 can receive a call from the caller device 102. The core network processor 111 can route the call from the caller device 102 to the receiver device 104. The core network processor 111 can also transmit network traffic to the CIS 112. The network traffic can include communications between the caller device 102 and the receiver device 104, SIP INVITE, ISUP initiation, IDP traffic, BICC IAM, or any other SS7 communication. For instance, when the caller device 102 calls a receiver device 104, the core network processor 111 can transmit, to the CIS 112, network traffic comprising the device identifiers of the caller device 102 and the receiver device 104.

[0051] FIG. 3 illustrates a method for providing caller identification services according to embodiments of the present disclosure. The method 300 can include receiving a request to identify a first entity initiating a call to a second entity (step 302). The method 300 can include identifying an identity of the first entity (step 304). The method 300 can include transmitting a request to display a message on the second entity device (step 306). The method 300 can be performed by the caller identification system 112 shown in FIGs. 1 A and 1B. Additional details regarding FIG. 3 are provided in conjunction with the description of FIG. 4A and 4B.

[0052] Referring now to FIG. 4A, FIG. 4A illustrates a flow for providing caller identification services according to embodiments of the present disclosure. A caller device 102 initiates a call to a receiver device 104 at flow 402. At flow 404, the MSS 108 determines routing information for the caller device 102 and the receiver device 104. The MSS 108 determines the routing information based on a flag set in the home location register 110 of the mobile network operator 106 associated with the receiver device 104. At flow 406, the FILR 110 indicates that the receiver device 104 of the call is a subscriber to the caller identification service. At flow 408, the MSS 108 transmits a request to the CIS 112 to determine information about the call placed by the caller device 102. At flow 410, the CIS 112 transmits an acknowledgement packet, for example, aCAP CUE in response to the CAP IDP request. At flow 412, the CIS 112 identifies the device identifier of the caller device 102. At flow 414, the MSS 108 routes the call from the caller device 102 to the receiver device 104. At flow 416, the CIS 112 sends a message request to the messaging service 128 to transmit identification of the caller device 102 to the receiver party 104. In flow 418, the messaging service 128 transmits a display request to display the identification of the caller device 102 on the receiver device 104.

[0053] Referring more specifically to flow 408 and step 302 of FIG. 3, a caller identification system, such as the CIS 112 receives an identification request to identify the caller to the receiver device 104. The identification request can be received from a mobile switch, such as an MSS 108 of the mobile network operator 106. The identification request can be generated responsive to a caller device 102 initiating a call to a receiver device 104. The identification request can be generated by the MSS 108 responsive to the MSS 108 determining that the caller device 102 initiated the call to the receiver device 104. The MSS 108 transmits the identification request to identify the caller device 102 based on information stored in the HLR 110. As previously discussed in reference to flow 404, the MSS 108 queries the HLR 110 to determine routing information for the caller device 102. The HLR 110 can determine if the receiver device 104 is a subscriber of the caller identification service. The HLR 110 can determine that the receiver device is a subscriber if the HLR 110 includes a flag indicating that the receiver device 104 is a subscriber to the caller identification service. The flag can be the T-CSI flag or the TICK flag. As previously discussed in reference to flow 406, based on the flag, the HLR 110 responds with routing information for the MSS 108. Based on the routing information, the MSS 108 can route the call from the caller device 102 to the receiver device 104 and to the CIS 112 for identification of the caller device 102. In some embodiments, if the HLR 110 determines that the receiver device 104 is a subscriber of the caller identification service, then then HLR 110 can include an indication in a response to the MSS 108 to send a caller identification request of the caller device 102 to the CIS 112. In some embodiments, if the HLR 110 determines that the caller device 102 and the receiver device 104 are both subscribers, then the HLR 110 can request the MSS 108 to send an identification request to the CIS 112. The identification request can trigger the CIS 112 to determine information about the caller device 102. The identification request can be a CAP IDP request. In some embodiments, the MSS 108 can transmit the identification request via STP via CAMEL protocol. The call manager 114 of the CIS 112 can receive the identification request. As previously discussed in reference to flow 410, the CIS 112, or in particular, the call manager 114, can transmit an acknowledgement packet, for example, CAP CUE, in response to the identification request to determine information about the caller device 102.

[0054] Referring more specifically to flow 412 and step 304 of FIG. 3, the CIS 112 identifies the identity of the caller device 102. The CIS 112 can determine the identity of the caller by querying the caller device 102 in a database. For instance, the CIS 112 can look up the MSISDN of the caller device 102 in the database. The CIS 112 can identify information that matches the MSISDN of the caller device 102. For instance, the information that the CIS 112 determines as corresponding to the MSISDN of the caller device 102 can be a name of the entity or user associated with the caller device 102. It should be appreciated that flow 404, 406, 408, 410, and 412 can be performed prior to, parallel to, or subsequent to flow 414.

[0055] Referring more specifically to flow 416 and step 306 of FIG. 3, the CIS 112 transmits a message request to transmit a display request to display a message on the receiver device 104. The CIS 112 can transmit the message request via SMPP, USSD push, smart push, or push SMS. In some embodiments, the CIS 112 can transmit the message request to the messaging service 128 when the CIS 112 identifies the caller device 102. The message request can include the information about the caller device 102, such as the name of the entity or user using the caller device 102. The CIS 112 can transmit the information using predetermined templates. For instance, the CIS 112 can combine a template stating “the caller is:” with the name of the caller device 102 to create a message of “the caller is: Bob Jones.” In some embodiments, the message request can allow the receiver device 104 to create a contact having the name and phone number of the caller device 102. In other embodiments, the message request can indicate that the information only appear as a pop up from a mobile application executing on the mobile device.

[0056] The message service 128 can receive the message request to transmit the display request. The messaging service 128 can be the SMSC or the network server. Responsive to the message request, the messaging service 128 can transmit the display request to display the message on the receiver device 104. The message service 128 can transmit a display request to display the message in a mobile application or as part of a messaging service. Based on the message request, the message service 128 can allow the receiver device 104 to create a contact having the name and phone number of the caller device 102.

[0057] The flow shown in FIG. 4A involves the MSS 108 querying the HLR 110 for a presence of a flag or other indicator set by the CIS 112 indicating that the device identifier, for example the MSISDN associated with the receiver device 104, is subscribed to the caller identification service. Flowever, the CIS 112 may not always be able to set the flag for the device identifier in the HLR 110. For example, the CIS 112 may not be able to set the flag in the HLR 110 if another service has also been configured to update one or more fields of the HLR 110. In such situations, the MSS 108 will not be able to determine whether the device identifier, for example the MSISDN, associated with the receiver device 104 is a subscriber to the caller identification service.

[0058] To address the such a situation or for other reasons, the CIS 112 may analyze the network traffic of the MSS 108 of the core network processor 111 without having to rely on the MSS 108 querying HLR 110. As such, the CIS 112 may determine from the network traffic whether to identify the caller to the receiver device 104 as shown in FIG. 4B. [0059] The present disclosure further describes methods and systems for providing caller identification services, in particular, by the CIS 112 analyzing the network traffic received from the core network processor 111. According to one aspect, the method includes maintaining one or more data structures including a plurality of subscriber records corresponding to subscribers of a caller identification service. In some embodiments, the data structures can be the local database 118. In some embodiments, the plurality of subscriber records can be the local subscriber records 120. The method can also include receiving, from a network processor, responsive to a first entity initiating a call to a second entity, network traffic corresponding to the call. In some embodiments, the network processor can be the core network processor 111. In some embodiments, the first entity can be the caller device 102. In some embodiments, the second entity can be the receiver device 104. The method can also include identifying, from the network traffic, a first device identifier of the first entity and a second device identifier of the second entity. In some embodiments, the device identifiers can be MSISDNs. The method can also include determining, by performing a lookup in the one or more data structures, that the second entity associated with the second device identifier is a subscriber of the caller identification service. The method can also include identifying, using the first device identifier, an identity of the first entity via a lookup in one or more data structures. The method can also include transmitting, responsive to determining that the second entity is a subscriber and responsive to identifying the identity of the first entity, a first request to a messaging service to transmit, to the second entity, a second request to display a message including the identity of the first entity on a display of a device corresponding to the second device identifier associated with the second entity. In some embodiments, the messaging service can be the SMSC 128. In some embodiments, the method for providing caller identification services described herein can be executed by the CIS 112.

[0060] Referring now to FIG. 4B, FIG. 4B illustrates an embodiment of the flow for providing caller identification services, in particular, by the CIS 112 analyzing the network traffic received from the core network processor 111. Flow 402 depicts the caller device 102 communicating with the core 111 to place a call to the receiver device 104. At flow 405, the core network 111 transmits the network traffic comprising the communication sent by the caller device 102 to the CIS 112. At flow 407, the CIS 112 analyzes (for example parse, scan, monitor, or filter) the network traffic to determine the respective device identifiers associated with the caller device 102 and the receiver device 104. At flow 409, the CIS 112 determines the subscription status of the device identifier, for example the MSISDN of the receiver, associated with the receiver device 104. At flow 412, the CIS 112 identifies the caller associated with the device identifier associated caller device 102. At flow 414, the core 111 routes the call from the caller device 102 to the receiver device 104. At flow 416, the CIS 112 requests the SMSC 128 to display the identity of the caller on the receiver device 104. At flow 418, the SMSC displays the identity of the caller on the receiver device 104. It should be appreciated that flow 405, 407, 409, and 412 can be performed prior to, parallel to, or subsequent to flow 414. [0061] Referring more specifically to flow 407, the CIS 112 can parse the network traffic to identify the device identifier of the caller device 102 and the receiver device 104. For instance, the CIS 112 can determine the device identifiers from network packets in the network traffic. Referring more specifically to flow 409, the CIS 112 can determine the subscription status of the device identifier associated with the receiver device 104 by performing a lookup of the device identifier in the local database 118. Based on the lookup, the CIS 112 can determine whether the device identifier associated with the receiver device 104 corresponds to a local subscriber record 120. The CIS 112 can then determine the subscription status of the device identifier based on the local subscriber record 120. Referring more specifically to flow 412, the CIS 112 can identify the caller device 102 by performing a lookup of the device identifier associated with the caller device 102 in the local database 118. Based on the lookup, the CIS 112 can determine whether the device identifier associated with the caller device 102 corresponds to a local subscriber record 120. The CIS 112 can then identify the caller device 102 based on information associated with the local subscriber record 120 associated with the caller device 102.

[0062] Now referring to FIG. 4C, illustrated is a flow for subscribing a device to the caller identification services according to embodiments of the present disclosure. A receiver device 104 transmits a subscription request to the CIS 112 at flow 420, as previously described in reference to FIGs. 1A and 1 B. At flow 422, the CIS 112 generates and transmits the billing request for the receiver device 104 to subscribe to the caller identification service. The subscription request and billing request can be identical regardless of whether the CIS 112 is communicating with the core network processor 111 or the MSS 108 and the HLR 110. Flowever, if the CIS 112 is communicating with the core network processor 111 as previously described in reference to FIG. 1 B, then the CIS proceeds to flow 428. If the CIS 112 is communicating with the MSS 108 and the HLR 110 as previously described in reference to FIG. 1A, then the CIS 112 proceeds to flow 424 and flow 426. At flow 424, the CIS 112 flags the caller device 102 in the HLR 110 to route caller information to the CIS 112 responsive to the receiver device 104 receiving a call. At flow 426, the HLR 110 acknowledges the registration of the receiver device 104 to the CIS 112. At flow 428, the CIS 112 stores information corresponding to the receiver device 104 in the local database.

[0063] Now referring to FIG. 5A and FIG. 5B, illustrated is a user interface of the caller identification services according to embodiments of the present disclosure. Displaying information corresponding to the caller device 102, as previously discussed in reference to step 306, is illustrated on user devices 502a-502n (generally referred to as user device 502). The user device 502 can be any mobile device such as the receiver device 104. As similarly discussed in reference to step 306, the user device 502 can receive caller information 504a-504n (generally referred to as caller information 504). As similarly discussed in reference to step 306, the caller information 504 can indicate a name associated with the caller device 102, a device identifier such as a phone number, and an accuracy indicator indicating the accuracy of the caller information 504. As similarly discussed in reference to step 306, the caller identification service can allow the receiver device 104 to save 506a-506n (generally referred to as save 506) the caller information 504. The caller identification service can also allow the receiver device 104 to cancel 508a-508n (generally referred to as cancel 508) the caller information 504.

B. COMPUTER SYSTEM

[0064] Various operations described herein can be implemented on computer systems, which can be of generally conventional design. FIG. 6 shows a simplified block diagram of a representative server system 600 and client computer system 614 usable to implement certain embodiments of the present disclosure. In various embodiments, server system 600 or similar systems can implement services or servers described herein or portions thereof. Client computer system 614 or similar systems can implement clients described herein. The caller identification system 100 and others described herein can be similar to the server system 600.

[0065] Server system 600 can have a modular design that incorporates a number of modules 602 (e.g., blades in a blade server embodiment); while two modules 602 are shown, any number can be provided. Each module 602 can include one or more processors 604 and local storage 606.

[0066] One or more processors 604 can include a single processor, which can have one or more cores, or multiple processors. In some embodiments, one or more processors 604 can include a general-purpose primary processor as well as one or more special-purpose co-processors such as graphics processors, digital signal processors, or the like.

In some embodiments, some or all processing units 604 can be implemented using customized circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself. In other embodiments, one or more processors 604 can execute instructions stored in local storage 606. Any type of processors in any combination can be included in one or more processors 604.

[0067] Local storage 606 can 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). Storage media incorporated in local storage 606 can be fixed, removable or upgradeable as desired. Local storage 606 can be physically or logically divided into various subunits such as a system memory, a read-only memory (ROM), and a permanent storage device. The system memory can be a read-and-write memory device or a volatile read-and-write memory, such as dynamic random-access memory. The system memory can store some or all of the instructions and data that one or more processors 604 need at runtime. The ROM can store static data and instructions that are needed by one or more processors 604. The permanent storage device can be a non-volatile read-and-write memory device that can store instructions and data even when module 602 is powered down. The term “storage medium” as used herein includes any medium in which data can be stored indefinitely (subject to overwriting, electrical disturbance, power loss, or the like) and does not include carrier waves and transitory electronic signals propagating wirelessly or over wired connections.

[0068] In some embodiments, local storage 606 can 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 functions of the caller identification system 100 of FIGs. 1 A and 1 B or any other system described herein, or any other servers or system associated with the caller identification system 100 of FIGs. 1A and 1 B.

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

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

[0071] A wide area network (WAN) interface 610 can provide data communication capability between the local area network (interconnect 608) and a larger network, such as the Internet. Conventional or other activities technologies can be used, including wired (e.g., Ethernet, IEEE 802.3 standards) and/or wireless technologies (e.g., Wi-Fi, IEEE 802.11 standards).

[0072] In some embodiments, local storage 606 is intended to provide working memory for one or more processors 604, providing fast access to programs and/or data to be processed while reducing traffic on interconnect 608. Storage for larger quantities of data can be provided on the local area network by one or more mass storage subsystems 612 that can be connected to interconnect 608. Mass storage subsystem 612 can be based on magnetic, optical, semiconductor, or other data storage media. Direct attached storage, storage area networks, network-attached storage, and the like can be used. Any data stores or other collections of data described herein as being produced, consumed, or maintained by a service or server can be stored in mass storage subsystem 612. In some embodiments, additional data storage resources may be accessible via WAN interface 610 (potentially with increased latency). [0073] Server system 600 can operate in response to requests received via WAN interface 610. For example, one of modules 602 can implement a supervisory function and assign discrete tasks to other modules 602 in response to received requests. Conventional work allocation techniques can be used. As requests are processed, results can be returned to the requester via WAN interface 610. Such operation can generally be automated. Further, in some embodiments, WAN interface 610 can connect multiple server systems 600 to each other, providing scalable systems capable of managing high volumes of activity. Conventional or other techniques for managing server systems and server farms (collections of server systems that cooperate) can be used, including dynamic resource allocation and reallocation.

[0074] Server system 600 can interact with various user-owned or user-operated devices via a wide-area network such as the Internet. An example of a user-operated device is shown in FIG. 6 as client computing system 614. Client computing system 614 can be implemented, for example, as a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smart watch, eyeglasses), desktop computer, laptop computer, and so on.

[0075] For example, client computing system 614 can communicate via WAN interface 610. Client computing system 614 can include conventional computer components such as one or more processors 616, storage device 618, network interface 620, user input device 622, and user output device 624. Client computing system 614 can be a computing device implemented in a variety of form factors, such as a desktop computer, laptop computer, tablet computer, smartphone, other mobile computing device, wearable computing device, or the like.

[0076] Processor 616 and storage device 618 can be similar to one or more processors 604 and local storage 606 described above. Suitable devices can be selected based on the demands to be placed on client computing system 614; for example, client computing system 614 can be implemented as a “thin” client with limited processing capability or as a high-powered computing device. Client computing system 614 can be provisioned with program code executable by one or more processors 616 to enable various interactions with server system 600 of a message management service such as accessing messages, performing actions on messages, and other interactions described above. Some client computing systems 614 can also interact with a messaging service independently of the message management service.

[0077] Network interface 620 can provide a connection to a wide area network (e.g., the Internet) to which WAN interface 610 of server system 600 is also connected. In various embodiments, network interface 620 can 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.). [0078] User input device 622 can include any device (or devices) via which a user can provide signals to client computing system 614; client computing system 614 can interpret the signals as indicative of particular user requests or data. In various embodiments, user input device 622 can include any or all of a keyboard, touch pad, touch screen, mouse or other pointing device, scroll wheel, click wheel, dial, button, switch, keypad, microphone, and so on.

[0079] User output device 624 can include any device via which client computing system 614 can provide data to a user. For example, user output device 624 can include a display to display images generated by or delivered to client computing system 614. The display can incorporate various image generation technologies, e.g., a liquid crystal display (LCD), light-emitting diode (LED) including organic light-emitting diodes (OLED), projection system, cathode ray tube (CRT), or the like, together with supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors, or the like). Some embodiments can include a device such as a touchscreen that function as both input and output device. In some embodiments, other user output devices 624 can be provided in addition to or instead of a display. Examples include indicator lights, speakers, tactile “display” devices, printers, and so on.

[0080] Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a computer readable storage medium. Many of the features described in this specification can be implemented as processes that are specified 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 operation indicated in the program instructions. Examples of program instructions or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter. Through suitable programming, one or more processors 604 and 616 can provide various functionality for server system 600 and client computing system 614, including any of the functionality described herein as being performed by a server or client, or other functionality associated with message management services.

[0081] It will be appreciated that server system 600 and client computing system 614 are illustrative and that variations and modifications are possible. Computer systems used in connection with embodiments of the present disclosure can have other capabilities not specifically described here. Further, while server system 600 and client computing system 614 are described with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. For instance, different blocks can be but need not be located in the same facility, in the same server rack, or on the same motherboard. Further, the blocks need not correspond to physically distinct components. Blocks can be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks might or might not be reconfigurable depending on how the initial configuration is obtained. Embodiments of the present disclosure can be realized in a variety of apparatus including electronic devices implemented using any combination of circuitry and software.

[0082] While the disclosure has been described with respect to specific embodiments, one skilled in the art will recognize that numerous modifications are possible. For instance, although specific examples of rules (including triggering conditions and/or resulting actions) and processes for generating suggested rules are described, other rules and processes can be implemented. Embodiments of the disclosure can be realized using a variety of computer systems and communication technologies including but not limited to specific examples described herein.

[0083] Embodiments of the present disclosure can be realized using any combination of dedicated components and/or programmable processors and/or other programmable devices. The various processes described herein can 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 can be accomplished, e.g., by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Further, while the embodiments described above may make reference to specific hardware and software components, those skilled in the art will appreciate that different combinations of hardware and/or software components may also be used and that particular operations described as being implemented in hardware might also be implemented in software or vice versa.

[0084] Computer programs incorporating various features of the present disclosure may be encoded and stored on various computer readable storage media; suitable media include magnetic disk or tape, optical storage media such as compact disk (CD) or DVD (digital versatile disk), flash memory, and other non-transitory media. 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 electronic devices (e.g., via Internet download or as a separately packaged computer- readable storage medium).

[0085] Thus, although the disclosure has been described with respect to specific embodiments, it will be appreciated that the disclosure is intended to cover all modifications and equivalents within the scope of the following claims.