FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules  2005

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

‘’Method of implementing Master Service Control Function forfacilitating enhanced inter carrier value added services’’

APPLICANTS:
Name Nationality Address
Alcatel Lucent France 3  avenue Octave Gréard 75007 Paris 
France.

The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-

TECHNICAL FIELD
[001] The present invention relates to telecommunication networks and  more particularly  to systems and methods of utilizing a Master Service Control Point to provide access-rights based inter-operator value-added and supplementary services associated to a telecom operator to subscribers of another operator.
BACKGROUND
[002] Present day telecommunication services are provided by a host of network operators and service providers. These network operators and service providers operate independent of each other with limited interoperability. However  with the growth of telecommunication technology and competitive pressure  network operators and service providers need to provide newer applications along with improved customer subscriber services.
[003] Each operator network makes use of an intelligent network to control and manage various services provided by the operator and any third party applications. The Intelligent Network (IN) is an operator specific network architecture  which facilitates communication between various network components to provide operator specific  value added and supplementary services to subscribers . The IN makes use of service switching points –SSP’s  service control points –SCP’s  a signaling system called SS7 (Signaling System 7) and various signal transfer points to provide services to users. The intelligent network makes use of Service Control Point (SCP) to control and manage network services. SCPs are connected with either Service Switching Points-SSP or Signal Transfer Points-STP. This is dependent upon the network architecture of the network service provider.
[004] Each subscriber registered with a service provider  is associated to a specific service control function inside the network  which connects him to the operator’s intelligent network logic. Any subscriber connected to one single intelligent network can subscribe and access all the services provided by the operator network via the Service Control Point. The subscriber is restricted to services provided by the service provider and cannot access services provided by other operators. Alternately  most of the value added / supplementary service offering requires interaction among two subscribers like peer-to-peer refill and need these subscribers to belong to the same operator.
[005] With the growing number of service providers  subscribers tend to have multiple subscriptions with various service providers in order to get the best services from each service provider. In such a scenario  subscribers need to manage various subscriptions independently. Inter-operator services are generally restricted to basic services  due to isolated functioning of Operator specific SCPs catering to their own set of subscriber base. Also  as the network architecture of each service provider may differ  providing inter-operator services becomes challenging.

