WO2004059905A1

WO2004059905A1 - Integrating, generating and managing services in a telecommunication network

Info

Publication number: WO2004059905A1
Application number: PCT/BR2003/000206
Authority: WO
Inventors: Ricardo Santoro; Nobile Oristanio; Gilberto Carayde Assis Junior; Cláudio Márcio SILVEIRA; Rodrigo Carvalho Dos Santos; Glauco Galves Bordin; Cesar Lourenco Botti Filho; Luciano Haiek; Marcos Roberto Macedo
Original assignee: Bcp S/A
Priority date: 2002-12-30
Filing date: 2003-12-30
Publication date: 2004-07-15
Also published as: BR0205203A; AU2003287798A1

Abstract

System of integrating and managing services comprising an interface module associated to a processing nucleus by means of standard transport messages, and at least on adapting module selectively associated to the processing nucleus by means of a message distributing module arranged in the processing nucleus. The interface module comprises a receiving means, which receives different protocols and a converting means, which changes the different protocols into standard transport messages. The different protocols come from the various service-providing entities connected, for instance, to a mobile phone network.

Description

INTEGRATING, GENERATING AND MANAGING SERVICES IN A TELECOMMUNICATION NETWORK

The present invention relates to a system of integrating and managing services, particularly used in mobile telephone networks, capable of providing interactivity between different service-rendering systems and the structures of the telephony networks, and to a process of integrating and managing services, applied to telephony networks. Description of the Prior Art The operators of mobile telephone networks have made a significant investment to build robust networks, capable of meeting their business models. However, these networks are becoming larger and more complex, many of them being formed by network elements of suppliers and various protocols. All this complexity makes the development of a product time consuming and expensive, since there is a need for integrating the new applications and products with the elements of the network. This need is mainly caused by dependence to which these new products are subjected at present with respect to the telephony network. Thus, with each implementation of a new product for the mobile telephone network it is necessary to develop an entire new infrastructure of connection and integration between the platforms that provide the proposed service and the network. In addition, there is the need for implementing the management and charge services by the new service to be rendered. In this case, the teams of Engineering, Information technology, in addition to the teams of implantation of new products, Management and Charge, which makes the process slow and expensive for the company responsible for the mobile telephone network.

Moreover, further with regard to the presently known form for implementation of new products in the mobile telephone network, it is known that the number of physical connections of some platforms that provide service for telephony network are limited, which sometimes requires enlarge- ment of platforms with which one need to communicate. Further, there is the problem of the time spent and the complexity involved in meeting the necessary communication protocols between the service-providing platforms and the charging system, since each requested platform has charging-system model of its own.

Other interfaces and integration systems used in mobile telephony network are known from the prior art. However, these have not been developed for the purpose of optimizing the implantations of new products and services in the network by optimizing the connection and communication be- tween these services and the network.

As an example, one may cite the prior-art document US H1.894, which relates to an interface system of integrating modules for managing and monitoring platforms of telecommunication networks, the function of which is to deal with different languages or systems aiming at the integration thereof. However, this system is directed to the communication and control central, among others, which are responsible for the voice treatment, that is to say, the improvements described in this system are not capable of generating an interface between the platforms that provide new services and the mobile telephone network. Also, document WO 00/01102 relates to an interface system of integrating Management and Monitoring of Platforms of Telecommunication Networks, but directed to communication protocols responsible for signaling among the network platforms, as for example, frame relay.

Finally, document US 5,867,495 discloses an architecture that searches the junction of the Internet with the telephony system. This system consists of a hybrid network, based on the transfer of information over the Internet by using telephony routine and protocol information of the Internet itself. Objectives of the Invention The present invention has the objective of providing the integration and the management of communication messages between providers of different services and the serve platforms of the mobile telephone networks. Another objective of this invention is to provide the optimization of the processes of developing and implanting new products or services associated to the mobile telephony.

A further objective of the present invention is to decrease the costs for integration of new platforms that provide services with the mobile telephone networks.

