WO2004081859A1

WO2004081859A1 - Device and procedure for handling of services

Info

Publication number: WO2004081859A1
Application number: PCT/SE2004/000334
Authority: WO
Inventors: Johan Ny
Original assignee: Telia Ab (Publ)
Priority date: 2003-03-12
Filing date: 2004-03-09
Publication date: 2004-09-23
Also published as: EP1604328A1; NO20053608L; NO20053608D0

Abstract

A device and a procedure for smart card services where a smart card user (120) handles one or more registers over services which are initiated by messages which are transmitted from/to the smart card, where the registers are stored at/on the smart card. Device including a terminal (104) and a smart card (102). The smart card includes one or more registers (112) over the defined services. The user gets access to the service by a dialog box in the terminal and can, via a dialog box, handle services which have been initiated via messages at/on the user's smart card. In the dialog between the user and the smart card, information is asked for/requested for making the smart card service functioning. In order to after that execute the service, the user enters into his/her list over stored services, and selects the service which shall be executed.

Description

DEVICE AND PROCEDURE FOR HANDLING OF SERVICES

Technical field

The present invention relates to a device and a procedure to store functionality on smart cards, chip cards, more particularly to handle one or more registers over/of services which services are stored on the smart card, which services are initiated by messages which are transmitted from/to the user.

Prior art

During recent years smart cards (SC) and chip cards have captured some part of the market. The advantages which smart cards provide are, for instance, greater security at the use of the card and the function, as well as the possibility to store more data than what is possible with the magnetic card.

The smart card is a plastic card of the size of a credit card, complying with the ISO Standard 7816 and having a

CR-80 ISO-format. According to ISO-7816 the contact surface is located/placed according to given rules on/at a specific place/spot on the smart card and has a file structure consisting of root library plus sub library. In rough outline there are two types of smart cards, one type with a chip which has a built-in microprocessor and storage unit/block. Another type is a simple chip card which only has a storage unit which can store certain information. One example is the GSM-cards which are using processor and memory/storage. Another example is chip cards, for instance telephone cards for payphone.

By means of software, for instance Java, which is downloaded into the smart card, it will be possible to control the chip to execute certain functions, for instance to transmit encrypted information. Today all files are standardized on SIM/USIM according to 3GPP TS 31.102 and all commands for handling of the protocol. One way is, for instance, SIM Application Toolkit (SAT) according to 3GPP TS 31.111. By means of 3GPP TS 31.102 all operators, SIM-card manufacturers and terminal manufacturers know which files that exist on the SIM-card and how they shall be handled. So a standardized file to save SMS-initiated services, however, does not exist in 3GPP TS 31.102.

WO 0072612, "System and method for providing requested information to a mobile subscriber using SMS or a microbrowser", describes a system and a method to provide information to a terminal which, for instance, transmits SMS-messages to a service which after that transmits SMS- messages back to the user.

WO 02076122, "Method for providing telephone directory service accompanying SMS notification", describes a procedure to get telephone directory information to a mobile unit which saves/stores the telephone number so that the user does not need to ask for the number again.

Summary of the invention The present invention relates to a device and a procedure to handle one or more registers of/over services which are initiated by messages which are transmitted from/to the smart card user.

The present invention solves the problem of a smart card user today not having possibility to handle a list over services which are initiated by SMS or similar function, on the user's smart card.

A smart card user can, via a dialog box, handle services which are initiated via messages such as SMS, MMS etc, at/in the user's smart card, for instance SIM/USIM or similar smart cards. In the dialog between the user and the smart card, information is asked for to make the service functioning. When the user has provided relevant information, the dialog is terminated and the service is stored with indicated name in executable form in a specific list on the user's smart card. In order to, after that, execute the service, the user enters into his/her list over stored services, and selects the service which shall be executed. After that, a message with the specified content is transmitted to the specified/indicated destination number. The user will have the information which has been asked for back from the service provider.

