GB2315387A

GB2315387A - Method and apparatus for accessing a plurality of networks

Info

Publication number: GB2315387A
Application number: GB9614922A
Authority: GB
Inventors: William Robinson; Nicholas Whinnett; Jonathan Gibbs; Den Heuvel Anthony Van
Original assignee: Motorola Ltd
Current assignee: Motorola Solutions UK Ltd
Priority date: 1996-07-16
Filing date: 1996-07-16
Publication date: 1998-01-28
Anticipated expiration: 2016-07-16
Also published as: GB2315387B; GB9614922D0

Abstract

A removable User Identity Module (UIM) 400 allows a user to simultaneously access services provided by different networks 200, 201, 202 via one or more terminals 300, 301, 302 while retaining the option of having only one dialable number for all services. The UIM 400 is inserted in a terminal and the user chooses the services to be available at that terminal. The user can then select a mode of operation where the terminal will maintain that availability when the UIM (400) is withdrawn. The UIM can then be inserted in a different terminal (301) for a different set of services. The UIM is a smartcard comprising a microprocessor 410 and memory 420 to store subscription information and currently registered services. A service registered and thus made available on one terminal in one network can be deregistered remotely from another terminal in the same or a different network.

Description

METHOD AND APPARATUS FOR ACCESSING A PLURALITY OF NETWORKS Field of the Invention The present invention is generally related to telecommunication devices and system, and more particularly, to a method and apparatus for providing a number of different services.

Backmound of the Invention Telecommunications systems are offering an increasingly sophisticated set of services to end users. For example in the Global System for Mobile Communications (GSM), many new services, such as high speed circuit switched data, packet data services, etc., are planned for introduction in the next few years. The next generation of telecommunications systems, e.g. the Universal Mobile Telecommunications System (UMTS), is expected to have even more services available to the end user. The end user will be able to subscribe to a large number of different services and may require a plurality of different terminals for use with different services or sets of services. For example the end user may choose to have one terminal (mobile phone) for voice telephony services, a different terminal (fax machine) for fax services and yet another terminal aaptop computer) for packet data services. Of course, it is also possible to provide access to more than one service at one terminal.

It is desirable for the user to have one dialable number for all his telecommunications needs. In the present GSM system, the dialable number is associated with a Subscriber Identity Module (SIM). The SIM can be inserted into and removed from the terminal by the user in order to register and de-register with the network/service provider for telecommunications services. However, such a SIM cannot be used to register more than one terminal at the same time, because whenever the SIM is removed, the terminal is automatically de-registered. The result of this limitation is that if a user is engaged in a telecommunications service using one of his terminals, his other terminals are unavailable for other services.

Also, if one looks at almost any business card, one can immediately see that most people have a number of different addresses which can be used to contact the individual, with each address representing a contact identity for a subset of the total services available to the individual. This situation is undesirable because the calling party is required to remember and store all of these different dialable identities. Furthermore the calling party must select the appropriate called party identity for the service being invoked.

In the future, it will be desirable to minimize the number of identities associated with a user, preferably to just one or two numbers for all services. For example, a user could have one business number and one private number, with each number providing access to all of the telecommunications services the user needs in each role (i.e. business role or private role). The concept of number portability between networks has already been accomplished by the roaming capability of GSM. However, each GSM dialable number belongs to only one GSM network and is allocated to a particular subscriber within the subscription domain of that network. In the future it will be desirable for the ownership of dialable numbers to be independent of the specific network and to be associated with the individual user.

Accordingly, there is a need for a method and means for allowing a user to simultaneously access services from different networks while retaining the option of using only one dialable number for all services.

Brief Descrihon of the Drawings FIG. 1 is a block diagram of a communication system according to the present invention; FIG 2 is a block diagram of a communication system according to an alternate embodiment of the present invention; FIG. 3 is a block diagram of a communication system according to another alternate embodiment of the present invention.

FIG. 4 is a block diagram of a terminal according to the present invention; FIG. 5 is a block diagram of a service provider according to the present invention; FIG. 6 is a flow chart showing the registration of a terminal to multiple networks according to the present invention; FIG. 7 is a flow chart showing the method of accepting or denying service according to the present invention; FIG. 8 is a flow chart showing the preferred method of accepting or denying service according to the present invention; FIG. 9 is a flow chart showing a method for accessing multiple networks according the present invention; FIG. 10 is a flow chart showing a method for accessing multiple networks according to an alternate embodiment of the present invention; FIG. 11 is a flow chart showing steps of a deregistration procedure for a network; FIG. 12 is a flow chart showing the deregistration process at the UIM network; FIG. 13 is a flow chart showing the deregistration process at the service network; FIG. 14 is a flow chart showing the deregistration process at a terminal generally; FIG. 15 is a flow chart showing the deregistration process at a UIM terminal; FIG. 16 is a flow chart showing the method for multiple registration profile inquiry in a multiple network environment; FIG. 17 is a flow chart showing the steps for generating a service activity report; and FIG. 18 is a block diagram of an apparatus for communicating with a plurality of networks.

