WO2013079115A1

WO2013079115A1 - Enhanced user options for rule-based services in ip multimedia subsystem

Info

Publication number: WO2013079115A1
Application number: PCT/EP2011/071517
Authority: WO
Inventors: Mikael Forsberg
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2011-12-01
Filing date: 2011-12-01
Publication date: 2013-06-06

Abstract

One aspect is a method of configuring an IMS Rule-based service for a subscriber of an IMS network. A user equipment, UE, of the subscriber is able to access the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf. The method comprises providing the subscriber with an option to set up a Rule-based action that provides a message to a calling party. The message indicates to the calling party one or more valid response options that the calling party can make. The method also comprises providing the subscriber with an option to set up a further Rule-based action that is conditional upon the receipt in the IMS network of a valid response from the calling party. Another aspect is a method of providing an IMS Rule-based service to a subscriber of an IMS network. The method comprises: receiving, in the IMS network, a call from a calling party. A message is provided to the calling party, the message indicating to the calling party one or more valid response options that the calling party can make. When a valid response is received from the calling party, a further action of the Rule-based service is invoked, as specified by the subscriber when setting up the Rule-based actions.

Description

Enhanced User Options for Rule-based Services in IP Multimedia Subsystem

Technical Field The present invention relates to enhancements of Rule-based services provided in IP Multimedia Subsystem (IMS) networks.

Background IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within a communication session. The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers).

Figure 1 illustrates schematically how the IMS 10 fits into the mobile network architecture in the case of a GPRS/PS access network. Call/Session Control Functions (CSCFs) operate as SIP proxies within an IMS core network 11 in a control layer 15. The IMS core network 11 also includes a Media Resource Function (MRF) provides media related functions such as media manipulation (e.g. voice stream mixing) and playing of tones and announcements. The MRF is divided into a Media Resource Function Controller (MRFC) 18 in the control layer 15 and a Media Resource Function Processor (MRFP) 19 in the connectivity layer 14. A user accesses the IMS 10 via an access network 13 and gateway nodes in a connectivity layer 14. The user must register with the IMS using the specified Session Initiation Protocol, SIP REGISTER method in order to gain access to IMS services. After registering, the user is able to establish a communication session with other peers, making use of the multimedia capabilities of the IMS 10. The IMS also includes a service network 12, that includes an application layer 16, in which Application Servers (ASs) 17 implement IMS service functionality to provide services to the end-users.

Some IMS applications available to users are termed Rule-based services, that allow a user to set up a condition, or conditions that affect how calls to or from the user are handled. One example of a Rule-based service is Communication Diversion (CDIV). CDIV is a mechanism that is specified in 3GPP Technical Specification TS 24.604 "Technical Specification Group Core Network and Terminals; Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", and enables a user to set up a call diversion service, using a set of predefined rules, so that incoming calls destined for the user are automatically diverted to a particular entity - e.g. to another user or to an answering service. Other examples include Anonymous Communication Rejection and Communication Barring, as specified in 3GPP Technical Specification TS 24.611. These Technical Specifications specify how a user can set up and define the conditions under which a rule is activated, for example based on the time of day, the identity of a calling party, the type of media employed in the call/session, and the presence condition (i.e. registered or not-registered) of the user. However, these specified Rule-based services offer a fairly limited set of options.

Described herein are a system and method for enhancing the use of Rule-based services to provide users with greater choice and flexibility in the use of the services.

Summary

According to a first aspect there is provided a method of configuring an IMS Rule- based service for a subscriber of an IMS network. A user equipment, UE, of the subscriber is able to access the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf. The method comprised providing the subscriber with an option to set up a Rule-based action that provides a message to a calling party. The message indicates to the calling party one or more valid response options that the calling party can make. The method also comprises providing the subscriber with an option to set up a further Rule-based action that is conditional upon the receipt in the IMS network of a valid response from the calling party. According to a second aspect there is provided a method of providing an IMS Rule- based service to a subscriber of an IMS network, wherein the subscriber has accessed the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf. The method comprises: receiving, in the IMS network, a call from a calling party. A message is provided to the calling party, the message indicating to the calling party one or more valid response options that the calling party can make. When a valid response is received from the calling party, a further action of the Rule- based service is invoked, as specified by the subscriber when setting up the Rule- based actions. According to another aspect, there is provided an Application Server, AS, in an IMS network configured to provide a Rule-based service to a subscriber of the IMS network. A user equipment, UE, of the subscriber is able to access the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf. The AS comprises: a memory storing a Rules database, and Rules application software; a processor; a transmitter for transmitting messages; and a receiver for receiving messages. The Rules application software, when executed by the processor, implements the Rule-based action set up by the subscriber, including when receiving a call from a calling party, transmitting a message to the calling party, the message indicating to the calling party one or more valid response options that the calling party can make. On receiving a valid response from the calling party, a further action of the Rule-based service is invoked, as specified by the subscriber when setting up the Rule- based action.

