WO2002033992A1

WO2002033992A1 - Providing customized mobile services, accessed with a keyword

Info

Publication number: WO2002033992A1
Application number: PCT/FI2001/000908
Authority: WO
Inventors: Kaarlo Vapaaoksa; Jaakko Melantie; Pasi Laitala; Ari Laitala; Jarkko KOTAMÄKI; Jerry Jalassola
Original assignee: Oy Wireless Media Finland Ltd
Priority date: 2000-10-19
Filing date: 2001-10-18
Publication date: 2002-04-25
Also published as: FI20010130A0; AU2002212371A1; FI20010130L; FI109440B; EP1332629A1

Abstract

A method for providing a customized service to mobile subscribers (MS1, MS2) in a mobile network comprising a text-delivery function, such as the one in WAP or a short message function. The mobile subscribers comprise a service client (MS1) who customizes the service and at least one service user (MS2) who uses it. The service client initially configures (3-2) the customized service. This step comprises selecting at least one selectable keyword for future use of the customized service. Later the service client updates (3-8) the customized service via the text-delivery function. The service user accesses (3-20) the customized service via the text-delivery function. In the updating and accessing steps, the service is accessed by entering at least a part of the keyword (524) selected by the service client. The service client maintains access control of the customized service.

Description

Providing customized mobile services, accessed with a keyword

Background of the invention

The invention relates to methods and equipment for providing mobile services to mobile subscribers. Mobile services are commonly accessed via a short message connection but Wireless Application Protocol (WAP) is increasingly gaining foothold as an access mechanism. The proliferation of short message services is a somewhat surprising phenomenon. From the very beginning, GSM specifications have included a short message protocol but when the first GSM hand- sets were produced, many manufacturers omitted the short message functionality because they did not consider it useful or practical. Now a wide variety of services, such as news, weather, jokes, etc. are accessible via short messages. A limitation of such services is that mobile users can only act as service recipients, ie receive information, but not update the service. There are mechanisms for providing rudimentary access to existing

Internet services with a mobile station. For instance, PCT publication WO98/47270 describes a system for accessing existing Internet services with a mobile station, but the system is limited to read-only access. US patent 6 125281 discloses a calendar application which can be accessed either via the Internet or from a mobile station. This system is limited to the few fixed applications offered by a service provider. Neither system suggests customizable services which are accessible to a controllable set of service users.

Disclosure of the invention

An object of the invention is to increase the number of mobile ser- vices available to mobile subscribers. This object is achieved with a method and equipment which are characterized by what is disclosed in the attached independent claims. Preferred embodiments of the invention are disclosed in the attached dependent claims.

The invention will be described with the following terminology. A network operator is a self-explanatory term referring to the company running an underlying mobile network which is capable of providing a text-delivery function, such as a short message function or wireless application protocol (WAP). A service provider is an organization which uses the messaging function of the mobile network to offer services according to the invention to mobile subscribers. The network operator and the service provider may be the same or different entities. A service client is a mobile subscriber who creates his/her own services by means of the tools provided the service provider. A service user is a mobile subscriber who uses the services created by a service client. Thus the service provider offers a platform on which customized services are built, whereas the service client is in charge of the information associated with the service.

The mobile services are updated and/or accessed from a mobile station. According to a first embodiment of the invention, the service updating and/or accessing takes place by means of a messaging function of a mobile communication system. In the context of this invention, the term 'text-delivery function' basically means that messages can be sent using a text-based interface (typically a display and keyboard or touch screen).. An example of a text- delivery function is a short message function, such as the one used in a GSM system, in which short messages are sent without establishing a permanent circuit-switched channel. The term 'short message service' is also frequently used in the industry, but in the context of this invention the underlying bearer service is called a 'function' to avoid confusion with the customized services which make use of the messaging function. In the future, the messaging function can be implemented by means of a data connection in a packet radio sys- tern, such as the GPRS. According to a second embodiment of the invention, the service updating and/or accessing takes place by means of WAP protocol. Ideally, a common application server comprises access and updating routines for accessing and updating services from both types of terminals. In other words, any customized service can preferably be updated and/or accessed re- gardless of the terminal type (short message or WAP).

The invention is partially based on the surprising discovery that valuable services can be created if mobile subscribers (service clients) are able to update even very small amounts of information which is accessible to other mobile subscribers (service users) and if the service clients are able to control the accessibility of the services.

