This is a continuation of application Ser. No. 07/624,894, filed Jan. 18, 1991, now abandoned.

FIELD OF INVENTION

This invention pertains to a method of managing a database in an intelligent network.

DESCRIPTION OF RELATED ART

Various services, such as collect calls, three-way conversations, and telephone conventions, are offered to users of telephone networks.

Generally, service application programs for realizing such services, together with databases for use in such services, are provided in switching centers.

Recently, research has been performed to find a way of separating such service application programs from the exchanging operation and thereby centrally manage them at one point in the network. A communication network that realizes this objective is called an intelligent network. Its purpose is to enable operators of exchange networks to freely create service application programs indepently of the type of exchange machine. Conventionally, creation of such service application programs depends on the type of exchange machine in the switching center.

FIG. 1 shows an example of an intelligent network's configuration. The service switching points 11 are exchange machines for controlling connections between terminals. Each is connected to a device control point (SPC) 12 through a signal network. The object is to concentrate application programs and databases for processing services requested by subscribers in the service control point 12.

However, currently only databases are concentrated, so exchange network operators cannot freely create new service application programs. This is because the service application programs and database management functions are closely linked, making it necessary to comprehend the database structures and the like in developing application programs. This requires special know-how and a huge number of development steps.

Not all the services provided to telephone network users can be activated simultaneously. Such services include a service for activating something prioritized and some services can not be activated concurrently. Therefore, when an originating subscriber requests a plurality of services, the existence of mutual restrictions between services needs to be checked. The required checks are performed in respective application programs. When a new application program is created, existing application programs need to be modified. This lowers efficiency in developing a program.

SUMMARY OF THE INVENTION

This invention purports to enable service application programs for communication networks to be developed without special attention being paid to a database structure.

In one preferred mode, an Application Interface Platform (APIP) is provided between a plurality of service application programs and databases. Access to the database from respective application programs is performed through the application interface platform. Processing requests between each application programs and the application interface platform is performed based on a common data format. The application interface platform comprises a translating module, a database processing module and output processing module.

In an intelligent (communication or telephone) network which integrally controls a plurality of service application programs, the translating module analyzes a service request message from subscriber and creates a database processing request based on the service request message. The database processing module accesses a database and makes an application processing request to a plurality of service application programs, based on the database processing request from the translating module. The database processing module accesses the database based on the database processing request from the service application programs.

The output processing module outputs messages to the communication network based on an output processing request from one of the service application programs. The processing requests, either between two modules or between a module and the service application programs, all have a common data format.

The translating module creates the database processing request, e.g., by adding a processing tag corresponding to the service to each parameter of the received service request message. The database processing module obtains the desired information by accessing the database based on the above database processing request. The database processing module creates an application processing request from the obtained information and each parameter of the service request message. The service application programs designated by this application processing request execute the respective service processing. If the execution result needs to be outputted to the communication network, the service application programs create the output processing request and output it to the output processing module. If the database needs to be accessed as a result of the service execution, the service application programs create tile database processing request in correspondence with the necessary processing content and output the database processing request to the database processing module.

Thus, the service application programs can be configured separately from the database by inserting a translating module, a database processing module and an output processing module either between the communication network and the service application programs or between the database and the service application programs, and by making the processing requests between each module and the service application programs in a common data format.

Accordingly, service application programs can be developed without any special attention being paid to the database structure, thereby improving efficiency in developing the program.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of an intelligent network's configuration,

FIG. 2 shows the configuration of the preferred embodiment of this invention,

FIG. 3 is a flowchart of the translation-check process,

FIG. 4 explains a mutual restriction matrix table,

FIG. 5 shows an example of a closed-user-group-related database-processing request slip,

FIG. 6 explains a processing tag,

FIG. 7 is a flowchart of the database processing,

FIGS. 8A through 8D explain a closed-user-group-related database processing,