According to another aspect, there is provided a User Equipment, UE, configured to access an IMS network and to set up Rule-based actions to be invoked by the IMS network on behalf of a subscriber to the IMS network. The UE comprises: a memory storing a Rules database, and Rules configuration software; and a processor. The Rules configuration software, when executed by the processor, provides the subscriber with an option to set up a Rule-based action to be implemented on the subscriber's behalf by the IMS network. A message is provided to a calling party, the message indicating to the calling party one or more valid response options that the calling party can make. The Rules configuration software, when executed by the processor, also provides the subscriber with an option to set up a further Rule-based action that is conditional upon the receipt in the IMS network of a valid response from the calling party.

Brief Description of the Drawings

Figure 1 is a schematic illustration showing how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network. Figure 2 is a signal sequence diagram illustrating an example of an enhanced Rule- based procedure as described herein. Figure 3 illustrates schematically an example of an Application Server suitable for implementing the methods described herein.

Figure 4 illustrates schematically an example of a User Equipment suitable for implementing the methods described herein.

Figure 5 is a flow diagram for a method of configuring a Rule-based action.

Figure 6 is a flow diagram for a method of implementing a Rule-based action. Detailed Description

The 3GPP specifications for Communication Diversion (CDIV), TS 24.604 and Anonymous Communication Rejection and Communication Barring, TS 24.611 , define the conditions that may be applied when specifying a rule - for example time of the call, identity of the caller, type of media and presence of the subscriber/client may all be used. However, the specifications do not provide or suggest any mechanisms by which a Rule-based service can offer the calling user different choices, or allow the caller to provide information, which then can be used by the service to invoke some further action. For example a CDIV service could offer the caller an option to enter an account number to speed up subsequent processing of the call/service (as used, for example, in automated answering systems employed by call-centres). The current 3GPP specifications do not contain or describe this kind of interaction between the calling user and the called service. The following examples illustrate how a Rule-based service can be set up to provide this interactivity with the calling party. In this way, a service can be provided that offers a straightforward way for a users to set up group (e.g. family), call-centre type and business services, where a caller can provide inputs, such as selection from choices or account information, before the call is routed towards the target destination. The first example relates to a CDIV service. Before illustrating this, it is worth reviewing how a CDIV rule is currently set up in accordance with 3GPP TS 24.604. A subscriber to the service, whom we will refer to as Bob, can set up a CDIV rule such that any calls to Bob from a caller Alice are diverted to another user Charlie. When setting up the rule, Bob provides a rule id (in this example, he calls the rule "alice") and provides a URI address of Alice (alice@example.com) . He then sets up the rule as a "forward to" rule, and specifies the URI address of the target to whom the call from Alice will be diverted - i.e. Charlie at charlie@example.com. Having provided this information he then activates the CDIV rule. The setting up of a Rule-based action is done by means of The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) as set out in IETF RFC 4825. The user can either set the service data from a UE terminal or from a webportal. In both cases the Ut/XCAP interface is used. The structure of the XML documents are defined in the standards - for example for a CDIV rule the document structure is defined in 3GPP 24.604 CDIV. The basic CDIV conditions and actions are defined by the Internet Engineering Task Force (IETF) and the Open Mobile Alliance (OMA) - see 3GPP TS 24.604 v10.2.0 (201 1-09). The following is an example of an XML schema sequence for setting up a CDIV rule although it does not contain the complete XML headers. <ss : communication-diversion active="true ">

<cp:rule id="alice">

<cp:one id="sip : alice@example . com"/>

</cp : identity>

</ cp : conditions>

<forward-to>

<target>sip : charlie@example . com</target>

</ forward-to>

</ cp : actions>

</ cp : rule>

</ cp : ruleset>

