GB2581266A - Improved gateway system and method - Google Patents

Abstract

A mobile communication gateway system 1 and a method of operating a mobile communication gateway system 1 is disclosed. A database 11 stores Subscriber records holding values of attributes in association with a unique MSISDN. A unique binary lookup key is also associated with each Subscriber record, the key being generated by applying an MSISDN-to-binary conversion function. In response to receiving a request containing an MSISDN, the conversion function is applied to determine the appropriate binary lookup key. The database 11 is queried with the key to retrieve a value of an attribute from a Subscriber record, and a requested operation is executed in dependence on the value of the retrieved attribute.

Description

Improved gateway system and method

Field of the invention

The invention generally relates to a gateway system, and methods relating to the operation of such a gateway system. More particularly, the invention relates to a mobile communication gateway system that is suitable for handling Short Message Service (SMS) message data

Background to the invention

A mobile communication gateway system acts as an intermediary between service providers and mobile subscribers. Service providers that use the gateway system to provide services to mobile subscribers are thus typically referred to herein as gateway users.

The gateway system can typically carry out a variety of different operations on behalf of those gateway users. The gateway system typically receives a request from a gateway user device to carry out an operation together with an MSISDN (Mobile Station International Subscriber Directory Number) which uniquely references a corresponding mobile subscriber device which would typically be the subject of the request.

One example operation is the distribution of digital content, such as the bulk transmission of SMS message data. In response to a request from a gateway user device, the gateway system is able transmit SMS message data from a messaging interface of the gateway system. This is transmitted via a Mobile Network Operator (MNO)-controlled Short Message Service Centre (SMSC) to a potentially large number of mobile subscriber devices. SMS message data is routed to an appropriate mobile subscriber device by referencing the corresponding MSISDN.

Another operation may be billing MNO-controlled mobile subscriber accounts for the provision of premium or value-added services. Again, a request from the gateway user necessarily includes the MSISDN which is passed to an MNO system along with parameters such as a value to be billed.

A further operation involves looking up information, such as Home Location Register (HLR) data, that is useful in determining whether a mobile subscriber device is active and connected to a network.

The gateway system also handles information and requests that originate from mobile subscriber devices which may have a subsequent influence on requests originating from gateway users. For example, the gateway system may handle a SMS message originating from a mobile subscriber device that indicates a mobile subscriber's preferences to opt into or out from communications or services run by gateway users.

Additionally, settings data corresponding to the capabilities of the mobile device may be received by the gateway system from mobile subscriber devices, and this settings data can be processed in a way that controls subsequent actions taken by the gateway system on behalf of gateway users.

Accordingly, a gateway system does not act as a simple relay between gateway users and mobile subscribers. Requests to perform operations are subject to certain conditions, such as the status or settings of a device associated with an MSISDN. As mentioned, a condition could be whether a mobile subscriber associated with an MSISDN has registered a preference to opt into or out from SMS communications, for example.

Accordingly, requested operations need to be controlled in dependence on those conditions. These conditions are stored in a database of the gateway system within a Subscriber record, and the MSISDN is used as a key to access a relevant Subscriber record. The values of attributes of a Subscriber record, which typically represent those conditions, are thus used to control whether and how a requested operation is executed.

Some gateway systems currently receive operation requests in respect of thousands of MSISDNs per second, and this is set to increase as more mobile subscriber accounts and MSISDNs are created to meet demand. Thus, a significant bottleneck experienced by gateway systems relates to the querying of the database to retrieve such attribute values.

It is against this background that the present invention has been conceived.

Summary of the invention

According to a first aspect of the present invention there is provided a gateway system as set out in Claim 1.

In other aspects and embodiments of the present invention, the gateway system may be a mobile communication gateway system, and may be a system that is suitable for handling SMS message data. The system may comprise at least one of: an MNO interface (such as a messaging interface), a gateway user interface and a database. The messaging interface may be suitable for communicating with MNO-controlled systems, such as a Short Message Service Centre (SMSC) and may be arranged to transmit and/or receive SMS message data, via the Short Message Service Centre (SMSC) of a mobile network operator (MNO), to and/or from mobile subscriber devices of a mobile network.

As discussed, each mobile subscriber device may be allocated with a unique MSISDN (Mobile Station International Subscriber Directory Number) and the gateway user interface may be arranged to receive requests from, and/or transmit responses to gateway user devices. The database of the gateway system may store Subscriber records, and the Subscriber records ideally hold values of attributes (e.g. such as "settings" data of a mobile subscriber device, or registered preferences of a Subscriber) in association with a corresponding MSISDN.

Advantageously, each Subscriber record may have a unique binary lookup key, and this is ideally pre-generated from the MSISDN associated with that Subscriber record. Binary look-up key generation is ideally performed by applying an MSISDN-to-binary conversion function. Advantageously, by utilising a unique binary lookup key, the efficiency with which an MSISDN can be stored and retrieved is improved.

In existing gateway systems, MSISDNs are stored as strings -which have a high storage, retrieval and processing burden. However, it is considered to be important to use such a format so as to preserve leading zeros frequently present in MSISDNs. For example, an MSISDN starting with "0044..." stored in a numerical format (e.g. integer) rather than a string format will be stored and indistinguishable from a MSISDNs starting "44..." or "044...". This problem is particularly exacerbated as MSISDNs do not have a predetermined length, and so leading zeros cannot be reliably restored after a loss caused by a straightforward translation of a string to a standard numerical format.

However, the MSISDN-to-binary conversion function disclosed herein can reliably generate a unique binary lookup key that advantageously preserves leading zero digits present in the MSISDN input to the function.

Preferably, the MSISDN-to-binary conversion function comprises at least one of: * determining a prefix portion, and a suffix portion of an MSISDN; * querying a prefix index table with the prefix portion of the MSISDN to retrieve from it a predetermined prefix binary code that is associated with the prefix portion of the MSISDN; * transforming the suffix portion of the MSISDN into a suffix binary code by applying a suffix transformation function; and * appending the suffix binary code to the prefix binary code to generate the binary lookup key for the Subscriber record.

The use of a prefix index table is particularly useful for a database containing MSISDNs because the start of an MSISDN is generally representative of a country code, and carrier-specific code. Accordingly, it has been recognised that large sets of MSISDNs in the database have prefix portions identical to one another, and this represents a statistical redundancy that can be eliminated to reduce the size of the dataset being stored.