Detailed Descrlntlon of the Invention The method of the present invention relies on the use of a removable User Identity Module (UIM), which can store information about multiple subscriptions to multiple networks. The UIM preferably can store information including information about which services the user has subscribed to and with which networks these services have been subscribed. The information stored in the UIM also preferably includes information about which services are currently registered with which network. Additionally, the UIM, or less advantageously the terminal, is preferably adapted to use the information stored in the UIM to detect whether a specific service has been registered and with which network it is registered to prevent the registration of a service on one network if that service is already registered via a different network.

The terminals preferably allow the user to select services for registration (e.g. via menu selection) and with which network. Also, the serving network preferably indicates to the terminal (e.g. via broadcast messages) which services the network can support. The terminal also determines which of those services supported by the network it also supports, and the tariffs for those services. The terminal also preferably determines via information contained in the UIM, which of the services the user has subscribed to and consequently displays information about which services are accessible to the user via this terminal and this network, the services are currently registered and via which networks they are registered (e.g. via a display). Finally, the terminal also informs the user as to the outcome of the users attempt to register services (e.g.

via a display).

The UIM and the terminal together are adapted to exchange information regarding requested services for registration and the status of each service being proposed for registration. After the UIM is inserted into the first terminal, the terminal detects a first user set of services selected to be registered and the network with which these services are to be registered, taking account of the accessibility of services according to network, terminal and subscription capabilities. According to one aspect of the invention, the terminal could be adapted to block any outgoing calls if the UIM is not in the device, while allowing incoming calls. The terminal informs the UIM of the first user set of services. Optionally, this selection of the first user set of services could be automated by the terminal. The UIM checks the information stored in the UIM to test that none of the first user set of services are currently already registered with a different network.

As this is the first registration attempt, all of the first user set of services which have been subscribed for access via the first network are given the "go" status by the UIM. The terminal registers the first user set of services with the first network. The UIM is informed of the registration status of the first user set of services by the terminal while the user is informed of the registration status of the first user set of services by the terminal. The UIM preferably stores the registration status of all of the services in the first set of services. Subsequently, the UIM may be removed from the first terminal and inserted into a second terminal. A second user set of services to be registered and the networks with which these services are to be registered are selected. The registration for the second set of services does not essentially require the use of a second terminal. If the first terminal has the capability to access multiple networks simultaneously, then the second set of services can be registered via the first terminal. This process is repeated for as many user sets of services as appropriate.

The present invention allows users to simultaneously have access to services from different networks whilst enabling the UIM to prevent any service from being simultaneously registered with two different networks, and allows all of the services subscribed and registered to be associated with the user's single identity where this is desirable. In the case of the terminal roaming to a visited network, the visited network may reject the registration attempt for one or more of the services. Where this occurs, the terminal will inform the user and the UIM of this event. Also, deregistration of services is achieved by inserting the UIM into a terminal, selecting the service(s) for de-registering from the user set of services and initiating the de-registration procedure for that service. Upon completion of this procedure, the information stored in the UIM is updated accordingly.

Thus, as shown in FIG. 1, a telecommunications system 100 includes a service provider 200, which provides one or more services to users of at least two terminals 301. Three terminals, including a fax machine 300, a radio telephone 301 and a handheld or laptop computer 302 are shown by way of example. A controller 400, which can be a socalled smartcard, comprises a microprocessor 410 and a memory 420. An alternate embodiment of the present invention shown in FIG. 2 includes at least two service providers, although three service providers 200, 201 and 202 are shown.

One can envisage a situation where, for example, one service provider 201 specializes in voice services only and does not support data services. Another service provider 200 might specialize in data services, such as facsimile services, only, whilst a third service provider 202 provides a comprehensive set of voice and data services, but at perhaps a slightly lower performance than the other two service providers 200 and 201. As the competition between these service providers develops, the service providers 200, 201 and 202 might choose to add more and more services as they compete for revenue and market share. In these circumstances, it is likely that an end user might purchase more than one terminal 301 Perhaps the user initially starts off with a basic voice terminal 301, such as a cellular telephone, and, not wishing to throw away his investment in the voice terminal 301, he subsequently decides to purchase a fax terminal 300 and also a voice and data terminal 302, such as a lap-top computer, rather than to buy a single more expensive terminal which supports all of the services. These three terminals 300, 301 and 302 fulfill the same function as a more expensive integratedservices terminal 304 as shown in FIG. 3.