</ss : communication-diversion> In addition, Bob can set up a specific announcement to be played to Alice before her call is diverted to Charlie. For example, to play the announcement "in a meeting" would be done by including: <mmt-serv : play-announcement>In a meeting< /mmt- serv : play-announcement> in the <cp : actions> section of the above sequence.

In a first example, an interactive CDIV rule is set up in which a menu option is added to the existing Rule action. In this case, the caller is provided with a menu of choices of different places where the call may be diverted to, and is asked to make a selection from the menu. The places could, for example, be different departments within a called company or organisation, or could be different members of a group or a family, where the family has a main number and the caller can then select from a list of different members of the family. Thus, the caller would be asked to press a different number on their keypad for each option - e.g. in a family select father by pressing 1 , mother by pressing 2, daughter by pressing 3, son by pressing 4, or connect to voice mail by not making a selection.

In this example, the response from the caller is recognised by use of the Dial Tone Multi Frequency (DTMF) signal. The application server calls on a DTMF transmitter/receiver to collect the callers selection and to play the announcement defined for each option. In addition, there is a default action (e.g. divert to voicemail) to be taken in case no DTMF digit is received that matches any of the menu options within a specified time-out. There is also a special "error" action that is taken if a DTMF signal is received that does not match any of the given menu choices. Two options are possible: to repeat the playing of the menu or to define a new target.

The programming sequence is shown below, where the action elements that are new (relative to those that follow what is specified in the 3GPP TS 24.604, or are already known from other/existing CDIV applications) are shown in bold text. communication-diversion active="true">

<cp:rule id="Unconditional menu">

< ! -- Unconditional

</cp : conditions>

<mmt-ser : menu>

<itimt-ser :menu-option key="l">

<mmt-serv: play-announcement>Press 1 to become a new customer</mmt-serv:play-announcement>

<forward-to>

<target>sip : new- customer@example . com</target> </forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="2">

<mmt-serv: play-announcement>Press 2 if you are an existing customer</mmt-serv: play- announcement>

<forward-to>

<target>sip:exiting- customer@example . com</target> </forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="3">

<mmt-serv: play-announcement>Press 3 if you are a supplier</mmt-serv:play-announcement>

<forward-to>

<target>sip : supplier- customer@example . com</target> </forward-to>

</mmt-ser :menu-option> <itimt-ser :menu-option key="default">

<mmt-serv: play-announcement>Or wait to be connected to the receptionist</mmt-serv:play- announcement>

<mmt-ser : timeout>15</mmt-ser : timeout>

<forward-to>

<target>sip : reception@example . com</target>

</forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="error">

<mmt-ser : repeat-menu/>

</mmt-ser :menu-option>

</mmt-ser :menu>

</cp : actions>

</cp:rule>

</cp : ruleset>

</ss : communication-diversion>

From the above, when an incoming call is received, the caller hears an automated announcement that states:

"Press 1 to become a new customer; press 2 if you are an existing customer; press 3 if you are a supplier, or wait to be connected to the receptionist". When the caller selects 1 , 2 or 3 by pressing the appropriate button on his UE, the call will diverted to the appropriate target, as specified in the associated CDIV action. If no selection is made before the preset timeout (15 seconds) the call is diverted to the receptionist. If the caller responds by pressing an incorrect key (i.e. not 1 , 2 or 3) then the error action triggers a repeat of the announcement. In the second example, the above procedure is extended by the use of a hierarchical menu structure. In this case, instead of an immediate diversion of the call in response to the selection of one of the initial menu choices, a second menu of choices is provided. In the sequence below, this second menu is provided when the caller selects option key 1 in the first example above. The new elements (relative to 3GPP TS 24.604/what is already known) are shown in bold and those that are new relative to the first example above are also underlined in the sequence below: communication-diversion active="true">

<cp:rule id="Unconditional menu">

< ! -- Unconditional

</cp : conditions>

<mmt-ser : menu>

<itimt-serv:menu-option key="l">

<mmt-ser : menu>

<mmt-ser :menu-option key="l">

<mmt-serv: play-announcement>Press 1 for car insurance</mmt-serv:play-announcement>

<forward-to>

<target>sip : new-car- insurance@example . com</target> </forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="2">

<mmt-serv: play-announcement>Press 2 for house insurance</mmt-serv:play-announcement>

<forward-to>

