Arrangement for improving availability of services in a communication system

The present invention relates to an arrangement for improving availability of services in a communications system, especially a telecommunications system, said system comprising distributed hardware and software components which interact in order to provide services to one or more users, and primarily the invention suggests that this improvement can be implemented by introducing in said system a user mobility support, for thereby enabling application availability including personal mobility. More specifically, the present invention suggests the introduction of user mobility support in distributed systems, and specifically by using agent technology which allows modification of internal implementation of agents without effecting the rest of the system.

FIELD OF THE INVENTION
 The present invention relates to an arrangement for improving availability
 of services in a communications system, especially a telecommunications
 system, said system comprising distributed hardware and software
 components which interact in order to provide services to one or more
 users.
 More specifically the invention concerns the user mobility support in
 distributed systems.
 Still more specifically the invention relates to an improved utilisation of
 agent technology.
 STATE OF THE ART
 Open distributed system is a category of distributed systems which are made
 up of components that may be obtained from a number of different sources,
 which together work as a single distributed system.
 The open distributed system provides an application interface to the
 distributed system and the application may run on any local operating
 system which is appropriate. The TINA architecture (Telecommunications
 Information Network Architecture) is a specialisation of open distributed
 system for telecommunications applications, and the present invention has
 primarily been developed in connection with inter alia such TINA
 architecture.
 The TINA-C architecture does address the personal (user) mobility issue,
 but does not use multiple agents for each user. Further, this architecture
 does not address the allowance of additional constellations, for example
 by letting one user using several terminals of same or different
 capabilities and the allowance of several users using the same terminal.
 Besides TINA, there is no architecture addressing user mobility on
 distributed systems.
 Consequently, there exists an increasing demand for user mobility,
 especially in connection with distributed systems, and hitherto no proper
 solution for distributed system has been suggested.
 OBJECTS OF THE INVENTION
 An object of the present invention is to suggest implementations of the
 improved availability of services in a communication system, especially
 the user mobility support in distributed systems.
 Another object of the present invention is to provide an arrangement
 allowing a user to move and still allow access to applications/services.
 Still another object of the present invention is to provide an improved
 availability by which one user can use several terminals of same or
 different capabilities and whereby several users can use the same
 terminal.
 Yet another object of the present invention is to provide an arrangement
 allowing the separation and protection of objects belonging to different
 users but running on the same terminal.
 A further object of the present invention is to suggest an improved use of
 multiple agents for each mobile user.
 SUMMARY OF THE INVENTION
 The above objects are achieved in an arrangement of the type as stated in
 the preamble, which primarily is characterised by introducing in said
 system a user mobility support, for thereby enabling application
 availability including personal mobility.
 More specifically the objects are achieved by introducing said user
 mobility support for distributed system.
 Further features and advantages of the present invention will appear from
 the following description taken in conjunction with the enclosed drawings,
 as well as from the enclosed patent claims.

