JP2003256223A - Service control method and device in open api system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a service controller and a service control method in an Open API system in which a plurality of service applications are simultaneously received by a telecom carrier network regardless of the service start conditions of those applications. <P>SOLUTION: A service control system 10 stores competing service start condition registration/change/deletion requests received from an Open API client in a memory, and analyzes the service start condition registering states from already stored service start condition registration/change/deletion requests. The received requests are compared with the service start condition registering states at that point of time so that the unchanged service start condition part, the service start condition part to be added, and the service start condition part to be deleted can be discriminated from each other, and the service start condition registration/change/deletion requests can be configured based on the discrimination, and noticed to an Open API server 11. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention exposes network functions such as a call control function and a mail function of a telecom carrier network to the outside so that those other than the telecom carrier can access and develop additional service applications. The present invention relates to an open API (Open Application Programming Interface, hereinafter referred to as Open API) system for enabling the above.

In particular, the present invention relates to a service control apparatus and method for arbitrating an application using OpenAPI so that a plurality of service applications can operate simultaneously.

Further, according to the present invention, there are a plurality of OpenA for applications using the OpenAPI.
The present invention relates to a service control device and method that provide a mechanism for hiding the distributed configuration of a PI server.

[0004]

2. Description of the Related Art When a user of a telecom service uses a service, it can be assumed that the service is provided under the same or similar conditions. For example, answering service and call forwarding service. At that time, the telecom carrier who is the provider of the telecom service needs to analyze the functions and provision conditions of a plurality of services used by the relevant user, and preferentially provide the most appropriate service. Conventionally, a method has been adopted in which the determination is made in advance in a switch on the network after grasping the functions and provision conditions of all services in advance.

[0005] In contrast to such a fixed method,
OpenAPI provides a mechanism by which an application that uses a service can dynamically notify in advance the conditions under which a self-application is started to a telecom carrier network. Using this mechanism, O
In penAPI, the telecom network activates the service when the activation condition notified in advance is satisfied. Therefore, on the telecom network, fixed determination processing for preferentially providing the most appropriate service is unnecessary, while the service activation conditions dynamically notified from multiple service applications are sequentially analyzed, Judgment processing for preferentially providing the most appropriate service is required.

[0006] Further, according to the OpenAPI specification, Open
The API application and the OpenAPI server need to recognize each other on a one-to-one basis. Therefore, when there are a plurality of OpenAPI servers in the telecom carrier network, the OpenAPI application must individually recognize the plurality of OpenAPI servers. Further, when the OpenAPI application notifies the OpenAPI server of the request by using the API, it is necessary to appropriately determine which server of the plurality of OpenAPI servers should be notified of the request.

[0007]

DISCLOSURE OF THE INVENTION Problems to be Solved by the Invention
The enAPI has a limitation that only one service application having the same service activation condition can be registered in the telecom carrier network.
For example, regarding the answering machine service and the transfer telephone service, only one of them can register the service activation condition in the telecom carrier network. Under such restrictions, many services cannot be flexibly operated.

If there are a plurality of OpenAPI servers in the telecom carrier network, the Open
The nAPI application needs to know the distributed configuration of the OpenAPI server in order to determine the appropriate OpenAPI server. This causes the service logic of the OpenAPI application to be complicated, and impedes the efficiency of service development.

Therefore, it is an object of the present invention to provide a service control apparatus and method in an OpenAPI system that is simultaneously accepted by a telecom carrier network regardless of the service activation conditions of a plurality of service applications. .

Another object of the present invention is to provide an appropriate service preferentially to a plurality of service applications.
An object of the present invention is to provide a service control device and method in a penAPI system.

Still another object of the present invention is OpenAPI.
Applications that use multiple open APIs
When operating on a telecom carrier network composed of servers, it is possible to provide services without knowing the distributed configuration of the OpenAPI server.
It is to provide a service control device and method in an API system.

[0012]

In order to achieve the above object, an open API is provided in an open API network.
There is a need for network elements that are accessible and accessible by both clients and servers. This network element needs to be able to communicate with both the open API client and the server, but it should not be aware that they are communicating with the network element. All additional functionality provided to enhance the OpenAPI specification or to hide some of its imperfections is implemented within this network element.