Access control can be implemented by one or more of the following features. Each service is accessed by at least one keyword which is selectable by the service client. Ideally, the keywords are freely selectable but with two restraints. Obviously, the keywords must contain characters supported by the underlying protocol (messaging function or WAP). The characters must be supported by all of protocols if several alternative protocols are used). Addi- tionally, some characters (such as a currency sign at the beginning of a word) could be used to indicate services with a charge higher than normal, and some words are reserved for commands. Even allowing for such restraints, service clients have a virtually unlimited number of keywords available. A message for updating or accessing a service contains one or more parameters. One of the parameters is called a client identifier, and it is associated with a service client, although the association may not be immediately apparent to a service user. For example, a service client has registered a client identifier 'pubs'. Under this client identifier there are services which are accessed by service keys 'irish', 'english', etc. The parameters for accessing a service, ie the client identifier and the service keys, are commonly referred to as keywords. Preferably, all keywords for accessing a service are freely selectable (within the restraints above) by the service client.

By selectively concealing or publishing (better yet: allowing to be published) the keywords, the service client can determine the accessibility of the services. Ideally, the service client can indicate whether or not each keyword is publishable in response to a keyword inquiry from service users. Very high confidentiality is maintained if the client identifier and/or the service keys are private (not publishable) and include hard-to-guess spelling. Secret key- words are virtually immune to brute-force attacks because an attacker must pay the price of one short message for each attempt. On the other hand, some services are meant to be published. If the service client's client identifier is publishable, his/her publishable services can be accessed by knowing nothing more than the client's name (and sufficient contact information to distinguish the client from other clients with identical names), if the service provider offers a service for listing the client's identifier and public keywords. If the service provider offers a directory service for listing all client identifiers that match a given pattern, service uses can locate services with interesting names without any prior knowledge of the services. In the context of this invention, customizing a service is a wide term which comprises the act of initially forming the service and, as the situation requires, later acts of updating the service. Depending on the situation, service updating may comprise content creation, modifying and deletion. For instance, service clients may form a service for indicating their location. Whenever they change locations, they update the service by reporting their new location. A benefit of such a service is that the service clients' friends can locate the ser- vice clients even if they are not able to answer a call. A service client may indicate that she goes to, say, a discotheque, and her friends will know where she is, although the music is too loud for her to hear a phone ring.

One aspect of the invention is a method for offering services to mo- bile subscribers. Another aspect of the invention is a service provisioning equipment which uses the text-delivery function of a mobile network to offer services to mobile subscribers.

According to a preferred feature of the invention, a service client may register a new client identifier with a web browser but the client must acti- vate the identifier with a mobile station. A benefit of the separate activation with the mobile station is that the service provider can charge for the service (with a contract with the network operator if they are separate entities) because mobile network operators are well equipped to charge small amounts for various services. Another benefit of the separate activation is that client identifiers cannot be hoarded without paying.

Brief description of the drawings

The invention will be described in more detail by means of preferred embodiments with reference to the appended drawings wherein:

Figure 1 is a block diagram illustrating a network architecture in which the invention can be used;

Figure 2 is a block diagram illustrating an application server according to a preferred embodiment of the invention and its interfaces towards user equipment;

Figure 3 is a signalling diagram illustrating a possible set of events in a system according to a first embodiment of the invention utilizing a messaging function of a mobile communication system;

Figure 4 is a flow chart illustrating the acts performed by a logic section within the application server;

Figure 5 illustrates various forms for customizing services via the Internet; and

Figure 6 is a signalling diagram illustrating a possible set of events in a system according to a second embodiment of the invention utilizing a wireless application protocol compatible mobile station for updating the customized service. Detailed description of the invention

Figure 1 is a block diagram illustrating a network arrangement in which the invention can be used. Reference sign AS depicts an application server according to the invention. An idea of the invention is that services are best configured initially from a web browser in a user's personal computer PC. Mobile users must be able to use the services via a mobile network PLMN (Public Land based Mobile Network). Accordingly, the application server AS has Internet connectivity, as shown by reference number 2, and a short message gateway SGW to a short message service centre SMSC of the PLMN. The AS/SGW combination is indicated by reference number 1 , and it is deliberately open to interpretation whether the combination is inside or outside the PLMN, or in other words, whether it is operated by the PLMN operator or an independent service operator. The remaining network elements are well known to those skilled in the art. The acronyms are spelled out at the end of this specification. For WAP connectivity, there is a WAP gateway WGW which connects the application server AS to the mobile network PLMN. The two mobile stations shown in Figure 1 are collectively denoted by reference sign MS. Mobile station MS_SMS supports short message communication and mobile station MSW_AP supports WAP protocol instead of or in addition to the messaging function. Ideally, the arrangement shown in Figure 1 comprises both gateways, ie the SGW and WGW. A benefit of the dual-gateway arrangement is that users changing the type of their handsets can always be supported.