In principle, the vast majority of MSISDNs can be stored within the database in a truncated format, i.e. with the prefix portions removed, and simply accessed via the relevant prefix index. Additionally, this can also improve the look-up speed of data associated with those MSISDNs, in terms of minimised data-access contention, and improved support for parallelism. The database entries can be categorised according to the MSISDN prefix portion, and compartmentalised within a region of the database table (or other suitable data structure) that is dedicated to that particular MSISDN. Of particular benefit is storing MSISDNs within a component (data structure or hardware), that allows access of the data within it substantially independently and simultaneously to other components dedicated to other MSISDN prefix portions. Parallel access and processing of such data can thus be achieved.

In more general terms, the MSISDN-to-binary conversion function may comprise applying a transformation function to at least a portion of an MSISDN to convert it into a corresponding binary code. The MSISDN-to-binary conversion function may also (or instead) comprise querying a lookup table with at least a portion of an MSISDN to retrieve from it a corresponding binary code. These methods may be used independently, or in combination with one another, for example with different portions of the MSISDN. Nonetheless, it is useful for any conversion and/or transformation function to be ideally arranged to preserve leading zero digits of the MSISDN or portion thereof Preferably, the prefix index table is prepopulated with the most frequently-occurring MSISDN prefix portions of the database. Ideally, each MSISDN prefix portion is associated with a corresponding unique prefix binary code.

Preferably, the system is arranged to receive a request and, in response, query the database to retrieve an attribute held therein, and then execute an operation in dependence on the value of the retrieved attribute. The request may be received via the gateway user interface and/or the messaging interface.

Ideally, the system is arranged to receive a request, via the gateway user interface, from a gateway user device, the request comprising at least one of: * authentication information for authenticating the gateway user device; * an MSISDN; and * an operation to be executed by the gateway system that is controlled by a value of a control attribute of a Subscriber record stored within the database.

In response to receiving a/the request, the system is arranged to: * determine, from the data included in the request, an appropriate binary lookup key, for example by applying the MSISDN-to-binary conversion function to an MSISDN included in the request; * query the database with the determined binary lookup key to retrieve, from a corresponding Subscriber record, the value of a control attribute for controlling the execution of the operation; and * executing the operation contained within the request in dependence on the value of the attribute retrieved.

Preferably, a/the request comprises at least one of: * a "transmit SMS" operation; * SMS message data to be transmitted to the mobile subscriber device associated with the MSISDN of the request; * a "bill user" operation; * a value to be charged to an MNO-controlled account associated with the MSISDN of the request; * "Home Location Register (HLR) data lookup" operation; and * a cache recency threshold.

Preferably, a/the controlling attribute comprises at least one of: * an "OPT-IN/OUT" attribute for signifying whether or not a Subscriber has registered a request to block SMS messages, and ideally: o an "OPT-OUT" value of that control attribute prevents onward transmission by the system of SMS message data via the messaging interface; and/or o an "OPT-IN" value of that control attribute causes the system to transmit said SMS message data from the messaging interface to the mobile subscriber device allocated that MSISDN via an SMSC; * a "blacklist" attribute for signifying whether or not a Subscriber has registered a request to permanently block charged services, and ideally: o a "blacklisted" value of that control attribute prevents transmission by the system of a "bill user" command; and/or a a "non-blacklisted" value of that control attribute causes the system to transmit a "bill user" command, optionally together with a value to be charged, to an MNO-controlled account associated with the MSISDN of the request; * a "cache updated" attribute for signifying how recently HLR data has been cached within the database by the system, and ideally: o the system is arranged to respond to the requesting gateway user device with cached HLR data (such as device connection status and/or IMEI data) from the respective Subscriber record if the value of the "cache updated" attribute is more recent than that specified by a cache recency threshold; or otherwise: o the system is arranged to communicate via the messaging interface with an MNO-controlled HLR to acquire the HLR data for caching within the database and transmission in a response back to the requesting gateway user device.

Preferably, the system is arranged to respond to the requesting gateway user device with a notification to indicate: * the value of the controlling attribute; and/or * whether an attempt to execute an operation (e.g. transmit SMS message data, bill user) was made by the system.

Preferably, each unique prefix binary code of the prefix index table is stored as a binary value B bits in length, and the prefix index table has 28 records. Ideally B = 8.

Advantageously, the prefix index table is thus fully-populated to make full and efficient use of it. Optimally, the prefix index table has exactly 256 records and 256 unique prefix binary codes that are each 8 bits in length.

Preferably, the prefix index table is populated by analysing the database to select and populate the prefix index table with the most frequently-occurring MSISDN prefix portions.

Preferably, the most frequently-occurring MSISDN prefix portions are selected from a filtered list, filtered in dependence on the value of a selected attribute. For example, the filtered list filters out old Subscriber records having the value of a selected fimestamp attribute that is older than a predetermined threshold.

Advantageously, this ensures that the prefix index table is populated with relevant data, such as those relating to Subscriber records that have been most recently entered into, updated, or retrieved from the database. Assisfive to this, the database may comprise a traffic log. Moreover, the system may maintain a traffic log of communications with: * its gateway user interface (such as requests from gateway user devices); and/or * its messaging interface, (such as SMS message instructions from mobile subscriber devices).

Furthermore, the traffic log may comprise a log timestamp of the occurrence of a communication having an MSISDN associated with it. Advantageously, this can be used to determine MSISDNs (or portions thereof) that have most recently been entered into, updated, or retrieved from the traffic log of the database. Thus, the prefix table may be populated by analysing the traffic log -specifically, to select and populate the prefix index table with the most frequently-occurring MSISDN prefix portions in those communications that occur within a predetermined time period by reference to each respective log timestamps.

Preferably, the MSISDN-to-binary conversion function comprises determining the prefix and suffix portion by splitting the MSISDN of a total length t digits into two, with a first p digits forming the prefix portion, and the last t -p digits forming the suffix portion.

Preferably, the value of p is predetermined to match the size of the longest prefix portion held by the prefix index table. Advantageously, this can improve the speed at which the prefix index table can be queried.

If querying the prefix index table with the prefix portion of the MSISDN of length p yields no matches, then it is preferable to iteratively decrement the value of p, re-split the

S

MSISDN and requery the prefix index table with a progressively shorter prefix portion until a match is found and so a prefix binary code can be retrieved.

Advantageously, this allows the prefix index table to be queried in a way that allows the table to store variable-length MSISDN prefix portions but, during a querying operation, prevents accidental matching with a shorter prefix portion when a longer prefix portion exists.

The use of variable-length prefix portions in the prefix index table can be useful from the perspective of maximising the benefits of parallelism, or categorised storage of MSISDN data. To achieve these benefits, it is generally desirable to spread the total number of Subscriber records across multiple categories relatively evenly. This increases the chance that look-ups can be carried out simultaneously, with each MSISDN lookup being served by a different component. It has been empirically determined that, for databases that store MSISDN data, this is best achieved by choosing prefix portions that aren't necessarily the same length as one another. For example, a prefix could be three digits in length (e.g. 009), or longer (e.g. 004478).

