EP2151105A2 - Messaging terminals - Google Patents

Abstract

The present invention relates to configuring messaging terminals such as, but not exclusively, mobile communications devices, and relates to the configuration of the messaging terminals and the like by using predetermined configuration parameters, and to methods and systems mat facilitate the configuring of messaging terminals.

Description

Messaging Terminals

Aspects and embodiments of the present invention relate to configuring messaging terminals. In particular, but not exclusively, the invention relates to configuring messaging terminals and the like by using pre-determined configuration parameters, and to methods and systems that facilitate the configuring of messaging terminals.

In recent years, the use of messaging terminals that allow messages to be sent between messaging terminals as part of a communications network have become widespread. A messaging terminal is any electronic device capable of receiving and/or sending messages; messaging terminals typically take the form of personal computers or mobile messaging terminals such personal digital assistants (PDAs) and mobile telephones, though other types of messaging terminals are available. Typically, messages are communicated via a network such as the internet and/or, particularly where the messaging terminal is a mobile terminal, via a cellular radio network.

Messaging terminals are sometimes configured in advance, for example before being sold to an end-user, to perform certain functions, such as using messaging services and other services. However, it is often impractical for a messaging terminal to be pre-configured to perform all of the functions that it is capable of performing, due to the large number of such functions, and resulting large number of configuration parameters required; furthermore, new functions may become available after the messaging terminal has been bought by the user.

As a result, messaging terminals are often capable of performing functions that they are not initially configured to perform. In order to take advantage of these functions, it is usually necessary for the user to enter a set of configuration parameters manually via an "advanced settings" or other input interface screen. However, this requires the user to know what the configuration parameters are, and where and how to enter them. Users who are not technically-minded may be unable or unwilling to discover and input such data. Furthermore, even when the user does attempt to do this, the large number of configuration parameters that are typically required often results in errors being made in inputting the parameters, leading to unsuccessful configuration and, ultimately, to user frustration and dissatisfaction.

An example of such a situation relates to using mobile telephones to access email accounts. Users of mobile telephones often have existing email accounts with an internet service provider (ISP) or within their employer's information technology infrastructure. These email accounts are typically accessed using a personal computer or the like. Although internet-enabled mobile telephones can enable their users to access their email via webmail or the like, due to the large number of different providers of email account services, again, it is not feasible for mobile phones to be pre-configured to act as email clients, which are able to directly receive emails from the relevant email server, for all of these services.

Some messaging terminals provide "wizard" applications which attempt to assist a user to configure an email client to use their servers. However, these are difficult to provide with respect to, for example, mobile telephones because of the large number of different types of mobile telephones that exist, and a lack of standardisation, meaning that a wizard designed to work on one manufacturer's mobile telephone often will not work on another manufacturer's model. Wizard applications also have the disadvantage that a different wizard is required for each email provider.

Some systems use a pre-populated database that a user can access to request configuration parameter information. The required parameter information may then be sent to the mobile telephone using an SMS message, or other type of message. However, the large and growing number of email services available means that it may be impractical to populate and maintain such databases with configuration parameters for all such services; furthermore, the databases can only be updated with new parameter information by manual input from the maintainers of the database.

It is an aim of aspects and embodiments of the present invention to provide improved ways of providing- configuration parameters for messaging terminals.

In accordance with a first aspect the present invention, there is provided a method of adding entries to a database, said database comprising configuration parameters for configuring a messaging terminal, said method comprising: receiving a message comprising a configuration parameter, said message having been sent in response to a messaging terminal being configured using said configuration parameter; and storing said configuration parameter in said database.

Thus the present invention provides a method of populating and maintaining a database without the need for manual input of each configuration parameter. Individual messaging terminals are configured, and the parameters used for the configuring sent to the database, allowing configuration information to be pooled.

In accordance with a second aspect of the present invention, there is provided a method of providing configuration information for configuring a messaging terminal, said method comprising: receiving a first message comprising a configuration parameter, said message having been sent in response to a first messaging terminal being configured using said configuration parameter; and sending a second message comprising said configuration parameter to a second messaging terminal.

This aspect of the present invention allows configuration parameters used to configure one messaging terminal to be provided to another messaging terminal.

According to a third aspect of the present invention, there is provided a parameters server comprising configuration parameters for configuring messaging terminals, said parameters server being adapted to: receive a message comprising a said configuration parameter, said message being sent in response to a said messaging terminal being configured; and store said configuration parameter.

According to a fourth aspect of the present invention, there is provided a messaging terminal capable of being configured by configuration parameters, said messaging terminal being adapted to send a message comprising a configuration parameter in response to being successfully configured using said configuration parameter, wherein said message is sent to a database for storing in said database.

According to a fifth aspect of the present invention, there is provided a communications system comprising a messaging server and a plurality of mobile communications devices, said messaging server being adapted to receive a message from a first mobile communications device, said message comprising a configuration parameter for configuring a mobile communications device to use a communications service, wherein said message is sent in response to said first mobile communications device being successfully configured using said parameter, and wherein said messaging server is further adapted to send said configuration parameter to a second communications device in response to receiving a request from said second communications device.

According to a sixth aspect of the present invention, there is provided a messaging server adapted to perform the method steps described above in relation to either of a first aspect of the present invention and a second aspect of the present invention.

According to a seventh aspect of the present invention there is provided a computer program suitable for adapting a messaging server to perform the method described above in relation to either of a first aspect of the present invention and a second aspect of the present invention.

According to an eighth aspect of the present, there is provided a computer program product comprising a microprocessor-readable medium having microprocessor-readable instructions recorded thereon for providing configuration information, the microprocessor-readable instructions being operative, when performed by a messaging terminal, to cause the messaging terminal to send a message in response to being configured using a configuration parameter, said message comprising said configuration parameter, wherein said message is sent to a database for storing in said database.

According to an ninth aspect of the present invention, there is provided a server adapted to provide a computer program product according a tenth aspect of the present invention.