As shown in FIGs. 1-3, for example in the alternate embodiment of the controller 400 can be a removable User Identity Module (UIM), having a single dialable number for the end user associated therewith, for example by having the dialable number and/or other identification information uniquely associated with the dialable number, as well as other information, stored as an identifier in an electronic memory 420, which is connected to the microprocessor 410 in the UIM 400. Other information which can be stored in the memory 420 of the UIM 400 includes communications enabling information, such as encryption/decryption algorithms and/or service authorization information.

At least one of the terminals includes a card reader. As shown in FIG. 4, a representative terminal includes a reader 310 for reading the UIM 400 to determine the identifier that is associated with the UIM 400 and a memory 320 for storing the read information including the identifier and the communications enabling information. The reader 301 can be a contactless reader or can require contact with the UIM 400, for example by inserting the UIM 400 into a slot (not shown) in the terminal 300. -The terminal 300 also includes a transmitter 330 for communicating, via antenna 315, the stored information to the service provider 200, as indicated by arrow 325. A services selector 340 for selecting one or more of the plurality of services to be associated with the identifier is provided so that the user can choose which services, of those offered by the service provider, are required. The services selector 340 can be menu driven, if the terminal has a display, or can be responsive to the selection of buttons corresponding to services to be selected. Information regarding the selected services is stored in the memory 320 for transmittal to the service provider together with the identifier. The terminal 300 also includes a mode switch 350, coupled to the memory 320 and the reader 310, to enable the user to switch between two modes of operation of the terminal 300. In one of the modes, the UIM 400 is required to be physically associated with the terminal 300 for availability of services to be maintained. If the UIM 400 is removed, the terminal 300 is automatically deregistered from the service provider, as in known systems. In the second mode, however, the physical presence of the UIM 400 in the terminal 300 is not required to maintain the availability of the selected services at the terminal 300.

As best shown in FIG. 5, at least one of the service providers 200 includes a receiver 220, coupled to an aerial 215, for receiving the identifier and information regarding selected services transmitted (as shown by arrow 225) by the terminal 300, a memory 210 for storing the received identifier and information regarding which services are currently selected for the particular identifier, a comparator 230, a first controller 240 for allowing or denying access to the requested service depending upon the output of the comparator and for creating and storing in the memory 210 a new set of selected services and a second controller 250 for creating and storing in the memory 210 a new set of selected services and for removing from any existing set of services any service which is to be included in the new set of services.

In operation of the preferred embodiment, the UIM 400 is inserted into the terminal 300. The reader 315 of the terminal 300 reads the identifier and communication enabling information stored in the memory 420 of the UIM 400. The terminal 300 and the UIM 400 together provide a capability called hereinafter Personality Capture". Personality Capture is defined as the capability to duplicate the functionality and data stored in the UIM 400 and to store this flinctionality and data in the terminal 300 This can be achieved by the terminal 300 simply using the reader 310 to read the information stored in the memory 420 of the UIM 400 and storing this information in the memory 320 of the terminal 300. This mode of operation can be selected by the mode selector 350 and protected by a pre-determined authentication mechanism, such as password protection. This Personality Capture is invoked prior to the withdrawal of the UIM 400 from the terminal 300. Having completed the Personality Capture in the first terminal 300, and withdrawn the UIM 400 from the first terminal 300, the UIM 400 can subsequently be inserted into a second terminal 301. Thus, the first terminal 300 maintains the availability of the first set of services that were selected and a second set of services can then be selected at the second terminal 301 and can be made available at the second terminal 301.

As described above, when the UIM 400 is inserted into one of the terminals 300, the user is able to select which services are to be accessible via that specific terminal 300 using the services selector 340. The terminal 300 will only accept those services for which it has the appropriate service capability. For example, if the terminal does not have a video display capability, then any service which is dependent upon video images will be rejected by the terminal. Having made the selection, the user selects at the terminal using a service control selector 360 which of the two controllers 240 and 250 available in the service provider 200 are to be activated. These selections are communicated to the service provider 200 by the terminal 300 using the transmitter 330 and the receiver 220.

