HK1106893B - System and method for supporting telecommunication client service requests - Google Patents

Description

Method and system for supporting telecommunication customer service requests

Priority of request

The present application claims priority from EPO application 05425764.7 filed on 28/10/2005 and italian application MI2005a002073 filed on 28/10/2005, both of which are incorporated herein by reference in their entirety.

Technical Field

The present invention relates to telecommunications processing system architectures. In particular, the present invention relates to a layer of a telecommunications system architecture that handles third party telecommunications service requests.

Background

The rapid development of data processing and telecommunication technologies has resulted in a large number of communication services available to consumers. Such telecommunications services include traditional telephone services, internet services, cable television services, cellular telephone services, paging services, combined voice and data delivery services, and many others. Further, many services may be based on wireless or wireline.

Established telecommunication service providers have invested a tremendous amount of time, money and advanced technology to achieve and reliably provide a large number of telecommunication products and services. In the past, this investment was primarily only beneficial to telecommunication service providers. That is, telecommunication service providers keep their own technology internally confidential and for their own use.

In the context of such complex telecommunications architectures, each telecommunications service provider desires to explore and develop new business opportunities for generating new revenue channels. Existing technologies in service provider architectures may drive such new revenue channels. However, in the past, there has been no sufficiently secure, flexible, and efficient mechanism for allowing third parties to access underlying functionality in a service provider architecture.

Furthermore, even if a third party has access to functions in the service provider architecture, there is no supporting architecture for handling third party service requests. It is not sufficient that the third party can request telecommunication services from the service provider. Without supporting processing architectures, third party requests are not replicable.

A need has long existed for an enhanced telecommunication service provider architecture.

Disclosure of Invention

Establishing an enhanced telecommunication service provider architecture presents considerable technical challenges. As one example, there are technical challenges in receiving and organizing the very large number of potentially simultaneous or near-simultaneous service requests that may be received from third parties. As another example, there are technical challenges in determining which service requests to process in an organized and efficient manner. Other technical challenges are to perform the extracted service request to actually complete the processing of the request, to provide error-tolerant service request processing, and to maximize the performance of the service request processing.

One aspect of the present invention is to provide a service broker layer for a service request processing system of a telecommunications architecture. The service request processing system includes a service request interface, an allocator system, an extractor system, and a workflow engine. Other or different components may be included in the service request processing system.

The service broker is part of the service delivery platform and provides some technical advantages. The first advantage is configurability, which is achieved through the specification management database definition of workflows, tasks and operations (actions). The service broker allows the telecommunication service provider to create new services originating from existing building blocks and allows the service provider to create new building blocks from predefined templates. The service broker thus provides a wide flexibility for the service provider to define services without limiting the service provider to a completely conventional and inflexible infrastructure.

A second advantage is control. The service agent provides error handling, logging, and control of the execution of workflows, particularly asynchronous workflows, used to deliver services. The service agent provides an error management graphical user interface. Through this interface, an experienced operator can complete, resubmit, change, redo, or correct the process of delivering the workflow of the service.

A third advantage is maintenance. In general, service agents avoid hard coding of workflows, messages, and data elements. Instead, the service broker uses workflow, message and data elements based on reconfigurable XML and metadata. As a result, the service broker functionality is far easier to maintain, modify, extend and improve than a hard-coded implementation.

In addition, the service agents provide the ability to perform both synchronous and asynchronous workflows. Resulting in enhanced performance. In some implementations, 500 transactions (transactions) or more may be processed per second.

The service request interface receives a service request for a telecommunication service from an external entity. Each service request includes a service identifier field. The service identifier field informs the service agent of the type of service requested in the service request.

An allocator in the service broker receives each service request. Based on the service identifier field, the allocator allocates the service request into different service queues. Separate service queues may be established to independently queue requests for particular requesting entities and/or service types. For example, the service queue may include a messaging (e.g., SMS or MMS) service request queue, a billing service request queue, a service activation request queue, or other type of service queue.

The service agent also includes an extractor system. The extractor system takes the queued service requests from a separate service queue for processing. In some implementations, the service agent may include multiple extractor systems that provide multiple independent extractor engines. A set of traffic control parameters manages the retrieval of queued service requests by the extractor system from the individual service queues.

The workflow engine initiates a sequence of workflow steps that fulfill the retrieved service request. The service agent may execute a plurality of independent workflow engines. For example, the workflow engine may process a workflow defined for a service request selected by a particular extractor system.

Other aspects of the invention include methods and systems for efficiently ordering telecommunications service request processing. In particular, the service agent establishes a plurality of service queues and distributes a plurality of queued telecommunication service request records into the service queues. The service agent also initiates simultaneous execution of multiple extractor engines to fetch the service request.

The first extractor engine then retrieves a portion of the telecommunication service request record (e.g., technical service procedure identifier (TSO _ ID)) stored in the service queue. The service request record represents a first service request submitted by an external entity. Similarly, the second extractor engine again attempts to retrieve a portion of another telecommunication service request stored in the service queue. The service request record represents a second service request submitted by an external entity.

The service agent then initiates execution of the workflow using different workflow request delivery techniques to fulfill the first service request and the second service request. For example, the service broker may implement the first workflow request by publishing a workflow request message through a message publish/subscribe system to which the workflow engine has subscribed. As an alternative workflow request delivery technique, the service agent may directly invoke the second workflow engine, specifying the second service request.

Thus, the service broker architecture overcomes the technical challenges associated with processing external service requests. Allocating service requests into queues solves the technical challenge of receiving and organizing extremely large numbers of simultaneous or near-simultaneous service requests. The multiple extractor and workflow engine architecture addresses the following technical challenges: the method includes extracting service requests in an organized and efficient manner, performing the extracted service requests to actually implement processing of the requests, providing error-tolerant service request processing, and maximizing performance of the service request processing.

Other systems, methods, features and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.

Drawings

The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts or elements throughout the different views.

FIG. 1 shows a portion of a telecommunications architecture including a service agent connected to a third party access gateway;

FIG. 2 shows a service broker in a telecommunications architecture;

FIG. 3 shows an alternative implementation of a service broker in a telecommunications architecture;

FIG. 4 shows traffic control parameters for an extractor system in a service broker;

FIG. 5 shows a distributor system for service agents in a telecommunications architecture;

FIG. 6 shows a first extractor system for a service agent in a telecommunications architecture;

FIG. 7 shows a specification management database for an extractor system in a telecommunications architecture;

FIG. 8 shows a second extractor system for a service broker in a telecommunications architecture;

FIG. 9 shows an enhanced specification management database for extractor systems in a telecommunications architecture;

FIG. 10 illustrates operations that may be taken by an inbound request manager to process a telecommunication service request;

FIG. 11 illustrates operations that may be taken by a workflow engine to process a telecommunication service request;

FIG. 12 illustrates operations that may be taken by the parallel task manager to process a telecommunication service request;

FIG. 13 shows a message flow through a service broker for handling authentication requests;

FIG. 14 shows a message flow through a service proxy for processing charging requests;

FIG. 15 shows the message flow through the service broker for handling SMS delivery and billing requests;

fig. 16 shows the message flow through the service broker for handling MMS delivery and charging requests;

FIG. 17 shows a message flow through a service agent for handling SIP call requests;

FIG. 18 shows a message flow through a service broker for handling a user status request;

FIG. 19 shows a message flow through a service broker for handling a mobile user authentication request;

fig. 20 shows a message flow through the service broker for processing an IPTV user authentication request.

Detailed Description