It is posited that this because there are likely to be in any given MSISDN database a relatively high frequency of MSISDNs that start with the same digits. This stems from common prefix portion being associated with a particular country code (e.g. 0044 for the UK, 001 for the US), and also subsequent mobile operator codes. It is therefore beneficial to use variable length prefix portions to get a more even spread of records across the index, and also to increase the utilisation of the records of the prefix index.

It should be noted that the shorter the prefix, the greater the number of MSISDNs that have that prefix in common, and so proportionally more of the MSISDNs of the database can be stored in a truncated format. However, the shorter the prefix, the longer the suffix will be (i.e. the part of the MSISDN that is left after truncation), and so this will take up relatively more space to store.

It has been empirically determined that using an 8-bit binary prefix index, referencing the 254 most frequently-occurring variable-length prefix portions yields an optimal trade-off in terms of prefix-to-suffix length.

Preferably, the suffix transformation function comprises generating an intermediate representation of the suffix portion of the MSISDN. Ideally, the intermediate representation is then transformed into the suffix binary code.

During generation of the intermediate representation of the suffix portion of the MSISDN, leading zero digits of the suffix portion of the MSISDN may be replaced by a replacement character different from the character set from which the MSISDN is normally composed. Whilst they may be stored as a string, MSISDNs are generally composed exclusively of a decimal character set (i.e. from 0 to 9). Accordingly, the replacement character may be a different character such as "a".

Preferably, the position of the replacement character within the intermediate representation is chosen in dependence on the number of leading zero digits. Advantageously, this can reduce the space needed to store the intermediate representation, and moreover the suffix binary code from which the intermediate representation is generated. The existence of a replacement character indicates that leading zeros are present, and the position of the replacement character indicates the number of leading zeros. Thus, the total number of digits required to encode the intermediate representation can be reduced more so than, for example, a naive replacement of leading zero characters with a corresponding number of replacement characters. Two or more leading zeros can be substituted with a single replacement character.

The replacement character may be inserted into the intermediate representation at the nth significant digit, n being the number of leading zeros replaced by the replacement character.

Advantageously, this is more storage-efficient than a naive substitution of the leading zeros with a replacement character at the most significant digit end of the suffix portion; such a naive substitution results in the intermediate representation being a larger number requiring an increased number of bits to store the suffix binary code subsequently generated. To this end, it should be noted that insertion of the replacement character is relative to the least significant digit. In other words, the 1st significant digit is the least significant digit. Furthermore, insertion of the replacement character ideally does not overwrite any pre-existing digits, but rather the pre-existing digits are shifted in position. By way of example, if the suffix portion of the MSISDN is "0001234", then the number of leading zeros is three. Accordingly, a replacement character "a" can be inserted at the third position from the right-hand, least significant digit to generate the intermediate representation of "12a34".

Preferably, the replacement character together with the decimal character set together defines a base 11 character set, and the suffix transformation function further comprises converting the intermediate representation from base 11 into base 2, thereby to generate the binary suffix code.

Naturally, the invention extends in a second aspect to a method. In particular, the second aspect may provide a computer-implemented method of operating a mobile communication gateway system suitable for handling Short Message Service (SMS) message data.

It will be understood that features and advantages of different aspects of the present invention may be combined or substituted with one another where context allows. For example, the functions or processes carried out by components associated with the first aspect of the invention may be part of the method according to the second aspect.

For example, the method of the second aspect may comprise at least one of: o storing, in a database of a gateway system, Subscriber records holding values of attributes in association with a unique MSISDN; o determining a prefix portion, and a suffix portion of each MSISDN; o generating a prefix index table populated with the most frequently-occurring MSISDN prefix portions of the database, with each MSISDN prefix portion being associated with a corresponding unique prefix binary code; o generating, from the MSISDN associated with each Subscriber record, a unique binary lookup key for association with that Subscriber record, the unique binary lookup key being generated by applying an MSISDN-to-binary conversion function comprising: * determining a prefix portion, and a suffix portion of an MSISDN; * querying the prefix index table with the prefix portion of the MSISDN to retrieve from it a predetermined prefix binary code that is associated with the prefix portion of the MSISDN; * transforming the suffix portion of the MSISDN into a suffix binary code by applying a suffix transformation function, leading zero digits of the suffix portion of the MSISDN being preserved by said suffix transformation function; and * appending the suffix binary code to the prefix binary code to generate the binary lookup key for the Subscriber record; o receiving a request, via a gateway user interface of the gateway system from a gateway user device, the request comprising: * authentication information for authenticating the gateway user device; * an MSISDN, and * an operation to be executed by the mobile communication gateway system that is controlled by a value of a control attribute of a Subscriber record stored within the database; and o in response to receiving the request: * determining, from the MSISDN included in the request, an appropriate binary lookup key by applying the MSISDN-to-binary conversion function; * querying the database with the determined binary lookup key to retrieve, from a corresponding Subscriber record, the value of the control attribute for controlling the requested execution of the operation; and * executing the operation contained within the request in dependence on the value of the attribute retrieved.

Furthermore, features of the first or second aspect may themselves constitute further aspects of the present invention. For example, the features, structure and/or processing of the database, the user gateway interface, and/or messaging interface may themselves constitute further aspects of the present invention.

Additionally, further aspects of the present invention may reside in a method according to the second aspect, carried out by at least one computing device. Still further aspects of the present invention may reside in a computer program product comprising instructions which, when the program is executed by a processor of a computing system, causes the computing system to carry out the method of the second aspect of the present invention.

Still further aspects of the present invention may reside in a computer-readable storage medium comprising instructions which, when executed by a computing system, cause the computing system to carry out the method of the second aspect of the present invention.

Brief description of the drawings

In order for the invention to be more readily understood, embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic view of the mobile communication gateway system according to various embodiments of the present invention, the gateway system being shown in conjunction with other devices and system that are external to it, but with which the gateway system interacts; Figure 2 is a flow diagram of a process utilised by the system of Figure 1 to generate an example 8-bit prefix index table; Figure 3 is a representative example of the 8-bit prefix index table generated by the process of Figure 2; Figure 4 is an illustrative example of a Subscriber record in an optimised database of the system of Figure 1; and Figure 5 is a flow diagram of an example MSISDN-to-binary conversion function utilised by the system of Figure 1.

Specific description of the preferred embodiments