One advantage with the present invention is that a mobile user can store a service which has been initiated via SMS, for instance an SMS- or MMS-service, on the smart card, and then the user himself/herself can initiate the service when needed.

Another advantage with the present invention is that the user is using the function in similar way as a telephone book/directory though it is the access of services that have been stored on the smart card.

Yet another advantage with the present invention is that the user can bring along the functionality, in the case the user changes terminal identity, by the information being stored on the smart card.

Brief description of the drawings

The invention will be described in more details in the following with reference to enclosed drawings, in which Figure 1 shows a survey of a smart card service system and a broad outline of a signal diagram over the function for handling of service menus, Figure 2 shows a flow chart over installation/insertion of service,

Figure 3 shows a flow chart over how a service from the service menu is used.

Description of preferred embodiments

The invention aims at making it easy for a smart card user to handle registers over services which the user wants to utilize on later occasions.

Another aim is that the user shall have possibility to use the same smart card when it is moved between different terminals. That is, if the user changes terminal, he/she will bring along the services which the user has stored on the smart card to another terminal.

Smart card service is a type of card which has a technical function for which the smart card is used, for instance GSM SIM-card, cash card, telephone card etc.

Service implies the function which a user wants to use.

Program platform is that part of the terminal or the smart card which can control the terminal/smart card, for instance Windows, for computers.

Figure 1 shows a survey of a smart card service system 100 and a broad outline of a signal diagram over the function for handling of service menus . Smart card service system 100 relates to a procedure for handling of services which are stored in registers at/in a smart card. Smart card service system 100 consists of one or more smart cards 102, terminals 104, network systems 106, service servers 108 and users 120. Examples of smart cards 102 can be SIM/USIM- cards, "cash cards" or similar cards. Examples of terminals 104 can be a computer, a mobile terminal, PDA or any similar terminal. Examples of network systems 106 can be a mobile network, Internet, telephone network or any other similar network which can handle access services. Service servers 108 are those servers which handle access services at one or more service providers.

In Figure 1 an example of how the smart card service function is used is shown. It is based on that the smart card user 120 initiates to use a specific service by an initiation 110 being executed. The smart card service is initiated 110 from a register over own services (the service menu) 112 which are stored at/in a smart card 102. The register 112 is produced by an icon in the terminal 104, with an appearance like a switch in the telephone book/ directory. Of course it need not be an icon, but in any way this function is represented in the terminal 104 either by it originally existing in the terminal 104, like switches in the telephone directory, or it will be possible to initiate functions via a message from the service which the user wants to utilize. After that, an SMS-message

(Short Message System) is transmitted 114 from the terminal 104 to a service server 108 via SMS-C. Which service server that is addressed depends on which service that is initiated. The service server 108 interprets 116 the SMS and executes ordered service. An answer 118 is transmitted to the terminal 104 which has requested to get answer from requested service. Examples of answers from a service server can be SMS, MMS, text, picture, sound, video, conversation, database information retrieval etc.

A more detailed description of another example of how the present invention is used:

A SIM-card user 120 can via a dialog in a dialog box handle (create/save/use/delete) services which have been initiated via SMS on the user's SIM-card 102. In the dialog between the user 120 and the SIM-card 102 information is asked for to get the SIM-card service functioning. One way to get this functionality on the SIM-card 104 is that the invention is implemented by SIM Application Toolkit (SAT) . That means that the communication between the terminal 104 and the SIM-card 102 utilizes the 3GPP TS 31. Ill-protocol, or corresponding protocol for using smart card, to create this communication. First, the user 120 needs to create/ store requested service. This is done by the user 120 utilizing the dialog box in the terminal 104 by, for instance, clicking on a smart card service icon at/on the terminal. The user 120 after that creates the service by specifying "Name of the service", content in SMS, and specifying "destination number" for the SMS. When the user 120 has indicated/specified relevant information, the dialog is terminated and the service is stored with indicated/specified name in executable form in a specific register 112 at/in the user's SIM-card 102. In order to after that execute the service, the user 120 enters into his/her register 112 over stored services, and selects the service which shall be executed. After that, an SMS with the specified/indicated content is transmitted to the indicated/specified destination number. The user 112 will have that information, which has been asked for/requested, back from the service provider.