This communication initiates the process of registration for these selected services.

Registration of services is indicated to the service provider 200 as either a standard incremental service registration to complement the services already registered, or a superseding incremental registration.

Referring firstly to FIG 6, in the registration procedure commencing at START, the user first selects (500) which of the services are to be registered at the terminal via the services selector. The user then also selects (510) which type of service registration (standard incremental registration or superceding incremental registration) is required using the service control selector.

The terminal then communicates (515) the selections from the previous two steps (500 and 510) to the service provider, via the transmitter and the receiver.

The information about the requested services is passed (520) by the service provider either to the first controller, if a standard incremental registration has been requested during the second step (510) or to the second controller if a superceding incremental registration has been requested during the second step (510) and the procedure comes to an END.

If standard incremental registration procedure has been selected, the first controller then processes (530) the information and controls the service provider accordingly. This procedure is shown in more detail in FIG 7.

If superceding incremental registration procedure has been selected, the second controller then processes (540) the information and controls the service provider accordingly. This procedure is shown in more detail in FIG 8.

In standard incremental service registration, the service provider 200 shall not cause a new incremental registration of services to supersede any previous registration of services. Furthermore the service provider 200 shall reject an incremental service registration which includes a service already registered. This process operates, as shown in FIG. 7, by the following steps: Firstly, commencing at START, one of the requested services is selected (532) and passed to the comparator in the service provider. The comparator compares (534) this requested service with information already stored in the memory of the service provider to determine whether or not the requested service is already registered for the identifier associated with the particular controller. If the requested service is the same as one of the currently selected services, the comparator provides a first output. If the requested service is not the same as one of the currently selected services, the comparator provides a second output.

If the comparator provides the second output during the comparison step (534), the requested service is accepted (536) and the service is entered into a service set associated with this registration and this information is stored in the memory. If the comparator provides the first output during the comparison step (534), the requested service is denied (538).

The first controller then determines (539) whether there are any remaining requested services and if so, the procedure is repeated from the first step (532) for the next requested service. For each requested service, the service provider may inform the terminal about the outcome of the registration process in the normal way. If there are no remaining requested services, the procedure ENDS.

In superceding incremental service registration, the service provider 200 knows that new services are being registered but if one of the new services being registered in the current registration attempt has previously been registered via another terminal, then the new registration takes precedence. This control process is executed using the comparator 230, the second controller 250 and the memory 210.

This process operates, as shown in FIG. 8 commencing at START, with the first of the requested services being selected (542) and passed to the comparator in the service provider. Similarly to the standard incremental service procedure, the comparator then compares (544) this requested service with information already stored in the memory of the service provider to determine whether or not the requested service is already registered for the identifier associated with the particular controller. However, if the requested service is the same as one of the currently selected services, the comparator provides a first output and determines which of the existing service sets for the service sets contains the requested service. If the requested service is not the same as one of the currently selected services, the comparator provides a second output, as before.

If the comparator provides the second output during the comparison step (544), the requested service is accepted (546) and the service is immediately entered into a service set associated with this registration and this information is stored in the memory of the service provider. If, however, the comparator provides the first output during the comparison step (544), then the requested service is removed (548) from the set identified during the comparison step (544) and the information stored in the memory is updated to reflect this change. Following the completion of the step (548) of removal and update, the requested service is accepted (546) and the service is subsequently entered into a service set associated with this registration Finally, the second controller determines (549) whether there are any remaining requested services and if so, the procedure is repeated from the first step (542) for the next requested service. For each requested service, the service provider (200) may inform the terminal (300) about the outcome of the registration process in the normal way. If there are no remaining requested services, the procedure ENDS. This process of registering services at different terminals may be repeated for any additional terminal or terminals being used by the user.

If terminal identities or temporary terminal identities are used by the system, then these identities can easily be associated with the particular instance of registration by the service provider 200 in the memory 210.

The invocation of Personality Capture can be triggered in a number of ways, depending on the product concerned, for example by: a) pressing a designated button at the terminal 300; b) pressing a designated button while withdrawing the UIM 400 from the terminal 300; c) selecting from a menu option at the terminal 300; d) having a menu option selected while withdrawing the UIM 400 from the terminal 300; or e) default invocation of Personality Capture upon commencement of withdrawal of the UIM 400.

