MANAGEMENT OF SIMULTANEOUS USERS IN AN APPARATUS OF A TELECOMMUNICATIONS NETWORK

Abstract: The invention relates to a method for management of simultaneous users (LM, RU1, RU2) in a telecommunications apparatus (N). Users communicating with the apparatus send the apparatus commands, at least some of which are write commands, to change the settings of the apparatus, several users simultaneously communicating with the apparatus are prevented from changing at least the same apparatus settings. To allow an apparatus connected to existing networks to be protected in a simple manner against simultaneous changes in its settings, (a) at least some of the commands sent by the users to the apparatus include an identifier (UNO) which identifies the sender of the command to the apparatus, (b) the apparatus allocates at least some of the identifiers as a response to a request made by the user, and (c) the apparatus keeps a record of the user rights relating to the identifiers, and determines on the basis of the identifier it has received whether the command relating to the identifier is to be performed.

Description: Management of simultaneous users in an apparatus of a telecommunications network Field of the Invention The invention relates to a method according to the preamble of appended claim 1 for management of simultaneous users in a node apparatus of a tele¬ communications network. The term user refers herein to systems and/or persons operating the apparatus. The user may thus be, for example, a network management system or part of a local management system. The term user thus does not necessarily refer to a person operating the apparatus, although the user may also be a human operator. Background of the Invention A telecommunications system typically comprises a plurality of nodes which are connected to each other through data links. A node consists of a telecommunica- tions apparatus, e.g. a cross connection ' apparatus, which typically comprises a plurality of card units for implementing one or more telecommunication functions, such as cross connection. A large number of different settings and parameters are stored in such a telecommunications apparatus; their values are dependent on how the apparatus controls or relays traffic in the network, and how the apparatus is supposed to operate in case of faults, alarms or emergency services, or under similar special circumstances. These set values/parameters are stored in the apparatus when it is put to use, and it must be possible to change them in a flexible manner during the use of the apparatus. The changes are made either by means of the network management system (through the network) or locally, by the operator at the node apparatus. The object of the method of the present invention is to ensure that no more than one user can simultaneously change the settings of a node apparatus or the like. At present, simultaneous users cannot be monitored efficiently at a node apparatus of a telecommunications network to ensure that only one user at a time can change certain apparatus settings. In a typical implementation, the apparatus identifies users on the basis of the interface through which they are connected to the apparatus. There may be, for example, two interfaces: one for a local user and the other for remote users (e.g. network management system) . A local interface usually has a higher priority; thus, when a local user changes certain settings, the remote users cannot change the settings (at least the same ones) . The drawback of such a mechanism is primarily that it is impossible to distinguish between the remote users. In computer environment, an implementation is known where user identifiers and/or passwords are defined for all users to allow them to log in the system. The primary purpose of these systems is to prevent the access of unauthorized persons to the system as users. In principle, it is also conceivable to use such a mechanism in a node apparatus of a tele- communications network for managing simultaneous users. In this case it should, however, be possible to create individual identifiers/passwords for all users in the network and to update them when the situation changes. This is extremely difficult in practice, particularly since the network may already comprise a large number of apparatuses from several different manufacturers. If only group-specific identifiers are created, it is impossible to distinguish between users within a group. Brief Description of the Invention The object of the present invention is to provide a new type of solution for management of simultaneous users in a node apparatus of a telecommunications network in order to obviate the above-mentioned drawbacks. This object is achieved with a ^ hod of the invention, which is characterized by what is disclosed in the characterizing part of appended claim 1. The idea of the invention is to provide a command given to the apparatus with an identifier to allow the apparatus to identify the user and the rights of the user, and thereby to decide whether the command containing the identifier is to be carried out. Part of the idea is that the apparatus itself allocates at least some of the identifiers to the users in response to requests made by the users. The solution of the invention allows a node apparatus of a network to be provided with management of simultaneous users in a simple manner. In addition, it is simple to add a node apparatus provided with the management property of the invention to an existing network. These advantages can be achieved, because in the commonly employed hierarchical command structure, an additional identifier forms only an additional grade, wherefore compatibility with the previous implementations is maintained. A user does not need a predetermined user identifier, and the method does not prevent the user from making changes, if necessary, irrespective of the other users. Nor is it necessary to change the network management system if not desired. Brief Description of the Figures In the following, the invention and the preferred embodiments will be described in greater detail with reference to the examples according to the accompanying drawings, in which Figure 1 is a general view of a node apparatus of a telecommunications network, Figure 2 illustrates the format of a command to be sent to a node apparatus, Figure 3 illustrates the elements by which the method of the invention is implemented in a node apparatus according to Figure 1, Figures 4 to 6 are flow charts illustrating the execution of commands by elements according to Figure 3, and Figure 7 is a flow chart illustrating the checking of users, conducted by the apparatus from time to time. Detailed Description of the Invention Figure 1 is a general view of a node apparatus N of a telecommunications network in which the method of the invention is applied. The node comprises (a) a plurality of parallel interface units IU1...IUn, through which the node is connected to the network, and (b) a control unit CU common to several interface units. The interface may be, for example, a conventional 2 Mbit/s PCM interface according to ITU-T (former CCITT) recommendation G.703, as shown in the figure. Certain bits in a suitable timeslot of a PCM signal are allocated to command messages given by the users, and the messages are transmitted on this selected channel "a piece at a time". The input of each interface unit comprises a multiplexing/demultiplexing block 11, connected to an internal bus IBUS of the node. In addition, each interface unit comprises a control block 12, which is constantly connected to the control block 13 of the entire node through a control bus CBUS. The control unit CU comprises an AND gate 14 for switching data from the control block 13 of the node or from a local management device LM to the internal bus of the node. The local management system is typically connected through a serial traffic connection, such as V.ll, to a serial port SP, which in turn is connected to the AND gate 14. There may be several users (LM, RU1...Run) , and they may all be connected to the node apparatus from different directions. All commands from different directions are transferred through the internal bus IBUS of the node to the node control block 13, which processes them. The control block 13 of the node, in turn, is connected to the control blocks 12 of the interface units through the control bus CBUS. The management of simultaneous users according to the invention is implemented in the control block 13 of the node. In the example which will be described below, it is assumed that write rights are granted to only one user at a time. In principle, it would also be possible to grant several simultaneous write rights, provided that the rights do not relate to the same settings (i.e. the rights could be record-specific) . In practice such a solution is, however, too complicated. In the example, the commands (messages) to be sent to the apparatus are divided into three main categories: read, set and management commands. Read commands are commands for only reading the settings of the apparatus. Set commands (i.e. write commands) are commands for changing the settings of the apparatus. Management commands are commands pertaining to user management (the term UNO command will be used below to refer to these commands) . The management commands are further divided into several different types. According to the invention, each user transmits his own user number (identifier) at least in the commands that are not read commands. It is not necessary to protect read commands by user numbers. In the following, the user number will be referred to as UNO. All commands that are used have a similar basic format, e.g. as shown in Figure 2. At first the command comprises a constant part A with certain predetermined constant contents for each command type; the type of the command is thus determined by means of this part. Thereafter the command comprises a UNO part according to the i * "- ττΩ ntion (indicated by B) , containing the user number O) . The user number is followed by an identnication field C, containing the identifier of the apparatus setting to be changed. The abbreviation ID will be used below to refer to this identifier. The identification field can be divided into two parts in such a manner that, in addition to containing the identifier, it also indicates from which value onwards the settings will change. This optional part is indicated by OFFSET. The last part of the write command is a data field D, containing the new value of the setting indicated by the identifier. The format illustrated in the figure is a commonly used command format to which the UNO part B has been added to inform the apparatus about the rights of the user in question. The users of a node apparatus are preferably divided into two different categories, in which the UNOs are allocated in two different ways. The first user category is formed by non- registered users (the term refers to the fact that the apparatus does not keep a record of these users) , who typically perform single tasks from the point of view of the apparatus and want to do this without any interference from the other users. This user category may use, for example, two different UNOs: e.g. UNO = 1 for writing without checking any rights or other users, and UNO = 255 for writing only if there is no registered user for the apparatus at that moment. Non-registered users are typically for instance network management systems, which are thus given an opportunity to perform writing operations freely. The second user category is formed by registered users, who must at first register themselves at the apparatus before they can perform any writing operations. A record is constantly kept of the users registered at the apparatus at each moment. When a user wishes to register at the apparatus, he sends a registration request containing a certain predetermined UNO value, e.g. UNO = 0. The registration request is thus preferably in accordance with the command format shown in Figure 2, and the apparatus identifies the command as a registration request on the basis of the UNO value included in the message. (A registration request belongs to management messages.) With the same UNO value, a user may also request read-only rights. As stated above, a user does not need a UNO for reading, but if the user wishes to inform others of his ongoing session with the apparatus, or if the user wishes his session to be stored in the log of the apparatus, he may request read-only rights from the apparatus . Fields B...D of a registration request command thus comprise at least the following information: - field B: UNO=0, - field C: ID=X, - field D: R/W, where X represents a setting, R indicates that read-only rights are requested, and W indicates that write rights are requested (R and W are alternatives) . In addition, further information, such as user name, time and date, are preferably sent in data field D (for the log of the apparatus) . The node apparatus replies to the registration request with a new UNO value, which the user must use after the registration. At the same time the user also gains his rights. Fields B... D of the reply message thus contain at least the following information: _d B: UNO=Y (byte) , ..eld C: ID=X, field D: R/W, where Y is a new UNO value, R indicates that the user has gained read-only rights, and W indicates that the user has gained write rights. In addition, further information can be sent to a new user in data field D on any other simultaneous users: e.g. name, rights (R/W) , and information on whether the user is a local or remote user (i.e. through which interface the user has logged in the apparatus) . [Non-registered users have fixed names given by the apparatus and linked with the UNO values used by them. ] The registration operation described above starts a user session. It should be noted that the UNO mechanism is intended for management of only simultan¬ eous write events. In addition to this, the apparatus can be provided with one or more (e.g. user-specific) passwords to allow only the desired users to change the settings. [The term simultaneous users refers to users having simultaneous (active) sessions with the apparatus. ] According to a preferred embodiment of the invention, a registered user must send specific alive messages during a session to inform the apparatus that a user with a certain UNO value still has an active session. The alive messages fall within management commands. If the user has already registered but has no write rights, he may request them in an alive message. On the other hand, if a user has write rights but does not need them any more, he may renounce them by means of an alive message. Having renounced his write rights, the user still remains a registered user obliged to send alive messages. If the user really needs write rights and does not want to use forced write, he can make a "forced request" for write rights in an alive message. This "forced request" cancels the write rights of another user and grants them to the user who made the "forced request". This embodiment can, however, be modified in such a way that the write rights of a user (such as a local user) with a higher priority cannot be cancelled, but the user who has made the "forced request" must in such a case wait for the local user to log out. Fields B...D of an alive message thus contain at least the following information: - field B: UNO = Z (byte), - field C: ID = XX, - field D: R/W/F, where Z is the UNO value of the user in question, XX is the identifier of the setting in question, and R, W and F indicate that the user needs read-only rights (R) , write rights (W) , or that the user is making the above-mentioned "forced request" (F) . The reply message sent by the apparatus contains the user rights. The rights granted may be different from what has been requested in the alive message, since e.g. a local user may override the other users, and someone may make a "forced request", in which case he overrides - if not the local user - at least the other users. The user must therefore always check the rights he has gained in the response. In the reply message, the apparatus also indicates the settings that the other users have changed since the preceding alive message. Data field D of the reply message to an alive message thus contains for instance the following information: - granted rights: R/W, - number of changed settings, and - identifiers of changed settings. The reply message may further contain information on the other simultaneous users [e.g. names, rights (R/W) and locations (local user/remote user) of the users] . It should be noted that by sending alive messages more frequently, the user may receive information on the changed settings more rapidly. It is not necessary to use alive messages; it is also possible to use e.g. timeout counted from the previous session as an indicator of an active session. However, this would mean losing the possibility of exchanging information by alive messages. The registered users have a certain UNO range, e.g. UNO = 21...60, for their use. The (one and the same) UNO which falls within this range and which is allocated by the apparatus during the registration must be used in each write command to allow the apparatus to check the user rights. If the user sends a write command to the apparatus although he has no write rights, the apparatus indicates in the reply message the name of the user who has the write rights at that moment. Alternatively, it is possible to send only an error message. A registered user with no write rights may also need to change the settings of the apparatus irrespective of the other users. According to a preferred embodiment of the invention, a registered user may do this by adding a fixed number, e.g. 100, to his UNO. Thus, for example, a user with the UNO 29 may perform a forced write with the UNO 129. When the user has performed all the desired operations, he logs out. If the user does not use the mechanism provided for this purpose but merely breaks the connection, the apparatus logs the user out after a certain timeout (e.g. 10 minutes) . If the apparatus has not received alive messages from the user during the timeout (e.g. during the last 10 minutes), it logs the user out, whereby the user must register again. The timeout counters are not incremented for any user when someone is reading the settings. A normal write command is also interpreted as an alive message. If the user sends a great deal of setting data, it is therefore unnecessary to transmit alive message in between. Nor are the timeout counters of other users incremented then. Timeout counting is therefore used only when there is no traffic between the apparatus and the users. When a user with write rights has logged out (or been logged out by the apparatus) , the apparatus may grant write rights to another user. The first-registered user sending alive messages provided with a request for write rights gains the write rights. The following table shows the allocation of UNOs 0...255 in accordance with the above. The second column (status) indicates whether the UNOs are in use; the meanings of the abbreviations used are as follows: U = in use, RM = reserved for management systems, RF = reserved for future use, RNU = reserved only for non- registered users. The fifth column indicates the typical (management) apparatus that controls the node apparatus using the UNOs in question. The meanings of the abbreviations used are as follows: DM = local management device for node apparatus, MS = network management system, NRU = non-registered users. The sixth column describes the checking conducted by the node apparatus. The meanings of the abbreviations used are as follows: A = check other users for granting proper rights to new user, B = no checking, C = check rights and that UNO is registered, D = check whether there are active users with write rights, E = check that there is a user whose UNO is the UNO in the command minus 100. UNO Status UNO al¬ Regis¬ Manage¬ Check¬ located tered ment ing by users device 0 U user no DM A 1 U user no MS B 2-20 RM user no MS B 21-60 U appar. yes DM C 61-80 U user no/yes DM B 81-120 RF - - - - 121-160 U user yes DM E calcu¬ lates 160-210 RF - - - - 211-230 U user no/yes DM D 231-254 RNU user no NRU D 255 U user no NRU D As appears from the table, some of the UNOs can be allocated only by the user and some of them only by the apparatus. There are many possibilities of forced writing: e.g. UNO = 1, UNO = 121...160, UNO = 2...20 and UNO = UNO = 61...80. The first alternative is, for example, for a network management system; the second alternative inform' the apparatus of the user in question if othe. are to be informed thereof. The other alternat; _e mainly provided for later use if expansion is ued. F- ' _ • 3 illustrates those elements in the control r .- 13 of the node by which the method of the invent" .s implemented. A message processing unit 31 recei " a message from the block (not shown) that phyε * .ally receives the message. The message processing uni * checks the address of the receiver, that the message is error-free (parity or check sum) , and the type of the message (i.e. whether the message is an inquiry, set or user management command) . On the basis of the message type, the message processing unit 31 transmits the message forward. If it is- an inquiry command, which does not require management of simultaneous users, the command is forwarded directly to a command processing unit 33, which fetches the necessary information either directly from a permanent memory 36 or from other blocks (indicated by reference numeral 37) of the node apparatus. In the case of a set command or a command (registration, alive message or logout) relating to user management (UNOs) , the command is forwarded to a UNO processing unit 32. The UNO processing unit 32 checks the rights from the set commands and, if they seem to be sufficient, the command is forwarded to the normal command processing unit 33, which performs the operation by means of the other blocks 37 and/or the permanent memory 36. When checking the rights, the UNO processing unit utilizes a user table 34 comprising the UNO, name and rights of each user. The users are identified by means of the UNO. In the case of a management, i.e. UNO, command (registration, alive message or logout) , the UNO processing unit executes the command itself by the use of a user table 34 and time stamp memories 35a...35c. The first time stamp memory 35a stores the time when the user information was last changed, i.e. the last time that a change took place in the data of the user table (a user has logged in or out, the user rights have changed, etc.) . The second time stamp memory 35b stores, for each setting, the time when the setting was last changed. The third time stamp memory 35c stores for each registered user (i.e. UNO) the time when the user last contacted the apparatus by a command relating to user management (the stamp of the latest registration or alive message) . The elements shown in Figure 3 are located in the control block 13 of the node. The processing of some commands requires, however, a connection to the control block of one or more interface units; thus one or more of the subsystems 37 in the figure may be the control block of an interface unit or a block that takes care of the communication towards an interface unit. In the following, the execution of commands will be described in greater detail with reference to Figures 4 to 7. At the beginning (step 1000), a message is received: the address of the receiver has been checked (i.e. the message is coming to this node), and the message is error-free (the check sum is in order) . In the following step (1010), the type of the message is checked. In the case of an inquiry message, the message is forwarded in the usual manner to unit 33 for processing (step 1100), the reply is given normally (step 1110), and the process returns to the beginning to wait for a new message. In the case of a set message, step 1500 is proceeded to (Figure 5) . At first, the type of the UNO included in the set message is checked (step 1520) . If the UNO is not registered and it is not a forced write UNO, an error message is sent as a response (step 1530), and the process returns to the beginning to wait for new messages. If the UNO is registered, it is checked whether it has write rights (step 1590) . If it does not have write rights, an error message is sent as a response (step 1595) , and the name of the user having the write rights is also indicated. Thereafter the process returns to the beginning to wait for new messages. If the registered user has write rights or if a forced write UNO is in question, the process proceeds to perform the setting. It is at first checked (step 1540) whether the settings are acceptable (no overlaps/contradictions) . If an error is detected, an error message is sent to the user (step 1550), and the process returns to the beginning to wait for new messages. If the new settings are acceptable, they are made (step 1560) , a time stamp is given to the changes (step 1570), the change log is updated (step 1580), a confirmation is sent (step 1582) , and the process returns to the beginning to wait for new messages. If the message was a UNO message (registration, alive message or logout) from the beginning (step 1010, Figure 4), the process proceeds to check (step 1200) the type of the UNO message. In the case of a registration message, the process proceeds to check (step 1210) what kind of rights the user that is registering requests. If he requests write rights, it is checked (step 1211) whether the write rights have already been granted to another registered user. If this is the case, or if the user has requested only read rights, the user is allocated a free UNO and granted read rights (step 1213) . If the user has requested write rights and no one else has reserved them, a free UNO is allocated to him (step 1212) and at the same ^irne write rights are granted to this UNO. Thereaf ** in the same way as after the allocation of read _s and UNO in step 1213, the process proceeds to s j 1214, in which a new time stamp is given to the change of user data. Thereafter a time stamp is given to the allocated UNO (step 1217), and information on the allocated UNO and rights and information on the other users are sent to the user as a response to the registration (step 1219) . Thereafter the process proceeds to the beginning to wait for a new message. If the message in step 1200 is an alive message, the process proceeds to check the UNO included in the message (step 1230) . If the UNO is not registered, an error message is sent (step 1232), and the process proceeds to the beginning to wait for a new message. If the UNO is registered, it is checked in step 1235 what kind of rights the user is requesting in the alive message. If the user needs read rights, it is checked what kind of rights he has at that moment (step 1237) . If the rights have been read rights, a response is sent to the alive message (step 1270) . If the rights of the user have been write rights, they are changed to read rights in step 1239, whereby the write rights become free and can be granted to a user requesting them. Thereafter a new time stamp is given to the change of user information (step 1241), and a response is sent to the alive message (step 1270) . If it is observed in step 1235 that the user has requested write rights, it is checked (step 1243) what kind of rights the user has at that moment. If the user has already had write rights, no changes are needed, and thus a response can be sent to the alive message (step 1270) . If the user has had only read rights, it is checked in step 1245 whether the write rights are granted to another user. If this is the case, a response can be sent to the alive message (1270) . If the write rights have not been granted to anyone, the rights of the user are updated as write rights (step 1247), and a new time stamp is given to the change in the user information (step 1250) . Thereafter a response is sent to the alive message (step 1270) . If the user has requested forced write rights in step 1235, it is checked (step 1255) what rights he has at that moment. If he has already had write rights, a response is sent to the alive message (step 1270) . If the user has had only read rights, it is checked in step 1260 whether the write rights have been granted to someone else. If this is the case, the rights of this user must at first be updated as read rights (step 1262) . Thereafter, in the same way as if the write rights had not been granted to anyone else, the user rights are updated as write rights (step 1265) . Thereafter a new time stamp is given to the change in the user information in step 1267, and a response is sent to the alive message (step 1270) . If it is detected in step 1200 that the message is a logout message, the process proceeds to check the UNO in step 1400. If the UNO is not registered, an error message is sent as a response (step 1410), and the process proceeds to wait for a new message. If the UNO is registered, the process proceeds to step 1430 to store the logout data in the log, the UNO in question becomes free for use, and the information relating to it is removed from the user table. Thereafter a new time stamp is given to the change in the user information (step 1440) , a response is sent (step 1450) , and the process proceeds to wait for a new message. From step 1270, the process proceeds directly to step 1300 according to Figure 6. In this step, it is checked whether some setting has a newer time stamp than the user's own time stamp (the time stamp of the UNO) . If this is the case, there has been a change in the settings since the user's last contact, and the user will be informed of this change. In step 1310, the response message is provided with a list of the identifiers of the settings that have changed. There¬ after, and also if there have been no changes, the process proceeds to step 1320 to check whether the user information has changed since the last contact. The checking is conducted by comparing the time stamps of the UNO and the user information. If the information has changed, the list of users is added to the response message in step 1330. Thereafter, and also if there have been no changes, the process proceeds to step 1340 to update the user's own time stamp. After that, a response to the alive message is sent (step 1350) , and the process proceeds to wait for a new message. The current users must be checked from time to time. Figure 7 illustrates a "cleaning routine", by which users who have not sent alive message for a long time are logged out. When the process is started (step 2000), it proceeds to check (step 2100) whether there are registered users at the node apparatus. If there are none, the checking is unnecessary and over this time (step 2120) . If users are found, they are all checked. The checking can be started, for example, from the smallest UNO (step 2150) . If it is detected in the next step (2160) that the time of this UNO has expired, he is logged out (step 2170) by freeing his UNO for use, by removing the information relating to the UNO from the user table, and by entering the logout information in the log. Thereafter a new time stamp is given to the change in the user information in step 2180. After that, or even after step 2160 if the user's time has not expired, the process proceeds to step 2190 to check whether there are still such registered users at the apparatus that have not been checked. If there are none, the checking is over (step 2120) . If there are still such users, the process proceeds to the following user (step 2200) and continues the checking with this user as described above, starting from step 2160. This will be continued until all the users have been checked, and the process can, after step 2190, be finished (step 2120) . In the above, the invention has been described with reference to an example. However, it will be obvious that the invention is not limited to this example but can be modified within the inventive concept disclosed above and in the appended claims. The operation of the management system can thus be modified in many ways, of which some short examples will be given in the following. Renouncement of (write) rights does not necessarily have to be allowed during a session but only at the end of the session. Nor does gaining of (write) rights have to be allowed during a session, but a new registration attempt can be required. It is also possible to prevent deprivation of write rights from another user and to require the use of forced write, if necessary. Moreover, it is not necessary to inform a user of other users; alternatively, an error message can be sent to the user to inform him that the operation cannot be performed, since there are no rights. Logs are not necessary, either. The UNO groups can also be divided in different ways: an apparatus can, for example, have only one forced write group, and another group for users who register.