DETAILED DESCRIPTION OF EMBODIMENTS
 Definition of User Mobility
 Let us now consider an example consisting of a telecom system.sub.N domain,
 a Terminal.sub.m domain and a User.sub.a domain. The User.sub.a domain
 consists of the User.sub.a object and an arbitrary computational object
 called CO1. Note that the object CO1 may or may not reside physically in
 the terminal.sub.m. In the case where the user is also a terminal or
 hardware device, CO1 may reside on the user itself and not on the
 Terminal.sub.m domain.
 To offer user mobility means to allow the whole user domain including COi,
 to move and change terminal and still be able to interact with an object
 CO2 residing in the telecom system.sub.N domain. By interactions it is
 meant both operations and stream flows. This is depicted in FIG. 1.
 Use of Agents
 Let us now introduce the agents necessary to enable interactions between
 domains. To represent the User.sub.a an agent called PD_UA.sub.a
 (ProviderDomain_User_Agent.sub.a) is introduced in the telecom
 system.sub.N domain. This agent assumes security functions such as
 identification, authentication, encryption, etc. and is also responsible
 for the functions supporting the mobility of the user. Another agent
 called TDm_UA.sub.a (TerminalDomain_User_Agent.sub.a) is introduced in the
 Terminal.sub.m domain to represent the User.sub.a and to assume the
 security functions of the Terminal.sub.m. If the User.sub.a is also using
 another terminal, namely Terminal.sub.n then a TDn_UA.sub.a is also
 defined for him on the Terminal.sub.n domain.
 We assume further that every terminal must have an owner and it is
 reasonable to define this owner as the default user of the terminal. A
 legal and operative terminal will always have a default user. This default
 user is permanently registered at the terminal. Definition of a default
 user for a terminal allows us to implement access control procedures which
 may restrict the usage of the terminal. Of course, the default user can
 also be registered at another terminal but the former registration is
 always valid and we have a multiple terminal registration case. There is
 therefore introduced in the Terminal.sub.m domain an agent TD_UA.sub.m
 representing the default user. Correspondingly, an agent PD_UA.sub.m is
 introduced in the telecom system.sub.N domain.
 In addition, we have objects such as SPAN representing the telecom
 system.sub.N domain in the Terminal.sub.m domain, TAm representing the
 Terminal.sub.m in the telecom system.sub.N domain, TAP representing a
 Terminal Access Point (port), NAP representing a Network Access Point.
 This is depicted in FIG. 2.
 Enabling Operations Between the Mobile User and the Telecom System
 Since operations can be initiated either by the User.sub.a or by objects in
 the telecom system.sub.N domain, we will consider the two cases
 separately.
 Operations Initiated by the Mobile User
 Suppose now that CO1 wants to invoke an operation OpY( ) on the object CO2.
 The invocation is not done directly.
 First, an operation Call(CO2.OpY( )) is issued to the object TD_UA.sub.a.
 This shows that there must be an association between CO2 and TD_UA.sub.a.
 The definition of this association will be discussed later. The
 TD_UA.sub.a will then invoke the operation Call(O2.OpY( )) on its
 peer-object PD_UA.sub.a. What TD_UA.sub.a needs in order to issue the
 operation request is the identifier of the object PD_UA.sub.a. Since both
 TD_UA.sub.a and PD_UA.sub.a represent the same user and there is only one
 unique PD_UA.sub.a, it is not a problem for TD_UA.sub.a to find the
 identifier of PD_UA.sub.a. Indeed, both of these two objects hold the
 identity of the user whom they represent.
 The operation Call(O2.OpY( )) on PD_UA.sub.a is converted to an operation
 Call(PD_UA.sub.a.Call(CO2.OpY( ))) of the SPAN. The SPAN issues a
 operation request Call(PD_UA.sub.a.Call(CO2.OpY( ))) on its peer-object
 TA.sub.m. This request is converted to the operation
 Call(TA.sub.m.Call(PD_UA.sub.a.Call(CO2.OpY( ))) on the TAP. The TAP will
 then forward this operation to the NAP to which it is currently connected
 with. The NAP will then issue an operation request
 Call(PD_UA.sub.a.Call(CO2.OpY( ))) to the TA.sub.m. The TA.sub.m will then
 invoke Call(CO2.OpY( )) of the PD_UA.sub.a. The PD_UA.sub.a will now call
 the operation OpY( ) of the object CO2. This concludes the conveyance of
 the operation OpY( ).
 The invocation of operations by objects in the user domain are seamless
 supported. The only information required by the user domain is that CO2 is
 residing on the fixed kTN (or located in the telecom system domain). No
 additional information is required. This is depicted in FIG. 3.
 Operations Initiated by an Object in the Telecom System Domain
 Reference is made to FIG. 4.
 Suppose now that an object CO2 in the telecom system domain wants to invoke
 the operation OpX( ) of Col. This operation will be converted to the
 operation Call(CO1.OpX( )) of the PD_UA.sub.a. In order to make the
 conversion possible the information that CO1 belongs to the User.sub.a
 domain and not to any other user domain, must be available in the telecom
 system domain.
 The PD_UA.sub.a will then invoke the operation Call(CO1.OpX( )) on the
 object TD_UA.sub.a. The first requirement is to find the identifier of
 TD_UA.sub.a. For the time being we just suppose that such information is
 available. We shall soon come back to how it can be found. The operation
 request is thereafter converted to the operation
 Call(TD_UA.sub.a.Call(CO1.OpX( )) on the TA.sub.m. To be able to do that,
 the PD_UA.sub.a must have the identifier of TA.sub.m or the identity of
 the terminal, namely Terminal.sub.m where the User.sub.a is located.
 The procedure to acquire the necessary information to reach the mobile user
 is commonly known as location tracking and is often supplemented by a
 location registration and deregistration procedure.
 Let us suppose for the time being that the PD_UA.sub.a somehow gets
 sufficient information and calls the correct Terminal_agent, namely
 TA.sub.m. From this step to step 6, all the operations are related to the
 handling of terminal mobility. The TA.sub.m will transfer the call to its
 peer-to-peer object SPAN by issuing the operation
 Call(SPAN.Call(TD_UA.sub.a.Call(CO1.OpX( )) to the NAP. The NAP transfers
 the call to the corresponding TAP. The TAP invokes then the operation
 Call(TD_UA.sub.a.Call(CO1.OpX( ))) of the SPAN. The SPAN calls the
 operation Call(CO1.OpX( )) of the TD_UA.sub.a. Finally, the TD_UA.sub.a
 invokes the operation OpX( ) of the object CO1. This concludes the convey
 of an operation initiated by an object in the telecom system domain.
 We have seen that the condition for the success of these procedures is the
 availability of information about the current terminal which the user is
 using or having access to. Formally speaking, the success of operations
 initiated by objects.residing on the telecom system domain depends on the
 definition of the association between the PD_UA.sub.a and a TA.
 When the User.sub.a is moving, the association between PD_UA.sub.a and TA
 is changing correlatively and may sometimes be undefined. The operations
 necessary to determine this association are parts of the procedures
 commonly referred to as user registration and deregistration.
 User Location Registration and Deregistration
 The user location registration and deregistration is the procedure to
 determine the association between the PD_UA and the TA. There are many
 methods that will be described in the following sections.
 The "On-the-Fly" Method
 The most straightforward method is the "on-the-fly" method. This method can
 also be called "lazy" since nothing is to be done unless it is necessary,
 e.g. a request is issued. When an object CO2 residing in the telecom
 system domain wants to call an operation of an object CO1 belonging to the
 User.sub.a domain, a request is issued to the PD_UA.sub.a object. The
 PD_UA.sub.a object will issue a broadcast to all the TAs asking them to
 search for the mobile user. The TAs can ask their counterpart, namely the
 SPA, to search for the corresponding TD_UA.sub.a. If none of the SPAs
 succeed, then the User.sub.a cannot be reached. Nothing else can be done.
 If one SPA succeeds in finding the mobile User.sub.a, it will answer to
 the corresponding TA which again informs the PD_UA.sub.a. Then the
 PD_UA.sub.a can send the operation invocation to the TA in question which
 forwards it to the corresponding SPA. The SPA forwards the operation to
 the TD_UA.sub.a object which delivers it to the object CO1. Interactions
 are then enabled.
 This method is acceptable for small and "less geographically distributed"
 system, i.e. system with small number of terminals and small number of
 users. It can be time consuming for larger or more geographically
 distributed systems. It may take a while to find the user or to know that
 it is not possible to find him. This method requires also much activity in
 the telecom system domain. If there are n terminals and m users in the
 system, then, in the worst case, m.times.n search procedures can be
 initiated simultaneously to find all the m users. This method is used in
 Internet when a search engine is used to identify the location of another
 web page or place of information.
 Method Based on the Predetermination of the Association Between the PD_UA
 and the TA
 There is another method based on the predetermination of the association
 between the PD_UA and the TA. The PD_UA knows in advance whether the
 mobile user has contact with any TA or not, and which specific TA instance
 it is associated with. In other words, the PD_UA object has the ability to
 store the association between the PD_UA and the TA.
 A simple implementation is to use a TA identifier which is a kind of
 "distribution transparent" pointer to a TA. By this method, much time will
 be saved at run-time when an operation request is issued.
 The TA identifier does not necessarily have to be incorporated inside the
 PD_UA but can be realized as a separate computational object, say
 User_Registration offering registration information service to the PD_UA
 object. The User_Registration object may contain several TA identifiers
 since a user may be allowed to use several terminals at the same time.
 The second piece of information required is the identifier of the
 corresponding TD_UA. Although this information can be deduced from the
 identity of the user and the identity of the terminal, it is more
 convenient to store it. The less the processing required at run-time, the
 shorter response time will be obtained. A User_Registration object
 containing a information about the TD_UAs and the TAs is shown in FIG. 5.
 The questions now are: how can the PD_UA get the information about the
 TD_UAs and the TAs and when should the up dating be done to ensure
 consistency with the real movements of the user?
 Default Registration
 As mentioned earlier, every terminal is associated with a default user who
 is the owner of the terminal. In this case, the association between the
 PD_UA and the TA is always defined. We can refer to this as default
 registration.
 Let us consider again the example where an object CO2 wants to invoke the
 operation OpX of an object CO1 belonging the User.sub.a domain. Let us
 suppose now that the User.sub.a is the default user of the Terminal.sub.m.
 When receiving the operation request Call(CO1.OpX( )), the PD_UA.sub.a
 call the operation Get_Registration ( ) of the User_Registrations.sub.a.
 The User_Registration.sub.a checks its TD_UA and TA table and return the
 identifiers of the default TD_UA and the TA, namely TD_UA.sub.a and
 TA.sub.m to PD_UA. The PD_UA.sub.a proceeds to call the operation
 Call(TD_UA.sub.a.Call(CO1.OpX( )) on the TA.sub.m object. The procedure
 will continue as described earlier until the whole operation OpX is
 accomplished. This is depicted in FIG. 6.
 Local Registration
 The local registration is the case where a User.sub.a wants to use a
 Terminal.sub.m belonging to a User.sub.m. Actually the local registration
 belongs to the Access Session which purpose is to enable the user to
 access services.
 Before continuing, some requirements have to be imposed on the terminal. In
 order to allow several users to use the same terminal to access the
 telecom system domain, the terminal must have some more local
 "intelligence", i.e. more processing and storage capability than the
 current terminal used in the fixed network. We introduce an object called
 UI (User_Interface) in the Terminal.sub.m domain. This object is
 responsible for the supervision and control of interactions between the
 terminal and the users. UI has the functionality to switch between
 different users in the case where several users share the same terminal.
 Upon request, UI can also create new TD_UA object to serve new arriving
 user.
 In FIG. 7 we show an example with three users. User.sub.b and User.sub.c
 are already registered at Terminal.sub.m. Upon request, UI can switch
 between these two users, i.e. connecting the input/output channel
 respectively to TD_UA.sub.b or TD_UA.sub.c. The switch request can be
 realised in different ways such as entering command New_User( ),
 depressing a key or by using a mouse to click on an icon, etc.
 When User.sub.a arrives and wants to use the terminal he/she can issue a
 request New_User. The UI can create a new and "temporary" TD_UA object. By
 temporary it is meant that this TD_UA is not yet associated with any user
 or more specific to any PD_UA which is known and recognisable for the
 telecom system domain. The association will only be done after the local
 registration has been accomplished successfully. The UI will also connect
 the input/output channel to this TD_UA. The User.sub.a can now interact
 with the temporary TD_UA.
 Let us now return to our example. The User.sub.a wants to register himself
 at the Terminal.sub.m. After calling the operation New_User( ) and getting
 a temporary TD_UA assigned to him, the User.sub.a enter his User
 Identifier (or name) to the temporary TD_UA (see FIG. 8).
 From the User Identifier the temporary TD_UA deduces the Computational
 Interface Identifier (CII) of the corresponding PD_UA.sub.a knowing that
 the operation LocalRegister( ) has to be invoked on that PD_UA.sub.a. The
 temporary TD_UA invokes therefore the operation Call(PD_UAa.LocalRegister(
 )) on the SPAN, to start the convey of the operation LocalRegister( ). The
 invocation is conveyed through the TAP, NAP and arrives at TA.sub.m. The
 TA.sub.m will then invoke the LocalRegister( ) operation on the
 PD_UA.sub.a. The PD_UA.sub.a will start the security procedures. As shown
 in FIG. 9, we assume now that the security procedures are successful. The
 PD_UA.sub.a will call the operation Set_Registration(TD_UA, TA.sub.m) on
 the User_Reg.sub.a which saves the identifiers of the TD_UA and TA.sub.m.
 The PD_UA.sub.a will answer back to the TD_UA with a status Ok. The TD_UA
 will save the identifier of PD_UA.sub.a and becomes a permanent agent
 associated to User.sub.a. The TD_UA will remain alive until an eventual
 deregistration of the User.sub.a for Terminal.sub.m.
 Remote Registration
 The remote registration is the case where a User.sub.a wants to run or
 receive an application on a remote Terminal.sub.m where he has not logged
 in. User.sub.a is actually logged in at a Terminal.sub.n. In order to
 perform a remote registration User.sub.a must have a registration
 application running on Terminal.sub.n. A registration application is a
 special outgoing application which allows the registration for the
 delivery of application. The design of the registration application falls,
 however, beyond the scope of this document.
 Let us for the time being assume that the Registration application allows
 User.sub.a to enter the identity of the wanted remote terminal, namely
 Terminal.sub.m.
 The Registration application will then invoke Register(Term.sub.m) on the
 PD_UA.sub.a.
 The PD_UA.sub.a will invoke the operation Register(User.sub.a) on TA.sub.m,
 the terminal agent of Terminal.sub.m. Here again, before granting the
 registration, the TA.sub.m initiates the access control of the user for
 the use of the terminal to check whether User.sub.a is allowed to register
 himself at Terminal.sub.m for example to protect the privacy of the
 terminal owner. If the User.sub.a is not allowed, TA.sub.m returns a
 NotAllowed status in the response to PD_UA.sub.a which informs the
 registration application. The registration application will then deliver a
 NotAllowed message to the User.sub.a.
 Let us assume that the access control is successful. The TA.sub.m will
 invoke the operation Register(PD_UA.sub.a) on its counterpart SPAN. As
 usual, the operation invocation must of course be conveyed through the NAP
 and TAP.
 In FIG. 10, we present briefly some operations belonging to the terminal
 mobility support in italics in order not to burden our explanation.
 Upon receipt of the call, the SPAN will create a TD_UA.sub.a2 and invoke
 the operation Associate_with (PD_UA.sub.a) on the TD_UA.sub.a2 causing the
 saving of the identifier of PD_UAa. The TD_UA.sub.a2 will then persist
 until a deregistration for Terminal.sub.m. The SPAN will return an Ok
 status and the identifier of TD_UAa2 to the TA.sub.m which also returns
 the same information to the PD_UA.sub.a.
 The PD_UA.sub.a will then call the operation
 Set_Registration(TD_UA.sub.a2,TA.sub.m) on the User_Reg.sub.a which saves
 the identifiers of TD_UA.sub.a2 and TA.sub.m. The PD_UA.sub.a returns then
 an Ok status to the Registration application. The Registration application
 delivers an Ok Status to the User.sub.a at Terminal.sub.m. This completes
 the remote registration. The procedure for remote registration is shown in
 FIG. 11.
 Local Deregistration
 When the user wants to terminate all his activities at a terminal, he can
 just log out from this terminal. The deregistration is initiated locally
 from the same terminal.
 Let us consider the example shown in FIG. 12. A User.sub.a registered at
 the Terminal.sub.m wants to log out. He terminates his access session (see
 Paragraph 9.4) which results in a termination request to the TD_UA. Before
 terminating, the TD_UA invokes the operation LocalDeregister( ) on the
 PD_UA.sub.a. The operation request is converted into the operation
 Call(PD_UA.sub.a.LocalRegister( ) on the SPAN. The operation is conveyed
 through the TAP, NAP and arrives at TA.sub.m. The TA.sub.m will then
 invoke the operation LocalDeregister( ) on the PD_UA.sub.a. The
 PD_UA.sub.a will invoke the operation Reset_Registration(TD_UA,TA.sub.m)
 of the User_Rega which removes the identifiers of the TD_UA and TA.sub.m
 from its internal table. The PD_UA.sub.a will return to TD_UA a status Ok.
 The TD_UA can now terminate itself. The procedure for local deregistration
 is shown in FIG. 13.
 Remote Deregistration
 To terminate all his activity at a terminal, the user can also initiate the
 deregistration remotely from another terminal. Let us consider the example
 where a User.sub.a wants to deregister himself at a Terminal.sub.m
 belonging to a User.sub.m (the default user), from another terminal,
 namely Terminal.sub.n.
 In order to do such deregistration User.sub.a must have access to a
 deregistration application running on Terminal.sub.n so that he can enter
 the identity of the remote terminal he wants to deregister from. The
 deregistration application will then invoke the operation
 Deregister(Term.sub.m) on the PD_UA.sub.a object.
 The PD_UA.sub.a will call the operation Deregister(User.sub.a) on the
 TD_UA.sub.a2, the terminal domain user agent on Terminal.sub.m assigned to
 User.sub.a. This operation is shown by a dotted arrow in FIG. 14.
 Physically it is converted to an operation on the TA.sub.m and then
 conveyed via the NAP, TAP, SPAN before arriving at TD_UA.sub.a2. The
 TD_UA.sub.a2 object will remove the identifier of the PD_UA.sub.a, return
 an Ok status to the PD_UA.sub.a object and terminate itself. The
 PD_UA.sub.a object will call the operation
 Reset_Registration(TD_UA.sub.a2, TA.sub.m) on the User_Rega object causing
 the removal of the identifiers of the TD_UA.sub.a2 and TA.sub.m from its
 internal table. Upon receipt of an Ok status, the PD_UA.sub.a object can
 return the Ok status to the deregistration application which may forward
 it to User.sub.a. This completes the remote deregistration. The procedure
 for deregistration is shown in FIG. 15.
 Supporting Multiple Terminal Registration
 As stated earlier, a user must be allowed to register at and use several
 terminals at the same time.
 To clarify the situation, let us consider the example shown in FIG. 16. A
 User.sub.a is registered at two terminals Terminal.sub.n and
 Terminal.sub.m and is associated with two terminal agents TD_UA.sub.a1 and
 TD_UA.sub.a2 respectively. He has two computational objects CO1 and CO3
 running on Terminal.sub.n and Terminal.sub.m respectively. CO1 is
 interacting with CO2, CO3 with CO4, where CO2 and CO4 belong to the
 telecom system domain.
 Suppose first that CO1 requests an operation OpX( ) on CO2. The operation
 request is translated to the operation Call(CO2.OpX( )) on TD_UA.sub.a1.
 The TD_UA.sub.a1 object will then invoke the equivalent operation
 Call(CO2.OpX( )) on its peer-object PD_UA.sub.a in the telecom system
 domain which in turn delivers the request to CO2. This is done without
 difficulty since TD_UAa1 knows the identifier of PD_UA.sub.a. Similarly,
 CO3 can invoke any operation on CO4 without any problem. The existing
 mechanism is sufficient to support invocation initiated form the user
 domain. The opposite that is, object CO2 invoking an operation on CO1 or
 object CO4 on object CO3 requires additional information and
 functionality.
 Suppose next that CO2 requests an operation OpY( ) on CO1. Again, the
 operation request is translated to the operation Call(CO1.OpY( )) on
 PD_UA.sub.a. The problem now is that PD_UA.sub.a does not know on which
 terminal CO1 is located. It is unable to decide whether it should transfer
 the operation request to TD_UA.sub.a1 or to TD_UA.sub.a2. The PD_UA.sub.a
 holds only the information that User.sub.a is registered at both terminals
 Terminal.sub.n and Terminal.sub.m but it has no knowledge concerning the
 location of each object of User.sub.a. It is therefore obvious that such
 information must be supplied to it.
 Every object in the user domain wishing to receive request from object on
 the telecom system domain must therefore be registered by some object in
 the telecom system domain so that the PD_UA.sub.a object can interrogate
 in order to obtain the location of the user object. A convenient place to
 store this information will be the User_Registration.sub.a object.
 The user agents TD_UA.sub.a1 and TD_UA.sub.a2 must be equipped with an
 additional operation permitting the registration of the user objects in
 the terminal domain. Such operation, say ObjReg may have the following
 IDL/ODL specification in which IDL is defined as Interface Definition
 Language defined in CORBA, and ODL is defined as Object Definition
 Language defined by TINA-C which is an extension of IDL allowing the
 definition of object [TIN95h].
 ObjReg(in ObjectId objectname, in ObjectId useragentname) objectname is the
 Computational Interface Identifier of the registered object.
 useragentname is the Computational Interface Identifier of the user agent
 to where the object will be registered. This argument is not necessary
 when the registration is done locally and may therefore be empty.
 This registration of the user objects (CO1 or CO3) may be done by the user
 objects themselves or by some proxy objects. FIG. 18. The user agents
 (TD_UA and PD_UA) act as relays for passing the registration information
 to the User_registration object.
 When receiving the operation request ObjReg(objectname,TD_UAname), the
 TD_UA will call the operation UserObjReg(objectname, TD_UAname) on its
 peer-object PD_UA. The PD_UA will in its turn call a similar operation
 UserObjReg(objectname, TD_UAname) on its User_Registration object. Upon
 receipt of the request, the User_Registration object shall save the object
 registration information. Its storage capability must therefore be
 expanded to include such information. The internal data structure can be
 implemented in different ways. An example is shown in FIG. 17. For each
 row of the main table, there is assigned an ObjectList containing the
 identifiers of all object registered at a terminal. To enhance further the
 functionality, a multiple object registration operation may also be
 defined for each of the objects TD_UA, PD_UA and User_Registration.
 An object can also be deregistered. The procedure for object deregistration
 and the required operations are quite similar to these for registration.
 Upon receipt of an operation UserObjDereg(objectname, TD_UAname), the
 User_Registration fetches the corresponding ObjectList and removes the
 identifier of the specified object. When a row of the main table is
 remove, i.e. a user deregistration for a terminal is executed, the
 corresponding ObjectList will also be deleted.
 In addition to the object registration and deregistration operations, the
 User_registration object must also have an operation other objects may use
 in order to request object registration information:
 GetObjReg(in ObjectId objectname, out ObjectId useragentname)
 When receiving an operation request Call(CO1.OpY( )) from CO2 addressed to
 CO1, and CO1 is not in the telecom system domain, the PD_UA.sub.a invokes
 GetObjReg(CO1, AgentToCall) on its User_Registration object. The
 identifier of TD_UA.sub.a1 is returned in the parameter AgentToCall. The
 PD_UA.sub.a can proceed to invoke Call(CO1.OpY( )) on TD_UA.sub.a1. The
 operation is finally conveyed all the way to TD_UA.sub.a1 which call OpY
 on CO1. The result will be returned using the same path back to CO2.
 Merits of the Invention
 The present invention provide user mobility in distributed system.
 It is quite flexible since it is using agent technology which allows
 modification of the internal implementation of the agents without
 affecting the rest of the system.
 It can be used in any type of networks, fixed or mobile, public or private,
 local-area or wide-area, wireline or wireless.
 It also allows several users to use same terminal.
 It also allows one user to use several terminals simultaneously.
 It ensures the user privacy by recording and separating objects belonging
 different users.