In Figure 2 a method to install and save 200 a service via the dialog box is shown. The storing 200 of the SMS- initiated service is executed in the following way: The user 120 installs the service by starting 202 the dialog. After that, the user 120 specifies B-number to/of the service "<Specify the telephone number of the service>" 204. After that, the user specifies 120 text string which identifies the service "<Specify the code of the service>" 206. After that, the user 120 specifies the name by which the service shall be called from then on in the service menu "<Name service>" 208. After that, the user 120 terminates 210 the dialog.

In Figure 3 a method to use a service via the dialog box is shown. Use 200 of the stored SMS-initiated service is executed in the following way:

The user 120 starts 302 the dialog and selects 304 a saved service from the service menu. Then the information is retrieved/fetched 306 by transmitting an SMS with content to the service server 108 to get back requested information. The company's server can act upon the message and transmit the information back to the user 120. The information is shown 308 on the screen of the user' s terminal 104. The dialog box is terminated 310 when the user does not want to fetch more information from the service menu.

Deletion of the stored SMS-initiated service is executed in the following way: The user starts the dialog and selects 304 a saved service from the service menu which shall be deleted. Deletion of the service is done in the register. The dialog is terminated when the user does not want to delete more information from the service menu.

A device 122, see Figure 1, for smart card services, which device includes at least one terminal 104 and at least one smart card 102. The smart card is arranged to include one or more service menus 112 over the defined services. Handling of the services is at/in the terminal or at/in the smart card. The user gets access to the service by a dialog box on/at the terminal. The service menu consists of one on the smart card or the terminal arranged memory. The service is stored with information regarding name of service, content of the message, and destination number, at which said service is called by the name. Example 1

In this example a company has built a server-solution where employees can send in status reports via SMS. The employees state/specify their identity, a security code, and different predefined code words for reported status, in an SMS which is transmitted to the company's server.

Here one example where an employee, Anna, with security code "G5HTFR43" shall install services for the status codes "OK", and "Not OK" in the service menu will follow. These status codes then shall be transmitted to number "12345":

To add the service to the service menu, the customer first initiates the program which handles the dialog, and initiates this:

1. The text ^w<Specify the telephone number of the service>" is shown.

2. The customer specifies the card number which is associated to the company's server, here "12345", and presses "OK".

3. The text "<Specify the code of the service>" is shown.

4. The customer indicates "Anna G5HTFR43 OK" and presses "OK". 5. The text "<Name service>" is shown.

6. The customer indicates, for instance, "OK" and presses "OK".

7. The text "<Select place>" is shown and the existing service menu is shown to the user. 8. The user selects to store the service at place No 1 of 10 possible in the service menu. 9. The service is stored in correct format at place

No 1 to make it possible to later initiate it via the menu on a later occasion. Point 1-9 are repeated for the status code "Not OK" where

"Not OK" is indicated instead of "OK" in the example above, and the service then is placed at place No 2 in the service menu. The result will be: OK

Not OK

<empty>

<empty>

<empty> When then the user wants to transmit status "Not OK", he/she enters into the service menu and selects the stored service "Not OK". Then an SMS with content "Anna G5HTFR43

Not OK" is transmitted to number 12345, and the company'^' s server can act upon the message.

Example 2 :

A private customer has an empty service menu and wants to add the service "Stockholm weather". The information is transmitted to the customer via SMS when the customer writes the code "START OF WEATHER 08" in an SMS and transmits it to telephone number "72104".

To add the service to/in the service menu, the customer first initiates the program which handles the dialog, and initiates this :

1. The text "<Specify the telephone number of the service>" is shown.

