WO2005112479A1 - Method for implementing a telephone switchboard service - Google Patents

Abstract

The publication discloses a method for implementing a telephone switchboard service. The method utilizes a telephone intelligent network (1, 2), an operator system (4, 5, 6) and an external server system (3), which is connected to the telephone intelligent network (1, 2) and the operator system (4, 5, 6). In the method, the telephone intelligent network (1, 2) gives each call coming to the service a call identifier and forwards both the call and the call identifier to the operator system (4, 5, 6). In the operator system (4, 5, 6), a suitable extension of the telephone switchboard service is selected for the call. The selected extension and the call identifier given to the call from the operator system (4, 5, 6) are notified to the external server system (3). The call is returned to the control of the telephone intelligent network (1, 2), in which case the telephone intelligent network (1, 2) requests the server system (3) for a new destination number for the call individuated with the aid of the call identifier. Finally, the call is routed to the destination number stated by the external server system (3).

Description

METHOD FOR IMPLEMENTING A TELEPHONE SWITCHBOARD SERVICE

The present invention relates to a method, according to the preamble of Claim 1, for implementing a telephone switchboard service.

The nature of the work of a telephone switchboard operator has changed in recent years, when many new communications devices for company employees have appeared, which must be able to be taken into account in the operator's work. Calls and messages must be able to be sent to the user of the most diverse devices. Not only to switchboard-connected phones, but also to mobile telephones, VoIP telephones, smart phones, PDA devices, computers, and other similar devices. In addition to connecting calls, the operator sends the destinations text messages, e-mail messages, leaves voice-mail call requests, etc. The nature of people's work too has changed so that the boundary between work and leisure time is often flexible. A person may even do work in the middle of leisure time. On the other hand, there can also be moments, when it is not wished to receive work calls under any circumstances, unless they are particularly important. All of this brings additional challenges to the operator's activities and also to those developing switchboard systems. Checking all of the information on the desired destination is laborious and time- consuming. On the other hand, an operator in a large company may take hundreds of calls each day, so that the time for processing a single call should be minimized.

Finnish patent number 110910 discloses a method, in which, in association with connecting a call, the operator's user interface is supplied with the previous history of the connection of the call. This avoids, for instance, a situation, in which the operator attempts to connect a call to a number, where the call has already been rung before it was transferred to the operator. In addition, the patent discloses at a schematic level how state data (free, busy, cannot be contacted) can be supplied in association with connecting the call. However, there is also a need to transmit state data in cases in which the call comes to the operator for the first time, so that case the system disclosed in the patent for collecting event data cannot be utilized directly.

Finnish patent number 109 751 in turn discloses the use of state data in the automatic routing of a call to a free customer-service agent (control logic in the SCP of an intelligent network). The provision of state data is based on the SCP commanding the MSC to monitor the states of the connections connected to the service. The SCP monitors (according to the data received from the MSC) the stages of the connections and commands the MSC accordingly to connect the call to queuing or forward it to a free subscription. This solution can be exploited when routing incoming calls to the call number to a free operator. On the other hand, the solution is not, as such, very suitable for use in a switchboard system when forwarding calls, which come to the operator.

Data on a person's current state can be retrieved to the operator's workstation (and display) from numerous different sources; not only from the switchboard's info system, but also, for example, from calendars and the network's Presence servers. Data can be updated to a Presence server from different sources automatically or manually by the operator (e.g., in connection of the selection of a profile from the telephone). The updating and use of the data of a Presence server in the automatic routing of calls is disclosed in US patent application publication number 2002/0085701A1.

One very important functionality when an operator connects calls is queuing to a busy connection. A problem in existing queuing solutions is, however, how to send information of a queued call to the destination. Generally the person speaking on the phone is informed of an incoming call only with the aid of the GSM call- waiting function. Call- waiting only offers, however, queuing of about one minute, which is generally insufficient.

In addition to the connection of queued calls by the operator, queuing must also be implemented between extensions. From the point of view of the caller, queuings between extensions can be roughly divided into two types. One is so-called receiver-up queuing, which can be similar to queuing connected by the operator, in which the call terminates in the busy situation automatically, or in a queuing service selected by the caller. Several known methods exist for implementing queuing of this kind. These do not, however, disclose how information on the queuing is sent to the destination, as the queuing service is not a functionality of the switchboard. In the call- waiting functionality according to the GSM standards, notification is received of an incoming call, but call- waiting only offers very short queuing, when longer queuing is often needed.

A second type of queuing is so-called receiver-down queuing, in which the caller activates the queuing service. In switchboards, this is typically implemented in such a way that, when the telephone is busy, the caller keys in the number 5 from the telephone, when the phone sends a command using DTMF (dual-tone multifrequency) code to the switchboard to initiate the queuing service, and then puts down the receiver. The switchboard checks when both connections are free and then gives the queued caller a ring tone (the phone rings intermittently), so that if the queued caller lifts the receiver, the switchboard connects the call from the caller to the destination. A corresponding 'receiver-down queuing' functionality is not defined in the GSM standards. Finnish patent number 109 751 discloses so-called receiver-up queuing, which cannot be applied as such to so-called receiver-down queuing, in which the state data of both connections (the caller and the destination) should be momtored and information on the connection of the queued call sent to the queued caller.

When connecting a call in a network through several servers, there is a need to transfer an identifying individual identifier along with the call, by means of which the call can be distinguished from the other calls being transmitted through the same system. The A- subscriber number cannot be used as such an identifier in all cases, because several simultaneous calls can have the same A-subscriber number. For example, in some corporate switchboards outgoing calls from the switchboard always have the operator's call number as the A-subscriber number. There are several known methods for creating a call identifier, for example, in the A-subscriber or B-subscriber fields in the signalling.

The problem in these methods is that, if the identifier is used to replace, for example, the original A-subscriber number, this important information is lost. If, on the other hand, the identifier is added after the A-subscriber number, the number series will easily become so long that all systems, (for example, certain switchboards) will not be able to process it.

The invention is intended to create a telephone switchboard service, which is efficient and safe from the point of view of an telephone intelligent network, and which, on the other hand, permits comprehensive and flexible services to be provided as additional properties to customers of the telephone switchboard service.

The invention is based on the telephone switchboard service being implemented in an external server system, which operates jointly with the telephone intelligent network and operator system. In the method, the telephone intelligent network gives each incoming call to the switchboard service an individual call identifier and forwards the call and the call identifier to the operator system. In the operator system, a suitable extension of the switchboard service is selected for the call and after this the selected extension is notified to the external server system. At the same time, the call identifier given to the call is also notified, on the basis of which the extension and the call can be associated with each other. The call is returned to the control of the telephone intelligent network typically by cutting off the call from the operator system. The telephone intelligent network then requests a new destination number from the external server system and routes the call to the destination number stated by the external server system.

More specifically, the method according to the invention is characterized by what is stated in the characterizing portion of Claim 1.

Considerable advantages are gained with the aid of the invention. With the aid of the invention it is possible to create a telephone switchboard service, which is efficient and safe from the point of view of the telephone intelligent network and which, on the other hand, permits comprehensive and flexible additional services to be provided for customers of the telephone switchboard service. This is based on the fact that most of the operations required by the service are implemented in an external server system, which is, however, linked to the telephone intelligent network to efficiently connect calls with the aid of the functionality of the telephone intelligent network.

The invention also has many preferred embodiments providing additional advantages.