Turning now to FIG. 9, a flow chart shows the method for registering to multiple networks with a single UIM. At a step 902, a terminal receives the UIM, and determines whether the user of the UIM is a subscriber with multiple networks at a step 904. If the user is not a subscriber to multiple networks, the terminal registers to a first set of user services of a first network at a step 906. However, if the user is a subscriber to multiple networks, the terminal determines whether the set of user services is desired on a given network at a step 908. Although a set of users services is described, the set could comprise a single service.

If a given network is desired, the terminal accesses the network which provides the set of user services at a step 910. The terminal then registers with the network at a step 912. The registration status is stored in the UIM at a step 913. The terminal then determines whether there is another set of user services desired on a different network at a step 914.

If another set of services is desired, the terminal accesses the different network which provides the set of user services at a step 910.

Turning now to FIG. 10, a flow chart shows in more detail the preferred method for registering a terminal to multiple networks according to the present invention. At a step 1002, the terminal receives the UIM. The terminal then detects the set of user services selected for registration at a step 1004 (e.g. via manual selection). The terminal then detects the network selected for each service at a step 1006 (e.g. via manual selection), and determines whether there is any selected service of the set of user services which is currently registered with a different network at a step 1008 by interrogating the UIM. If no service is registered with a different network, a "GO" status is transmitted by the UIM to the terminal at a step 1010. The terminal then registers the set of user services with the network at a step 1012. The terminal also provides the registration status of the set of user services with the network to the UIM at a step 1014. Finally, the UIM receives and stores the registration status for the set of user services at a step 1016. If the terminal determines that additional services are desired at a step 1018 (e.g.

manual input), the terminal detects the selection of additional services of the set of user services at a step 1004.

If a selected service is registered with a different network, the terminal displays a message indicating that the selected service is registered at a step 1022. The terminal then determines whether a change of status of services is desired at a step 1024 by receiving feedback from the user (e.g. via manual input). If a change of status is required, the terminal determines whether the currently registered network is accessible at a step 1026. Because the different networks providing service may not be capable of or have an arrangement to exchange information, a network may not be able to change the status of service. If the registered networks are accessible (i.e. capable of exchanging information), the terminal instructs the network to deregister the current service at a step 1028 to enable registration to another network. After deregistering, the UIM transmits a "GO" status to the terminal at a step 1010. If the currently registered network is not accessible at step 1026, the network prevents registration of the service at a step 1030, and determines whether any additional services are desired at a step 1018.

Turning now to FIGs. 11-15, the method steps for deregistration according to the present invention are shown. To more clearly describe the operation of deregistration within the network, various flow charts are used to describe the preferred steps at a various networks or terminals within the system according to the present invention. In particular, a UIM terminal is defined as a terminal having the UIM. A UIM network is a network providing service to the UIM terminal. A service terminal is any terminal not having a UIM. A service network is a network which is providing service to the service terminal. A service terminal may be provided by either the UIM network or the service network.

Turning first to FIG. 11, for each user, the network determines whether it is in the UIM network state or service network state for that user at a step 1102. If the network is in the UIM network state, the UIM network determines, as set forth in FIG. 12, whether the UIM terminal instructs the UIM network to initiate remote deregistration at a step 1202. If the UIM terminal has instructed the UIM network to remote deregister another terminal which will be a service terminal, the UIM network then determines whether remote deregistration is required in the UIM network at a step 1204. That is, the UIM network determines whether the service terminal which is being remotely deregistered is being provided service by the UIM network or some other network. If the service terminal is provided service by the UIM network, the UIM network would have access to the service terminal, and therefore instructs the service terminal to remote deregister at a step 1206. The network then sets the deregist terminal determines whether it is in the UIM terminal state or the service terminal state at a step 1404. If the terminal is in the service terminal state, the terminal determines whether the network providing service has provided instructions to remote deregister at a step 1406. If remote deregistration is required at a step 1406, the terminal performs the deregistration process and indicates the registration status to the user at a step 1408. The terminal then determines whether a change of state to a UIM terminal occurs at a step 1410. As will be described in more detail in reference to the remaining figures, a change in states to the UIM terminal must be provided to the network providing service. In particular, many steps of the deregistration process are determined by whether the terminal is a UIM terminal or a service terminal.

Returning to FIG. 11, if the network is in the service network state, the service network responds to commands from the UIM network according to the steps of FIG. 13. In particular, the service network determines whether the UIM network has instructed the service network to remote deregister the service terminal at a step 1302. If the UIM network has instructed the service network to remote deregister the service terminal, the service network performs remote deregistration according to step 1304. In particular, the service network instructs the service terminal to remote deregister at a step 1306. The service network sets the deregistration status to pass at a step 1308 and determines whether the service network and the UIM network are cooperating at a step 1310. If the networks are cooperating, the service network indicates the deregistration to the UIM network at a step 1312.