Figure 2 is a block diagram illustrating an application server AS according to a preferred embodiment of the invention and its interfaces towards the user equipment. In this example the application server comprises four major sections, namely a web server WS, a logic section LS, a database interface Dl and a "smart" database DB. In this context, "smart" means that the database comprises an SQL (Structured Query Language) server. An example of the web server WS is Microsoft's IIS (Internet Information Server). The logic section LS comprises an ISAPI interface towards the web server to enable the logic section to execute programs as a response to users' requests. The logic section also comprises programs in the form of script and/or dll files.

The database interface consists mainly of two interface technologies. Towards the logic section LS, the database interface offers a code inter- face based on Active Database Objects (ADO), and towards the database DB, there is an Open DataBase Connectivity interface (ODBC). As stated, the application server AS communicates with the Short Message Service Center SMSC via the short message gateway SGW. There is an HTTP interface HI between the gateway and the application server. The purpose of the HTTP interface HI is to convert short messages into URLs for the web server WS. Communication to WAP-enabled mobile stations MSW_AP takes place via the wap gateway WGW.

The logic section LS comprises software routines for service configuration, service updating, accessing (= using) services and access control. Preferably, there is a routine for counting the number of accesses to a service. The number of access times could be used for rewarding service clients (economically or otherwise) for services which are accessed frequently.

Figure 3 is a signalling diagram illustrating a possible set of events in a system according to the first embodiment of the invention utilizing the messaging function. The scenario involves two users, Alice and Bob. Alice Wilson is a service client/user, and Bob is only a service user. Alice begins to configure her first service with her computer PC and a web browser. In step 3- 0, she reserves a client identifier for herself. The service configuration comprises many substeps, most of which are routine to those skilled in the art. Typically, the service configuration comprises the following acts: 1) Alice initi- ates a web connection from her PC to the application server and 2) selects a link to a HTML page for customizing a new service. 3) The server AS sends Alice the HTML page (a form to be filled). 4) Alice fills the form and sends it to the server AS.

According to a preferred feature of the invention, the client identifier reservation is only temporary if it takes place via a web connection, and a separate activation from a mobile station is required. What really matters is that clients should not be able to hoard client identifiers without paying. Although the initial service configuration is best done via a web connection, the separate activation should require payment, which is conveniently imple- mented by allowing only one service identifier per charged message. Thus in step 3-2, Alice uses her mobile station MS1 to activate her client identifier by sending the server AS an appropriate short message such as: start alice_wil

The server acknowledges in step 3-4. In step 3-6, Alice begins the initial configuration of her first service. Figure 5 shows example forms for service configuration. Reference number 50 depicts a form for initial service con- figuration. Fields 502 contain the service client's contact information (name, address, etc.) Field 504 indicates the number of the mobile station from which the client identifier will be activated later. Field 506 contains a client identifier which will be used to access the service(s). According to a preferred feature of the invention, the service client can select whether or not his/her client identifier can be published to other users. In this example, Alice uses radio buttons 508 to indicate that her client identifier can be listed as a response to an inquiry from other users. Another set of radio buttons 510 (or any other menu system) is used to select one of the available services. Assuming that Alice se- lects the first available service, ie a response to one keyword, she will be shown a form 52 for configuring that service.

In this example, the form 52 for configuring the service "response to one keyword" contains a client identifier field 520 whose default entry is the client id entered to field 504. A password field 522 is used to enter a password which is required to update the service later. A service key field 524 is used to enter a service key for the service. The service is accessed later by a combination of the client id plus service key. A response field 526 is used to enter an initial response to the service. The form 52 preferably also includes a public/private indicator 528 which indicates whether the service key field 524 can be listed as a response to inquiries from other users.

As stated, services will be accessed later by a combination of the client id and the service key. Obviously, this combination must be unique within the application server AS. Confusion is minimized by imposing an additional requirement that the client identifiers 506 (and 520, if different) must be unique. If the client identifiers are unique, all clients can choose the service keys at will.