Fig. 1 shows a telecommunications architecture 100 that interacts with a third party 102. The third party 102 may vary widely in form and implementation. For example, the third party 102 may include: user devices 104 such as cellular telephones, personal data assistants, network (e.g., internet) communication devices; applications 106, such as telecommunication service applications implemented by other service providers, such as Short Message Service (SMS) messaging applications, Session Initiation Protocol (SIP) systems, and billing applications that charge customers for products and services; and other devices, programs, or entities 108.

The telecommunications architecture 100 implements functionality to support telecommunications products and services. The telecommunications architecture 100 exposes the selected functionality to the third party 102. In other words, the third party 102 may communicate with the telecommunications architecture 100 to use functionality already in the architecture 100. As a result, the third party 102 need not consume the resources required to locally duplicate the functionality already provided by the telecommunications architecture 100.

The products and services, and the underlying functionality they expose, may vary between different implementations. For example, telecommunications architecture 100 may expose SMS messaging services (deliver and charge for SMS messages), Multimedia Message System (MMS) messaging services (deliver and charge for MMS messages), and SIP services (establish and charge for SIP calls). As further examples, the telecommunications architecture 100 may expose billing services (requesting charging for an account), Internet Protocol Television (IPTV) services (requesting delivery of television programs), user status services (requesting a current user status, such as 'online', 'offline', 'busy', or 'away'), and user authentication services (e.g., requesting verification of whether a mobile user exists and whether the mobile user has credentials to purchase a desired service, such as an IPTV service). Other functionality may be provided in addition or as an alternative. In addition, the telecommunications architecture 100 may also provide access to communication network services (e.g., internet browsing services) through a third party access gateway 110.

The telecommunications architecture 100 protects access to the exposed services. To this end, the architecture 100 provides a third party access gateway 110. The third party access gateway 110 acts as a single point of contact for the third party 102 to the exposed services.

As shown in fig. 1, the third party access gateway 110 receives a service request 112 from the third party 102. In response, third party access gateway 110 verifies that the service request originated from an authenticated and authorized third party. In the case of a network communication service request (as an example), the third party access gateway 110 processes the authorized service request and relays the service request to the service provider 114. In the case of requests for exposed services, such as SMS, MMS, and SIP service requests, the third party access gateway 100 may process the authorized service request and relay it to the service broker 116.

The service broker 116 executes the service request. In doing so, the service broker 116 may communicate with Business Support Systems (BSSs) and Operations Support Systems (OSS)118, where the architecture 100 implements the business support systems and operations support systems to create, configure, manage, and maintain telecommunications products and services. As an example, the OSS/BSS system 118 may include a billing system, a directory and presentation system, an authentication system, a provisioning system, or other support system. In executing the service request, the service broker 116 may additionally or alternatively communicate with a network layer 120 that may deliver or return service-related data to the service broker 116. Responses from the service provider 114 and the service proxy 116 are returned to the third party access gateway 110 for delivery to the originating third party requester.

The third party access gateway 110 provides a layer of security between the third party 102 and the exposed functionality implemented in the telecommunications architecture 100. At the same time, the service broker 116 provides an architectural layer for flexibly and efficiently processing third party service requests. Thus, the architecture 100 allows a telecommunication service provider to expose core functionality to third parties 102 and process service requests from the third parties 102 in a secure, standardized, and controlled manner.

FIG. 1 also shows a Customer Relationship Management (CRM) system 122 in communication with the service broker 116. As will be described in more detail below, the CRM system 122 may also issue a telecommunication service request to the service broker 116. As an example, the service request submitted by the CRM system 122 may include a service activation, pause, restart, or termination request. These requests may result from customer service personnel interacting with CRM system 122 to establish, suspend, or terminate customer telecommunication products and services (e.g., cellular telephone service).

Each service request may include a service type identifier field and a service request identifier field. In the following discussion, the TSO _ LABEL field provides a service type identifier field and the TSO _ ID field provides a service request identifier field. The TSO _ LABEL in the service request is a service type identifier that specifies the type of service requested (e.g., a request to activate a particular telecommunications product or service). The TSO _ ID in the service request is a service request identifier that provides an identifier (e.g., a unique identifier) of the service request itself.

Figure 2 shows a more detailed view of one implementation of the service broker 116. As described above, the service agent 116 connects to external systems including the OSS/BSS system 118, the third party gateway 110, and the CRM system 122 through the service request interface 201. The service request interface may include a physical adapter, a logical adapter, or both a physical and logical adapter. The OSS/BSS system connects to the service agent 116 through a physical adapter 202 and a logical adapter 208, the third party gateway connects to the service agent 116 through a physical adapter 204 and a logical adapter 210, and the CRM system connects to the service agent through a physical adapter 206 and a logical adapter 212.

The physical adapter 202 and 206 may be implemented by communication software that handles communication between external systems and service agents. The logical adapter 208 and 212 represent data translators, mappers, and/or converters that perform message mapping between different data models in the service agent and external systems. The logical adapter 208 and 212 ensure that message data from the external system arrives at the service broker 116 in the form expected by the service broker 116. In one implementation, the adapter 208 and 212 support the conversion of messages and/or message content from a format defined by one schema (e.g., the XML schema for messages to be followed in the third party gateway 110) to another format defined by another schema (e.g., the XML schema for messages received by the service broker 116).

The message publishing system 214 provides a message bus for passing messages between external systems and the service broker 116. Additionally, the message bus may pass messages between components of the service agent 116 itself. Message publishing system 214 receives a message assigned to a topic and publishes the message to a user of the topic. The user may be a processing system (e.g., systems 110, 118, and 122), a program, or other entity. However, other messaging techniques may be used in other implementations, including bulk file transfer, sharing files or memory, or other inter-process communication techniques.

For example, message distribution system and adapter 202 and 212 may be implemented with TIBCO adapter (SM) and TIBCO Rendezvous (TM) messaging available from TIBCO software corporation of Palo Alto, Calif. In other implementations, the physical adapter may be implemented with BEA Weblogic integration controls available from BEA Systems of San Jose, Calif. In one implementation, the message is an extensible markup language (XML) message and the adapter performs the transformation according to an extensible stylesheet transformation language (XSLT) stylesheet. The transformation may transform data between schemes of XML, HyperText transfer protocol (HTTP), Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), eXtensible schema drawing (XSD), Java database connectivity/open database connectivity (JDBC/ODBC), or any of the other message formats, content standards, or communication protocols.

The service broker 116 also includes an allocator system 216 that allocates incoming service requests into a service request queue 218. The service request queues 218 may include one or more independent queues assigned to particular types of service requests. In the example shown in FIG. 2, the service queues 218 include one or more third party gateway service request queues 220 that queue service requests received from third party gateways 110, and one or more customer relationship management queues 222 that queue service requests from the CRM system 122.

As an example, the third party gateway service request queue 220 may include a message service request queue 224 (for queuing, for example, SMS or MMS message delivery requests) and a billing service request queue 226 (for queuing, for example, billing requests). Additional examples of queues 220 include authentication request queues and status request queues. Similarly, the CRM queues 222 may include an activate service request queue 228, a terminate service request queue 230, and other queues for service requests received from the CRM system 122. The queues 220 and 222 are not limited to the types and numbers described above. Rather, one or more queues may be implemented and allocated to queue any one or more types of service requests received from any one or more service requesters.

The service agent 116 includes an extractor system 232. Under control of the traffic control parameter 234, the extractor system 232 takes the queued service request from the service queue 218. The extractor system 232 then delivers the retrieved service request to the workflow system 236. The workflow system 236 initiates execution of a workflow engine (e.g., workflow engines 238, 240, 242), wherein the workflow engine determines and requests execution of workflow steps in a predefined order to fulfill a service request.