It is also an objective of this invention provides a process to interact and manage services applied to telephony networks. Brief Description of the Invention The objective of the invention is to provide a system of integrating and managing services particularly utilized in telephony networks, the service integrating and monitoring system being characterized by comprising: an interface module comprising a means of receiving different protocols and a means of converting the different protocols into standard transport messages (STM); a processing nucleus comprising a plurality of modules of controlling and managing transactions from said standard transport messages; and at least one adapting module for communication with each plat- form that one wishes to communicate, comprising a controlling module selectively associated to the processing nucleus and at least one providing module associated to a platform of the telephony network.

It is also an objective of this invention to provide a process of integrating and managing services particularly utilized in telephony networks, the integration and monitoring process comprising the following steps:

A) Receiving a requisition for a service by means of a different protocol;

B) Converting the different protocol into a standard transport message (STM);

C) Transmitting the standard transport message (STM) to a processing nucleus;

D) Distributing and processing transactions by means of controlling and processing modules arranged in the processing nucleus; E) Opening a transaction detail record (TDR);

F) Sending an order of execution to at least o adapting module;

G) Completing the requested requisition and sending the results of the transactions to the processing nucleus; and H) Closing the transaction detail record (TDR).

Brief Description of the Drawings

The present invention will now be described in greater detail with reference to an embodiment represented in the drawings. The figures show:

- Figure 1 is a block diagram representing the interface system of integrating and managing services of the present invention;

- Figure 2 is a block diagram of the interface module;

- Figure 3 is a schematic diagram of the formation of the standard transport message STM that composes the object of this invention;

- Figure 4 is a detailed block diagram of the interface system of integrating and managing services of the present invention;

- Figure 5 is a schematic block diagram of the communication between the controlling module and at least one providing module; and

- Figure 6 is a flowchart of the main embodiment of the process of integrating and managing services of the present invention. Detailed Description of the Figures

According to a preferred embodiment and as can be seen in Figure 1 , the services integrating and managing system of the present invention comprises an interface module 10 associated to a processing nucleus 20 by means of standard transport messages (STM), and at least one adapting module 30 selectively associated to the processing nucleus 20 by means of a message distributing module 21 , arranged in the processing nucleus 20.

As illustrated in Figure 2, the interface module 10 comprises a receiving means 11 , which receives the different protocols 40, and a converting means 12, which changes the different protocols 40 into standard trans- port messages STM. The different protocols 40 come from the various service-providing entities connected to the mobile telephone network.

The means 40 for receiving different protocols is an end interface 11 , the function of which is to implement the means or protocols of communication between the entities that provide theses protocols and the telephony network.

These external interface 11 receives the requisition of services in the various original formats of the different protocols 40, as for example, HTTP, XML, SMPP, JAVA MAIL, among others, and sends them to the converting means, which is the internal interface 12 by means of a message transport system 101 of the RMI (Remote Method Invocation) type, which enables a module to send messages to another remote module as if it were locally accessed, besides helping in the processing distribution.

The internal interface 12 comprises a converter 102, the function of which is to transform the different protocols 40 received from the external interface 11 into standard transport messages STM, which is the common protocol of communication between the interface module 10, the processing nucleus 20 and the adapting modules 30.

According to Figure 3, the standard transport message STM comprises two portions, the first one being of information 52, which identifies the requested product, and the second one being of data 53, which comprises data of the requested service. ' The information portion 52 is provided with two subdivisions, the first subdivision comprising protocol presentation data 54 and the second subdivision comprising control data 55. The data portion 53 is provided with a single subdivision comprising variable information of the applications.

Both the presentation data subdivision 54 and the control data subdivision 55 are formed by storing layers 50, where the information and the data obtained from the conversion of the different protocols 40 are allocated.

Thus, the converting mechanism 102 decomposes the different protocol 40 and allocates, distributes, its data and information in the specific storage layers 50 of the information portion 52 of the standard transport mes- sage STM. During the transport of this standard message STM by the integration and management system, the storage layers 50 are read by the respective modules that compose the processing nucleus 20 and by the adapt- ing module 30, and the transactions requisitioned are carried out.

Each implementation of a new internal interface 11 for the communication with different protocols 40, a converter 102 is also created, which is capable of transforming the contents of the new different protocol 40 to a standard transport message STM.