System overview Figure 1 is a schematic view of the mobile communication gateway system 1 according to a first embodiment of the present invention, that is suitable for handling Short Message Service (SMS) message data. The gateway system 1 comprising a system processor 10, a database 11, a gateway user interface 12, and a Mobile Network Operator (MNO) interface in the form of a messaging interface 13. As also shown in Figure 1, the mobile communication gateway system 1 is configured and arranged to interact with a number of other external devices, typically via a communications network such as the Internet. Notably, these include gateway user devices 20, 21, 22, 23, MNO systems such as an SMSC 30 and Home Location Register 31, and mobile subscriber devices 40, 41, 42, 43, 44.

Functionally, the gateway user interface 12 of the gateway system 1 is arranged to communicate with many different gateway user devices 20, 21, 22, 23 and moreover is configured to receive requests from, and transmit responses each of the gateway user devices 20, 21, 22, 23. Requests and responses typically relate to operations that are carried out on behalf of the gateway users.

The messaging interface 13 of the gateway system 1 is configured to transmit information to a Short Message Service Centre (SMSC) of an MNO. For example, such information may include SMS message data that is intended to terminate at mobile subscriber devices 40, 41, 42, 43. Naturally, the messaging interface is also configured to receive information via the SMSC which has originated from mobile subscriber devices.

The mobile communication gateway system 1 is able to communicatively interact with other MNO components, such as a Home Location Register (HLR), either via the SMSC, or directly.

It will be appreciated that Figure 1 provides a functional view of the mobile communication gateway system 1, and this may be implemented in many different ways known in the art. In particular, the functionality of the gateway system 1 may be achieved through various combinations of hardware and components.

For example, the gateway user interface 12 is not necessarily a single server which receives requests from/responds to gateway user devices 20-23. In preferred embodiments, the gateway user interface 20 may be embodied by a set of servers. Moreover, each server may be arranged to receive, process and respond to a different type of request. For example, an HLR lookup server, acting as the gateway user interface 12 of the gateway system 1, may be configured to exclusively receive and respond to requests relating to HLR data lookups. Similarly, a bulk SMS server, acting as the gateway user interface 12, may be configured to exclusively receive and respond to requests relating to bulk SMS transmission. It should be understood that with such an arrangement, each server that is dedicated to a given operation may be remotely accessed by a gateway user device 20-23 via an address or URL that is distinguished from another server. Thus a request received by that server implicitly includes the operation to be executed by that server. In alternatives, if the system centrally receives requests from gateway user devices, then the operation to be carried out may be specified explicitly in the request (rather than implicitly via the use of a specific URL).

It should also be noted that the data storage and processing capabilities of the gateway system 1, represented in Figure 1 by the database 11 and system processor 10 respectively, may not necessarily relate to a singular database or processing unit. Rather, this could encompass a set of databases and processors, each dedicated to a particular set of operations, and synchronised with one another (if and where necessary) to ensure processing and data integrity and validity. Furthermore, it will be understood that where the gateway system 1 as referred to herein as performing an operation, this is typically executed or otherwise controlled by the system processor 10. Furthermore, the gateway system 1 may also include, for the avoidance of doubt, at least one computer-readable storage medium comprising instructions that are carried out by the system processor 10 to perform the functions described herein.

As discussed, the gateway system 1 acts as an intermediary between gateway user systems (of service providers) and mobile subscriber devices (typically of end-users), and can carry out requests pertaining, for example, to the distribution or aggregation of digital content. These services are provided with reference to a mobile subscriber's unique MSISDN (Mobile Station International Subscriber Directory Number). Each mobile subscriber device 40-44 is allocated with a unique MSISDN, and content is routed to the mobile subscriber device by addressing that MSISDN. Alternatively, content originating from a mobile device can be processed and aggregated with reference to that MSISDN.

As already discussed, the operations that the gateway system 1 can carry out may include the bulk transmission of SMS message data, billing MNO-controlled mobile subscriber accounts for the provision of premium services, and looking up information, such as Home Location Register (HLR) data. However, the gateway system 1 does not act as a simple relay between gateway user systems 2 and mobile subscriber devices 4.

Requests to perform operations are subject to conditions, such as the status and settings of a device associated with an MSISDN. For example, if the device associated with an MSISDN has a status whereby it is incapable of receiving a message via SMS, then it would be wasteful to attempt to transmit a such message.

These conditions are stored in the database 11 of the gateway system 1, and are retrieved and used to control a particular operation relating to a particular MSISDN. More particularly, an MSISDN is used as a key to access a relevant mobile Subscriber record within the database, and so the values of attributes of a Subscriber record. The values of these attributes typically represent the conditions that are used to control whether and how an operation is executed. Such attributes can thus be defined as control attributes.

System optimisation In the present embodiments, the manner in which the gateway system 1 is configured and arranged is optimised, primarily to maximise the efficiency with which the gateway system 1 is able to carry out such operations, and also to minimise storage, processing and bandwidth wastage. This configuration and arrangement primarily relates to how data is stored, updated and retrieved from the database 11.

Prior to optimisation, a database of the gateway system nominally contains MSISDNs that are stored within the database in string format. Other information (such as settings data) associated with that MSISDN is stored in a record alongside the MSISDN value, and, the MSISDN value is used as a primary key in a query to retrieve the settings data relevant to a mobile device that is associated with an MSISDN. The string format in which the MSISDN data is stored has previously been considered to be essential as it capable of retaining properties of variable-length MSISDN values that would otherwise be lost. For example, leading zeros are lost when such MSISDN values are stored in other numerical format such as binary or integer formats. (e.g. the string "07801576933" would be erroneously truncated to the integer "7801576933").

However, it has been recognised that there are speed and storage drawbacks with the string format. Storage utilisation is relatively high -usually a minimum of 1 byte per MSISDN digit, and sometimes more depending on the string encoding convention of a particular database -and also the processing burden of querying a string is higher.

Embodiments of the present invention attempt to address these issues by storing MSISDNs entries in a compressed format, to cut down the size of each record, and allow for smaller index files so they are more likely to fit in memory. It has been determined that MSISDNs can be stored in approximately a third of the original space occupied prior to optimisation.

Part of the optimisation involves converting the MSISDN into a binary code, which leads to more efficient storage, and also more efficient querying of the database when using that binary code as a primary binary lookup key.

Moreover, it has been recognised that a conversion that handles a prefix portion and a suffix portion of an MSISDN independently yields better results than other methods. This is likely to be due to statistical redundancies prevalent with a large set of MSISDNs, and in particular relating to the phenomenon that there is comparatively less variation at the start of a MSISDN than at the end. The starting prefix portion of an MSISDN tends to be restricted by a country and carrier codes, whereas the end suffix portion of an MSISDN is not normally restricted, and is typically random.

This is exploited through the generation and use of a prefix index table. This allows for an optimised handling of the prefix portion of an MSISDN.