According to a tenth aspect of the present invention, there is provided a method of adapting a messaging terminal, the method comprising installing a messaging terminal with a computer program product according to a tenth aspect of the present invention.

Further features and advantages of the invention will become apparent from the following description.

Specific embodiments of the invention, are now provided with reference to the accompanying drawings; wherein;

Figure 1 is a block diagram showing a plurality of messaging terminals, a network and connections between them in accordance with the prior art;

Figure 2 is a block diagram showing a messaging terminal downloading a messaging application from a messaging application provider, via a network;

Figure 3 is a block diagram showing a plurality of messaging terminals, a parameters server, a plurality of email servers, a network and connections between them; Figure 4a is a schematic diagram showing an advanced settings page of a messaging terminal prior to configuration parameters being entered;

Figure 4b is a schematic diagram showing an advanced settings page of a messaging terminal after configuration parameters have been entered;

Figure 5 is a flow diagram showing a messaging terminal being configured and a success report being sent;

Figure 6 is a schematic diagram showing a success report comprising configuration parameters;

Figure 7a is a schematic diagram showing a database of a parameters server prior to being updated with die configuration parameters of die success report of Figure 6;

Figure 7b is a schematic diagram showing a database of a parameters server after being updated with the configuration parameters of the success report of Figure 6;

Figure 8 is a flow diagram showing the action of a parameters server in receiving a success report and updating a database with configuration parameters contained in the success report;

Figure 9 is a schematic diagram showing a ranking information report;

Figure 10 is a schematic diagram showing an automatic configuration screen;

Figure 11a is a schematic diagram showing a first request for configuration parameters;

Figure lib is a schematic diagram showing a first response from a parameters server containing configuration parameters;

Figure lie is a schematic diagram showing a second request for configuration parameters;

Figure Hd is a schematic diagram showing a second response from a parameters server containing a plurality of "no suggestions" messages; .

8 Figure 12 is a flow diagram showing the action of a parameters server in receiving requests for and sending messages containing configuration parameters;

Figure 13 is a schematic diagram showing interactions between a providing terminal, a requesting terminal and a parameters server, wherein a request for configuration parameters is made by the requesting terminal for configuration parameters that have been previously provided to the parameters server by the providing terminal;

Figure 14 is a schematic diagram showing interactions between a providing terminal, a requesting terminal and a parameters server, wherein a request for configuration parameters is made by the requesting terminal for configuration parameters that are subsequently provided to the parameters server by the providing terminal;

Figure 15 is a block diagram showing a messaging terminal containing a messaging application, an email server, a fake email server, a parameters server containing a database, a network and connections between them;

Figure 16a is a schematic diagram showing interactions between a messaging terminal, a fake email server, a genuine email server and a parameters server in verifying configuration parameters;

Figure 16b is a schematic diagram showing interactions between a messaging terminal, a fake email server, a genuine email server and a parameters server in determining that configuration parameters provided to the parameters server are not genuine.

Embodiments of the present invention relate to configuration information for configuring messaging terminals. Such messaging terminals typically send and receive messages via a network. Figure 1 is a representation of a system in which embodiments of the present invention may be realised. Messages are sent between messaging terminals 100 via a network 102. Typically, communication is possible between many different messaging terminals, but only two are represented here for conciseness.

The network 102 is shown as a single network, however, it should be understood that the network 102 may include a number of different interconnected networks, including one or more radio access network (s) or networks such as a cellular radio network, for example a GSM or 3GPP network. Communications between the messaging terminals and the network may use radio signals and a connection-based packet mode protocol, such as TCP. Messaging terminals may be mobile communications devices such as mobile telephones or PDAs, or other user terminals such as personal computers.

Some types of messaging terminals comprise microprocessors, and are capable of installing and running messaging applications which may be added by the user. Figure 2 illustrates a messaging application 204 being downloaded for use on a terminal 100 from a messaging application provider 202, via the network 102. The messaging application 204 may comprise microprocessor-readable instructions. Embodiments of the present invention use such a messaging application which a user may initially download and install on their messaging terminal 100, though other means for installing and running the application are envisaged. In some cases, messaging terminals may be pre-installed with the messaging application 204 prior to purchase. Once the messaging application 204 is installed and running on the messaging terminal 100, it may be configured to perform functions such as messaging functions.

The messages sent may be email messages. In email messaging, each messaging terminal typically has an associated server and an inbox at the server with a specified email address for receiving messages. An example of such a system is shown in Figure 3, in which messages are transferred between messaging terminals 100a, 100b and email messaging servers 302a, 302b using protocols such as Post Office Protocol (POP3), Internet Message Access Protocol (IMAP) or Simple Mail Transfer Protocol (SMTP), and transferred between servers 302a, 302b using SMTP. A message sent from a first device typically contains one or more destination addresses for the message, and the message is routed to the inbox or inboxes specified by the address or addresses. The message then remains in the inbox until the corresponding messaging terminal accesses the inbox and retrieves the message. Typically, each messaging terminal sends messages to and receives messages from an associated server, the messages being routed between the associated server and the same or other servers associated with other messaging terminals. In the present example, it may be that all messages sent or received by messaging terminal 100a are communicated via email server 302a. The format of e-mail messages may be as defined in RFC 2822 and RFC 2045 to RFC 2049.

Servers, such as email servers, may comprise a software application running on a computer or across multiple computers, or an embedded system, or some other computerised system that provides services to electronic devices.

The following discussion will refer to email messaging and configuration parameters relating to email messaging, but it will be apparent that embodiments of the present invention can be performed in relation to configuration parameters for other types of messaging, such as SMS messaging or Instant Messaging, or in relation to other functions of messaging terminals unrelated to messaging, for example Internet access or peer-to-peer communications.