By means of preferred embodiments of the invention, a call can be individually identified in all systems without losing any essential call data (calling party number, destination number etc.). In spite of this, the number fields will not grow too long.

In some embodiments, it is possible, for example, to combine data obtained from different sources, to form state data that are important precisely in the operator's work. The state of the destination can be shown in a graphically illustrated form, for example, using traffic- light symbols, from which the operator can see quickly the first conclusion about the state of the destination. Additional data can be grouped suitably in the additional information fields, which the operator uses as required at the time. This optimizes the operator's use of time for each call and thus also improves the customer service. In addition to this, in the preferred embodiments, better ways than in the previously known solutions are disclosed for implementing the retrieval of connection/telephone-state data into the switching systems and more highly developed queuing services to busy connections.

In some embodiments, the telephone operator can be provided with useful information on the desired destination in illustrative form, on the basis of which the operator can rapidly decided how well and when the destination can be expected to be contacted. With the aid of such embodiments, the operator can rapidly connect a call to the queuing service, independently of the type of subscription of the destination. The destination telephone can be,_. for example, a fixed telephone, a VoIP telephone, or a mobile station. The queuing service adapts the network's different technical elements, in which the user's subscription or telephone is situated, to each other.

With the aid of some embodiments, it is also possible to solve making a connection to a busy extension and creating a queuing service between the extensions of a corporate switchboard, in a more user-friendly and technology-independent manner. The preferred embodiments will significantly facilitate implementing a wireless switchboard service, in such a way that different kinds of terminal devices can be connected to the service.

By using the methods of some embodiments, queuing can be made to a busy extension for a desired length of time and, in addition, inform the terminal device of the destination subscription of the incoming call.

With the aid of some embodiments, it is also possible to convert, sort, and combine data retrieved from different systems to form the values of specified parameters in the network's databases and to retrieve the data to the switching system and to combine the parameters and values of the switching system to form predefined symbols, for example, traffic-lights, which are shown in the operator's interface with role information, as well as the entry of other values into the additional information field.

With the aid of some embodiments, it is possible to implement timed queuing (or 'booked call connection'), in which not only the data of the caller and the destination are monitored, but also profile/presence data, from which a decision is formed on the connection of the 'queued' call. Data on a call coming for queuing and of the connection of a queued call when the destination becomes free can be transferred with the aid of, for example, UUS, SMS, USSD, SIP, or MMS messages.

Further, in some embodiments, GSM call-transfer blocking can be implemented (e.g., busy, not-in-network state, by setting the signalling parameter 'transfer calculator' value to its maximum value in the operator system, the queuing server, SCP, SIP proxy, VoIP gateway, or other applicable element.

In the following, the invention is examined with the aid of examples and with reference to the accompanying drawings.

Figure 1 shows the operation of one method according to the invention in one possible system environment.

Figure 2 shows the operation of a second method according to the invention in a second possible system environment.

Figure 3 shows the operation of a third method according to the invention in a third possible system environment.

Figure 4 shows the operation of a fourth method according to the invention in a fourth possible system environment.

Figure 5 shows the operation of a fifth method according to the invention in a fifth possible system environment.

Figure 6 shows the implementation of queuing in one embodiment.

Figure 7 shows the implementation of queuing in a second embodiment.

Figure 8 shows the implementation of queuing in a third embodiment. Figure 9 shows the implementation of queuing in a fourth embodiment.

Figure 10 shows the implementation of queuing in a fifth embodiment.

Figures 1 - 5 show some possible system environments, in which the invention can be used. The figures show the network elements SCP 1 and SSP 2 that belong to a telephone intelligent network. In the embodiments of the figures, the initiation of the system requires very few definitions to be made to the telephone intelligent network, nor is there usually any need during the use of the operator system either for updates to be made in the basic elements of the telephone intelligent network.

The systems of the figures also include a server system 3, in which the routing of calls and the management of services is implemented. The server system includes software, which in turn includes several services. Connected to it, there is also a database, which is not shown in the figures. In the example, the sever system 3 includes the following service logics:

S = SCP interface

TP = State-data service

M = Switching-system interface

J = queuing service

V = Switching-system application (in companies, which have their own operators, the switching system is in the server system, from which there is in turn a www-interface for the operators).

From time to time, a call can be connected from the queuing service to an IVR application, which is not shown here. The IVR can discuss with the caller whether, for example, it is wished to continue queuing, or if the call should be connected to voice mail or to the operator. The exploitation of an IVR application is disclosed in greater detail in Finnish patent number 108 981. The methods disclosed in the patent can also be applied in connection with the present invention.

The server system 3 is an external server system. The term 'external server system' refers to the fact that the server system 3 does not belong to the basic elements of the intelligent network. The server system 3 does, however, have a telecommunications link to the SCP 1, through the SCP interface S. Physically, the server system 3 can operate in one or more computers.

The figures also show an operator system service 6, which provides the telephone operator (person) with a physical and user interface with the operator system. In the embodiments of some figures, both the telephone switchboard 4 and the concentrator 5 of the customer company can also be regarded as belonging to the operator system.

In some figures, the home register (HLR) 7 of the mobile station network is also shown, which can be exploited in the control of mobile-station subscriptions and in analysing the state and location.

The telephone switchboard service system shown in the figures may have extension connections operating under several switching centres. The extensions can be, for example, fixed subscriptions, corporate switchboard extensions, or mobile station subscriptions.

The example of Figure 1 shows one embodiment, in which switchboard operations are outsourced and in which the call is connected to an extension of the switchboard and a switchboard-specific call identifier is utilized when connecting. This is a question of transferring the call to an extension of the customer's switchboard, through an operator system. In the various elements, the call is identified by a company-specific/switchboard- specific/call-number-specific identifier GGGG and by an associated call-specific identifier HH. According to the example, the following operations are then performed:

11) An incoming call to the company's call number is received with the aid of a telephone intelligent network and the SCP issues from its own data a physical routing number of the network corresponding to the call number XXXX (the front part of the so-called direct dialling number, e.g., 358093960) and after it a call- identifier OHH (corresponding to the operator call or extension number). The front part of the routing number (e.g., 358093960) is deleted in the switching centre, when the call is routed to the customer's switchboard. HH is the call identifier selected by the SCP for calls routed to the destination switchboard in question. In front of it some prefix, e.g., 0 is added. The A number is ZZZZ, in which ZZZZ is the caller's real number. The intelligent network knows internally the customer identifier GGGG of the relevant customer switchboard (e.g., in the customer- specific data of an external database of the SCP or one connected to it).

12) The SCP routes the call to the number of the customer switchboard.

13) The customer switchboard routes the call directly to the concentrator, because in this embodiment the customer switchboard is programmed to route all incoming calls starting with this 0-decade to the switchboard in this manner. The customer switchboard, however, adds the customer identifier GGGG in front of the caller's number, in which case the number, i.e. the A-subscriber identifier, becomes GGGGZZZZ. The number dialled does not change. Service identifier=DNI=0HH.

14) Operator calls are created in the concentrator for all HH numbers, so that according to its own logic it searches for a free operator corresponding to the GGGG identifier (controlled by the operator system) and routes to call to them. Information of the customer identifier (GGGG) and the call identifier (HH) are forwarded through the concentrator to the agent of the switching system. The operator is shown, on the basis of the GGGG identifier, the number of the company to which the call has come (so they will be able to answer correctly).