The initial service configuration step 3-6 is completed when Alice clicks the OK button in form 52. In step 3-8 (which may take place day or weeks after step 3-6), Alice begins to use her location service. She goes to the opera and will be unable to take calls. Accordingly, she updates her location service by sending the following short message from her mobile station MS1 to the number assigned to the application server AS: upd alice_wil where password in opera until 22:45 wherein "upd" means update. Assuming that the application server AS recognizes the parameter combination, it will acknowledge the short message in step 3-10. Note that the response to the keyword "where", ie "in opera until 22:45", is placed last. This placement allows the use of multiple words and arbitrary characters within the response.

Steps 3-12 through 3-18, which are indicated by dotted arrows, relate to yet another preferred feature of the invention, according to which ser- vice users may inquire service clients' names and keywords, unless the service clients have used the indicators 508 and 528 to conceal such information. Note that other users may still access Alice's services if she discloses her client id and service key(s) in person.

In an optional step 3-12, Bob wants to know Alice's client id. It would be very easy to implement such a directory service via an Internet connection but a short message of current GSM mobile stations is limited to 160 characters. Accordingly, Bob may send from his mobile station MS2 to the server AS a short message which narrows the list of service clients. Assuming that Bob remembers that Alice lives in Main Street, he may send the server AS the following short message:

LISTUSER alice wilson main street

Naturally, the number of Bob's mobile station is carried with the short message, although Bob does not explicitly type it. Assuming that only one client matches the inquiry, the server AS the returns Alice Wilson's client id in step 3-14. In another optional step 3-16, Bob wants to know Alice's service keys, or at least the ones which are publishable. He sends the server AS the following short message:

LISTSERV alice_wil

The server responds by listing Alice's publishable service keys in step 3-18. In this example, the response 3-18 contains the keyword "where". (It is also possible to combine the inquiries and responses 3-12 through 3-18 such that the server AS lists Alice's client id and all her publishable service keys in step 3-14, in which case steps 3-16 and 3-18 are redundant.)

In step 3-20, Bob sends the application server an inquiry about Al- ice's location. In other words, he sends the following short message: alice__wil where

In step 3-14, the application server sends Bob the following short message: alice_wil in opera until 22:45 (The server may omit "alice_wil" because Bob obviously knows who is in opera.) Bob can access Alice's location service because the services according to the invention are accessed independently from the identifier of the underlying messaging function (such as a certain subscriber number). Instead Bob accesses the service by a client identifier and service key, both of which are freely selectable by Alice.

A clear benefit of such a simple location service is that Alice is able to use her mobile station to let her friends see her location although she is unable to take any calls during the performance. Another very useful application of such a one-word location service is location maintenance of people with outdoor hobbies, such as boating or hiking. The location service can be invaluable to rescue teams if a person cannot answer the phone as a result of injury or hardware/battery failure or lost coverage.

According to a yet further preferred feature of the invention, the ser- vice update message in step 3-8 may comprise a lifetime for the service or the information provided by the service. For example, a rarely used symbol can be reserved to indicate that the remainder of the service update message indicates the lifetime of the message. Let us assume that in step 3-8 Alice sends the following message: upd alice_wil where password in opera until 22:45»23:00

The "»" symbol means that Alice's location information expires automatically at 23:00. After that time, the server responds that it has no entry for Alice's "where" keyword. There may be another symbol, such as "«" for indicating that the service (or the information association with it) is valid after the specified date and/or time. Naturally, the lifetime (from ... to) can be indicated during the initial web-based configuration as well.

In step 3-12, Bob sent the server AS a client inquiry ("listuser") which included Alice's name and partial address. This is a preferred way of retrieving client identifiers of actual persons. Some services may not relate to a single person. For instance, a football tournament event will be described below. All public services relating to football can be retrieved by a short message: listuser %football% wherein the percent signs act as wildcards. Figure 6 is a signalling diagram illustrating a possible set of events in a system according to a second embodiment of the invention utilizing a wireless application protocol (WAP) compatible mobile station for updating the customized service. To keep the illustration compact, Figure 6 is shown as a variation of Figure 3, and only the differences will be described. The optional steps 3-0 through 3-4 can be used similarly to the first embodiment. In step 6-2 Alice uses her WAP-enabled mobile station to configure the service initially. In step 6-4 Alice activates (opens) a WAP session via the WAP gateway WGW to the application server AS. The session activation comprises authen- tication with the client identifier and password. In step 6-6 the application server acknowledges the session activation. In step 6-8 Alice updates her first service by the service key and the new contents. In an optional step 6-8', Alice updates her next service, if any. Step 6-8' can be repeated as many times as there are services to be updated. A benefit of the WAP session is that Alice does not have to enter her password every time she wants to update a service. Rather the password is entered only once per session and it is used for all services to be updated during the session. In step 6-10 Alice closes the session and the server acknowledges in step 6-12. In the remaining steps shown in Figure 6, Bob uses Alice's service(s), but even if Bob uses (in this example) a WAP-enabled mobile station, there is no need to establish a session for the service accessing steps 3-12 through 3-22.

