WO2004040884A1 - Implementing a service, particularly a financial service, in a network involving mobile terminals - Google Patents

Implementing a service, particularly a financial service, in a network involving mobile terminals Download PDF

Info

Publication number
WO2004040884A1
WO2004040884A1 PCT/FI2003/000807 FI0300807W WO2004040884A1 WO 2004040884 A1 WO2004040884 A1 WO 2004040884A1 FI 0300807 W FI0300807 W FI 0300807W WO 2004040884 A1 WO2004040884 A1 WO 2004040884A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
user
mobile terminal
definition
server
Prior art date
Application number
PCT/FI2003/000807
Other languages
French (fr)
Inventor
Pekka JÄRVINEN
Pekka Lehti
Ulla-Maija Uusitalo
Kimmo Ikonen
Sirpa Liukkonen
Original Assignee
Meridea Financial Software Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Meridea Financial Software Oy filed Critical Meridea Financial Software Oy
Priority to EP03758179A priority Critical patent/EP1557029A1/en
Priority to AU2003274198A priority patent/AU2003274198A1/en
Priority to JP2004547684A priority patent/JP2006505165A/en
Publication of WO2004040884A1 publication Critical patent/WO2004040884A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card payments
    • G06Q20/3563—Software being resident on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities

Definitions

  • the invention concerns the technical field of using mobile terminals for accessing certain services. Especially the invention concerns the task of facilitating easy and flexible use of financial services through the mobile terminals of a network.
  • Mobile terminals first gained truly widespread acceptance in the form of mobile telephones, which has had a strong influence on the development of user interfaces for mobile terminals.
  • the most widespread format of a user interface in a mobile terminal consists of a microphone, a loudspeaker, an alarm buzzer, a relatively small display and a keypad with a slightly more than a dozen individual keys.
  • the small keypad of his mobile terminal to type in an inquiry message that includes at least a message type identifier that identifies the message as a balance check, the number of the account the balance of which is to be checked, a username and a password.
  • the user After having completed the message, the user must select a "transmit message" functionality, type in the SMS service number of his bank or scroll through a list or previously stored numbers to find it there, and release the message for transmission.
  • SMS-based service employs usernames and passwords for providing security, it requires the user to remember these or to carry around a paper slip or similar memory aid. It is possible to leave out usernames and passwords if the service relies only on the capability of a cellular radio system in identifying subscribers, but such a service is only as secure as the cellular radio system, which frequently is not enough.
  • An additional objective of the invention is that each user can tailor the services so offered to suit his personal needs without sacrificing the ease of use.
  • a further objective of the invention is that the services can be offered to users substantially irrespective of the types of mobile terminals they are using.
  • a yet further objective of the invention is that the services so offered could be open for modification by both users and service providers, according to the needs that concerns every particular service.
  • the objectives of the invention are achieved by allowing the mobile terminals of users to be programmed so that only a single key press, a very short sequence of key presses or a similar very simple activation of the user interface launches the use of a service in a way which the user and/or the service provider has configured beforehand.
  • a method according to the invention is characterized by the features that are recited in the characterizing part of the appended independent claim directed to a method.
  • a mobile terminal according to the invention is characterized by the features that are recited in the characterizing part of the appended independent claim directed to a mobile terminal.
  • a system according to the invention is characterized by the features that are recited in the characterizing part of the appended independent claim directed to a system.
  • the present invention is based on the insight that despite of a veritable proliferation of services that are available for the users of mobile terminals, each user will have a relatively small selection of services that he will use regularly. It is therefore possible to associate such often used services with certain parts or features of even a relatively simple user interface, so that a minimal interaction by the user, such as pressing one key, executing a simple sequence of key presses, or tapping one icon, can be unambiguously associated with the user's intention to use a particular service.
  • the mobile terminal notices that the user gives such a dedicated yet simple activation command, it launches the use of the appropriate service, executing independently even complicated sequences of operations so that as a result the user gets the service he wanted.
  • the services involve not only the mobile terminal itself but a system that comprises a cellular radio network, potentially a wired data transmission network as well as fixed installations such as service providers' servers.
  • a service means that there is some communication between a mobile terminal and a server through the cellular radio network and the potential wired data transmission network.
  • at least certain occasions of using a certain service may include actions of a mobile terminal only, but even in such cases the mobile terminal typically utilizes information that it has obtained earlier from a server provider's server.
  • Another extreme case is such where the mobile terminal has only the function of a command interpreter and link, so that an activation of a service causes the mobile terminal to transmit a certain command message, and all other activities related to the use of the service are performed at the server.
  • a central feature of the present invention is the ability of a user and/or a service provider to tailor a certain service exactly to the needs of an individual user, without compromising the ease of use that follows from the simple way of activating the service at the user's mobile terminal.
  • This aspect of the invention is called the service definition aspect. It ecompasses a multitude of variations of how should the actual task of defining and tailoring the service be accomplished. Three basic branches of such variations are dynamic definition, programmatic definition and definition by the service provider.
  • Informational usage refers to services where the user obtains some useful simple information, like the current balance of a certain account.
  • Analytical usage refers to services where the user obtains more descriptive information about the status and/or history of his assets.
  • Advisory usage refers to services through which the user can obtain suggestions about what should he do with his assets.
  • Transactional usage refers to services through which the user can commit financial transactions.
  • Device independence is achieved in the invention through the use of a specific execution language for defining the operations that various devices must accomplish when using the services in question. The only thing that is then required from the various devices is that they are either capable of understanding and executing said specific execution language, or that they rely on other devices that convert instructions given in said specific execution language into some other, more standardized form of communication.
  • Fig . 1 illustrates a framework for application of the present invention
  • f fiigg.- 2 2 illustrates schematically a mobile terminal according to an embodiment of the invention
  • fig- 3 illustrates the roles of execution language and its handling
  • fig. 4 illustrates an example of dynamically defining a service
  • fig- 5 illustrates programmatic service definition with a text editor
  • f fiigg.. 6 6 illustrates programmatic service definition with an application development system with a graphical user interface
  • fig- 7 illustrates a mobile terminal based service execution scenario
  • fig. 8 illustrates a distributed service execution scenario in a mobile terminal and server
  • f fiigg.. illustrates a framework for application of the present invention
  • f fiigg.- 2 2 illustrates schematically a mobile terminal according to an embodiment of the invention
  • fig- 3 illustrates the roles of execution language and its handling
  • fig. 4 illustrates an example of dynamically defining a service
  • fig- 5 illustrates programmatic service definition with
  • FIG. 9 9 illustrates a modification of a distributed service execution scenario in a mobile terminal and server
  • fig- 10 illustrates communication between several entities during the use of a financial service according to the invention
  • fig- 11 illustrates the concept of branching from a script to client programs
  • f fiigg.- 1 122 illustrates certain system level aspects of the invention.
  • Fig. 1 illustrates the framework within which services are typically used in accordance with the invention.
  • a user 101 has at his disposal a mobile terminal 102, which is capable of communicating wirelessly with a cellular radio network 103. From the last-mentioned there is a bidirectional data transfer connection to a wired data network 104, to which also a service provider's server 105 is connected.
  • An operator's interface 106 is available for controlling the operation of the server 105.
  • the user 101 gives a service activation signal through a user interface of the mobile terminal 102.
  • This causes the mobile terminal 102 to execute a series of operations, the result of which is a certain message that the mobile terminal 102 transmits to the cellular radio network 103 at step 112.
  • the cellular radio network 103 forwards the message to the wired data network 104, which forwards it further to the server 105 at step 114.
  • the server 105 receives the message from the mobile terminal 102 and responds by performing certain operations, which typically results into a response message being sent from the server 105 to the mobile terminal 102 at step 121.
  • Steps 122 and 123 describe the transmission of the response message through the wired data network 104 and the cellular radio network 103 to the mobile terminal 102.
  • the mobile terminal 102 executes certain final operations that include at least displaying to the user 101 certain information that came in the_ response message.
  • the present invention aims at arranging the operation of all parts of the system shown in Fig. 1 so that step 111 would be as simple as possible, comprising only minimal required interaction from the user 101. This must be accomplished together with the equally important goal according to which at step 124 the user gets exactly the kind of personalized response that he wanted to get by using this particular service.
  • Fig. 2 is a schematic representation of certain parts of a mobile terminal that have importance to using services in accordance with the present invention.
  • Each mobile terminal has a processor 201 that executes programs stored in a program memory 202.
  • the processor 201 also communicates with the user interface components 203 of the mobile terminal, e.g. for receiving key commands through a keypad and for displaying information on a display screen, through certain user interface drivers 204.
  • the mobile terminal comprises a radio transceiver 205 for implementing wireless communications with a cellular radio network.
  • the relationship between certain input (key commands) that the processor 201 received through a user interface and a corresponding function was tightly fixed, with flexibility existing only in the form of certain softkeys.
  • a personalized service must be available for use, i.e. it must be possible to make the mobile terminal execute a certain customized series of actions, by only pressing one key, by executing a very simple sequence of key presses or by otherwise performing a very simple activating action through the user interface. Therefore the invention requires the program memory 202 (or the Ul drivers section 204) to comprise an easily reprogrammable Ul command interpretation unit 211. Associating a service with a certain simple activating action through the user interface means that the Ul command interpretation unit 211 is programmed to respond to such a simple activating action by issuing a command to the processor 201 to start the customized series of actions that constitutes the mobile terminal's part of such a service.
  • Blocks 212 and 213 shown in fig. 2 are related to the concept of an execution language. According to the invention, it is advantageous to specify a certain execution language that constitutes a standardized, device-independent way of describing actions to be taken by a device that takes part in providing a service.
  • the execution language should allow developers to define the creation and execution of platform-independent and parameterized processes in a uniform way and provide the means to hook these processes, or activities, with each other into entities that together form complete instructions for the operation of the devices involved.
  • the execution language must comprise at least the suitable language means for defining the business logic of single, independent activities.
  • the execution language provides means for configuring activities in various ways: for example limits may be placed on time of execution of an activity, and an activity may be characterised by its requirements concerning execution order, like whether an activity may be run concurrently or in parallel with other activities or whether sequential execution is required.
  • Mechanisms defined in the execution language should include exception signalling, as well as support for receiving input and producing output in an application- independent way.
  • the exact form and content of the execution language is not important to the present invention, as long as the execution language serves to achieve the described objectives.
  • Fig. 3 illustrates further the role of an execution language in defining a service.
  • a certain way of defining a service i.e. generating a definition of what should certain device(s) do in order to provide a user with the service he wants.
  • Some alternative ways of defining the service will be described later; for the time being it suffices to assume that a certain service-defining process exists. This process has been schematically represented as 301 in fig. 3.
  • the result of the service-defining process 301 is an execution language script 302.
  • the execution language script 302 is as such not directly suitable for execution by a processor.
  • the execution language script 302 is readily suitable for storing in a memory and for communicating from one device to another according to some suitable communication protocol.
  • the execution language script 302 is a kind of programmatic representation of the service in a nice, compact packet.
  • a process of execution language script parsing 303 is needed.
  • the parsing step 303 produces an executable program 304.
  • the program 304 does not need to be self-contained and fully processable in the sense that it would always consist of only processor-executable instructions. For example certain passages of execution language may remain encapsulated at certain parts of the program 304, for example if they represent complicated features that will only be needed under very rarely occurring circumstances so that it is more economical to parse them only if they are really needed, or if they contain passages of execution language that must be transmitted to another device or process to be parsed and executed there.
  • the executable program is then passed on to an execution process proper 305, which causes the device(s) in question to act so that the user gets the service he wanted.
  • the program memory 202 of the mobile terminal is shown to comprise certain memory space 212 reserved for storing execution language scripts. Additionally the program memory 202 of the mobile terminal is shown to store an execution language parser program, through the execution of which the processor 201 can parse execution language scripts into executable programs.
  • a further functionality that a mobile terminal according to the invention will need is a communication method, because acting according to the user's wishes for providing a service will inevitably include exchanging information with other devices, particularly with servers.
  • the messaging application 214 stored in the program memory 202 contains instructions through the execution of which the processor 201 is capable of transmitting and receiving messages that are related to the services that the user wishes to use.
  • certain points in an executable program that was a result of parsing an execution language script trigger the processor to activate the messaging functionality and to use it for communication with other devices.
  • SMS Short Messaging Service
  • MMS Multimedia Message Service
  • Dynamic definition in general means that the user instructs a device to follow and memorize his actions when he performs manually an act of using a service.
  • Fig. 4 is a schematic representation of a simple exemplary series of events during dynamic definition of a service.
  • the user wants to define a service for inquiring for a piece of information, like an account balance.
  • the user initiates dynamic service definition, which causes the normal, manually operated functions of the terminal device to call a dynamic service definition application at step 402 and to put is into a state of readiness.
  • the dynamic service definition application After the dynamic service definition application has been invoked at step 402, it monitors the actions of the user and the manually operated routines in order to find out, how should the dynamically defined service proceed.
  • the user initiates a message inputting application.
  • this action of the user is forwarded to the dynamic definition application at step 404, it stores at step 405 an execution language representation of a step of initiating automatic generation of a message.
  • the user types in the contents of a query message, which when forwarded at step 407 causes the dynamic definition application to store the contents of the query at step 408.
  • the user decides that the message is complete and initiates message transmitting; again information about this action is forwarded to the dynamic definition application at step 410 and it stores at step 411 an execution language representation of a step of initiating message transmitting.
  • Steps 412, 413 and 414 represent selection of a number into which the query message is to be transmitted and storing a corresponding number selection command in the dynamically defined service.
  • Steps 415, 416 and 417 represent the user giving his final permission to transmitting the query message, which permission is stored in the dynamically defined service as a command to transmit the query message to the stored number.
  • the mobile terminal Shortly after the query message has been sent, the mobile terminal receives a response from the server to which it sent the query.
  • the terminal device informs the user about a received response.
  • Information about a received response is also given to the dynamic definition application at step 419, which causes it to store at step 420 an execution language representation of the fact that a response message is to be expected.
  • the user commands the terminal to display the response message, which command when forwarded to the dynamic definition application at step 422 causes it to store an automatic initiation of response displaying at step 423.
  • the user gives at step 425 a command to end the dynamic definition of a service. This command is forwarded at step 426 to the dynamic definition application, which stores the completed script at step 427.
  • an execution language script After an execution language script has been stored, it is necessary to associate it with a certain simple activation command through which the user wishes to activate the use of the service at later occasions.
  • the mobile terminal will prompt the user to press the key that he wishes to associate with the newly generated script, or otherwise give an example of the activation command that should be used.
  • the stored script automatically appears as a representative icon in a graphical user interface, so that activating that icon will trigger the use of the corresponding service.
  • the dynamic definition application then stores information about the given activation command, and reprograms the programmable user interface command interpreter (211 in fig. 2) so that when that particular command is received through the interface, a the processor of the mobile terminal is instructed to initiate a process of parsing the execution language script and executing the resulting executable program.
  • the dynamic definition application must have a quite low level access to what is happening in the mobile terminal: for example in the case of fig. 4 it should be able to detect single key presses and the occurrence of a response message having been received. This tends to imply that the dynamic definition application can hardly be completely device independent. If it were only a feature of a certain device independent high level application program, it could well be used for tracking events that concern directly the activities of such an application program, but it could not have access to what is going on outside the specific application program.
  • vigation paths refers to the actual physical actions that a user made during the dynamic definition of a service. Physically speaking, when the user e.g. initiates the message inputting application, he typically presses one key that may well be a softkey so that the action it causes depends on the context; at that moment the effect of the softkey was just indicated to be the initiating of a message inputting application.
  • the dynamic definition application should not store just the information "softkey XX was pressed", because later when the dynamically defined service is used, the context may be different so that a service that just emulated the press of a softkey at a certain moment might well cause something unexpected to happen.
  • the dynamic definition application should be smart enough to notice that by pressing that softkey the user meant to initiate the message inputting application, so that in the resulting execution language script it includes a command "initiate message generation” instead of "emulate pressing softkey XX".
  • Figs. 5 and 6 illustrate schematically two exemplary possibilities of programmatic service definition. It is possible to use a conventional text editor 501 to write aombre service description as if it was a conventional computer program. Depending on the definitions of the execution language it may be possible to write a service description directly in the execution language, but it is likewise possible to write the service description in some more common and more easily comprehensible programming language and use a converter program to convert such a preliminary service description into an actual execution language script.
  • Fig. 6 illustrates schematically the use of a graphical user interface for composing a service description. In the presented exemplary case the graphical user interface consists of a function library 601 and a workspace 602.
  • the task of the person that composes a service description is to select suitable functions from the function library 601 and to use them to build a graphical representation (a flow diagram) of the service in the workspace 602.
  • the application development system that offers a graphical user interface to the user is then responsible for collecting pieces of precomposed script that correspond to the selected functions and to combine them in a way that corresponds to the service definition structure built by the user.
  • This kind of computer-aided programming is well known as such from the technology of general-purpose application development systems.
  • a programmatic service definition scenario can rely heavily on preprogrammed library functions. These are passages of execution language script that have been written to both fulfil an actual functional task and to contain an application interface that enables their use as building blocks of any desired service command flow.
  • An example of a library function could be a function "acquire secure connection", which would be built to detect and utilize any currently available possibilities for setting up a secure communication connection to a given destination address.
  • the functional task of such an exemplary library function would be the actual setting up of a connection, while the application interface would consist of a standardized input format in which the function would accept the destination address from any freely selected other part of execution language script, as well as the inter-process communication means by which the function would detect the presence and availability of various means of secure communication.
  • a library function component must typically declare itself to be a "subtask" for an operating system to be able to handle it properly.
  • a third possible service definition scenario is definition by the service provider. This scenario does not necessarily differ much from a programmatic service definition in actual implementation, but the important difference is that a service provider and not a user is responsible for defining the service and for offering it to be used by users. From the user's point of view this is by far the simplest way of service definition, with the obvious obverse that it does not offer as much possibility of tailoring the services exactly to individual needs. The user may acquire such a service for example by bringing his mobile terminal to a branch office of the service provider for installation, or by downloading the required script(s) from a web page.
  • a service defined by the service provider might well consist of two parts, of which only a simple activating (and potentially result displaying) part runs in the user's mobile terminal and a more complicated processing part runs in the service provider's server.
  • Figs. 7, 8 and 9 illustrate certain principal alternatives for service execution scenarios.
  • Fig. 7 is a simple terminal-based execution scenario that may include an optional earlier information transfer step 701 from a service provider's server to a mobile terminal, but after that all steps take place locally at the mobile terminal.
  • the user activates the use of a service by giving a simple activation command.
  • the mobile terminal parses a script that represents the selected service, and at step 704 it processes the service according to the executable instructions that resulted from the parsing step.
  • the results are displayed to the user.
  • Fig. 8 illustrates a more interactive service execution scenario, in which also the server has an active role.
  • the user of a mobile terminal activates the use of a service by giving a simple activation command.
  • the mobile terminal parses a script that represents the selected service, and at step 803 it formulates a request message to the server according to the executable instructions that resulted from the parsing step.
  • the request message is transmitted to the server, which processes the request at step 805 and transmits a response at step 806.
  • the mobile terminal receives and processes the response message to put the results of the service into a form in which they can be presented to the user, and at step 808 the results are displayed.
  • figs. 9 the activation step 901 may be followed by a script parsing and local processing steps 902 and 903, but in any case the request message that the mobile terminal transmits to the server at step 904 contains also certain passages of yet unparsed script.
  • the server parses such passages of script, and/or transforms them into sonie server specific macro language that is used for controlling the operations of the server.
  • step 905 it is possible to arrange step 905 to be performed at an auxiliary "interpreter" device either so that script-containing requests from mobile terminals automatically go first to such an interpreter device or so that when a service provider's server encounters a request that contains script, it forwards it to the interpreter device for parsing the script.
  • the interpreter device then forwards parsed instructions to the actual service-providing server in a form that is acceptable to the latter.
  • An interpreter device may be for example a trusted auxiliary interpreter server hidden behind an actual service provider's server, which has no native parsing capability.
  • the server processes the request, and at step 907 it transmits a response message to the mobile terminal.
  • This response message could comprise passages of script as well. If that is the case, the response processing step 908 at the mobile terminal must include some script parsing as well.
  • the results of the service are displayed. If passages of script are transmitted between the mobile terminal and the server, they must be wrapped into some conventional communication protocol: for reasons of compatibility it cannot be required that any other device that takes part in the communication between the mobile terminal and the server should be able to understand or act according to the script.
  • a division of work between the mobile terminal and the server does not preclude the mobile terminal from performing some service-related processing also during the time when it waits for a response from the server.
  • Using a service at the mobile terminal may comprises two or more parallel processing paths, the execution of which may be concurrent and at least partly independent from each other. All service-related transmissions between the mobile terminal and the server should be encrypted in order to provide security.
  • the communication protocol(s) used for communication over the wireless communication link should include optimization features that take into account the specific nature of wireless links; such optimization features are known and very well developed for example in WAP.
  • a first service usage scenario is informational usage, which can be characterised as offering answers to the question "what am I doing?".
  • a user has typically certain financial assets, like bank accounts, a current state of which can be easily characterised by a simple number or character string.
  • simple information is typically highly confidential, which means that a service for inquiring and providing such information must include security features for ensuring that only an authorized user has access to the information.
  • Typical examples of information of this kind are account balances, remaining monthly credit of a credit card, or the current content of a stocks portfolio.
  • a second service usage scenario is analytical usage, which is close to the first one described above but is understood to encompass a somewhat wider scope of information.
  • Analytical services may be understood as answering the question “how am I doing?". So instead of or in addition to a remaining monthly credit the user might be interested in accumulated debiting on his accounts over a certain period, classified according to a certain prestored model.
  • a third service usage scenario is advisory usage, which goes even further from analytical usage in that the user wants to know not only the developments so far, but also certain prospects of the future and/or suggested financial actions.
  • the illustrative question is "what should I do?", and the information looked after in the service may include e.g. investment tips that take into account a predefined risk- taking profile.
  • a fourth service usage scenario is transactional usage, which differs from the three others mentioned above in that instead of or in addition to just receiving information the user wants to actively accomplish something, like paying bills or making investment decisions.
  • a mobile communication device includes a so-called electronic safe store, which is a specifically protected memory circuit for safely storing information of this kind.
  • An electronic safe store is even suitable for storing electronic cash, which as a term refers to cryptographically authenticated pieces of digital information that parties in commerce agree to have certain monetary value so that they can be used as tenders for debts. It is possible to give a service according to the invention access to the electronic safe store of the user, which further streamlines the use of financial services in accordance with the invention.
  • Fig. 10 illustrates a situation where the user first wants to check the balance of his account than then decides to download some electronic cash into his electronic safe store.
  • the user activates a banking service with a simple activation command according to the invention.
  • the user has previously tailored the service so that it always begins with a balance check.
  • the bank will not give the balance information unless the corresponding request message was cryptographically authenticated and contains the correct identifiers; means for cryptographical authentication as well the user's identifiers are stored in the electronic safe store of the mobile terminal. Therefore the terminal requests the appropriate protected information from the safe store at step 1002.
  • the safe store may be further configured so that it will not become available without a PIN number being given online; therefore the optional PIN request and PIN inputting steps 1003 and 1004 are shown in fig. 10.
  • the electronic safe store returns the requested information at step 1005.
  • the other parts of the terminal utilize this information to compose a properly identified and cryptographically authenticated message to the server at step 1006.
  • PIN giving or similar strictly user-dependent authentication - known alternatives to PIN giving exist and include e.g. electronic fingerprint reading, speech sample analysis and optically scanning the iris of the eye
  • two approaches are possible. The first of them involves requiring the user to be present and to authenticate himself to the mobile terminal every time when the electronic safe store in the mobile terminal must be accessed. This approach represents ultimate safety, because it vitiates even well-timed attempts of stealing a mobile terminal during the execution of a script, after the legitimate user has authenticated himself but before he has availed himself of any advantage that would involve utilizing the contents of the electronic safe store.
  • the other approach is based on requiring the user to authenticate himself once, after which the script to be currently executed becomes a trusted representative of the user in the sense that it may access the electronic safe store by its own without requiring the user to repeat the authentication step during the period of executing the script.
  • the latter approach is more convenient to the user, and also reasonably safe at least if the time it takes to execute such a "trusted script" remains below a reasonable limit.
  • a script that has once acquired the status as the user's trusted representative may keep that status ever since (or for a predetermined time, or predetermined number of times of using the service), or then the status as the user's trusted representative only lasts until the end of that particular occasion of using the service, in which latter case the script has to re-acquire the status every time when the script is started anew.
  • the electronic safe store it is also possible to utilize the electronic safe store to store the script itself or at least major parts of it. In that case the user must authenticate himself at the very beginning of the execution of a script, and the safely stored script is as safe from unauthorized tampering as anything else stored in the electronic safe store.
  • the first request message is a balance check
  • the server responds at step 1007.
  • the response message comes in cryptographically protected form, and the terminal is not able to decrypt and verify it without first consulting the electronic safe store again at steps 1008 and 1009.
  • the terminal displays it to the user at step 1010.
  • Fig. 11 illustrates schematically an alternative approach.
  • the horizontal bar 1101 illustrates the execution of a parsed script, advancing from the left to the right, so that at moment 1102 the user causes the execution to start by giving a very simple activation command according to the invention.
  • the use of the service in question proceeds as determined in the script until moment 1103, at which the user is given the possibility of making a selection. It is possible to define a default case according to which no selection or the simplest selection possible expressed at moment 1103 causes the use of the service to proceed according to a basic alternative defined in the script itself. Another selection made by the user and expressed in a simple selection command given through the user interface causes the use of the service to divert into a client program 1111, the execution of which starts at moment 1112.
  • the client program 1111 may be defined in another script, or it may be some completely different, even device-dependent other functionality like a messaging application.
  • the client program 1111 in turn offers the user certain selections regarding its termination at alternative moments 1113, 1114 or 1115. Terminating the use of the client program at any of these moments causes a return to the use of the basic service; here we have additionally assumed that terminating the use of the client program at each of these moments causes a return to a different point 1106, 1105 or 1107 respectively of the basic service.
  • Another exemplary client program is illustrated as the block 1121. It is started if the user expresses a certain selection at a point 1104 of using the basic service that is defined in the script. Executing the simple, no-selections-involved second client progam proceeds from moment 1122 to moment 1123, after which a return occurs to exactly that point in the "master" service at which a diversion to the client program 1121 occurred.
  • a client program may be responsible for arranging a more elaborate communication between a user and his mobile terminal than what is possible or reasonable to realize by means of a simple script. If a suitable client program is not permanently resident in the mobile terminal of a user, making a certain selection during the execution of a parsed script may trigger the operation of fetching and downloading a suitable client program from a certain predefined location in a network.
  • the execution language script may support a generic interface towards plugin-type external function modules, that may be interchangeable without altering the rest of the steps of using a service.
  • a generic interface may exist towards plugin-type modules for setting up a safe communication connection.
  • the execution language script may adapt to the use of any of a multitude of possible ways of setting up a safe communication connection, without paying attention to what are the specific features of the selected method.
  • Modules that could utilize a generic interface definition include but are not limited to communication setup modules, user authentication modules, man-machine-interface maintaining modules and timing modules in the form of clocks, timers and calendars.
  • the selections at the various selection points may include a feature according to which pressing always the same single key, or otherwise giving always the same simple command that triggered the start of the basic service itself, causes the use of the service to proceed according to the default route, which in fig. 11 means proceeding through the bar 1101 from left to right without making diversions to any client programs. This would be the easiest for a user to learn and understand, since it is natural to associate the simplest and most familiar of commands to the simplest and most often needed way of proceeding through the use of a service.
  • the results obtained through the use of a client program may have influence on how the use of the basic service proceeds from that moment at which a return to the basic service occurred. For example if a client program was initiated for transmitting a request message to a stock exchange server for getting the latest stock price quote for a certain company and for receiving a response message, and the response message indicated that a certain predefined price limit has been exceeded, the basic service may treat this information as a parameter value that triggers a suggestion to the user to commence offering his stocks for sale.
  • the use of clients in accordance with the present invention is most typical in services having certain transactional nature.
  • allowing a service according to the invention to control the user interface means that the reprogrammable user interface command interpreter block 211, is responsive also during the processing of a service.
  • the processor 201 is arranged to drive a display to show the temporary meanings of the softkeys, so that pressing a particular softkey causes a particular continuation to be selected in processing the service.
  • the server responds by transmitting the requested electronic cash in a message the decryption and authentication of which necessitates a further consultation of the electronic safe store at steps 1016 and 1017.
  • the terminal performs the action ordered in the message from the server, i.e. stores the newly received electronic cash into the electronic safe store.
  • an indication is given to the user about the completion of the requested task.
  • the user terminates the current use of the banking service.
  • a mobile terminal will only accept and store a script that contains the digital signature of a recognized service provider;
  • the mobile terminal shall ask for the user's approval before storing a script for later use, and the user can at any time check the number and nature of scripts stored in his terminal and remove possible unwanted or unnecessary scripts;
  • the service provider's server shall only respond to communications contacts that have been generated by authenticated, i.e. appropriately signed scripts and that contain some cryptographic verification of this fact.
  • the service for the use of which a user wants to apply the present invention may well be such that it does not necessarily require its use to be automated in the way described in the present invention.
  • the user might well use the same service "manually", e.g. by keying in the request messages by hand.
  • a simple way to achieve such discrimination ability is to require that in the course of a user authentication process, a first identifier is selected (e.g. read from an electronic safe store) if manual use is involved, and a second, different identifier is selected instead (or in addition thereto) if a script was responsible for the use of the service.
  • Fig. 12 illustrates certain overall system aspects concerning the invention.
  • Two communications networks are involved, one of which is a cellular radio network
  • a user has two different types of terminals at his disposal: a wireless terminal 1203 for actually using services according to the invention and a more versatile but potentially larger, heavier and clumsier wired terminal 1204.
  • the wireless terminal 1203 contains at least a programmable user interface, which the user may adapt to accept an ultimately simple starting command for the use of a particular service according to the invention, as well as downloading and communication capability for downloading scripts from service definition server(s) and for exchanging messages related to the use of services with service provider's server(s).
  • the wired terminal 1204 contains a network connection and a browser program for contacting service definition servers and for using them to define and edit user-tailored services.
  • a service definition server 1205 has a network connection to the wired data network
  • a service provider's server 1206 which may even be physically the same as a service definition server 1205, must contain the actual service application as well as a communication interface for bidirectionally communicating with mobile terminals during the course of a user using a certain service.
  • the capability of parsing execution language scripts resides in the user's mobile terminal 1203.
  • the mobile terminal can do completely without parsing capability, if enough such capability exists elsewhere in the system.
  • the mobile terminal includes some native mechanism for executing a series of commands in a device-depending command language and for associating the beginning of such executing to some simple user interface command, which the user wants to associate with a certain service.
  • the service definition server 1205 is capable of parsing an execution language script into a device-dependent command series.
  • Another alternative is that users may acquire conversion programs to their wired terminals.
  • the user may download the script into his wired terminal 1204, convert it into a device-dependent command series and forward the result to his mobile terminal 1203 through the networks 1201 and 1202 or through a local short- distance link. If the steps of defining the service and composing the script took place at the user's wired terminal 1204, no script downloading is needed but the converting and forwarding steps are performed in a similar manner.