15) The operator connects the call to a free extension of the customer switchboard and the extension answers the call. The customer identifier GGGG and the extension number are used as the routing data.

16) The software of the switching system makes an HTTP request to the sever system, in which the following data are set: call identifier (which now consists of the customer identifier GGGG + the identifier HH transmitted by the intelligent network) GGGGHH, as well as the information that the call has been connected within the customer switchboard and that call-routing/monitoring can be terminated. The voice channel from the customer switchboard to the concentrator is released. The original A-subscriber is shown as the caller's number.

17) The operator system releases the call (normal release cause code). The SCP requests the server system for a new destination number. In the request, the SCP gives the call identifier GGGGHH (which now consists of the customer identifier GGGG + and identifier HH given by the intelligent network). In the request, the SCP gives the number to which the call was last routed, and the release cause of the previous call, if this is known. The server system responds with the information that the call can be released (no further routing and monitoring can be terminated). The SCP releases the call.

With the aid of the embodiment described above, queuing to extensions can incorporate switchboard properties (i.e. queuing takes place in the customer switchboard). The embodiment also permits the operator to see the state data of the extension prior to routing. In addition, the call's A-number is transmitted to the extensions quite normally.

The example of Figure 2 shows one embodiment, in which telephone operations are outsourced and in which a call is connected to a mobile extension, i.e. to a mobile station. When making the connection, a switchboard-specific call identifier (GGGG+HH) is utilized. This example is a matter of transferring the call through the operator to a queue and from there to a mobile extension. According to the example, the following operations are then performed:

21) The SCP receives the call and gives from its own data the physical routing number (e.g., 358093960) of the customer number corresponding to the call number XXXX and, added to the end of this, a call identifier 0HH. The front part of the routing number (e.g., 358093960) is deleted in the switching centre, when the call is routed to the customer's switchboard. HH is an individual call identifier selected by the SCP for calls to be routed to the relevant destination switchboard. The A-number is ZZZZ, in which ZZZZ is the caller's real number. The intelligent network knows internally, what the customer identifier GGGG of the relevant customer switchboard is.

22) The SCP routes the call to the number of the customer switchboard.

23) The customer switchboard routes the call directly to the concentrator (all starting with the 0-decade), i.e. the caller's number becomes GGGGZZZZ. The number dialled does not change. CallID=DNI=0HH.

24) In the concentrator, operator calls are created for all numbers HH, in which case, according to its own logic it searches for a free operator on the basis of the GGGG identifier (routed by the switching system) and routes the call to them. Information on the customer identifier and the calllD is transmitted through the concentrator to the agent of the switching system.

25) The switching system sends a state-data request through the server system to the HLR and receives information as to which connection is free and makes the call transfer from the interface to the mobile extension. The switchboard software makes an HTTP request to the sever system, which sets the following number data: subscription number, to which the call is connected (Y YYY), call identifier GGGGHH, type of subscription (so that the server system will known whether it can queue to the subscription, and how a subscription-state request is performed).

26) The operator system releases the call (normal release reason). The SCP requests the server system for a new destination number. In the request, the SCP gives the call identifier GGGGHH. The server system gives to the SCP as the routing number the number YYYY of the mobile subscription, and information as to whether call transfers are blocked/permitted.

The next stage is divided into several possible cases: - if the mobile subscription is free, the SCP routes the call to the destination. As the A- number, the SCP sets ZZZZ, in which ZZZZ is the real number of the caller. -> 27)

- if the mobile subscription has become busy in the meantime, the operations follow the settings of the subscription. In the example, the alternatives according to the settings are as follows:

A) The subscription does not have call-waiting activated, busy-transfer is activated, but the SCP has received information that transfers are blocked. The call returns to the SCP, which requests the server system to inform it to where the call with the calllD GGGGHH should be routed, when the server system routes the call to the queuing service, by returning the number: DDDDYYYYGGGGHH. The SCP routes the call to the server system. The number selected is DDDDYYYYGGGGHH, in which DDDD is a 4-digit prefix configured to the sever system/SCP/SSP, from which the server system recognizes the call as a queued call to an extension of the switchboard system. YYYY states the extension of the switchboard system which is being queued for and GGGGHH is the call identifier. The SCP sets ZZZZ as the A-number, in which ZZZZ is the caller's real number. -> 28)

B) The subscription does not have call-waiting activated and busy transfer activated, but the SCP has received information that transfers are permitted. The call is routed according to the transfers. In the answered state monitoring is terminated and the calllD is released; in other situations the call is routed back to the operator. -> 27)

C) The subscription has call-waiting activated and busy transfer activated, but the SCP has received information that transfers are blocked. If the call is not answered before the end of the call-waiting time, the call returns to the SCP, which requests the server system to state the number to which the call with the calllD GGGGHH should be routed. The server system then routes the call to the queuing service by returning the number DDDDYYYYGGGGHH (described in greater detail in section A). -> 28) D) The subscription has call-waiting activated and busy transfer is also activated, but the SCP has received information that transfers are permitted. If the call is not answered before the call-waiting time ends, the call is routed according to the transfers. -> 27). In the answered state, monitoring is terminated and the calllD is released, in other situations the call is routed back to the operator.

29) Once the switchboard system connection becomes free (and the queued call is the first in the queue), the queuing service releases the call (normal release cause). The SCP requests the number from the server system. In the request, the SCP gives the call's identifier GGGGHH, the number to which the call was last routed, and the reason for the release of the previous call, if this is known. The server system responds with the extension number YYYY of the switchboard system and states that this call is a call to an extension.

30) The SCP routes the call to the mobile subscription YYYY. As the A-number, the recipient is shown ZZZZ. On the basis of this, the SCP knows to terminate monitoring of the number and to release the calllD.

With the aid of the embodiment described above, it is possible to queue to mobile subscriptions, in the same way as to switchboard extensions. The embodiment also permits the operator to see the state of a mobile subscription of the switchboard prior to connecting. In addition, the A-number is correctly transmitted to the mobile subscription.

The example of Figure 3 shows one embodiment, in which the call is connected to an extension of the customer's switchboard and a customer-specific call identifier is used in the connecting. The question is of the transfer of a call to the extension of the customer's switchboard through a www-operator. In this case, the operator system is software in the server system, from which there is a www-interface for the operator. According to the example, the following operations are then performed:

31) The SCP routes the call to the server system. The dialled number (DNI i.e. B- number) is FFFFGGGGHH, in which FFFF is a 4-digit prefix configured to the SCP, from which the server system identifies the call as an operator-service call, and HH is a call identifier (varying component) generated by the SCP. GGGG is the company's identifier (fixed component of the ID). An additional routing number, e.g., 358091234, which is deleted in the switching centre once the call has been routed to the server system, can be used in front of the dialled number. The A-number is ZZZZ, in which ZZZZ is the real A-number of the caller. The server system retains the identifier for later use.

32) The server system searches for a free operator (mobile subscription, fixed extension, or switchboard extension). The operator associated with the call number, who has been free longest, is sought and the state of the mobile operator is checked by a state query prior to calling (the query is made, for example, to the HLR).

33) The server system makes a new call to the operator (from the server system). The operator's number CCCC and the A-number are transmitted as the number data of the call. The operator system is informed of the call identifier with the aid of the internal operations of the server system.

