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 signifi- cant 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 ap- plications 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 re- sponsible 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 ser- vice 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 neces- sary 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 teleph- ony network are known from the prior art. However, these have not been de- veloped 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 integra- tion 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 as- sociated 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 in- teract and manage services applied to telephony networks.

Brief Description of the Invention The objective of the invention is to provide a system of integrat- ing 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 con- trolling 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 selec- tively 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 in- tegrating 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 stan- dard 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 Fig- ure 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 convert- ing means 12, which changes the different protocols 40 into standard trans- port messages STM. The different protocols 40 come from the various ser- vice-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 communi- cation 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 con- verting 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 com- prises data of the requested service. 8 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 inte- gration and management system, the storage layers 50 are read by the re- spective 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 com- munication 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 stan- dard transport message STM, the internal interface 12 generates a transac- tion 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 ad- minister 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 pro- posed 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, inde- pendently of its type of communication protocol, the internal interface 12 of the interface module 10 will make the transformation of the latter into a stan- dard 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 pro- vide 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 mes- sage distribution module 21, which accounts for reading, priorization and dis- tribution of the transactions for the other modules of the processing nucleus 20.

The distribution module 21 is permanently in contact with a stor- age module 22, where the requisitions are recorded and stored in lines, whi- ch 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 algo- rithm 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) *m+c 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 atten- tion 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 ad- vanced date of a determined requisition.

Once the requisitions have been given priority, they are distrib- uted to the other modules of the processing nucleus 20.

The execution mechanism 242 delivers the requisition to the re- spective executing module and requests execution of the transaction accord- ing 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 teleph- ony 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, more- over, 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 de- veloped 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 as- sociated 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 re- quested 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- tem 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 tran- sactions 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 integration and management system. Name of the col-Description Type Tam Values umn of data serialNum The serial num-Long-31201270 ber of the Log registration Event Type Classification of String-FATAL the event that ERROR has generated WARN the log registra-INFO tion, by its criti-DEAD L. cality and type SECURITY TRANSACTION Modulold Identifier of the String-Identifier of the mod- module respon-ule sible for the re- cord generated (originator) CreatorEntity A Entity_id, Ses-String-Name of the Creator- sionld, Refer-Entity enceKey or Transaction id that has gener- ated the log event SourceTransact Userld, transac-String-Description of the tionld or applica-source transact tion that re- quested the transaction Source time The date and Date-20020331201258 : time when the 1024922526203 log event was generated Creation-timesta The date and Date-20020331201259 : mp time when the 1024922526203 log record was created EventName Name of the String-Name of the event event EventDescription Description ofthe String Description of the event event Statuslnstance Status of the re-String-1-CONTINUE 2- quest NUE Optional_1 Optional parame-String-Optional ter 1 Optional_2 Optional parame-String-Optional ter 2 Optional,3 Optional parame-String-Optional ter 4 Optional_5 Optional parame-String Optional ter 5

The information or records generated by the system and reported to the central monitoring module 261, by means of a plurality of action man- agement modules 26, may be classified by type and criticality, as illustrated in Table 2 below : Table 2: Classification of the criticality of the monitored records. EventType Level Monitored Definition TRANSACTION N/A No Utilization for representing all the transactions carried out by the module. It should be equivalent to the threshold number reported per hour. OFF 1 Yes Utilization by the monitor module for reporting that a determined module is in off-line status FATAL 2 Yes It should be utilized for reporting some internal or external event that prevents the module from con- tinuing its activities. ERROR 3 Yes It should be utilized for reporting an unexpected or incomplete entry of data, errors in the communica- tion with external agents, er- rors/events propagated, etc. WARN 4 Yes It should be utilized for reporting when a determined value is reach- ing its limit, with processing rate, high level of charge or recourse occupation, proximity in reaching the maximum number of connec- tions ermitted, threads, etc. INFO 5 Yes It should be utilized for reporting some sporadic event that is being or will be executed, such as exter- nal interventions, startup, shut- down, reload config, redefinitions of parameters, etc. DEAD LOCK 4 Yes It should It should be utilized for reporting DeadLock event SECURITY 3 Yes It should be utilized for reporting all the EventName of security, such as incomplete or unauthorized at- tempts of access, login, logout, timeout, authorizations, restriction controls, etc. DEBUG N/A No This type of event may be utilized for reporting all the events that may help in the debug process of software by the developer. This type will only be generated when the DebugKey is with a true value STATE N/A No It reports the events of state of each module: STARTED-when the module is initiated; ONLINE-when the module is ac- tive and normal ; ALARM-when the module is not communicating; OFF-LINE-when the module is turned off in an abnormal way; SHUTDOWN-when the module is normally turned off. THRESHOLD N/A No It reports the levels of occupation/ time of each module : GREEN = X < 80% YELOW = 80% < X < 90% RED = X > 90%

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 in- stance, to stop and initiate the functions of a determined module (interface module 10, processing nucleus 20 and adapting module 30), as well as re- configure 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 as- sociated 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, us- ers, configurations and other functioning data of the service integration and management interface system.

The auditing device 271 has the function of appraising the con- nection, 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 exe- cuted.

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

The service integration and management system further com- prises at least one adapting module 30 for each service aggregate-value plat- form 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 commu- nicate 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 inter- connected 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 modifica- tions 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 avail- able 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 re- sources 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 conven- tional or commercial components.

Figure 6 illustrates the flowchart of a service integration man- agement, 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 ser- vice. This requisition is a different protocol 40, which is received by the inter- face 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 proto- col 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 authentic- ity 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 initi- ates 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 requisi- tion. The communication step B4 brings the step B to a conclusion.

In the step C, the standard transport message STM is transmit- ted to a storage module 22 of the processing nucleus 20.

Once the transactions coming from the standard transport mes- sage 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 mecha- nism 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 exe- cution mechanism 242, during a recording step D3. Further in this step D3, the execution mechanism 242 sends orders of execution to the adapting mo- dules 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 consump- tion 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 com- pletion 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 re- quested, 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 mod- ules 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 secu- rity 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 de- vice 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 in- ternal 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 mes- sage 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 de- scribed in the above preferred embodiment.

A preferred embodiment having been described, it should be un- derstood 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.