Abstract:
A user interaction procedure in an Intelligent Networks system may include several stages, such as playing an announcement to a user, and receiving digits entered by the user. The switching point returns messages to the control point at intermediate stages during the procedure.

Description:
FIELD OF THE INVENTION 
     This invention relates to a user interaction procedure, specifically in an Intelligent Networks telecommunications network architecture. 
     BACKGROUND OF THE INVENTION 
     The Intelligent Networks (IN) architecture consists of a Service Switching Point (SSP), which is a switching system that is able to intercept telephone calls, and query a Service Control Point (SCP). The SCP is a system which contains service specific logic, and data which allows it to return instructions to the SSP on how further to treat the intercepted call. 
     Many IN services include a user interaction phase, which typically consists of an announcement being played to the user, and may then require the user to send digits back to the SSP, in order to indicate the requested service. 
     From existing IN standards, for example European Telecommunication Standard ETS 300 374-1 (pages 163-165) a system is known in which, when the SCP sends an instruction to the SSP to play an announcement to the end user, an instruction may also be sent to the SSP that, at the end of the user interaction procedure, a report should be sent back from the SSP to the SCP. Similarly, from the same document at pages 166-171, when the user interaction procedure involves the user returning digits to the SSP, the SCP can send an instruction to the SSP, instructing the SSP to report at the end of the user interaction procedure, i.e. at the end of digit collection. 
     However, these prior art systems have the limitation that the service logic is unable to make decisions based on intermediate events occurring during the interaction procedure. 
     SUMMARY OF THE INVENTION 
     The present invention seeks to overcome this limitation in the prior art, by allowing intermediate reports to be sent from the SSP to the SCP. This has the advantage that the SCP is then able, in appropriate circumstances, to take account of the latest status of the user interaction procedure in making further decisions. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Reference will now be made, by way of example, to the accompanying drawings, in which: 
     FIG. 1 is a schematic illustration of an Intelligent Networks architecture; and 
     FIG. 2 is a flow chart illustrating a user interaction procedure operating in accordance with the present invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1 shows an architecture with an end user 12, such as a telephone subscriber, being connected to a Service Switching Point (SSP) 14. The SSP 14 is in turn connected to a Service Control Point (SCP) 16. It will be appreciated that FIG. 1 shows only a small part of a network, which may include many end users, SSPs, and SCPs. The SSP intercepts telephone calls and queries the SCP, which contains service specific logic and data, which allows it to return instructions to the SSP on how to deal with an intercepted call. 
     FIG. 2 is a flow chart illustrating a user interaction procedure in accordance with the invention. 
     In step 22 of the procedure, the SSP intercepts a call originating from an end user. In step 24, the SSP queries the SCP, for instructions on how to treat the call. In step 26, the SSP receives instructions from the SCP. These instructions will typically include instructions to play an announcement to the user, and, in this illustrated example, include instructions to collect digits from the user in response to the announcement. Moreover, in this case, the instructions from the SCP to the SSP also include instructions to report intermediate events in the user interaction procedure. 
     Thus, in step 28, the SSP starts the announcement to the end user. In step 30, the SSP reports to the SCP about the successful start of the announcement. In step 32, the SSP completes the announcement to the user. Then, in step 34, the SSP reports to the SCP about the end of the announcement. In step 36, the SSP collects the digits entered by the user. Finally, in step 38, the SSP reports to the SCP that the user interaction procedure has been completed. By contrast with the prior art, in which such a report is the only report of its type sent by the SSP to the SCP, in this case the report sent by the SSP must indicate that it is the completion of the user interaction procedure which is being reported. 
     By comparison with the prior art system, the procedure described above includes two additional report stages, in which the SSP reports to the SCP about the start of the announcement and the end of the announcement. This information allows the SCP to make decisions based on those intermediate events. For example, the SCP might start charging when the successful start of the announcement is reported. In addition, the SCP is able properly to synchronize its instructions, for example by issuing instructions at an appropriate stage in the procedure or by allowing or denying other service requests depending on the status of the user. 
     It will be appreciated that the instructions sent by the SCP to the SSP, and received in step 26, must indicate to the SSP which intermediate reports are required. Thus, the message from the SCP will need to include appropriate indications, if intermediate reports are required. 
     There is thus described a procedure which allows the service logic to have a more accurate view of the user status, and the status of the system, so that it is able when necessary to act on accurate information.