SUMMARY
[006] In view of the foregoing  embodiments herein provide a method for providing inter-operator services to multiple subscribers of multiple network operators by employing a Master Service Control Point (SCP). In addition to cross operator services; it also provides a mechanism of dynamically sharing of other relevant information among SCPs. The method comprises of receiving a service request message by the Master SCP from an operator network ‘A’’s SCP for providing / requesting access to an inter-operator service along with relevant parameters required for processing the request to an operator network ‘B’  authenticating the service request message by the master SCP for analyzing access rights of the operator network A over the operator network B  processing the service request by the master SCP including interaction with the operator network B’s SCP if required  and sending of response message by the master SCP back to the operator network A’s SCP indicating either positive access acknowledgement or denial of service. The access rights define the services supported/granted by service control point of one operator to service control point of another operator. Mediating SCPs use diameter protocol for sending and receiving request and response messages. The processing of the request message involves use of information available on the server of the Master Service Control Point.
[007] Embodiments further disclose a Master Service Control Point for providing inter-operator services to multiple subscribers of multiple network operators. The Master service control point comprises of receiving a service request message from an operator network A for service related to an operator network B  authenticating the service request message for analyzing access rights of the operator network A over the operator network B  processing the service request which may include interaction with operator B’s SCP  if the service is permitted and sending a reply message to the operator network A. The access right defines the services supported by service control point of one operator for service control to another operator. Mediating SCPs use diameter protocol for sending and receiving messages. Processing of the reply message involves use of information available on the server of the Master Service Control Point.
[008] Embodiments herein further disclose a system in a communication network for providing inter-operator services to subscribers of multiple network operators  the system comprising plurality of service control points  a Master Service Control Point  further the Master Service Control Point configured for receiving a service request message from an operator network A for service related to an operator network B  authenticating the service request message for analyzing access rights of the operator network A over the operator network B  processing the service  for the operator network A if the service is permitted and sending a response message back to the operator network A. The system authenticates the message to determine the access rights where the access rights define the services supported by service control point of one operator for service control to another operator. The system sends and receives the request and the reply messages using diameter protocol. The system processes the reply message by using information available on the server of the Master Service Control Point.
[009] Embodiments herein also disclose methods for inter- operator subscriber to subscriber collaborative charging  inter- operator deposit and withdrawals and employing the Master SCP for inter-operator voucher based recharge.
[0010] Embodiments further disclose a method for processing messages between network operators and service control points  the method comprising defining various services and creating new “attribute value pairs” for relevant messaging between the service control points. The method wherein defining of services includes inter-operator services offered by the network operators connected to each other using a Master Service Control Point (SCP). The attribute value pairs are defined for each service provided by the master SCP.
[0011] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES
[0012] The embodiments herein will be better understood from the following detailed description with reference to the drawings  in which:
[0013] FIG. 1 illustrates a block diagram of the network of telecommunication operators connected to a Master Service Control Point  according to the embodiments as disclosed herein;
[0014] FIG. 2 illustrate a block diagram of the Master Service Control Point  according to the embodiments as disclosed herein;
[0015] FIG. 3A and 3B illustrate an example of a diameter packet format used as the communication protocol  according to the embodiments disclosed herein;
[0016] FIG. 3C and 3D illustrate the Call Control Request and Call Control Answer messages and their definitions  according to the embodiments disclosed herein;
[0017] FIG. 4 shows an example describing access rights shared by a calling/requesting operator network’s SCP with other service provider’s service control point  according to the embodiments disclosed herein;
[0018] FIG. 5 illustrate a Global MSISDN – SCP ID – SCP ADDRESS MAPPING Table  according to the embodiments disclosed herein;
[0019] FIG. 6 illustrates a Global Profile to Function Mapper table  according to the embodiments disclosed herein;
[0020] FIG. 7A  7B  7C are example flowcharts describing a method - an inter- operator subscriber (belonging to OP1) to subscriber (belonging to OP2) credit deposit  according to embodiments disclosed herein;
[0021] FIG. 8A  8B  8C are example flowcharts describing a method of inter-operator subscriber (belonging to OP1) to subscriber (belonging to OP2) credit withdrawal according to embodiments disclosed herein;
[0022] FIG. 9A  9B  9C are flowcharts describing a method of inter- operator subscriber to subscriber collaborative charging  according to embodiments disclosed herein;
[0023] FIG 10A  10B illustrates flowchart diagrams describing the use case where Master SCP is used for inter-operator voucher based recharge; and
[0024] FIG. 11 illustrates local SCP functions  according to embodiments disclosed herein;