During the transformation of the different protocol 40 into a standard transport message STM, the internal interface 12 generates a transaction identifier 51 , which is also allocated in one of the layers that form the STM message. This transaction identifier 51 is single for each procedure re- quested and allows the service integration and management system to administer and monitor the course of each request for service carried out. Each request for service generates a transaction.

Starting from the interface module 10, it is possible to provide the communication of the various platforms that provide services with the teleph- ony network, even if such platforms have a communication protocol different from that utilized by the network. Thus, when a new product/service is proposed to a service provider, the latter will not have to take into consideration the type of communication product utilized by the telephony network in order to develop its product, that is to say, it will not have to worry about the inte- gration of its new product/service with the telephony network, since, independently of its type of communication protocol, the internal interface 12 of the interface module 10 will make the transformation of the latter into a standard transport message STM, common to all the other modules existing in the network. For this reason, the development and the implementation of this product/service is no longer complex and time consuming, since the products are no longer dependent upon the telephony network.

Another advantage of this system is the fact that it provides the optimization of the costs relating to the connection of new platforms that provide services to the telephony network, since it decreases the complexity of the integration of these new platforms in a considerably extent.

According to Figure 4, the processing nucleus 20 comprises a plurality of transaction control and management modules. Among the control and management modules, there is the message distribution module 21, which accounts for reading, priorization and distribution of the transactions for the other modules of the processing nucleus 20. The distribution module 21 is permanently in contact with a storage module 22, where the requisitions are recorded and stored in lines, which will later be consumed by the adapting modules 30.

By means of a priorization algorithm, the message distribution module 21 reads out the requisitions, which are stored in the storage module 22, and arranges these requisitions in order of priority. This priorization algorithm is called "priority line", and the line of requisitions is generated by order or priority by means of it.

The degree of priority of the requisition may be calculated by the algorithm in order to prevent non-execution of a requisition that is originally of low priority, in the face of the existence of so many other requisitions that are originally of high priority. For this purpose, this algorithm has a formula of priority described as:

Priority = p(n){n*m+d} Wherein: p is the function of the priority calculation; n is the original priority of the requisition; m is a multiplication factor; and d is the date of requisition in milliseconds. By means of this formula, the priorization algorithm pays attention to the low-priority requisitions, but these should have an advanced date, which means that other requisitions with higher priority have already been met. It is by means of the multiplication factor that one can detect the advanced date of a determined requisition.

Once the requisitions have been given priority, they are distributed to the other modules of the processing nucleus 20. The execution mechanism 242 delivers the requisition to the respective executing module and requests execution of the transaction according to a business logic circuit 243, which has the function of reporting to the execution mechanism 242, the correct activity to be executed, in addition to filtering and validating the requisitions.

This execution mechanism 242 is also responsible for requesting the opening and closing of the transaction detail record TDR, that is to say, with each request for execution of transaction the transaction detail record TDR is generated, which will be used by the charging system of the telephony network. This transaction detail record TDR represents the entire request and its result, after execution by the adapting module 30. In general, this transaction detail record TDR has information about the service executed, date and time of the request and execution, business rules informing, moreover, who pays for the service, white contents, category of the requesting user, application of origin, among others.

For this reason, the transaction detail record TDR has been developed so as to meet all the types of service offered, thus becoming a stan- dard model known by the charging system, independently of its purpose. Thus, the charge-account generating process does not need to be modified either, adapted or updated to meet each new product offered.

The creation of the transaction detail record TDR is controlled and organized by a TDR management module 24. The processing nucleus 20 comprises a security module 25 associated to the internal interface 12 of the interface module 10. This security module 25 accounts for verifying the authenticity of the accesses of users of the telephony network and for authorizing the execution of services requested by the users. These data are available in the layers 50 of the stan- dard transport message STM.

The security module 25 is provided with a memory device 252 and a cryptography device 251. The memory device 252 is controlled by the security module 25 and exists for each authenticated user of the telephony network. In this way, when a use is authenticated, his profile and the charac- teristics of the services authorized to him are stored in the memory device 252, so that the information allocated in the standard transport message STM referring to the users and requisitions made by the users are compared with the execution restrictions attributed to the latter and that are in the memory device 252.