Figure 4 is a flow chart illustrating the acts performed by the logic section LS within the application server AS. In step 4-2, the server AS receives a message (a short message or a WAP message) and parses it. In step 4-4 the server determines if the first word is a valid command or client id. If it is neither, an error is reported in step 4-6. If the first word is a valid client id, the next word is checked in step 4-8. If it is a valid service key of a service that only has one service key, the server inquires its database and formats and sends a response in step 4-10. If in step 4-8, the second word is the first ser- vice key of a service requiring two service keys, the check in step 4-8 is repeated for the second service key. If an invalid service key is detected, an error is reported in step 4-6. Thus step 4-10 provides a response to a valid inquiry with a client id and one or two service keys. In step 4-4, if the first word is a valid command, the server executes step 4-12 in which the command is processed. An illustrative but non-exhaustive list of commands and responses is listed in the following table 1 in which curly brackets "{}" denote optional matter:

Table 1

In the table, "cjd", "psw" and "msg" are abbreviations for client identifier, password and message, respectively.

Form 54 in Figure 5 illustrates the initial configuration of a somewhat more complex customizable service, namely a response to two keywords which is accessed by the second choice under "available services" 510 in form 50. This service is described in the context of a football tournament. Field 541 is a client ID field, but in this case the entry "Football-15" does not directly indicate any given client but a football tournament for juniors up to 15 years. However, the client ID 541 still identifies a client, albeit indirectly and only to the server AS and its operator, because the form 54 is accessed via form 50 which registers the client's real contact data. Reference number 543 points to a set of first keyword values, which in this example are the names of the teams. Reference number 544 points to a set of second keyword values, which in this example indicate the teams' coach (name, contact, etc.), sched- ule and results. More than three first or second keywords can be accessed by using the scroll bars 549.

The coach name fields are not updated frequently, and their maintenance is trivial in light of the previous example shown in Figure 3. The con- tact information of a team's coach can be retrieved by sending the application server AS the following short message: football-15 teaml coach

A response can be "Martin Smith, 12345678", for example. Figure 5 shows the form 54 at a stage when a tournament administrator is entering ini- tial configuration data for the teams. The data field for the schedule of Team2 opens up for writing as a result of the administrator writing a long text entry in the field. After the initial configuration and data entry via the Internet, the data fields are easy to update from a mobile phone. Let us assume that the administrator wants to update the schedule for teams 1 and 2 to play on field 5 in- stead of field 1. He wants to avoid typing everything and loads the old entry for the schedule of teaml by sending the following short message: football-15 teaml schedule

The server AS responds by sending the schedule as a short message. The administrator edits the short message, enters the required keywords and password, and sends it to the server AS. The short message for updating the schedule is as follows: upd football-15 teaml schedule password 9:00 Team2 Field5, ...

Naturally, a similar amendment must be made to the schedule of Teaml 's opponent, ie Team2. In a real-life situation the names of the teams and football fields will vary more than they do in this example. This means that only a few letters suffice to uniquely identify which of the first keywords 543 or second keywords 544 is intended. Thus, according to a further preferred feature of the invention, the server AS recognizes a partial keyword if two conditions are met: 1) the keyword is public (not private) and 2) the partial keyword uniquely identifies one of the possible keywords. The reason for the first condition is as follows. Some information is meant to be published, such as information in the football tournament example, for instance. Access to information is simpler if the users do not have to type the keywords verbatim. However, some information is intended for a closed group of friends or co-workers. Let us assume that Alice maintains another service called "holiday#plans" which is private, ie not listed as a response to an inquiry to Alice's services. Alice controls access to this service by disclosing this service key personally to her friends. Confidentiality is maintained by a combination of the non-obvious spelling (including the "#" sign) and the fact that potential hackers must pay the price of one short message for each attempt to guess Alice's private services. If the server AS recognized just the letter "h", which in this example uniquely identifies a keyword, the non-obvious spelling would be ineffective.