<target>sip : new-house- insurance@example . com</target> </forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="default"> <mmt-serv: play-announcement>Or wait to be connected to the receptionist</mmt-serv:play- announcement>

<mmt-serv: timeout>15</mmt- ser : timeout>

<forward-to> <target>sip :

reception@example . com</target> </forward-to>

</itimt-serv :menu-option>

<itimt-ser :menu-option key="error">

<mmt-ser : repeat-menu/>

</mmt-ser :menu-option>

</mmt-ser :menu>

<mmt-ser :menu-option key="default">

<mmt-serv:play-announcement>Or wait to be connected to the receptionist </mmt-serv:play- announcement>

<mmt-ser : timeout>15</mmt-ser : timeout>

<forward-to>

<target>sip : reception@example . com</target>

</forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="error">

<mmt-ser : repeat-menu/>

</mmt-ser :menu-option>

</mmt-ser :menu>

</cp : actions>

</cp : rule>

</cp : ruleset>

</ss : communication-diversion>

From the above, when the caller selects option 1 from the first menu, indicating that he is a new customer, he then hears another automated announcement that states:

"Press 1 for car insurance; press 2 for house insurance, or wait to be connected to the receptionist". When the caller selects 1 , or 2 by pressing the appropriate button on his UE, the call is diverted to the appropriate target, as specified in the associated CDIV action. If no selection is made before the preset timeout (15 seconds) the call is diverted to the receptionist. In the third example, the caller is provided with the option to enter data. This might be used to automate and reduce the time needed for the receiving agent to collect data, such as a phone number and account number from the caller. In this example, the caller can enter the numerical data using the number keypad of her UE to provide a DTMF signal to transfer the data to the IMS. The application server may include the entered information in the SIP INVITE that is forwarded to the specified <forward-to> target. The header parameter to be used in the SIP Request-URI is also specified in the rule to make the solution as flexible as possible. Although the telephone number is normally present in the P-Asserted-ldentity SIP header in the INVITE, there may be occasions when it is not present. For example the user may be anonymous or may be calling from another UE than the one that is connected to the account that the caller wants to access. The new elements (relative to 3GPP TS 24.604/ what is already known) are shown in bold and those that are new relative to the first and second examples above are also underlined in the sequence below.

<cp:ruleset>

<cp:rule id="Unconditional menu">

< ! -- Unconditional

</cp : conditions>

<cp:actions>

<mmt-ser : menu>

<itimt-ser : menu-option key="l">

<mmt-ser : play-col>

<mmt-serv:play- announcement>Please enter your phone number and end with a #</mmt-serv: play-announcement>

<mmt-ser : end-key>#</mmt- ser : end-key > <mmt-ser : timeout>15</mmt- ser : timeout>

<mmt-ser : header>phone- number</mmt-ser : header>

</mmt-ser :play-col>

<forward-to>

<target>sip : new-car- insurance@example . com</target>

</forward-to>

</mmt-serv:menu-option>

<itimt-ser :menu-option key="default">

<mmt-ser : timeout>15</mmt-ser : timeout>

<forward-to>

<target>sip : reception@example . com</target> </forward-to>

</mmt-ser :menu-option>

<mmt-ser :menu-option key="error">

<mmt-ser : repeat-menu/>

</mmt-ser :menu-option>

</mmt-ser :menu>

</cp : actions>

</cp:rule>

</cp : ruleset>

</ss : communication-diversion>