DETAILED DESCRIPTION OF EMBODIMENTS
[0025] The embodiments herein  the various features  and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly  the examples should not be construed as limiting the scope of the embodiments herein.
[0026] FIG. 1 illustrates a block diagram of the network of telecommunication operators connected to a Master Service Control Point- Master SCP  according to the embodiments as disclosed herein. A master SCP 101 in a base operator 102 acts as a hub for communication between the shown operators - OP1  OP2  OP3  and OP4. The base operator 102 is generally one of the existing operators in the network environment. The base operator 102 is the one which provides the basic network architecture which all the other operators may use and implement on their own operator networks. Each operator (OP1  OP2  OP3  OP4) connects to a huge number of subscribers (shown as mobile phones in the figure) using a service control point-SCP. For example  OP1 consists of an SCP1  which communicates with subscriber A  and subscriber C and OP2 consists of SCP2  which communicates with subscriber B and subscriber D. The SCP of an operator network is a standard component of an operator network  hosting core call control logic for controlling and handling the call (voice  data  SMS) initiated by the respective SSP- Service Switching Point. The SCP implements the services. The subscribers communicate with the SCP via a service switching point-SSP. The SSP is responsible for routing of call initiated by a subscriber of one operator to another subscriber of same/other operator. It implements a call state machine  whose transitions are guided by the instructions given by the SCP. The SCP also communicates with a service data point-SDP for accessing subscriber related information during processing of a service. The figure shows a single SCP associated with each operator network. However  multiple SCP’s may be present in every operator’s network. The base operator 102 may be considered as the one containing the Master SCP 101 and the other operators (OP1  OP2 OP3 OP4) may be called local operators The master SCP 101 communicates with the SCP’S of other operators- SCP1  SCP2  SCP3  SCP4 using a diameter protocol. The diameter protocol ensures authentication  authorization and accounting -AAA at each stage of the communication. The diameter protocol provides attribute value pairs - AVP’s which allows new commands  attributes and functions to be defined by the operator networks. In Figure 1  the Master SCP 101 may be considered as a central diameter node containing processing means and a server with information required for inter operator communication. The other operators -OP1  OP2  OP3  and OP4 act as client diameter nodes. The figure 1 shows only network components relevant to the embodiments of the present invention. Not all the components in a telecommunication operator network are shown. Any mobile computing device can be used to connect to an operator network. Also  the subscribers shown are an example and in reality hundreds of thousands of subscribers may be part of one operator network. Each mobile operator network shown a cloud may be using different architectural frameworks. The network operators shown may be using different signaling and communication approaches like GSM architecture  an Internet Protocol based Multimedia system (IMS) or even an session initiation protocol (SIP) for audio and video communications. The Master SCP 101 is configured such that it can communicate and process information between any type of operator networks.
[0027] FIG. 2 illustrates a block diagram of the Master Service Control Point  according to the embodiments as disclosed herein. The depicted master SCP 101 block diagram does not show all the modules of an SCP. It shows modules relevant to the present invention. The master SCP is a part of the base operator network. The Master SCP 101 contains a receiver 201  transmitter 202  a processing unit 203 and a server 204. The receiver 201 receives data and messages from various SCP’s of different operators and sends it to the processing logic. The processing unit 203 may comprise of control logic 205  decoders 206 and encoders 207. The decoders 206 decode the messages received by the processing unit 203 and the control logic 205 decides on an appropriate reply for the received message. The encoder 207 then encodes the reply into a format understandable by the SCP’s. The control logic 205 makes use of all the information available in the server 204 to decide on a reply. The control logic 205 may also have sequences of events stored. The server 204 comprises of an SCP IP/SS7 based address database 208  an SCP_ID to MSISDN range mapping table 213  operator profile data 209  operator ID’s 210  SCP ID’s 211 . The SCP IP/SS7 based address 208 stores the IP/SS7 address of the operator networks required for Master-to-Local SCP communication. The SCP_ID 211 contains pre-defined IDs of all the connected operator networks’ SCPs. The operator profile dataset 209 contains the profile of each operator network. The operator profile 209 defines the right each operator provides to other operators. These rights define the inter-operator feature access rights of one operator network over the other. For example  the operator OP2 may want to allow balance transfer from an OP1’s subscriber to his worn (OP2’S) subscriber. The Master SCP checks the access rights given by OP2 for transfer function from OP1 and allows any transfer function from a subscriber of OP1 towards subscriber of OP2. MSISDN ranges are generally defined for operator networks. A SCP_ID to MSISDN range mapping table 213 is useful for identifying the hosting SCP of the requesting/responding subscriber. While certain inter-operator features require a pre-agreed arrangement between the calling and the called party  requiring OP1 SCP to store respective called party numbers linked to the calling party (own subscriber). For other cases the decision criteria/feature access may be through dynamic in-call approval/disapproval of service request by the responding party. Access rights may be thus be defined at two levels. A subscriber-to-subscriber access decision rules/data may be confined to the local SCP of the invoking subscriber and an Operator-to-Operator access rights defining an operator’s access capability may further be defined at Master SCP.
[0028] FIG. 3A and 3B illustrate an example of a diameter protocol packet format 300 used as the communication protocol  according to the embodiments disclosed herein. The diameter protocol acts a means for communication between client operator networks using the master SCP 101 as a central node. Messages  command  and functions can be configured on a diameter packet 300  and sent across the network. The diameter protocol packet format 300 consists of a message header 301 and a message payload 302. The message header 301 comprises of a diameter version 303  a command code version 304  a command code 305  application ID 306  a hop-by-hop identifier 307 and an end-to-end identifier 308. The command code version 304 generally comprises of 7 bits. Certain bits are reserved to indicate the type of message. For example  a request (R) bit may be set to indicate a request; a proxiable bit (P) may be set to indicate a message  which needs to be proxied  repeated or redirected. These versions can also be configured and set in master SCP’s service creation environment. A command is assigned with a command code 305. These command codes 305 are defined for both request and reply/answer messages. For example  command code CCR stands for credit control request. The application ID 306 refers to application in the packet. The application ID 306 may refer to a third party application  authentication  or accounting. The application ID 306 can also be defined at the master SCP 101. The hop-by-hop identifier 307 is used to match requests and replies. The end-to-end identifier 308 helps in identifying duplicate messages. The message payload 302 consists of a variable number of attribute value pairs -AVP’s 309 that encapsulate information relevant to the diameter message.
Fig 3B describes the message payload and the AVP’s 309 in further detail. The AVP code 310 contains the same code as command code 305. The flags 311 are used to define the AVP’s. The flag is 7 bits in length with certain reserved bits. The AVP length 312 defines the length of the message. The vendor ID 313 is an optional field. The data field 314 contains all data sent/received. The AVP’s can be created and used as required.
[0029] FIG. 3C and 3D illustrate the Call Control Request and Call Control Answer messages and their definitions  according to the embodiments disclosed herein. Figure 3c depicts CCR request message and the AVP definitions pertaining to the CCR request. Figure 3d depicts CCA message and the AVP definitions pertaining to the CCA message.
[0030] FIG. 4 shows an example describing access rights shared by a calling/requesting operator network’s SCP with other service provider’s service control point  according to the embodiments disclosed herein  Figure 4 shows a calling operator SCP_ID 401  linked operators 402  the SCP_ID’s 403 associated with the linked operators and applicable operator SCP profile 404 . The SCP profile 404 defines the access right given for particular operator-to-operator combination. The calling operator 106 here is XXX with the calling operator SCP_ID as XXX_SCP1. The linked operators 402 include YYY_1 and ZZZ_1. The YYY_1 operator contains two SCP’s one with YYY_SCP1 as the SCP_ID 403 and the other one as YYY_SCP2 as the SCP_ID 403. The Operator_SCP_profile 404 defines the access right in terms of inter-operator features/function offered by each associated Operator to its linked operators. The YYY_SCP1 allows only account balance enquiry while the YYY_SCP2 grants account balance enquiry as well as account balance withdrawal permission to XXX_SCP1. The ZZZ_SCP2 grants balance transfer related functions to XXX_SCP1  while ZZZ_SCP1 does not give access to any inter-operator function in any manner. The profile to allowed functions mapping is given in FIG 6. In other embodiments  the functions granted to different SCP belonging to an operator may allow the same access rights/functions. Consider an example when both ZZZ_SCP2 and ZZZ_SCP1 allow all inter operator functions.
[0031] FIG. 5 illustrates a Global MSISDN – SCP ID – SCP ADDRESS MAPPING Table  according to the embodiments disclosed herein. The MSISDN range 501 shows the MSISDN number ranges associated to an operator. The operator ID 502 shows the operator associated with the MSISDN ranges. The SCP_ID 403 identifies the SCP hosting the subscriber data of respective MSISDN range f the operator. The SCP IP/SS7 addresses 503 define the SS7/IP addresses of the respective SCPs of various operators for communication purposes. The SS7/IP addresses shall be used by the Master SCP to facilitate communication between the linked operators’ SCPs.
[0032] FIG. 6 illustrates a Global Profile to Function Mapper table  according to the embodiments disclosed herein. The operator SCP profile 404 shows the access available to another operator and the function supported 601shows the supported functions/services accessible to the operators belonging to the specific profile.. Consider an example where subscriber C of OP1 wants to access services from OP2. If the operator OP2 grants only balance deposit function to OP1  then subscriber belonging to operator OP1 will have access to only balance deposit function towards another subscriber ‘D’ of operator OP2. Access to any other functions will be rejected.
[0033] FIG. 7A  7B  7C are flowcharts describing a method of inters- operator subscriber to subscriber credit deposit  according to embodiments disclosed herein. Subscriber A of OP1 initiates a request (701) for depositing funds (F1) in subscriber B’s account. The subscriber B belongs to operator 2-OP2. The request containing amount to be transferred along with beneficiary MSISDN details is sent by the subscriber A in an USSD format or an SMS format. The SCP1 of OP1 receives (702) the request containing the amount to be transferred along with the MSISDN number of subscriber B. The SCP1 then requests (703) subscriber A to enter a PIN number for authentication of the subscriber A. The SCP1 then checks (704) if the PIN entered by the user is correct. If the PIN is incorrect  the subscriber A is requested (705) to enter the PIN number again. If the PIN is correct  the SCP1 checks (706) if subscriber A is subscribed to the service. If the user is not subscribed to the service  the subscriber A is sent (707) a message requesting to subscribe to the service. Next SCP shall check if the invoked inter-operator function requires a pre-defined agreement between party-A and party-B  or if the access would be granted dynamically by responding party ‘B’ during the call. For cases such as balance withdrawal/deposit  a pre-defined agreement may not be required. The OP2 subscriber B (responding entity)  may be asked to either allow/disallow the service request from subscriber of OP1 during the triggered request itself. However for cases  such as balance enquiry a one-time pre-defined agreement between the called and the calling party may be stored at OP1’s SCP eliminating the need for in-call request from OP2’s subscriber. The SCP1 then checks (708) if subscriber A has sufficient balance in the account. If the subscriber A does not have sufficient balance  the service is denied (709) and subscriber A is sent a message showing account balance. If subscriber A has sufficient balance for the transaction  SCP1 sends (710) a CCR -credit control request to the master SCP 101. The CCR request is sent (711) using a diameter protocol message containing amount to be transferred  the beneficiary MSISDN and the operator ID of subscriber A and received 711 by the master SCP 101. The master SCP 101 determines (712) operator ID of subscriber B using the MSISDN - SCP_ID-SCP address mapping table. The master SCP 101 then checks (713) if the SCP_ID 403 of OP1 is valid. If the SCP_ID 403 is invalid  SCP1 of OP1 is denied (714) access to master SCP 101 service. If the SCP_ID 403 of OP1 is valid  The master SCP checks (717) if OP2 gives rights to OP1 for performing credit deposit in the form-F1. If OP2 does not give 717-access right over OP1 for function F1  a function is not supported message sent (718) to SCP1 and the subscriber A. If OP2 gives access right to OP1  the master SCP sends (719)  the CCR request to SCP2 of OP2 whose address is derived from the MSISDN - SCP_ID-SCP address mapping table. The SCP2 of OP2 receives (720) the request containing the amount to be deposited/credited along with subscriber B’s details. The SCP2 sends (721) an acknowledgement for receiving the CCR request to the master SCP. The SCP2 of OP2 credits (722) the amount in subscriber B’s account and sends (722) a message to subscriber B. The SCP2 then sends (723) a CCR request successful message to SCP1 via the master SCP. The SCP1 then debits (724) the subscriber A’s account with the requested amount. The SCP1 finally sends (725) a message to subscriber A indicating successful transaction along with the amount debited. The various actions in method 700 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 7A  7B  7C may be omitted.
[0034] FIG. 8A  8B  8C are flowcharts describing a method of inter- operator subscriber to subscriber credit withdrawal  according to embodiments disclosed herein. Subscriber A of OP1 initiates a request (801) for withdrawal of funds (F2) from subscriber B’s account. The subscriber B belongs to operator 2-OP2. The request is sent by the subscriber A in an USSD format or an SMS format. The SCP1 of OP1 receives (802) the request containing the amount to be withdrawn along with the MSISDN number of subscriber B. The SCP1 then requests (803) subscriber A to enter a PIN number for authentication of the subscriber A. The SCP1 then checks (804)  if the PIN entered by subscriber A is correct. If the PIN is incorrect  the subscriber A is requested (805) to enter the PIN number again. If the PIN is correct  the SCP1 checks (806) if subscriber A is subscribed to the service. If the subscriber A is not subscribed to the service  subscriber A is sent (807) a message requesting to subscribe to the service. Next SCP shall check if the invoked inter-operator function requires a pre-defined agreement between party-A and party-B  or if the access would be granted dynamically by responding party ‘B’ during the call. For cases such as balance withdrawal/deposit  a pre-defined agreement may not be required. The OP2 subscriber (responding entity) may be asked to either allow/disallow the service request from subscriber of OP1 during the triggered request itself. However for cases  such as balance enquiry a one-time pre-defined agreement between the called and the calling party may be stored at OP1’s SCP eliminating the need for in-call request from OP2’s subscriber. SCP1 sends (808) a CCR -credit control request to the master SCP. The CCR request is sent using a diameter protocol message containing (809) amount to be transferred  the MSISDN of ‘B’ and the operator ID of subscriber A. The master SCP 101 determines (810) operator ID of subscriber B using the MSISDN - SCP_ID-SCP address mapping table. The master SCP then checks (811) if the SCP_ID of OP1 is valid. If the SCP_ID is invalid  SCP1 of OP1 is denied (812) access to master SCP service. If the SCP_ID of OP1 is valid  the master SCP 101 checks (815) if OP2 gives rights to OP1 for performing credit withdrawal function-F2. If OP2 does not give 815-access right over OP1 for function F2  a function is not supported message sent (816) to SCP1 and the subscriber A. If OP2 gives access right to OP1  the master SCP sends (817)  the CCR request to SCP2 IP address of OP2 uses the MSISDN - SCP_ID-SCP address mapping table. The SCP2 of OP2 receives (818) the request containing the amount to withdrawn along with subscriber B’s details. The SCP2 then checks (820)  if subscriber B has sufficient balance in the account for the transaction. If the subscriber B does not have sufficient balance  the service is denied (821) and a failure message is sent to subscriber A and SCP1. If subscriber B has sufficient balance  for the transaction  SCP2 sends (822) a USSD menu/message to subscriber B requesting permission for withdrawal. Subscriber of OP2 responds to USSD Menu based request by selecting either the allow or disallow option. If subscriber B does not  give (823) permission for withdrawal  service is denied (824) to subscriber A and a failure message is sent to subscriber A via the master SCP 101. If subscriber B allows withdrawal  the SCP2 of OP2 withdraws 825 the amount from subscriber B’s account and sends 825 a message to subscriber B. The SCP2 then sends (826) a CCR request successful message to the master SCP 101. The SCP1 then credits (827) the subscriber A’s account with the requested amount. The SCP1 finally sends (828) a message to subscriber A indicating successful transaction along with the amount credited. The various actions in method 800 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 8A  8B  8C may be omitted.
[0035] FIG. 9A  9B  9C are flowcharts describing a method of inter- operator subscriber to subscriber collaborative charging  according to embodiments disclosed herein. A collaborative charging method allows the subscribers involved in a voice/video/sms call to share call charges by a fraction specified by calling subscriber. Subscriber A of OP1 initiates a request (901)  requesting the Subscriber B to pay partially/wholly for the next call towards him by subscriber A. The subscriber B belongs to operator 2-OP2. The request is sent by the subscriber A to his/her respective SCP either through a USSD or SMS request. A sample USSD Request sent by Calling Party A for establishing collaborative charging relationship with Called Party B for the following call is: * < ACCESS CODE> * * . The SCP1 of OP1 receives (902) the request specifying the fraction of total call charges (50 – 50 % of call charges; 100 – complete call charges) to be levied on called party ‘B’ along with the MSISDN number of subscriber B. The charging of subscriber ‘B’ may be done in accordance to the charging rates applicable to subscriber ‘A’ as per the subscribed tariff plan. The SCP1 then requests (903) subscriber A to enter a PIN number for authentication of the subscriber A. The SCP1 then checks (904)  if the PIN entered by subscriber A is correct. If the PIN is incorrect  the subscriber A is requested (905) to enter the PIN number again. If the PIN is correct  the SCP1 checks (906) if subscriber A is subscribed to the service. If the subscriber A is not subscribed to the service  subscriber A is sent (907) a message requesting to subscribe to the service. Next SCP1 shall check if the invoked inter-operator function requires a pre-defined agreement between party-A and party-B  or if the access would be granted dynamically by responding party ‘B’ during the call. For cases such as balance withdrawal/deposit  a pre-defined agreement may not be required. The OP2 subscriber (responding entity) may be asked to either allow/disallow the service request from subscriber of OP1 during the triggered request itself. However for cases  such as these  one-time pre-defined agreement between the called and the calling party may be stored at OP1’s SCP eliminating the need for in-call request from OP2’s subscriber. SCP1 calculates the rate at which the called party shall be charged based on the fraction requested from the calling subscriber. The remainder of charges shall be borne by the Calling party. It is important to note here that Operator may levy a periodic or volume based fixed charge on the calling party for such calls. SCP1 sends (908) a CCR -credit control request to the master SCP. The CCR request is sent using a diameter protocol message containing (909) the rate at which called party needs to be charged  B’s MSISDN A’s MSISDN and the operator ID of subscriber A. The master SCP 101 determines (910) operator ID of subscriber B using the MSISDN - SCP_ID-SCP address mapping table. The master SCP then checks (911) if the SCP_ID of OP1 is valid. If the SCP_ID is invalid  SCP1 of OP1 is denied (912) access to master SCP service. If the SCP_ID of OP1 is valid  the master SCP 101 then checks (913) if OP2 gives rights to OP1 for performing collaborative charging function-F7. If OP2 does not give -access right over OP1 for function F7  a function is not supported message sent (914) to SCP1 and the subscriber A. If OP2 gives access right to to OP1  the master SCP sends (915)  the CCR request to SCP2 IP address of OP2 whose address is derived from the MSISDN - SCP_ID-SCP address mapping table. The SCP2 of OP2 receives (916) the request containing the rate at which the called party ‘B’ is to be charged along with subscriber A’s and B’s MSISDN details. SCP2 sends (917) a a CCR response acknowledgement to master SCP. The SCP2 then checks (918)  if subscriber B has sufficient balance in the account for the transaction. If the subscriber B does not have sufficient balance  the service is denied (919) and a failure message is sent to subscriber A and SCP1. If subscriber B has sufficient balance  for the transaction  SCP2 sends (920) a USSD menu/message to subscriber B requesting permission for allowing the next call from subscriber ‘A’ to be charged to be charged on his account at the defined rate. Subscriber B of OP2 responds to USSD Menu based request by selecting either the allow or disallow option. If subscriber B does not  give (921) permission  service is denied (922) to subscriber A and a failure message is sent to subscriber A via the master SCP 101. If subscriber B allows collaborative charging  the SCP2 of OP2  sends (923) a CCR request successful message to the master SCP 101. In addition SCP2 also makes a note of the fact that for the next call from subscriber ‘A’   subscriber ‘B’ shall be charged at a definite rate as specified by Master SCP. The SCP1 finally sends (924) a message to subscriber A indicating successful operation The call charges of next call made by subscriber ‘A’ to subscriber ‘B’ is shared between the two subscribers. The various actions in method 9000 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 9A  9B  9C may be omitted.
[0036] FIG. 10A  10 B are flowcharts describing another inter-operator user case for subscriber-to-subscriber inter-operator voucher based recharge  according to embodiments disclosed herein. An inter-operator voucher based recharge allows a subscriber A belonging to Operator OP1 to recharge the account of another subscriber B belonging to Operator OP2. Subscriber A of OP1 initiates a request (1001)  requesting to recharge another subscriber B. The subscriber B belongs to operator 2-OP2. The request is initiated by the subscriber A either through USSD or through SMS request or through an Interactive Voice Response System of OP1  presenting the voucher number and MSISDN of subscriber B. The vouchers may be a special voucher cards provisioned by the operator OP1 for specific cases of inter-operator voucher based recharge. The SCP1 of OP1 receives (1002) the request  specifying the recharge voucher details and the MSISDN of subscriber B. The SCP1 then requests (1003) subscriber A to enter a PIN number for authentication of the subscriber A. The SCP1 then checks (1004)  if the PIN entered by subscriber A is correct. If the PIN is incorrect  the subscriber A is requested (1005) to enter the PIN number again. If the PIN is correct  the SCP1 checks (1006) if subscriber A is subscribed to the service. If the subscriber A is not subscribed to the service  subscriber A is sent (1007) a message requesting to subscribe to the service. SCP1 derives authenticates the voucher card number and derives the associated amount to be credited to the account. SCP1 sends (1008) a CCR-credit control request to the master SCP. The CCR request is sent using a diameter protocol message containing (1009) the amount to be credited  the MSISDN of the Subscriber B  the MSISDN of the Subscriber A and the operator ID of OP1. The master SCP 101 determines (1010) operator ID of subscriber B using the MSISDN - SCP_ID-SCP address mapping table. The master SCP then checks (1011) if the SCP_ID of OP1 is valid. If the SCP_ID is invalid  SCP1 of OP1 is denied (1012) access to master SCP service. If the SCP_ID of OP1 is valid  the master SCP 101 then checks (1013) if OP2 gives rights to OP1 for performing voucher based recharge – function F8. If OP2 does not give 1013-access right over OP1 for function F8  a function is not supported message sent (1014) to SCP1 and the subscriber A. If OP2 gives access right to OP1  the master SCP sends (1015)  the CCR request to SCP2 IP address of OP2 whose address is derived from the MSISDN - SCP_ID-SCP address mapping table. The SCP2 of OP2 receives (1016) the request containing subscriber A’s MSISDN  subscriber B’s MSISDN and the amount to be credited to subscriber B’s account. The SCP2 sends (1017) a CCR receipt response acknowledgement to master SCP. The SCP2 of OP2 credits (1018) the amount to subscriber B’s account and  sends (1019) a CCR request successful message to the master SCP 101. In addition SCP2 also sends (1020) a notification to subscriber B  indicating that his account has been credited by the respective amount by MSISDN ‘A”. The SCP1 finally sends (1021) a message to subscriber A indicating successful operation. The various actions in method 1000 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 10A  10 B may be omitted.
[0037] FIG. 11 illustrates local SCP functions  according to embodiments disclosed herein. The master SCP may allow a subscriber belonging to one local SCP of an operator network  to hold multiple linked accounts with other network operators. Such subscribers may be allowed to manage and control inters operator services as well as services within each operator network. For example  a business running subscriber holding such an account can link multiple user accounts and use this system for transferring weekly income to users. In case when a subscriber uses different operator services in different cities  he might wish to control and manage all his user accounts from everywhere and might require inter-operator services too. The transmitter 202 sends across reply messages to the respective SCP in the respective operator network. The local SCP function shows the base account along with the base account number of the subscriber. The screen shows accounts linked to the base account along with the operator ID. The local function shows the base account along with the base account number of the subscriber. It shows one of the linked accounts. It also shows the services which the subscriber of the base operator can perform on OP2 using the base account number.
[0038] In an embodiment  the method facilitates dynamic sharing of relevant information among SCPs or among other network entities like SSP of Operator B and SCP of Operator A via Master SCP over Diameter Interface. This information may correspond to be information regarding the CDR data of in-roamers  roaming under operator B coverage with operator A’s SCPs for billing purposes and so on.
[0039] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can  by applying current knowledge  readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept  and  therefore  such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limiting. Therefore  while the embodiments herein have been described in terms of preferred embodiments  those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.