FIG. 9 shows an example of a closed-user-group-related application-program-processing request slip,

FIG. 10 is a flowchart of the interface processings in an application program,

FIG. 11 shows an example of the output-processing request slip,

FIGS. 12A and 12B show examples of database processing request slips,

FIG. 13 shows the configuration of a closed-user-group statistical database,

FIG. 14 is a flowchart showing the procedure for extending the functions of the translation-check processing module,

FIG. 15 explains the corresponding relations between the parameters of the database-processing request slip and the received message,

FIG. 16 is a flowchart showing the procedure for extending the functions of the database processing module,

FIG. 17 shows an example of an originating-side closed-user-group database and a destination-side closed-user-group database,

FIG. 18 explains the corresponding relations between the parameters of the application program processing request slip and the received message, and

FIG. 19 explains the corresponding relations between the data formats outputted to the signal network and the output processing request slip.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

A preferred embodiment of the present invention is explained by referring to the drawings.

The present embodiment pertains to the service control point (SCP) (service control point) 12 for executing the database management method of the present invention.

An intelligent network has the structure shown in FIG. 1. The service control point 12 comprises a database, various service application programs and an application program interface platform 22, to be described later.

FIG. 2 shows the configuration of the main part of the service control point.

In the present embodiment, a common (Application Interface Platform) 22 is provided between database 18 and a plurality of application programs 17. Access to database 18 from respective application programs 17 is performed through a common data format by the application interface platform 22.

In accordance with it, though discribed in detail later, when the database is accessed by one of the application programs 17, only a processing request for accessing the database with regard to application interface platform 22 based on the predetermined data format is required. Therefore, a developer of an application program 17 can develop a program without considering the structure of the database 18, and the development of the application program becomes easy.

As shown in FIG. 2, the application interface platform 22 comprises a translation-check processing module 13, a database processing module 16 and an output processing module 21.

In FIG. 2, the translation-check processing module 13 analyzes a message received from an originating subscriber supplied through a service switching point 11 and determines the service to be executed. Then, if the originating subscriber requests a plurality of services, the translation-check processing module 13 judges whether all or only some of the requested services can be executed concurrently by referring to a mutual restriction-matrix table 14, to be described later.

When the service or services to be executed are determined, by adding a processing tag corresponding to the service content, the translation-check processing module 13 creates a database-processing request slip 15, to be described later, and sends it to a database-processing module ! 6.

The database-processing module 16 reads or writes data by accessing a particular database 18 according to the processing tag of the database-processing request slip 15 from the translation-check processing module 13 or an application program 17, to be described later. The database-processing module 16 also creates an application-program-processing request slip 19, to be described later, based on the data processed in accordance with the processing tag of the database-processing request slip 15.

The application program 17 executes to process various services such as closed-user groups, three-way conversations, or reverse charging. After the respective services have been processed, the application program 17 creates the database-processing request slip 15 and updates the database 18. Also, the application program 17 creates an output-processing request slip 20, to be described later, based on the processing result, and outputs it to an output-processing module 21.

The output-processing module 21 converts the data received as the output-processing-request slip 20 to a predetermined data format based on a protocol defined in a signal network.

A man-machine interface (MMI) 23 for inputting commands for expanding the functions of each module when a service is added is connected to the application program interface platform 22.

Next, the operations of this embodiment are explained.

The following describes a case in which a subscriber requests two services, closed-user-group and collect calls, at the same time.

FIG. 3 is a flowchart of the translation-check process in the translation-check processing module 13.

First, a message is received from an originating subscriber (Step 1 in FIG. 3).

Second, a service key is extracted from the received message (Step 2 in FIG. 3).

Third, the mutual-restriction-matrix-table 14 (FIG. 4) is searched with the extracted service key (Step 3 in FIG. 3), and it is judged whether or not a mutually restricting condition exists between the two services (Step 4 in FIG. 3).