The generation of a prefix index table, will now be described with reference to Figure 2 which is a flow diagram of the steps needed to generate an example 8-bit prefix index table: The database 11 is analysed to determine MSISDN prefix portions (i.e. the first few numbers of the MSISDN) which are the most frequently-occurring. When determining the most frequently-occurring MSISDN prefix portions, the database records are ideally first filtered based on the value of a timestamp attribute to include only those that have been updated recently -for example, within the last month.

In preferred embodiments, the 255 most frequently-occurring MSISDN prefix portions are determined. An 8-bit prefix index table is then generated, and each of those 255 prefix portions are stored against a corresponding (and unique) prefix binary code. There is a 1:1 mapping between a MSISDN prefix portion and a prefix binary code.

More specifically, the 8-bit prefix index table has 256 records in it, with a prefix binary code column ranging from 00000000 to 11111111. 255 entries of the prefix binary code column (e.g. from 00000000 to 11111110) are stored alongside those 255 MSISDN prefix portions determined to be the most frequently-occurring. A 256th part of the index (e.g. 11111111) is the exception -and is representative of MSISDNs that do not have a prefix portion that matches any of the 255 most frequently-occurring.

An representative example of the 8-bit prefix index table is shown in Figure 3.

As mentioned, the database will typically have a timestamp attribute which indicates when a record, or part thereof, was last updated, and this can be used as the basis for filtering records. Accordingly, the generation of the prefix index table may be carried out periodically to ensure that the database optimisation strategy in general is relevant to the most recent set of data stored in the database.

To aid the periodic generation of a relevant prefix index table, the system may maintain a traffic log that is updated in response to communications of the system that concern Subscriber records. Specifically, the traffic log may have a log fimestamp of a communication having an MSISDN associated with it. Communications include those received at the gateway user interface such as requests from gateway user devices, and also those received at the messaging interface (such as SMS message instructions from mobile subscriber devices).

Whenever such a communication takes place, a log timestamp value alongside the corresponding MSISDN is updated to reflect the time at which that communication took place. This can be fed back to filter a list of MSISDNs during prefix index table generation.

The prefix index table notionally allows the prefix portion of the vast majority of MSISDNs to be replaced with a binary code which can be stored and queried more efficiently than a string. This can reduce the size of the database, and also improves look-up speed of data associated with those MSISDNs, in terms of minimised data-access contention, and improved support for parallelism.

For example, the MSISDN records can be spread across multiple end tables (e.g. up to 256 end tables for an 8-bit prefix index table), with each end table corresponding a different MSISDN prefix portion. Thus, each end table may be compartmentalised within a region of the database (or other suitable data structure) that is dedicated to that particular MSISDN prefix portion. Of particular benefit is storing MSISDNs within a component (data structure or hardware), that allows access of the data within it substantially independently and simultaneously to other components dedicated to other MSISDN prefix portions. Parallel access and processing of such data can thus be achieved.

To maximise the benefit of this categorised storage of MSISDN records, it is generally desirable to spread the total number of entries across multiple end tables relatively evenly. This increases the chance that look-ups can be carried out simultaneously, with each MSISDN record lookup leading to a different end table, and so being served by a different component. It has been empirically determined that this is best achieved by the use of MSISDN prefix portions that aren't necessarily the same length as one another. For example, a prefix portion could be three digits in length (009), or longer (004478). It is suggested that this because there are likely to be, in any given MSISDN database, a very high frequency of MSISDNs having a common prefix portion -e.g. associated with a country code (e.g. 0044 for the UK, 001 for the US), and also subsequent mobile operator codes. It is therefore beneficial to use variable length prefix portions to get a more even spread of entries across the 256 records of an 8-bit prefix index table, and also to increase the utilisation of each of the 256 entries of the prefix index table.

It should further be noted that the shorter the prefix portion, the greater the number of MSISDNs that have that prefix in common, and so proportionally more of the MSISDNs of the database can be stored in a "truncated" format. However, the shorter the prefix, the longer the suffix portion will be (i.e. the part of the MSISDN that is left after truncation), and so this will take up relatively more space to store. It has been empirically determined that using an 8-bit binary prefix index, referencing the 255 (+1 exception) most frequently- occurring variable-length prefix portions yields an optimal trade-off in terms of prefix-to-suffix length.

Another part of the optimisation concerns the handling of the suffix portion of an MSISDN, and in particular transforming the suffix portion of the MSISDN into a suffix binary code.

One issue is that suffixes cannot be translated directly from the original string format into binary format. One reason for this is that different types of databases store binary formats in different way, and many exhibit a problem wherein leading zeros cannot be reliably represented in binary. For example, numbers "0016" and "16" are both be represented in binary as "10000" -there is no way of distinguishing which format should be used when translating back from binary to numerical/string format.

One way to solve this problem is to simply continue to store the MSISDNs in a data structure which preserves the leading zero notation -for example, the original string. However, as before, this is wasteful of storage space, and increases the time and processing overhead of looking up an entry in the database.

A better way to store this data had been determined that translates the MSISDN suffix portions into a binary form in a way that preserves the leading zero, and also minimises the space required to store the data. This is achieved by applying a suffix transformation function: The suffix portion of the MSISDN is checked to first determine if it contains any leading zeros. If not, then the value of the suffix portion of the MSISDN can be converted to a corresponding binary code.

If leading zeros are present, then an intermediate representation of the suffix portion of the MSISDN is generated prior to conversion into base 2/binary. The intermediate representation used utilises the base 11 number system. For the avoidance of doubt, the standard decimalised version of an MSISDN utilises base 10, and so ten digits (0-9) are used to represent a standard MSISDN. Base 11 has the same digits (0-9) as base 10, plus an extra character (a). This can be used as a replacement digit to denote the leading zeros, and moreover that replacement character won't be stripped out during a conversion to binary.

The simplest (and naive) way to do this would be to convert at least the first zero of the suffix portion of the MSISDN into "a". However, this would mean that the intermediate representation of the suffix portion of the MSISDN would take on a large value which, in turn, would increase the number of bits to store that value following subsequent conversion to base 2/binary.

To counteract this, the preferred embodiments generate the intermediate representation of the suffix portion of the MSISDN using a more sophisticated method whereby the position of the replacement character (a) tends towards the least significant digit of the intermediate representation, and moreover, the positon is controlled in dependence on the number of leading zeros. Specifically, the replacement character (a) is inserted at a position that is as many digits from the least significant digit (on the right), as there are leading zeros. So, for example, 046573 would become 46573a, and 00046573 would become 465a73.

Thereafter, the intermediate representation of the suffix portion of the MSISDN can then be converted from a base 11 character set into base 2 to generate the suffix binary code.

It should be noted that, for consistency of conversion back and forth between base 2 and base 10 values, if the suffix portion of the MSISDN does not contain any leading zeros, then the value of the suffix portion of the MSISDN may need to be converted from base 10 to base 11, and then to base 2 to generate a corresponding suffix binary code.