For example, to deliver and charge for SMS messages, the workflow system 236 can initiate execution of an SMS workflow engine that, as one step, issues a billing request to a billing system to charge for the SMS message, and, as another step, issues a messaging request to the SMS system to send the message. The workflow system 236 may be implemented with a Tibco InConcert (TM) workflow engine available from TIBCO software, Inc. of Palo Alto, Calif., or may be implemented with other workflow systems.

The service broker also includes a technical procedures management (TOM) database 240. The TOM database 240 stores configuration rules defining a set of technical service procedure steps to be performed in a workflow for fulfilling a service request. TOM database 240 is described in more detail below.

Figure 3 shows an alternative implementation of the service broker 302. The service broker 302 includes a second extractor system 304. The second extractor system 304 also takes service requests from the service queue 218 under control of the service control parameter 234. Alternatively, the second extractor system 304 may operate under the control of a separate set of traffic control parameters. Additional extractor systems and sets of traffic control parameters may be provided.

The second extractor system 304 employs a different workflow request delivery technique than the extractor system 232. In particular, the second extractor system 304 issues workflow request messages to a message publishing system, such as system 214. The message publishing system 214 may then deliver the workflow request message to the second workflow system 306 that subscribes to the workflow request message at the message publishing system 214. In other words, the message publishing system 214 relieves the burden of the second extractor system 304 and bottlenecks in the direct call workflow sequence.

However, the second workflow system 306 receives the published workflow request message and initiates execution of the workflow to fulfill the service request. The second workflow system 306 need not be implemented in the same manner as the first workflow system 236. In the example shown in fig. 3, the second workflow system 306 includes an inbound request manager 308, a workflow engine 310, and a parallel task manager 312. An operations engine 318, including an operations manager 320 and an operations orchestrator 322, performs network provisioning operations within the workflow. Each of which will be described in more detail below.

The addition of the second workflow system 306 produces several benefits. In particular, the second workflow system 306 helps eliminate a potential bottleneck in processing service requests by directly invoking the workflow system 236 via the first extractor system 232. Furthermore, the first extractor system 232 and the second extractor system 304 may execute together, which not only improves end-to-end performance by processing service requests in parallel, but also provides a robust fault tolerance mechanism by providing two independent extractor/workflow engine systems to process service requests.

The service agent 302 or 116 may also include a web error Graphical User Interface (GUI). FIG. 3 shows an example of a web error GUI 314 provided for the second extractor system 304. The Web error GUI 314 may be implemented as a Web Application running the Java Server pages of a Web server (e.g., the Weblogic Application Server available from BEA Systems of San Jose, Calif.).

The web error GUI 314 populates (populates) the user interface display with information regarding any errors encountered in processing the service request. The web error GUI 314 may also provide an input mechanism by which the reviewer provides corrective input (e.g., changing data or completing a service request or supporting input of missing data in a workflow task to correct the service request or task), manually completes the service request or task, or resubmits the service request or task for processing.

In one implementation, each service request that has encountered an error may be represented in the web error GUI with a descriptive title and hyperlinks to additional details of the service request characteristics. The web error GUI 314 may further provide a query interface. The query interface accepts search criteria (e.g., MSISDN number, TSO _ ID, data range, service request type, error code, customer or other identifier, or any other characteristic of a service request) and performs a reactive search and display of matching error records. Clicking on the hyperlink causes the web error GUI 314 to populate the display with error information specific to the selected service request and additional characteristics available for the service request (e.g., request type, IMSI number, MSISDN number, sender, recipient, message text, customer name and address, or any other characteristics).

The web error GUI 314 accepts corrective input from the reviewer. The reviewer may instruct the web error GUI 314 to reissue the corrected service, task, or operation to the extractor system 304. The extractor system 304 receives the corrected service request message and processes the corrected service request, task or operation that replaces the original counterpart. In this manner, the extractor system 304 saves valuable time and processing resources by continuing the workflow that has been instantiated where the initial service request encountered the error.

A separate web error GUI may also be provided for the first extractor system 232. Rather than using the message publishing system 214, the web error GUI for the first extractor system 232 may pass error information through function calls defined in the API. The function call may be provided by the tibco inconcert (tm) workflow engine and the web error GUI may report error information and accept changes in the input and the counterpart described above for the web error GUI 314.

The service agent may also provide a workflow GUI 324. The workflow GUI 324 provides a graphical interface for workflow definition that provides wide configurability to service agents. The workflow GUI 324 implements a drag-and-drop interface through which an operator can select and customize tasks to create a new workflow.

FIG. 3 shows that the operator has sequenced four tasks 326, 328, 330, and 332 to form one example of a new workflow 334. Any number of tasks may be arranged in any order to define a new workflow that customizes the service agent for any functionality desired by the service provider. The workflow GUI 324 may provide a graphical display of workflows, tasks, and operations for one or more predefined workflows, tasks, and operations defined in the TOM database 316. The workflows, tasks, and operations can represent workflows, tasks, and operations defined in a workflow table 902, a task configuration table 904, and/or an operations table 906 described below.

An enhanced TOM database 316 is also provided in the service broker 302. Enhanced TOM database 316 extends first TOM database 244 to support second workflow system 306 and web error GUI 314. As will be explained in more detail below, the enhanced TOM database 316 defines the sequence of tasks and operations to be taken to fulfill a particular service request and provides a reporting table for the web error GUI 314.

Fig. 4 shows an example of traffic control parameters 234. In particular, FIG. 4 shows a function name parameter 402, a pool size parameter 404, and a polling time parameter 406. Fig. 4 also shows a commit timer parameter 408, a criteria parameter 410, and a standby parameter 412. The additional traffic control parameters include a wait parameter 414, a control lock parameter 416, and a data parameter 418.

Table 1 provides a description of each traffic control parameter 234 below:

the traffic control parameters 234 may dynamically reconfigure the extractor systems 232 and 304 at runtime. To this end, the traffic control parameters 234 may be passed to a traffic control manager process (e.g., via an HTTP connection, with the parameters embedded in the URL) inside the extractor systems 232 and 304. The traffic control manager may then set internal variables with new parameters for next fetching of the service request block.

Fig. 5 shows an example of an implementation of the distributor 216. The distributor 216 may include a processor 502 connected to a memory 504. The memory 504 stores an allocation program 506. The allocator 506 may be a multi-threaded process. The memory 504 also holds inbound messages 508 for processing by the dispatcher 506. The inbound message 508 includes a technical service procedure LABEL (TSO _ LABEL) field 510, a TSO _ ID field 511, and service request message data 512 that further defines the service request (e.g., by specifying SMS message data, the recipient, or other data that supports the service request). The TSO _ LABEL field provides a service type identifier field indicating the requested service.

The inbound message 508 may be an extensible markup language (XML) message that includes an identification tag around each data element in the message. The dispatcher 506 examines the XML data in the inbound message 508 and builds a service request record in the service queue 218 based on the tag field in the XML data. In particular, based on the service identifier field (e.g., based on TSO _ LABEL), the allocator 506 creates a service request record in a particular service queue based on TSO _ LABEL 510. In other words, the TSO _ LABEL 510 identifies the type of service request for the allocator 506, and thus the appropriate service queue in which the service request should exist.

Service queue 218 may be implemented as a database table. Fig. 5 shows an example of a service request record 514 that may be defined in the service queue 218. However, other service request record definitions may be implemented. The fields of the service request record 514 are illustrated in table 2 below.

TSO _ ID, TSO _ LABEL, and TSO _ DATE are stored in separate fields. When the allocator 506 receives the inbound message 508, the allocator may extract the TSO _ ID, TSO _ LABEL, and TSO _ DATE data, respectively, from the message 508 and store the data in the corresponding fields in the service request record 514. Extractor systems 232 and 304 may thus extract line data from the queue table through any field or combination of fields.