As shown in FIG. 4, the mutual restriction matrix table 14 describes the service names A through F on the horizontal and vertical axes and defines the mutual restriction condition between the respective services in a matrix form.

In FIG. 4, "O", described as the point where A and B services interact, indicates that there is no mutual restriction between both services. "pA", described as the point where A and E services interact, indicates that the execution of A service is prioritized and E service is ignored when A and E services are requested simultaneously. Other mutually restrictive conditions between respective services are predetermined according to the various mutually restrictive conditions shown in FIG. 4.

Back in FIG. 3, if it turns out that the two requested services cannot be contemporaneously activated as a result of the judging made in Step 3, the output processing module 21 is notified of the result. A message is then sent to the originating subscriber that the requested services cannot both be utilized (Step 5 in FIG. 3).

If it turns out that the two requested services do not conflict with each other, both services are activated (Step 6 in FIG. 3). The receiving parameter, service key, originating number, index code, OA display, destination number related to the CUG (closed-user-group) and reverse charging request, are saved in a memory (not shown in the drawing) (Step 7 in FIG. 3).

Further, the corresponding processing tag is added to the service key, and the database-processing request slip 15 related to the closed-user-group and the reverse charging is created (Step 8 in FIG. 3).

In the present embodiment, the processing requests between respective modules or between a module and the application program 17 are made in a common data format.

Processing requests to the database-processing module 16, the application program 17, and the output processing module 21 are made by the database-processing request slip 15, the application-program-processing request slip 19, and the output-processing request slip 20, respectively. These processing-request slips are stored in a memory at the service control point 12.

FIG. 5 shows an example of the database-processing request slip 15 related to the closed-user-group service created in the translation-check-processing module 13.

In this case, since the service key is "closed-user-group", the translation-check-processing module 13 designates a relay conversion as the processing tag Then the service key "closed-user-group", the originating number and the closed-user-group index are designated as the first, second and third parameters, respectively, so that the database-processing-request slip 15 shown in FIG. 5 is created. As for general purpose parameter of database-processing request slip, there are transmitting day and time, password, routing numbers in public network, encounting numbers for line busy, subscriber calling numbers, booking numbers and ISDN Feature Activation numbers.

The processing tag herein contains information designating the processing to be executed. As shown in FIG. 6, it is defined in correspondence with the respective service functions.

In FIG. 6, for instance, in case of a closed-user-group check processing wherewith information B is obtained from information A and information C corresponding to information B is obtained, a relay conversion is designated as the processing tag. In case of a password check for examining the conformance between information A and information B, a check is designated as the processing tag.

Processing tags for other services shown in FIG. 6 are designated according to the functions performed by the services.

When the database-processing-request slip 15 is thus created, a database processing is executed in the database-processing module 16 (Step 9 in FIG. 3).

FIG. 7 is a more detailed flowchart of the database processing performed in Step 9. It shows the case in which the database-processing-request slip 15 related to a closed-user-group service is received.

The closed-user-group service is offered only to certain registered subscribers, who have an individual index code assigned. If an interlock code defined in correspondence with the index code is registered in the closed-user-group database of the receiver or destination, the closed-user-group service is provided.

Upon receiving the database-processing-request slip 15 (e.g. the database-processing-request slip for closed-user-group service shown in FIG. 5) from the translation-check-processing module 13 (Step 10 in FIG. 7), the database-processing module 16 recognizes from the processing tag that the processing to be executed is a relay conversion (Step 11 in FIG. 7). It then recognizes from the service key of the first parameter of the database-processing-request slip 15 that the database to be accessed is a closed-user- group database (Step 12 in FIG. 7).

FIGS. 8A through 8D show an example of an originating-side closed-user-group database and a destination-side closed-user-group database. These figures explain the process of accessing a database after Step 13 in FIG. 7.