The suffix binary code may thus be appended to the prefix binary code such that each MSISDN record can have associated with it, in an optimised version of the database, a unique and pre-generated binary lookup key. This can be used as a primary key to efficiently query the database.

An illustrative example of a Subscriber record in the optimised database is shown in Figure 4, with the binary lookup key in the first column. The corresponding MSISDN is shown in the second column by way of illustration. MSISDNs do not necessarily need to be stored in the database, as it is possible to derive them by applying a binary-to-MSISDN conversion function which is effectively the reverse operation of the MSISDN-to-binary conversion function. This generally involves: * splitting the binary lookup key into a prefix binary code, and a suffix binary code.

This is relatively straightforward as the length of the prefix binary code matches the predetermined size of the prefix index table (i.e. 8 bits in the present embodiment); * use the prefix binary code to retrieve the corresponding prefix portion of the MSISDN (base 10 character set) from the prefix index table; * apply a reverse suffix transformation function to the suffix binary code to obtain the suffix portion of the MSISDN, in particular: o convert the suffix binary code from base 2 to base 11; o determine if there is a replacement character (i.e. "a") within the base 11 value, and its position relative to the least significant digit -position 1 being at the least significant digit. Thereafter, remove the replacement character from this value, and add the same number of leading zeros at the start of the value to correspond to that position. If no replacement character exists within the base 11 representation, simply convert to base 10; and o output suffix portion of MSISDN (base 10 character set, but handled as a string to preserve leading zeros); * concatenate the prefix and suffix portions of the MSISDN thereby to output the MSISDN value.

Referring back to Figure 4, in the present embodiment, the original MSISDN values, having the base 10 character set, can simply be stored alongside the binary lookup key.

However, the original MSISDN values are not used as a key to retrieve data from the table as the use of the binary lookup key is far superior.

It should be noted that, depending on the architecture and implementation of the database system, the binary lookup key may not necessarily be stored as shown in Figure 4 (i.e. with the prefix binary code, and the suffix binary code explicitly concatenated). Rather the prefix binary code, and the suffix binary code may be stored independently, in separate columns in the table, or even in different tables. Moreover, in some implementations, the prefix binary code, held in one table may address a relevant end table of the database (which can then be queried using only the suffix binary code).

Nonetheless, both prefix and suffix binary codes are required to identify a unique record, and so the binary lookup key as a whole will be referenced in a corresponding database query.

As will be described further below, the purpose of a database query is often to determine a value of an attribute stored within a particular Subscriber record.

Figure 4 is a table that is illustrative of a Subscriber record held within the database. The values and attributes shown in Figure 4 are not an exhaustive list of those held within Subscriber records / database. For example, in addition to the binary lookup key, a Subscriber record may hold the values of one or more of the following attributes: * OPT-IN/OUT attribute -for signifying whether or not a Subscriber has registered a request to block SMS messages. In particular, the gateway system 1 is arranged to receive, via the messaging interface 13, a notification originating from a mobile subscriber device 40, that sets the value of this attribute. For example, if the notification includes the text "OPT OUT" or "STOP", then value of the attribute of the corresponding Subscriber record is updated to an "OPT-OUT" value in response.

* Blacklist attribute -for signifying whether or not a Subscriber has registered a request to permanently block charged services.

* HLR data -signifying data received from the HLR of the MNO, and cached by the gateway system, such as: o device connection status -signifying whether a mobile device associated with the corresponding MSISDN is connected to a network, and which network this is; and/or o IMEI data -corresponding to the unique number assigned to the mobile device 40 that is currently associated with the corresponding MSISDN.

In complement with each of the above attributes, a Subscriber record may also hold a timestamp attribute to signify when the value of a corresponding attribute within a Subscriber record was last updated.

For example, the OPT-IN/OUT attribute may be complemented by an OPT-IN/OUT update timestamp attribute, the value of which indicates on which day and time the value of the OPT-IN/OUT attribute was most recently set. The gateway system is arranged to set the value of this timestamp attribute in response to (and corresponding to the day/time when) a respective notification originating from a mobile subscriber device 40 was received by the gateway system 1 via the messaging interface 13.

In the case of HLR data, the corresponding timestamp attribute is referred to as a "cache updated" attribute, and this signifies when the HLR data was received via the messaging interface 13 from the HLR of the MNO, and cached in as an HLR data value in the database 11.

It should be noted that either a timestamp attribute, or the attribute with which it is associated may, where context allows, be used as a control attribute to control the behaviour of the gateway system 1 as will now be described.

System operation In an exemplary method of operation, the gateway system 1 is arranged to receive a request via the gateway user interface 12, from a gateway user device 20. The request typically comprises authentication information for authenticating the identity of the gateway user device 20. Also included within the request is an operation to be executed by the gateway system 1, typically for and on behalf of the gateway user device 20. A request also identifies at least one MSISDN which is the subject of the request.

The request may include other data relevant to the request, such as a message, a value, and/or a fimeframe By specific example, a request may comprise a "transmit SMS" operation, and additionally include SMS message data to be transmitted to the mobile Subscriber device associated with the MSISDN. Another request may comprise a "bill user" operation, and additionally include the value to be billed (and a currency in which the bill is to be issued). Yet another request may comprise an "HLR data lookup" operation, and additionally include a cache recency threshold that specifies a limit on the acceptable age of data cached by the database 11. For example, a value of "<2 days" indicates that acceptable cache values are those which are under two days old.

In response to receiving the request, the gateway system 1 is arranged to query the database 11 to retrieve, from a corresponding Subscriber record, the value of an appropriate control attribute for controlling the requested execution of the operation. The gateway system 1 then executes the operation contained within the request in dependence on the value of the attribute retrieved.

For example, a controlling attribute for the "transmit SMS" operation is an "OPT-IN/OUT" attribute for signifying whether or not a Subscriber has registered a request to block SMS messages. If an "OPT-OUT" value of that "OPT-IN/OUT" control attribute is stored within a particular Subscriber record, then the system prevents onward transmission of the SMS message data contained within the original request. Alternatively, if the Subscriber record has an "OPT-IN" value instead, the gateway system 1 proceeds to transmit said SMS message data, utilising the MSISDN of that record to address the appropriate mobile subscriber device 40-44. Typically, this is transmitted from the messaging interface 13 of the gateway system 1 via an SMSC 30 of an MNO system 3 and thus routed to an appropriate mobile subscriber device 40-44. Further actions may be taken by the gateway system 1, such as sending a response back to the gateway user device 20. This may include a notification that indicates the outcome of the original request. For example, the notification may indicate whether an attempt to transmit the SMS message data was made by the gateway system 1, and so by implication, this may also indicate the value of the OPT-IN/OUT attribute. Moreover, if transmission fails, an error code may be provided in the response back to the gateway user device 20 which indicates a reason for the failure of the transmission of SMS message data.