The service network may also deregister the service terminal without an instruction from the UIM network. In particular, the service terminal may determine at a step 1314 whether a registration timer has expired. Such a timer may preferably be set to minimize inadvertent or unauthorized use of the network. If the registration timer has expired, the service network instructs the terminal to remote deregister at a step 1304. Alternatively, the service network could determine whether service is invoked at the service terminal at a step 1316. If service is invoked, the service network will reset and start a service invocation timer at a step 1318.

The service network would then determine whether the service invocation timer has expired at a step 1320. Such a timer could also minimize excessive, inadvertent or unauthorized use of service provided by the network. If the service invocation timer has expired, the service terminal performs deregistration at step 1304. However, if the service invocation timer has not expired, the network determines whether an user inquiry timer has expired at a step 1321. If the user inquiry timer has expired, the service network then determines whether the service network and the UIM network are cooperating at a step 1322. If the networks are not cooperating, the service network performs remote deregistration according to steps 1304. If the networks are cooperating, the service network requests the UIM network for continuation of service terminal registration at a step 1324. The service network then receives a registration continue/discontinue status from the UIM network at a step 1326. If a registration discontinue status is received at a step 1328, the service network performs the deregistration function at step 1304. Ifthe service network receives a registration continue status at step 1328, the service network resets and starts the user inquiry timer at step 1330.

After the deregistration status has been indicated to the UIM network at step 1312 or after determining whether the user inquiry has expired at step 1321, the network may receive a terminal change of status indication at a step 1108. Although the timers are shown in connection with the operation of the service network, similar timers may be utilized in the UIM network although this option is not shown in FIGs. 11 and 12 to avoid redundancy. Also, timers based on other criteria may be utilized within the spirit and scope of the present invention. The timers described in reference to FIG. 3 are given by way of example.

Returning to FIG. 12, if the UIM terminal does not instruct the UIM network to initiate remote deregistration at step 1202, the UIM network then determines whether the cooperating service network indicates remote deregistration status of the service terminal at a step 1222. If the service network indicates the remote deregistration status, the UIM network provides an indication of the deregistration status to the UIM terminal at step 1210. However, if the cooperating service network does not provide an indication of remote deregistration of a service terminal, the UIM network determines whether the service network has requested continuation of registration for the service terminal at a step 1224. If the service requests a continuation, the UIM networks requests registration continuation from the UIM terminal at a step 1226. The UIM terminal then provides a registration continue/discontinue status at a step 1228. The UIM network then informs the service network of the continue/discontinue status of the UIM network at a step 1230. After indicating the deregistration status to the UIM terminal at step 1210 or informing the service network of the continue/discontinue status at step 1230, the network determines whether it receives a terminal change of state indication at a step 1104. If a change of state of the terminal occurs, the resets and starts a registration timer, resets and starts a service invocation timer and resets and starts a user inquiry timer at a step 1106.

Remote deregistration can either be performed manually by a user or automatically by a network. If the terminal is in the UIM teraiinal state at step 1404, the UIM terminal could initiate a remote deregistration according to the steps shown in FIG. 15. At a step 1502, the terminal determines whether the user has instructed the terminal to initiate remote deregistration. If the user has instructed the UIM terminal to initiate a remote deregistration, the terminal accesses the UIM to obtain the ID of a corresponding service network for deregistration at a step 1504, assuming that multiple networks are employed in the system. In the embodiment of FIG. 1 where a single network is involved, step 1504 would not be necessary. Step 1504 would however be necessary for the embodiments of FIGs. 2 and 3. The UIM terminal then instructs the UIM network to initiate remote deregistration at a step 1506. The UIM terminal then receives a request acknowledgment from the UIM network at a step 1508. The terminal also determines whether a deregistration status of "pass" or "fail" is received at a step 1510. If a deregistration status of "pass" is received, the terminal instructs the UIM to store the deregistration status at a step 1512. In the embodiment of FIG. 1 where a single network is involved, step 1512 would not be necessary. Step 1512 would however be necessary for the embodiments of FIGs. 2 and 3. The terminal then indicates the registration/deregistration status to the user at a step 1514, and determines whether the terminal has changed a state to a service terminal at a step 1412. If the terminal has changed state at step 1412, the terminal informs the network of the change of terminal state at step 1414.