A service control apparatus according to a first aspect of the present invention is an open API (Open Application Programming).
Interface (hereinafter referred to as an open API client), an open API server that operates as part of the telecom network,
In an open API system including a proxy provided in the telecom network on behalf of the open API server for the open API client,
Memory for storing the service activation condition registration / change / deletion request received from the open API client, and analysis of the service activation condition registration state from at least one service activation condition registration / change / deletion request already stored in the memory And a service start condition part that does not change based on the received service start condition registration / change / deletion request and the service start condition registration state,
It is characterized by having a means for distinguishing a service activation condition part to be changed and a service activation condition part to be deleted.

As a proxy of the open API client for the open API server, it is determined based on the distinction whether or not to notify the open API server, and if not, the service activation in which the change does not occur The system further comprises notification determination means for forming a service activation condition registration / modification / deletion request from the condition part, the service activation condition part to be changed, and the service activation condition part to be deleted, and notifying the open API server. It is characterized by

The service control device according to the present invention is provided in the telecom network as a proxy for the open API client to the open API server, and the service is activated from the open API server when a service activation condition is satisfied on the telecom network. Upon receiving the activation condition satisfaction notification, a specifying unit that specifies at least one open API client that has registered the service starting condition corresponding to the service activation condition establishment notification, and a plurality of open API clients are specified by the specifying unit. In this case, a means for deciding a priority order for notifying all of the open API clients that the service activation condition is satisfied is provided.

As a proxy of the open API server for the open API client, when only one open API client is specified by the specifying means, a notification that the service activation condition is satisfied is sent to the open API client. However, when a plurality of open API clients are specified by the specifying unit, a notification unit is further provided for sequentially sending notifications that the service activation conditions are satisfied according to the priority order.

When there is no response from the open API client to the notification that the service activation condition is satisfied, which is sent to one open API client, the notifying means opens the AP having the next priority.
It is characterized in that a notification that the service activation condition is established is sent to the I client.

The open API client and the open API server are characterized in that they operate as a proxy device with the standard OpenAPI specifications without changing the interface.

As described above, by adding the service control device according to the present invention to the system composed of the server and the client application conforming to the standard OpenAPI specification, many service applications which cannot be realized by the standard OpenAPI specification can be realized. Regardless of having such service activation conditions, all service applications can be registered at the same time in the telecom carrier network. Further, it becomes possible to make a determination for preferentially providing the most appropriate service.

A service control device according to a second aspect of the present invention is an open API (Open Application Programming).
Interface), an open API system including an application (hereinafter, referred to as an open API client) and a plurality of open API servers that operate as a part of a telecom network, the open API servers for the open API clients. Receiving means for receiving any one of a service activation condition registration / change / deletion request and a call generation request from the open API client as a proxy of the open API client, and the receiving means as a proxy of the open API client for the plurality of open API servers. The API distribution means for notifying the request received by any one of the plurality of open API servers.

The plurality of open API servers are 1) physically plural but logically one on the telecom network, 2) physically plural, and logically divided into plural 3 ) The patterns are distributed in any one of the combination of 1) and 2) above, and the API distribution means determines one open API server to which the request is distributed.

As described above, the static control between the OpenAPI client and the OpenAPI server is separated by adding the service control system according to the present invention to the system composed of the server and the client application conforming to the standard OpenAPI specification. It becomes possible. This is, among other things, an Open
One OpenAPI request from API client
When forwarded to the server, it means that the next request from the same OpenAPI client may be forwarded to another OpenAPI server. The service control system hides the network topology for all OpenAPI clients.

[0023]

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

First Embodiment 1.1) Service Control System FIG. 1 is a schematic configuration diagram of an OpenAPI system using a service control system (SCS) according to an embodiment of the present invention. Here, a service control system 10 and an OpenAPI server 11 are provided on the network side, and the service control system 10 has a plurality of OpenAPIs.
It is interposed between the clients (applications using OpenAPI) C1 to CN and the OpenAPI server 11. The interface of the service control system 10 is an interface based on the OpenAPI specification. OpenAPI clients C1 to CN are also open
The enAPI server 11 does not need to know the existence of the service control system 10.