Returning to Figure 3, the system shown also comprises a parameters server 304, which comprises a database 306, containing configuration information; the database 306 will be described in detail below. The parameters server 304 is capable of receiving messages from and sending messages to the messaging terminals 100a, 100b, using, for example, HTTP. HTTP is a request/response protocol between clients and servers; one version of HTTP, HTTP/1.1, is defined in RFC 2616 (1999).

Each of the two terminals 102a, 102b is capable of performing various functions, when configured to do so. An example of such a function is sending email messages to and receiving email messages from an email server. In the following discussion, neither of the two terminals 100a, 100b is initially configured to send or receive email messages.

A method of configuring a messaging terminal may involve inputting parameters into an advanced settings screen. An example is now described in which the user of one messaging terminal 100a inputs values into the advanced settings screen shown in Figure 4a; this screen may be presented as a function of a messaging application 204 of the messaging terminal 100a. The user must typically manually input a value into each of the parameter fields 400 corresponding to each of a plurality of parameter names 402...414. The parameter names 402...414 listed are by way of example only, and do not represent an exhaustive list. Parameter name 414 relates to an email address, which is typically unique to the particular user of the messaging terminal 100a; however, the other parameter names 402...412 all refer to parameters which typically may be used by any user wishing to access the server. Of these, three of the parameter names, inbound server protocol 402, inbound server port 404 and inbound security protocol, 406 refer to parameters typically used for receiving email; the other three parameter names, outbound protocol 408, outbound server port 410 and outbound security protocol 412, refer to parameters typically used for sending email. Figure 4b shows the advanced settings page with parameters (IMAP4revl, 993, SSL, SMTP, 465, STARTTLS and bbb(g>bb.com) input into all of the parameter fields 400.

Initially it will typically not be known whether the configuration parameters that have been input are correct i.e. whether the configuration has been successful. However, if at some later point the messaging application 204 is used successfully to send and/or receive email, this confirms that the configuration has been successful. In embodiments of the present invention, when it has been confirmed that the configuration of the messaging terminal 100a is successful, the messaging application 204 is adapted to send a success report containing the configuration information to the parameters server 304.

Figure 5 is a flow diagram showing the action of the messaging application 204 in sending a success report. At step S500, the messaging terminal 100a is configured; this may be done manually as described above with reference to Figure 4a and Figure 4b. At step S502, a messaging function is attempted; this may comprise, for example, attempting to send or receive an email, although other functions are possible. At step S504, a determination is made as to whether the function has been performed successfully. If the function has not been performed correctly, this indicates that at least one of the configuration parameters used is incorrect, and the user may attempt to reconfigure the terminal by returning to step S500. However, if the function has been performed successfully, this indicates that the configuration parameters necessary for the function to be performed have been correctly input. For example, if the configuration parameters shown in Figure 4b are used successfully to receive an email, this confirms that the configuration parameters 416...420 necessary for receiving an email are correct. Similarly, if the same configuration parameters are used successfully to send an email, this confirms that the parameters 422...426 are correct.

If the determination at step S504 is that the messaging function has been correctly performed, a success report is prepared at step S506 and sent to the parameters server 304 containing a database 306 at step S508. The success report and the database 306 will be described in detail below. In some cases, the messaging application 204 may be arranged to send the success report automatically without any user input; in other cases the user may be prompted to choose whether to send the report in response to a prompt.

It should be noted that, in the above description, each of the example functions described in relation to step S502 individually only allow some of the configuration parameters 416...426 to be confirmed at step S504; in this case, the success report sent at step S508 will contain only some of the configuration parameters 416...426. In other cases, step S502 may comprise performing more than one function, such as both sending and receiving email, in order that all configuration parameters 416...426 can be confirmed prior to sending the success report; in these cases, the success report may comprise all configuration parameters 416...426. Further, in some cases a report may be sent to the parameters server 304 even where the configuration has been unsuccessful; it may be advantageous to store data relating to configuration parameters that are known not to be correct. Figure 6 shows an example success report 650; in this example, the success report 650 is of the form of a message having headers such as those shown in Figure 6. The message comprises a number of headers of the form "X- ..." (headers 550...562); these are "user-defined fields", as provided for in the RFC 822 standard for the format of ARPA internet text messages specification, and will be ignored by message transport mechanisms. The success report may be sent using HTTP, or some other convenient transport protocol. There is one header 550 indicating an email address of the messaging terminal from which the success report 650 is sent; this can be used to identify the email service for which configuration parameters have been selected correcdy. In some cases it may not be necessary to provide the entire email address; the portion before the @ mark (i.e. "bbb") may not be necessary, as this is user-specific: indeed, not including it may help to protect user privacy. However, providing a full email address may allow advantageous features of some embodiments of the present invention to be performed, as is described below. In other cases, information such as the name of the email service provider may alternatively or additionally be provided. Headers 552...562 provide the configuration parameters 416...426 used to configure the messaging terminal 100a. In this way, information is provided to a database 306, allowing the latter to map email services with associated configuration information.

The database 306 associated with the parameters server 304 is now described with reference to Figure 7a, which shows a representation of an initial state of the database. The database 306 comprises a list of email services 700, 702. In this case each service is listed according to the portion of email addresses including and after the "@" mark in email addresses associated with each respective service; in other cases, other information, such as the name of the service provider may be listed. Typically, the database 306 lists many email services, but here, for conciseness, only two services 700, 702 have been represented. The database 306 also comprises lists of configuration parameter names 704...714 associated with the email services. The configuration parameter names 704...714 listed are by way of example only, and do not represent an exhaustive list. In the example shown, die database 306 is populated with configuration parameters for the email service corresponding to @aa.com; diis may be due to manual input by the maintainers of the database, or these configuration parameters may have been received in an earlier success report, and stored as described below. Similarly, the list of email services may be wholly or partly input manually; alternatively, or additionally, new entries may be generated in response to success reports and/or requests, as described below. In the example shown, there is only one entry in each configuration parameter field. However, in other cases, there may be more than one entry for one or more of the configuration parameter fields; the entries may be ranked according to predetermined criteria, as described below.

The database 306 does not initially list configuration parameters for the email service corresponding to @bb.com. A method of adding entries for these configuration parameters is now described with reference to Figure 8. The parameters server 304 receives a success report 650 at step S800. The success report may be in die form of a message as described in relation to Figure 6. The parameters server 304 reads the information provided in the headers 550...562 of the message. At step S801, the parameters server identifies the email service to which the success report 650 relates. In this case, this comprises reading the header 550 containing the sender email address bbb@bb.com. At step S802, the parameters server 304 determines whether the email service identified at step S801 is listed in the database 306. If it is not listed, a new entry may be created at step S804; in the present case, however, the service is listed in entry 702.

At step S805, the parameters server 304 identifies a configuration parameter contained in the success report 650; in the present example, this may comprise reading one of the headers 552...562. When a configuration parameter has been identified, it is next determined at step S806 whether the configuration parameter identified is already listed in the field to which it corresponds. If the field is empty, or contains an entry for a different configuration parameter (i.e. a different value), an entry for the configuration parameter is entered into the database 306 at step S808. If the configuration parameter is already listed, step S808 is omitted. After the new entry is created (or it is determined that the configuration parameter is already listed), a determination is made at step S810 as to whether there are any more configuration parameters contained in the success report 650. If there are more configuration parameters, the process returns to step S805 and repeats this and subsequent steps. If there are no more configuration parameters contained in the success report 650, the configuration parameters are verified at step S811, as will be described below. After this confirmation, the process terminates at step S812. Thus, configuration parameters that have been used to configure one messaging terminal are communicated to a parameters server and stored in a database; these configuration parameters can subsequendy be provided to further messaging terminals, as is described below.

It should be noted that it may be possible in some cases for a success report to be sent that contains configuration parameters that are not correct for the email service indicated in the success report. This may be due to a fake email server, having a separate set of configuration parameters. A system comprising a fake email server 1500 is shown in Figure 15. In this system, the user of a messaging terminal 100a (which is installed with a messaging application 204) has an email account, an inbox of which may be accessed by communication with a genuine server 302a. The system also contains a parameters server 304 and a fake email server 1500.

In one example, the messaging terminal 100a is initially configured manually by the user, via an advanced settings screen, as described above; the user intends to configure the messaging terminal using configuration parameters suitable for using the email service associated with the genuine email server 302a, but instead, perhaps due to false information, uses the configuration parameters that are incorrect for the genuine server 302a, but correct for the fake email server 1500. The fake email server 1500 is arranged to accept email addresses of the email service associated with the genuine email server, and to indicate (perhaps falsely) to the messaging application 204 of the messaging terminal 100a that some messaging function has been performed successfully, resulting in a success report containing false configuration parameters for the email service associated with the genuine email server 302a being sent to the parameters server 304. Without verification of configuration parameters received in success reports, false configuration parameters may be stored in the database 306 of the parameters server. As described below, configuration parameters stored in the database 306 are subsequently used for configuring other messaging terminals; if false configuration parameters are used, this may result in users of other messaging terminals inadvertently logging-in to the fake email server 1500 and providing sensitive information such as usernames and passwords to the fake email server 1500; the proprietor of the fake email server 1500 may then use this information for fraudulent purposes. We now turn to describing a method of verifying that configuration parameters received in a success report are valid. Figure 16a is a schematic representation of the interactions between the messaging terminal 100a, the fake email server 1500, the genuine email server 302a and the parameters server 304, in verifying configuration parameters received at the parameters server 204 in a success report. At step Sl 600a, the messaging terminal 100a is configured with the correct configuration parameters for the genuine email server 302a; the messaging terminal connects to the genuine email server 302a and performs some messaging function at step Sl 601a. The server sends some (explicit or implicit) indication that the messaging function has been performed correctly at step S 1602a; this may comprise, for example, receiving an email from an inbox of the genuine email server 302a. As a result of this, a success report is sent from the messaging terminal 100a to the parameters server 304 at step Sl 603a; in this case, the success report contains the email address for which the messaging terminal 304 has been configured. The parameters server 304 receives the success report and enters the configuration parameters contained in it at step Sl 604a.

At this stage, the configuration parameters have been entered into the database 306 of the parameters server, but they have not been verified as genuine. They are therefore kept in a secure state in which they cannot be externally accessed until they are verified. In order to verify the configuration parameters, the parameters server sends a verification email, at step Sl 605a, using the email address contained in the success report. The verification email contains some identifier, such as a number generated uniquely for the email service in question; the identifier is contained in an "X-" header. The verification email arrives at an inbox in the genuine email server 302a; since the messaging terminal 100a has been correctly configured to use the email service at step Sl 600a, it is able to retrieve the message from the genuine email server 302a. The messaging terminal 100a receives the verification email and parses it to obtain the identifier at step Sl 606a. Having obtained the identifier, a confirmation email containing the same identifier is sent from the messaging terminal 100a to the parameters server 304 at step Sl 607a; the identifier is contained in an "X-" header. The parameters server receives the confirmation email and, by matching the identifier sent in the verification email at step Sl 605a with that received in the confirmation email, it is then able to confirm that the messaging terminal 100a is able to send and receive email via the email service indicated in the success report sent at step S1603a. The configuration parameters sent in the success report at step Sl 603a are therefore validated at step Sl 608a. Thereafter, the configuration parameters may be removed from the secure state described above and instead placed into a state whereby they may be externally accessed.

Figure 16b is a schematic representation of interactions between a messaging terminal 100a, a fake email server 1500, a genuine email server 302a and a parameters server 304, in determining that configuration parameters sent in a success report are not genuine. At step Sl 600b, the messaging terminal is configured using configuration parameters which are incorrect for the genuine email server 302a, but correct for the fake email server 1500. The messaging terminal 100a is therefore connected to the fake email server at Sl 601b, which gives some false indication that a messaging function has been successfully performed at step Sl 602b. This results in a success report being sent, at step Sl 603b, which contains configuration parameters that are not correct for the email service indicated in the success report. This success report contains the email address for which configuration of the messaging terminal was attempted at step Sl 600b. The parameters server receives the success report and enters the configuration parameters into the database 306 at step Sl 604b. A verification email containing an identifier of the email service indicated in the success report is sent, at step Sl 605b, to the email address provided in the success report sent at step Sl 603b. The verification email arrives at the genuine email server but in this case, since the messaging terminal 100a has not been correctly configured to use the email service associated with the genuine email server 302a, it does not retrieve the verification email. Therefore, no confirmation email is sent to the parameters server 304, and the configuration parameters received in the success report are not validated. It may be that configuration parameters are kept in a secure state, as described above, until a confirmation is received; in other cases, the parameters entered at step S 1604b may be deleted from the database if no confirmation email is received within a predetermined time interval.

In the examples described above, the configuration parameters received in the success report were initially stored in the database in a secure state, before being placed into an externally accessible state in response to being verified. In other cases, the configuration parameters are not be stored at all prior to verification.

Figure 7b provides a representation of the database 306 after the configuration parameters provided in the success report 650 of Figure 6 have been added.

As mentioned above, in some cases more than one configuration parameter may be listed in a single field; this may be as a result of a configuration parameter added to the database at step S808 corresponding to a parameter name for which a different parameter is already listed. In some cases, more than one set of configuration parameters may be used for a given email service. In some embodiments of the present invention, messaging applications 204 of messaging terminals 100a, 100b may be adapted to provide the parameters server 304 with information that enables different sets of configuration parameters to be ranked according to predetermined criteria, allowing preferred parameters to be identified. This may be done at predetermined time intervals; the ranking information may be sent automatically by the messaging application 204, without any user interaction, or it may be sent as a result of a user action, which may be in response to a prompt.

An example message that can be used to provide such information is shown in Figure 9. The message 950 comprises a "rankmailaddress" header 900 containing an email address of the sending terminal 100a; this can be used by the parameters server 304 to identify the email service to which the message 950 relates. Headers 902...912 provide the configuration parameters to which the ranking information contained in the message relates. A "totaluptime%" header 914, and a "failedops" header 916 provide ranking information. In the example shown, the former provides a time percentage during which the email service was available for use using the configuration parameters 902...912 provided over a period of one month, and the latter provides the number of failed operations using those configuration parameters 902...912 over that period. Other ways of measuring up-time may be used in addition or instead. The parameters server may use an algorithm to rank configuration parameters according to one, or some combination, of these values. Typically, the parameters server collates information provided across a large number of such ranking messages. Other criteria may be used for ranking in some cases. One method by which the parameters server 304 may provide configuration information to a messaging terminal 100b is now described. In particular, a messaging terminal 100b is configured for the service associated with email addresses ending in @aa.com is described. Initially, the messaging terminal 100b is not configured. It may be possible to configure the messaging terminal 100b using an advanced settings screen, such as that shown in Figure 4a, if the configuration parameters are known and the user is able to enter the information correctly. However, in accordance with embodiments of the present invention, the configuration parameters are obtained from the parameters server and used for configuration. The user is initially prompted to provide some information such as an email address via an automatic configurations screen, such as mat shown in Figure 10. After entering an email address into the email address field 1000, the configuration process is initiated by, for example, selecting a "configure" button 1002 on the automatic configuration screen.

Selecting the configure button 1002 prompts the messaging application 204 to send a request for configuration parameters to the parameters server 304. Figure 11a shows an example request 1105, comprising an "X-" header (the "emailaddress" header) 1102 indicating an email address corresponding to the email service for which configuration parameters are being requested.

The request 1105 of Figure 11a is received and analysed by the. parameters server 304, as is now described with reference to Figure 12. In this example, the parameters server 304 contains a database 306 as represented in Figure 7a. The parameters server 304 receives the request 1105 at step S1200. At step S1201, the parameters server identifies the email service to which the request 1105 relates; in the example of the request 1105 of Figure 11a, the parameters server 304 reads the "emailaddress" header

1100, and identifies the email service by reading the part of the email address including and following the @ mark (i.e. @aa.com). At step S1202, the parameters server determines whether the email service identified in the previous step is listed in the database 306. If the service is not listed, a new entry in the database 306 may be created at step S 1204, a message indicating that there are no suggestions for the requested configuration parameters may then be sent at step Sl 206, and a record of the request made at step S1207; the purpose of this record is described below.

However, in the present example request 1105 of Figure 11a, the email service is listed in the database 306 of Figure 7a, at entry 700. The parameters server proceeds to generate a response indicating configuration parameters for the relevant email service; this may be in the form of a response message 1115, as shown in Figure lib. The response message 1115 may be generated using an iterative method, as is now described. For each of the configuration parameters 704...714 listed in the database 306, the parameters server 304 generates a respective "X-" header 1122...1132, indicating the listed parameter. Returning to Figure 12, at step S1208, for a given parameter name 704...714, the parameters server 304 determines whether a corresponding parameter is listed. If a corresponding parameter is listed, it is added to the response message 1115, as part of an "X-" header 1122...1132, at step S1212. If there is no corresponding parameter listed, the message "no suggestions" is added as part of the header 1122...1132 at step Sl 210 and a record of the request for the missing parameter made at step Sl 211, as is described below.

At step S 1214, the parameters server determines whether there are any remaining parameter names 704...714 for which parameters have not been added to the response 1115. If there are remaining parameter names

704...714, the process returns to step S1208; this step and subsequent steps are iterated until a complete response message 1115 is generated. However, if at step Sl 214 it is determined that there are no outstanding parameter names 704...714, the process proceeds to step S1216, in which the response 1115 is sent; this may be done using HTTP, for example.

When the response message 1115 is received by the messaging terminal 100b, the messaging application 204 may then read the "X-" headers to extract the configuration parameters provided in the response message 1115. The messaging application 204 may then use the configuration parameters thus extracted to configure the messaging terminal 100b to use the messaging service; this may be done automatically without any user input, or may involve a user responding to a prompt.

The configuration parameters sent at step S 1216 may be verified using a similar procedure to verification procedure described in relation to Figure 16a and Figure 16b above. In an example method, the messaging terminal 100b sends a verification email containing an identifier to the parameters server 304, which parses the verification email to extract the identifier, and responds with a confirmation email containing the same identifier; on receipt of the confirmation email, the configuration parameters are validated as genuine.

An overview of the above described processes, in which configuration parameters used to configure one messaging terminal 100a are communicated to a parameters server 304 and subsequently provided to another messaging terminal 100b for configuration, is now given with reference to Figure 13, which shows a schematic representation of interactions between a providing terminal 100a, a requesting terminal 100b, and a parameters server 302. At step Sl 300, the providing terminal 100a is successfully configured; this step may comprise a confirmation of a successful configuration. At step Sl 301, the messaging application 204 of the providing terminal 100a sends a success report 650 containing the configuration parameters used for successful configuration of the providing terminal 100a to the parameters server 304. The parameters server 304 receives the success report 650 and updates the database 306 to include the configuration parameters in the success report 650 at step Sl 302. At some later time, the requesting terminal 100b sends a request 1105 for configuration parameters to the parameters server 304. The parameters server 304 sends the configuration parameters to the requesting terminal 100b at step S1306. Upon receiving the configuration parameters, the requesting terminal 100b is configured at step Sl 308.

The above discussion was directed to a case in which the configuration parameters requested were available at the parameters server 304 at the point at which the request was made. We now consider, by way of an example, a case in which configuration parameters not initially available at the parameters server 304 are requested. More particularly, we consider a case in which the request 1155 of Figure l ie is sent to the parameters server 304, where the database is initially of the form shown in Figure 7a. In this case, the email address used to identify the email service for which configuration parameters are required is bbb@bb.com. as shown in header 1150. In the initial state of the database 306, the entry 702 for the corresponding email service contains no configuration parameters. Referring to Figure 12, at step S 1208, for each of the parameter names 704...714 listed, there is no configuration parameter listed in the database, so "no suggestion" messages will be generated at step S1210, and a record of the request for the missing parameter made at step Sl 211. This record comprises an indication of an email address, or some other address, of the requesting terminal, and indications of the requested parameters.

The response thus generated is of the exemplary form of the response message 1175 shown in Figure Hd. Each of the "X" headers 1182...1192 contains the message "no suggestions". This response message 1175 is sent to the requesting terminal 100b at step S1216; this may involve using an email address of the requesting terminal 100b in the "To" field 1194 of the message. The response 1175 also contains a header 1180 indicating the email service for which configuration parameters were requested.

On receiving the response 1175, the messaging application 204 of the requesting terminal 100b indicates to the user that the configuration parameters have not been received, leaving him the option of configuring manually, as described above. However, in accordance with embodiments of the present invention, the database 306 of the parameters server 304 is populated with the required configuration parameters some time after the initial request is made, as described above. Therefore, the user may re- attempt to obtain the configuration parameters from the parameters server 304 at a later time. In some cases, the messaging application 204 may send further requests for configuration parameters to the parameters server 304 automatically without user input. In further cases, the parameters server may make use of the record made at step S1211 or step S1207 to send a notification to the requesting terminal 100b in response to the required configuration parameters becoming available, the notification indicating that the information has become available. An example process in which -a requesting terminal 100b requests configuration parameters which are not initially available, and subsequently receives those parameters is now described with reference to Figure 14, which shows a schematic representation of interactions between a providing terminal 100a, a requesting terminal 100b and a parameters server 304. At step S1400 the requesting terminal sends a request 1155 to the parameters server 304. The parameters server sends a "no suggestions" response 1175 to the requesting terminal at step S 1402, and records the request at step S 1404.

Some time later, the providing terminal is configured at step S 1406 using the configuration parameters initially requested by the requesting terminal 100b, and a success report 650 is sent at step Sl 408 to the parameters server 304. At step S1410, the parameters server 304 updates the database 306 to include those configuration parameters. Since the configuration parameters initially requested are now available, a notification is sent at step S 1412 to the parameters server. This notification may be of the form of an email message which is sent to the email address provided in the original request 1155. Although this message may not be received at the messaging terminal 100b from which the original request 1155 was made, the user of the messaging terminal 100b may retrieve the message by other means, and thereby manually prompt the messaging application 204 of the messaging terminal 100b to retrieve the configuration parameters required. Alternatively, or additionally, the initial request 1155 may comprise information, such as an SMS telephony number, to allow the parameters server 304 to contact the requesting terminal 100b by other means, such as by SMS messaging. In some embodiments of the present invention, the requesting terminal 100b is adapted to respond to the receipt of a notification by automatically, without any user input, sending a further request for the configuration parameters to the parameters server. This automatic response may be implemented using, for example, Java MIDlets using the PushRegistry or Symbian applications.

Returning to Figure 14, having received an availability notification, the requesting terminal 100b sends a further request for the required configuration parameters at step S1414 to the parameters server 304. The latter responds by sending the configuration parameters at step S1416, and the requesting terminal is configured at step Sl 418.

In some cases, the notification sent at step S 1412 may itself contain the required configuration parameters, in which case steps S1414 and S1416 may not be required.

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, in the examples described above, the database 306 as shown in Figure 7a and Figure 7b contains email service entries 700, 702 for which either all configuration parameters are listed or no configuration parameters are listed; in some cases, there may be email services entered for which some, but not all configuration parameters are listed. Further, responses such as those shown in Figure lib and Figure Hd may contain a mixture of parameters and "no suggestions" messages within a single response. It is similarly to be understood that success reports may refer to messaging services for which there is initially no entry in the database, resulting in a new entry being made for that service. Requests may also be made for configuration parameters corresponding to those for which no messaging service is initially entered. Further, in the example given with reference to Figure 10, retrieval of configuration parameters was initiated by entering an email address into a configuration screen and selecting a "configure" button. Other methods are envisaged; for example, in some cases, the information may be retrieved automatically when an attempt to send an email message is made.

The above discussion described success reports being sent to a parameters server. In some cases, "non-success" reports, containing configuration parameters known to be incorrect, may additionally be sent. A method of verifying configuration parameters sent to the parameters server was described in which a verification email and corresponding confirmation email were used. Other methods of verifying configuration parameters are envisaged; for example, in some embodiments, entries in the database 306 may be kept in a secure state until a predetermined number of success reports containing the same configuration parameters for the same email service are received.

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

Claims

1. A method of adding entries to a database, said database comprising configuration parameters for configuring a messaging terminal, said method comprising: receiving a message comprising a configuration parameter, said message having been sent in response to a messaging terminal being configured using said configuration parameter; and storing said configuration parameter in said database.

2. A method according to claim 1, in which said configuration parameters are for configuring a messaging terminal to use a communications service.

3. A method according to claim 2, in which said communications service comprises a messaging service.

4. A method according to claim 3, in which said messaging service comprises an email messaging service.

5. A method according to any preceding claim, in which said configuration parameters are suitable for configuring an email application to use an email messaging service.

6. A method according to any preceding claim, in which said configuration parameters comprise parameters for accessing an email server.

7. A method according to any preceding claim, in which storing the configuration parameter comprises associating the configuration parameter with a communications service.

8. A method according to any preceding claim, in which said database comprises information indicating each of a plurality of communications services and further comprises information indicating sets of configuration parameters, each of said communications services being associated with a respective set of configuration parameters.

9. A method according to claim 8, in which at least one communications service is associated with a plurality of said sets of configuration parameters, and said plurality of said sets is ranked according to predetermined criteria.

10. A method according to claim 9, in which the sets are ranked in response to information provided by one or more messaging terminals.

11. A method according to claim 10, in which said information comprises uptime performance information.

12. A method according to claim 8 or claim 9, in which said information comprises an indication of a number of failed operations using a communications service.

13. A method according to any preceding claim, in which the message is sent from said messaging terminal using HTTP.

14. A method according to any preceding claim, in which said message is sent in response to a confirmation that the messaging terminal has been successfully configured.

15. A method according to any preceding claim in which said messaging terminal comprises a mobile communications device.

16. A method according to any preceding claim in which said message is sent without any user input.

17. A method according to any preceding claim in which said messaging terminal is configured manually by a user.

18. A mediod of providing configuration information for configuring a messaging terminal, said method comprising: receiving a first message comprising a configuration parameter, said message having been sent in response to a first messaging terminal being configured using said configuration parameter; and sending a second message comprising said configuration parameter to a second messaging terminal.

19. A mediod according to claim 18, in which said configuration information is for configuring a messaging terminal to use a communications service.

20. A method according to claim 19, in which said communications service comprises a messaging service.

21. A method according to any one of claims 18 to 20, in which said first message is sent in response to a confirmation that said first messaging terminal has been successfully configured.

22. A method according to any one of claims 18 to 21, wherein said method further comprises storing said configuration parameter in a database.

23. A method according to claim 22, wherein said database comprises a plurality of configuration parameters and a reference to each of a plurality of communications services, each configuration parameter being associated with a communications service.

24. A method according to claim any one of claims 18 to 23, in which said communications service comprises an email messaging service.

25. A method according to claim any one of claims 18 to 24, in which said configuration parameters are suitable for configuring an email application to use an email messaging service.

26. A method according to any one of claims 18 to 25, in which said configuration parameters comprise parameters for accessing an email server.

27. A method according to any one of claims 18 to 26, wherein said method further comprises receiving a request from said second messaging terminal and the second message is sent in response to said request.

28. A method according to claim 27, in which said request comprises a third message, said third message being sent from said second messaging terminal.

29. A method according to claim 28, in which said third message is sent using HTTP.

30. A method according to any one of claims 27 to 29, wherein said request comprises an identifier of a communications service.

31. A method according to any one of claims 27 to 30, wherein said request comprises an indicator of said configuration parameter.

32. A method according to claim 30 or claim 31, wherein said method further comprises using said identifier to identify a communications service listed in said database, and identifying said configuration parameter, said configuration parameter being associated with the identified communications service, wherein said second message comprises said configuration parameter.

33. A method according to claim 32, wherein there is a plurality of candidate configuration parameters associated with the identified communications service, and identifying said configuration parameter comprises selecting said configuration parameter according to a ranking of said parameters.

34. A method according to claim 33, wherein said ranking is according to predetermined criteria, and based on ranking information provided by messaging terminals.

35. A method according to claim 34, wherein said information comprises up-time information.

36. A method according to claim 34 or claim 35, wherein said ranking information comprises an indication of a number of failed operations using a communications service.

37. A method according to any one of claims 27 to 36, wherein said request is received before the first message is received, and said method further comprises : determining that said configuration parameter is not listed in said database; and sending a notification that a required parameter is not available.

38. A method according to any one of claims 18 to 37, wherein at least one of said first messaging terminal and said second messaging terminal comprises a mobile communications device.

39. A method according to any one of claims 18 to 38, wherein said first message is sent without any user input.

40. A method according to any one of claims 18 to 39, wherein said first messaging terminal is configured manually by a user.

41. A method according to any one of claims 27 to 40, wherein said request is sent without any user input.

42. A method according to any one of claims 18 to 41, wherein said configuration parameter is used to configure said second messaging terminal.

43. A method according to any one of claims 18 to 42, wherein said configuration parameter is used to configure said second messaging terminal without any user input.

44. A parameters server comprising configuration parameters for configuring messaging terminals, said parameters server being adapted to: receive a message comprising a said configuration parameter, said message being sent in response to a said messaging terminal being configured; and store said configuration parameter.

45. A parameters server according to claim 44 further adapted to send said configuration parameter to a further said messaging terminal in response to receiving a request from said further messaging terminal.

46. A parameters server according to claim 44 or claim 45, in which said configuration parameters are for configuring messaging terminals to use a communications service.

47. A parameters server according to claim 46, in which said communications service comprises an email messaging service and said configuration parameters are for configuring messaging terminals to use an email service.

48. A parameters server according to any one of claims 44 to 47, further comprising references to communications services, and wherein each of said configuration parameters is associated with a said communications service.

49. A parameters server according to any one of claims 44 to 48, wherein at least some parameters are ranked according to ranking information provided by said messaging terminals.

50. A parameters server according to any one of claims 44 to 49, wherein said ranking information comprises at least one of uptime information and a number of failed operations using a communications service.

51. A parameters server according to any one of claims 44 to 50, wherein said message is sent in response to a confirmation that said messaging terminal has been successfully configured.

52. A messaging terminal capable of being configured by configuration parameters, said messaging terminal being adapted to send a message comprising a configuration parameter in response to being successfully configured using said configuration parameter, wherein said message is sent to a database for storing in said database.

53. A messaging terminal according to claim 52, wherein said configuration parameters are for configuring a messaging terminal to use a communications service.

54. A messaging terminal according to claim 53, wherein said communications service comprises an email service.

55. A messaging terminal according to any one of claims 52 to 54, wherein said messaging terminal is further adapted to receive a configuration parameter from said database and thereby to be configured.

56. A messaging terminal according to any one of claims 52 to 55, wherein said messaging terminal is configured without any user input.

57. A messaging terminal according to any one of claims 52 to 56, wherein said message is sent without any user input.

58. A messaging terminal according to any one of claims 52 to 57, wherein said messaging terminal is further adapted to provide said database with ranking information relating to said configuration parameters.

59. A messaging terminal according to claim 58, wherein said ranking information comprises uptime information.

60. A messaging terminal according to claim 58 or claim 59, wherein said ranking information comprises an indication of a number of failed operations using a communications service.

61. A messaging terminal according to any one of claims 52 to 60, wherein said messaging terminal comprises a mobile communications device.

62. A communications system comprising a messaging server and a plurality of mobile communications devices, said messaging server being adapted to receive a message from a first mobile communications device, said message comprising a configuration parameter for configuring a mobile communications device to use a communications service, wherein said message is sent in response to said first mobile communications device being successfully configured using said parameter, and wherein said messaging server is further adapted to send said configuration parameter to a second communications device in response to receiving a request from said second communications device.

63. A communications system according to claim 60, wherein said communications service comprises an email messaging service and said messaging server comprises an email messaging server.

64. A communications system according to claim 60 or claim 61, wherein said messaging server comprises a server, and said configuration parameter is stored in said database.

65. A messaging server adapted to perform the method steps of any one of claims 1 to 43.

66. A computer program suitable for adapting a messaging server to perform the method steps of any one of claims 1 to 43.

67. A computer program product comprising a microprocessor- readable medium having microprocessor-readable instructions recorded thereon for providing configuration information, the microprocessor- readable instructions being operative, when performed by a messaging terminal, to cause the messaging terminal to send a message in response to being configured using a configuration parameter, said message comprising said configuration parameter, wherein said message is sent to a database for storing in said database.

68. A computer program product according to claim 67, wherein the message is sent in response to a confirmation that the messaging terminal has been successfully configured.

69. A computer program product according to claim 67 or claim 69, wherein said configuration parameters are for configuring a messaging terminal to use a communications service.

70. A computer program product according to claim 69, wherein said communications service comprises an email service.

71. A computer program product according to any one of claims 67 to 70, wherein the microprocessor-readable instructions are further operative to cause the messaging terminal to receive a configuration parameter from a database and thereby be configured.

72. A computer program product according to any one of claims 67 to 71, wherein the microprocessor-readable instructions are further operative to cause the messaging terminal to be configured without any user input.

73. A computer program product according to any one of claims 67 to 72, wherein the microprocessor-readable instructions are operative to cause the message to be sent without any user input.

74. A computer program product according to any one of claims 67 to 73, wherein the microprocessor-readable instructions are further operative to cause the messaging terminal to provide said database with ranking information relating to said configuration parameters.

75. A computer program product according to claim 74, wherein said ranking information comprises uptime information.

76. A computer program product according to claim 74 or claim 75, wherein said ranking information comprises an indication of a number of failed operations using a communications service.

77. A computer program product according to any one of claims 67 to 76, wherein said messaging terminal comprises a mobile communications device.

78. A server adapted to provide a computer program product according to any one of claims 67 to 77.

79. A method of adapting a messaging terminal, said method comprising installing a messaging terminal with a computer program product according to any one of claims 67 to 77.

80. A method according to any one of claims 1 to 17, in which said message comprises an email address associated with said messaging terminal, said method comprising: sending a verification email message comprising an identifier to said email address; receiving a confirmation email message comprising said identifier from said messaging terminal; wherein said storing comprises placing said configuration parameter into an externally accessible state in response to receiving said confirmation email.

81. A method according to claim 80, in which said configuration parameters are placed in a secure state in response to receiving said message

82. A method of adding entries to a database comprising configuration parameters for configuring a messaging terminal, said method comprising: receiving a message comprising a configuration parameter, said message having been sent in response to a messaging terminal being configured using said configuration parameter; storing said configuration parameter in said database and associating said configuration parameter with a communications service, and using said configuration parameter to configure the messaging terminal to use the communications service.

83. A method according to claim 82 wherein the method includes the step of receiving and storing a plurality of configuration parameters wherein said parameters relate to a specific communications service and the parameters are grouped and linked to a specific communication service.

84. A method according to claim 83 wherein the method includes the step of storing in the database configuration parameters relating to a plurality communication services.