34) The operator makes a request to the server system, in which the operator requests a check of the state of the customer switchboard extension using a 'state query', which can be made from the server system to the switchboard in several alternatives ways.

35) The server system makes the 'state query' by calling the switchboard. Alternatively the server system sends a state-data query to the switchboard, through the CTI interface. The operator receives information on the state of the extension on their display and is informed that the extension is free.

36) From the interface, the operator makes a call transfer to the extension (state free). The operator software makes a request, which sets the number data for the server system's database service: switchboard extension number, to which the call is to be connected (YYYY, in international form), call identifier GGGGHH, and the types of the extension. 37) The server system releases the call (normal release cause). The SCP requests the server system for a new number. In the request, the SCP gives the call's identifier GGGGHH, the number to which the call was last routed, and the release cause of the previous call, if this is know. The server system responds with the number YYYY, call-transfer block data, and gives the information that this call is a call to an extension.

38) The SCP routes the call to the extension YYYY (which answers). The A-number is shown to the recipient as ZZZZ. The SCP terminates monitoring and informs the server system that the calllD can be deleted.

The example of Figure 4 shows one embodiment, in which telephone operations are outsourced and in which a call is connected to a queue and from the queue forwarded to a mobile subscription, i.e. to a mobile station. The connection exploits a switchboard- specific call identifier. In this example, the question is of the transfer of a call through the operator to a queue and from there to a mobile subscription. According to the example, the following operations are then performed:

51) From its own data, the SCP gives the network's physical routing number corresponding to the call number XXXX (the so-called prefix of the direct dialling number, e.g., 358093960), followed by a call identifier 0HH (corresponding to an operator call or extension number). The prefix (e.g., 358093960) is deleted in the switching centre, when the call is routed to the customer's switchboard. HH is an individual call identifier selected by the SCP for calls routed to the destination switchboard in question. Some prefix, e.g., 0 is attached in front of it. The A- number is ZZZZ, in which ZZZZ is the caller's real number.

52) The customer switchboard routes the call directly to the concentrator (all calls beginning with the 0-decade) and add the customer identifier GGGG in front of the caller's number. The caller's number then becomes GGGGZZZZ. The dialled number does not change. CallID=DNI=0HH. 53) In the concentrator, operator calls are created for the number HH, from which, according to its own logic, (directed by the operator system) it searches for a free operator corresponding to the GGGG identifier and routes the call to them. Information of the customer identifier and the calllD is transmitted through the concentrator to the agent.

54) The switching system makes a state query and is informed that the extension is busy. The operator also sees from the display of the operator software that the recipient already has a queue (in the server system) and makes, from the interface, a call transfer to the queue. The operator software makes an HTTP request to the server system, in which the following number data are set: extension number to which queuing is taking place (YYYY), call identifier GGGGHH, type of extension (so that the server system can queue to the extension and how an extension state query is made).

55) The operator system releases the call (normal release cause). The SCP requests a new number from the server system. In the request, the SCP gives the call's identifier GGGGHH, the number to which the call was last routed, and the release cause of the previous call (if this is known). The server system responds with the number DDDDYYYY, call-transfer block information, and informs that this call is not a call to an extension (the queuing service answers, but monitoring is not terminated).

56) The SCP routes the call to the server system. The dialled number is DDDDYYYYGGGGHH, in which DDDD is the 4-digit prefix configured to the server system SCP/SSP, from which the server system identifies the call as a queued call to an extension of the system. YYYY states the extension of system to which the call is queued, and GGGGHH is the call identifier. The SCP sets ZZZZ as the A-number, in which ZZZZ is the caller's real number.

57) The queuing service makes state-data queries at specific intervals until the extension has become free, the A-subscriber has broken off the call (connection released), or the maximum queuing time is reached (in which case notification is given and the connected released, or the call is routed back to the operator, or to the IVR menu).

58) Once the extension has become free (and the queued call is the first in the queue), the queuing service releases the call (normal release cause). The SCP requests the number from the server system. In the request, the SCP gives the call identifier GGGGHH, the number to which the call was last routed, and the cause of the release of the previous call, if this is known. The server system responds with the extension number YYYY, call-transfer block information, and states that this call is a call to an extension. On the basis of this, the SCP knows, when it receives the answer indication, to terminate monitoring of the number and to release the calllD.

59) The call is routed to the recipient YYYY. The recipient is shown ZZZZ as the A- number. When the destination answers, the SCP terminates monitoring and informs the server system that the calllD can be deleted.

With the aid of the embodiment of Figure 4, queuing can take place to mobile subscriptions in the same way as to switchboard extensions. The embodiment also permits the operator to see the state data of a mobile subscription of the switchboard, prior to connecting. In addition, the call's A-number is correctly transmitted to mobile subscriptions.

The example of Figure 5 shows one embodiment using www-switchboard services, in which a call is connected to a queue and then from the queue to a mobile subscription, i.e. to a mobile station.

61) The SCP routes the call to the server system. The dialled number (DNI, i.e. B- number) is FFFFGGGGHH, in which FFFF is a 4-digit prefix configured to the SCP, from which the server system identifies the call as a switchboard services call and HH is a call identifier (varying component) generated by the SCP. GGGG is the company's identifier (fixed component of the ID). An additional routing number, e.g., 358091234, can be used in front of the dialled number, and is deleted in the switching centre when the call is routed to the server system. The A- number is ZZZZ, in which ZZZZ is the caller's real A-number. The server system retains the identifier for later use.

62) The server system searches for a free operator (mobile/fixed/switchboard extension). The operator associated with the call number, who has been free longest, is sought and the state of the mobile operator is checked prior to calling using a state query (HLR).

63) The server system makes a new call to the operator. The operator's number CCCC and the A-number ZZZZ are transmitted as the number data of the call. The operator software is informed of the call identifier with the aid of the internal operations of the server system.

64) The server system makes a 'state query' . The operator is shown the state of the mobile subscription on their display. For example, the operator is informed that the subscription is free.

65) From the interface, the operator makes a call transfer to the extension (state free). The operator software makes a request, in which the number data are set for the database service of the sever system: extension number to which routing is to take place (YYYY, in international form), call identifier GGGGHH, and the type of the extension.

66) The server system releases the call (normal release cause). The SCP requests the server system for a new number. In the request, the SCP gives the call identifier GGGGHH, the number to which the call was last routed, and the release cause of the previous call, if this is known. The server system responds with the number YYYY, call-transfer block information, and gives the information that the call is a call to an extension.

67) The call is routed to the recipient YYYY (who answers). The recipient is shown ZZZZ as the A-number. 68) The SCP terminates monitoring and tells the server system that the calllD can be deleted.

In the examples described above, the call identifier is intended as an identifier, by means of which the call is identified as the same call in the control system throughout the entire life of the call. The call identifier can include, for example, the numbers 0 - 9. The SCP generates the call identifier, when it routes a new call to the server system or to the operator system. The SCP also ensures that the identifiers are individual. The call identifier can consist of, e.g., a switchboard-specific or call-number-specific (fixed) component GGGG and an individual call-specific (varying) component (HH) for this. In this case, when the switchboard-specific component is known in different elements (SCP, operator system including the switching centres), it is then sufficient if the call-specific varying component (HH) is transported with the call, in which case the processing of the calls/numbers in the network elements will be facilitated (made possible). In some environments, the call identifier can also consist of three components: fixed company identifier (KKKK), fixed switchboard/call-number identifier (GG), and a varying call identifier (HH).