As described above, in OpenAPI (for example, Parlay), only the interface when the client and the server operate in a one-to-one correspondence is defined,
One client can request control for one call. In such a system, since a plurality of clients may not know the existence of the other party, there is a possibility that a plurality of different clients may make mutually competing requests for control of one call. Although such conflicting requests are prohibited in the OpenAPI system, the service control system 10 according to the present invention allows multiple clients to request control of the same call using the same OpenAPI specification without receiving an error. Is possible.

The service control program is composed of a series of interlock software modules as middleware, and can be written in platform-independent code. For example, as will be described later, the service control program registers / changes / starts service start conditions.
From the server, a module that accepts and stores the delete request, a module that analyzes the already stored request, a module that compares the newly accepted request with the current analysis result, and creates a request that notifies the server. It includes a module for deciding to which client and in what order the request fulfillment notification is to be sent when the request fulfillment notification is received.

The service control process is Open.
Communication is performed between the API clients C1 to CN and the OpenAPI server 11 through a normal transport system, that is, the transport system (for example, CORBA, WSDL, etc.) that the OpenAPI client and server are currently using to communicate with each other. .
The interfaces used on the service control software are all based on the OpenAPI specifications.

1.2) Acceptance and Processing of Requests from Multiple Clients FIG. 2 is a sequence diagram for explaining the operation of the service control system according to the embodiment of the present invention. The service control system 10 accepts a service activation condition registration / change / deletion request from the OpenAPI client,
Once processed, they are properly opened API server 11
Send to. If the request is first received from the client, the processed request is sent to the OpenAPI server 11.

1.3) Notification of Request Satisfaction to Multiple Clients When requests from a plurality of clients for controlling one call are accepted, the service control system 10 obtains a call satisfying the requests of the client from the network. Need to decide which clients should receive the notification.

In FIG. 2, when the service activation condition is satisfied on the network, the service control system 10 causes the network event (here, the request completion notification 11.
0) is received. When the request establishment notification 11.0 is received,
The service control system 10 first determines which client should receive the request establishment notification 11.0 (step S12).

According to the OpenAPI specification, the client that receives the event makes some kind of response. Therefore, when the request establishment notification 11.0 is received, the OpenAPI client should return a response. If there is no response (for example,
The service control system 10 sends the same event (request establishment notification 11.0) to the next priority client due to a logic failure of the client, a failure of the network, or the like.

If any client cannot receive an event, the service control system 10 notifies the OpenAPI server 11 of an error.

Second Embodiment 2.1) Service Control System FIG. 3 is a schematic configuration diagram of an OpenAPI system using a service control system (SCS) according to another embodiment of the present invention. Here, the service control system 20 and a plurality of OpenAPI servers S1 to S1 are provided on the network side.
SM and are provided. Service control system 20
Is an OpenAPI client (application that uses OpenAPI) 21 and a plurality of OpenAPIs.
It is interposed between the servers S1 to SM.

The service control system 20 is OpenAP
It acts as a proxy (proxy device) between the I client 21 and the OpenAPI server. The service control system 20 can receive a registration / change / deletion request of an event condition or a call generation request from the OpenAPI client 21. For these requests, an appropriate OpenAPI server is determined as a distribution destination and transmitted as described later.

From the OpenAPI client, the service control system 20 appears as an OpenAPI server. From the OpenAPI server, the service control system 20 may: 1) appear as a framework entity requesting a service interface on behalf of the framework after the OpenAPI client has been authenticated, or 2) call on behalf of another OpenAPI client, for example. It looks like an OpenAPI client requesting generation.

The interface of the service control system 20 is an interface based on the OpenAPI specification. OpenAPI client 21 is also OpenAP
The I servers S1 to SM do not need to know the existence of the service control system 20.

FIG. 4 is a schematic hardware configuration diagram of the service control system 20. In addition to the interfaces 201 and 204 for network connection, it has at least a processor 202 for executing the API distribution control program according to the present invention and a memory 203 for storing necessary reference data such as service activation conditions.

The API distribution control program is composed of a series of interlock software modules as middleware, and can be written in platform-independent code. For example, as described below, A
The PI distribution control program refers to the module that receives and stores the service activation condition registration / change / deletion request or the call generation request, and the service activation condition
It includes a module for deciding whether to distribute to the pen API server.