The cryptography device 251 has the function of codifying the personal data of the users, as for example, passwords of access to the sys- tern and of service requisition.

The processing nucleus 20 further comprises a management structure formed by a plurality of action monitoring modules 26, associated to the central monitoring 261.

This management structure has the function of monitoring and auditing the integration system. Therefore, at least one action management module 26 is arranged close to the other modules of the system, such as the interface module 10, the adapting module 30 and the various modules that compose the processing nucleus 20. The action management modules 26 accompany the course of the transactions and report the information or re- cords to the central monitoring module 261.

As illustrated in Tables 1 and 2 below, this information may refer to: (i) an alarm identifying the lack of operation (ii) the status or course of the monitored transactions in a determined period of time, for instance, every thirty seconds, (iii) the history of the transactions carried out, in order to pro- duce a diagnosis when necessary, and (iv) the control of the volume of transactions existing in each module of the system, among others. Table 1 : List of the standard information or records monitored by the action monitoring modules 26, in order to meet the various situations encountered in the service inte ration and mana ement s stem.

The information or records generated by the system and reported to the central monitoring module 261, by means of a plurality of action management modules 26, may be classified by type and criticality, as illustrated in Table 2 below:

Highest level = 1 , lowest level = 5, N/A = not applied.

In addition, the action management modules 26 enable one to carry out command actions of the central monitoring module 261 , as for instance, to stop and initiate the functions of a determined module (interface module 10, processing nucleus 20 and adapting module 30), as well as reconfigure these modules in real time, among other actions.

Another module that composes the processing nucleus 20 is the administrating module 27, provided with an auditing device 271 indirectly associated to a service-flow control device 28.

The administering module 27 centralizes all the administrative functions of the system, namely the module 27 administers the services, users, configurations and other functioning data of the service integration and management interface system.

The auditing device 271 has the function of appraising the connection, the transaction detail record TDR generated and other data, in order to follow and monitor the integrity of the transactions or the integrity of the executions of the requisitions. The service-flow control device 28 accounts for sequence and control the executions of the transaction services, that is to say, transactions composed of more than one action, generating a request to the message distribution module 21 , which manages all the texts created for a transaction service. In this way, all the transaction actions are programmed and triggered during the executions of the activities, which guarantees greater reliability and security to the transactions executed and to the transactions to be executed.

An auxiliary mechanism 29 is associated to the service-flow con- trol device 28, in order to help in executing the composed or others by administering and controlling the course of the tasks triggered by the device 28.

The service integration and management system further comprises at least one adapting module 30 for each service aggregate-value platform with which one wishes to communicate. According to Figure 4, each adapting module 30 comprises one controlling module 31 , associated to at least one providing module 32, the internal communication of which takes place by means of the protocol RMI. By means of the controlling module 31 , the adapting module 30 can communicate with the processing nucleus 20 and the interface module 10, that is to say, with the rest of the integration system, via lines of messages, whereas by the provider 32 the adapting module 30 can communicate with the service platforms of the telephony network implementing the specific protocol that each aggregate-value platform makes available for external communication. Optionally, the controlling module 31 may be associated to a plu- rality of providing modules 32, distributing the requisition load to the service platform of the telephony network.

In order for the controller 31 can communicate with the other modules that compose the integration system, the latter is capable of reading the information contained in the standard transport message STM and mak- ing the charge balancing between the providers 32.

On the other hand, the providing module 32 is responsible for the communication between the controlling module 31 and the legated system or the aggregate-value platforms VAS. For this purpose, the providing module 32 is capable of reading the standard transport message STM and converts it into the specific protocol of each platform.

The adapting modules 30 are responsible for implementing the services that represent an access to the resources available in each interconnected platform.

Thus, since the provider 32 has the function of converting the standard transport message STM to the specific protocols of each platform; it becomes less complex and expensive to implement services by associating platforms of the telephony network. This is because adaptations or modifications are no longer necessary for one to develop new telephony services that may be offered to clients by several channels, as for example, Web, MO, WAP, among others.