Abstract

A method and arrangements are presented for providing a user with a service from a server (105, 1206) coupled to a communications network (103, 104, 1201, 1203). A definition (302) of automatically using the service is stored (427) into a mobile terminal (102, 1203) of the user. Said mobile terminal (102, 1203) is reprogrammed to associate a certain input command given through a user interface of said mobile terminal with starting the use of the service. As a response to receiving (702, 801, 901, 1001) said certain input command after the step of reprogramming said mobile terminal has been accomplished, the use of the service according to said definition commences. The use of the service comprises communicating information (112, 113, 114, 121, 122, 123) between said mobile terminal (102, 1203) and the server (105, 1206) through the communications network (103, 104, 1201, 1203).

Description

Implementing a service, particularly a financial service, in a network involving mobile terminals
The invention concerns the technical field of using mobile terminals for accessing certain services. Especially the invention concerns the task of facilitating easy and flexible use of financial services through the mobile terminals of a network.
Mobile terminals first gained truly widespread acceptance in the form of mobile telephones, which has had a strong influence on the development of user interfaces for mobile terminals. The most widespread format of a user interface in a mobile terminal consists of a microphone, a loudspeaker, an alarm buzzer, a relatively small display and a keypad with a slightly more than a dozen individual keys.
Attempts to provide versatility to the selection of services that a user can access through his mobile terminal have repeatedly encountered difficulties that arise from the limited size and limited functionalities of the traditional user interface. Exemplary solutions of this kind are presented e.g. in patent publications EP 0 972 275 and WO 96/13814. As an illustrative example we may consider a user that wants to check the balance of his bank account by using text messages, like the well-known SMS messages (Short Message Service). First the user must invoke the SMS application program of his mobile terminal and select the functionality of writing an SMS message. Then he must use the small keypad of his mobile terminal to type in an inquiry message that includes at least a message type identifier that identifies the message as a balance check, the number of the account the balance of which is to be checked, a username and a password. After having completed the message, the user must select a "transmit message" functionality, type in the SMS service number of his bank or scroll through a list or previously stored numbers to find it there, and release the message for transmission.
Typically the number of key presses that are required for a complete balance check operation is in the order of several dozens. As an additional drawback the process includes several inherent error sources: for example a single erroneous key press during typing of the message will cause the whole operation to fail. If the SMS- based service employs usernames and passwords for providing security, it requires the user to remember these or to carry around a paper slip or similar memory aid. It is possible to leave out usernames and passwords if the service relies only on the capability of a cellular radio system in identifying subscribers, but such a service is only as secure as the cellular radio system, which frequently is not enough.
It is an objective of the present invention to provide a method and apparatus for offering easy-to-use, secure and versatile services to the users of mobile terminals. An additional objective of the invention is that each user can tailor the services so offered to suit his personal needs without sacrificing the ease of use. A further objective of the invention is that the services can be offered to users substantially irrespective of the types of mobile terminals they are using. A yet further objective of the invention is that the services so offered could be open for modification by both users and service providers, according to the needs that concerns every particular service.
The objectives of the invention are achieved by allowing the mobile terminals of users to be programmed so that only a single key press, a very short sequence of key presses or a similar very simple activation of the user interface launches the use of a service in a way which the user and/or the service provider has configured beforehand.
A method according to the invention is characterized by the features that are recited in the characterizing part of the appended independent claim directed to a method.
The invention applies also to a mobile terminal. A mobile terminal according to the invention is characterized by the features that are recited in the characterizing part of the appended independent claim directed to a mobile terminal.
Additionally the invention applies to a system that comprises mobile terminals and at least one server for providing services to the users of the mobile terminals. A system according to the invention is characterized by the features that are recited in the characterizing part of the appended independent claim directed to a system.
Various advantageous embodiments of the invention are described in the depending claims.
The present invention is based on the insight that despite of a veritable proliferation of services that are available for the users of mobile terminals, each user will have a relatively small selection of services that he will use regularly. It is therefore possible to associate such often used services with certain parts or features of even a relatively simple user interface, so that a minimal interaction by the user, such as pressing one key, executing a simple sequence of key presses, or tapping one icon, can be unambiguously associated with the user's intention to use a particular service. When the mobile terminal notices that the user gives such a dedicated yet simple activation command, it launches the use of the appropriate service, executing independently even complicated sequences of operations so that as a result the user gets the service he wanted.
In the context of the present invention we assume that the services involve not only the mobile terminal itself but a system that comprises a cellular radio network, potentially a wired data transmission network as well as fixed installations such as service providers' servers. Typically using a service means that there is some communication between a mobile terminal and a server through the cellular radio network and the potential wired data transmission network. As an extreme case at least certain occasions of using a certain service may include actions of a mobile terminal only, but even in such cases the mobile terminal typically utilizes information that it has obtained earlier from a server provider's server. Another extreme case is such where the mobile terminal has only the function of a command interpreter and link, so that an activation of a service causes the mobile terminal to transmit a certain command message, and all other activities related to the use of the service are performed at the server.
A central feature of the present invention is the ability of a user and/or a service provider to tailor a certain service exactly to the needs of an individual user, without compromising the ease of use that follows from the simple way of activating the service at the user's mobile terminal. This aspect of the invention is called the service definition aspect. It ecompasses a multitude of variations of how should the actual task of defining and tailoring the service be accomplished. Three basic branches of such variations are dynamic definition, programmatic definition and definition by the service provider.
Considering financial services according to the invention, four main categories of usage can be defined. Informational usage refers to services where the user obtains some useful simple information, like the current balance of a certain account. Analytical usage refers to services where the user obtains more descriptive information about the status and/or history of his assets. Advisory usage refers to services through which the user can obtain suggestions about what should he do with his assets. Transactional usage refers to services through which the user can commit financial transactions. Device independence is achieved in the invention through the use of a specific execution language for defining the operations that various devices must accomplish when using the services in question. The only thing that is then required from the various devices is that they are either capable of understanding and executing said specific execution language, or that they rely on other devices that convert instructions given in said specific execution language into some other, more standardized form of communication.
The exemplary embodiments of the invention presented in this patent application are not to be interpreted to pose limitations to the applicability of the appended claims. The verb "to comprise" is used in this patent application as an open limitation that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated.
The novel features which are considered as characteristic of the invention are set forth in particular in the appended claims. The invention itself, however, both as to its construction and its method of operation, together with additional objects and advantages thereof, will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings.
Fig . 1 illustrates a framework for application of the present invention, f fiigg.- 2 2 illustrates schematically a mobile terminal according to an embodiment of the invention, fig- 3 illustrates the roles of execution language and its handling, fig. 4 illustrates an example of dynamically defining a service, fig- 5 illustrates programmatic service definition with a text editor, f fiigg.. 6 6 illustrates programmatic service definition with an application development system with a graphical user interface, fig- 7 illustrates a mobile terminal based service execution scenario, fig. 8 illustrates a distributed service execution scenario in a mobile terminal and server, f fiigg.. 9 9 illustrates a modification of a distributed service execution scenario in a mobile terminal and server, fig- 10 illustrates communication between several entities during the use of a financial service according to the invention, fig- 11 illustrates the concept of branching from a script to client programs and f fiigg.- 1 122 illustrates certain system level aspects of the invention. Fig. 1 illustrates the framework within which services are typically used in accordance with the invention. A user 101 has at his disposal a mobile terminal 102, which is capable of communicating wirelessly with a cellular radio network 103. From the last-mentioned there is a bidirectional data transfer connection to a wired data network 104, to which also a service provider's server 105 is connected. An operator's interface 106 is available for controlling the operation of the server 105.
The most typical case of using a service according to the invention proceeds as follows. At step 111 the user 101 gives a service activation signal through a user interface of the mobile terminal 102. This causes the mobile terminal 102 to execute a series of operations, the result of which is a certain message that the mobile terminal 102 transmits to the cellular radio network 103 at step 112. At step 113 the cellular radio network 103 forwards the message to the wired data network 104, which forwards it further to the server 105 at step 114. The server 105 receives the message from the mobile terminal 102 and responds by performing certain operations, which typically results into a response message being sent from the server 105 to the mobile terminal 102 at step 121. Steps 122 and 123 describe the transmission of the response message through the wired data network 104 and the cellular radio network 103 to the mobile terminal 102. At step 124 the mobile terminal 102 executes certain final operations that include at least displaying to the user 101 certain information that came in the_ response message.
The present invention aims at arranging the operation of all parts of the system shown in Fig. 1 so that step 111 would be as simple as possible, comprising only minimal required interaction from the user 101. This must be accomplished together with the equally important goal according to which at step 124 the user gets exactly the kind of personalized response that he wanted to get by using this particular service.
Fig. 2 is a schematic representation of certain parts of a mobile terminal that have importance to using services in accordance with the present invention. Each mobile terminal has a processor 201 that executes programs stored in a program memory 202. The processor 201 also communicates with the user interface components 203 of the mobile terminal, e.g. for receiving key commands through a keypad and for displaying information on a display screen, through certain user interface drivers 204. Additionally the mobile terminal comprises a radio transceiver 205 for implementing wireless communications with a cellular radio network. In a typical prior art mobile terminal the relationship between certain input (key commands) that the processor 201 received through a user interface and a corresponding function was tightly fixed, with flexibility existing only in the form of certain softkeys. With a fixed relationship we mean that e.g. a key press on an alphanumeric key "3def always caused the processor 201 to receive one of the characters "3", "d", "e" or "f depending on the number of consecutive presses on the same key, but nothing else. The known softkeys have been keys next to a display unit, so that the processor has been able to indicate, with a word or symbol appearing on the display, the current effect of the key. However, the "programmable" different effects of softkeys have still been very strictly fixed in the factory-time programming of the mobile terminal.
According to the present invention a personalized service must be available for use, i.e. it must be possible to make the mobile terminal execute a certain customized series of actions, by only pressing one key, by executing a very simple sequence of key presses or by otherwise performing a very simple activating action through the user interface. Therefore the invention requires the program memory 202 (or the Ul drivers section 204) to comprise an easily reprogrammable Ul command interpretation unit 211. Associating a service with a certain simple activating action through the user interface means that the Ul command interpretation unit 211 is programmed to respond to such a simple activating action by issuing a command to the processor 201 to start the customized series of actions that constitutes the mobile terminal's part of such a service.
Blocks 212 and 213 shown in fig. 2 are related to the concept of an execution language. According to the invention, it is advantageous to specify a certain execution language that constitutes a standardized, device-independent way of describing actions to be taken by a device that takes part in providing a service. The execution language should allow developers to define the creation and execution of platform-independent and parameterized processes in a uniform way and provide the means to hook these processes, or activities, with each other into entities that together form complete instructions for the operation of the devices involved. The execution language must comprise at least the suitable language means for defining the business logic of single, independent activities. Additionally it is advantageous if the execution language provides means for configuring activities in various ways: for example limits may be placed on time of execution of an activity, and an activity may be characterised by its requirements concerning execution order, like whether an activity may be run concurrently or in parallel with other activities or whether sequential execution is required.
Mechanisms defined in the execution language should include exception signalling, as well as support for receiving input and producing output in an application- independent way. The exact form and content of the execution language is not important to the present invention, as long as the execution language serves to achieve the described objectives.
Fig. 3 illustrates further the role of an execution language in defining a service. We assume that there exists a certain way of defining a service, i.e. generating a definition of what should certain device(s) do in order to provide a user with the service he wants. Some alternative ways of defining the service will be described later; for the time being it suffices to assume that a certain service-defining process exists. This process has been schematically represented as 301 in fig. 3.
The result of the service-defining process 301 is an execution language script 302. Taking into account the assumption of device independency, the execution language script 302 is as such not directly suitable for execution by a processor. On the other hand the execution language script 302 is readily suitable for storing in a memory and for communicating from one device to another according to some suitable communication protocol. The execution language script 302 is a kind of programmatic representation of the service in a nice, compact packet.
In order to convert an execution language script 302 into a set of executable instructions for a processor to execute, a process of execution language script parsing 303 is needed. The parsing step 303 produces an executable program 304. The program 304 does not need to be self-contained and fully processable in the sense that it would always consist of only processor-executable instructions. For example certain passages of execution language may remain encapsulated at certain parts of the program 304, for example if they represent complicated features that will only be needed under very rarely occurring circumstances so that it is more economical to parse them only if they are really needed, or if they contain passages of execution language that must be transmitted to another device or process to be parsed and executed there. The executable program is then passed on to an execution process proper 305, which causes the device(s) in question to act so that the user gets the service he wanted. Referring back to fig. 2, the program memory 202 of the mobile terminal is shown to comprise certain memory space 212 reserved for storing execution language scripts. Additionally the program memory 202 of the mobile terminal is shown to store an execution language parser program, through the execution of which the processor 201 can parse execution language scripts into executable programs.
A further functionality that a mobile terminal according to the invention will need is a communication method, because acting according to the user's wishes for providing a service will inevitably include exchanging information with other devices, particularly with servers. The messaging application 214 stored in the program memory 202 contains instructions through the execution of which the processor 201 is capable of transmitting and receiving messages that are related to the services that the user wishes to use. Typically certain points in an executable program that was a result of parsing an execution language script trigger the processor to activate the messaging functionality and to use it for communication with other devices.
At the priority date of this patent application the most widespread and most readily available method for comrnunicating small pieces of data to and from mobile terminals is SMS (Short Messaging Service) messages. For the purposes of the present invention the selection of a communication method is not important: it may well be SMS, but other kinds of messaging applications like MMS (Multimedia Message Service) could as well be used. Because the specific features of a messaging application have little practical significance to their use together with the present invention, it is easy and straightforward to adapt the present invention to utilize also any future messaging applications that are yet unknown.
Next we will consider certain more detailed ways of implementing the service definition process that is schematically represented as 301 in fig. 3. There are at least three mutually alternative approaches to service definition: dynamic definition, programmatic definition and definition by the service provider.
Dynamic definition in general means that the user instructs a device to follow and memorize his actions when he performs manually an act of using a service. Fig. 4 is a schematic representation of a simple exemplary series of events during dynamic definition of a service. In this case the user wants to define a service for inquiring for a piece of information, like an account balance. At step 401 the user initiates dynamic service definition, which causes the normal, manually operated functions of the terminal device to call a dynamic service definition application at step 402 and to put is into a state of readiness. After the dynamic service definition application has been invoked at step 402, it monitors the actions of the user and the manually operated routines in order to find out, how should the dynamically defined service proceed.
At step 403 the user initiates a message inputting application. When this action of the user is forwarded to the dynamic definition application at step 404, it stores at step 405 an execution language representation of a step of initiating automatic generation of a message. At step 406 the user types in the contents of a query message, which when forwarded at step 407 causes the dynamic definition application to store the contents of the query at step 408. At step 409 the user decides that the message is complete and initiates message transmitting; again information about this action is forwarded to the dynamic definition application at step 410 and it stores at step 411 an execution language representation of a step of initiating message transmitting.
Steps 412, 413 and 414 represent selection of a number into which the query message is to be transmitted and storing a corresponding number selection command in the dynamically defined service. Steps 415, 416 and 417 represent the user giving his final permission to transmitting the query message, which permission is stored in the dynamically defined service as a command to transmit the query message to the stored number.
Shortly after the query message has been sent, the mobile terminal receives a response from the server to which it sent the query. At step 418 the terminal device informs the user about a received response. Information about a received response is also given to the dynamic definition application at step 419, which causes it to store at step 420 an execution language representation of the fact that a response message is to be expected. At step 421 the user commands the terminal to display the response message, which command when forwarded to the dynamic definition application at step 422 causes it to store an automatic initiation of response displaying at step 423. After the response has been displayed to the user at step 424, the user gives at step 425 a command to end the dynamic definition of a service. This command is forwarded at step 426 to the dynamic definition application, which stores the completed script at step 427.
After an execution language script has been stored, it is necessary to associate it with a certain simple activation command through which the user wishes to activate the use of the service at later occasions. Typically after the steps shown in fig. 4 the mobile terminal will prompt the user to press the key that he wishes to associate with the newly generated script, or otherwise give an example of the activation command that should be used. It is also possible that the stored script automatically appears as a representative icon in a graphical user interface, so that activating that icon will trigger the use of the corresponding service. The dynamic definition application then stores information about the given activation command, and reprograms the programmable user interface command interpreter (211 in fig. 2) so that when that particular command is received through the interface, a the processor of the mobile terminal is instructed to initiate a process of parsing the execution language script and executing the resulting executable program.
Certain considerations must be made regarding the "event listener" or dynamic definition application that is responsible for dynamically converting certain actions into passages of execution language script. The dynamic definition application must have a quite low level access to what is happening in the mobile terminal: for example in the case of fig. 4 it should be able to detect single key presses and the occurrence of a response message having been received. This tends to imply that the dynamic definition application can hardly be completely device independent. If it were only a feature of a certain device independent high level application program, it could well be used for tracking events that concern directly the activities of such an application program, but it could not have access to what is going on outside the specific application program.
Another consideration about the dynamic definition application is its dependency or non-dependency on the strict validity of certain "navigation paths", which term refers to the actual physical actions that a user made during the dynamic definition of a service. Physically speaking, when the user e.g. initiates the message inputting application, he typically presses one key that may well be a softkey so that the action it causes depends on the context; at that moment the effect of the softkey was just indicated to be the initiating of a message inputting application. When accomplishing its event tracking task, the dynamic definition application should not store just the information "softkey XX was pressed", because later when the dynamically defined service is used, the context may be different so that a service that just emulated the press of a softkey at a certain moment might well cause something unexpected to happen. The dynamic definition application should be smart enough to notice that by pressing that softkey the user meant to initiate the message inputting application, so that in the resulting execution language script it includes a command "initiate message generation" instead of "emulate pressing softkey XX".
Figs. 5 and 6 illustrate schematically two exemplary possibilities of programmatic service definition. It is possible to use a conventional text editor 501 to write a „ service description as if it was a conventional computer program. Depending on the definitions of the execution language it may be possible to write a service description directly in the execution language, but it is likewise possible to write the service description in some more common and more easily comprehensible programming language and use a converter program to convert such a preliminary service description into an actual execution language script. Fig. 6 illustrates schematically the use of a graphical user interface for composing a service description. In the presented exemplary case the graphical user interface consists of a function library 601 and a workspace 602. The task of the person that composes a service description is to select suitable functions from the function library 601 and to use them to build a graphical representation (a flow diagram) of the service in the workspace 602. The application development system that offers a graphical user interface to the user is then responsible for collecting pieces of precomposed script that correspond to the selected functions and to combine them in a way that corresponds to the service definition structure built by the user. This kind of computer-aided programming is well known as such from the technology of general-purpose application development systems.
A programmatic service definition scenario, regardless of its actual implementation, can rely heavily on preprogrammed library functions. These are passages of execution language script that have been written to both fulfil an actual functional task and to contain an application interface that enables their use as building blocks of any desired service command flow. An example of a library function could be a function "acquire secure connection", which would be built to detect and utilize any currently available possibilities for setting up a secure communication connection to a given destination address. The functional task of such an exemplary library function would be the actual setting up of a connection, while the application interface would consist of a standardized input format in which the function would accept the destination address from any freely selected other part of execution language script, as well as the inter-process communication means by which the function would detect the presence and availability of various means of secure communication. A library function component must typically declare itself to be a "subtask" for an operating system to be able to handle it properly. A third possible service definition scenario is definition by the service provider. This scenario does not necessarily differ much from a programmatic service definition in actual implementation, but the important difference is that a service provider and not a user is responsible for defining the service and for offering it to be used by users. From the user's point of view this is by far the simplest way of service definition, with the obvious obverse that it does not offer as much possibility of tailoring the services exactly to individual needs. The user may acquire such a service for example by bringing his mobile terminal to a branch office of the service provider for installation, or by downloading the required script(s) from a web page. A service defined by the service provider might well consist of two parts, of which only a simple activating (and potentially result displaying) part runs in the user's mobile terminal and a more complicated processing part runs in the service provider's server.
Figs. 7, 8 and 9 illustrate certain principal alternatives for service execution scenarios. Fig. 7 is a simple terminal-based execution scenario that may include an optional earlier information transfer step 701 from a service provider's server to a mobile terminal, but after that all steps take place locally at the mobile terminal. At step 702 the user activates the use of a service by giving a simple activation command. At step 703 the mobile terminal parses a script that represents the selected service, and at step 704 it processes the service according to the executable instructions that resulted from the parsing step. At step 705 the results are displayed to the user.
Fig. 8 illustrates a more interactive service execution scenario, in which also the server has an active role. At step 801 the user of a mobile terminal activates the use of a service by giving a simple activation command. At step 802 the mobile terminal parses a script that represents the selected service, and at step 803 it formulates a request message to the server according to the executable instructions that resulted from the parsing step. At step 804 the request message is transmitted to the server, which processes the request at step 805 and transmits a response at step 806. At step 807 the mobile terminal receives and processes the response message to put the results of the service into a form in which they can be presented to the user, and at step 808 the results are displayed.
Both service execution scenarios presented in figs. 7 and 8 require the mobile terminal to possess full script parsing capability. However, an alternative approach can be presented where only relatively limited script parsing capability is required from the mobile terminal. In fig. 9 the activation step 901 may be followed by a script parsing and local processing steps 902 and 903, but in any case the request message that the mobile terminal transmits to the server at step 904 contains also certain passages of yet unparsed script. At step 905 the server parses such passages of script, and/or transforms them into sonie server specific macro language that is used for controlling the operations of the server. If it is not possible or not desirable to add script parsing capability to the particular server that will provide the actual service, it is possible to arrange step 905 to be performed at an auxiliary "interpreter" device either so that script-containing requests from mobile terminals automatically go first to such an interpreter device or so that when a service provider's server encounters a request that contains script, it forwards it to the interpreter device for parsing the script. The interpreter device then forwards parsed instructions to the actual service-providing server in a form that is acceptable to the latter. An interpreter device may be for example a trusted auxiliary interpreter server hidden behind an actual service provider's server, which has no native parsing capability.
At step 906 the server processes the request, and at step 907 it transmits a response message to the mobile terminal. This response message could comprise passages of script as well. If that is the case, the response processing step 908 at the mobile terminal must include some script parsing as well. At step 909 the results of the service are displayed. If passages of script are transmitted between the mobile terminal and the server, they must be wrapped into some conventional communication protocol: for reasons of compatibility it cannot be required that any other device that takes part in the communication between the mobile terminal and the server should be able to understand or act according to the script.
A division of work between the mobile terminal and the server does not preclude the mobile terminal from performing some service-related processing also during the time when it waits for a response from the server. Using a service at the mobile terminal may comprises two or more parallel processing paths, the execution of which may be concurrent and at least partly independent from each other. All service-related transmissions between the mobile terminal and the server should be encrypted in order to provide security. The communication protocol(s) used for communication over the wireless communication link should include optimization features that take into account the specific nature of wireless links; such optimization features are known and very well developed for example in WAP.
The mechanisms of defining and executing a service according to the invention place little requirements to what is the actual content of the service. However, certain features of the invention make it especially well suited for financial services. In the following we consider four alternative service usage scenarios that are helpful in understanding certain characteristics that are peculiar to financial services.
A first service usage scenario is informational usage, which can be characterised as offering answers to the question "what am I doing?". A user has typically certain financial assets, like bank accounts, a current state of which can be easily characterised by a simple number or character string. However, even such simple information is typically highly confidential, which means that a service for inquiring and providing such information must include security features for ensuring that only an authorized user has access to the information. Typical examples of information of this kind are account balances, remaining monthly credit of a credit card, or the current content of a stocks portfolio.
A second service usage scenario is analytical usage, which is close to the first one described above but is understood to encompass a somewhat wider scope of information. Analytical services may be understood as answering the question "how am I doing?". So instead of or in addition to a remaining monthly credit the user might be interested in accumulated debiting on his accounts over a certain period, classified according to a certain prestored model.
A third service usage scenario is advisory usage, which goes even further from analytical usage in that the user wants to know not only the developments so far, but also certain prospects of the future and/or suggested financial actions. The illustrative question is "what should I do?", and the information looked after in the service may include e.g. investment tips that take into account a predefined risk- taking profile.
A fourth service usage scenario is transactional usage, which differs from the three others mentioned above in that instead of or in addition to just receiving information the user wants to actively accomplish something, like paying bills or making investment decisions.
Features that are common to all usage scenarios of financial services include a pronounced demand for security, privacy and reliability. The information that is handled is highly confidential and must not be available for unauthorized parties. Transactions that are performed must either succeed completely or not at all, i.e. no transaction should be allowed to be only partly perfomed. It must be possible to later check and verify a completed transaction. A user must also be able to trust that the information he gets is correct and really comes from the source from which he expects it to come.
Technology that is used for enhancing security and reliability in electronic communication frequently relies on the use of encryption keys, cryptographically protected authenticity certificates, PLNs (Personal Identification Numbers) and other corresponding identifiers that involve complicated character strings that must be either remembered or safely stored. From the technology of secure wireless communication, solutions are known where a mobile communication device includes a so-called electronic safe store, which is a specifically protected memory circuit for safely storing information of this kind. An electronic safe store is even suitable for storing electronic cash, which as a term refers to cryptographically authenticated pieces of digital information that parties in commerce agree to have certain monetary value so that they can be used as tenders for debts. It is possible to give a service according to the invention access to the electronic safe store of the user, which further streamlines the use of financial services in accordance with the invention.
Fig. 10 illustrates a situation where the user first wants to check the balance of his account than then decides to download some electronic cash into his electronic safe store. At step 1001 the user activates a banking service with a simple activation command according to the invention. The user has previously tailored the service so that it always begins with a balance check. The bank will not give the balance information unless the corresponding request message was cryptographically authenticated and contains the correct identifiers; means for cryptographical authentication as well the user's identifiers are stored in the electronic safe store of the mobile terminal. Therefore the terminal requests the appropriate protected information from the safe store at step 1002. The safe store may be further configured so that it will not become available without a PIN number being given online; therefore the optional PIN request and PIN inputting steps 1003 and 1004 are shown in fig. 10. In any case the electronic safe store returns the requested information at step 1005. The other parts of the terminal utilize this information to compose a properly identified and cryptographically authenticated message to the server at step 1006.
Regarding online PIN giving (or similar strictly user-dependent authentication - known alternatives to PIN giving exist and include e.g. electronic fingerprint reading, speech sample analysis and optically scanning the iris of the eye) during the execution of a script, two approaches are possible. The first of them involves requiring the user to be present and to authenticate himself to the mobile terminal every time when the electronic safe store in the mobile terminal must be accessed. This approach represents ultimate safety, because it vitiates even well-timed attempts of stealing a mobile terminal during the execution of a script, after the legitimate user has authenticated himself but before he has availed himself of any advantage that would involve utilizing the contents of the electronic safe store. The other approach is based on requiring the user to authenticate himself once, after which the script to be currently executed becomes a trusted representative of the user in the sense that it may access the electronic safe store by its own without requiring the user to repeat the authentication step during the period of executing the script. The latter approach is more convenient to the user, and also reasonably safe at least if the time it takes to execute such a "trusted script" remains below a reasonable limit.
Regarding subsequent uses of the same service, two alternatives exist: either a script that has once acquired the status as the user's trusted representative may keep that status ever since (or for a predetermined time, or predetermined number of times of using the service), or then the status as the user's trusted representative only lasts until the end of that particular occasion of using the service, in which latter case the script has to re-acquire the status every time when the script is started anew.
It is also possible to utilize the electronic safe store to store the script itself or at least major parts of it. In that case the user must authenticate himself at the very beginning of the execution of a script, and the safely stored script is as safe from unauthorized tampering as anything else stored in the electronic safe store.
Above we assumed that the first request message is a balance check, so after having verified the authenticity of the requesting user the server responds at step 1007. The response message comes in cryptographically protected form, and the terminal is not able to decrypt and verify it without first consulting the electronic safe store again at steps 1008 and 1009. When the balance information is ready in plaintext form, the terminal displays it to the user at step 1010.
We assume that one part of the executable instructions that resulted from a previous script parsing step at the mobile terminal was particularly directed to temporarily modify the user interface of the mobile terminal so that at least certain softkeys are taken to the control of the service in question. This means that when the first results are displayed at step 1010, the selections that the user can make are readily available for him by pressing only one key or otherwise activating a very simple part of the user interface. In other words, in a mobile terminal equipped with softkeys, together with displaying the requested account balance there are displayed texts and/or icons next to the softkeys that indicate, what simple functional alternatives are now available for selection through the press of a softkey.
The subject of giving the user the possibility of altering the course of using a service at a particular time deserves some further consideration. It is naturally possible to compose a script the parsing of which produces a relatively complicated program complete with branching points at which a further selection command received from a user will cause the further execution of the program to follow one of a number of alternative routes. However, such an approach could easily result in a situation where a number of similar functionalities could exist parallelly as parts of different scripts. Fig. 11 illustrates schematically an alternative approach. The horizontal bar 1101 illustrates the execution of a parsed script, advancing from the left to the right, so that at moment 1102 the user causes the execution to start by giving a very simple activation command according to the invention. The use of the service in question proceeds as determined in the script until moment 1103, at which the user is given the possibility of making a selection. It is possible to define a default case according to which no selection or the simplest selection possible expressed at moment 1103 causes the use of the service to proceed according to a basic alternative defined in the script itself. Another selection made by the user and expressed in a simple selection command given through the user interface causes the use of the service to divert into a client program 1111, the execution of which starts at moment 1112.
The client program 1111 may be defined in another script, or it may be some completely different, even device-dependent other functionality like a messaging application. In fig. 11 we assume that the client program 1111 in turn offers the user certain selections regarding its termination at alternative moments 1113, 1114 or 1115. Terminating the use of the client program at any of these moments causes a return to the use of the basic service; here we have additionally assumed that terminating the use of the client program at each of these moments causes a return to a different point 1106, 1105 or 1107 respectively of the basic service.
Another exemplary client program is illustrated as the block 1121. It is started if the user expresses a certain selection at a point 1104 of using the basic service that is defined in the script. Executing the simple, no-selections-involved second client progam proceeds from moment 1122 to moment 1123, after which a return occurs to exactly that point in the "master" service at which a diversion to the client program 1121 occurred.
The task of a client program may be almost anything. For example, a client program may be responsible for arranging a more elaborate communication between a user and his mobile terminal than what is possible or reasonable to realize by means of a simple script. If a suitable client program is not permanently resident in the mobile terminal of a user, making a certain selection during the execution of a parsed script may trigger the operation of fetching and downloading a suitable client program from a certain predefined location in a network.
The execution language script may support a generic interface towards plugin-type external function modules, that may be interchangeable without altering the rest of the steps of using a service. For example, such a generic interface may exist towards plugin-type modules for setting up a safe communication connection. Through the generic interface the execution language script may adapt to the use of any of a multitude of possible ways of setting up a safe communication connection, without paying attention to what are the specific features of the selected method. Modules that could utilize a generic interface definition include but are not limited to communication setup modules, user authentication modules, man-machine-interface maintaining modules and timing modules in the form of clocks, timers and calendars.
The selections at the various selection points may include a feature according to which pressing always the same single key, or otherwise giving always the same simple command that triggered the start of the basic service itself, causes the use of the service to proceed according to the default route, which in fig. 11 means proceeding through the bar 1101 from left to right without making diversions to any client programs. This would be the easiest for a user to learn and understand, since it is natural to associate the simplest and most familiar of commands to the simplest and most often needed way of proceeding through the use of a service.
The results obtained through the use of a client program may have influence on how the use of the basic service proceeds from that moment at which a return to the basic service occurred. For example if a client program was initiated for transmitting a request message to a stock exchange server for getting the latest stock price quote for a certain company and for receiving a response message, and the response message indicated that a certain predefined price limit has been exceeded, the basic service may treat this information as a parameter value that triggers a suggestion to the user to commence offering his stocks for sale. The use of clients in accordance with the present invention is most typical in services having certain transactional nature.
Referring briefly back to the schematically presented mobile terminal of fig. 2, allowing a service according to the invention to control the user interface means that the reprogrammable user interface command interpreter block 211, is responsive also during the processing of a service. At a certain step of the service processing the processor 201 is arranged to drive a display to show the temporary meanings of the softkeys, so that pressing a particular softkey causes a particular continuation to be selected in processing the service.
In fig. 10 we assume that the user selects downloading electronic cash by pressing the appropriate softkey at step 1011. A further PIN request from the user would probably be unnecessary if only a short time interval has passed since the last one at steps 1003 and 1004, so the task of composing a cryptographically authenticated request message is managed just between the electronic safe store and the rest of the terminal at steps 1012, 1013 and 1014. At step 1015 the server responds by transmitting the requested electronic cash in a message the decryption and authentication of which necessitates a further consultation of the electronic safe store at steps 1016 and 1017. At step 1018 the terminal performs the action ordered in the message from the server, i.e. stores the newly received electronic cash into the electronic safe store. At step 1019 an indication is given to the user about the completion of the requested task. At step 1020 the user terminates the current use of the banking service.
The facts taken into account that a service according to the invention will at least request certain information from the service provider's server, and possibly also cause transactions to be executed, which transactions may involve substantial financial value, it is within the interest of the service provider to make sure that the script(s) that define and control the service are "legal", i.e. acceptable to the service provider. Additionally the user of a mobile terminal certainly wants to ensure that only correct, appropriate and wanted scripts are stored into his terminal. The following considerations apply:
- only signed scripts are acceptable: a mobile terminal will only accept and store a script that contains the digital signature of a recognized service provider;
- the user has the control: the mobile terminal shall ask for the user's approval before storing a script for later use, and the user can at any time check the number and nature of scripts stored in his terminal and remove possible unwanted or unnecessary scripts;
- the service provider's server shall only respond to communications contacts that have been generated by authenticated, i.e. appropriately signed scripts and that contain some cryptographic verification of this fact.
The service for the use of which a user wants to apply the present invention may well be such that it does not necessarily require its use to be automated in the way described in the present invention. In other words, the user might well use the same service "manually", e.g. by keying in the request messages by hand. It is in the interest of the service provider to be able to discriminate between such occasions where the service is used through a script and such where the use of the service involves manual interaction. A simple way to achieve such discrimination ability is to require that in the course of a user authentication process, a first identifier is selected (e.g. read from an electronic safe store) if manual use is involved, and a second, different identifier is selected instead (or in addition thereto) if a script was responsible for the use of the service.
Fig. 12 illustrates certain overall system aspects concerning the invention. Two communications networks are involved, one of which is a cellular radio network
1201 and the other is a wired data network 1202. In the most advantageous case considering the technology of the priority date of this patent application, a user has two different types of terminals at his disposal: a wireless terminal 1203 for actually using services according to the invention and a more versatile but potentially larger, heavier and clumsier wired terminal 1204. The wireless terminal 1203 contains at least a programmable user interface, which the user may adapt to accept an ultimately simple starting command for the use of a particular service according to the invention, as well as downloading and communication capability for downloading scripts from service definition server(s) and for exchanging messages related to the use of services with service provider's server(s). The wired terminal 1204 contains a network connection and a browser program for contacting service definition servers and for using them to define and edit user-tailored services.
A service definition server 1205 has a network connection to the wired data network
1202 as well as a service definition application that users may access through the use of browser programs. It must also have transmitting capability for transmitting completed service-defining scripts to the mobile terminals of users through the cellular radio network 1201. A service provider's server 1206, which may even be physically the same as a service definition server 1205, must contain the actual service application as well as a communication interface for bidirectionally communicating with mobile terminals during the course of a user using a certain service.
Considering the system framework of fig. 12, in the foregoing we have assumed that the capability of parsing execution language scripts, or at least a part of such capability, resides in the user's mobile terminal 1203. However, it is possible to present an embodiment of the present invention where the mobile terminal can do completely without parsing capability, if enough such capability exists elsewhere in the system. Additionally such an embodiment of the invention assumes that the mobile terminal includes some native mechanism for executing a series of commands in a device-depending command language and for associating the beginning of such executing to some simple user interface command, which the user wants to associate with a certain service. An an example we may assume that the service definition server 1205 is capable of parsing an execution language script into a device-dependent command series. After the process of composing an execution language script has been completed in the service definition server 1205, one still needs to indicate the type of the mobile terminal 1203 to the service definition server 1205. When the latter recognizes the terminal type in question, it may continue by parsing the completed script, so that a subsequent downloading step involves downloading the parsed device-dependent command series instead of the execution language script from the service definition server 1205 to the mobile terminal 1203.
Another alternative is that users may acquire conversion programs to their wired terminals. In an example of a scheme based on such an assumption, when a user has completed the action of defining his personalized way of using a service at the service definition server 1205, and the corresponding script has been composed and duly authenticated, the user may download the script into his wired terminal 1204, convert it into a device-dependent command series and forward the result to his mobile terminal 1203 through the networks 1201 and 1202 or through a local short- distance link. If the steps of defining the service and composing the script took place at the user's wired terminal 1204, no script downloading is needed but the converting and forwarding steps are performed in a similar manner.