In one implementation, when the allocator 506 inserts a row in the service queue table with the new service request record 514, the allocator 506 inserts data for the following fields:

TSO_ID

TSO_LABEL

TSO_DATE

XML_IN

BP_FLAG＝0

AP_FLAG＝0

INS_TMS＝System Date

fig. 6 shows one implementation of extractor system 232. The extractor system 232 includes a processor 602 coupled to a memory 604. The memory 604 stores an extractor 606 (e.g., a multi-threaded process). The memory also holds a service request record line list 608. The entries in the service request record line list 608 point to service requests in the service queue 218.

The extractor 606 polls the service queue 218 as directed by the traffic control parameter 234. The extraction program 606 retrieves each pool TSO _ ID from the selected service request record. The extractor 606 may call a stored Structured Query Language (SQL) program to access the tables in the service queue 218.

The stored program may set BP _ FLAG to 1 for each row in service queue 218 that meets the search criteria provided by the extractor system. The stored program may return a row list 608 of rows that satisfy the search criteria to the extractor system 232. The row list 608 may include the TSO _ ID field from each matching service request record.

The extractor program 606 obtains the row list 608 from the stored program. The extractor program 606 then passes the row list 608 to the workflow invoker 610. The workflow invoker 610 invokes the workflow engine 236 to initiate execution of the appropriate workflow to execute each service request represented in the service request record identified in the row list.

More specifically, the workflow caller 610 processes the line list 608 asynchronously for each line. The workflow caller 610 WAITs for the WAIT time specified in the traffic control parameter 234. When the WAIT time has expired, the workflow invoker 610 sets BP _ FLAG to '2' for the service request record currently being processed.

The workflow caller 610 then calls the workflow system 236 directly to initiate a workflow that implements the service request associated with the current row. In calling to initiate a workflow, the workflow caller 610 may asynchronously pass the TSO _ ID field to the workflow system 236. The workflow invoker 610 then sets BP _ FLAG to' 3 to indicate that the workflow has been invoked.

In the workflow system 236, the workflow engine executes the workflow steps (e.g., any, operations, and TSO) that implement the particular service request. The first task performed by the workflow engine when executing a service request is to fetch XML _ IN data from the queue table. The workflow engine retrieves the XML _ IN data from the service request record that matches the TSO _ ID provided by the extractor system 232. The service workflow thus obtains a complete definition of the requested service, including support data for the requested service. For example, XML _ IN data for SMS message delivery would include message text and recipient identifier.

The TSO _ LABEL field specifies the requested service. The workflow performs the task of completing the requested service. For example, for SMS message delivery, the workflow engine may send a billing message to the billing system and then send the message text to the SMS delivery subsystem. The workflow engine also returns the results of the service request processing. For example, the workflow may return a success message and an error message, optionally with a specification or any other information resulting from the service request processing.

The workflow ends by updating the service request record for the applicable TSO _ ID. The workflow engine writes the XML _ OUT string into the service request record. The XML _ OUT string may include the result of the service request processing. In addition, the workflow engine sets AP _ FLAG to '1' to indicate that the workflow has ended, and sets END _ TMS to the current system date (i.e., date/time when the workflow is completed).

The workflow engine determines the tasks and operations to be performed and the order of execution by referencing a technical rules management (TOM) database 244. Fig. 7 shows one implementation of a data model for TOM database 244. The data model is not limited to the implementation shown in FIG. 7, but may vary widely depending on the particular implementation in which the data model is employed. TOM database 244 includes a service specification catalog (STOC) table 702, an operations table 704, and a STOC parameters table 706. TOM database 244 also includes a ClassBuild Table 708, a PutSequenceInclass Table 710, and a sequence Build Table 712.

The STOC table includes a STOC _ ID field 714 as a primary key and an additional field 716. The Action table includes an Action _ ID field 718 as a primary key and an additional field 720. The STOCParam table 706 includes a STOCParam _ ID field 722 as a primary key and an additional field 724. The ClassBuild table 708 includes a Param _ ID field 726 as the primary key and an additional field 728. The PutSequence inclass table 710 includes a PutSequence _ ID field 730 as a primary key and an additional field 732. The Sequence _ ID field is a primary key of the Sequence _ result table 712.

The STOC table 702 defines a workflow template referred to as a workflow step of a Technical Service Order (TSO) for processing service requests. The operations table 704 defines the TSOs (i.e., operations) and their order of execution to be performed to complete any given service request and links them back to the STOC table. In some implementations, the database 228 may define a reverse operation table similar to the operation table 704. When an error occurs in the course of processing an operation in the workflow, an associated reverse operation may be performed. The reverse operation may synchronize customer account status, procedure status, or other data between independent processing systems. TOM database 244 further defines parameters for operations that may be received from service requestors or may be provided by the workflow engine itself. Each of the tables 702-712, including additional fields, will be described in more detail below.

The workflow system 236 splits the service protocol processing into two tasks. The first task is to determine how to split the service request into TSOs by searching the workflow definition in TOM database 244. The second task is to manage the TSO by sending it in the correct sequence, receiving the response, and processing the error.

Based on the TSO _ LABEL and the definition established in the TOM database 244, the workflow system 236 determines the set of TSOs to be executed and their order. The workflow system 236 also builds a list of attributes for each TSO to be executed. Attributes may be specified in whole or in part by a service requestor (e.g., CRM system 122), and may also be specified in whole or in part by TOM database 244. As the TSO is executed, the workflow engine increments an index pointing to the currently executing TSO.

The workflow engine builds a message requesting execution of the TSO. For example, the message may be posted to a provisioning system that performs the operation specified in the message as part of fulfilling the entire service request. TOM database 244 supports the establishment of messages and provides the order in which TSOs should be executed, the attributes used for TSOs (e.g., static attributes specified within TOM database 244, and dynamic attributes submitted by service requesters), the body to which messages are published, and other parameters described above.

Accordingly, the TOM database 244 provides configuration rules that separate the service request workflow associated with the TSO _ LABEL into a set of TSOs that fulfill the service request. TOM database 244 thus provides an extremely flexible, reconfigurable, and extensible mechanism to define workflows, TSOs that implement workflows, and the order in which TSOs execute.

Fig. 8 shows an exemplary implementation of the second extractor system 304. The extractor system 304 may include a processor 802 connected to a memory 804. The memory 804 stores an extractor program 806 (e.g., a multi-threaded process). The memory also holds a service request record line list 808. The entries in the service request record line list 608 point to service requests queued in the service queue 218 and submitted by the third party gateway 110, the CRM system 122, or any other external service requester.

The extractor program 806 polls the service queue 218 as directed by the traffic control parameters 234 (or a separate set of traffic control parameters established for the extractor system 304). The extractor program 806 retrieves the block TSO _ ID from the matching service request record. The extractor program 806 may execute a stored Structured Query Language (SQL) program to access the tables in the service queue 218.

For each service request to be processed, the extractor program calls the instance manager program 814. The instance manager program populates the tables in the TOM database 316 to instantiate the workflow table for the service request. The TOM database tables are described in more detail below.

The extractor program 806 passes the line list 808 to the message publisher program 810. The message publisher 810 publishes a workflow request message 812 (specifying a service request) to the second workflow system 306. The extractor system 304 thus eliminates the potential bottleneck of directly invoking the workflow engine by allowing the message publishing system 214 to deliver workflow request messages to the second workflow system 306. The workflow request message may specify a TSO _ ID (in TSO _ ID field 814) and a TSO _ LABEL (in TSO _ LABEL field 816). The TSO _ ID and TSO _ LABEL are obtained from service records in the service queue 218. The extractor system 304 can wait for a response from the message publishing system 214 after the extractor system 304 publishes each workflow request message.