With the presence of the adapting module 30 the partners and developers will not have to develop their products focusing on the specific communication protocol of the platform, but rather by resorting to the available services. These services are specialized in the platforms and adaptable to the system of the telephony network, which brings about greater versatility to the development of new products and services, besides reducing the costs involved.

The service integration and management system utilizes resources of the telephony network, and the aggregate-value platforms VAS correspond to the platforms that compose the telephony network.

In addition, the service integration and management system of this invention may be embodied by means of electric and electronic circuits, formed from processors, memory devices, transistors, among other conventional or commercial components.

Figure 6 illustrates the flowchart of a service integration management, particularly used in telephony networks and that comprises the fol- lowing steps:

A) Receiving a requisition for a service by means of a different protocol 40; B) Converting the different protocol into a standard transport message (STM);

C) Transmitting the standard transport message (STM) to a processing nucleus 20; D) Distributing and processing transactions by means of controlling and processing modules arranged in the processing nucleus 20;

E) Opening a transaction detail record (TDR);

F) Sending an order of execution to at least o adapting module 30;

G) Completing the requested requisition and sending the results of the transactions to the processing nucleus 20; and

H) Closing the transaction detail record (TDR).

In the step A, the process is initiated with a requisition for a service. This requisition is a different protocol 40, which is received by the interface module 10 by means of an external interface 11. After the step A and in order to initiate step B, there is a step A1 of sending the different protocol 40 received by the external interface 11 to an internal interface 12. The sending is made by means of a remote- message transport system - RMI (Remote Method Invocation).

The internal interface 12 receives the different protocols 40, initi- ating the step B. In this step, before the transformation of the different protocol 40 takes place in standard transport messages STM, there is a step B1 of transmitting the different protocols 40 to a security module 25. The security module 25 receives the information and, by a step of verification of authenticity B2, the security module 25 verifies the user who makes the requisition for the service and further verifies the possibility of this user requesting such a service. This verification is effected by comparing the data received with the data stored in a memory device 252.

If this verification results in a rejection of the requisition, one initiates the step B3 of transmitting message to the external interface 11 , inform- ing the user of the rejection of his request.

On the other hand, if the verification results in acceptance of the requisition, there will also be the step B3 of transmitting message, but this time the information is transmitted to the internal interface 12, authorizing the conversion of the different protocols 40. Once the authorization has been received, the internal interface 12 executes the transformation of the different protocols 40 into standard transport message STM. Further during the step B, the internal interface 12 generates a transaction identifier 51 during the conversion of the different protocols 40 and transmits it to the external interface 11, by a communication step B4,so the that the user will take cognizance of the number that identifies his requisition. The communication step B4 brings the step B to a conclusion. In the step C, the standard transport message STM is transmitted to a storage module 22 of the processing nucleus 20.

Once the transactions coming from the standard transport message STM are recorded and stored in line in the storage module 22, the step D begins. During the step D, there is a step D1 of reading, priorization and distribution of the stored transactions to the other modules of the processing nucleus 20 by means of a distribution module 21, permanently in contact with the storage module 22.

Once the distribution of these transactions is finished, the step D2 of receiving the transactions begins. In this step D2, an execution mechanism 242 receives the order of priorization of the transactions organized by the distribution module 21. The order of priorization of the transactions to be carried out is again recorded in the storage module 22 by means of an execution mechanism 242, during a recording step D3. Further in this step D3, the execution mechanism 242 sends orders of execution to the adapting modules 30, which will be responsible for the execution, according to the type of service requested.

The step E begins when the execution mechanism 242 requests a note management module 24 for the opening of a transaction detail record TDR. The opening of a transaction detail record TDR note requested takes place during a note opening step E1 , executed at each request for execution of a transaction. At the end of the step E1 , one initiates the step F of sending an order of execution to at least one adapting module 30. Each adapting module 30 makes, by means of its controlling modules 31 , the reading and consumption of its respective line of transactions that is stored in the storage module 22. Then, by means of the providers 32 of each adapting module 30, one makes the communications with the legated systems or with the aggregate- value platforms VAS of the telephony network responsible for carrying out the requested service.

At the end of the step F, the requested service is carried out by the aggregate-value platforms VAS of the telephony network, and upon completion of this service the step G begins.