Claims

Claims
1. A method for providing a user with a service from a server (105, 1206) coupled to a communications network (103, 104, 1201, 1203), characterized in that it comprises the steps of:
- storing (427) a definition (302) of automatically using the service into a mobile terminal (102, 1203) of the user,
- reprogramming said mobile terminal (102, 1203) to associate a certain input command given through a user interface of said mobile terminal with starting the use of the service, and - as a response to receiving (702, 801, 901, 1001) said certain input command after the step of reprogramming said mobile terminal has been accomplished, commencing use of the service according to said definition; wherein the use of the service comprises communicating information (112, 113, 114, 121, 122, 123) between said mobile terminal (102, 1203) and the server (105, 1206) through the communications network (103, 104, 1201, 1203).
2. A method according to claim 1, characterized in that before the step of storing (427) a definition (302) of automatically using the service, it comprises a step of composing (301) a customized definition (302) of the service adapted to the needs of the particular user.
3. A method according to claim 2, characterized in that said step of composing (301) a customized definition (302) of the service involves tracking certain operations through which the user uses the service manually and converting observations made during such tracking into a definition of automatically using the service.
4. A method according to claim 3, characterized in that it comprises:
- observing the context in which the user made a certain physical operation,
- taking said context into account in deducing what was the function to be executed as a response to said certain physical operation and
- storing into said customized definition of the service a command to execute said function instead of just storing a command that would directly correspond to repeating said certain physical operation.
5. A method according to claim 2, characterized in that:
- said step of composing (301) a customized definition (302) of the service is performed in a device that is other than the mobile terminal of the user, and
- between said steps of composing a customized definition of the service and storing a definition of automatically using the service, the method comprises a step of downloading a composed customized definition (302) of the service into the mobile terminal of the user.
6. A method according to claim 5, characterized in that said step of composing (301) a customized definition (302) of the service is performed in a service definition server (1205) of the motion of the user and comprises the substeps of:
- providing a browser connection between a terminal (1204) of the user and said service definition server (1205),
- executing a service definition application in said service definition server (1205), and - directing the execution of said service definition application according to commands given by the user through said browser connection.
7. A method according to claim 5, characterized in that said step of composing a customized definition of the service is performed in a service provider's server (105) of the motion of said service provider and comprises the substeps of:
- providing a control connection between a control terminal (106) and said service provider's server (105),
- executing a service definition application in said service provider's server (105), and
- directing the execution of said service definition application according to commands given by an operator through said control connection.
8. A method according to claim 2, characterized in that the step of composing (301) a customized definition (302) of the service produces a definition (302) of the service in the form of device-independent execution language script.
9. A method according to claim 1, characterized in that the step of reprogramming said mobile terminal (102, 1203) involves programming a programmable user interface command interpretation unit (211) to interprete a certain single command given through said user interface as a starting command for the use of said service.
10. A method according to claim 9, characterized in that said certain single command is a press of a certain key for the duration of a certain time.
11. A method according to claim 1, characterized in that the step of commencing use of the service comprises the substeps of:
- reading an execution language script (302) from a memory (212) of the mobile terminal,
- parsing (303, 703, 802, 902) said execution language script (302), thus converting said execution language script (302) into a set of executable instructions (304) for a processor (201) to execute, and - commencing execution (305, 704, 803, 903) of said set of executable instructions (304) in a processor (201) of the mobile terminal.
12. A method according to claim 11, characterized in that after the step of commencing execution (305, 704, 803, 903) of said set of executable instructions (304, 1101) it comprises the steps of:
- executing said set of executable instructions until a certain branching point (1103, 1104),
- prompting the user for a selection command, and depending on which selection command is thereafter received from the user:
- as a response to a first alternative selection command received from the user, continuing execution of said set of executable instructions (1101) that resulted from parsing said execution language script, and
- as a response to a second alternative selection command received from the user, commencing execution of a client program (1111, 1121) that is external to said set of executable instructions (1101) that resulted from parsing said execution language script.
13. A method according to claim 12, characterized in that said first alternative selection command is the same as said certain input command that originally caused commencing the use of the service according to said definition.
14. A method according to claim 12, characterized in that in a case where a second alternative selection command was received from the user, said client program (1121) is executed until an end (1123), after which execution of said set of executable instructions (1101) that resulted from parsing said execution language script is resumed from said branching point (1104).
15. A method according to claim 12, characterized in that in a case where a second alternative selection command was received from the user, said client program (1111) is executed until an end (1113, 1114, 1115), after which execution of said set of executable instructions (1101) that resulted from parsing said execution language script is continued from a return point (1105, 1106, 1107) that is later in said set of executable instructions (1101) than said braching point (1103).
16. A method according to any of claims 14 or 15, characterized in that:
- executing said client program (1111, 1121) comprises obtaining a parameter value, and - returning from the execution of said client program (1111, 1121) to the execution of said set of executable instructions (1101) that resulted from parsing said execution language script involves bringing said parameter value as input information to the execution of said set of executable instructions (1101).
17. A method according to claim 12, characterized in that at the step of prompting the user for a selection command there exist more than two alternative selection commands, so that depending on which selection command is thereafter received from the user, a way of continuing execution from the branching point is selected from more than two alternatives.
18. A method according to claim 1, characterized in that the use of the service according to said definition comprises the substeps of:
- receiving online a piece of authentication information (1004) from the user, and
- using said piece of authentication information to access (1005) an electronic safe store in the mobile terminal.
19. A method according to claim 18, characterized in that it comprises the steps of:
- after a first occasion of receiving online a piece of authentication information (1004) from the user, acknowledging said definition of automatically using the service as a trusted representative of the user, and
- after a first occasion of using said piece of authentication information to access (1005) an electronic safe store in the mobile terminal, utilizing the acknowledged status as a trusted representative of the user by accessing again (1008, 1009, 1012, 1013, 1016, 1017) said electronic safe store in the mobile terminal without having to receive again any authentication information from the user.
20. A method according to claim 19, characterized in that the step of acknowledging said definition of automatically using the service as a trusted representative of the user involves awarding said definition of automatically using the service with a status of a trusted representative of the user also for a number of subsequent times of automatically using the service.
21. A method according to claim 19, characterized in that the step of acknowledging said definition of automatically using the service as a trusted representative of the user involves awarding said definition of automatically using the service with a status of a trusted representative of the user only for an ongoing occasion of automatically using the service.
22. A method according to claim 1, characterized in that the step of storing (427) a definition (302) of automatically using the service into a mobile terminal of the user involves storing said definition into an electronic safe store in the mobile terminal.
23. A method according to claim 1, characterized in that said communication of information between said mobile terminal (102, 1203) and the server (105, 1206) through the communications network comprises at least one of the following:
- informational usage of a service, including communicating from the server (105, 1206) to said mobile terminal (102, 1203) a character string that illustrates a current state of a financial asset of the user,
- analytical usage of a service, including communicating from the server (105, 1206) to said mobile terminal (102, 1203) analyzed information about financial assets of the user,
- advisory usage of a service, including communicating from the server (105, 1206) to said mobile terminal (102, 1203) information about suggested financial actions for the user, and
- transactional usage of a service, including communicating from said mobile terminal (102, 1203) to the server (105, 1206) information about financial transactions that the user wants to accomplish.
24. A mobile terminal (102, 1203) for providing a user with a service from a server (105, 1206) coupled to a communications network (103, 104, 1201, 1202), characterized in that it comprises:
- a memory (212) for storing a definition of automatically using the service, - reprogrammable user interface means (203, 204, 211) for reprogramming said mobile terminal to associate a certain input command given through a user interface (203) of said mobile terminal (102, 1203) with starting the use of the service,
- processor means (201) adapted to respond to receiving said certain input command after reprogramming said mobile terminal has been accomplished by commencing use of the service according to said definition, and
- communication means (205, 214) for communicating information between said mobile terminal (102, 1203) and the server (105, 1206) through the communications network (103, 104, 1201, 1202).
25. A mobile terminal according to claim 24, characterized in that it comprises tracking means (201) adapted to track certain operations through which the user uses the service manually and to convert observations made during such tracking into a definition of automatically using the service.
26. A mobile terminal according to claim 24, characterized in that it comprises parser means (213) adapted to convert a definition (302) of service from the form of device-independent execution language script into the form of processor-executable instructions.
27. A mobile terminal according to claim 24, characterized in that it comprises means for accepting and storing a definition (302) of service in a form of a device- dependent command series previously parsed from the form of device-independent execution language script.
28. A mobile terminal according to claim 24, characterized in that said reprogrammable user interface means (203, 204, 211) are adapted to be reprogrammed to associate the press of a certain pressable key of said mobile terminal with starting the use of the service.
29. A system for providing a user with a service, comprising:
- a communications network (103, 104, 1201, 1202),
- a service provider's server (1206) coupled to the communications network, and
- a user's mobile terminal (1203) coupled to the communications network; characterized in that it comprises:
- service defining means (1203, 1204, 205) for creating a customized definition of automatically using the service in a way adapted to the needs of the particular user,
- means for storing a created customized definition of automatically using the service into the mobile terminal (1203) of the user, - means for reprogramming said mobile terminal (1203) to associate a certain input command given through a user interface of said mobile terminal with starting the use of the service, and
- at the mobile terminal (1203), means for responding to receiving said certain input command after said reprogramming has been accomplished by commencing use of the service according to said definition.
30. A system according to claim 29, characterized in that said service defining means are located at the user's mobile terminal (1203).
31. A system according to claim 29, characterized in that said service defining means are located at a service definition server (1205) coupled to the communications network (1201, 1202).
32. A system according to claim 31, characterized in that the service definition server (1205) is adapted to digitally authenticate created customized definitions of automatically using services, and the user's mobile terminal (1203) is adapted to only accept such digitally authenticated definitions of automatically using services for storing.
33. A system according to claim 31, characterized in that the user's mobile terminal (1203) is further adapted to indicate the digital authentication when communicating to the service provider's server (1206) during the automatical use of a service, and the service provider's server (1206) is adapted to only accept communication from mobile terminals (1203) that automatically use a service if such communication includes such indicated digital authentication.
PCT/FI2003/000807 2002-11-01 2003-10-31 Implementing a service, particularly a financial service, in a network involving mobile terminals WO2004040884A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP03758179A EP1557029A1 (en) 2002-11-01 2003-10-31 Implementing a service, particularly a financial service, in a network involving mobile terminals
AU2003274198A AU2003274198A1 (en) 2002-11-01 2003-10-31 Implementing a service, particularly a financial service, in a network involving mobile terminals
JP2004547684A JP2006505165A (en) 2002-11-01 2003-10-31 Method, mobile terminal and system for providing services in a network, in particular financial services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20021951 2002-11-01
FI20021951A FI20021951A (en) 2002-11-01 2002-11-01 The realization of a service, in particular a financial service, in a network comprising portable terminals