If the network connections, switching centres, and switching systems used permit the cost-effective transmission of longer number series with the call and their processing, the call identifier can also be processed as a single sufficiently long number space, which is common to all customers connected to the system (each call will still have its own individual identifier). E.g., a six-digit call identifier cccccc (c = any number 0 - 9).

The invention also has embodiments, in which additional properties are attached to the call identifier. For example, in an intelligent network there can be information, according to which the call number, e.g., 01012345, is converted into a technical call number, which will be routed to the correct number of the customer switchboard, e.g., the number 0912345.

Logic can also be built into the intelligent network, in such a way that, when the server system requests it to route a call to an extension, the intelligent network pays not attention to the call identifier in the call in question, but if the call is routed back to the original call number, it acts in the same way as in a case in which the call is a new incoming call to the system, i.e. the ID should be added using the same principle. If, however, the server system requests a call to be routed to other than an extension or back to the call number (i.e. to the server system to the queue server), the intelligent network should always add a complete call identifier to the dialled number, even though the call had come to an operator system that paid no attention to anything except the varying component of the call identifier.

The call identifier can also be exploited in monitoring the history data of calls. Operations carried out during the call (e.g., connection attempt to an extension) can also be stored in connection with each event in a (external server system's, switching system's, or SCP's) database, from where it can be retrieved at a later stage, e.g., to the switching system, and displayed to the operator. For example, if the call is routed to an operator system, the switching system checks from its own database, or requests the server system for the call's earlier routing data. If routing data is found for an incoming call (for the calllD), it can be displayed to the operator, e.g., the call has been connected to an extension (from where it has returned to the operator in a 'no answer' case). The routing data can also be converged (e.g., in the switching system) to the operator in a more illustrative form (e.g., call returning from extension 1234).

In the examples, the Web operator is connected to the switching system using a web- browser-based interface. The telephone subscription of the Web operator can be, for example, a subscription of a mobile or fixed network.

The switchboard can also be a VoIP switchboard, in which case the calls travel through a gateway. A state-data query can then be made through a corresponding data connection, or retrieved from a presence sever, in which the data are updated.

Instead of the HLR, the state data can also be requested, for example, from the Presence server of the IP network (in which the state data of different devices can be updated: GSM, UMTS, VoIP telephone, VoIP softphone, etc.). A great many additional properties can be created in a telephone switchboard service by modifying the examples described above. Several advantageous additional functionalities can be implemented, for example, in the manner described below in a system, which includes an operator-system interface and software, a queuing/state-data server and IVR service connected to it, located in the network, and a state-databank. These are linked to various systems: a call-switching element (e.g., SSP), a call-routing database (e.g., SCP), a switching element (e.g., switchboard), switchboard, VoIP switchboard, wireless network register (e.g., HLR), Presence server, calendar service (e.g., Outlook), and an information system (e.g., switchboard information). The queuing server and the operator's interface retrieve the state data of the destination from the state-database, whenever necessary. The data are updated to the state-database, either at intervals using batch runs, using a separately made request, or whenever information changes.

The following describes in greater detail the various elements and service functionalities in the aforementioned embodiment. Of course, the following elements and functionalities can also be used separately from each other, for example, in the systems according to Figures 1 - 5, or in other such systems, which provide suitable interfaces and other corresponding basic conditions for the operation of the elements and functionalities.

State-data server

A person's contactability data are continuously updated in the database of the state-data server of the network. There are various kinds of parameters in the database and additional data related to them. One parameter is, for example, the state data of a telephone, which can be, e.g., busy, free, in network, or not in network. Additional information to this can be, e.g., in which network, or in which country the telephone is connected (e.g., information is provided as to whether the destination is abroad). Another possible parameter is, e.g., a profile, the values of which can be, e.g., at work, in conference, at lunch, not at work, on leave, etc., or a role, e.g., extension or operator connection. Updating of state data in the state-data database

The state data of a GSM phone can be updated in at least two ways. In the first alternative, the SCP of the intelligent network (or some other similar call-routing database, such as the SIP proxy of an IP network) sends information to the state-data server, e.g., over an https connection, on every occasion when the state of the telephone changes, e.g., from busy to free. This requires that all calls of the subscription (in the case of an SCP, in the intelligent network) trigger. An alternative form of implementation is that the information is always retrieved when necessary as a query. For example, the queuing server requests state data from the HLR using a MAP/ATI query. In the busy case, when queuing, the query can be made, e.g., at one-second intervals. The information can also be updated by batch runs at specified times, or at specified intervals.

State data can be sent from calendar services to the state-data sever according to known methods, e.g., as batch runs (e.g., at 10-minute intervals), when the information changes, or at regular intervals, e.g., through an API interface.

State data can be retrieved from digital and VoIP telephone switchboards using the same kind of query through a TAPI/JTAPI interface, that is used by existing switching systems to retrieve them. In the method according to the invention, it need not be retrieved from the switchboard to the switching system, but instead to the state-data server of the concentrated network, to which corresponding state data are also retrieved from other networks. The switching system can then request the state data of all subscriptions from a single location.

Updates made by the used can be transferred from the info system as the same kind of batch-run updates as from the calendar service. Alternatively, a system can be built into the system, which also always transfers altered/new information to the state-data server of the network.

The state data of a GSM/UMTS telephone can also be retrieved from the Presence server. Contactability/profile information (e.g., conference, normal) selected from the user's terminal device can also be obtained from the Presence server. The data are transferred from the terminal device to the Presence server according to generally known methods, with the assistance of SDK, USIM, WAP and other similar technologies, using, e.g., SMS, USSD, OTA, GPRS and other similar connections as transfer links. If necessary, the information is converted into the form used by the application. For example, normal = at work, is the number is a work number and normal = not at work if the number is a so- called civil number etc. Alternatively, the profile menus of the Presence server can, in the case of a company, be directly made compatible with the menus used by the switchboard service, and the same menus used.

Operator's user interface

The values of the parameters of the network state-database can be combined in a more illustrative form to create so-called traffic lights. Specific values of the database are combined with specific traffic-light symbols, from which the operator can quickly decide the most important facts; in addition, additional data can be shown in the additional information field. An example of the combination of data is given below.

Green light: Connection free / in network in home country and role at work.

Yellow light: Connection busy / in network abroad / connection free and role at home.

Red light: Connection not in network / role on leave.

In the operator's user interface, in addition to the traffic lights, it is also possible, for example, to show role information in the adjacent field, for example, at work, conference, at home, etc. The more specific facts can be shown in the additional-information field.

Possible values of the role field can be, for example, busy, at work, conference, at lunch, at home, on leave.

Possible data of the additional-information field can be, for example, length of queue, when the conference/lunch will end, when the person will return to work, in which country the connection is in a network, state data of the civil number, etc. In such an embodiment, the operator can see, for example, directly from the green light that the call can be connected at once to the extension, so that the connection of the call is accelerated. From the yellow light, the operation can see that contactability should be checked. The operator then first of all looks to see what the role field says. If the role field says busy, the operator can ask the caller if they want to wait in the queue. If the caller wants to queue, the operator connects the call to the queue service. From the red light the operator sees that the object cannot answer the call, either at all, or, for example, only if the matter is particularly urgent. They can then check the state and additional information in the role field. For example, if the object's telephone is not in a network, but the same person's civil telephone is in a network and this connection is free, the operator can enquire how urgent the matter is and act accordingly. In the additional-information field, it can also possibly state the numbers from which calls originating should be connected in all cases. The information of this so-called screening list can be transferred, for example, from the info system, from the SCP/SIP proxy (e.g., from a contactability service), or from within the switching system in general.

Operator connects to queuing for a busy connection

If the caller wishes to queue for a busy connection, the operator connects the call to the network's queuing service. The sever sends notification of the queuing to the busy destination according to the selection of the user/company, or in a manner appropriate to the type of connection, for example, as a UUS/SMS/USSD message, as a SIP message, an MMS message, etc. This message can be linked to the tone in the telephone notifying of the arrival of a message (SDK/USIM/SIP application, etc.). After this, the server checks from time to time (e.g., at one-second intervals) the state of the connection from the state- database. Once the state is free, the queuing server connects the call to the destination.

After a set queuing time, the caller can be connected to a menu service, in which they can choose whether they want to continue queuing, or do something else, for example, transfer back to the operator, etc. The message can be left according to known methods, for example, using e-mail, SMS, MMS, as an SIP message, by connecting the call to the user's voice mail, etc. Call-transfer block

In certain situations, for example, in operator connected calls, it may be wished to prevent a call from ending up in voice mail, even though it could otherwise go there, if the user is not able to reply to it. In that case, the routing control of the call is retained by the server and it can route it according to its definitions, for example, if, in a busy situation, it is wished to return to the operator. The call can go to voice mail, for example, if GSM call- transfer is activated in a busy case to number xxx, or the telephone is not in the network and the not in network transfer to the number xxxx is activated. Call forwarding can be prevented by using standard ISUP signalling messages. The problem with this is that these are not yet in use in many networks. The problem can be solved by using existing signalling methods in a way differing from the normal. For example, in PSTN network calls, forwarding can be prevented by setting (e.g., by the SCP) an excitation class for the telephone. This is disclosed in Elisa's Finnish patent number 108 189.

In GSM-network calls, forwarding of a call can be prevented by setting the call calculator parameter of the ISUP signalling to the maximum value, in which case, according to the telecommunication network's definitions, the network may no longer transfer calls. The calculator can be set the maximum value, for example, in the switching system, in the queuing server, or in the intelligent network (SCP). Setting the transfer to the maximum value is not by itself sufficient to prevent call transfers in all cases in all PSTN networks, because the switching centre may be configured in such a way that, in the home- answering-device service, a call will be transferred despite the answering device's calculator value. For this reason, in the call both the calculator can be set to the maximum value and the call class to the excitation class, which will prevent transfers in both a GSM network and in a fixed network.

Queuing between extensions

So-called receiver-up queuing between extensions can be solved in the same way as in the operator connection case described above. In addition, another kind of queuing can be implemented, in which the user can close the call and also make other calls during queuing. In that case, the queuing server checks from time to time the state of both extensions, and when both are free, connects the calls immediately. The caller can be informed, for example, using a UUS/SMS USSD/MMS message, a SIP message, etc., that the call in question is a queued call to the number xxxx, when the call can be simultaneously connected to both extensions. The rapid connection prevents either from being able to take a new call in the meantime. If the transfer of the message is, for example, UUS, USSD, or GPRS-MMS/SD?, it will reach its destination sufficiently quickly and the user will see it possibly simultaneously, or even before the phone begins to ring. The call can also be first of all opened to the person setting it in the queue, when the IVR tells to which extension the queuing is activated and can, if necessary, request the caller to confirm the connection of the call.

Queuing between extensions is shown in greater detail in Figures 6 - 10, which are examined in greater detail in the following.

Figure 6 shows queuing in a busy state from a mobile-station subscription to a mobile- station subscription. In the example, the mobile-station subscription is a GSM subscription, but the principles hold correspondingly also when using other technologies. In the embodiment of Figure 6, the following operations are carried out:

71) The A-subscriber attempts to call from their mobile station to the mobile station of the B -subscriber, which is busy.