Assuming that the server AS recognizes a uniquely identifying part of a keyword, the administrator can update the teams' results as follows. Let us further assume that Teaml beats Team2 by 3 to 1. The administrator sends the following short messages: upd football-15 teaml res password Team2: 3-1 upd football-15 team2 r password Teaml: 1-3 Here, "res" and "r" suffice to uniquely identify the keyword "results" because no other second keyword 544 begins with an "r". Later in the tournament, when the result entries grow longer, it may be convenient to retrieve them from the server, modify and re-send them to the server, as was described in connection with the schedule change. Alternatively, it is possible to enhance the service update syntax. Like the symbol "»" for indicating a service's lifetime, there may be a reserved symbol for indicating that the remainder of the short message is to supplement rather than replace the original contents of the service. A suitable symbol for this purpose is "&&". Assuming that Team2 now beats Team3 by 4-2, the administrator could send the following short message: upd football-15 team2 res password &&, Team3: 4-2

Now the Results entry for Team2 is: Teaml : 1-3, Team3: 4-2 According to yet another preferred feature of the invention, service updating is facilitated if the server AS omits password checking when the ser- vice update takes place from the same mobile station which was indicated in form 50 (see Figure 5) and which was used to activate the client id in step 3-2 (see Figure 3). Skipping the password check may be restricted to public services. In other words, password check should always be performed if the service key is private. Form 56 in Figure 5 relates to a voting/opinion poll service, which is accessed by selecting the third option under "available services" 510 in form 50. The voting service will be described in connection with the previous football tournament. Martin Smith, who coaches Team 1 , arranges a vote for to- night's restaurant. The client id, password and service key fields 560 - 564 are self-explanatory in view of the services already described, as is the public/private indicator 568. This service includes multiple options 566, which in this example are local restaurants. The initial choices are best configured via a web connection and the form 56. However, with appropriate syntax, it is possi- ble to set up a voting service entirely or change the existing options with a mobile station.

Team members can retrieve the options by sending an explicit or implicit query. An example of an explicit query is: cnt martin_s restaurant wherein "cnt" is a reserved keyword for reporting the vote count. An example of an implicit query is the same but without the keyword "cnt". Because a user accesses the voting service but does not vote any option, the server AS assumes that the user wants to know the voting status or options. Accordingly, the server responds as follows: 1: Luigi's Lasagne (x/t %), 2: Pietro's Pizzeria (y/u %), 3: Kamal's

Kebab (z/v %) wherein x, y and z are the absolute votes and t, u and v are the percentage share of each option. A team member may vote for a restaurant by sending a short message as follows: martin_s rest xxx wherein "xxx" is replaced by the voter's choice which may be expressed as a number from 1 to 3 (the number of options) or as an unambiguous part of a choice, such as "luigi".

Assuming that the tournament is a multi-day event, the coach may update the voting service each day by resetting the votes. He does so by sending the following short message: reset martin_s restaurant password He may also update the voting service by changing one of the options for the next day. Assuming that option 2 won on day 1 , the coach may force some variation by replacing option 2 with the following short message: upd martin_s restaurant password option2=Salvatore's Spaghetti The fourth service under the available services 510 in form 50 is

"retrieve requested file". This service can be used to retrieve lengthy text files in response to recognized keywords. This service recognizes short messages containing one of a number of predetermined keywords and retrieves a corresponding text file from a URL address which is configured in a configuration form which is basically similar to the forms 52, 54 and 56 in Figure 5, but is not shown separately.

In the previous examples, all services can be accessed from any mobile station (or a web browser) as long as the service user knows the required keyword(s). The service client maintains access control by selecting whether the keywords are public or private, and if they are private, the service client reveals them only to trusted persons. Security can be further enhanced by having a third option in which a service can only be accessed from the mobile station which was used to register the client identifier.

The invention is not limited to the embodiments described above in detail. The invention can be used to provide customizable mobile-to-mobile pull services. Unlike push services, such as a short message to a group of recipients, pull services are explicitly requested (accessed) by service users. Because the service users explicitly request the service, the access count of a service is a measure of user satisfaction. The invention enables mobile users to maintain highly relevant mobile content. For example, a service client may maintain a service called "cheapgaz" for indicating the cheapest petrol stations in the neighbourhood. Another service may be called "goodrestaurants". Other users may locate such services by inquiring client identifiers that match "%gaz%" or "%restaurant%", respectively. Such services could be very popular if the content is relevant. Accordingly, the service or network operator can reward the service client based on a percentage of the generated text-delivery traffic.