WE CLAIM:
1. A method for providing inter-operator value added and supplementary telephony services to multiple subscribers of multiple network operators by employing a Master Service Control Point (SCP)  said method comprising
receiving a service request message by said master SCP from a subscriber of operator network A for service related to a second subscriber of an operator network B;
authenticating said service request message by said master SCP for analyzing access rights of said operator network A over said operator network B;
processing said service by said master SCP  for said operator network A if said service is permitted; and
sending a response message by said master SCP to said operator network B.
2. The method as in claim 1  wherein said access right defines the services supported by service control point of one operator for service control to another operator.
3. The method as in claim 1  wherein said method provides a generic mechanism for inter-operator feature implementations requiring respective Operator SCPs to share relevant subscriber/charging data through said Master SCP.
4. The method as in claim 1  wherein said method facilitates subscribers belonging to different operators to pay collaboratively for a specific service like such as SMS  data call.
5. The method as in claim 1  wherein said method facilitates dynamic subscriber approval for a requested inter-operator service by a subscriber of another operator.
6. The method as in claim 1  wherein said method is applicable to architectures that include IP Multimedia Service (IMS)  Session Initiation Protocol (SIP)  Global System for Mobile Communication (GSM).
7. The method as in claim 1  wherein said method further comprising dynamically sharing of relevant information among SCPs or other operator specific network entities via Master SCP through the provisioned diameter interface.
8. The method as in claim 1  wherein said method further comprising
defining various services for processing messages between network operators and service control points; and
creating new attribute value pairs for each service provider for relevant messaging between said service control points.
9. The method as in claim 8  wherein defining of services includes inter-operator services offered by said network operators connected to each other using a Master Service Control Point (SCP).
10. A Master Service Control Point for providing inter-operator services to multiple subscribers of multiple network operators  said service control point comprising
storing consolidated network information on operator SCPs  operator-to-operator inter-operator service agreements;
receiving a service request message from an operator network A for service related to an operator network B;
authenticating said service request message for analyzing access rights of said operator network A over said operator network B;
processing said service  for said operator network A if said service is permitted; and
sending a reply message to said operator network B.
11. The Master Service Control Point as in claim 10  wherein said access right defines the inter-operator service access granted by service control point of one operator to service control of another operator.
12. A system in a communication network for providing inter-operator services to multiple subscribers of multiple network operators  said system comprising plurality of service control points  a Master Service Control Point  further said Master Service Control Point configured for
receiving a service request message from a subscriber of an operator network A for service related to a second subscriber of an operator network B;
authenticating said service request message for analyzing access rights of said operator network A over said operator network B;
processing said service  for said operator network A if said service is permitted; and
sending a reply message to said operator network B.
13. The system as in claim 12  wherein said system authenticates said message to determine said access rights where said access rights defines the services supported by service control point of one operator for service control to another operator.
14. The system as in claim 12  wherein said system is further configured to facilitate subscribers belonging to different operators to pay collaboratively for a specific service like such as SMS  data call.
15. The system as in claim 12  wherein said system is further configured to provide a generic mechanism for inter-operator feature implementations requiring respective Operator SCPs to share relevant subscriber/charging data through said Master SCP.
Dated 20th Sep  2011

Dr. Kalyan Chakravarthy
Patent Agent

ABSTRACT
A Master SCP for extended cross –operator features is disclosed. The present invention relates to telecommunication networks and  more particularly  to systems and methods of utilizing a Master Service Control Point to provide inter-operator value added and supplementary services to a subscribers belonging to varied and independent network operators and service providers. A master SCP acts as a central node providing communication between multiple SCP’s of different network operators using diameter protocol messages. It facilitates provisioning of operator-specific services as operator-independent services for use by/among subscribers associated to varied network operators.FIG. 1