"Please enter your phone number and end with a #". The caller then has 15 seconds to enter his/her phone number before a SIP INVITE is forwarded to the <forward-to> target, in this example new-car-insurance@example.com. The caller must enter a designated end-tag key (in this case #) to indicate that he/she has finished entering the data. The resulting INVITE will then be: INVITE sip: new-car-insurance@example.com;cause=302;phone-number=12345678 SIP/2.0 Cause=302 is a reference to the call being diverted due to the unconditional CDIV rule, and the application server has added the phone-number= 12345678, as that was what the user entered before the end key # and was contained in the header specified by the <mmt-serv:header> tag. The terminal used by new-car-insurance(S)example.com can then use the phone-number included in the SIP INVITE and, for example, display to the serving agent any previous customer engagements where that phone number has been used before.

It's possible to include more than one request for the caller to enter data (<mmt- serv:play-col>) to obtain more information. Each piece of data entered by the caller is added to the SIP INVITE sent to the target.

The fourth example relates to a call barring service. As for the CDIV Rules, the basic conditions and actions are defined by IETF and OMA, and the relevant 3GPP Technical Specification is TS 24.61 1. In this case an option is provided to allow the caller to enter a bypass code that will enable the call to be routed instead of being barred.

Again, in the sequence below, the new elements are shown in bold and those that are new relative to the first and second examples above are also underlined. <ss : incoming-communication-barring active="true">

<cp:rule id="unconditional menu with user input">

<!-- No conditions in this example

</cp : conditions>

<mmt-ser : menu>

<itimt-ser :menu-option key="l">

<mmt-ser :play-col> <mmt-serv: play-announcement>The person you called is not available. Enter the bypass code . </mmt-serv:play-announcement>

<mmt-ser : match>123456</mmt- ser : match>

<mmt-serv: key-length>6</mmt- ser : key-length>

<mmt-ser : timeout>15</mmt- ser : timeout>

</itimt-serv :play-col>

</itimt-ser :menu-option>

<mmt-ser :menu-option key="default">

<ss : allow>false</ss : allow>

</mmt-serv:menu-option>

</mmt-ser :menu>

</cp : actions>

</cp : rule>

</cp : ruleset>

</ss : communication-diversion>

The Incoming Communication Barring service will play an announcement to the caller to state: "The person you called is not available. Enter the bypass code"

The caller can then enter the digits of a bypass code on his/her UE, and will allow the call through provided the entered digits match the bypass code (123456) that was specified in the <mmt-serv:match> tag.

The same procedure can be applied to an Outgoing Communication Barring service where the user needs to enter a correct pass code to be able to make an outgoing call. This can be particularly useful, for example, when combined with <mmt-serv:start-with> conditions as used in the Ericsson ® Multimedia MTAS, which performs a leftmost front match (where, for example, +44 will match all calls to UK) so that all international calls require a correct access code to be completed. This is useful also as a parental control, or in public or semi public phones, such as in a hotel reception or in conference rooms, where domestic/local calls are allowed, but not international calls.

The following list is a summary of the new mmt-serv:xxx XML tags introduced and used in the above examples.

<mmt-ser : menu> < !— Defines a menu.

< /itimt- ser : menu> < !— A menu can contain another menu item to create hierarchical menus.

<itimt-ser : menu-option key=" " > < !— Defines a key for a menu option, where "0-9", "A-D", "*" or "#" is used for DTMF keys.

</mmt-ser : menu-op tion> < !— where "default" is defining a default action if no key is pressed...

< !— ...and "error" is defining the menu option if a non-matching key is pressed.

<mmt-serv : timeout>Time < !— Defines the time the AS shall wait </mmt-ser : timeout > before taking the default action.

<mmt-ser : repeat-menu/ < !— Action to repeat the menu, can be used for any menu-option.

<mmt-ser : play-col> . . . < !— Defines a play and collect group, which contains an announcement...

</mmt-ser : play-col> < !— ...and an end key that specifies the end of the collected digits.

<mmt-ser : end-key >key < !— Defines the key (0-9, A-D, * or #) </mmt-ser : end-key > that is the end of the requested input...

< !— ...unless a timeout is used

<mmt-serv : header>SIP URI header parameter < !— Defines the SIP URI < / mmt- ser : header > header parameter where the AS shall

assign the collected digits to

<mmt-serv : match>Digits to match < !— Defines the digits that the

</mmt-serv : match> shall match, e.g. for a PIN code <itimt-ser : key-iength>Length < !— Defines the length of the requested </itimt-serv : key-iength> input. Can be used if no end key is used. Figure 2 is a signal diagram relating to a CDIV service. The service has been implemented by a user, User B, who is a subscriber to the CDIV service that is provided by an IMS AS 22. The signals are shown between a caller A 21 , the AS 22, a MRFP 23 and User C who has been set up as the target of the CDIV service. Note that although the example shows an MRFP it would also be possible to use a separate MRFC (Media Resource Function Controller).

Signal 201 is a SIP INVITE sent from caller A 21 inviting User B to set up a call/session. As User B has set up a CDIV rule, the call is forwarded to the AS 22 in the IMS. The AS 22 is the provider of the CDIV service, and knows that this involves the playing of an announcement, and possibly the receiving of a response from the caller. Therefore it sends an H248 Add signal to the MRFP 23 to alert it, and signal 203 is the MRFP's reply. Signal 204 is a SIP progress message sent from the AS 22 to the caller 21 , and to which the caller 21 responds with a provisional acknowledgement PRACK signal 205. The AS 22 returns a SIP 200OK signal 206 to the caller 21 , and then provides information to the MRFP 23 regarding the announcement that will be made to caller A 21. The MRFP 23 returns an H248 Modify Reply signal 208 to the AS 22. The announcement is played to caller A 21 at step 209. The caller A 21 sends a response in signal 210. This may be a DTMF signal from the keypad of caller A's UE , or it could be contained in a SIP INFO message sent to the AS 22. If it is a DTMF signal, this will be intercepted by the MRFP, which then sends an H.248 Notify signal 21 1 that informs the AS 22 of the data contained in the DTMF signal. This is acknowledged in an H.248 NotifyReply signal 212. Alternatively, if the response signal 210 is a SIP message that includes the relevant response data, then this is received at the AS 22, which then sends an H.248 Subtract signal 213 to the MRFP 23. This is a request to the MRFP to extract the response data from the SIP message. The MRFP 23 sends an H.248 SubtractReply 214 with the relevant data extracted from the SIP message.

The AS 22 now has the reply and is able to carry out the next action in the CDIV Rule- based service that was set up by User B. In this example, the caller A 21 has been asked to provide a phone number and the AS 22 includes this in the SIP INVITE 215 that it forwards to User C, as required by the CDIV rule. The SIP INVITE 215 then establishes a call/session between the caller A 21 and User C 24, as indicated by the signals 216 and 217 returned from user C 24 to Caller A 21 via the AS 22. Note that instead of communicating directly with an MRFP, the SIP messages could be sent to an MRFC external to the IMS core network.

Figure 3 illustrates schematically an example of an AS 31 for implementing an IMS Rule-based service in accordance with the methods described above. The AS 31 can be implemented as a combination of computer hardware and software. The AS 31 comprises a processor 32, a memory 33, a receiver 34 and a transmitter 35. The memory 33 stores the various programs/executable files that are implemented by the processor 32, and also provides a storage unit for any required data. For example, this data can include but is not limited to a rules database 36 that stores the rules configured for the users who have subscribed to the Rule-based service. The programs/executable files stored in the memory 33, and implemented by the processor 32, include but are not limited to a rule configuration unit 37, a rule application unit 38, and an action performance unit 39. The rule configuration unit 37 can process rule configuration information received from a user in order to configure the rule for the service that is to be applied for the user. This configuration of the rule would include storing the rule for the user in the rules database 36 provided by the memory 33. When the AS 31 receives a communication relating to the subscriber user, using the receiver 34, the rule application unit 38 can then access rules database 36 provided by the memory 33 and retrieve the user's rules for the service. The rule application unit 38 can then determine if the condition defined in the rule is met by the communication and thereby determine if an action associated with the rule should be performed in relation to the communication. If it is determined that the action should be performed, then the action performance unit 39 can implement the action defined in the rule for that communication.

In addition to the above, the AS 31 can ascertain if the rule requires the playing of an announcement to the caller, with the possibility of the caller providing a response, either in the form of a DTMF signal, or included in a SIP message. In that case the AS 31 will contact an MRFP or MRFC, as described above, and will implement the action based upon the response received from the caller in accordance with the specified rules set up by the subscriber user.

Figure 4 illustrates schematically an example of a UE 40 suitable for implementing the methods described above. The UE 40 can be implemented as a combination of computer hardware and software. The UE 40 comprises a user input device 41 , processor 42, a memory 43, a receiver 44 and a transmitter 45. The memory 43 stores the various programs/executable files that are implemented by the processor 42, and also provides a storage unit for any required data. The programs/executable files stored in the memory 43, and implemented by the processor 42, include but are not limited to a user input unit 46, and a rule configuration unit 47. The user input unit 46 can process any user input received from the user input device 41. For example, the user input unit 46 can accept input from the user input device 41 that defines a rule for the user that is to be applied by a supplementary service in accordance with the above- described methods. The user input unit 46 would then provide any user input relating to rule definition/configuration information to the rule configuration unit 47 to allow the user to define such a rule. The rule configuration unit 47 would then ensure that a message is sent to an Application Server (AS) that implements the Rule-based service, the message including the rule definition/configuration information defined by the user input.

Figure 5 is a flow diagram illustrating a method of configuring a Rule-based action of the type described above. At step 501 , a user who is a subscriber to the Rule-based service in an IMS network initiates a Rule-based action set up procedure. At step 502, a determination is made as to whether the action to be set up is one that will require the use of a caller's response. If not, then the procedure can move directly to step 505 to complete the setting up and implementation of the Rule-based action. However, if at step 502 the answer is Yes, then at step 503 the user specifies the outgoing message (announcement) to be played to the caller and stipulating any options and corresponding responses (e.g. the digits that will be used to provide DTMF signals) that will form the basis of the Rule-based action. At step 504, a further determination is made as to whether there are any further response options to be included. Note that these may be hierarchical, or conditional upon the response that is received to a first outgoing announcement message. If there are, then the procedure loops back to step 503. If not, then the procedure moves on to step 505 to complete the setting up and implementation of the Rule-based action.

Figure 6 is a flow diagram for a method of implementing a Rule-based action of the type described above. The Rule-based action has been set up by a subscriber to the service In accordance with the methods described above. At step 601 a call is received for the subscriber. Note that although the call for the subscriber may be a call from another party destined for the subscriber, it could also be an attempt to make an outgoing call, where the subscriber has, for example, set an Outgoing Call Barring Rule. At step 602 a determination is made in the network as to whether the subscriber has set a Rule-based action that is invoked by the received call. If not, then at step 603 the normal call routing procedure will continue. If the call does invoke a Rule- based action, then at step 604 the announcement is played to the calling party, and in this case the announcement requests the calling party to provide a response e.g. (a menu selection). At step 605 a determination is made as to whether a valid response has been received. If it has, then at step 606 a further action is implemented depending on the response received. As described above, for example, this further action could be to implement a diversion of the call to a target selected by the caller, or could be bypassing of a call barring rule, or could be to include information entered by the caller into a SIP message forwarded to another user. If no valid response has yet been received, then at step 607 a determination is made as to whether an invalid (error) response has been received. If it has then at step 608 an error action is implemented, which could be, for example, to repeat the original announcement, or to divert the call to a default target, or some other predetermined action. If no response (valid or invalid) has been received, then at step 609 a determination is made as to whether the timeout period has expired. If not, then the procedure loops back to step 605. If the timeout period has been exceeded, then at step 610 the default action is carried out (e.g. divert call to receptionist/voicemail).

It will be appreciated by the person of skill in the art that the above-described examples are examples of illustrative embodiments to which various modifications may be made without departing from the principles or scope of the present invention. For example, in order to configure a Rule-based service in accordance with the above-described embodiments, the user could access a web portal/web page provided by the network operator/service provider. The user could then log in and configure their service settings via the web portal. The user could also access such a web portal using their UE. Configuring the rules from a webportal could use the Ut interface in the portal's backend, or alternatively another interface of a BSS (Business Support System) that the operator uses. Some AS applications have specialised interfaces, for example the Ericsson ® Multimedia MTAS has defined a CAI3G (Customer Administration Interface 3rd Generation) interface that supports more features than are accessible on the Ut interface.

The embodiments described above, and the principles they embody, offer a network operator an easy and attractive way to provide an interactive family, call centre and business service, where input and/or choices can be entered by the caller before the call is routed towards the target destination. This invention allows an IMS operator or user to specify advanced rules within the context of existing services such as Communication Diversion and Communication Barring to provide, for example, a group/family service, automated answering in a company or organisation and a bypass service for Incoming and Outgoing Communication Barring.

Claims

CLAIMS:

1. A method of configuring an IMS Rule-based service for a subscriber of an IMS network, wherein a user equipment, UE, of the subscriber is able to access the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf, the method comprising:

providing the subscriber with an option to set up a Rule-based action that provides a message to a calling party, the message indicating to the calling party one or more valid response options that the calling party can make , and to set up a further Rule-based action that is conditional upon the receipt in the IMS network of a valid response from the calling party.

2. A method of providing an IMS Rule-based service to a subscriber of an IMS network, wherein the subscriber has accessed the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf, the method comprising:

receiving, in the IMS network, a call from a calling party;

providing a message to the calling party, the message indicating to the calling party one or more valid response options that the calling party can make;

receiving a valid response from the calling party; and

conditional upon the valid response received, invoking a further action of the Rule-based service as specified by the subscriber when setting up the Rule-based actions.

3. The method of claim 1 or claim 2 wherein the message provided to the calling party includes a menu of options to which the calling party can respond by selecting a response that corresponds to one of the options.

4. The method of claim 3 wherein the menu of options includes a plurality of call answering options for calls directed to the subscriber in a Communication Diversion,

CDIV, service.

5. The method of claim 3 or claim 4, wherein the menu of options is a hierarchical menu and invoking the further action on receiving the valid response that corresponds to one of the menu options comprises providing a further message to the calling party, to which the calling party can respond by providing a further response.

6. The method of any preceding claim wherein the message, or further message, provided to the calling party includes an invitation for the calling party to provide a response that includes information relating to the calling party, for forwarding in a message to a target defined by the subscriber in the Rule-based action.

7. The method of claim 6 wherein the information relating to the calling party is numerical information, such as a telephone number, account number or PIN number.

8. The method of claim 1 or claim 2, wherein the Rule-based action relates to a call barring service, and the message provided to the calling party includes an option to provide a response that includes a bypass code for bypassing the call barring.

9. The method of claim 8 wherein the calling party is a party attempting to initiate a call/session with the subscriber, the call barring service being used to prevent calls being routed to the subscriber.

10. The method of claim 8 wherein the calling party is a UE of the subscriber, the call barring service being used to prevent outgoing calls being made from UEs of the subscriber.

1 1. The method of any preceding claim wherein the Rule-based action includes a default action that is invoked if no valid response is received from the calling party within a predetermined time limit.

12. The method of any preceding claim wherein the Rule-based action requires the calling party to enter a designated end-tag key to indicate that the calling party has finished entering the response.

13. The method of any preceding claim wherein the Rule-based action includes an error action that is invoked if an invalid response is received.

14. The method of any preceding claim wherein the response, and if used the further response, comprises a Dial Tone Multi-Frequency, DTMF signal.

15. The method of any of claims 1 to 13, wherein the response, and if used the further response, comprises a Session Initiation Protocol, SIP, message.

16. The method of any preceding claim wherein the subscriber is provided with the option to set up a Rule-based action from an Application Server, in response to the subscriber initiating a Rule-based action set-up procedure.

17. The method of any of claims 1 to 15, wherein the option to set up a Rule-based action is provided from an application stored in a memory of User Equipment operated by the subscriber.

18. An Application Server, AS, in an IMS network configured to provide a Rule- based service to a subscriber of the IMS network, wherein a user equipment, UE, of the subscriber is able to access the IMS network to set up Rule-based actions to be invoked by the IMS network on the subscriber's behalf, the AS comprising:

a memory storing a Rules database, and Rules application software;

a processor;

a transmitter for transmitting messages; and

a receiver for receiving messages,

wherein the Rules application software, when executed by the processor, implements the Rule-based action set up by the subscriber, including when receiving a call from a calling party, transmitting a message to the calling party, the message indicating to the calling party one or more valid response options that the calling party can make and, on receiving a valid response from the calling party, invoking a further action of the Rule-based service specified by the subscriber when setting up the Rule- based action.

19. The AS of claim 18, further comprising configuration software, wherein the configuration software, when executed by the processor, provides the subscriber's UE with a Rule-based action set-up procedure including an option to set up a Rule-based action.

20. The AS of claim 18 or claim 19, configured to forward a received response to a Media Resource Function Processor, MRFP, for interpretation of the response, and to receive a .

21. The AS of claim 18 or claim 19, wherein a valid response comprises a SIP message, and the AS is configured to forward a received response to a Media Resource Function Processor, MRFP, for detection of the DTMF signal.

22. User Equipment, UE, configured to access an IMS network and to set up Rule- based actions to be invoked by the IMS network on behalf of a subscriber to the IMS network, the UE comprising:

a memory storing a Rules database, and Rules configuration software; and a processor;

wherein the Rules configuration software, when executed by the processor, provides the subscriber with an option to set up a Rule-based action to be implemented on the subscriber's behalf by the IMS network, wherein a message is provided to a calling party, the message indicating to the calling party one or more valid response options that the calling party can make, and to set up a further Rule-based action that is conditional upon the receipt in the IMS network of a valid response from the calling party.