72) In the busy situation, the call is routed to the IVR as a functionality of the intelligent network (e.g., in contactability chain), or as a functionality of the GSM switching centre (call transfer in a busy case).

73) The IVR plays, for example, the following menu: press 5, if you want to queue; 6, if you want your call to be connected to voice mail; or wait, when your call will be connected to the operator. The A-subscriber selects queuing.

74) In the queuing case, the caller puts down the receiver (can receive other calls).

75) The IVR asks, for example, at two-second intervals, the HLR for state data on the B -subscriber's telephone (busy/free). The HLR notifies the state of the telephone.

76) Once the B-subscriber is free, the IVR asks the HLR for the state of the A- subscriber.

77) Once the A-subscriber is free, the IVR calls the A-subscriber. The user sees from the IVR's A-number that the caller is the IVR, and if the name: queued call is defined in the telephone's memory for the number in question, it is shown on the display.

78) In addition, the IVR calls the B-subscriber and set as the A-subscriber' s number the A-number of the A-subscriber, i.e. the queued caller.

79) Once both the A and B-subscribers have answered, the IVR requests the MSC to connect these two calls and itself drops out of the call. The MSC tickets the call, in which the original caller is marked as the A-subscriber and the bill can be targeted to the correct A-subscriber.

In the embodiments of Figure 6, it is also possible to implement echoing of the B-end call tone through the IVR to the A-subscriber, when the A-subscriber has answered.

Figure 7 shows queuing in a busy situation, from a mobile-station subscription to a VoIP subscription. In the embodiment of Figure 7, the following operations are carried out:

81) The A-subscriber tries to call from their mobile station to the B-subscriber's VoIP network telephone, which is busy.

82) In the busy situation, the call is routed to the IVR as a functionality of the intelligent network (e.g., in a contactability chain), or as a functionality of the GSM switching centre (call transfer in a busy case).

83) The IVR plays, for example, the following menu: press 5, if you want to queue; 6, if you want your call to be connected to voice mail; or wait, when your call will be connected to the operator. The A-subscriber selects queuing.

84) In the queuing situation, the caller puts down the receiver (can receive other calls in the meantime).

85) At, for example, two-second intervals, the IVR requests the state data (busy/free) of the B-subscriber's telephone from the SIP proxy (SIP signalling),or checks it using H323 signalling. The SIP proxy/xxx notifies the state of the telephone.

86) Once the B-subscriber is free, the IVR requests the HLR for the state of the A- subscriber.

87) Once the A-subscriber too is free, the IVR calls the A-subscriber. The A- subscriber sees from the A-number of the IVR that the caller is the IVR, and, if the name: queued call is defined in the telephone's memory, it will be shown on the display.

88) In addition, the IVR calls the B-subscriber and sets the A-number of the A- subscriber, i.e. the queued caller, as the A-subscriber number.

89) Once both the A and B-subscribers have answered, the IVR requests the MSC to connect both calls and itself drops out of the call. The MSC tickets the call, in which the original caller is marked as the A-subscriber and the bill can be targeted to the correct A-subscriber.

In the embodiment of Figure 7, it is also possible to implement echoing of the B-end call tone through the IVR to the A-subscriber, when the A-subscriber has answered.

Figure 8 shows queuing in a busy situation according to a first modification, from a mobile station subscription to a PSTN subscription, such as an extension of a company switchboard. In the embodiment of Figure 8, the following operations are performed:

91) The A-subscriber attempts to call, from their mobile station, the B-subscriber's PSTN-network telephone, which is busy.

92) In the busy situation, the call is routed to the IVR as a functionality of the intelligent network (e.g., in a contactability chain), or as a functionality of the GSM switching centre (call transfer in a busy case).

93) The IVR plays, for example, the following menu: press 5, if you want to queue; 6, if you want your call to be connected to voice mail; or wait, and your call will be connected to the operator. The A-subscriber selects queuing.

94) In the queuing situation, the caller puts down the receiver (can receive other calls in the meantime).

95) The IVR makes at, for example, five-second intervals, a short call attempt, by means of which it detects whether the B-subscriber is busy/free.

96) Once the call-clear tone comes from the B-subscriber's end (not-busy signal), the IVR terminates the call attempts and requests the HLR for the A-subscriber' s state data.

97) Once both subscribers are free, the IVR calls the A-subscriber. The user sees from the A-number of the IVR that the caller is the IVR, and, if the name: queued call is defined in the telephone's memory, it will be shown on the display.

98) In addition, the IVR calls the B-subscriber and sets the A-number of the A- subscriber, i.e. the queued caller, as the A-subscriber number.

99) Once both the A and B-subscribers have answered, the IVR requests the MSC to connect both calls and itself drops out of the call. The MSC tickets the call, in which the original caller is marked as the A-subscriber and the bill can be targeted to the correct A-subscriber.

In the embodiment of Figure 8, it is also possible to implement echoing of the B-end call tone through the IVR to the A-subscriber, when the A-subscriber has answered.

Figure 9 shows queuing in a busy situation according to a second modification, from a mobile station subscription to a PSTN subscription, such as an extension of a company switchboard. In the embodiment of Figure 9, the following operations are performed:

101) The A-subscriber attempts to call, from their mobile station, the B-subscriber's PSTN-network telephone, which is busy.

102) In the busy situation, the call is routed to the IVR as a functionality of the intelligent network (e.g., in a contactability chain), or as a functionality of the GSM switching centre (call transfer in a busy case).

103) The IVR plays, for example, the following menu: press 5, if you want to queue; 6, if you want your call to be connected to voice mail; or wait, and your call will be connected to the operator. The A-subscriber selects queuing.

104) In the queuing situation, the caller puts down the receiver (can receive other calls in the meantime).

105) The IVR makes at, for example, three-second intervals, a query to the HLR as to whether the A-subscriber is free.

106) If the A-subscriber is free, the IVR attempts to create a call to the B-suscriber. The IVR sets the A-number of the A-subscriber, i.e. the queued caller, as the A- number.

107) Once the call-clear tone comes from the B-subscriber's end, the IVR calls the A- subscriber. The user sees from the A-number of the IVR that the caller is the IVR, and, if the name: queued call is defined in the telephone's memory, it will be shown on the display.

108) Once both the A and B -subscribers have answered, the IVR requests the MSC to connect both calls and itself drops out of the call. The MSC tickets the call, in which the original caller is marked as the A-subscriber and the bill can be targeted to the correct A-subscriber.

In the embodiment of Figure 9, it is also possible to implement echoing of the B-end call tone through the IVR to the A-subscriber, when the A-subscriber has answered.

Figure 10 shows queuing in a busy situation according to a first modification, from a PSTN subscription to a mobile station subscription. In the embodiment of Figure 10, the following operations are performed:

111) The A-subscriber attempts to call, from their PSTN-network telephone, the B- subscriber's mobile station, which is busy.

112) In the busy situation, the call is routed to the IVR as a functionality of the intelligent network (e.g., in a contactability chain), or as a functionality of the GSM switching centre (call transfer in a busy case).

113) The IVR plays, for example, the following menu: press 5, if you want to queue; 6, if you want your call to be connected to voice mail; or wait, and your call will be connected to the operator. The A-subscriber selects queuing.

114) In the queuing situation, the caller puts down the receiver (can receive other calls in the meantime).

115) The IVR requests, for example, four-second intervals, the HLR for the state data (busy/free) of the telephone of the B-subscriber. The HLR notifies the telephone's state.

116) Once the B-subscriber is free, the IVR calls the A-subscriber. The user sees from the A-number of the IVR that the caller is the IVR, and, if the name: queued call is defined in the telephone's memory, it will be shown on the display. 117) Once the call-clear tone comes from the A-subscriber' s end, IVR calls the B- subscriber and sets the A-number of the A-subscriber, i.e. the queued caller, as the A-subscriber number.

118) Once both the A and B -subscribers have answered, the IVR requests the MSC to connect both calls and itself drops out of the call. The MSC tickets the call, in which the original caller is marked as the A-subscriber and the bill can be targeted to the correct A-subscriber.

In the embodiment of Figure 10, it is also possible to implement echoing of the B-end call tone through the IVR to the A-subscriber, when the A-subscriber has answered.

Timed queuing

Timed queuing acts as a modern replacement for a call-back request. In the service, it is possible to build an additional property to a contactability service, in which the caller is told the data of the state-data server, if the call cannot be answered. The call can be routed to the service's IVR-menu, for example, in a situation in which the recipient is 'not in network', or if the user does not answer. In the menu, the information on the destination given by the state-database is given (text-to-speech method, or ready-recorded possible choices corresponding to the parameters of the database). For example, the person is in a meeting and will be free after 2 p.m. As one alternative in the IVR-menu, the caller can then select the functionality 'call, once you are free' . The IVR then forwards the selection to the queuing server, which from time to time (e.g., at 1-minute intervals) retrieves the data: roles and state from the state-data server. When the role changes (e.g., at work) and the state is free, the queuing server checks the corresponding data for the caller who activated the functionality and, if these data are defined (e.g., at work, free) the server immediately calls both callers. The caller who activated is informed of the connection of the service in a manner corresponding to the queuing service.

Same phone in civil life

According to generally known methods, it is possible to utilize in the same telephone the so-called Dual SIM solution, in which, for example, in the same subscription there can be two numbers, one of which is, for example, used at work and the other in civil life. The A-subscriber number shown when calling depends on which SIM card has been selected. Correspondingly in billing work, calls are charged to the company and civil calls to the employee. The selection is made when the phone is switched on, when information is updated to the HLR (and possibly to the Presence server) according to which number has been selected for use. In a solution of this kind, the state data of the civil phone can also be transferred to the operator, in such a way that the switching system requests the state through the queuing server from the HLR, or from the Presence server. Incoming calls to the subscription of the person in question can then be routed according, for example, to a

'black&white' filtering list managed by the person themselves (permitting specific 'civil calls' to the work subscription and vice versa).

Forced release of a call and connection of an incoming call in its place