The idea of a reward for frequently-accesses services can be further enhanced if the server AS classifies services into two classes depending on whether the service is free or subject to charge (in addition to the price of one short message). Chargeable services could be indicated on the customi- zation forms (Figure 5), and the client identifier could begin with a special symbol, such as '$' or any other currency symbol. The server operator may charge the service client a small monthly fee for access counting and reward calculation. Thus service clients could test new business models basically free of charge, and when a model is successful, it can be made chargeable.

There are many types of local information services which are best accessed from a mobile terminal. A culinary expert could maintain a client identifier called '$goodrestaurants' with service keys like 'meat', 'fish', 'vegetarian', 'tex-mex', 'dancing', etc. Apart from the fact that the service may be chargeable, the server AS implements such a service precisely like Alice's location service, but because the services are accessed with client-selectable keywords, the same logic in the server can be used to implement a virtually endless variety of different business models.

Current mobile text-delivery functions, such as the short message service of the GSM system and the WAP protocol, and the user interfaces of mobile handsets are severely limited compared to what can be achieved via the Internet. However, in the long run, such limitations may turn out to be an asset. Because what matters is the content rather than the looks of a service, the invention is likely to attract content providers who aim to produce relevant mobile-accessible services but are not experienced in programming or HTML coding. The invention enables very easy creation of services. A simple text- based interface is sufficient, and no programming or HTML coding is required. Thus it is reasonable to expect that the number of services will be quite large. While the above wildcard-based technique for finding a service on the basis of its name (client id plus service key) may suffice initially, finding a service on the basis of its contents would be desirable. Thus, according to a another preferred embodiment of the invention, the application server AS comprises or is operationally coupled to a search engine which finds services on the basis of one or more search words. For example, a service user is interested in blonde jokes. The following messages could be used to locate such services: search blond /count search blond /use

The first message (with the parameter "/count") sorts the services in descending order based on the word count of "blond". The second message (with the parameter "/use") sorts the services in descending order based on number of accesses (perhaps during the last 30 days). Naturally, the search engine searches only within public services. Because of the limitations of current short messages, the server may list only as many services that fit into one short message. A more complete search could be performed via a web browser.

An additional technique for facilitating service finding is categorization. For example, the previous example, ie blonde jokes, can be placed in a hierarchy such as: entertainment - jokes - blonde jokes. A category indicator can be inserted to the service configuration forms 52 - 56 (see Figure 5). If the service is created entirely by means of a short message, the ins or inspub command (see table 1) can include a parameter such as cat="blonde jokes". Because categorization is meant to facilitate service finding, placing a service within a category implies that that the service is public.

Service users can search categories by sending a message such as: search cat xx wherein xx is the category name or its substring, eg "jokes", "blond" etc. If the searched category has subcategories, the server can list them. If the category is at the bottom of the hierarchy, the server will list the actual ser- vices.

Access to frequently-used services can be further simplified by using a feature known as "aliases" in some operating systems. Assume that there is a student called Charlie, who has registered a client id 'charlie'. Charlie uses frequently bus line 102 running from Otaniemi to Helsinki (and back). Charlie has created a service which lists the bus schedule in response to three parameters, namely the bus number, time of day and the start station.

The following message retrieves buses starting from Otaniemi from 8 in the morning: charlie 102 0800 otaniemi

Charlie can define an alias "mb" (for "morning buses") by sending the following message: alias charlie password mb-102 0800 otaniemi Now he can retrieve the morning bus schedule by sending the following message: charlie mb

The server expands the alias parameter mb to the actual parame- ters associated with it and sends the requested bus schedule.

According to a further preferred feature, the alias-replacement logic expands certain reserved words to their current values. For example Itime! and Iplace! can be expanded to the current time and place, respectively. (In this case, "place" does not mean the location verbally indicated by a client, such as Alice's "in opera", but positioning information obtained from the network operator. Naturally, a mobile subscriber's permission is required if the service operator and network operator are different entities, but such a permission is implied by the use of a position-dependent service.)

Although the invention has been described in connection with pre- ferred embodiments, the invention is not limited to these embodiments but it can vary within the limits set by the appended claims.

Acronyms (some are not official)

AS: Application server

ADO: Active Database Objects API: Application Programming Interface

BSC: Base Station Controller

BTS: Base Transceiver Station

DLL: Dynamic Link Library

GMSC: Gateway MSC GSM: Global System for Mobile Communication

GPRS: General Packet Radio Service

GW: Gateway

HTML: HyperText Mark-up Language

HTTP: HyperText Transfer Protocol IIS: Internet Information Server (Microsoft)

IF: Interface

ISDN: Integrated Services Data Network

MS: Mobile station

