METHOD AND ARRANGEMENT FOR DISTRIBUTING, EXECUTING AND CONSUMING RECREATIONAL APPLICATIONS IN AND BETWEEN MOBILE TELECOMMUNICATION DEVICES

Abstract: A method and arrangements are provided for distributing a recreational application within a group of terminal arrangements (1101, 1102). The group comprises at least two terminal arrangements and each terminal arrangement comprises a terminal of a cellular radio system. Within the method, there is transmitted from a first terminal arrangement to a second terminal arrangement a proposal (104, 204, 704) for setting up a session of utilising a recreational application. Only after the second terminal arrangement has received said proposal, one used (107, 108, 207, 208, 308, 408, 409, 508, 509, 510, 607, 608, 609, 610, 611, 707, 710, 711) the communicational capabilities of at least one of the first and second terminal arrangements to establish a state where both the first terminal arrangement and the second terminal arrangement possess enough software components (1103, 1104, 1105, 1106, 1205) for setting up a common, shared session of utilising said recreational application.

Description: Method and arrangement for distributing, executing and consuming recreational applications in and between mobile telecommunication devices The invention concerns generally the use of mobile telecommunication devices for recreational purposes. Expecially the invention concerns the adaptation of mobile telecommunication devices for obtaining, distributing and executing certain pieces of software and content required to run recreational applications such as simulated board games or electronically stored music or literary works. Mobile telecormnunication devices are evolving from wireless telephones towards multifunctional personal digital assistants with diverse cormnunication capabilities both locally and globally. One of the features introduced into mobile telecommunication devices recently before the priority date of this patent application is the possibility of playing recreational games by using the same user interface which is used for the main functions of the device. As an example we will describe the so-called worm game which can be played for example in certain mobile telephone models manufactured by the Nokia Corporation. The telephone version of the worm game is a software module which the processor of the mobile telephone may execute as a response to an initiation command given by the user. The processor uses the small liquid crystal display of the telephone to display a field limited by edges and obstacles. A moving fraction line within the field denotes a "worm". The worm advances at a certain speed into its local ahead direction, which is one of the four principal directions (up, down, left, right), and the user may instruct it to turn in steps of 90 degrees by pressing some of the numerical keys of the telephone. Two users can play the worm game against each other through using the local wireless communication ports (the infrared transceivers) of their mobile telephones. In the two-player version there are two worms on the field simultaneously. Each player controls one of the worms. Each mobile telephone conveys the worm control commands given by its user to the other mobile telephone so that an exact replica of the field with the same instantaneous location and speed of the worms appears on the displays of both mobile telephones. The worm game is only an example of known recreational applications designed for mobile telecommunication devices. Basically the manufacturer of the device may store an arbitrary game into the memory of the device in the form of processor- executable instructions. The limiting factors that have to be considered are only the size of the storage capacity that can be allocated for the recreational applications and the limited input/output characteristics of the user interface. There are also portable terminals built especially for the purpose of playing recreational games. A widely known example of these is the Nintendo Gameboy pocket console (Nintendo and Gameboy are registered trademarks), which has also some local communicational capability in the form of an infrared transceiver and a wired serial port. In addition to games, there are other recreational objects that may fall within the scope of the present invention. Such other recreational objects include but are not limited to electronically stored musical pieces, electronically stored literary works such as books, newspapers, magazines and parts thereof, electronically stored visual objects such as films and animations and parts thereof, and multimedia-like combinations of those mentioned above. In this patent application such other recreational objects are meant to fall within the scope of the term "recreational application". The disadvantage of the conventional recreational software- and recreational application solutions is their inflexibility especially regarding distribution. The user gets easily bored with the preprogrammed standard selection of games, so there should be the possibihty to download other recreational appUcations from somewhere. It is known at the priority date of the present patent application that software applications and updates can be downloaded into mobile telecommunication devices through the radio interface from the cellular radio network. However, the known downloading arrangements are typically not optimized for downloading recreational appUcations, which may make their use for that purpose inconvenient. In dedicated playing consoles like the Nintendo Gameboy the loading of a new game requires the user to acquire a new memory module where the new game is permanently stored. It is an object of the invention to present a method and an arrangement for distributing and executing recreational appUcations in mobile telecommunciation devices in an easy and convenient manner. It is another object of the invention to especially adapt the distribution and execution of recreational applications to the specific needs arising from games where two or more players may take part simultaneously. The objects of the invention are achieved by providing different versions of certain recreational appUcations with regard to rights of use and using the communication capabiUties of the mobile telecommunication devices to arrange the distribution of the versions. Certain objects of the invention are also achieved by providing an agent program which guides a player in playing and monitors certain characteristics of the game. Certain further objects of the invention are achieved by making the usabiUty of a recreational appUcation that has been shared between at least two mobile telecommunication devices dependent on the physical distance between said at least two mobile telecommunication. Such physical distance has most typicaUy a manifestation in a possibihty or impossibiUty of using certain transmission means to exchange information between the mobile telecommunication devices. The invention appUes to a method for distributing a recreational appUcation within a group of terminal arrangements, where the group comprises at least two terminal arrangements and each terminal arrangement comprises a terminal of a ceUular radio system. The method is characterised by what is said in the characterising portion of the independent patent claim directed to a method. The invention appUes also to a terminal arrangement which is characterised by what is said in the characterising portion of the independent patent claim directed to ari arrangement. A feature which distinguishes mobile telecommunication devices from other portable electronic equipment which are used for executing and consuming recreational appUcations is the mobile telecommunication devices' superior capabiUty of communicating with other devices, such as other mobile telecommunication devices and fixed servers coupled to communication networks. According to a first aspect of the invention this communication capabiUty is harnessed for the purpose of distributing recreational appUcations or parts thereof in a situation where two or more players want to take part in a common session of using a recreational appUcation. One device acts as an initiator and invites at least one other device to take part in the session. Only one of the devices, typicaUy the initiator, must initiaUy possess the appUcation software or a certain key component thereof. The device initially possessing the application software or key component thereof either communicates it to the other device(s) through a local link or a communications network, or it instructs the other device(s) to download the application software or key component thereof from a certain network resource. Acquiring and/or using a certain recreational appUcation is typicaUy subject to charge paid to the original designer and/or owner of rights of the appUcation. We assume that the copy of the recreational appUcation or key component thereof which was initiaUy possessed by one of the devices is legal: the user of the device has paid the associated fees, if any, and consequently has a legal right to use the appUcation. In order to prevent the above-described distributing process from being used for iUegal dupUcating, we may require that the recreational appUcation or key component thereof so distributed has Umited usabiUty in the sense that it can only be used for setting up a common session with the device from which or with the help of which it was obtained. Alternatively we may define that the process of distributing a recreational appUcation or key component thereof from a certain first device to another device causes the transmission of a payment or a piece of invoicing information to the original designer and/or owner of rights of the appUcation. A yet further alternative is to aUow the user of a device to share a recreational appUcation or a piece thereof with the users of other devices that are physicaUy close enough to the "originator" device so that communication between two devices through a certain short-distance communications connection is possible. After the distance between the devices grows longer than a predefined threshold value, the "foUower" devices are deprived of the right to execute or consume the recreational appUcation. According to a second aspect of the invention the recreational appUcation consists of a piece of passive information which may be caUed the definition of a field, and an active part which we denote as the agent. Several tasks that relate to the execution of the recreational appUcation may be given to the agent. Examples of such tasks comprise but are not Umited to checking the obedience to rules in association with moves made by the participants, assisting the participants hi making advantageous moves, storing and analysing information related to different strategies of using the recreational application, and arranging the exchange of information between devices during a bi- or multilateral session of using the recreational appUcation. 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 the appUcation of a first embodiment of the invention, Fig. 2 iUustrates the appUcation of a second embodiment of the invention, Fig. 3 i ustrates the appUcation of a third embodiment of the invention, Fig. 4 iUustrates the appUcation of a fourth embodiment of the invention, Fig. 5 iUustrates the appUcation of a fifth embodiment of the invention, Fig. 6 iUustrates the appUcation of a sixth embodiment of the invention, Fig. 7 iUustrates the appUcation of a seventh embodiment of the invention, Fig. 8 iUustrates a first alternative of imposing charges, Fig. 9 iUustrates a second alternative of imposing charges, Fig. 10 iUustrates a third alternative of imposing charges, FFiigg.. 1111 iUustrates a high-level block diagram of two terminal arrangements, Fig. 12 iUustrates an alternative high-level block diagram of two terminal arrangements, Fig. 13 iUustrates a block diagram of a recreational appUcation, Fig. 14 illustrates a method executed by a terminal arrangement according to an embodiment of the invention, Fig. 15 iUustrates a method executed by a terminal arrangement according to another embodiment of the invention, Fig. 16a iUustrates a block diagram of a terminal arrangement according to an embodiment of the invention and Fig. 16b iUustrates a block diagram of a teπninal arrangement according to another embodiment of the invention. The invention is meant to be equaUy appUcable regardless of the nature of the recreational appUcation involved. As a first basic assumption known as the "game" we may assume that the recreational application concerned involves a certain degree of interactiveness between at least two opponents, at least one of which is not a computer. There is a certain domain of activity where the actions of the users manifest themselves in the form of changing relations between fhe elements of which the domain of activity consists. Certain rules define the allowable actions for the users. The domain of activity and the elements thereof are typically virtual in the sense that they only exist as digital (or partly analog) values in the memory of at least one electronic device. As a second, alternative basic assumption known as the "content" we may assume that the recreational application concerned involves an electronically stored copyright-protected piece of work, such as a piece of music, a book, a newspaper, a magazine, a film, an animation or a part or combination of those mentioned above. As an example of a recreational appUcation of the first kind we will consider a virtual board game. In that case the domain of activity consists of a virtual board and a number of virtual pieces. The board is a data structure that comprises a number of aUowed locations for the pieces. Each location can usuaUy be individuaUy addressed through a certain addressing scheme which has typicaUy a matrix form with rows and columns so that each intersection between a row and a column is an aUowed location. The board may naturaUy have more dimensions than two; the addressing matrix must have a corresponding number of dimensions. The pieces may be differently valued and may belong to different players, or at least some of them may be unclaimed. In a static situation each piece is located either at a certain aUowed location on the board or in a reserve for used and/or unused pieces. The reserves may be Umited or unlimited regarding the number of pieces with certain value. The rules of the game define at least the aUowable ways of moving the pieces between locations, the distribution of playing turns and the conditions of winning or losing the game. A typical playing turn means that a certain player moves at least one piece from its old location to a new location. The move may cause consequences, like that piece being "eaten" or set aside which was previously in said new location or the value of the moved piece or some other piece being changed as a result of reaching a certain decisive location. The game does not need to stay in a static situation between the playing turns of the players: the electronic devices through which the game is played may change the relations between the ~ pieces or the nature of the board automatically in a regular or sporadic fashion. As an example of regular automatic changing one might consider the automatic forward movement of the worms in the worm game mentioned in the description of prior art. Fig. 1 iUustrates a situation where a first user wants to utilize his first terminal for playing a game against a second user using a second teπninal. We assume that at least one of said users is not a computer. At step 101 the first user initiates the procedure which aims at playing the game. The initiation consists typically of the first user selecting the game function from a certain menu or list of available functions. At step 102 the first terminal inquires, which opponent the first user would like to play against. In known electronic solitaire games the first user plays against his own terminal. This possibiUty may be avaUable for the user even in the case iUustrated in Fig. 1, but in order to describe the applicabiUty of the present invention we assume that at step 103 the first user either keys in an identifier of the second user's terminal or selects the second user from a list of proposed candidate opponents. Taken that the terminals are mobUe telecommunication devices we may assume that such a Ust may be the same as the first user's telephone directory or a part thereof. If the game is going to be played locaUy, the first user may even instruct the first teπninal to propose the game to be played against any user the terminal of which is the first to answer a locaUy announced open caU for playing. Later on we wiU describe the generalisation of the scheme presented in Fig. 1 to multilateral sessions where more than two players take part in the game. Irrespective of the way in which the first user identified the second user (or the second user's terminal), at step 104 the first terminal transmits to the second terminal a proposal to play the game. The form and content of the proposal as weU as the route through which the proposal is transmitted are not important from the viewpoint of the present invention. The proposal may be transmitted locaUy through a local link such as an infrared communication link or a wired link, or it may be transmitted even to completely another part of the world through worldwide communication networks. A non-locaUy transmitted proposal may take the form of an SMS message (Short Messaging Service), an MMS message (Multimedia Messaging Service), an electronic mail message, a data caU, a packet-switched coπuTiunication connection or any other form of connection. TypicaUy the proposal comprises some identification information of the first user, as weU as the name or other identifier of the game the playing of which is proposed. It may also comprise additional information, such as a skill rating of the first user or a capability description of the first terminal which sets a limit to the complexity of some computational and/or presentation-related tasks concerning the game. After having received the proposal for playing the game, the second terminal produces at step 105 an indication to the second user so that the second user may decide, whether he wants to take part in the game. If the second user does not accept the proposal, he simply does not react at all or gives a negative answer. In that case the second terminal either does not transmit any response to the first terminal, or it transmits a negative response; in either case the procedure terminates after the first terminal has either received a negative response or deduced from the expiration of a time limit that the proposal was turned down. However, we assume in Fig. 1 that the second user accepts the proposal and makes his acceptance known to the second teπninal at step 106. If both the first and second terminal already possessed all necessary software components for conducting the game, the game would begin after step 106 with the second terminal indicating its readiness to the first terminal. However, in Fig. 1 we assume that the second terminal either did not have the playing software stored at aU before receiving the proposal to play, or at least some key component of the software, like a decryption key or a set of instructions, was missing. So, in order to make it possible to run the playing software in the second terminal, the second terminal transmits at step 107 a request for the software or the missing component to the first terminal. The form, contents and routing of the request are as freely selectable as was described previously regarding the proposal to play transmitted in the other direction at step 104. When the first terminal has received the request, it transmits the software or the missing component thereof to the second teπninal at step 108. Transmitting a piece of software between two or more terminals typicaUy consumes much more communication resources than transmitting simply a proposal or acceptance message. This should be kept in mind when selecting the route for the transmission at step 108. The transmission may use the same route which was used for the proposal at step 104, or it may use a different route. Even if the route itself were the same, certain communication characteristics like bandwidth reserved or modulation method chosen may be different in order to provide more throughput in the units of bits per second for the transmission of the software. After the transmission is complete and the second terminal has received and stored the appropriate pieces of information that make it capable of running the playing software, it sends at step 109 an acknowledgement message to the first terminal: The reception of the acknowledgement message at the first terminal causes the terminal to announce to the first user at step 110 that playing may begin. The second terminal gives a similar indication to the second user at step 111. Thereafter the actual playing of the game may start: it involves typicaUy the repeated exchange of messages where the players announce their moves. This step is generaUy represented in Fig. 1 as 112. We will return later to the role of the agent, which is associated with a certain aspect of the invention, during step 112. The procedure of Fig. 1 could be simplified if the first terminal transmitted already within the proposal to play at step 104 also the playing software or the missing key components thereof to the second terminal. In such a case the steps 107 and 108 would not be needed at all. If the second user accepted the proposal at step 106, the acknowledgement to the first terminal could be transmitted immediately; if not, the second terminal would simply discard the received playing software. However, such a simpUfication would considerably increase the use of communication resources, between the first and second terminals, because however simple a game, the corresponding software or even only a key component thereof is likely to consume much more communication resources than just a simple proposal message. AU resources used for proposal+downloading transmissions which do not lead to playing the game would be wasted. In the foregoing we assumed that the first terminal is the source for downloading the playing software or key component thereof to the second terminal. We may designate such an embodiment of the invention as the "Would you play this game with me" embodiment. However, in many cases it may prove to be more advantageous to use an external data source for downloading. From prior art downloadable recreational appUcations there is known the concept of having the actual appUcations stored in a server somewhere in a communications network. Terminals that wish to download a certain recreational appUcation make a request to said server, and in return they obtain the requested recreational appUcation or the parts of software that are required in order to make an already existing other part of software usable. Fig. 2 iUustrates an appUcation of an embodiment of the present invention where the principle of downloading recreational software from a server is appUed. This embodiment is designated as the "Get a game like this so we can play" embodiment. Steps 101, 102 and 103 are the same as in Fig. 1. However, at step 204, together with the proposal for playing the game the first teπninal transmits to the second terminal the network address, telephone number for data caUs or SMS messages, dynamic Internet Protocol address link, or other contact information of the server from which the playing software or key component thereof may be downloaded. In the foUowing we wiU use the designation "network address" to denote any form of contact information. Informing the second terminal about the network address requires naturaUy that the first terminal is aware of such a network address. We may assume that the playing software has been previously downloaded to the first terminal from the same server, so that the first terminal has stored the address together with the sof ware itself. Even if the playing software had been brought to the first terminal through some other route like on an attachable memory module, the downloading address may have come together with the software. Steps 105 and 106 are again same as in Fig. 1. An important difference comes after step 106 where the second terminal has received the second user's acceptance for playing the game. Instead of contacting the first terminal, at step 207 the second terminal sends to the game server a request for downloading the playing software or the missing parts thereof. As a response the game server transmits at step 208 the requested information. After having received the requested information, the second terminal transmits at step 109 an acknowledgement message to the first terminal, indicating that it is now ready for playing. This step, as weU as the indication steps 110 and 111 and the playing step 112 are the same as in the embodiment of Fig. 1. The communication connection between the second terminal and the game server at steps 207 and 208 may physicaUy take the form of a data caU, a packet-switched communication connection, a WAP connection (Wireless AppUcation Protocol), an SMS connection or any other connection. In order not to unnecessarily delay the beginning of the game, the physical form of the connection is most advantageously selected to be as fast as possible. Fig. 3 iUustrates the appUcation of another embodiment of the invention which differs only sUghtly from that of Fig. 2. We caU the embodiment of Fig. 3 the "If you want to play with me I teU you where to get the game" embodiment. Steps 101, 102, 103, 104, 105, 106 and 107 are actually the same as in the embodiment of Fig. 1. However, as a response to the second terminal's request for downloading the playing software or key component thereof at step 107, the first terrninal does not directly provide the requested information but transmits, at step 308, the network address of the game server or other network resource from which the requested information can be downloaded. Thereafter the requesting and downloading operations between the second terminal and the game server at steps 207 and 208 take place as in the embodiment of Fig. 2. The remaining acknowledgement and indication steps 109, 110 and 111 and the playing step 112 are the same as in the embodiments of Figs. 1 and 2. Mirror images of the embodiments of Figs. 2 and 3 are also encompassed by the invention; mirroring means that the second terminal is the one already possessing the playing software or key component thereof and the first terrninal must acquire it. In Fig. 2 this means that the proposal of step 204 does not necessarily contain a server address, and that instead of asking for the playing software or key component thereof from the game server at step 207 the second terminal transmits to the first terrninal a message where it agrees to play a game and teUs the first terrninal the server address. The steps of asking for and providing the playing software or key component thereof according to steps 207 and 208 take part between the first teπninal and the game server, whereafter the first terminal transmits the acknowledgement of step 109 to the second terminal and not vice versa as in Fig. 2. Mirroring the embodiment of Fig. 3 means that at step 107 the second terrninal agrees to play, after which at step 308 the first terminal asks for the server address. Thereafter comes an additional step in which the second terminal transmits to the first terminal a message where it teUs the first terminal the server address. Thereafter the procedure continues as in the above-explained mirror image of Fig. 2 from the steps of asking for and providing the playing software or key component thereof. Fig. 4 iUustrates the appUcation of another embodiment of the invention which also differs only sUghtly from that of Fig. 2. We call the embodiment of Fig. 4 the "If you want to play with me I ask them to send you the game" embodiment. Steps 101, 102, 103, 104, 105, 106 and 107 are again the same as in the embodiment of Fig. 1. However, as a response to the second terminal's request for downloading the playing software or key component thereof at step 107, the first terrninal does not directly provide the requested information but transmits, at step 408, to the game server a request for downloading the playing software or the missing parts thereof also to the second terminal. This request must naturaUy comprise some kinf of identification information of the second terminal so that the game server is able to "attach the correct address label" to its transmission. As a response the game server transmits at step 409 the requested information to the second terminal, which acknowledges the successful reception of the transmitted information with an acknowledgement message to the first teπninal at step 109. Steps 110, 111 and 112 are the same as before. In a mirror image of the embodiment of Fig. 4 step 107 is omitted and steps 408, 409 and 109 are flipped 180 degrees about the "GAME SERVER" line. In other words, the second terrninal asks the game server to send the playing software or the missing parts thereof to the first terrninal, such transmission is accompUshed and the first terminal acknowledges to the second terminal having received the transmission. A characteristic feature of the embodiments described so far, except the mirror image embodiments, is that the first terminal is assumed to possess a fuUy operational version of the playing software even before proposing a playing session to the second terrninal. The invention does not require such an assumption to hold. Fig. 5 illustrates an "Let's play, FU get the game" embodiment of the invention where the steps 101, 102, 103, 104, 105, 106 and 107 are again the same as in the embodiment of Fig. 1. However, as a response to the second terminal's request for downloading the playing software or key component thereof at step 107, the first terminal does not directly provide the requested information but transmits, at step 508, to the game server a request for downloading the playing software or the missing parts thereof to the first terrninal. As a response the game server transmits at step 509 the requested information to the first terminal. After having received the requested information, the first terminal forwards it at step 510 to the second terrninal, which acknowledges the successful reception of the transmitted information with an acknowledgement message to the first terminal at step 109. Steps 110, 111 and 112 are again the same as before. In a mirror image of Fig. 5 step 107 is omitted, steps 508 and 509 take place between the second terminal and the game server, at step 510 the second server transmits some version of the playing software or the missing parts thereof to the first terrninal and at step 109 the first terminal acknowledges. In another sUghtly altered embodiment the second terminal already possesses the playing software or the missing parts thereof but the first terrninal does not. In such a case the contents of the message at step 107 would be "OK, I have it already, you go and get one yourself'. In that case the message at step 510 would be an acknowledgement where the first terrninal announces it to be ready, after which steps 110 and 111 can be executed without another acknowledgement at step 109. Fig. 6 iUustrates the appUcation of an embodiment of the invention which is a kind of combination of the embodiments of Figs. 4 and 5. The designation of this embodiment is "Let's get a game and play if. Steps 101, 102, 103, 105 and 106 are the same as in e.g. Fig. 1, and step 204 is the same as in Fig. 2 in the sense that the proposal of the first terrninal also includes the network address from which the playing software can be downloaded. Step 607 which takes place after step 106 is an acknowledgement from the second terrninal where it announces to the first terrninal the second user's willingness to play. After that both teπninals send to the game server their own requests for downloading the playing software or the missing parts thereof at steps 608 and 609. The game server responds by transmitting the requested information to both terminals at steps 610 and 611. After having successfuUy received the requested information, one of the terminals, which in Fig. 6 is the first terrninal but which could as well be the second terminal, transmits at step 612 to the other terminal a message where it announces itself to be ready and may even ask the other terminal about its readiness. At the next step the other terrninal confirms that it also is ready; this message is actually an acknowledgement just like that previously introduced as step 109, so the same reference designator is used also in Fig. 6. Steps 110, 111 and 112 are again the same as before. The idea of Fig. 6 can be implemented with one transmitted message less if, instead of sending the first acknowledgement 607, the second terminal executes steps 608 and 610 immediately after receiving the accept command 106 from the user and only thereafter sends an acknowledgement like that of step 607 to the first terminal. The first terrninal would then execute steps 609 and 611 after receiving said acknowledgement and transmit a general ready message 612 after it had downloaded the playing software or the missing parts thereof. Step 109 could then be omitted, and steps 110 and 111 would come immediately after step 612. However, this alternative doubles the waiting time before playing may begin since the downloadings take place in succession rather than simultaneously as in Fig. 6. The embodiments described so far have underlined the role of the first user in selecting the game to be played. Fig. 7 iUustrates the appUcation of another embodiment of the invention where the second user has much more to say in this respect. This embodiment is designated as the "Let's play one of your games" embodiment. Steps 101, 102 and 103 are the same as before. However, the proposal sent by the first terrninal to the second terminal at step 704 is only a general proposal for playing a game together. It may contain some limiting information describing the preferences of the first user and/or the capabiUty of the first terrninal, like "Let's play some game which is suitable for chUdren under 10 years", "Let's play some card game" or "Let's play some game which can be run in a terminal of type XX (or in a terrninal of capabiUty class YY)". The invention does not obUgatorily require it to contain any such Umitations. At step 705 this proposal is conveyed to the second user. Before conveying the proposal to the second user the second terrninal may translate any preferences contained therein into some other form, e.g. depending on the capability of the second teπriinal. As an example we may assume that the first terminal proposed at step 704 to play "a card game, chess, go or some variation of the worm game". We further assume that of these, only card and worm games can be run in the second terminal, in which case the second terrninal conveys at step 705 to the second user a proposal in the form "Opponent NN would like to play some card game or some variation of the worm game against you". At this stage the second user could again turn down the whole proposal. However, we assume that the second user expresses at step 706 his willingness to play. Additionally the second user may already at this stage select the game he wants to play, or select a subset of the proposed set of games. We further assume that in the case of Fig. 7 the second user would be wilting to play some card game, but he lets the first user to select which one. In that case the acceptance input to the second terminal at step 706 has the form "OK, some card game against NN would be nice". If the second user would accept any of the proposed games, he would simply express his agreement at step 706. As a response, the second terminal transmits at step 707 to the first terminal a message in which it presents the selection of games the software of which exists in stored form in or at the disposal of the second terrninal. If the second user had made Umitations at step 706, the transmission at step 707 would contain only the coπespondingly Umited selection of games. At step 708 the first terrninal forwards the selection of games to the first user and prompts the first user to select the game to be played. At step 709 the first user makes his selection. As a response, the first terminal transmits at step 710 a request for the required software or the missing component to the second terminal. The form, contents and routing possibiUties of the request correspond to those described in association of step 107 in Fig. 1. When the second terrninal has received the request, it transmits the software or the missing component thereof to the first terminal at step 711. If the second user would have wanted to decide exactly the game which he would like to be played, he could have simply made his selection at step 706. In such a case the selection of games presented to the first terminal at step 707 and further to the first user at step 708 would only consist of a single game. Step 709, which above is said to consist of the first user making his selection among a group of proposed games, would thereby become a simple accept/reject decision: either the first user accepts the game to be played or he turns down the proposal. In any case, after the transmission of the playing software or the missing component thereof is complete and the first terminal has received and stored the appropriate pieces of information that make it capable of running the playing software, it sends at step 712 an acknowledgement message to the second terminal and announces to the first user at step 110 that playing may begin. The second terrninal gives a similar indication to the second user at step 111. Thereafter the actual playing of the game may start, as is generaUy represented in Fig. 7 as step 112. The multitude of approaches in using a game server as the source of dowr oading the playing software or a key component thereof, presented above in association of Figs. 2 to 6, can naturally also be applied to the principle of Fig. 7 where the second terminal is given at least partly the responsibiUty of deciding, which game(s) is/are to be played. As an example, at step 707 the second terminal may inform the first terminal about the network address(es) from which the games may be downloaded, which corresponds to the principle of Fig. 2, or the network address might be given only after the first terminal's request at step 710 similarly as in Fig. 3. In association with Figs 1 to 6 we discussed mainly those cases where the first user proposes a certain individual game to the second user. A generaUsation is possible in this respect: at aU those steps where the first terminal is said to transmit to the second terminal a proposal for the game, the first terminal may actuaUy transmit a whole Ust of games. When the second terrninal proposes the games in the Ust to the first user, it may again limit the selection to those games which are possible to run in the second terminal. In stating his acceptance the second player selects the game he agrees to play, and the step of asking for the game program is amended so that the second terminal announces exactly which one of the proposed games should be downloaded. Next we wiU examine the procedures iUustrated in Figs. 1 to 7 from the viewpoint of the "content" assumption mentioned previously. It is typical to the "content" assumption that after the distribution of the recreational appUcation has been accompUshed, there is tittle or no such interaction between the terminals that would directly relate to consuming the recreational appUcation. Each user of a terminal consumes his obtained copy of the recreational appUcation by himself, like by listening to a piece of music or by reading an article. However, in order to keep dishonest users from making and distributing iUegal copies of copyright-protected material, it may be required that during the time of consuming the recreational appUcation the terminals must be close enough to each other so that they can exchange control messages through a short-distance communications connection. Alternatively or additionaUy a copy of distributed "content" (or certain important piece of software that is needed for its consumption) may be equipped with a time bomb type algorithm that only aUows it to be consumed for a Umited time after distribution. Under the "content" assumption we may explain step 101 in Fig. 1 so that the user of the first terrninal initiates the lending of some content to another user. At step 102 the first terminal prompts the user to identify the party to which the recreational appUcation is to be lent, and at step 103 the first user gives some identification information of the second user. At step 104 the first terminal sends a message to the second terrninal, the essential contents of the message being a proposal to receive a copy of the recreational appUcation in question. At step 105 the second terminal presents the proposal to its user (known as the second user) through a user interface, and at step 106 the second user expresses his acceptance. At step 107 the second terminal asks the first terrninal to transmit the recreational application in question, and the actual transmission of the recreational appUcation follows at step 108 with an acknowledgement from the second terminal to the first at step 109. Due to the Umited amount of foUowing interaction between userd the "ready to consume" messages are now not needed, so step 110 may be completely omitted and step 111 may consist of simply beginning the consumption, i.e. starting the presentation of the acquired copy of the recreational appUcation to the second user. FoUowing the assumption that communication through a short-distance communications connection must be active during the time when the second user is aUowed to consume the recreational appUcation, we may say that step 112 in Fig. 1 iUustrates such communication. We may denote such communication as "patting the watchdog". The invention does not place Umitations to the actual way that is used for patting the watchdog. The short-distance communications connection used is typicaUy a short-distance wireless link such as a Bluetooth connection or an infrared connection. In order to make the patting routine safe against attempts of recording the actions of the first terrninal and using some sort of reproduction device to imitate them after the first terrninal has gone, the patting routine should involve certain dynamic nature, i.e. the signals used for patting should change over time. We regard the actual implementation of suitable patting routines as falling within the capability of a person skiUed in the art. Also the invention does not place Umitations to whether the consumption of same content should be disabled or not at the first terrninal during the time when the content is consumed at the second terminal. Both alternatives are possible. The procedure of Fig. 2 is easily understood also under the "content" assumption. Steps 101 to 106 are the same as above, and at step 207 the second terminal contacts a content server instead of the first terminal to ask for downloading the content in question. Downloading the requested content from the content server to the second terrninal takes place at step 208, after which an acknowledgment is sent to the first terminal at step 109 in order to start the patting the watchdog routine. Step 110 can be again omitted (although here as well as above it may be useful to inform the first user about the latest developments in successfuUy acquiring a copy of the content in question by the second terminal), and steps 111 and 112 are the same as above. The procedures illustrated in Figs. 3 to 7 are likewise easily read under the "content" assumption by noting that in each downloading step the content in question (or a certain important software component needed to consume the content in question) is downloaded and not a game. The patting the watchdog routine applies in a similar way in aU cases. We wiU now move on to the subject of defining the rights of using the playing (or more generaUy: recreational) appUcation and the possibiUties for charging at least one of the users a fee for the playing or consuming session which is set up according to one of the embodiments described above. With respect to the rights, we assume that there exist at least two categories of Ucences: a copy of the recreational appUcation may come either as fuUy Ucenced, in which case it can be freely used for any playing or consuming session either alone or against/with one or more opponents, or it may come with a restricted Ucence which aUows its use only during a certain session and/or against a certain opponent or group of opponents. Known arrangements exist for automaticaUy enforcing such Ucencing conditions: for example a copy of software with a limited Ucence may be only run through for a limited number of times, in which case a counter built into the software itself disables further attempts of use after the maximum count has been reached. Or the software may only operate correctly after it has checked that the time obtained from some real time clock is within predetermined limits. In other arrangements aU outgoing messages are encrypted with a key which or the counterpart of which is only known to a certain registered opponent. The actual mechanism which is used to implement a restricted Ucence are not important to the present invention: it suffices to know that such a mechanism exists. In the embodiment of Fig. 1 it is most natural to assume that the first terrninal possesses a fuUy Ucenced copy of the recreational application, or at least such a copy where the choice of opponent(s) is not Umited, because otherwise the step of choosing the opponent would not make sense. It is also natural to assume that the first user has paid a fee at the stage when he acquired the recreational appUcation and stored it into his terminal. In order not to aUow the second user to take undeserved advantage of the fact that he actuaUy gets a copy of the recreational appUcation which only the first user paid for, it is advisable to transmit at step 108 only a copy of the recreational appUcation with a limited licence. The limitation may be temporal so that the second user can only use the software for a certain time, or related to the number of sessions so that the second user may only use it once or only a few times (preferably in his session against the first user), or even personal so that the second user may only use the software to play against the first user, which is the legal owner of the software copy. It may be advantageous place even a limitation which disables any soUtary use of the software in the second terrninal alone. Above we have already described the possibility of placing a restriction depending on physical location or more accurately on mutual distance of two teπninals. The embodiments of Figs. 2 and 3 have the common feature that the second terrninal requests and downloads its own copy of the recreational appUcation directly from the game or content server, which we assume to be run if not directly by the original owner of rights then at least with his consent. Therefore it is rather straightforward to arrange the downloading of such a copy of the recreational appUcation the Ucenced rights of which correspond to the needs of the second user, and also for charging the appropriate fee (if any) from the second user. This appUes especiaUy if the recreational appUcation copy to be downloaded is not meant to be associated with the fact that it was actuaUy a certain first user which originaUy proposed playing the game or consuming the content. However, we may envisage also a situation where the first user offers to pay to the owner of rights the fee which is payable for the intended playing or consuming session. In such a case certain cryptographic authentication methods may be used in accordance with Fig. 8. At step 801, which typicaUy coincides with the general step 104 or 204 of proposing for a game or a session, the first teπninal transmits to the second terminal a cryptographicaUy authenticated offer where the first terminal offers to pay for a session with the second terminal. Known cryptographical autenhication methods exist for providing both authentication of origin and non-repudiation, i.e. for ensuring that even if such an offer is later used somewhere else it is clear that the originator was just the first terminal in question and the first terminal can not ever! deny having sent such an offer. Additionally it is clear even later that it was just the second teπninal in question against which the first terrninal intended to play, and not any arbitrary second terminal. The extent to which the second user should be able to use the recreational appUcation can be chosen by the first user and encoded into the cryptographicaUy authenticated offer. NaturaUy the first user may even offer to pay for a complete, fully licenced copy to the second user. However, we expect that a more often encountered situation is such where the first user offers to stand for the costs of a single session only or for a Umited number of sessions between him and the second user. At step 802, which typicaUy coincides with the request step 207, the second terminal presents said cryptographicaUy authenticated offer to the game or content server. From the offer the game server checks, who is the party who offered to pay the fee, and whether the second terminal that presented the offer is just the second* terminal which is mentioned in the offer as the intended opponent. The latter check is used to ensure that the user presenting the offer is not any third party which would have snatched the offer from the Internet or other unsecure communication network. At step 803 the game or content server deducts the fee for one (usuaUy Umited) Ucence from the account of the first user, and at 804 which typicaUy coincides with step 208 the game or content server transmits the recreational appUcation with its associated (Umited) Ucence to the second terminal. The arrangement of Fig. 4, where the first terrninal instructs the game or content server to transmit a recreational appUcation to the second user, readily suggests that also here it would be the first user who stood for the costs. When the order for the recreational appUcation to the second terrninal comes directly from the first terminal to the game or content server, it is even simpler than in the above-described arrangement of Fig. 8 to enable the first teπninal to define the Ucence conditions for the copy to be transmitted to the second terminal: the first terrninal simply transmits at step 408 to the game or content server a cryptographicaUy authenticated message in which it instructs the game or content server to send to the second terminal a recreational appUcation with the licence as defined in the message itself, and to charge the associated fee (if any) from the account of the first user. However, the embodiment of Fig. 4 also aUows for the authenticated order to come from the second terrninal in accordance with Fig. 9. At step 901, which typically coincides with step 107, the second terrninal transmits to the first terminal a cryptographicaUy authenticated order in which the second terrninal defines the Ucencing conditions which it wants to apply to its ordered copy of the recreational application. At step 902, which typicaUy coincides with step 408, the first terminal forwards the cryptographicaUy authenticated order to the game or content server. At step 903 the server decodes the order. If an intended opponent (the first terrninal) is mentioned in the order, the game or content server may even check at step 903 that the order came through the mentioned intended opponent. The server deducts the appropriate fee (if any) from the account of the second user and transmits, at step 904 which is the same as step 409 in Fig. 4, the ordered recreational application to the second terrninal. Any of the approaches of Figs. 8 and 9, or both, may be used in association with the embodiment of Fig. 5. If the first user stands for the costs, the coπesponding cryptographicaUy authenticated order is transmitted to the game or content server together with the request of step 508. If the second user wants to pay, the corresponding cryptographicaUy authenticated order is transmitted to the first terminal at step 107 and forwarded to the game or content server together with the request of step 508. Fig. 10 iUustrates a combined approach where at step 1001, which typicaUy coincides with step 107, the second terminal transmits to the first terrninal a cryptographicaUy authenticated order in which the second terminal defines the Ucencing conditions which it wants to apply to its own ordered copy of the recreational appUcation. At step 1002, which typicaUy coincides with step 508 the first terminal forwards the cryptographicaUy authenticated order to the game or content server along with its own cryptographicaUy authenticated order in which the first terminal defines the Ucencing conditions which it wants to apply to its own ordered copy of the recreational appUcation. At step 1003 the server decodes the orders. If an intended opponent is mentioned in the orders, the game or content server may even check at step 1003 that the orders constitute a matching pair. The server deducts the appropriate fees (if any) from the accounts of the users and transmits, at step 1004 which is the same as step 509 in Fig. 5, the ordered recreational appUcation copies to the first terminal. It is then on the responsibiUty of the first terrninal to forward the coπect copy to the second terminal. Any of the approaches described above in association with Figs. 8, 9 and 10 can be apphed in association with the embodiment of Fig. 6. The embodiment of Fig. 7 is a kind of mirror image of that of Fig. 1 in the sense of distributing the recreational appUcation copies under certain licence conditions. It is on the responsibiUty of the second terminal to transmit, at step 711, a copy with a suitably Umited Ucence to the first terrninal so that the user of the first terrninal does not get any undeserved advantage e.g. in the form of a recreational application which he would not have paid for but which could be used freely. Next we wiU describe an advantageous general structure for the playing software and the aspects rising therefrom that relate to the distribution of the software and its components. Fig. 11 is a high-level block diagram which iUustrates a first terrninal 1101 and a second terminal 1102. In each terminal there are two software components that together constitute a certain piece of recreational software. In the first terrninal 1101 there is the first agent program 1103 and a first copy of the field of activity 1104. Coπespondingly in the second terminal 1102 there is the second agent program 1105 and a second copy of the field of activity 1106. The agent is an "active" component of the recreational software, whereas the field of activity is a "passive" component. These concepts have been defined so that the field is merely a certain allocated storage area where the momentary conditions and possible mutual relations of the elements of the recreational software are stored, whereas the agent is a collection of processes that interact with the user, the field, the opponent and possibly also with one or more elements in a network 1107. Recalling our virtual board game example we may say that the field consists of the game board and the pieces, whereas the agent consist of all those processes that are related to mamtaining and changing the locations and mutual relations of the pieces on the board. TypicaUy the conimunication between playing parties is implemented as exchange of messages between the agents. The first and second copies 1104 and 1106 of the field of activity should remain synchronized in the sense that both players see the situation in the game to be the same. This does not mean that both players should receive exactly the same information about the situation in the game: for example in the majority of card games no one is aUowed to see the hands of (i.e. the cards possessed and not shown by) the other players. Fig. 12 iUustrates an alternative high-level block diagram which is especiaUy appUcable to those situations where only a Umited copy of the recreational software is given to one of the users. In the embodiment of Fig. 12 the users, the terminals 1101 and 1102, the first agent 1103, the first and second copies 1104 and 1106 of the field of activity and the network 1107 have sirmTar roles as in Fig. 11. Instead of an agent of his own, the second user has only a command link program 1205 stored into his terrninal. The difference between an agent and a command link is in capability: the message link 1205 is only capable of translating the commands given by the second user into changes within the second copy 1106 of the field of activity, conveying the commands to the first teπninal, and receiving commands from the first teπninal and translating them into changes within the second copy 1106 of the field of activity. We may say that the combination of a command link and a copy of the field of activity together constitute the ntinimum requirements of playing against another user which has an actual agent at his disposal. Below we wiU analyse certain potential advanced functional features of the agent; if the second user should be given any access to these in the arrangement of Fig. 12, they must be made available remotely so that the agent 1103 in the first terrninal serves also up to some extent the second user. Fig. 13 illustrates a more detaUed structure for an agent according to an embodiment of the invention. Also the field of activity 1301 is seen in Fig. 13. For the reason of illustrativeness we wiU use the language relating to board games in the following description, so e.g. the field of activity 1301 is caUed the board. A certain command interpreter block 1302 receives the move commands from the user (which move commands themselves may come in any form, like key presses, roUerbar movements, other mechanical movements, voice commands etc.) and translates them into a form where they represent directly certain movements of pieces on the board. The translated commands could be taken directly to the board 1302 to implement the changes, but in the embodiment of Fig. 13 we assume that they are first taken to an analysing block 1303 the task of which is to check, with the help of a set of rules read from a database 1304, that the moves are legal. Accepted moves can then be implemented on the board 1301. If a move is not accepted, a negative acknowledgement (NACK) can be generated for the user in block 1305. In addition to analysing legaUty, the agent may also check, whether the intended move is wise and in accordance with a previously selected playing strategy. For this purpose the analysing block 1303 may forward a formaUy accepted move into another analysing block 1306 the task of which is to analyse the situation on the board 1301, and further to an electronic assistant block 1307 which generates, on the basis of the analysis given by block 1306, an evaluation of the intended move and gives it as an output to the user. In its evaluation work the electronic assistant block 1307 may consult a database 1308 of stored previous games and typical moves. Said database and the electronic assistant block 1307 may have been programmed to adapt their operation according to a certain identified opponent player, so that e.g. previous games against the same opponent are used in predicting, what would be the typical reaction of the opponent to a certain intended move. After having received the hint from block 1307, the user either makes another move or confirms the previous move so that the effect becomes visible on the board. The moves made by the player could be transmitted as outputs to the opponent directly from block 1302. However, if it is the intention of the user to first let his agent to analyse his intended move and reveal to the opponent only those moves which actually become confirmed, it is possible to make the information to the opponent be generated in block 1309, which gives the status on the field after the move has been accompUshed. Information from block 1309 comes also to the user himself and goes into block 1308 to be stored as a part of the game history. Previously we noted that certain moves on the board may even take place automatically. Block 1310 is responsible for accomplishing these moves. They come into the knowledge of the user and the opponent through the status reports generated in block 1309. Move commands from the opponent are first received in block 1303, where their legality is checked. If a move command from an opponent is found to be against the rules, a negative acknowledgement is transmitted to the opponent from block 1305. A simpler alternative would be just to ignore move commands that are against the rules. If the approach of using acknowledgements is chosen, it is advantageous to make block 1305 to transmit an acknowledgement, positive this time, even for accepted moves so that the opponent knows that his move command has come through. Block 1303 may even check from a Ucence poUcy block 1311 that it is aUowable, under the existing Ucence conditions, to accept commands from (i.e. to play against) a certain opponent. Accepted move commands from the opponent take effect on the board 1301. If the agent is used remotely also by the opponent as in Fig. 12, the above-described loop of analysing and possibly suggesting a better move through the actions of blocks 1303, 1306, 1307 and 1308 can also be used. Before giving hints to the opponent, block 1307 may check from the Ucence poUcy block 1311 that it is aUowable, under the existing Ucence conditions, to give assistance to a certain opponent. The user may give also other kind of inputs to the agent than just move commands. In the arrangement of Fig. 13 these are interpreted in a command and inquiry interpreter block 1312. For example, a command to use a local communication link instead of the general network interface for communication with another terrninal is routed from block 1312 to a transmission mode selection block 1313 and furher to the transmission mode selection unit of the terminal (not shown). The user may also request status information of the current situation on the board as weU as other aspects relating to the game: such requests are routed from block 1312 to block 1309. Through block 1312 the user may also control the generation of automatic moves in block 1310. If the concept "automatic moves" is understood widely, it covers also the arrangements related to the beginning of a game where the pieces are set into their starting positions. The user may give commands related to the storing of previous games and moves typical to certain strategies, to the generation of hints and replayes of previous games and moves, and to the analysing of the situation on the board. These commands are routed from block 1312 to blocks 1308, 1307 and 1306 respectively. A request for a rule or a help text is routed from block 1312 to block 1304, which provides the requested information to the user, possibly after checking from the Ucence poUcy block 1311 that it is aUowed, under the current Ucence conditions, to provide the user with output copies of rules and/or help texts. The user may also select the skiU which he wishes the hints given by block 1307 to represent, or to switch off the advisory function of block 1307 completely. Such requests are routed from block 1312 to a skill level definition block 1314 which controls the operation of block 1307. There may also be couplings from the agent to a telecommunications network; in Fig. 13 these are represented by a connection from the network into the Ucence poUcy block 1311 and from block 1312 to the network. The network connection can be used e.g. for checking and updating Ucence poUcies and for transmitting downloading requests to a game server in the network. It is not necessary to use the agent between the field and the user just to show the status of the field. The display driver of the terrninal may have the right to directly access the memory location where the representation of the field and its current situation is stored so that the information is transferred directly from the storage location through the display driver into the display and further visuaUy to the user. This connection is shown in Fig. 13 with a broken line. I Taken that the agent has multiple roles and functions as was described above in association with Fig. 13, it is easy to present simpler and more compUcated versions of agents so that in a simpler version only a part of the functions of the more compUcated version are avaUable. Especially in a situation where only one of the players has acquired and paid for a fully Ucenced version of the software, it is advantageous to keep a fuUy functional agent program only at the disposal of that player and distribute simpler agent versions to the other players participating in a playing session. This way one would ensure that the other players can not take fuU advantage of the distributed software components afterwards, without paying the fee for a complete version downloaded from the game server. A simpler version need not be physicaUy a real subpart of the more compUcated version; it suffices to lock some of the components shown in Fig. 13 behind a password which a user can only obtain from an authorized dealer of the software. Naturally both players can also have equaUy equipped and equaUy helpful agents at their disposal to help them in executing the recreational application. Yet another alternative is such where the initiating player (who has typically acquired and paid for a fuUy Ucenced version of the software, and who is thus most likely to be the most experienced one of the players in this particular software), lends a more helpful agent to his inexperienced opponent than what he is using himself. The experienced player may play even completely without help from any artificial intelUgence, while the inexperienced player (or the players together) may select a suitable level of assistance from the agent to help the inexperienced player to be a more equal opponent. Getting a chance of winning as well as getting the impression of playing against an opponent whose level of skiU is suitably high to offer some chaUenge, be it with the help of artificial intelUgence or not, motivates each player to continue playing more and more. Fig. 14 iUustrates a method according to an embodiment of the invention, especiaUy the method executed by a terrninal which acts as the first terrninal in a situation of one of Figs. 1 to 7. The operation begins at step 1401 when the terrninal receives from its user an initiation for playing a game which requires an opponent. At step 1402 the terminal asks the user to identify the opponent and receives some identification of the opponent. Step 1403 is a decision between proposing a certain game or games (embodiments of Figs. 1 to 6) and just proposing to play (embodiment of Fig. 7). A negative decision at step 1403 leads to step 1404 where just a general proposal is sent to the opponent. At step 1405 the terminal waits for a positive response from the second terrninal; if such a response does not arrive in a reasonable time, the procedure terminates which in Fig. 14 is iUustrated by a small circle. A positive response from the second terminal at step 1405 means that the second terrninal presents a selection of games. This selection is forwarded to the user at step 1406. At step 1407 the terminal waits for the user to make his choice. No choice or a negative answer again lead to termination of the procedure. When the user has made his selection, the teπninal asks at step 1408 the second terminal to transmit the required software or the missing part thereof. Step 1409 is a check whether the software or the missing part thereof was received locaUy. A negative finding means that only a network address was obtained, in which case the software or the missing part thereof is downloaded from the game server at step 1410. When the software or the missing part thereof has been obtained in one way or another, an acknowledgement is transmitted to the second terminal at step 1411. After the terminal has given a "ready" signal to the user at step 1412 playing may begin. If a positive decision was made at step 1403, the terminal is acting as in one of Figs. 1 to 6. At step 1420 it checks, whether the software or the missing part thereof should be distributed locaUy or whether the game server wUl be involved. A positive finding at step 1420 leads to a procedure according to Fig. 1 beginning with step 1421 where the terminal transmits a proposal for a certin game or a selection of games to the second terminal. Steo 1422 denotes waiting for a positive response from the second terminal. If none is obtained, the procedure terminates. If the second terminal gives a positive response, possibly identifying a game if a Ust of games was proposed, the software or the missing part thereof which was requested is transmitted at step 1423. At step 1424 the terminal waits for an acknowledgement; if it remains missing, the procedure terminates. After a positive acknowledgement at step 1424 the terrninal gives a "ready" signal to the user at step 1412 and the playing may begin. After a negative decision at step 1420 the terminal decides at step 1430 whether it should send the network address of the game server to the second terminal immediately in the proposal, like in Figs. 2 and 6. A negative decision at step 1430 means that just a proposal for game or games is transmitted to the second terrninal at step 1431, like in Figs. 3, 4 and 5. Again a positive response is waited for at step 1432 with the possibihty of teπninating procedure if the positive response does not come. When it comes it causes a transition to step 1433 where the first terrninal checks whether it should itself download the software or the missing part thereof. A negative decision at step 1433 means that the procedure of either Fig. 3 or Fig. 4 is foUowed. Step 1434 is a further check whether the first terminal should request the game server to serve the second terminal. A positive finding at step 1434 means that the procedure of Fig. 4 is followed, in which case the first terminal transmits the request to the game server at step 1435. A negative finding at step 1434 means that the procedure of Fig. 3 is followed, in which case the first terminal only transmits the network address of the game server to the second teπninal at step 1436. In either case the first terminal ends up at step 1424 waiting for an acknowledgement; if it remains missing, the procedure terminates. After a positive acknowledgement at step 1424 the terminal gives a "ready" signal to the user at step 1412 and the playing may begin. A positive finding at step 1433 means that the first teixninal must itself download the software or the missing part thereof, as in Fig. 5, which it does at step 1440. If the procedure of Fig. 5 is foUowed, a positive decision is always made at step 1441 meaning that the software or the missing part thereof is transmitted to the second terrninal at step 1442. The first terrninal ends up again at step 1424 waiting for an acknowledgement; the above-given description appUes from there on. A positive finding at step 1430 meant that the procedure of either Fig. 2 or Fig. 6 is foUowed. The proposal with the network address(es) of the game server(s) is transmitted at step 1450. After a check for a positive response at step 1451 there is a check at step 1452 whether the procedure of Fig. 2 or Fig. 6 is followed: a negative finding means a direct transition to step 1412, because the positive response received already counted as an acknowledgement (see step 109 in Fig. 2), and a positive finding at step 1452 means a transition to the downloading step 1440, after which the first terrninal now arrives at a negative decision at step 1441, transmits its own ready signal to the second terminal at step 1453 and goes into step 1424 waiting for an acknowledgement; the above-given description appUes from there on. Fig. 15 iUustrates a method according to another embodiment of the invention, especiaUy the method executed by a terminal which acts as the second terrninal in a situation of one of Figs. 1 to 7. The operation begins at step 1501 when the terminal receives from the first terminal a proposal for playing a game. Step 1502 is a check whether the opponent is proposing a certain game or games (embodiments of Figs. 1 to 6) or just proposing to play (embodiment of Fig. 7). A positive finding at step 1502 leads to step 1503 where the proposal identifying the game(s) is presented to the user. At step 1504 the terrninal waits for a positive response from the user; if such a response is not given in a reasonable time, the procedure terminates which in Fig. 15 is iUustrated by a smaU circle. A positive response from the user at step 1504 means that the user agrees to play the proposed game or one of the proposed selection of games. When the user has made his selection, the terminal checks at step 1505 whether it already knows a network address from which the required software or the missing part thereof should be downloaded. A negative finding means either that a network address is stiU to be obtained or that the software or the missing part thereof is to be received locally. In either case the terminal requests the first terminal to provide the software or the missing part thereof at step 1506. At steps 1507 and 1508 the terrninal checks, what was received after such a request. Receiving a network address causes a transition to step 1509, where the software or the missing part thereof are downloaded from the game server. Receiving instead the software or the missing part thereof either directly from the first terminal or from the game server (the latter as a result of the first terrninal having instructed the game server to transmit to the second terminal) leads to step 1510, where the reception is acknowledged to the first terrninal. Receiving nothing leads to termination of procedure. From the downloading step 1509 the terminal may return to step 1510 without furher activity if it finds at step 1511 that it does not need to receive any further signals from the first teπninal, or through steps 1511 and 1512 if first it is * found at step 1511 that a ready signal is needed from the first terrninal and subsequently such a signal is received at step 1512. In any case after step 1510 there comes step 1513 where a "ready" signal is given to the user, after which playing may begin. A positive finding at step 1505 causes a transition to step 1514 where the terminal checks, whether an acknowledgement needs to be transmitted to the first terminal before downloading the software or the missing part thereof from the game server. If yes, transmission is accompUshed at step 1515 before going into step 1509; if not, step 1515 is omitted. A, negative finding at step 1502 means that only a general proposal to play was received as in Fig. 7. In that case the proposal is conveyed to the user at step 1520! A positive response from the user at step 1521 identifies either a game or a group of games to be proposed to the first terrninal at step 1522. If the first terminal asks for a software or the missing part thereof at step 1523, these are transmitted at step 1524. After the first terrninal has acknowledged the transmission at step 1525, a "ready" signal is given to the user at step 1513, after which playing may begin. The procedures iUustrated in Figs. 14 and 15 are easUy understood also under the "content" assumption when one takes notice of the differences explained previously at the passage of the description where we described the compatibiUty of Figs. 1 to 7 with said alternative assumption. Fig. 16a iUustrates schematicaUy certain parts of a terminal arrangement according to an embodiment of the invention. In Fig. 16a the terrninal arrangement consists simply of a terrninal of a ceUular radio system. An antenna 1601 is coupled through a duplexing block 1602 to a receiver block 1603 and a transmitter block 1604. The. sink of payload data from the receiver block 1603 and the source of payload data to the transmitter block 1604 is a baseband block 1605 which in turn is coupled to a user interface block 1606 for communicating with a human or electronic user. A control block 1607 receives control information from the receiver block 1603 and transmits control information through the transmitter block 1604. AdditionaUy the control block 1607 controls the operation of the blocks 1603, 1604 and 1605, and exchanges information locaUy through the user interface block 1606 and a local data interface block 1608. In accordance with the invention, the control block 1607 comprises the agent and field portions of the recreational software as was described in association with Fig. 13, or is at least programmed to execute at least one of the methods illustrated in Figs. 1 to 7, 14 or 15 in order to get the agent and field portions of the recreational software stored. Fig. 16b illustrates a terminal arrangement according to an embodiment of the invention where a terminal of a cellular radio system is locaUy coupled to a peripheral device 1620 which comprises its own control block 1621 and user interface 1622. In this case the the agent and field portions of the recreational software as was described in association with Fig. 13 are stored into the peripheral device 1620, and the control block 1607 of the ceUular radio terrninal is programmed to execute at least one of the methods iUustrated in Figs. 1 to 7, 14 or 15 in order to get the agent and field portions of the recreational software stored. In the foregoing we have described mainly the appUcation of the invention in a situation where exactly two users want to take part in a shared session of using a certain recreational appUcation. The descriptions given above may be generaUsed into multi-user sessions with more the two users. The terminal of each user must take on the role of either the first or the second terminal as described above. In one typical multiuser embodiment of the invention the terrninal of a certain one user acts as the first terrninal, and the terminals of aU other users act as second terminals. In this case the session begins when aU those second terminals the users of which want to take part in the session have transmitted their acknowledgement messages to the first terrninal. Another possibihty is that the terminals chaUenge each other into the session in a chain so that of the first two terminals the terrninal which first acted as a second terrninal takes on the role of a first terminal in order to chaUenge a further terminal an so on, so that the acknowledgement that precedes the "ready" signals to users comes backwards in the chain of terminals and finaUy reaches the terrninal which was the original first, initiating terminal. The exemplary embodiments described above should not be construed to place Umitations to the scope of protection which is defined in the appended claims. The word "comprise" is in this patent appUcation meant to be an open limitation in the sense that stating that "A comprises B" does not exclude A from comprising also other parts than B.