Turning now to FIG. 15, if the user does not instruct the terminal to initiate remote deregistration at a step 1502, the UIM terminal determines whether the UIM network has indicated that remote deregistration has occurred at a step 1516. If remote deregistration has occurred, the terminal instructs the UIM to store the deregistration status at a step 1512. The terminal then indicates the registration/deregistration status to the user at a step 1514. If remote deregistration has not occurred, the UIM terminal determines whether the UIM network has requested continued service at a remote service terminal at a step 1518. If the UIM network requests continued registration at a remote service terminal, the terminal then invites the user to select "continue" or "discontinue in response to the request at a step 1520. The UIM terminal then informs the UIM network of the continue/discontinue status at a step 1522.

Turning now to FIG. 16, the preferred steps for a multiple registration profile inquiry according to the present invention are shown.

In particular, the UIM causes the terminal to transfer local database information to the UIM network upon registration at a step 1602. The UIM network determines whether a multiple registration profile is desired at a step 1604. If a multiple registration profile is desired, the terminal sends a multiple registration profile inquiry to the UIM network at a step 1606. The UIM network determines whether the UIM is registered to multiple networks at a step 1608. If it is not registered to multiple networks, the UIM networks sends the multiple registration message to the terminal at a step 1610. However, if the UIM is registered to multiple networks, the UIM network determines whether the other networks are available at a step 1612. If the other networks are not available, the UIM network transmits a message to the UIM terminal providing a status of terminals registered to the UIM terminal only at a step 1614. In this case, the UIM terminal then accesses the UIM to determine the multiple registration profile at a step 1615. However, if other networks are available, the UIM network will transmit a message to available service networks. UIM network will receive reply messages from the service networks indicating the status of terminals registered with service networks. The UIM network then transmits a message indicating the status of the terminals to the UIM terminal at a step 1616.

The message would include the status of any terminal registered to the service networks.

According to an alternate embodiment of the invention, a service activity report informs the active terminals of services taking place based upon a predetermined set of criteria. For example, the report could be generated based upon a certain event, on a periodic basis, or upon request after a predetermined period of time.

Turning now to FIG. 17, the steps for generating a service activity report according to the present invention are shown. In a step 1702, a service activity report timer is reset. If a user requests a service activity report at a step 1704, the UIM network obtains an activity report from the service network for each cooperating service network at a step 1706. The UIM network then notifies the UIM terminal at a step 1708.

If no service activity report is requested at step 1704, the UIM terminal determines whether a service activity report timer is enabled and expires at a step 1710. If the timer is enabled that expired, the service activity report timer is reset at step 1712. The UIM network obtains the service activity report according to step 1706, and notifies the UIM terminal at step 1708. If the service activity timer is not enabled or has not expired, the UIM network determines whether it receives an indication of service invoked at a service network and service activity is notifiable. If service is invoked at the service network and service activity is notifiable, the UIM network notifies the UIM terminal at a step 1708.

However, if the activity is not invoked at a service terminal or the service activity is not notifiable, it is determined whether the service is invoked at a service terminal in this network and the service activity is notifiable at a step 1716. If the service is invoked at a service terminal in this network and the service activity is notifiable, it is determined whether the network in the UIM network or the service network state at a step 1718. If the network is in the UIM network state, the UIM network notifies the UIM terminal at a step 1708. If the network is in the service network state at step 1718, it is determined whether the UIM network is a cooperating network at a step 1720. If so, the service network notifies the UIM network at a step 1722.

Turning now to FIG. 18, a network apparatus 1800 for accessing multiple communications networks is shown. Network apparatus 1800 is adapted to perform the steps of the networks described herein and preferably includes a controller 1802 which is coupled to a transceiver 1804 for enabling RF communication with a terminal. A network-tonetwork interface port 1806 also provides information to controller 1802 to enable communication between networks. A memory 1808 having a cooperating network list is also coupled to controller 1802 to enable the controller to determine which networks will provide information regarding terminals on the network. Timers 1814 enable the controller to perform necessary timing functions of the network. Finally, a network state manager 1812 is coupled to the controller to provide network information.

While the specific implementations of the present invention are described above, variations and modifications could be made by one skilled in the art within the spirit and scope of the present invention. The present invention should be limited only by the appended claims.

I claim:

Claims