MSC: Mobile services Switching Centre ODBC: Open DataBase Connectivity PC: Personal computer PLMN: Public Land based Mobile Network PSTN: Public Switched Telephone Network SGW: Short Message Gateway

SMSC: Short Message Service Centre SQL: Structured Query Language URL: Uniform Resource Locator WGW: Wap Gateway

Claims

1. A method for providing a customized service to mobile subscribers in a mobile network comprising a text-delivery function, the mobile subscribers comprising a service client who customizes the service and at least one service user who uses it; characterized by: the service client (PC, MS1) initially configuring (3-0...3-6) the customized service, wherein the configuring step comprises selecting at least one selectable keyword (524, 543, 544, 564) for future use of the customized ser- vice; the service client updating (3-8) the customized service via the text- delivery function; the at least one service user accessing (3-20) the customized service via the text-delivery function; wherein the updating and accessing steps comprise entering at least a part of the at least one keyword selected by the service client; and the service client maintaining access control (508, 528, 3-12 ... 3-18) of the customized service.

2. A method according to claim ^ characterized in that the ini- tial configuring step comprises: the service client temporarily reserving a client identifier (506, 520, 541, 560) via an IP network (2); and the service client activating the temporarily reserved client identifier via the text-delivery function.

3. A method according to any one of the preceding claims, characterized in that the updating step (3-8) comprises indicating the lifetime of the customized service or information sent by that service.

4. A method according to any one of the preceding claims, characterized by the service client deciding whether the at least one selectable keyword (524, 543, 544) is public or private.

5. A method according to claim 4, characterized by allowing the service user to access the customized service with a uniquely identifying part of the at least one selectable keyword if the keyword is public, and allowing access with the complete keyword if the keyword is private.

6. A method according to any one of the preceding claims, characterized by counting the counting the number of accesses to the customized service.

7. A method according to claim 6, characterized by rewarding the service client on the basis of the counted number of accesses.

8. A method according to any one of claims 1 to 7, characterized in that the text-delivery function employs a short message function.

9. A method according to any one of claims 1 to 7, characterized in that the text-delivery function employs a wireless application protocol (WAP).

10. A method according to any one of claims 1 to 7, characterized in that the text-delivery function employs a short message function (SMS) or a wireless application protocol (WAP) depending on the capabilities of the terminal (MS_SMS, MS _AP) used by the service client or service user.

11. An application server (AS) for providing a customized service to mobile subscribers in a mobile network (PLMN) comprising a text-delivery function (SMS), the mobile subscribers comprising a service client (PC, MS1) who customizes the service and at least one service user (MS2) who uses it; the application server comprising an interface (GW, HI) to the text- delivery function; characterized by: a service configuration routine for initially configuring the customized service in response to a configuration input (3-0, 3-6, 50, 52, 54, 56) from the service client, the configuration input comprising at least one selectable keyword (524, 543, 544, 564) for future use of the customized service; a service update routine for updating the customized service via the text-delivery function in response to an update input (3-8) from the service client; a service access routine for providing access to the customized service via the text-delivery function in response to an access request (3-20) from the at least one service user; wherein the update input and access request comprise at least a part of the at least one keyword (524, 543, 544, 564) selectable by the service client; and access control means (508, 528, 522, 3-12... 3-18) for providing the service client with access control over the customized service.

12. An application server according to claim 11, characterized by an access counter logic for counting the number of accesses to the customized service.

13. An application server according to claim 11 or 12, characte- rized in that the text-delivery function employs a short message function

(SMS).

14. An application server according to claim 11 or 12, characterized in that the text-delivery function employs a wireless application protocol (WAP).

15. An application server according to claim 11 or 12, characterized in that the text-delivery function employs a short message function (SMS) or a wireless application protocol (WAP) depending on the capabilities of the terminal (MS_{S S}, MS AP) used by the service client or service user.

16. An application server according to any one of claims 11 to 15, characterized by a routine for classifying a service into one of at least two price classes depending on the keyword comprised in the access request.

17. An application server according to any one of claims 11 to 16, characterized in that one of its services comprises retrieval of a file from a URL address in response to a predetermined keyword in the access request.

18. An application server according to any one of claims 11 to 17, characterized by means for arranging several services into hierarchical categories and means for searching services within the categories.

19. An application server according to any one of claims 11 to 18, characterized by means for searching services on the basis of the infor- mation provided by the services.

20. An application server according to any one of claims 11 to 19, characterized by means for associating an alias parameter with several actual parameters and means for replacing the alias parameter contained in an access request with the associated actual parameters.