In some cases, it may be wished for the operator to be able to break off an existing call and connect a queued call in its place. In some switchboards this can be done optionally by the operator, when the call has an operator class (operator's extensions). If a corresponding functionality is desired for an extension of a wireless switchboard, it can be implemented in such a way that the SCP monitors the current call and at the same time asks the operator software whether it is wished to release the call by the operator operation. If it is wished, the SCP then releases the connection on the side of the A- subscriber of the call and connects the new desired call to the subscriber. In connection with the release, it is possible to play a desired message to the A and B subscribers, or to connect the operator to the call by creating a three-party conference, during which the operator can ask if it is wished to release the original call and receive the new call.

Possible alternative solutions and variations

The methods disclosed in the embodiments described above can be implemented in several different kinds of network. Even though in many of the examples the embodiments are illustrated by describing their operation using GSM-network connection and functionalities, as well as the functionalities of an intelligent network, corresponding mechanisms can, however, be implemented in connection with other technologies too, for example, in IP-networks, in which, for example, instead of/alongside the SCP there can be a SIP proxy, instead of/alongside the SSP there can be a router making IP-network connections, a switch, gatekeeper, etc.

The telephone can naturally be not only a switchboard telephone, a GSM telephone, a VoIP telephone, but also a computer application, a sip-telephone/application, a PAD device, a UMTS telephone, a WLAN telephone, etc. The examples of the disclosure emphasize methods typical of audio connections, but they can also be applied using multimedia connections.

Claims

Claims:

1. Method for implementing a telephone switchboard service, which method utilizes a telephone intelligent network (1, 2), an operator system (4, 5, 6) and an external server system (3) communicating with the telephone intelligent network (1, 2) and the operator system (4, 5, 6), characterized by

- the telephone intelligent network (1,2) giving each call coming to the service a call identifier and forwarding both the call and the call identifier to the operator system (4, 5,6),

- in the operator system (4, 5, 6), selecting a suitable extension of the telephone switchboard service for the call, and notifying the selected extension and the call identifier given to the call from the operator system (4, 5, 6) to the external server system (3),

- returning the call to the control of the telephone intelligent network (1, 2), in which case the telephone intelligent network (1, 2) requests the external server system (3) for a new destination number for the call individuated with the aid of the call identifier, and

- routing the call to the destination number stated by the external server system (3).

2. Method according to Claim 1, characterized in that

- the telephone intelligent network (1,2) monitors each call connector to the operator system (4, 5, 6) and

- the call is returned to the control of the telephone intelligent network (1, 2) by releasing the call from the operation of the operator system (4, 5, 6).

3. Method according to Claim lor2, characterized in that at least one of the extensions of the telephone switchboard service is a mobile-station extension.

4. Method according to any of Claims 1-3, characterized in that the telephone switchboard services has extension in both a mobile network and a fixed network and/or subordinate to at least one company switchboard (4).

5. Method according to any of Claims 1-4, characterized in that a call coming to the telephone switchboard service is targeted to a telephone number of a customer company of the telephone switchboard service and the call is given a call identifier, which consists of a fixed customer-specific component and a varying additional component.

6. Method according to any of Claims 1-5, characterized in that the call identifier is transmitted from the telephone intelligent network (1, 2) to the operator system (4, 5, 6) in the B-subscriber number field.

7. Method according to any of Claims 1-6, characterized in that the call identifier is selected in such a way that the first digit of the call identifier is a number, which in the coming telephone traffic will typically be free in all switching centres, so that the customer switchboard will be able to route the call forward to the concentrator of the switching system, on the basis of the first digit of the call identifier.

8. Method according to Claim 7, characterized in that the first digit of the call identifier is 0, which in a switchboard is generally the external line identifier and thus free in incoming traffic.

9. Method according to any of Claims 1-8, characterized in that the numbers of the call identifier are defined in the switchboard of the switching system as an operator call, which is routed in the switchboard to the operator.

10. Method according to any of Claims 1-9, characterized in that the numbers of the call identifier are defined in the switchboard of the switching system as extension numbers, from which forward routing to the operator is created.

11. Method according to any of Claims 1-10, characterized in that the numbers of the call identifier are defined in the switchboard of the switching system as series calls, from which forward routing to the operator is created.

12. Method according to any of Claims 1 - 11, characterized in that the numbers of the call identifier are defined in the switchboard of the switching system as other destination numbers, for example, as numbers of an LCR table, without a physical connection location, from which forward routing to the operator is created.

13. Method according to any of Claims 1 - 12, characterized in that in the operator system (4, 5, 6) the call is routed to its own modem pool, which is reserved for calls coming from the customer switchboard.

14. Method according to any of Claims 1-13, characterized in that in the operator system (4, 5, 6) the call is routed forward to a free operator, according to the routing logic of the switching system connected to the switchboard.

15. Method according to any of Claims 1-14, characterized in that, if the extension selected in the operator system (4, 5, 6) is busy, the call is routed to a queue in the external server system (3).

16. Method according to any of Claims 1 - 15, characterized in that, if there is a queue in the external server system (3) to the selected extension, the state data of the queue is transmitted from the external server system (3) to the operator system (4, 5, 6) and the state data of the queue to the extension is displayed in the operator system (4, 5, 6) to the call operator during the call being transmitted.

17. Method according to any of Claims 1 - 16, characterized in that

- queries on the state of the extension are made with the aid of the external server system (3),

- the state data of the extension is transmitted from the external server system (3) to the operator system (4, 5, 6), and

- the state data of the extension is displayed in the operator system (4, 5, 6) to the call operator during the call being transmitted.

18. Method according to Claim 17, characterized in that the states of the extensions are classed in main groups, for each of which its own symbol is reserved, for example a colour, and the state data of an extension is displayed to the call operator in such a way that the symbol of the main group is shown easily noticeably in connection with expression of the extension, and additional data relating to the state of the extension are shown at least partly with the aid of a menu structure.

19. Method according to any of Claims 1-18, characterized in that

- the SCP (1) gives each call coming to the service a call identifier,

- the SCP (1) routes the call to the operator system (4, 5, 6) and transmits the call identifier along with the call,

- the SCP (1) monitors the call,

- selecting, in the operator system (4, 5, 6), a suitable extension of the telephone switchboard service for the call,

- the operator system (4, 5, 6) notifies the selected extension and the call identifier to the external server system (3),

- the operator system (4, 5, 6) releases the call,

- the SCP (1) detects the release of the call,

- the SCP (1) asks the external server system (3) what should be done to the call with the identifier,

- the external server system (3) states the extension corresponding to the identifier, and

- the SCP (1) routes the call to the stated extension.

20. Method according to any of Claims 1-19, characterized in that the call is set to queue for the extension and notification of the queued call is sent to the extension, for example, through a UUS, SMS, USSD, SIP, or MMS message.

21. Method according to any of Claims 1-20, characterized in that

- the call is set to queue for the extension,

- the queued call is released and the queuing is continued with the call disconnected,

- when the extension becomes free, the telephone connection with the calling subscription if reopened,

- a telephone connection is opened to the extension, and

- the call is connected between the extension and the calling subscription.

22. Method according to any of Claims 1-20, characterized in that

- a call is reserved between the calling subscription and the extension and a condition, for example, a time by the clock, is defined for the implementation of the call,

- when the defined condition is fulfilled, a telephone connection is opened to the calling subscription and to the extension, and

- the call is connected between the extension and the calling subscription.

23. Method according to any of Claims 1 - 22, characterized in that transfer of the call is prevented, according to GSM-network call transfers, by setting the value of the transfer calculator to the maximum value of transfers.

24. Method according to any of Claims 1 - 22 is characterized in that the transfer of the call is prevented, according to GSM-network and fixed-network call transfers, by setting the value of the transfers of the transfer calculator to the maximum value and the call class to the excitation class.

25. Method according to any of Claims 1-24, characterized in that the call- routing data are stored in a database call-identifier-specifically, so that the data can be utilized during the call.

26. Method according to Claim 25, characterized in that the earlier call-routing information is retrieved to the switching system and displayed to the operator as the history information of the call.