First, the originating-side closed-user-group database 24 is searched by the originating number of the second parameter so that the corresponding data unit 25 (FIG. 8A) is determined (Step 13 in FIG. 7). Second, the interlock code corresponding to the closed-user-group index code of the third parameter is extracted from the data unit 25 (Step 14 in FIG. 7). Since the fourth parameter is a delimiter indicating a section, the extracted interlock code is registered as source data (Step 15 in FIG. 7). Third, a corresponding data unit 27 (FIG. 8C) is determined by searching the destination-side closed-user-group database 26 with the destination number (Step 16 in FIG. 7). Fourth, the data unit 27 is searched by source data, i.e. the interlock code, and the corresponding destination-side index code is obtained (Step 17 in FIG. 7).

The application-program-processing-request slip 19 is created from the received message (information such as originating number and destination number received as a part of the database processing request slip) and the index code (searching data) thus obtained (Step 18 in FIG. 7). For instance, if the the database-processing-request slip 15 is as shown in FIG. 5, the data unit 25 shown in FIG. 8A is determined from the originating number "7126666" of the second parameter. Then, from the index code "090" of the third parameter, the interlock code "12345" is designated in correspondence with the index code "090" in the data unit 25, as shown in FIG. 8B.

Next, to determine whether or not this interlock code is registered in the destination to be accessed, the data unit 27 of the destination side CUG database 26 is determined from the destiniation number "7125555" of the fifth parameter, as shown in FIG. 8C. It is then searched by the interlock code "12345" to obtain the corresponding destination-side index code "010", as shown in FIG. 8D.

That is, in the above processing, the index code assigned to each user is converted once to the interlock code registered in the originating-side closed-user-group database 24. Then, from the destiniation number and its interlock code, it is checked whether or not the CUG user registration has already been made by determining whether or not the interlock code actually exists in the destination side CUG database 26.

If the final destination side index code is obtained, the application program processing request slip 19 is created from the index code and the received message.

FIG. 9 shows an example of an AP processing request slip 19 created by the above-described DB processing.

The application-program-processing-request slip 19 shown in FIG. 9 is created based on the closed-user-group-related database-processing-request slip 15 shown in FIG. 5.

In FIG. 9, the head of the application-program-processing- request slip 19 memorizes the "closed-user-group" as the program number designating the application program 17 to be executed. The destination side index code "010" and the interlock code "090" obtained from the database processing are memorized, together with the originating number and the destination number.

Next, the processing on the side of the application program (AP) 17 upon receiving the application program processing request slip 19 is explained by referring to the flowchart of FIG. 10. This explanation only pertains to the processing of the interface between the application program 17 and the output-processing module 21 or the database-processing module 16.

First, the respective processing of the application program 17 is designated by the program number of the application-program-processing-request slip 19 (Step 19 in FIG. 10).

Second, the output-processing-request slip 20 is created based on tile data obtained from this processing (Step 20 in FIG. 10).

FIG. 11 shows an example of the output-processing-request slip 20. The output-processing-request slip 20 shown in FIG. 11 is created based on the closed-user-group-related application-program-processing-request slip 19 shown in FIG. 9. In FIG. 11, a processing tag indicating a processing request related to a sending is added to the head of the output-processing-request slip 20, and the destination number "7125555" on the destination side and the destination side index code "010" are memorized as the first and second parameters, respectively.

In FIG. 10, it is judged whether or not statistical information of the database 18 needs to be updated (Step 21 in FIG. 10). If it does not, the processing goes on to either Step 22 or Step 24 shown in FIG. 10, and the created output-processing-request slip 20 is outputted to the output-processing module 21, or the database-processing-request slip 15 created by the respective application program processing is outputted to the database-processing module 16. The output processing in Step 22 is executed by the output-processing module 21, and it is recognized from the processing tag of the output-processing-request slip 20 that it is a sending processing. Succeeding information is then converted to the predetermined format according to the predetermined protocol of the signal network to which the reformatted information is outputted.