By way of another example, if the request comprises a "bill user" operation, the controlling attribute is the "blacklist" attribute for signifying whether or not a Subscriber has registered a request to permanently block charged services. A "blacklisted" value of that control attribute causes the gateway system not to transmit a "bill user" command. On the other hand, a "non-blacklisted" value of that control attribute causes the gateway system to transmit a "bill user" command, together with a value to be charged, to an MNO-controlled account associated with the MSISDN of the request. The value to be charged is typically included within the original request from the gateway user device 20 containing the "bill user" operation. Again, the gateway system may be arranged to respond to the requesting gateway user device with a notification to indicate the outcome of the original request, and specifically whether an attempt to transmit a "bill user" command was made by the gateway system 1.

Another request received by the gateway system 1 could comprise a "Home Location Register (HLR) data lookup" operation. In this example, the controlling attribute is a "cache updated" attribute for signifying how recently HLR data has been cached within the database by the gateway system 1. If the HLR data was cached recently enough, then it is more efficient to simply return the cached data to the requesting gateway user device 20-23 rather than fetch this from an external source, such as the MNO systems.

However, if the HLR data in the cache is too old, then it is necessary to update the cache before returning it to the gateway user device 20-23.

Accordingly, the request received by the gateway system 1 may also include a cache recency threshold. Comparing this with the "cache updated" attribute allow the gateway system 1 to determine how that request is to be executed: The gateway system 1 is arranged to respond to the requesting gateway user device with the cached HLR data from the respective Subscriber record if the value of the "cache updated" attribute is more recent than that specified by the cache recency threshold. Otherwise, the gateway system 1 is arranged to communicate via the messaging interface with an MNO-controlled HLR to acquire the HLR data for caching and retransmission in a response back to the requesting gateway user device.

In each of the examples above, the gateway system 1 performs a query of the database to determine the value of a control attribute within a Subscriber record associated with the MSISDN also included with the request. The speed at which an average query is performed takes advantage of the optimised structure of the database, but naturally needs to format the query in the appropriate manner.

Specifically, an appropriate binary lookup key is determined from the MSISDN included within a request from a gateway user device 20-23 such that an appropriate Subscriber record (and so a relevant control attribute) can be found in an efficient manner.

The binary lookup key is determined by applying an MSISDN-to-binary conversion function which is similar to that described above.

Figure 5 is a flow diagram of the specific steps of an example MSISDN-to-binary conversion function.

The conversion function begins by receiving an MSISDN input (length t), and determining a prefix portion of the MSISDN (length p) and suffix portion (length t -p) of the MSISDN.

It should be noted that if the prefix index table were to hold fixed-length prefix portions of the MSISDN, then this determination is relatively straightforward to do, in that p is set to that fixed length.

However, in the preferred embodiments, the prefix index table holds prefix portions of variable length, and so it is necessary to consult the prefix index table when determining where to split the input MSISDN into the correct prefix and suffix portions.

Initially, the prefix portion of the MSISDN is set to be the same length as the longest prefix portion held by the prefix index table, and the prefix index table is queried to determine if a match exists for that length of prefix portion. If not, then the length of the prefix portion is shortened by one and the prefix index table is re-queried. This continues iteratively, until a match has been found within the prefix index table. If the prefix portion of the MSISDN is shortened to the shortest prefix portion held by the prefix index table (or otherwise if there are no other matches), then the exception part in the prefix index table is instead used to retrieve a "default" prefix binary code (e.g. 11111111) which is representative of a category of MSISDNs that do not have a prefix portion that matches any other of the 255 most frequently-occurring prefix portions.

Thus, a match will always be found within the prefix index table, but the potentially iterative querying of the prefix index table will control how the prefix portion and suffix portion of the MSISDN is determined. Notably, every time the length of the prefix portion of the MSISDN is shortened, the corresponding length of the suffix portion is lengthened.

Determination of a match naturally allows the retrieval of the corresponding prefix binary code, and also the determination of the length of the suffix portion of the MSISDN. The determined suffix portion of the MSISDN can then be used to derive a suffix binary code.

This is not performed as a look-up, but rather the suffix portion of the MSISDN is used as an input to a suffix transformation function which transforms the suffix portion of the MSISDN into the suffix binary code as already described above, and shown in Figure 5.

The prefix and suffix binary codes can then be concatenated to generate the binary lookup key for the Subscriber record.

Accordingly, in response to receiving a request that includes an MSISDN and an operation to be executed, the gateway system 1 can query the database 11, using the binary lookup key generated from that MSISDN to retrieve from the corresponding Subscriber record the value of at least one control attribute that is relevant to the request.

One or more control attributes can therefore govern whether and how the operation that that has been requested is to be executed.

The use of a binary lookup key leads to a highly efficient way to retrieve the relevant information from the gateway database 11, and this is an important part of overcoming a significant operational bottleneck that is a major problem in prior-known mobile communication gateway systems. Additionally, the splitting of the MSISDN into a prefix portion and a suffix portion enhances the storage, retrieval and processing of information from Subscriber records stored in the database 11.

As a whole, the above-described features, configuration and operation of embodiments of the gateway system 1 leads to a significant improvement over prior-known mobile communication gateway systems.

However, it should be noted that whilst invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the scope of the appended claims.

Claims (18)