2. The customer specifies number 72104 and presses "OK" . 3. The text "<Specify the code of the service>" is shown . 4. The customer indicates "START OF WEATHER 08" and presses "OK".

5. The text "<Name service>" is shown.

6. The customer indicates, for instance, "Weather Stockholm" and presses "OK".

7. The text "<Select place>" is shown and the existing service menu is shown to the user.

8. The user selects to store the service at place No 1 of 10 possible in the service menu. 9. The service is stored in correct format at place No 1 to make it possible to later initiate it via the menu on a later occasion.

Weather Stockholm <empty>

<empty>

<empty>

When then the user wants to know the weather in Stockholm, he/she enters into the service menu and selects the stored service "Weather Stockholm". Then an SMS with content "START OF WEATHER 08" is transmitted to number "72104", and the content service provider's server can act upon the message and transmit a weather report to the user.

In the same way it shall be possible for the user to delete a service by, via a dialog, marking the service in the service menu which shall be deleted, and press "OK". Yet another embodiment of how the present invention is used:

A smart card user can, via a dialog in a dialog box, handle services which have been initiated via SMS at/in the user' s smart card. In the dialog between the user and the smart card, information is asked for/requested to make the service functioning. The dialog is using a program which is adapted to the terminal or to the program platform of the ' smart card. First, the user needs to create/store the service asked for. This is done by the user utilizing a dialog in a dialog box on the terminal, by for instance clicking on a smart card service icon on/in the terminal. The user 120 after that creates the service by specifying "Name of the service", content of the message, and specifying "destination number" of/for the message. When the user has specified relevant information, the dialog is terminated and the service is stored with specified name in executable form in a specific register in/at the user' s terminal or at/in the user's smart card. The dialog is terminated when the user does not want to install more services from the register.

In order to after that use the service, the user enters into his/her register over stored services, and selects the service which shall be executed. After, that an SMS with the specified content is transmitted to the indicated/ specified destination number. The dialog is terminated when the user does not want to use more services from the register. That means that a service only transmits a message without getting a reply message. Such an occasion can be when one has stored a specific message which one wants to transmit to a receiver for information to just that specific receiver.

Of course it will be possible to, in the dialog, store, use and delete services as desired. The dialog need not necessarily be terminated between the different handling methods . That also applies to all types of embodiments which are described according to the present invention.

To make it possible to delete stored service, the user enters and starts the dialog and selects a saved service from the service menu which shall be deleted. Deletion of the service is executed in the register. The dialog is terminated when the user does not want to delete more information from the service menu.

Yet another embodiment of how to use the present invention: There may be occasions when storing is executed only in register which exists in the terminal. When the user changes terminal, the user wants to transfer the service to the exchanged terminal. The user can, before exchange of terminal, load/install the service on the smart card by entering into the dialog in the dialog box and manually transfer selected service/services to the smart card.

Deletion of service on the smart card is executed in similar way as above, but the user enters into the register which exists at/in the smart card via the dialog in the dialog box and deletes selected service from the register at/in the smart card.

There is yet another embodiment of how to use the present invention:

When the user installs a service via a dialog in the dialog box, the user can "program" the service in such a way that it asks for a certain information when the service is utilized.

That means, that when the user has selected above mentioned service, the user will have a request about giving a certain information to make it possible to use the service. One example of such a service can be to ask about the weather at a certain locality. Then the user presses on the service "weather" and then will have a question "which locality is wanted"; after that, the user specifies the locality. A message is transmitted to the service server which is in charge of weather information and then will find wanted locality. The service server sends requested information back.

Yet another embodiment of how to use the present invention: There may be occasions when storing has been initiated by a message from a service server which installs/loads the service on the smart card by entering into the dialog and automatically transfer selected service/services to the smart card.

Deletion of service on the smart card is executed in similar way as above, but a message from the service server deletes the service at/in the smart card by entering into the dialog and automatically delete selected service from the register in/at the smart card.

Claims

PATENT CLAIMS