In the step G, the providing module 32 receives the results from the transactions carried out and send them to the controlling module 31 , which, in turn, transmits the results to the storage module 22 of the process- ing nucleus 20.

During the step G, there is a step G1 of sending the results of the transaction by the storage module 22 to the distributing module 21 , which informs the execution mechanism 242 of the completion of the service requested, thus completing the step G. Whenever the requested service requires the requester to be informed of its completion, that it so say, requires a response to the interface before closing the transaction detail record TDR, there will be a response step G2, when the execution mechanism 242 will request the storage module 22 to transmit, through the transmitting step G3, the information of comple- tion of the service to a response interface 13.

After the transmission step G3, the response interface 13 sends a communication to the external interface 11 (interface communication step G4) or to the user, through the user communication step G5.

In the step H, the execution mechanism 242 requests that the transaction detail record TDR be closed, which had been opened in the step E1 , thus completing the process.

This transaction detail record TDR note will later be used by the charging system.

Thus, when necessary, after the step G and before the step H, a response with the result of the execution will be sent to the requester.

In a second embodiment of the service integration and manage- ment process, the step A will be initiated by means of a requisition received by the adapting module 30. In this case, the different protocols 40 come from the aggregate value platforms VAS and are received by the providing modules 32, which, in this context, play the role of interface and sends, through intermediate protocols, the received requests to the internal interface 12. As in the preferred embodiment, during the step B and before the transformation of the different protocol 40 into standard transport message STM, there is a step B1 of transmitting the different protocols 40 to the security module 25, which receives the information from the providing module 32 and, through an authenticity verification step B2, the security module 25 veri- fies the user who makes the requisition for service and further verifies the possibility of this user requesting such a service. This verification occurs upon comparison of the received data with the data stored in a memory device 252.

If this verification results in a rejection of the requisition, one initi- ates a step B3 of transmitting message to the internal interface 12, informing on the rejection of the request.

On the other hand, if the verification results in an acceptance of the requisition, there will also be the message transmitting step B3, but this time the information is transmitted to the internal interface 12, authorizing the execution of the request. Once this authorization has been received, the internal interface 12 executes the transformation of the different protocols 40 into standard transport message STM.

In the step C the standard transport message STM is sent to the storage module 22 of the processing nucleus 20. Once the transactions coming from the standard transport message STM are recorded in line in the storage module 22, the step D begins. During the step D there is a step D1 of reading, priorization and distribution of the transactions stored to the other modules of the processing nucleus 20 through a distribution module 21, permanently in contact with the storage method 22.

The other steps E, F, G and H of the second embodiment of the service integration and management process take place as already described in the above preferred embodiment.

A preferred embodiment having been described, it should be understood that the scope of the present invention embraces other possible variations, being limited only by the contents of the accompanying claims, which include the possible equivalents.

Claims

1. A system of integrating and managing services, particularly used in telephony networks, the system of integrating and managing services being characterized by comprising: an interface module (10) comprising a receiving means (11) of different protocols (40) and a converting means (12) of different protocols (40) into standard transport message (STM); a processing nucleus (20) comprising a plurality of transaction control and management modules from the standard transport messages (STM); and at least one adapting module (30) comprising a controlling module (31) selectively associated to the processing nucleus (20) and at least one providing module (32) associated to a telephony network platform.

2. A system according to claim 1 , characterized in that the receiv- ing means (11) of different protocols (40) are an external interface (11) and the converting means (12) of different protocols (40) into standard transport message (STM) are an internal interface (12).

3. A system according to claim 2, characterized in that the internal interface (12) comprises a converting mechanism (102) for converting different protocols (40) into standard transport messages (STM).

4. A system according to claim 3, characterized in that the standard transport message (STM) is formed by a first information portion (52) associated to a second data portion (53), the information portion (52) being provided with a first presentation subdivision (54) and a second control sub- division (55).

5. A system according to claim 4, characterized in that the information portion (52) and the data portion (53) comprise multiple storage layers (50).

6. A system according to claim 5, characterized in that the con- version mechanism (102) decomposes the different protocols (40) and distributes the data and information in the multiple storage layers (50) of the standard transport message (STM).