Note that the API distribution control process is
nAPI client 21 and OpenAPI server S1
Communicate with the SM through a normal transport system, that is, the transport system that the OpenAPI client and server are currently using to communicate with each other (eg, CORBA, WSDL, etc.). The interfaces used on the API distribution control software are all based on the OpenAPI specification.

2.2) API distribution control Registration / modification / control for controlling calls and / or call generation requests received from the OpenAPI client 21.
Traditionally, delete requests can only be sent to a particular OpenAPI server. For this purpose, OpenAPI
The static mapping between the client and the OpenAPI server cannot be changed at runtime. For example, based on an OpenAPI client's request to let us know if an event condition has occurred, this static relationship becomes less than desirable. Such inconvenience can be eliminated by introducing the service control system according to the present embodiment.

FIG. 5 is a sequence diagram showing an example of the API distribution control operation of the service control system according to the present invention. The service control system 20 can accept the event condition registration / change / deletion request RQ21.1 or the call generation request RQ21.2 from the OpenAPI client 21.

As described above, the service control system 20 is opened from the OpenAPI client 21.
Since it appears as an API server, the network configuration of the OpenAPI server is hidden from the client.
The service control system 20 is registered in the network of the OpenAPI server as a client.

[0043]

As described above, the standard OpenAP
By adding the service control system according to the first embodiment of the present invention to a system composed of a server and a client application conforming to the I specification, the standard O
Regardless of the service activation conditions of many service applications that cannot be realized by the penAPI specification, all service applications can be simultaneously registered in the telecom carrier network.
Further, it becomes possible to make a determination for preferentially providing the most appropriate service.

Further, by adding the service control system according to the second embodiment of the present invention to the system composed of the server and the client application conforming to the standard OpenAPI specification, the static relationship between the OpenAPI client and the OpenAPI server is established. Can be separated. This is especially true for some O
One request from the penAPI client is Open
It means that even if forwarded to the API server, the next request from the same OpenAPI client may be forwarded to another OpenAPI server. The service control system hides the network topology for all OpenAPI clients.

[Brief description of drawings]

FIG. 1 is a schematic configuration diagram of an OpenAPI system using a service control system (SCS) according to an embodiment of the present invention.

FIG. 2 is a sequence diagram illustrating an operation of the service control system according to the exemplary embodiment of the present invention.

FIG. 3 is a schematic configuration diagram of an OpenAPI system using a service control system (SCS) according to another embodiment of the present invention.

FIG. 4 is a schematic hardware configuration diagram of a service control system 20.

FIG. 5 is a sequence diagram showing an example of an API distribution control operation of the service control system according to the present invention.

[Explanation of symbols]

10 Service control system 11 OpenAPI server C1-CN OpenAPI client 20 Service control system 21 OpenAPI client S1-SM OpenAPI server

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor K. Sato             2-11-1, Nagatacho, Chiyoda-ku, Tokyo Stock             Ceremony company NTT Docomo (72) Inventor Yasuo Eguchi             2-11-1, Nagatacho, Chiyoda-ku, Tokyo Stock             Ceremony company NTT Docomo (72) Inventor Daniel A. Barnett             25th Forest, 1-4-30 Roppongi, Minato-ku, Tokyo             Building Nippon Lucent Technology Co., Ltd.             In the company (72) Inventor Fran Panken             Netherlands, Huizhen, Postbus 18,             Botterstraat 45, HE-3-04 (72) Inventor Andrew Jonathan Bennett             Great Britain and Northern Ireland             United Kingdom, Swindon, Business Par             Ku, Optimus Windmill Hill             1/125 F-term (reference) 5B076 AB10 AB17 BB06

Claims (22)