However, if it is necessary to update the statistical information, the database-processing-request request slip 15 is created for updating the statistical information (Step 23 in FIG. 10 ). Database processing is then activated by outputting the created database-processing-request slip 15 to the database-processing module 16 (Step 24 in FIG. 10 ).

FIGS. 12A and 12B show an example of the database-processing-request slip 15 when the number of times the closed-user-group database is accessed is sorted by the originating number or the interlock code. In this case, the processing tag for designating the updating processing is added to the head of the respective database-processing-request slip Also in this case, "closed-user-group statistics", "addition" and "1" are memorized as information indicating the database type of the first parameter, the operation content of the fourth parameter and the operation unit of the fifth parameter, respectively.

When the database-processing module 16 receives the database-processing-request slip 15 shown in FIGS. 12A and 12B, updating of the statistical information related to the closed-user-group statistical database is recognized from the processing tag and the database type.

The primary table 30 and the secondary table 31 of the database that memorizes the closed-user-group statistical information shown in FIG. 13 are then searched by the originating number "7126666" and the interlock code, so that the data in the corresponding areas are incremented by one to update the statistical information (the number of accessing times in this case).

As so far explained, in the above embodiment, the application program interface platform 22 is provided between the database 18 and the application program 17. The processing requests of the application-program interface platform 22 between the modules or between the module and the database 18 or between the module and the application program 17 are made in a common data format, such as in the form of a common processing request slip.

Consequently, the application program 17 can be developed without recognizing the structure of the database 18. This simplifies program development, and enables an exchange network operator to develop the application program 17 on a proprietary basis.

The check of the mutual restrictions between applications conventionally performed in the application program 17 is performed by the translation-check-processing module 13 provided inside the application program interface platform 22, so that the existing application program 17 need not be modified when a new service is added. This improves the efficiency of program development.

Next explained are the procedures for extending the functions of the translation-check-processing module 13 and the database-processing module 16 when a new service is added. This explanation assumes that the closed-user-group service does not exist and a closed-user-group service is newly added.

First, the procedures for extending the functions of the translation-check-processing module 13 are explained by referring to the flowchart shown in FIG. 14. When the service is added, an operator (such as an exchange network operator) defines a new service key through a device such as a keyboard (not shown in the drawing) of the man-machine interface 23 (Step 25 in FIG. 14).

Second, the mutual-restriction-matrix table 14 (FIG. 4) is displayed on the display screen of the man-machine interface 23, so that a new service is registered on the mutual-restriction-matrix table 14 and a further mutual restricting condition is set (Step 26 in FIG. 14). Then, a parameter for the incoming message received from the signal network is set.

Third, the format of the database-processing-request slip 15 of the newly-added service is created on the display screen, and the respective parameters for the incoming message and the database-processing-request slip 15 are displayed on the display screen so that their corresponding relations can be defined (Step 27 in FIG. 14).

FIG. 15 shows an explanatory view of the corresponding relations between the parameters of the received message and the database-processing request slip 15. In this drawing, for instance, the parameters for the received message and the database-processing-request slip 15 are displayed on the display screen so that their correspondence relationships can be defined. Based on this definition, the translation-check-processing module 13 creates the database-processing-request slip 15 of the newly added service.

Thus, when a new service is added, only the mutual restricting conditions with already-existing services need to be set in the mutual-restriction-matrix table 14, and existing application programs need not be modified. Besides, the setting of the mutual restricting condition is greatly simplified.

Next, the procedure for extending the function of the database-processing module 16 when a service is added is explained by referring to the flowchart shown in FIG. 16 and the database configuration diagram of FIG. 17.

First, the maximum sizes of the originating-side closed-user-group database 28 and the destination-side closed-user-group database 29 (FIG. 17) corresponding to the defined closed-user-group service are defined (Step 28 in FIG. 16). It is then defined which code (i.e., an index code or an interlock code) is used in searching the originating-side closed-user-group database 28 and the destination-side closed-user-group database 29.