7. A system according to claim 6, characterized in that the internal interface (12) generates a transaction identifier (51) for each procedure requested, the transaction identifier (51) being allocated in one of the multiple storage layers (50).

8. A system according to claim 2, characterized in that the external interface (11 ) sends the different protocols (40) to the internal interface (12) through a remote-message transport system (101).

9. A system according to claim 8, characterized in that the remote-message transport system (101) is of the RMI (Remote Method Invoca- tion) type.

10. A system according to claim 1 , characterized in that the processing nucleus (20) comprises a storage module (22) associated to a message distribution module (21), the storage module (22) being capable of storing the requisitions in lines.

11. A system according to claim 10, characterized in that the distribution module (21) organizes the requisitions stored in the storage module (22) in priority order by means of a priorization algorithm.

12. A system according to claim 11 , characterized in that the priorization algorithm calculates the degree of priority of the requisition from the date of recording the requisition on the storage module (22).

13. A system according to claim 12, characterized in that the processing nucleus (20) comprises an execution mechanism (242) associated to the distribution module (21) and capable of requesting the execution of a transaction according to a business logic circuit (243).

14. A system according to claim 13, characterized in that the execution mechanism (242) requests the opening and the closing of transaction detail records (TDR), the opening and closing of the transaction detail records (TDR) being controlled by means of a management module (24).

15. A system according to claim 1, characterized in that the processing nucleus (20) comprises a security module (25) associated to the internal interface (12) of the interface module (10).

16. A system according to claim 15, characterized in that the se- curity module (25) comprises a memory device (252) and a cryptography device (251).

17. A system according to claim 1, characterized in that the processing nucleus (20) comprises a plurality of action modules (26) ar- ranged close to the interface module (10), to a plurality of modules of the processing nucleus (20) and to the adapting modules (30), the action modules (26) being associated to a central monitoring module (261 ).

18. A system according to claim 17, characterized in that the plurality of action modules (26) are remotely associated to the central moni- toring module (261) and report multiple information and records classified according to the type and criticality.

19. A system according to claim 18, characterized in that a service-flow control device (28) is selectively associated to an auxiliary mechanism (29) capable of helping in execution of composed transactions.

20. A system according to claim 1 , characterized in that the controlling (31) is associated to a plurality of providing modules (32).

21. A system according to claim 20, characterized in that the controlling module (31) communicates with the processing nucleus (20) and with the interface module (10), the providing module (32) communicates with the service platforms of the telephony network.

22. A system according to claim 21 , characterized in that the controlling module (31) communicates with the processing nucleus (20) and with the interface module (10) by means of a standard transport message (STM).

23. A system according to claim 21 , characterized in that at least one providing module (32) comprises a system of converting the standard transport message (STM) into different communication protocols of each service platform of the telephony network.

24. A system according to claim 21, characterized in that at least one providing module (32) comprises a converting mechanism for converting the different communication protocols of each service platform of the telephony network into standard transport message (STM).

25. A process for integrating and managing services, particularly services used in telephony networks, the integration and management process being characterized by comprising the following steps:

A) Receiving a requisition for a service by means of a different protocol (40);

B) Converting the different protocol (40) into a standard transport message (STM);

C) Transmitting the standard transport message (STM) to a processing nucleus (20); D) Distributing and processing transactions by means of controlling and processing modules arranged in the processing nucleus (20);

E) Opening a transaction detail record (TDR);

F) Sending an order of execution to at least o adapting module (30);

G) Completing the requested requisition and sending the results of the transactions to the processing nucleus (20); and

H) Closing the transaction detail record (TDR).

26. A process according to claim 25, characterized in that, in the step (A), the different protocol (40) is received by an interface module (10) by means of an external interface (11 ).

27. A process according to claim 26, characterized in that, before the step (B), there is the step (A1) of sending the different protocol (40) to an internal interface (12) by means of an RMI type message transport system.

28. A process according to claim 25, characterized in that, in the step (B), there is a step (B1) of transmitting the different protocols (40) to a security module (25).

29. A process according to claim 28, characterized in that, after the step (B1) of transmitting the different protocols (40) to a security module (25), there is a step (B2) of verifying the authenticity of the user and of the requisitioned service by means of a memory device (252).