More specifically, the request/reply message may be defined as shown in tables 9-12 below:

TABLE 9 workflow request message
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><WORKFLOW_REQUESTxsi:noNamespaceSchemaLocation＝″BW_COMMON.xsd″><TSOID>TSO IDENTIFIER</TSOID><TSOLABEL>TSO LABEL VALUE</TSOLABEL><PARAM name＝″MSISDN″value＝″msisdn number″/><PARAM name＝″IMSI″value＝″imsi number″/></WORKFLOW_REQUEST>The MSISDN and IMSI values are optional.

TABLE 10 correctAcknowledge (reply)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><RESULT_STATUS xsi:noNamespaceSchemaLocation＝″BW_COMMON.xsd″><STATUS_CODE>0</STATUS_CODE></RESULT_STATUS>

TABLE 11-negative acknowledgement (reverts)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><RESULT_STATUS xsi:noNamespaceSchemaLocation＝″BW_COMMON.xsd″><STATUS_CODE>1</STATUS_CODE><ERROR_CODE>eai_10000</ERROR_CODE><ERROR_DESCRIPTION>Description</ERROR_DESCRIPTION></RESULT_STATUS>

TABLE 12 Common Schema (Common Schema)

<？xml version＝″1.0″encoding＝″UTF-8″？><xs:schema xmlns:xs＝″http://www.w3.org/2001/XMLSchema″elementFormDefault＝″qualified″attributeFormDefault＝″unqualified″><xs:element name＝″WORKFLOW_REQUEST″><xs:annotation><xs:documentation>Comment describing your rootelement</xs:documentation></xs:annotation><xs:complexType><xs:sequence><xs:element name＝″TSOID″type＝″xs:string″/><xs:element name＝″TSOLABEL″type＝″xs:string″/><xs:element name＝″PARAM″maxOccurs＝″unbounded″><xs:complex Type><xs:attribute name＝″name″type＝″xs:string″use＝″required″/><xs:attribute name＝″value″type＝″xs:string″use＝″required″/></xs:complexType></xs:element></xs:sequence></xs:complexType></xs:element><xs:element name＝″RESULT_STATUS″><xs:complexType><xs:all><xs:element name＝″STATUS_CODE″type＝″xs:int″/><xs:element name＝″ERROR_CODE″type＝″xs:string″minOccurs＝″0″/><xs:element name＝″ERROR_DESCRIPTION″type＝″xs:string″ minOccurs＝″0″/></xs:all></xs:complexType></xs:element></xs:schema>

Fig. 9 shows the enhancements provided in TOM database 316 in support of second extractor system 304. The sequence of steps taken to fulfill a service request is defined by a workflow table 902, a Task _ cfg table 904, and an operations table 906. In particular, the workflow table 902 defines workflow templates, the Task _ cfg table 904 defines tasks that implement workflows, and the operations table 906 defines operations associated with each Task. Tasks and operations may be performed, for example, by processes running in an external Tibco BusinessWorks (TM) processing system. A supporting task instance table 908 and a supporting operation instance table 910 are also provided. Each table will be described in more detail below.

The TASK _ INST table 908 may include the same fields as the TASK _ CFG table 904, and the following additional fields:

ACTION _ INST table 910 may include the same fields as ACTION table 906, and the following additional fields:

in addition, enhanced TOM database 316 provides support for web error GUI 314. In particular, enhanced TOM database 316 includes a GUI user table 912, a GUI role table 914, and a GUI status table 916. A GUI history table 918 is also included. Each table will be described in more detail below.

For each service request, the instance manager program 814 populates the TASK _ INST table 908 with the workflow TASK to be performed before issuing the corresponding service request message. The instance manager program 814 also populates the ACTION _ INST table 910 with provisioning operations within each task. The data that populates tables 908 and 910 is obtained from the templates defined in directory tables 902, 904, and 906. Thus, each service request to be processed has a workflow illustrated with a specific example prepared in the TASK _ INST table 908 and the ACTION _ INST table 910.

The second workflow system 306 receives the published workflow request message from the message publishing system 214. The workflow system 306 first processes the workflow request message through the inbound request manager 308.

Fig. 10 illustrates an exemplary flow diagram of operations 1000 taken by the inbound request manager 308. The inbound request manager 308 receives a published service request message published by the message publishing system 214 (operation 1002). The inbound request manager extracts the TSO _ ID from the service request message (operation 1004) and extracts the TSO _ LABEL from the service request message (operation 1006).

Using the TSO _ ID, the inbound request manager 308 searches the enhanced TOM database 314 for a specific instantiated workflow template that implements the service request represented by the TSO _ ID. If a template is not defined, the inbound request manager 308 returns a negative acknowledgement to the extractor system 304 (operation 1010). Otherwise, the inbound request manager 308 returns a correct acknowledgement to the extractor system 304 (operation 1012) and invokes the workflow engine 310 with the TSO _ ID and TSO _ LABEL (operation 1014).

FIG. 11 shows an exemplary flowchart of operations 1100 taken by the workflow manager 310. The workflow manager 310 receives the TSO _ ID and TSO _ LABEL from the inbound request manager 308 (operation 1102). The workflow engine 310 then retrieves the workflow TASKs within the workflow template from the TASK _ INST table 808 (operation 1104).

If there are any tasks in the workflow, the workflow engine 310 executes the next task in order (operation 1106). To do so, the workflow engine 310 invokes the sub-process identified for the TASK in the TASK _ INST table 808. For sequentially invoked tasks, the workflow engine 310 invokes the task sub-process and waits for a response from the sub-process (operation 1108). For tasks that can be invoked in parallel with other tasks, the workflow engine 310 invokes the task sub-process and continues on to the next task without waiting (operation 1110).

Some states are defined for the task. The workflow engine 304 and the web error GUI 314 may establish and maintain these states during the course of performing tasks. The initial state of the task is 'I' (initial) and the end state may be 'D' (done) or 'C' (forced). At the beginning, each task may have a state set to 'I'. When the workflow engine 310 calls a sub-process for executing a task, the task state changes to 'X' (execution). The 'X' state indicates that the sub-process is performing a task.

Successful completion of the task and receipt of a response from the sub-process will cause the task to go to the 'D' (complete) state. The workflow engine 310 in the workflow system 306 may then move to the next task in the workflow. If the sub-process replies with an error, the workflow engine 310 may set the task state to 'E' (error). In response, the workflow engine 310 passes the task to the web error GUI 314.

As described above, the web error GUI 314 provides an interface through which an operator may correct message content, skip a task, or resubmit a (corrected) task for processing. When a task is resubmitted, the task state goes to 'R' (resubmission). The workflow system 306 receives the resubmitted task, executes the sub-process that processes the task, and sets the task state back to 'X'. For tasks with error status 'E', the workflow engine 310 stops executing tasks. The web error GUI 314 may restart the task by issuing a request/reply message to the workflow system 306 requesting processing of the task.

If the web error GUI 314 skips the task, the task state is set to 'C' (complete). Additionally, the operator may control the performance of tasks via the web error GUI 314. The operator may issue a request through the web error GUI 314 to force the task to complete immediately (turning the task to the 'C' state), or may force the task to resubmit (turning the task to the 'R' state). The workflow system 306 considers the 'C' state to be the final state and, in response, proceeds to the next task in the workflow sequence.

FIG. 12 shows one example of operations 1200 taken by the parallel task manager 312. A particular task may be designated as a parallel task that may run concurrently with other tasks. However, some tasks may require results obtained by other tasks to be processed. Thus, the parallel task manager 312 monitors responses from sub-processes executing parallel tasks (operation 1202), obtains responses (operation 1204), and provides responses (e.g., by the workflow engine 310) to other tasks waiting for a response before being able to continue (operation 1206). Thus, the parallel task manager 312 thus works to open (unblock) tasks that are in an interrupt, waiting for input data.