Second, the respective database configuration is defined (Step 29 in FIG. 6). An extending command such as the following can then define a new database area.

A command "ORG_-- CUB_-- DB; originating number; index (0,15); interlock (16, 31)" defines the configuration of the originating-side closed-user-group database 28, and has an index-code-data area comprising bit 0 to bit 15 and an interlock-code-data area comprising bit 16 to bit 31 in a 32-bit-long data area. This command also means that the index code and the interlock code of the individual originating subscriber or call originator is stored in the database in the order of the originating number.

A similar extending command can define the configuration of the destination-side closed-user-group database 29. This enables the areas for the originating-side closed-user-group database 28 and the destination-side closed-user-group database 29 shown in FIG. 17 to be secured.

Since the database area can be secured at a command level, the functions of each module in the application-program interface platform 22 can be easily extended when a service is added.

In FIG. 16, the format for the application-program-processing request slip 19 corresponding to the added service is defined (Step 30 in FIG. 18).

FIG. 18 explains the corresponding relations between the received message and the parameter of the application-program-processing request slip 19.

For instance, as shown in FIG. 18, the respective parameters for the received message and the application-program-processing request slip 19 are displayed, so that correspondence is made between them on the display screen, thereby defining the relations between the parameters.

Also, at this time, the destination index code and the interlock code obtained from a database processing are defined as data for the sixth and fourth parameters, respectively.

Further, the program number (service key) of the newly-added closed-user-group service is registered in an activation control table (not shown in the drawings) (Step 31 in FIG. 16).

The database area of the statistical information updated when a closed-user-group service is activated, is then defined (Step 32 in FIG. 16).

The processing at Step 32 first defines the item which indicates whereto the statistical information is related and its area size. Thus, as shown in FIG. 13, the primary table indicating that the statistical information of the database relates to the originating number and the interlock code is defined.

Then the area size for the secondary table 31, i.e. the area size for memorizing the statistical information for respective items and the index item are defined.

Through the above procedures, the closed-user-group statistical database area for memorizing the numbers of accessing times for the originating number and the interlock code is defined.

Next, the functions of the output processing module 21 are extended.

FIG. 19 explains the corresponding relations between the output processing request slip 20 defined at this time and the data format outputted to the signal network.

As shown in FIG. 19, for example, the format of the output processing request slip 20 and the data format to be outputted to the signal network are created and their corresponding relations are defined on the display screen.

This enables data sent from the service application program 17 in the form of an output-processing-request slip (in this case, the output data related to the newly-added closed-user-group service) to be outputted by having the output-processing module 21 convert them to a predetermined data format set in a signal network.

Thus, because various processing-request slips and the mutual-restriction-matrix table 14 can be defined on the man-machine interface 23, modifications necessary for adding a new service can be very easily made.

Also, since the functions of each module are extended through the command input from the man-machine interface 23, a service can be added flexibly. In the embodiment described above, APIP 22 is provided between the database and a plurality of application programs 17 and processing request command between respective modules of application program interface platform 22 and application program 17 is performed by using common data format among a plurality of application programs. Therefore, if a network operator only knows the above common format, an accessing process to database based on the common format is conducted by database processing module in APIP. Therefore, since the above embodiment enables an application program to be developed without the database structure being recognized, an exchange network operator can easily develop such a program.

Since the common module has a mutual restricting matrix for storing the mutually restrictive conditions between application programs, the existing application programs need not be modified when a new service is added.

A processing request (a database-processing-request slip, an application-program-processing-request slip, or an output-processing-request slip) created by a translation-check module, a database-processing module, or an application program is not limited to the format stated in the description of the preferred embodiment, but may be in various formats. For example, it can be realized by a slip format without using a processing tag.

The configuration of devices utilizing the database management method of this invention is not limited to the configuration of the service control point 12 described earlier, but may be one of a variety of modified forms.