30. A process according to claim 29, characterized in that, after the step (B2) of verifying the authenticity of the user and of the requisitioned service, there is a step (B3) of transmitting message to the external interface (11), informing the rejection of the request.

31. A process according to claim 29, characterized in that, after the step (B2) of verifying the authenticity of the user and of the requisitioned service, there is a step (B3) of transmitting message to the internal interface (12), authorizing continuation of the transaction.

32. A process according to claim 29, characterized in that the step of converting the different protocols (40) into standard transport message (STM) takes place by means of the internal interface (12).

33. A process according to claim 32, characterized in that, in the step (B), there is generation of a transaction identifier (51) by means of the internal interface (12) and a communication step (B4) by sending transaction identifier (51 ) to the internal interface (11 ).

34. A process according to claim 25, characterized in that the step (D) begins with the recording and storing of transactions coming from the standard transport message (STM) in a storage module (22) of the processing nucleus (20).

35. A process according to claim 34, characterized in that, during the step (D), there is a step (D1) of reading, priorizing and distributing the transactions stored in the storage module (22) by means of a message dis- tributing module (21).

36. A process according to claim 35, characterized in that, after the step (D1 ) of reading, priorizing and distributing the stored transitions, there is a step (D2) of receiving the priorizations of the transactions by means of an execution mechanism (242).

37. A process according to claim 36, characterized in that, after the step (D2) of receiving the priorizations of the transactions, there is a step (D3) of recording the orders of priorizations of the transactions in the storage module (22).

38. A process according to claim 37, characterized in that, during the step (D3) of recording the orders of priorizations of the transactions, the execution mechanism (242) sends an order of execution to at least one adapting module (30).

39. A process according to claim 25, characterized in that, during the step (E), the opening of the transaction detail record (TDR) takes place by requesting the execution mechanism (242) for a TDR management module (24).

40. A process according to claim 39, characterized in that the opening of the transaction detail record (TDR) takes place at each request for execution of a transaction.

41. A process according to claim 25, characterized in that, during the step (F), at least one adapting module (30) executes the reading and consumption of a respective line of transactions stored in the storage module (22).

42. A process according to claim 41, characterized in that the reading and the consumption of the line of transactions takes place by means of the controlling module (31) of at least one adapting module (30).

43. A process according to claim 42, characterized in that, after the consumption of the line of transactions, there is communication between the adapting modules (30) and the platforms of the telephony network by means of at least one providing module (32).

44. A process according to claim 43, characterized in that, in the step (G), at least one providing module (32) receives results of the carried- out transactions and sends them to the storage module (22) by means of the controlling module (31).

45. A process according to claim 44, characterized in that, during the step (G), there is a step (G1) of sending the results of the transactions to the distributing module (21) by means of the storage module (22), and the distributing module informs the completion of the requested service to the execution mechanism (242).

46. A process according to claim 45, characterized in that, after the step (G1) of sending the results of the transactions, the execution mechanism (242) requests the storage module (22), by means of a response step (G2), for transmission of the information about the completion of the requested service to a response interface (13), this transmission occurring by means of a transmission step (G3).

47. A process according to claim 46, characterized in that, after the transmission step (G3), the response interface (13) sends a communication to the external interface (11) by means of a communication step (G4) of the interface.

48. A process according to claim 46, characterized in that, after the transmission step (G3), the response interface (13) sends a communication to at least one user by means of the communication step (G5) of the u- ser.

49. A process according to claim 25, characterized in that, in the step (H), the execution mechanism (242) requests the closing of the transaction detail record (TDR).

50. A process according to claims 25 to 49 characterized in that multiple action management modules (26) arranged close to the interface module (10), to the plurality of modules of the processing nucleus (20) and to the adapting modules (30), report the course of the carried-out transactions to the central monitoring module (261).

51. A process according to claim 25, characterized in that an administrative module (27) comprising an auditing device (271) monitor the integrity of the carried-out transactions.

52. A process according to claim 25, characterized in that, in the step (A), the different protocol (40) is received by at least one adapting module (30) by means of at least one providing module (32).