As described above, the workflow system 306 also includes an operations engine 318. The operation engine 318 performs network provisioning operations within a separate task. In other words, if the enhanced TOM database 316 specifies a network provisioning operation for a particular task, the second workflow system 306 may invoke the operations engine 318 to process the operation.

The operations engine 318 includes two layers: an operations manager 320 and an operations orchestrator 322. The operations manager 320 determines and initiates execution of provisioning operations in the correct sequence as defined in the TOM database. The operation orchestrator 322 creates and sends appropriate messages to the message publishing system 214 to request performance of the operation, and also receives responses from the message publishing system 214.

The operations engine 318 executes in a similar manner as the workflow engine 310 (FIG. 11). More specifically, the operations engine 318 receives a request to process a task in a workflow. In response, the operation manager 320 retrieves the operations performed for the task from the ACTION _ INST table 810.

For each operation to be performed, the operation manager 320 calls the operation orchestrator 322. If the operations are not independent (i.e., not executed in parallel), the operation manager 320 waits for a response from the operation orchestrator 322. Otherwise, the operation manager 320 initiates execution of the next operation in the sequence without waiting for a response from the operation orchestrator 322. The web error GUI 314 may also manage errors that occur during the course of performing operations in the same manner and with the same state transitions as task errors.

The operation orchestrator 322 builds and sends operation request messages to the message publishing system 214 for delivery to the system or process that is to perform the operation. The operation orchestrator 322 receives a response from the message publishing system 214 that results from the execution of the operation. The operation orchestrator 322 sends the response back to the operation manager 320. Depending on the response, the operation manager 320 may process any errors (e.g., via the web error GUI 314) or may perform the next network operation, if any.

Workflows, tasks, and operations may be defined for a wide range of service requests. As an example, the workflow of activating a UMTS Subscriber Identity Module (USIM) may be associated with TSO _ LABEL of "ACTIVATE _ USM" and may be divided into the following tasks: activating core basic services (providing, for example, the relevant IMSI and MSISDN), changing messaging services (e.g., to provide MSISDN and customer name to the relevant messaging services), and changing alerting services (e.g., to provide customer name, date of birth, address, or other customer information to the alerting services). Other examples of workflows associated with service requests from the CRM system 122 include workflows that: changing the USIM, pausing the USIM, continuing the USIM, changing the MSISDN number, deactivating the handset, pre-activating a prepaid or post-paid USIM, activating services, terminating services, and terminating the USIM.

The service broker 116 processes service requests for a number of telecommunications services. One task of the service broker 116 is to process service requests received from the third party gateway 110. Generally, the service broker 116 maps inbound service requests into a sequence of steps (e.g., tasks and operations) taken to fulfill the service request. The service broker 116 delivers a request to perform each step to the appropriate system or process, determines the results, and communicates with the third party gateway 110 regarding the results.

Fig. 13 shows an example of a message flow resulting from an authentication service request received from a third party gateway 110 (flow 1302). The third party gateway 110 may send an authentication request (including information for identifying the user, such as the MSISDN and/or IMSI number) when, for example, the user needs to be identified before they can purchase the service. The service agent 116 submits a request for a user profile to the directory system (flow 1304), and the directory system returns the user profile (flow 1306).

The service broker 116 returns the result to the third party gateway 110 (flow 1308). If the directory system is unable to authenticate the user, the service broker 116 returns an unauthorized message to the third party gateway. Otherwise, the service agent 116 returns an authorization message with the user profile data. When the user is authorized, the service agent 116 may then request additional information about the user from the directory system in the form of a request for a user service profile (flow 1310), and the directory system returns a profile (flow 1312).

The service agent 116 returns the result to the third party gateway 110 (flow 1314). If the profile information is not available, the service broker 116 returns an unauthorized message to the third party gateway 110. Otherwise, the service broker 116 returns an authorization message with the service profile data.

Tables 22 and 23 show examples of authentication service request messages and responses.

Table 22-XML input (authentication)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″ TSOlabel＝″USERSEAMLESSAUTHENTICATION″/><TSOattributes><attribute name＝″IPADDRESS″value＝″10.212.32.43″/><attribute name＝″SERVICEID″value＝″55555″/><attribute name＝″PROVIDERID″value＝″88888″/></TSOattributes></TSO_DATA>

Table 23-XML output (authentication)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″ TSOlabel＝″USERSEAMLESSAUTHENTICATION″/><TSOattributes><attribute name＝″ACCOUNTID″value＝″55555″/><attribute name＝″NETSTATUS″value＝″OK″/><attribute name＝″LOCATION″value＝″xxx″/><attribute name＝″TYPEOFACCESS″value＝″MEGA″/><attribute name＝″SERVICESTATUS″value＝″OK″/><attribute name＝″SERVICEDATA″value＝″test@testnet.com″/></TSOattributes><TSOresult><statusCode>O</statusCode><errorCode></errorCode><errorDescription></errorDescription></TSOresult></TSO_DATA>

Fig. 14 shows an example of a message flow resulting from a billing service request received from a third party gateway 110 (flow 1402). The third party gateway 110 may send a billing request to charge the user account for the amount of service. Service agent 116 submits a charging request including the amount charged to the billing system (flow 1404). The billing system charges the account for the service and returns the resulting status to the service agent 116 (flow 1406). The service broker 116 returns the resulting status to the third party gateway 110 (flow 1408).

Tables 24 and 25 show examples of billing service request messages and responses.

Table 24-XML input (billing)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″charGESERVICE″/><TSOattributes><attribute name＝″SERVICEID″value＝″55555″/><attribute name＝″STARTDATE″value＝″05/05/2004″/><attribute name＝″ENDDATE″value＝″10/05/2004″/><attribute name＝″ACCOUNTID″value＝″77777″/></TSOattributes></TSO_DATA>

Table 25-XML output (billing)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″charGESERVICE″/><TSOresult><statusCode>O</statusCode><errorCode></errorCode><errorDescription></errorDescription></TSOresult></TSO_DATA>

Fig. 15 shows an example of a message flow resulting from an SMS delivery service request received from a third party gateway 110 (flow 1502). The third party gateway 110 may send an SMS request to bill the user's account and deliver the SMS message. The service agent 116 requests the billing system to charge the account for the service (flow 1504) and receives the resulting status from the billing system (flow 1506). The service broker 116 returns the resulting status to the third party gateway 110 (flow 1508). The service agent 116 then invokes an SMS process or system over the network interface to send an SMS (flow 1510) and receive an acknowledgement (flow 1512). The service agent 116 may continue to retry sending SMS messages in the event of an error.

Tables 26 and 27 show examples of SMS service request messages and responses.

Table 26-XML input (SMS)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″SMSDELIVERY″/><TSOattributes><attribute name＝″SERVICE_TYPE″value＝″SMS″/><attribute name＝″SENDERADDRESS″value＝″M-Site″/><attribute name＝″SERVICEID″value＝″55555″/><attribute name＝″STARTDATE″value＝″05/05/2004″/><attribute name＝″ENDDATE″value＝″10/05/2004″/><attribute name＝″PRIORITY″value＝″High″/><attribute name＝″SUBJECT″value＝″Message″/><attribute name＝″ACCOUNTID″value＝″77777″/><attribute name＝″MESSAGE_BODY″value＝″Message Body″/><list name＝″TO_ADDRESSEE″value＝″3″><attribute name＝″1″value＝″+39xxxx″/><attribute name＝″2″value＝″+39xxxx″/><attribute name＝″3″value＝″+39xxxx″/></list><list name＝″CC_ADDRESSEE″value＝″4″><attribute name＝″1″value＝″+39xxxx″/><attribute name＝″2″value＝″+39xxxx″/><attribute name＝″3″value＝″+39xxxx″/><attribute name＝″4″value＝″+39xxxx″/></list><list name＝″BCC_ADDRESSEE″value＝″3″><attribute name＝″1″value＝″+39xxxx″/><attribute name＝″2″value＝″+39xxxx″/><attribute name＝″3″value＝″+39xxxx″/></list></TSOattributes></TSO_DATA>