1. CLAIMS1 A mobile communication gateway system suitable for handling SMS message data, the system comprising: o a messaging interface for transmitting and/or receiving SMS message data, via a Short Message Service Centre (SMSC) of a mobile network operator (MNO), to and/or from mobile subscriber devices of a mobile network, each mobile subscriber device being allocated a unique MSISDN (Mobile Station International Subscriber Directory Number); o a gateway user interface arranged to receive requests from, and transmit responses to gateway user devices; and o a database storing Subscriber records holding values of attributes in association with an MSISDN, each Subscriber record having a unique binary lookup key pre-generated from the MSISDN associated with that Subscriber record by applying an MSISDN-to-binary conversion function; and wherein: o the system is arranged to receive a request, via the gateway user interface, from a gateway user device, the request comprising: * authentication information for authenticating the gateway user device; * an MSISDN; and * an operation to be executed by the mobile communication gateway system that is controlled by a value of a control attribute of a Subscriber record stored within the database; and o in response to receiving the request, the system is arranged to: * determine, from the MSISDN included in the request, a corresponding binary lookup key by applying the MSISDN-to-binary conversion function; * query the database with the determined binary lookup key to retrieve, from a corresponding Subscriber record, the value of the control attribute for controlling the requested execution of the operation; and * executing the operation contained within the request in dependence on the value of the attribute retrieved.
2. 2 The gateway system of claim 1, wherein the request comprises a "transmit SMS" operation together with SMS message data to be transmitted to the mobile subscriber device associated with the MSISDN of the request, and the controlling attribute is an "OPT-IN/OUT" attribute for signifying whether or not a Subscriber has registered a request to block SMS messages: o an "OPT-OUT" value of that control attribute preventing onward transmission of the SMS message data via the messaging interface; o an "OPT-IN" value of that control attribute causing the system to transmit said SMS message data from the messaging interface to the mobile subscriber device allocated that MSISDN via an SMSC.
3. 3 The gateway system of claim 2, wherein the system is arranged to respond to the requesting gateway user device with a notification to indicate: * the value of the OPT-IN/OUT attribute; and/or a whether an attempt to transmit the SMS message data was made by the system.
4. 4 The gateway system of any one of claims 1 to 3, wherein the request comprises a "bill user" operation together with a value to be charged to an MNO-controlled account associated with the MSISDN of the request, and the controlling attribute is a "blacklist" attribute for signifying whether or not a Subscriber has registered a request to permanently block charged services: * a "blacklisted" value of that control attribute preventing transmission of a "bill user" command; and a a "non-blacklisted" value of that control attribute causing the system to transmit a "bill user" command, together with a value to be charged, to an MNO-controlled account associated with the MSISDN of the request.
5. The gateway system of claim 4, wherein the system is arranged to respond to the requesting gateway user device with a notification to indicate: * the value of the "blacklist" attribute; and/or o whether an attempt to transmit a "bill user" command was made by the system.
6. 6. The gateway system of any one of claims 1 to 5, wherein the request comprises a "Home Location Register (HLR) data lookup" operation together with a cache recency threshold, and the controlling attribute is a "cache updated" attribute for signifying how recently HLR data has been cached within the database by the system and: o the system is arranged to respond to the requesting gateway user device with the cached HLR data from the respective Subscriber record if the value of the "cache updated" attribute is more recent than that specified by the cache recency threshold; or otherwise: o the system is arranged to communicate via the messaging interface with an MNO-controlled HLR to acquire the HLR data for caching and retransmission in a response back to the requesting gateway user device.
7. 7. The gateway system of any preceding claim, wherein the MSISDN-to-binary conversion function comprises: o determining a prefix portion, and a suffix portion of an MSISDN; o querying a prefix index table with the prefix portion of the MSISDN to retrieve from it a predetermined prefix binary code that is associated with the prefix portion of the MSISDN; o transforming the suffix portion of the MSISDN into a suffix binary code by applying a suffix transformation function, leading zero digits of the suffix portion of the MSISDN being preserved by said suffix transformation function; and appending the suffix binary code to the prefix binary code to generate the binary lookup key for the Subscriber record.
8. 8 The gateway system of claim 7, wherein each unique prefix binary code of the prefix index table is stored as a binary value B bits in length, and the prefix index table has 26 records, wherein B = 8.
9. 9 The gateway system of claim 7 or claim 8, wherein the prefix index table is populated by analysing the database to select and populate the prefix index table with the most frequently-occurring MSISDN prefix portions from a filtered list, filtered in dependence on the value of a selected attribute.
10. 10. The gateway system of claim 9, wherein the filtered list filters out aged Subscriber records having the value of a selected timestamp attribute older than a predetermined threshold.
11. 11 The gateway system of any one of claims 7 to 10, wherein the system maintains a traffic log of communications with: o its gateway user interface (such as requests from gateway user devices); and/or o its messaging interface, (such as SMS message instructions from mobile subscriber devices); the traffic log comprising a log timestamp of the occurrence of a communication having an MSISDN associated with it, and the prefix table is populated by analysing the traffic log to select and populate the prefix index table with the most frequently-occurring MSISDN prefix portions in those communications that occur within a predetermined time period by reference to each respective log fimestamps.
12. 12 The gateway system of any one of claims 7 to 11, wherein the MSISDN-to-binary conversion function comprises determining the prefix and suffix portion by splitting the MSISDN of a total length t digits into two, with a first p digits forming the prefix portion, and the last t -p digits forming the suffix portion, the value of p being predetermined to match the size of the longest prefix portion held by the prefixindex table.
13. 13 The gateway system of claims 7 to 12, wherein if querying the prefix index table with the prefix portion of the MSISDN of length p yields no matches, then iteratively decrementing the value of p, resplitting the MSISDN and requerying the prefix index table with a progressively shorter prefix portion until a match is found and so a prefix binary code is retrieved.
14. 14. The gateway system of any one of claims 7 to 13, wherein the prefix index table is prepopulated with the most frequently-occurring MSISDN prefix portions of the database, with each MSISDN prefix portion being associated with a corresponding unique prefix binary code.
15. 15. The gateway system of any one of claims 7 to 14, wherein the suffix transformation function comprises generating an intermediate representation of the suffix portion of the MSISDN wherein leading zero digits of the suffix portion of the MSISDN are replaced by a replacement character different from the decimal character set from which the MSISDN is normally composed, the replacement character being inserted into the intermediate representation at the nm significant digit from the least significant, n being the number of leading zeros replaced by the replacement character, the replacement character together with the decimal character set together defining a base 11 character set, and the suffix transformation function further comprises converting the intermediate representation from base 11 into base 2, thereby to generate the suffix binary code.
16. 16 A method of operating a mobile communication gateway system, the method comprising: o storing, in a database of a gateway system, Subscriber records holding values of attributes in association with a unique MSISDN; o generating, from the MSISDN associated with each Subscriber record, a unique binary lookup key for association with that Subscriber record, the unique binary lookup key being generated by applying an MSISDN-to-binary conversion function; o receiving a request, via a gateway user interface of the gateway system from a gateway user device, the request comprising: * authentication information for authenticating the gateway user device; * an MSISDN; and * an operation to be executed by the mobile communication gateway system that is controlled by a value of a control attribute of a Subscriber record stored within the database; and o in response to receiving the request: * determining, from the MSISDN included in the request, an appropriate binary lookup key by applying the MSISDN-to-binary conversion function; * querying the database with the determined binary lookup key to retrieve, from a corresponding Subscriber record, the value of the control attribute for controlling the requested execution of the operation; and * executing the operation contained within the request in dependence on the value of the attribute retrieved.
17. 17. A computer program product comprising instructions which, when the program is executed by a processor of a computing system, causes the computing system to carry out the method of claim 16.
18. 18. A computer-readable storage medium comprising instructions which, when executed by a computing system, cause the computing system to carry out the method of claim 16.