[Claims] 1. An open API (Open Application Pro)
In an open API system including an application using a programming interface (hereinafter referred to as an open API client) and an open API server that operates as a part of a telecom network, a proxy for the open API server to the open API client. A memory provided in the telecom network for storing a service activation condition registration / change / deletion request received from at least one open API client; and at least one service activation condition registration / change / stored in the memory. An analysis means for analyzing the service activation condition registration status from the deletion request, and a service activation condition part that does not change based on the newly received service activation condition registration / change / deletion request and the service activation condition registration status. Service control apparatus characterized by comprising: a service activation condition part to be changed, and means for distinguishing the service activation condition part to be deleted, the. 2. As a proxy of the open API client to the open API server, based on the distinction, it is determined whether or not to notify the open API server, and if so, the change does not occur. A notification determination means for forming a service activation condition registration / modification / deletion request from the service activation condition part, the service activation condition part to be changed, and the service activation condition part to be deleted, and notifying the open API server. The service control apparatus according to claim 1, further comprising: 3. Open API (Open Application Pro
In an open API system including an application using a programming interface (hereinafter referred to as an open API client) and an open API server that operates as a part of a telecom network, the open API for the open API server is provided.
It is provided in the telecom network on behalf of the client, and when a service activation condition satisfaction notification is received from the open API server when the service activation condition is satisfied on the telecom network, the service activation corresponding to the service activation condition satisfaction notification is received. When a plurality of open API clients are specified by the specifying unit that specifies at least one open API client that has performed condition registration, the service activation condition is satisfied for all of the open API clients. And a means for deciding a priority order for making a notification to that effect, a service control apparatus. 4. The open API client is notified of the establishment of the service activation condition when only one open API client is specified by the specifying means as a proxy of the open API server for the open API client. And a notification unit that sequentially sends notifications that the service activation condition is satisfied when the plurality of open API clients are specified by the specifying unit according to the priority order. 3. The service control device described in 3. 5. The notification means is one open API.
If there is no response from the open API client to the notification that the service activation condition has been satisfied, which is sent to the client, the open API with the next priority is sent.
The service control device according to claim 4, wherein a notification that the service activation condition is satisfied is sent to a PI client. 6. The service control apparatus according to claim 1, wherein the open API client and the open API server can operate with the standard OpenAPI specifications without changing interfaces. . 7. An open API (Open Application Pro
application (hereinafter referred to as open API client) using a gramming interface) and a plurality of open A that operate as part of the telecom network.
An open API system including a PI server and the open API as a proxy of the plurality of open API servers to the open API client.
Receiving means for receiving any one of a service activation condition registration / change / deletion request and a call generation request from a client; and a plurality of requests received by the receiving means on behalf of the open API clients for the open API servers. An API distribution means for notifying any of the open API servers of the above. 8. The plurality of open API servers are 1) physically plural but logically one on the telecom network, 2) physically plural, and logically divided into plural. And 3) the patterns are distributed in any one of the combination of 1) and 2) above, and the API distribution unit determines one open API server to which the request is distributed. 7. The service control device described in 7. 9. An open API (Open Application Pro)
In an open API system including an application using a programming interface (hereinafter referred to as an open API client) and an open API server that operates as a part of a telecom network, a proxy for the open API server to the open API client. Storing a service activation condition registration / change / deletion request received from at least one of the open API clients in a memory, and at least one service activation condition registration / change / deletion request already stored in the memory from the service activation condition Analyzing the registration status, based on the newly received service activation condition registration / change / deletion request and the service activation condition registration status, a service activation condition part that does not change, a service activation condition part to be changed, Should be deleted Distinguish between-bis activation condition part, the service control method, wherein a. 10. As a proxy of the open API client for the open API server, based on the distinction, it is determined whether or not to notify the open API server, and if so, the change does not occur. A service start condition registration / change / deletion request is composed of a service start condition part, the service start condition part to be changed, and the service start condition part to be deleted, and the associated service start condition registration / change / deletion is made. The service control method according to claim 9, wherein the delete request is notified to the open API server. 11. An open API (Open Application P
Application using the rogramming Interface)
(Hereinafter referred to as the open API client) and an open API that operates as part of the telecom network
An open API system including a server and the open API for the open API server.
On behalf of the client, a service activation condition satisfaction notification is received from the open API server when the service activation condition is satisfied on the telecom network, and the service activation condition registration corresponding to the service activation condition satisfaction notification is performed. One open API client is specified, and when the plurality of open API clients are specified, the priority order for notifying all of the open API clients that the service activation condition is satisfied is determined. Characterized service control method. 12. As a proxy of the open API server for the open API client, when only one open API client is specified, a notification that the service activation condition is satisfied is sent to the open API client, 12. The service control method according to claim 11, wherein when the plurality of open API clients are specified, the notification that the service activation condition is satisfied is sequentially transmitted in accordance with the priority order. 13. When there is no response from the open API client to the notification that the service activation condition is satisfied, which is sent to one open API client, the open API client having the next priority is sent to the open API client. 13. The service control method according to claim 12, further comprising sending a notification that the service activation condition is satisfied. 14. Open API (Open Application P
Application using the rogramming Interface)
In an open API system including (hereinafter, referred to as an open API client) and a plurality of open API servers that operate as a part of a telecom network, the open API server acts as a proxy for the plurality of open API servers to the open API client. API
One of the plurality of open API servers receives the received request as a proxy of the open API client for the plurality of open API servers and receives any one of the service activation condition registration / change / deletion request and the call generation request from the client. A service control method characterized by: 15. The plurality of open API servers are
On the telecom network, 1) physically plural but logically one, 2) physically plural, logically divided into plural, 3) combination of 1) and 2) above, 15. The service control method according to claim 14, wherein one open API server to which the request is distributed is determined, which is distributed in any pattern. 16. An open API (Open Application P
Application using the rogramming Interface)
(Hereinafter referred to as the open API client) and an open API that operates as part of the telecom network
In a service control program for causing a computer in an open API system including a server to act as a proxy of the open API server for the open API client, service activation condition registration / change / reception / received from at least one open API client Storing a delete request in the memory, analyzing the service start condition registration status from at least one service start condition registration / change / delete request already stored in the memory, and newly received service start condition registration A step of distinguishing a service start condition part that does not change, a service start condition part that should be changed, and a service start condition part that should be deleted based on the / change / delete request and the service start condition registration state; To have Characterized service control program. 17. A step of determining whether or not to notify the open API server based on the distinction, as a proxy of the open API client to the open API server, and if not, the change is made. Constructing a service start condition registration / change / deletion request from a service start condition part that does not occur, the service start condition part to be changed, and the service start condition part to be deleted; and the configured service start condition. The service control program according to claim 16, further comprising: a step of notifying a registration / change / deletion request to the open API server. 18. The open API (Open Application P
Application using the rogramming Interface)
(Hereinafter referred to as the open API client) and an open API that operates as part of the telecom network
A service control program for causing a computer in an open API system including a server to act as a proxy for the open API client to the open API server, wherein a service activation condition is satisfied on the telecom network, Receiving a service activation condition satisfaction notification, identifying at least one open API client that has registered the service activation condition corresponding to the service activation condition satisfaction notification, and when the plurality of open API clients are identified Includes a step of deciding a priority order for notifying all of the open API clients that the service activation condition is satisfied, and a service control program. Gram. 19. When only one open API client is specified, a step of sending a notification that the service activation condition is satisfied to the open API client, and when the plurality of open API clients are specified 19. The method further comprises the step of sequentially sending notifications indicating that the service activation conditions are satisfied in accordance with the priority order, and causing the open API client to function as a proxy for the open API server. The described service control program. 20. When there is no response from the open API client to the notification that the service activation condition has been established, which is sent to one open API client, the open API client having the next priority is sent to the open API client. 20. The service control program according to claim 19, further comprising the step of sending a notification that the service activation condition is satisfied. 21. Open API (Open Application P
Application using the rogramming Interface)
A computer in an open API system including (hereinafter, referred to as an open API client) and a plurality of open API servers that operate as a part of a telecom network, as a proxy of the plurality of open API servers to the open API client. In the service control program for functioning, receiving one of a service activation condition registration / change / deletion request and a call generation request from the open API client; and as a proxy of the open API client for the plurality of open API servers, And a step of notifying the received request to any of the plurality of open API servers. 22. The plurality of open API servers,
On the telecom network, 1) physically plural but logically one, 2) physically plural, logically divided into plural, 3) combination of 1) and 2) above, 22. The service control program according to claim 21, wherein one open API server to which the request is distributed is determined, which is distributed in any pattern.