1. Device (122) for_: smart card services, which device includes at least one terminal (104) with at least one arranged memory and at least one smart card (102) with at least one arranged memory, c h a r a c t e r i z e d in that said device includes one or more registers (112) over a number, by a user (120), defined services, that handling of the services is in/at the terminal or in/at the smart card and in that said device includes means to create/save/ store said services, at which said means includes that the user (120) installs a service by starting a (202) dialog, that the user specifies B-number to/of the service (204), that the user specifies text string which identifies the service (206), that the user specifies a name (208), which the service henceforth shall be called in the register, and that the dialog is terminated (210) when the user does not want to use more services from the register.

2. Device as claimed in patent claim 1, c h a r a c t e r i z e d in that said device is adapted to be used in a mobile telephone system.

3. Device as claimed in patent claim 1, c h a r a c t e r i z e d in that said smart card is a SIM- or USIM-card which utilizes 3GPP TS 31.111.

4. Smart card service system (100) including one or more terminals (104), in which terminals there are one or more smart cards, network systems (106), service servers (108) and users (120) , c h a r a c t e r i z e d in that the smart card is arranged to include one or more registers (112) over the, by users, defined services, that handling of the services is in/at the terminal or in/at the smart card, and in that said system includes means according to patent claim 1 to create/save/store said services.

5. Procedure for smart card services, which procedure uses a device for smart card services, which device includes at least one terminal (104) and at least one smart card (102), at which the procedure handles one or more registers (112) at/in the smart card, c h a r a c t e r i z e d in that the procedure handles a dialog with/by a dialog box with services in/at the terminal or in/at the smart card; services are stored in the register at/in the smart card; and in that the procedure to create/save/store the function is executed by the user (120) installing the service by starting (202) the dialog, that the user specifies B-number to/of the service (204), that the user specifies text string which identifies the service (206) , that the user specifies a name (208) which the service henceforth shall be called in the register, and that the dialog is terminated (210) when the user does not want to use more services from the register.

6. Procedure for smart card services as claimed in patent claim 5, c h a r a c t e r i z e d in that the procedure to create/store the function is executed by the user creating an inquiry which turns up in the dialog in the dialog box when the user is using selected service.

7. Procedure for smart card services as claimed in patent claim 5, c h a r a c t e r i z e d in that the procedure to use the function is executed by the user (120) starting (302) the dialog, that the user selects (304) a saved service from the register, that the dialog transmits (306) message, and that the dialog is terminated (310) when the user does not want to use any more services from the register .

8. Procedure for smart card services as claimed in patent claim 5 and 7, c h a r a c t e r i z e d in that the procedure to use the function gives the dialog in the dialog box the user possibility to reply to inquiry which turns up when the user is using selected service.

9. Procedure for smart card services as claimed in patent claims 7-8, c h a r a c t e r i z e d in that after the dialog "transmits (306) message", a message with content is transmitted to a service server (108) to get back requested information, that the procedure gets back the requested information to the user, that the information is shown (308) on a screen at/in the user's terminal 104.

10. Procedure for smart card services as claimed in patent claim 5, c h a r a c t e r i z e d in that the procedure to delete the function is executed by the user (120) starting the dialog, that the user selects a saved service which shall be deleted from the register, that selected service is deleted from the register, and that the dialog is terminated when the user does not want to delete more services from the register.

11. Procedure for smart card services as claimed in patent claim 5 or 6, c h a r a c t e r i z e d in that the user can, via the dialog in the dialog box, specifically select to store service in the register at/in the smart card.

12. Procedure for smart card services as claimed in patent claims 5-6, c h a r a c t e r i z e d in that the user can, via the dialog in the dialog box, specifically select to delete service in the register at/in the smart card.

13. Program comprising/including program steps for execution of the steps in a procedure according to any of the patent claims 5-12.

14. Terminal with readable medium including instructions for execution of the steps in procedure according to any of the patent claims 5-12.