Publications (1)

Publication Number Publication Date
WO2004040884A1 true WO2004040884A1 (en) 2004-05-13

Family

ID=8564862

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2003/000807 WO2004040884A1 (en) 2002-11-01 2003-10-31 Implementing a service, particularly a financial service, in a network involving mobile terminals

Country Status (6)

Country Link
EP (1) EP1557029A1 (en)
JP (1) JP2006505165A (en)
CN (1) CN1732671A (en)
AU (1) AU2003274198A1 (en)
FI (1) FI20021951A (en)
WO (1) WO2004040884A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2033461A1 (en) * 2006-06-23 2009-03-11 Microsoft Corporation Virtualization of mobile device user experience

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106020948B (en) * 2016-05-10 2019-09-17 中国银联股份有限公司 A kind of process dispatch method and device
JP7466306B2 (en) 2016-08-19 2024-04-12 中国科学院化学研究所 Ultra-high molecular weight, ultra-fine particle polyethylene and its manufacturing method and applications

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998042173A2 (en) * 1997-03-24 1998-10-01 Fd Finanssidata Oy Use of banking services in a digital cellular radio system
US5832074A (en) * 1996-11-26 1998-11-03 Inventec Corporation Intelligent telephone system
WO2001052508A1 (en) * 2000-01-12 2001-07-19 Qualcomm Incorporated Apparatus and method for duplicating user input into a wireless communication device via command shortcuts
EP1233599A2 (en) * 2001-02-16 2002-08-21 Microsoft Corporation Shortcut system for use in a mobile electronic device and method thereof
WO2002067602A1 (en) * 2001-02-19 2002-08-29 Sensible Group Limited Enhanced text based messaging system
DE10117654A1 (en) * 2001-04-09 2002-10-17 T Mobile Deutschland Gmbh Control procedure for mobile-phone terminals, involves storing and carrying out macro-commands

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832074A (en) * 1996-11-26 1998-11-03 Inventec Corporation Intelligent telephone system
WO1998042173A2 (en) * 1997-03-24 1998-10-01 Fd Finanssidata Oy Use of banking services in a digital cellular radio system
WO2001052508A1 (en) * 2000-01-12 2001-07-19 Qualcomm Incorporated Apparatus and method for duplicating user input into a wireless communication device via command shortcuts
EP1233599A2 (en) * 2001-02-16 2002-08-21 Microsoft Corporation Shortcut system for use in a mobile electronic device and method thereof
WO2002067602A1 (en) * 2001-02-19 2002-08-29 Sensible Group Limited Enhanced text based messaging system
DE10117654A1 (en) * 2001-04-09 2002-10-17 T Mobile Deutschland Gmbh Control procedure for mobile-phone terminals, involves storing and carrying out macro-commands

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2033461A1 (en) * 2006-06-23 2009-03-11 Microsoft Corporation Virtualization of mobile device user experience
EP2033461A4 (en) * 2006-06-23 2014-01-08 Microsoft Corp Virtualization of mobile device user experience
US9542062B2 (en) 2006-06-23 2017-01-10 Microsoft Technology Licensing, Llc Virtualization of mobile device user experience