Claims: Claims 1. A method for distributing a recreational appUcation within a group of teπninal arrangements (1101, 1102), where the group comprises at least two terrninal arrangements and each terminal arrangement comprises a terrninal of a ceUular radio system, characterised in that the method comprises the steps of: - transmitting from a first terrninal aπangement to a second terminal arrangement a proposal (104, 204, 704) for setting up a session of utiUsing a recreational appUcation and - only after the second termmal arrangement has received said proposal, using (107, 108, 207, 208, 308, 408, 409, 508, 509, 510, 607, 608, 609, 610, 611, 707, 710, 711) the communicational capabiUties of at least one of the first and second terrninal arrangements to estabUsh a state where both the first terminal arrangement and the second terminal arrangement possess enough software components (1103, 1104, 1105, 1106, 1205) for setting up a common, shared session of utiUsing said recreational appUcation. 2. A method according to claim 1, characterised in that it comprises the steps of: a) ttansmitting from the first terminal aπangement to the second terrninal arrangement a proposal (104) identifying a number of proposed recreational applications, b) ttansntitting from the second terrninal arrangement to the first terrninal arrangement a request (107) for obtaining a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations and c) as a response to receiving said request (107) in said first terminal arrangement, transmitting said software component (108) from the first terminal arrangement to the second terminal arrangement. 3. A method according to claim 2, characterised in that it comprises, between steps a) and b), the step of presenting (105) said number of proposed recreational appUcations to the user of the second terminal arrangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (106) concerning one of said number of proposed recreational appUcations. 4. A method according to claim 2, characterised in that step c) comprises the substep of transmitting said software component (108) from the first terminal arrangement to the second terminal arrangement through a local communication link. 5. A method according to claim 2, characterised in that step c) comprises the substep of transmitting said software component (108) from the first terrninal arrangement to the second terminal arrangement through the ceUular radio system. 6. A method according to claim 2, characterised in that it comprises, after step c), the steps of d) transmitting from the second terrninal arrangement to the first terminal arrangement an acknowledgement (109) indicating the reception of said software component and e) after step d), indicating (110, 111) to the users of the first and second terrninal arrangements the readiness of utiUsing the recreational appUcation. 7. A method according to claim 1, characterised in that it comprises the steps of: a) ttansmitting from the first terrninal arrangement to the second terminal arrangement a proposal (204) identifying a number of proposed recreational appUcations, b) ttansntitting from the second terminal arrangement to a recreational appUcation server a request (207) for obtaining a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations and c) as a response to receiving said request in said recreational appUcation server, ttansrmtting said software component (208) from said recreational application server to the second terminal arrangement. 8. A method according to claim 7, characterised in that it comprises, between steps a) and b), the step of presenting (105) said number of proposed recreational appUcations to the user of the second terrninal arrangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (106) concerning one of said number of proposed recreational appUcations. 9. A method according to claim 7, characterised in that it comprises, after step c), the steps of d) ttansntitting from the second terminal arrangement to the first terrninal arrangement an acknowledgement (109) indicating the reception of said software component and e) after step d), indicating (110, 111) to the users of the first and second terminal arrangements the readiness of utiUsing the recreational appUcation. 10. A method according to claim 1, characterised in that it comprises the, steps of: a) ttansmitting from the first terminal aπangement to the second terrninal arrangement a proposal (104) identifying a number of proposed recreational appUcations, b) ttansmitting from the second terminal arrangement to the first terminal arrangement a request (107) for obtaining a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations, c) as a response to receiving said request (107) in said first terminal arrangement ttansmitting a network address (308) of a recreational application server from the first terminal arrangement to the second terminal arrangement, d) ttansntitting from the second terminal arrangement to said recreational appUcation server a request (207) for obtaining a software component necessary for setting up a common, shared session of utilising one of said proposed recreational appUcations and e) as a response to receiving said request in said recreational appUcation server, ttansnύtting said software component (208) from said recreational application server to the second terrninal arrangement. 11. A method according to claim 10, characterised in that it comprises, between steps a) and b), the step of presenting (105) said number of proposed recreational appUcations to the user of the second terminal aπangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (106) concerning one of said number of proposed recreational appUcations. 12. A method according to claim 10, characterised in that it comprises, after step e), the steps of f) ttansmitting from the second terminal arrangement to the first terrninal arrangement an acknowledgement (109) indicating the reception of said software component and g) after step f), indicating (110, 111) to the users of the first and second terrninal aπangements the readiness of utiUsing the recreational appUcation. 13. A method according to claim 1, characterised in that it comprises the steps of: a) transmitting from the first terminal arrangement to the second terrninal aπangement a proposal (104) identifying a number of proposed recreational appUcations, j b) transmitting from the second terminal arrangement to the first terminal arrangement a request (107) for obtaining a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations, c) as a response to receiving said request (107) in said first terrninal arrangement, ttansmitting from the first terrninal arrangement to a recreational appUcation server a request (408) for downloading into the second teπninal aπangement a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations and d) as a response to receiving said request (408) in said recreational application server, ttansr ' tting said software component (409) from said recreational appUcation server to the second teπninal aπangement. 14. A method according to claim 13, characterised in that it comprises, between steps a) and b), the step of presenting (105) said number of proposed recreational appUcations to the user of the second terminal arrangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (106) concerning one of said number of proposed recreational appUcations. 15. A method according to claim 13, characterised in that it comprises, after step d), the steps of e) transmitting from the second terminal arrangement to the first terrninal aπangement an acknowledgement (109) indicating the reception of said software component and f) after step e), indicating (110, 111) to the users of the first and second teπninal arrangements the readiness of utilising the recreational application. 16. A method according to claim 1, characterised in that it comprises the steps of: a) ttansmitting from the first terrninal arrangement to the second terrninal arrangement a proposal (104) identifying a number of proposed recreational appUcations, b) ttansntitting from the second terrninal arrangement to the first terminal arrangement a request (107) for obtaining a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations, c) as a response to receiving said request (107) in said first terrninal arrangement, transmitting from the first terminal arrangement to a recreational appUcation server a request (508) for downloading into the first terrninal arrangement a software component necessary for setting up a common, shared session of utiUsing said one of said proposed recreational appUcations, e) as a response to receiving said request (508) in said recreational appUcation server, ttansmitting said software component (509) from said recreational appUcation server to the first terminal arrangement and f) as a response to receiving said software component (509), ttansmitting from the first terminal arrangement to the second terrninal arrangement a software component (510) necessary for setting up a common, shared session of utiUsing said one of said proposed recreational appUcations. 17. A method according to claim 16, characterised in that it comprises, between steps a) and b), the step of presenting (105) said number of proposed recreational appUcations to the user of the second terrninal arrangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (106) concerning one of said number of proposed recreational appUcations. 18. A method according to claim 16, characterised in that it comprises, after step f), the steps of g) transmitting from the second terrninal aπangement to the first terminal arrangement an acknowledgement (109) indicating the reception of said software component and h) after step g), indicating (110, 111) to the users of the first and second terminal arrangements the readiness of utilising the recreational application. 19. A method according to claim 1, characterised in that it comprises the steps of: a) transmitting from the first teπninal arrangement to the second terminal arrangement a proposal (204) identifying a number of proposed recreational appUcations, b) ttansrnitting from the second terminal arrangement to the first terrninal arrangement a first acknowledgement (607) mdicating agreement to set up a common, shared session of utiUsing one of said proposed recreational appUcations, c) ttansmitting from the first terrninal arrangement to a recreational appUcation server a first request (609) for obtaining a software component necessary for setting up a common, shared session of utilising said one of said proposed recreational appUcations, d) ttansmitting from the second terminal arrangement to a recreational appUcation server a second request (608) for obtaining a software component necessary for setting up a common, shared session of utiUsing said one of said proposed recreational appUcations, e) as a response to receiving said first request (609) in said recreational appUcation server, ttansmitting the requested software component (611) from said recreational appUcation server to the first terrninal aπangement, f) as a response to receiving said second request (608) in said recreational appUcation server, ttansntitting the requested software component (610) from said recreational appUcation server to the second terminal arrangement and g) exchanging a pair of messages (612, 109) between the first and second terminal arrangements indicating the readiness of utilising the recreational appUcation. 20. A method according to claim 19, characterised in that it comprises, between steps a) and b), the step of presenting (105) said number of proposed recreational appUcations to the user of the second terrninal arrangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (106) concerning one of said number of proposed recreational appUcations. 21. A method according to claim 19, characterised in that it comprises, after step g), the step of indicating (110, 111) to the users of the first and second terminal aπangements the readiness of utiUsing the recreational application. 22. A method according to claim 1, characterised in that it comprises the steps of: a) ttansntitting from the first terrninal arrangement to the second terrninal arrangement a proposal (704) for setting up a common, shared session of utilising a recreational appUcation, b) ttansrnitring from the second terrninal arrangement to the first terminal arrangement a proposal (707) identifying a number of proposed recreational appUcations, c) ttansmitting from the first terminal arrangement to the second terrninal aπangement a request (710) for obtaining a software component necessary for setting up a common, shared session of utiUsing one of said proposed recreational appUcations and d) as a response to receiving said request (710) in said second terrninal aπangement ttansmitting said software component (711) from the second terminal arrangement to the first terrninal aπangement. 23. A method according to claim 22, characterised in that it comprises, between steps b) and c), the step of presenting (708) said number of proposed recreational appUcations to the user of the first terrninal arrangement, so that step b) is only executed as a response to receiving from said user an indication of acceptance (709) concerning one of said number of proposed recreational applications. 24. A method according to claim 22, characterised in that it comprises, after step d), the step of indicating (110, 111) to the users of the first and second terrninal aπangements the readiness of utiUsing the recreational application. 25. A method according to claim 1, characterised in that the step of using the communicational capabihties of at least one of the first and second terrninal arrangements to estabhsh a state where both the first terrninal aπangement and the second terrninal aπangement possess enough software components for setting up a common, shared session of utiUsing said recreational appUcation comprises the substep of - ttansntitting from the first terminal arrangement (1101) to the second terrninal arrangement (1102) a complete copy (1105, 1106) of those software components (1103, 1104) which the first terminal uses for setting up a common, shared session of utilising said recreational appUcation. 26. A method according to claim 1, characterised in that the step of using the communicational capabilities of at least one of the first and second terrninal aπangements to estabhsh a state where both the first terminal arrangement and the second terrninal aπangement possess enough software components for setting up a common, shared session of utiUsing said recreational application comprises the substep of - ttansmitting from the first terrninal arrangement (1101) to the second terminal arrangement (1102) a Umited copy (1205, 1106) of those software components (1103, 1104) which the first terminal uses for setting up a common, shared session of utiUsing said recreational appUcation, said Umited copy being only usable for setting up a common, shared session of utiUsing said recreational appUcation together with the particular first teπninal arrangement in question. 27. A method according to claim 1, characterised in that the step of using the communicational capabihties of at least one of the first and second terrninal arrangements to estabhsh a state where both the first terminal aπangement and the second teπninal arrangement possess enough software components for setting up a common, shared session of utiUsing said recreational appUcation comprises the substep of - ttansmitting from the first terminal arrangement (1101) to the second terrninal arrangement (1102) a more advanced copy (1205, 1106) of those software- components (1103, 1104) which the first terrninal uses for setting up a common, shared session of utilising said recreational application. 28. A method according to claim 1, characterised in that the step of using the communicational capabihties of at least one of the first and second terminal arrangements to estabhsh a state where both the first terminal aπangement and the second terrninal arrangement possess enough software components for setting up a common, shared session of utiUsing said recreational appUcation comprises the substeps of: - transmitting from the first terminal aπangement to the second terrninal aπangement an authenticated offer (801) for setting up a common, shared session of utiUsing said recreational appUcation, - forwarding said authenticated offer (802) from the second terrninal aπangement to a recreational application server, and - transmitting from said recreational application server to the second terminal aπangement a limited copy (804) of software components needed for setting up a common, shared session of utiUsing said recreational application, said limited copy being only usable for setting up a common, shared session of utilising said recreational application together with the particular first terminal arrangement in question. 29. A method according to claim 28, characterised in that it comprises the step of imposing a charge (803) to the user of the first terminal arrangement for setting up a common, shared session of utiUsing said recreational appUcation together with the particular second terrninal arrangement in question. 30. A method according to claim 1, characterised in that the step of using the communicational capabihties of at least one of the first and second terrninal arrangements to estabhsh a state where both the first terminal aπangement and the second terrninal arrangement possess enough software components for setting up a common, shared session of utiUsing said recreational appUcation comprises the substeps of: - ttansmitting from the second terrninal aπangement to the first terrninal arrangement an authenticated offer (901) for setting up a common, shared session of utiUsing said recreational appUcation, - forwarding said authenticated offer (902) from the first terrninal arrangement to a recreational application server, and - ttansmitting from said recreational application server to the second terrninal arrangement a copy of software components (904) needed for setting up a common, shared session of utiUsing said recreational appUcation. 31. A method according to claim 30, characterised in that it comprises the step of imposing a charge (903) to the user of the second terrninal arrangement for setting up a common, shared session of utiUsing said recreational application together with the particular first terminal arrangement in question. 32. A method according to claim 1, , characterised in that the step of using the communicational capabUities of at least one of the first and second terminal aπangements to estabhsh a state where both the first terminal aπangement and the second terrninal arrangement possess enough software components for setting up a common, shared session of utiUsing said recreational application comprises the substeps of: - ttansmitting from the second teπninal aπangement to the first terminal arrangement an authenticated offer (1001) for setting up a common, shared session of utiUsing said recreational appUcation, - forwarding said authenticated offer (1002) from the first terrninal arrangement to a recreational application server together with another authenticated offer from the first terminal aπangement for setting up a common, shared session of utiUsing said recreational appUcation, and - ttansrmtting from said recreational appUcation server to the terrninal aπangements copies (1004) of software components needed for setting up a common, shared session of utilising said recreational appUcation. 33. A method according to claim 32, characterised in that it comprises the step of imposing charges (1003) both to the user of the second terrninal arrangement for setting up a common, shared session of utiUsing said recreational appUcation together with the particular first terminal arrangement in question and to the user of the first terrninal aπangement for setting up a common, shared session of utiUsing said recreational appUcation together with the particular second terminal arrangement in question. 34. A method according to claim 1, characterised in that the step of using the communicational capabihties of at least one of the first and second terminal arrangements to estabhsh a state where both the first terrninal arrangement and the second terrninal arrangement possess enough software components for setting up a common, shared session of utiUsing said recreational appUcation comprises the substeps of: - exchanging information between the first and second terrninal arrangements through a short-distance communications connection during said common, shared session of utilising said recreational application, and - after the exchanging of information between the first and second terminal arrangements through said short-distance communications connection becomes impossible, deeming the common, shared session of utiUsing said recreational appUcation to be ended. 35. A method according to claim 34, characterised in that it additionaUy comprises the substep of refraining from other exchange of information between the first and second terminal arrangements through said short-distance communications connection during said common, shared session than such information that is needed to ensure that the short-distance communications connection is stiU active. 36. A terrninal aπangement comprising a terrninal of a cellular radio system, characterised in that it comprises - means for exchanging proposals (104, 204, 704) for setting up sessions of utiUsing a recreational appUcation with other terminal arrangements and - means for responding to a situation where such proposals have been exchanged by using its communicational capabihties (107, 108, 207, 208, 308, 408, 409, 508, 509, 510, 607, 608, 609, 610, 611, 707, 710, 711) to estabUsh a state where both it and another terrninal aπangement possess enough software components for setting up a common, shared session of utiUsing said recreational appUcation.

Inventors: HAERMAE ESA, HAERMAE, ESA
Applicants: HAERMAE ESA, NOKIA CORP, HAERMAE, ESA, NOKIA CORPORATION
Application year: 2001
Main classification: G06F19
IPC codes: A63F13, H04L29, H04M1