Table 27-XML output (SMS)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″SMSDELIVERY″/><TSOresult><statusCode>O</statusCode><errorCode></errorCode><errorDescription></errorDescription></TSOresult></TSO_DATA>

Fig. 16 shows an example of a message flow resulting from an MMS delivery service request received from a third party gateway 110 (flow 1602). The third party gateway 110 may send an MMS request to charge the user account and deliver the MMS message. Service agent 116 requests the billing system to charge the account for the service (flow 1604) and receives the resulting status from the billing system (flow 1606). The service broker 116 returns the resulting status to the third party gateway 110 (flow 1608). The service broker 116 then invokes an MMS process or system via the network interface to send an MMS (flow 1610) and receive an acknowledgement (flow 1612). The service broker 116 may continue to retry sending MMS messages in the event of an error.

Tables 28 and 29 show examples of MMS service request messages and responses.

Table 28-XML input (MMS)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″MMSDELIVERY″/><TSOattributes><attribute name＝″SERVICE_TYPE″value＝″MMS″/><attribute name＝″SENDERADDRESS″value＝″M-Site″/><attribute name＝″SERVICEID″value＝″55555″/><attribute name＝″STARTDATE″value＝″05/05/2004″/><attribute name＝″ENDDATE″value＝″10/05/2004″/><attribute name＝″PRIORITY″value＝″High″/><attribute name＝″SUBJECT″value＝″Message″/><attribute name＝″ACCOUNTID″value＝″77777″/><attribute name＝″MESSAGE_BODY″value＝″Message Body″/><list name＝″TO_ADDRESSEE″value＝″3″><attribute name＝″1″value＝″+39xxxx″/><attribute name＝″2″value＝″+39xxxx″/><attribute name＝″3″value＝″+39xxxx″/></list><list name＝″CC_ADDRESSEE″value＝″4″><attribute name＝″1″value＝″+39xxxx″/><attribute name＝″2″value＝″+39xxxx″/><attribute name＝″3″value＝″+39xxxx″/><attribute name＝″4″value＝″+39xxxx″/></list><list name＝″BCC_ADDRESSEE″value＝″3″><attribute name＝″1″value＝″+39xxxx″/><attribute name＝″2″value＝″+39xxxx″/><attribute name＝″3″value＝″+39xxxx″/></list></TSOattributes></TSO_DATA>

Table 29-XML output (MMS)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″MMSDE LIVERY″/><TSOresult><statusCode>O</statusCode><errorCode></errorCode><errorDescription></errorDescription></TSOresult></TSO_DATA>

Figure 17 shows an example of a message flow resulting from a Session Initiation Protocol (SIP) service request received from a third party gateway 110 (flow 1702). The third party gateway 110 may send a SIP request to establish the SIP call and charge a fee to the user account. The service agent 116 requests the billing system to charge the account for the service (flow 1704) and receives the resulting status from the billing system (flow 1706). The service broker 116 returns the resulting status to the third party gateway 110 (flow 1708). The service agent 116 then invokes a SIP process or system through the network interface to establish a SIP connection (flow 1710) and receives an acknowledgement (flow 1712). The service agent 116 may continue to retry establishing the SIP connection in the event of an error.

Tables 30 and 31 show examples of SIP service request messages and responses.

Table 30-XML input (SIP)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″SIPCALL″/><TSOattributes><attribute name＝″SERVICEID″value＝″55555″/><attribute name＝″STARTDATE″value＝″05/05/2004″/><attribute name＝″ENDDATE″value＝″10/05/2004″/><attribute name＝″ACCOUNTID″value＝″77777″/><attribute name＝″SENDERURI″value＝″http://10.212.23.30″/><attribute name＝″RECEIVERURI″value＝″http://12.234，45.23″/></TSOattributes></TSO_DATA>

Table 31-XML output (SIP)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″SIPCALL″/><TSOresult><statusCode>O</statusCode><errorCode></errorCode><errorDescription></errorDescription></TSOresult></TSO_DATA>

Fig. 18 shows an example of a message flow resulting from a user status service request received from a third party gateway 110 (flow 1802). The third party gateway 110 may send a status request to perform an online presence check of other users. The service agent 116 sends a status request message to the directory system (flow 1804) and the directory system returns the user status (flow 1806). The service broker 116 returns the user status to the third party gateway (flow 1808).

Tables 32 and 33 show examples of stateful service request messages and responses.

Table 32-XML input (State)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″GETUSERSSTATUS″/><TSOattributes><attribute name＝″CATEGORYID″value＝″″/><attribute name＝″USERID″value＝″test.user@testemail″/><attribute name＝″SERVICEID″value＝″acc00143423001″/></TSOattributes></TSO_DATA>

Table 33-XML output (Status)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″GETUSERSSTATUS″/><TSOattributes><list name＝″USERSID″value＝″3″><attribute name＝″1″value＝″test.user@testmail″/></list><list name＝″USERSSTATUS″value＝″3″><attribute name＝″1″value＝″ONLINE″/> </list></TSOattributes><TSOresult><statusCode>O</statusCode><errorCode></errorCode><errorDescription></errorDescription></TSOresult></TSO_DATA>