Also Published As

Publication number Publication date
AU2003274198A1 (en) 2004-05-25
FI20021951A0 (en) 2002-11-01
CN1732671A (en) 2006-02-08
EP1557029A1 (en) 2005-07-27
FI20021951A (en) 2004-05-02
JP2006505165A (en) 2006-02-09

Similar Documents

Publication Publication Date Title
JP5122282B2 (en) Electronic financial transaction system
EP1415231B1 (en) Method and system for visualising a level of trust of network communication operations and connection of servers
US9607293B2 (en) Method and system for account management and electronic wallet access on a mobile device
EP1807966A1 (en) Authentication method
CA2718514A1 (en) Electronic wallet for a wireless mobile device
KR20210135984A (en) Systems and methods for pre-authentication of customer support calls
KR20090114585A (en) Method and System for Processing Cash Payment by Using USIM and Recording Medium
NO321850B1 (en) Procedure for generating and verifying an electronic signature
KR20230005815A (en) Tap to pay your credit bill
KR20220038704A (en) Techniques for Call Authentication
WO2004040884A1 (en) Implementing a service, particularly a financial service, in a network involving mobile terminals
US9355241B2 (en) Method for providing a dynamic code via a telephone
KR20060130471A (en) System and method for selecting linking process of moblie banking service, mobile devices and recording medium
KR100589482B1 (en) Method and ars using a mobile phone
KR20070092917A (en) The method and system for transferring personal secret information and authenticating internet user via mobile telecommunication network
KR100854346B1 (en) System and Method for Providing Customized Mobile Banking Service
US20220405732A1 (en) Systems and methods for providing embedded banking services
KR20060132065A (en) System and method for syncronizing financial transaction information data, communication terminals for financial transaction, operating devices and recording medium
KR20090115089A (en) System for Transferring Cash Payment by Using USIM
KR100967929B1 (en) System for Processing Graphic User Interface Sysnchronous for Individual Communication Medium
El-Safi Mobile Banking Project
KR100963917B1 (en) System for Processing Account Transfer using Graphic User Interface and Program Recording Medium
KR101478349B1 (en) Method for Providing Financial Service by Selective Service
JP2024016271A (en) Generate and manage secure passwords using NFC and contactless smart cards
KR20100010871A (en) System and method for paying input by voip terminal, voip terminal and recording medium

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003758179

Country of ref document: EP

Ref document number: 305/MUMNP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2004547684

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 20038A61977

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003758179

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2003758179

Country of ref document: EP