CLAIMS 1. A method of communicating with a plurality of networks in a communication system, said method comprising the steps of: receiving a UIM at a first terminal; accessing a first network which provides at least one service of a set of services; registering said at least one service with said first network; accessing a second network which provides at least a second service of said set of services; and registering said at least one service with said second network.
2. The method of communicating with a plurality of networks of claim 1 wherein said step of receiving said UIM comprises receiving registration information stored in the memory of said UIM.
3. The method of communicating with a plurality of networks of claim 1 wherein said step of accessing a first network comprises determining whether said terminal is registered with a network of said plurality of networks.
4. The method of communicating with a plurality of networks of claim 1 wherein said step of registering with said first network comprises registering with a plurality of services of said set of services.
5. The method of communicating with a plurality of networks of claim 1 further including a step of providing an indication of the registration.
6. The method of communicating with a plurality of networks of claim 1 further including a step of detecting whether a change of status of service is desired.
7. The method of communicating with a plurality of networks of claim 1 further including a step of instructing the network to deregister the service in response to user input.
8. The 'method of communicating with a plurality of networks of claim 1 further including a step of providing a registration status.
9. The method of communicating with a plurality of networks of claim 1 further including a step of receiving said UIM at a second terminal, wherein said step of accessing a second network comprises accessing said second network from said second terminal.
10. The method of communicating with a plurality of networks of claim 1 further including a step of blocking any outgoing calls when said UIM is removed from the terminal.
11. The method of communicating with a plurality of networks of claim 17 further including a step of allowing incoming calls when said UIMis removed from the terminal.
12. A method of communicating with a plurality of networks substantially as hereinbefore described with reference to the accompanying drawings.
13. A method of enabling communication of a terminal with multiple networks in a communication system, said method comprising the steps of: providing registration information for accessing a first network which provides at least one service of a set of services; enabling registration of said terminal with said first network; providing registration information for accessing a second network which provides at least a second service of said set of services; and enabling registration of said terminal with said second network.
14. The method of enabling communicating of claim 13 further including a step of receiving registration status information from said terminal.
15. The method of enabling communicating of claim 14 further including a step of storing said registration status information on the UIM.
16. The method of enabling communicating of claim 14 further including a step of said first terminal interrogating said UIM to determine a current registration profile or a network ID.
17. The method of enabling communicating of claim 14 further including a step of said first terminal interrogating said first network to determine a current registration profile or a network ID.
18. A method of enabling communicating substantially as hereinbefore described with reference to the accompanying drawings.
19. A method of operating a communication network adapted to communicate with a terminal, said method comprising the steps of: determining whether a UIM is present in a terminal; setting a first state for said network if said UIM is present; and setting a second state for said network if said UIM is not present.
20. A method of deregistering a first terminal from a first network by a second terminal in a second network, said method comprising the steps of: receiving a request from said second terminal; detecting whether said first network is accessible; accessing said first network; and transmitting a deregistration request from said second network to said first network.
21. The method of deregistering a terminal of claim 20 further including a step of receiving a deregistration confirmation at said second network.
22. The method of deregistering a terminal of claim 20 further including a step of informing a UIM network of said deregistration confirmation.
23. The method of deregistering a terminal of claim 20 further including a step of informing a UIM terminal of said deregistration confirmation.
24. A method of deregistering a terminal of claim 23 further including a step of informing said second terminal of said deregistration confirmation.
25. A method of deregistering a terminal of claim 20 further including a request from said first network to extend service.
26. A method of deregistering a terminal of claim 25 further including a step of receiving at said second network a response from said first network.
27. A method of deregistering a terminal of claim 26 further including a step of sending a message to said second terminal.
28. A method of deregistering a terminal of claim 20 wherein said step of transmitting a deregistration request comprises transmitting a deregistration request when a deregistration timer has expired.
29. A method of deregistering a terminal of claim 20 wherein said step of transmitting a deregistration request comprises transmitting a deregistration request when an invocation timer has expired.
30. A method of deregistering a terminal of claim 20 wherein said step of transmitting a deregistration request comprises transmitting a deregistration request when an enquiry timer has expired.
31. The method of enabling communicating of claim 20 further including a step of said terminal interrogating said UIM to determine a current registration profile or a network ID.
32. The method of enabling communicating of claim 20 further including a step of said terminal interrogating said first network to determine a current registration profile or a network ID.
33. A method of deregistering substantially as hereinbefore described with reference to the accompanying drawings.
34. An apparatus for communicating with a plurality of networks in a communication system, said apparatus comprising: a reader for receiving a UIM; a memory coupled to said reader for receiving registration information for accessing a plurality of networks; at least one transceiver coupled to said memory for accessing said plurality of networks; and a service control selector for controlling the registration to said plurality of networks.
35. An apparatus substantially as hereinbefore described with reference to the accompanying drawings.