Claims: Claims 1. A method for management of simultaneous users (LM, RU1, RU2) in a telecommunications apparatus (N) , in which method - users communicating with the apparatus send the apparatus commands, at least some of which are write commands, to change the settings of the apparatus, several users communicating with the apparatus simultaneously are prevented from changing at least the same apparatus settings, c h a r a c t e r ¬ i z e d in that - at least some of the commands sent by the users to the apparatus include an identifier (UNO) which identifies the sender of the command to the apparatus, - the apparatus allocates at least some of the identifiers as a response to a request made by the user, and - the apparatus keeps a record of the user rights relating to the identifiers, and determines on the basis of the identifier it has received whether the command relating to the identifier is to be performed. 2. A method according to claim 1, c h a r ¬ a c t e r i z e d in that said request made by the user is identified on the basis of a predetermined value of the identifier (UNO) . 3. A method according to claim 1, c h a r ¬ a c t e r i z e d in that the apparatus divides the users into groups with different rights on the basis of the identifier values. 4. A method according to claim 3, c h a r ¬ a c t e r i z e d in that the apparatus divides the users into registered users, of which the apparatus keeps a record, and non-registered users, of which the apparatus does not keep a record. 5. A method according to claim 4, c h a r ¬ a c t e r i z e d in that when the identifier has a certain first value, the apparatus automatically grants write rights to the user that sent the value irrespect- ive of what kinds of rights the other simultaneous users have. 6. A method according to claim 4, c h a r ¬ a c t e r i z e d in that when the identifier has a certain second value, the apparatus grants write rights to the user that sent the value only if there are no other users at the apparatus at that moment. 7. A method according to claim 5, c h a r ¬ a c t e r i z e d in that the users that send said first identifier are classified as non-registered users. 8. A method according to claim 1, c h a r ¬ a c t e r i z e d in that when a user communicates with the apparatus, the user sends the apparatus specific alive messages comprising said user-specific identifier, whereby the apparatus knows that said user is still engaged in an active session. 9. A method according to claim 8, c h a r ¬ a c t e r i z e d in that in said alive messages the user may inform the apparatus that he wishes to change the write rights to read rights or vice versa. 10. A method according to claim 8, c h a r ¬ a c t e r i z e d in that in said alive messages the user may indicate that he wants write rights immediately irrespective of the rights of other users. 11. A method according to claim 6, c h a r - a c t e r i z e d in that a registered user with no write rights changes the settings by giving a write command in which a certain predetermined constant is added to the user's identifier value. 12. A method according to claim 1, c h a r - a c t e r i z e d in that write rights are granted to no more than one user at a time.

Inventors: KAINULAINEN JUKKA, KAINULAINEN, JUKKA
Applicants: KAINULAINEN JUKKA, NOKIA TELECOMMUNICATIONS OY, KAINULAINEN, JUKKA
Application year: 1996
Main classification: H04L12
IPC codes: H04L12, H04L29, H04Q3