Fig. 19 shows an example of a message flow resulting from a mobile subscriber status authentication service request received from a third party gateway 110 (flow 1902). The third party gateway 110 may send an authentication request (including information for identifying the user, such as the MSISDN and/or IMSI number) when, for example, the user needs to be identified before they can purchase a service, such as an Internet Protocol Television (IPTV) service. The service agent 116 submits a request for user service data (e.g., the user's network characteristics) to the directory system (flow 1904), and the directory system returns the user service data (flow 1906).

The service broker 116 returns the results to the third party gateway 110 (flow 1908). If the directory system is unable to authenticate the user, the service broker 116 returns an unauthorized message to the third party gateway. Otherwise, the service broker 116 returns an authorization message with the user service data. When the user is authorized, the service agent 116 may then request additional information about the user from the directory system in the form of a request for the user to apply a service profile (flow 1910), and the directory system returns a profile (flow 1912).

The service broker 116 returns the result to the third party gateway 110 (flow 1914). If the application service information is not available, the service broker 116 returns an unauthorized message to the third party gateway 110. Otherwise, the service broker 116 returns an authorization message with the application service data.

Tables 34 and 35 show examples of mobile subscriber authentication service request messages and responses.

Table 34-XML input (Mobile authentication)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″ TSOlabel＝″GETAPPLICATIONSERVICEDATA″/><TSOattributes><attribute name＝″MSISDN″value＝″3473626805″/><attribute name＝″SERVICEID″value＝″acc001005001″/></TSOattributes></TSO_DATA>

Table 35-XML output (Mobile authentication)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″GETAPPLICATIONSERVICEDATA″/><TSOattributes><attribute name＝″SERVICESTATUS″value＝″OK″/><list name＝″SERVICETECHNICALPROFILE″><attribute name＝″COUNTRYCODE″value＝″0039″/><attribute name＝″ROAMINGSTATUS″value＝″Status″/><attribute name＝″ACCESSCHANNEL″value＝″Pluto″/><attribute name＝″ROAMINGPARTNER″value＝″H3G″/><attribute name＝″CUSTOMERTYPE″value＝″Type″/><attribute name＝″PLANID″value＝″ID″/><attribute name＝″SIMTYPE″value＝″PREPAID″/><attribute name＝″TERMINALMODE″value＝″DUAL″/><attribute name＝″MMSSTATUS″value＝″OK″/><attribute name＝″UMTSSTATUS″value＝″OK″/><attribute name＝″GPRSSTATUS″value＝″OK″/></list></TSOattributes></TSO_DATA>

Fig. 20 shows an example of a message flow generated by an IPTV user authentication request received from the third party gateway 110 (flow 2002). The third party gateway 110 may send an authentication request (including information for identifying the user, such as the MSISDN and/or the IMIS number, allowing the user to use the service) when, for example, the user attempts to connect to a mobile IPTV application. The service broker 116 submits a request for user service data (e.g., network characteristics of the user) to the directory system (flow 2004), and the directory system returns the user service data (flow 2006).

The service broker 116 returns the result to the third party gateway 110 (flow 2008). If the directory system is unable to authenticate the user, the service broker 116 returns an unauthorized message to the third party gateway. Otherwise, the service broker 116 returns an authorization message with the user service data. When the user is authorized, the service broker 116 may then request additional information about the user from the directory system in the form of a request for the user to apply a service profile (flow 2010), and the directory system returns the profile (flow 2012).

The service broker 116 returns the result to the third party gateway 110 (flow 2014). If the application service information is not available, the service broker 116 returns an unauthorized message to the third party gateway 110. Otherwise, the service broker 116 returns an authorization message with the application service data.

Tables 36 and 37 show examples of IPTV user authentication service request messages and responses.

Table 36-XML input (IPTV authentication)
	<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″TSOlabel＝″GETAPPLICATIONSERVICEDATA″/><TSOattributes><attribute name＝″IPADDRESS″value＝″80.117.120.203″/><attribute name＝″SERVICEID″value＝″acc001004001″/></TSOattributes></TSO_DATA>

Table 37-XML output (IPTV authentication)

<？xml version＝″1.0″encoding＝″ISO-8859-1″？><TSO_DATA><TSOheader TSOID＝″12345″ TSOlabel＝″GETAPPLICATIONSERVICEDATA″/><TSOattributes><attribute name＝″SERVICESTATUS″value＝″OK″/><list name＝″SERVICETECHNICALPROFILE″><attribute name＝″ACCOUNTID″value＝″03403432″/><attribute name＝″ACCFIRSTNAME″value＝″Name″/><attribute name＝″ACCLASTNAME value＝″Name″/><attribute name＝″ACC BILLCITY″value＝″City″/><attribute name＝″ACCBILLADDRESS1″vaIue＝″Address″/><attribute name＝″ACCBILLREGION″value＝″Region″/><attribute name＝″ACCBILLPOSTALCODE″value＝″000100″/><attribute name＝″ACCBILLCOUNTRY″value＝″Country″/></list></TSOatt ributes></TSO_DATA>

Regardless of the particular implementation described, all of the above discussions are exemplary in nature, and not limiting. For example, although selected aspects, features, or components of the implementations are described as being stored in memory, all or portions of systems and methods consistent with a service broker may be stored on, distributed across, or read from: other machine-readable media, such as secondary storage devices, such as hard disks, floppy disks, and CD-ROMs; a signal received from a network; or other forms of ROM or RAM now known or later developed.

Moreover, although specific components of a service broker architecture are described, methods, systems, and articles of manufacture consistent with the service broker architecture may include additional or different components. For example, a processor may be implemented as a microprocessor, microcontroller, Application Specific Integrated Circuit (ASIC), discrete logic, or other type of circuit or combination of logic elements. Similarly, the memory may be DRAM, SRAM, flash, or any other type of memory. The tags, data, databases, tables, and other data structures may be stored and managed separately, may be consolidated into a single memory or database, may be distributed, or may be logically and physically organized in many different ways. The program may be part of a single program, a stand-alone program, or distributed across several memories and processors. The system may be implemented in hardware, software, or a combination of hardware and software in one processing system or distributed across multiple processing systems.

The service broker layer overcomes technical challenges associated with processing external service requests. Allocating service requests into queues solves the technical challenge of receiving and organizing extremely large numbers of simultaneous or near-simultaneous service requests. The multiple extractor and workflow engine architecture addresses the following technical challenges: the method includes extracting service requests in an organized and efficient manner, performing the extracted service requests to actually implement processing of the requests, providing error-tolerant service request processing, and maximizing performance of the service request processing.

While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.

Claims (20)

1. A service request processing system for a telecommunications architecture, the service request processing system comprising:

a service request interface that receives service requests for telecommunications services, each service request comprising a service type identifier field and a service request identifier field;

an allocator system that allocates the service requests into different service queues based on the service type identifier field, thereby establishing queued service requests;

a plurality of independent extractor systems that obtain a selected service request identifier from the service request identifier field of the queued service request for processing; and

a workflow system that initiates a workflow sequence that implements the queued service request identified by the selected service request identifier,

wherein at least one of the extractor systems takes the queued service request under control of traffic control parameters.

2. The service request processing system of claim 1, wherein the different service queue comprises:

a customer relationship management service request queue; and

a third party service request queue.

3. The service request processing system of claim 2, wherein the third party service request queue comprises:

a message service request queue; and

a service request queue is charged.

4. The service request processing system of claim 3, wherein the message service request queue comprises a short message service request queue.

5. The service request processing system of claim 3, wherein the message service request queue comprises a multimedia message service request queue.

6. The service request processing system of claim 2, wherein the third party service request queue comprises:

an authentication request queue; and

a status request queue.

7. The service request processing system of claim 6, wherein the authentication request queue comprises a mobile user authentication request queue.

8. The service request processing system of claim 2, wherein the customer relationship management service request queue comprises:

activating a service request queue; and

the service request queue is terminated.

9. The service request processing system of claim 1, wherein the different service queue comprises a database table comprising input message fields and output message fields.

10. A method for processing a telecommunication service request, the method comprising:

receiving service requests for telecommunication services, each service request comprising a service type identifier field and a service request identifier field;

allocating the service requests into different service queues based on the service type identifier field, thereby establishing queued service requests;

establishing service control parameters;

initiating execution of a plurality of independent extractor systems to retrieve the queued service request under control of the traffic control parameter and to obtain a selected service request identifier from the service request identifier field; and

initiating a workflow that implements the queued service request identified by the selected service request identifier.

11. The method of claim 10, wherein said initiating execution of a plurality of independent extractor systems comprises:

initiating execution of a first extractor system;

initiating execution of a second extractor system; and is

Wherein the initiating workflow comprises:

transmitting a first one of the selected service request identifiers to a first workflow engine for the first extractor engine; and

transmitting a second one of the selected service request identifiers to a second workflow engine for the second extractor engine.

12. The method of claim 10, wherein the assigning comprises:

distributing the service requests among:

a customer relationship management service request queue; and

a third party service request queue.

13. The method of claim 12, wherein the third party service request queue comprises a message service request queue.

14. The method of claim 13, wherein the message service request queue comprises a short message service request queue.

15. The method of claim 13, wherein the message service request queue comprises a multimedia message service request queue.

16. The method of claim 12, wherein the third party service request queue comprises:

an authentication request queue; and

a status request queue.

17. The method of claim 16, wherein the authentication request queue comprises a mobile user authentication request queue.

18. The method of claim 10, wherein the different service queue comprises a database queue table.

19. The method of claim 18, wherein the database queue table includes a 'processing status' field indicating whether a queue entry has been extracted.

20. The method of claim 19, wherein the database queue table includes a 'processing complete' field indicating whether processing of the queue entry has been completed.