Abstract:
Method and apparatus for provisioning an e-mail service to a mobile terminal in an e-mail system that uses e-mail addresses comprising a domain part. The apparatus maintains a list of good setting parameter sets versus e-mail domain parts. It receives an e-mail address and user authentication information from a user and compares the domain part of the received address with domain parts in the list of good parameter sets. If a match is found, e-mail service is provisioned with the matching parameter set. If no match is found, the apparatus requests and receives further parameters from the user, including an e-mail server address, and provisions the e-mail service with the further parameters. If the provisioning with the further parameters is successful, the domain part and the further parameters are used to generate a new setting parameter set in the list of good setting parameter sets.

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
       [0001]    The present application is a continuation of U.S. patent application Ser. No. 11/289,308 filed on Nov. 30, 2005, which claims the priority benefit of Finnish Patent Application No. 20045466 filed on Dec. 3, 2004 and U.S. Provisional Patent Application No. 60/651,081 filed Feb. 9, 2005. The disclosure of each of the aforementioned applications is incorporated herein by reference in their entireties. 
     
    
     BACKGROUND 
       [0002]    The invention relates to methods, equipment and software for provisioning of e-mail service. 
         [0003]    Before using an e-mail service with a mobile terminal, the e-mail service must be provisioned, which involves entering a set of settings, such as the address of an e-mail server. Some systems require the server addresses for incoming e-mail and outgoing e-mail separately. Prior e-mail service provisioning techniques suffer from certain problems. For instance, users are not normally aware of the required settings, and when they are, entry of parameters is difficult given the small user interfaces of mobile terminals. 
       SUMMARY 
       [0004]    An object of the present invention is to provide a method and an apparatus for implementing the method so as to alleviate the above problems. The object of the invention is achieved by the methods and equipment which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims. 
         [0005]    An aspect of the invention is a method that comprises the steps of: 
         [0006]    a) maintaining a list of good setting parameter sets, wherein each good setting parameter set relates to a domain part of an e-mail address; 
         [0007]    b) requesting and receiving an e-mail address and a user authentication information from a user of the mobile terminal, wherein the e-mail address comprises a domain part; 
         [0008]    c) comparing the domain part of the e-mail address received from the user with domain parts in the list of good setting parameter sets; 
         [0009]    d) if a match is found in step c), provisioning the e-mail service to the mobile terminal with the setting parameter set that produced the match; 
         [0010]    e) if no match is found in step c), requesting and receiving further parameters from the user, the further parameters including at least an address of an e-mail server, and provisioning the e-mail service to the mobile terminal with the further parameters; 
         [0011]    f) if the provisioning in step e) is successful, using the domain part and the further parameters to generate a new setting parameter set in the list of good setting parameter sets. 
         [0012]    Another aspect of the invention is an apparatus for carrying out the steps of the method. The apparatus may be a dedicated provisioning server, or it may be integrated in or co-located with some other network element or function. 
         [0013]    As used herein, ‘good’ and ‘bad’ in the context of domains and setting parameters are not relative terms but precise shorthand notations to indicate domains under which e-mail service respectively can and cannot be validly provisioned with this technique. 
         [0014]    The success or failure of e-mail service provisioning can be tested by sending a test message using the provisioned e-mail service and attempting to read, and optionally delete, the test message. 
         [0015]    An advantage of the invention is that in many cases e-mail service can be successfully provisioned to users unaware of the required setting parameters. A further benefit is that the amount of data to be entered is reduced. In other words, the invention save time and reduces errors. 
         [0016]    In terms of hardware, the apparatus can be a conventional Internet server comprising appropriate input and output interfaces, processor and memory, wherein the memory comprises routines and data structures for carrying out the steps of the above method. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]    In the following the invention will be described in greater detail by means of preferred embodiments with reference to the attached drawings, in which 
           [0018]      FIG. 1  shows an exemplary system architecture in which the invention can be used; 
           [0019]      FIG. 2  shows a user interface screen for requesting setting parameters from a user; 
           [0020]      FIG. 3  shows a table of good and bad setting parameters; 
           [0021]      FIG. 4A  shows a table of bad setting parameters; 
           [0022]      FIG. 4B  shows a table of alternative setting parameters; and 
           [0023]      FIG. 5  shows a flow chart for processing user-supplied setting parameters. 
       
    
    
     DETAILED DESCRIPTION 
       [0024]    The invention is applicable to virtually any mobile e-mail system architecture.  FIG. 1  shows an exemplary system architecture which is supported by the owner of the present application. Reference numeral  100  denotes a host system that is able to send an receive e-mail messages. Reference numeral  102  denotes a mobile terminal, also able to send an receive e-mail messages. The e-mail messages may originate or terminate at external e-mail terminals, one of which is denoted by reference numeral  104 . The invention aims at improving cooperation between the host system  100  and mobile terminal  102  such that they can use a single e-mail account as transparently as possible. This means, for example, that the users of the external e-mail terminals  104 , when sending or receiving e-mail, do not need to know if the user of the host system  100  actually uses the host system  100  or the mobile terminal  102  to communicate via e-mail. The transparency also means that e-mail manipulation at the mobile terminal  102  has, as far as possible, the same effect as the corresponding e-mail manipulation at the host system  100 . For example, email messages read at the mobile terminal  102  should preferably be marked as read at the host system. 
         [0025]    Reference numeral  106  denotes a data network, such as an IP (Internet Protocol) network, which may be the common Internet or its closed subnetworks, commonly called intranets or extranets. Reference numeral  108  denotes an e-mail server and its associated database. There may be separate email servers and/or server addresses for incoming and outgoing e-mail. The database stores an e-mail account, addressable by means of an e-mail address, that appears as a mailbox to the owner of the e-mail account. In order to communicate with mobile terminals  102 , the data network  106  is connected, via a gateway  112  to an access network  114 . The access network comprises a set of base stations  116  to provide wireless coverage over a wireless interface  118  to the mobile terminals  102 . 
         [0026]    Reference numeral  110  denotes a messaging centre that is largely responsible for providing the above-mentioned transparency between the host system  100  and the mobile terminal  102 . The system architecture also comprises a connectivity function  120 , whose task is to push e-mail messages to the mobile terminal. In the embodiment shown in  FIG. 1 , the connectivity function  120  is considered a physically integral but logically distinct element of the messaging centre  110 . 
         [0027]    The mobile terminal  102  may be a pocket or laptop computer with a radio interface, a smart cellular telephone, or the dike. Depending on implementation, the host system  100 , if present, may have different roles. In some implementations the host system  100  is optional and may be a conventional office computer that merely acts as the mobile terminal user&#39;s principal computer and e-mail terminal. In other implementations the host system may act as a platform for a single user&#39;s connectivity function, in addition to being an office computer. In yet other implementations the host system  100  may comprise the connectivity function for several users. Thus it is a server instead of a normal office computer. 
         [0028]    We assume here that the access network  114  is able to establish and maintain a tunnel  122  between the messaging centre  110  and the mobile terminal  102 . For instance, the tunnel may be set up using GPRS Tunnelling Protocol (GTP) or its later derivatives, or any other suitable tunnelling protocol. 
         [0029]      FIG. 1  shows an embodiment in which the messaging centre  110  is largely responsible for e-mail transport to/from the mobile terminal  102  via the access network  114 , while a separate connectivity function  120  is responsible for data security issues. The connectivity function  120  may be physically attached to or co-located with the messaging centre  110 , but they are logically separate elements. Indeed, a definite advantage of the separate connectivity function  120  is that it can be detached from the messaging centre, for instance, within the company that owns the host system  100  or the e-mail server  108 . For a small number of users, the connectivity function  120  can be installed in each host system  100 , or the host system  100  can be interpreted as a separate server configured to support multiple users. It is even possible to implement some or all the above-mentioned options. This means, for example, that there is one or more messaging centres  110  that offer services to several network operators, or they may be a dedicated messaging centre for each network operator (somewhat analogous to short messaging centres). Each messaging centre  110  may have an integral connectivity function  120  to support users who don&#39;t wish to install a separate connectivity function in a host system  100 . For users who do install a separate connectivity function  120  in their host systems  100 , such connectivity functions bypass the connectivity function in the messaging centre  110  and address the messaging centre  110  directly. 
         [0030]    A real e-mail system supports a large number of mobile terminals  102  and tunnels  122 . In order to keep track of which e-mail account and which tunnel belongs to which mobile terminal, the messaging centre  110  and the connectivity function collectively maintain an association  124 ,  124 ′ for each supported mobile terminal. Basically, each association  124 ,  124 ′ joins three fields, namely an e-mail address  124 A assigned to the mobile terminal or its user, encryption information  124 C and a temporary wireless identity  124 D of the mobile terminal in the access network. The embodiment shown in  FIG. 1  also employs a terminal identifier  124 B which may be the same as the e-mail address  124 A of the mobile terminal  102 , in which case the association  124  actually associates three information items. Alternatively, the terminal identifier  124 B may be an identifier arbitrarily assigned to the mobile terminal. In a preferred implementation the terminal identifier  124 B is the mobile terminal&#39;s equipment identifier or its derivative. The encryption information  124 C is preferably related to the mobile terminal&#39;s equipMent identity and is preferably generated by the mobile terminal itself, so as to ensure that no other terminal besides the one used for creating the encryption information  124 C will be able to decrypt incoming encrypted e-mail messages. The temporary wireless identity  124 D may be the identifier of the tunnel  122  to the mobile station. Of course, the tunnel identifier is not permanent and is only known when a tunnel exists. 
         [0031]    In the embodiment shown in  FIG. 1 , the inventive method can be executed in the connectivity function  120 , but if one is not present, a separate provisioning server  126  can be used. 
         [0032]      FIG. 2  shows a user interface screen  200  for requesting setting parameters from a user. The user may enter the setting parameters by means of the mobile terminal  102  or a conventional computer, such as the host system  100 . Reference numeral  202  generally denotes a set of prompts displayed to the user. Reference numerals on the right-hand side of  FIG. 2  denote the setting parameters entered by the user. Parameter  210  is the user&#39;s e-mail address. The e-mail address  210  contains a user-specific part  212  and a domain part  216  which are separated by a separator character CO  214 . As used herein, the domain part of an e-mail address is the part of the e-mail address that follows the separator character  044 . Parameters  220  and  222  constitute user-specific authentication information, which in this example consists of a user name  220  and a password  222 . 
         [0033]    The above-described parameters will be requested from every user, and for many users they suffice. Users who cannot be provisioned by the email address  210  and authentication information  220 ,  222 , will be requested to enter further parameters, such as server addresses for incoming and outgoing e-mail, denoted by reference numerals  240  and  242  respectively. 
         [0034]      FIG. 3  shows a table  300  of setting parameters.  FIG. 3  shows an embodiment in which good and bad setting parameter sets are stored in a single table. Reference numerals  300 A and  300 B denote good and bad setting parameter sets respectively.  FIG. 3  shows three versions of the table  300  that are present at different times. Reference numeral  300  shows the table in a some phase of operation, while reference numerals  300 ′ and  300 ″ denote versions of the table at two different phases of development. In the two first versions  300  and  300 ′, all setting parameter sets are assumed good, as indicated by the reference numeral  300 A. 
         [0035]    In this illustrative example, the table  300  comprises a row or record for three domains. For each domain, the table  300  comprises a column or field for a domain name  310 , incoming server address  320  and outgoing server address  330 . Preferably, there is also a failure measure column  340 , the use of which will be described later. 
         [0036]    The first version of table  300  comprises entries for two domains, denoted by subscripts after the columns. For example, reference numeral  3101  denotes a domain  310  for a first operator. 
         [0037]    Embodiments of the invention are best described by describing the user interface of  FIG. 2 , the data structures of  FIGS. 3 and 4 , and a method shown in  FIG. 5  simultaneously.  FIG. 5  shows a flow chart for processing user-supplied setting parameters. In step  500  a user logs in with a provisioning server that, by way of non-limiting example, can be the connectivity function  120  shown in  FIG. 1 . Alternatively, a dedicated provisioning server (not shown separately) can be provided. In step  502  the user is requested to enter the e-mail address  210  and authentication information  220 ,  222 , shown in  FIG. 2 . At this step, the remaining parameters  240 ,  242  shown in  FIG. 2  need not be requested or entered. In step  504 , the provisioning server parses the domain part  216  from the user-supplied e-mail address  210  and compares, in step  506 , the domain part  216  with the domains in the domain column  310  of the table  300 . In the example shown in  FIGS. 2 and 3 , the domain is operator.fi, which matches the domain part  3101  in the first displayed record in the table  300 . The table  300  comprises sets of known good setting parameters, and in step  508 , the provisioning of the e-mail service for the user is completed with the parameters  3201  and  3301  (server addresses for incoming and outgoing e-mail) found in this record. 
         [0038]    Steps  510  to  518  are performed if a match is not found in step  506 . In step  510  the user is requested to enter further parameters, such as the server addresses for incoming and outgoing e-mail, items  240  and  242  in  FIG. 2 . In step  512  the user&#39;s e-mail service provisioning is performed with these parameters. In step  514 , the validity of the user&#39;s newly-supplied parameters  240  and  242  is tested. For example, the provisioning server may send a test e-mail message to the user-supplied address  210  and attempt to read, and optionally, delete it with the user-supplied authentication information  220 ,  222 . If this test, or some other suitable test, is successful, the provisioning server creates, in step  518 , a new record in the table  300 . The complemented table is denoted by reference numeral  300 ′. It comprises the domain name  3103  and the user&#39;s newly-supplied parameters  3203  and  3303 . 
         [0039]    If the test  514  initially fails, it may be repeated some time afterwards to take care of situations in which the e-mail server(s) supporting the user is/are temporarily out of action. 
         [0040]    Step  520  relates to an optional but beneficial act of keeping track of a failure measure of e-mail service provisioning. The failure measure may, by way of example, indicate a count, rate or ratio of provisioning failures. Keeping track of the failure measure is beneficial because the user-supplied parameters  3203  and  3303  may not be valid to all users within the same domain  3103 . In other words, even if the test in step  514  is successful for one user, the parameters may still be invalid for other users because the relation of domain name versus server addresses may be ambiguous. This is why it is beneficial to keep track of a failure measure per domain, shown as column  340  in  FIG. 300 . The failure measure for the domain operator  3 . fi  is denoted by reference numeral  3403 . Let us assume that after some monitoring period, that measure exceeds some predetermined threshold. As a result, the data for the domain operator  3 . fi  is marked as bad (not configurable). In the example of  FIG. 3 , the server addresses for incoming and outgoing e-mail for operator  3 , denoted by reference numerals  3203  and  3303 , are replaced by zeros. The zeros acts as signs for invalid data, which means that the e-mail addresses in the domain operator  3 . fi  are ambiguous and cannot be adequately provisioned by this technique. Reference numeral  300 B denotes a section of the table  300  that comprises bad setting parameter sets. 
         [0041]    The predetermined threshold for the failure measure cannot be zero or very close to zero because even validly provisioned e-mail servers can be out of service for some time, and some failures must be tolerated even with good setting parameters. 
         [0042]      FIG. 4A  shows an alternative embodiment that employs an explicit list  400  of bad domains. In this embodiment the list  300  of good settings parameters is naturally devoid of bad domains. 
         [0043]      FIG. 4B  shows a further alternative embodiment that employs a list  420  of alternative setting parameters. This embodiment makes use of the fact that even if the e-mail server address(es) for a domain may not be unambiguously derivable from the domain name, a setting selected from a finite set of alternative settings usually applies. 
         [0044]      FIG. 4B  shows a list  420  of alternative setting parameters for two operators. Reference numeral  422  denotes three alternative setting sets for operator  3 . fi  and reference numeral  424  denotes two alternative setting sets for operator  5 . f L If the user-indicated e-mail address  210  ( FIG. 2 ) is under a domain  216  that is listed in the list  420 , the alternative setting sets can be tried automatically one by one, or they can be shown to the user for selection. If the user does not find a suitable setting parameter set among the alternative settings, he/she may enter a new setting parameter set, which can be tested and added to the list  420  if the test succeeds. The list of alternative setting sets for each operator can be maintained in the order of decreasing success rate of provisioning, whereby the most likely correct setting set will be tried first. 
       Further Preferred Embodiments 
       [0045]      FIG. 2  showed an embodiment in which the user name  220  was requested from the user separately from the e-mail address  210 . In some e-mail systems it is possible to deduce the user name  220  from the e-mail address  210  automatically. For instance, some e-mail systems may use the user-specific part  212  of the e-mail address  210  as the user name  220 , possibly after stripping of non-alphabetic characters. Accordingly, it is beneficial to maintain in the connectivity function  120  or provisioning server  126  a set of domain-specific rules for determining the user name  220  from the e-mail address  210  automatically. Such rules can be domain-specific. In other words, under a certain e-mail domain  216 , the user name  220  may be deduced from the e-mail address  210  by some specific rule. In case the connectivity function  120  or provisioning server  126  does not have a specific rule for a certain domain, it may try all or some of the most generally applicable rules, such as using the user specific part  212  as the user name  220 . 
         [0046]    The set of domain-specific rules may also comprise instructions to be displayed in case of provisioning problems. For instance, the connectivity function  120  or provisioning server  126  may test e-mail provisioning with the user-supplied parameters  210 ,  220 ,  222 . If the test fails, the user may be instructed to activate a premium service. 
         [0047]    It is readily apparent to a person skilled in the art that the inventive concept can be implemented in various ways, and the above embodiments are meant to illustrate rather than restrict the invention. For example, there may be one combined server address or separate e-mail server addresses for incoming and outgoing e-mail. The server addresses are shown in DNS (domain name server) format, but they can be maintained in any applicable format, such as IP addresses. Those skilled in the art will recognize that many other modifications are possible without departing from the scope of the invention as defined in the attached claims. 
         [0048]    Software for a data processor may include program instructions for carrying out the steps of the methods disclosed in the present application, whereby the software is executed by the data processor. 
         [0049]    Software for a data processor embodied in a carrier, the software comprising program instructions for carrying out a method for provisioning an e-mail service when the software is executed in the data processor is also disclosed.