(57)【要約】【課題】アプリケーションのファイル更新時に他のアプリケーションに影響を及ぼすことのないネットワーク制御システムを提供する。【解決手段】呼制御／プロトコル部１２は、呼が発生するとこの呼に関わる加入者を記憶部２００から検出し、検出した加入者に対応するサービスアプリケーションを３１〜３Ｎより検出する。そして複数のアプリケーションが検出される際に、上記複数のアプリケーションにファイル更新中のアプリケーションが含まれる場合には、当該呼を呼損処理する。また、ファイル更新中のアプリケーションが含まれる場合でも、このアプリケーションに特定のフラグが付加された情報が記憶部２００に記録される場合には、このアプリケーションを除いて呼を継続してイベント通知して、他のファイル更新を行っていないアプリケーションを起動してサービスを提供するようにしたものである。【選択図】      図１
2005236647.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムにおいて、
加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段と、
加入者からの要求に含まれる加入者の識別情報を検出する加入者検出手段と、
前記記憶手段が記憶する情報に基づき、前記加入者検出手段が検出した加入者に対応づけられたアプリケーションを検出するアプリケーション検出手段と、
このアプリケーション検出手段が検出したアプリケーションが運用可能な状態にない場合に、前記要求を破棄する要求処理手段とを具備することを特徴とするネットワーク制御システム。
【請求項２】
サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムにおいて、
加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段と、
加入者からの要求に含まれる加入者の識別情報を検出する加入者検出手段と、
前記記憶手段が記憶する情報に基づき、前記複数のアプリケーションの各々について、前記加入者検出手段が検出した加入者の識別情報に対応づけられたものか否か判定するアプリケーション判定手段と、
このアプリケーション判定手段が加入者の識別情報に対応づけられたアプリケーションと判定したものの中に、運用可能な状態にないアプリケーションが存在する場合に、前記要求を破棄する要求処理手段とを具備することを特徴とするネットワーク制御システム。
【請求項３】
前記記憶手段は、加入者が利用するアプリケーションの識別情報に、要求を破棄するか否かを示す破棄情報を対応づけて記憶するものであって、
前記要求処理手段は、運用可能な状態にないアプリケーションが存在する場合であっても、前記記憶手段において、前記運用可能な状態にないアプリケーションの識別情報に対応づけられた破棄情報が破棄しないことを示す場合には、前記要求を破棄しないことを特徴とする請求項１または請求項２に記載のネットワーク制御システム。
【請求項４】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、少なくとも前記着信先の加入者を示す着信先情報を含み、
さらに、前記着信先情報に基づいて、着信先の加入者が当該システムの加入者か否かを判定する着信先判定手段を備え、
前記加入者検出手段は、前記着信先判定手段が、前記着信先の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる着信先情報を加入者の識別情報として検出することを特徴とする請求項１乃至請求項３のいずれかに記載のネットワーク制御システム。
【請求項５】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、少なくとも前記発生元の加入者を示す発信元情報を含み、
さらに、前記発信元情報に基づいて、発信元の加入者が当該システムの加入者か否かを判定する発信元判定手段を備え、
前記加入者検出手段は、前記発信元判定手段が、前記発信元の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる発信元情報を加入者の識別情報として検出することを特徴とする請求項１乃至請求項３のいずれかに記載のネットワーク制御システム。
【請求項６】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、前記発生元の加入者を示す発信元情報と、前記着信先の加入者を示す着信先情報とを含み、
さらに、前記発信元情報に基づいて、発信元の加入者が当該システムの加入者か否かを判定する発信元判定手段と、
前記着信先情報に基づいて、着信先の加入者が当該システムの加入者か否かを判定する着信先判定手段とを備え、
前記加入者検出手段は、前記着信先判定手段が、前記着信先の加入者が当該システムの加入者であると判定し、かつ前記発信元判定手段が、前記発信元の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる発信元情報および着信先情報を加入者の識別情報として検出することを特徴とする請求項１乃至請求項３のいずれかに記載のネットワーク制御システム。
【請求項７】
サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムのプログラムにおいて、
加入者からの要求に含まれる加入者の識別情報を検出する加入者検出手段と、
加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段が記憶する情報に基づき、前記加入者検出手段が検出した加入者に対応づけられたアプリケーションを検出するアプリケーション検出手段と、
このアプリケーション検出手段が検出したアプリケーションが運用可能な状態にない場合に、前記要求を破棄する要求処理手段として前記ネットワーク制御システムを機能させるためのプログラム。
【請求項８】
サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムのプログラムにおいて、
加入者からの要求に含まれる加入者の識別情報を検出する加入者検出手段と、
加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段が記憶する情報に基づき、前記複数のアプリケーションの各々について、前記加入者検出手段が検出した加入者の識別情報に対応づけられたものか否か判定するアプリケーション判定手段と、
このアプリケーション判定手段が加入者の識別情報に対応づけられたアプリケーションと判定したものの中に、運用可能な状態にないアプリケーションが存在する場合に、前記要求を破棄する要求処理手段として前記ネットワーク制御システムを機能させるためのプログラム。
【請求項９】
前記記憶手段は、加入者が利用するアプリケーションの識別情報に、要求を破棄するか否かを示す破棄情報を対応づけて記憶するものであって、
前記要求処理手段は、運用可能な状態にないアプリケーションが存在する場合であっても、前記記憶手段において、前記運用可能な状態にないアプリケーションの識別情報に対応づけられた破棄情報が破棄しないことを示す場合には、前記要求を破棄しないことを特徴とする請求項７または請求項８に記載のプログラム。
【請求項１０】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、少なくとも前記着信先の加入者を示す着信先情報を含み、
さらに、前記着信先情報に基づいて、着信先の加入者が当該システムの加入者か否かを判定する着信先判定手段を備え、
前記加入者検出手段は、前記着信先判定手段が、前記着信先の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる着信先情報を加入者の識別情報として検出することを特徴とする請求項７乃至請求項９のいずれかに記載のプログラム。
【請求項１１】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、少なくとも前記発生元の加入者を示す発信元情報を含み、
さらに、前記発信元情報に基づいて、発信元の加入者が当該システムの加入者か否かを判定する発信元判定手段を備え、
前記加入者検出手段は、前記発信元判定手段が、前記発信元の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる発信元情報を加入者の識別情報として検出することを特徴とする請求項７乃至請求項９のいずれかに記載のプログラム。
【請求項１２】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、前記発生元の加入者を示す発信元情報と、前記着信先の加入者を示す着信先情報とをを含み、
さらに、前記発信元情報に基づいて、発信元の加入者が当該システムの加入者か否かを判定する発信元判定手段と、
前記着信先情報に基づいて、着信先の加入者が当該システムの加入者か否かを判定する着信先判定手段とを備え、
前記加入者検出手段は、前記着信先判定手段が、前記着信先の加入者が当該システムの加入者であると判定し、かつ前記発信元判定手段が、前記発信元の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる発信元情報および着信先情報を加入者の識別情報として検出することを特徴とする請求項７乃至請求項９のいずれかに記載のプログラム。
【請求項１３】
サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムの制御方法において、
加入者からの要求に含まれる加入者の識別情報を検出する加入者検出工程と、
加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段が記憶する情報に基づき、前記加入者検出工程で検出した加入者に対応づけられたアプリケーションを検出するアプリケーション検出工程と、
このアプリケーション検出工程で検出したアプリケーションが運用可能な状態にない場合に、前記要求を破棄する要求処理工程とを具備することを特徴とするネットワーク制御システムの制御方法。
【請求項１４】
サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムの制御方法において、
加入者からの要求に含まれる加入者の識別情報を検出する加入者検出工程と、
加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段が記憶する情報に基づき、前記複数のアプリケーションの各々について、前記加入者検出工程で検出した加入者の識別情報に対応づけられたものか否か判定するアプリケーション判定工程と、
このアプリケーション判定工程で加入者の識別情報に対応づけられたアプリケーションと判定したものの中に、運用可能な状態にないアプリケーションが存在する場合に、前記要求を破棄する要求処理工程とを具備することを特徴とするネットワーク制御システムの制御方法。
【請求項１５】
前記記憶手段は、加入者が利用するアプリケーションの識別情報に、要求を破棄するか否かを示す破棄情報を対応づけて記憶するものであって、
前記要求処理工程は、運用可能な状態にないアプリケーションが存在する場合であっても、前記記憶手段において、前記運用可能な状態にないアプリケーションの識別情報に対応づけられた破棄情報が破棄しないことを示す場合には、前記要求を破棄しないことを特徴とする請求項１３または請求項１４に記載のネットワーク制御システムの制御方法。
【請求項１６】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、少なくとも前記着信先の加入者を示す着信先情報を含み、
さらに、前記着信先情報に基づいて、着信先の加入者が当該システムの加入者か否かを判定する着信先判定工程を備え、
前記加入者検出工程は、前記着信先判定工程で、前記着信先の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる着信先情報を加入者の識別情報として検出することを特徴とする請求項１３乃至請求項１５のいずれかに記載のネットワーク制御システムの制御方法。
【請求項１７】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、少なくとも前記発生元の加入者を示す発信元情報を含み、
さらに、前記発信元情報に基づいて、発信元の加入者が当該システムの加入者か否かを判定する発信元判定工程を備え、
前記加入者検出工程は、前記発信元判定工程で、前記発信元の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる発信元情報を加入者の識別情報として検出することを特徴とする請求項１３乃至請求項１５のいずれかに記載のネットワーク制御システムの制御方法。
【請求項１８】
前記要求は、発生元の加入者が所望の加入者を着信先とした通信を要求するものであって、前記発生元の加入者を示す発信元情報と、前記着信先の加入者を示す着信先情報とを含み、
さらに、前記着信先情報に基づいて、着信先の加入者が当該システムの加入者か否かを判定する着信先判定工程とを備え、
前記発信元情報に基づいて、発信元の加入者が当該システムの加入者か否かを判定する発信元判定工程と、
前記加入者検出工程は、前記着信先判定工程で、前記着信先の加入者が当該システムの加入者であると判定し、かつ前記発信元判定工程で、前記発信元の加入者が当該システムの加入者であると判定した場合に、前記要求に含まれる発信元情報および着信先情報を加入者の識別情報として検出することを特徴とする請求項１３乃至請求項１５のいずれかに記載のネットワーク制御システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、呼制御機能などのネットワーク機能を外部に公開することで、キャリア以外の事業者においても付加的なサービスアプリケーション（以下、アプリケーションと記す）の開発を可能にすることを目的としたOpen Application Programming Interfaceシステムに関する。
【背景技術】
【０００２】
周知のように、Open Application Programming Interface（以下、OpenAPIと略称する）仕様に基づくプラットフォーム（以下、PFと略称する）がある。このPF上で動作するサービスアプリケーション（以下、アプリケーションと略称する）は、PFに対して、通知を受けたい呼の状態をイベント通知条件として登録する。
【０００３】
一方、PFは、呼の状態が変化する度に、その呼とアプリケーションによって登録された呼の状態とを比較し、一致すれば、該当アプリケーションに対して呼の状態をイベントとして通知する。そして、この通知を受けたアプリケーションは、PFに対して転送等の指示をすることで呼制御を行う。  
なお、１つのPF上には、複数のアプリケーションを配備することが可能であるとともに、１つの呼に関するイベントを複数のアプリケーションに通知することも可能である。
【０００４】
ところで、サービスの機能追加や不具合の修正を行う場合、アプリケーションのファイルを更新する必要がある。一般にこれまでのOpenAPIのアプリケーションのファイル更新手順は、旧アプリケーションを停止した後に新アプリケーションを起動する。このため、新アブリケーションヘの切り替え時には一時的にアプリケーションが起動されていない期間が生じる。
【０００５】
この期間に該アプリケーションで制御すべき発呼または着呼が生じた場合には、アプリケーションのサービス内容にもよるが、大多数は該呼を呼損とする必要がある。  
そして、１つの呼に関するイベントを複数のアプリケーションに通知する場合に、図６に示すように、上記複数のアプリケーションにファイル更新中でないアプリケーションとファイル更新中のアプリケーションの両方が含まれる場合、少なくともファイル更新中のアプリケーションについては呼損とすべきであるが、従来においては、呼が継続してしまうという問題があった。
【０００６】
またアプリケーション毎にサービスを提供する事業者が異なる場合もある。この場合、イベント通知の対象となる複数のアプリケーションのうちの１つをファイル更新する際に、該当アプリケーションのサービスが中断となることは許容されても、他の事業者のサービスには影響を及ぼすことは許容されない。
【０００７】
基本的な呼モデルとしてイベントを通知する点で類似するインテリジェントネットワーク（以下、INと略称する）がある（例えば、特許文献１参照）。このINでは、サービス論理入れ替え時に一時的に新旧のサービス論理を二重置きし、新規呼は新サービス論理に振り分けることで不具合を解決しようとしている。
【０００８】
しかしながら、現状のOpenAPI仕様ではアプリケーションを二重置きするためのAPIは規定されていないため、同様の方式を採用するためにはAPIを独自に拡張する必要があるが、APIを独自に拡張するとアプリケーションのポータビリティが損なわれるため好ましくない。
【０００９】
【特許文献１】特開平８−１６８０６３公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従来では、加入者からの要求に関わる加入者に対応する複数のアプリケーションに、ファイル更新中でないアプリケーションとファイル更新中のアプリケーションの両方が含まれる場合、要求が継続してしまうという問題があった。
この発明は上記の問題を解決すべくなされたもので、上記要求に関わる加入者に対応づけられた複数のアプリケーションに、ファイル更新中のアプリケーションが含まれる場合には、確実に要求を破棄することが可能なネットワーク制御システム、ネットワーク制御システムのプログラムおよびネットワーク制御システムの制御方法を提供することを目的とする。
【００１１】
また従来では、例えばOpenAPIなど仕様に基づくプラットフォームでは、アプリケーションのファイル更新にアプリケーションを二重置きする仕様となっていないため、アプリケーションのファイル更新を行うと、他のアプリケーションに影響を及ぼす虞があるという問題があった。
【００１２】
この発明は上記の問題を解決すべくなされたもので、アプリケーションのファイル更新にアプリケーションを二重置きするといったプラットフォーム拡張を行わなくても、アプリケーションのファイル更新時に他のアプリケーションに影響を及ぼすことのないネットワーク制御システム、ネットワーク制御システムのプログラムおよびネットワーク制御システムの制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の目的を達成するために、この発明は、サービスを提供する複数のアプリケーションを備え、ネットワークを通じた加入者からの要求に応じて、予め設定されたサービスを提供するネットワーク制御システムにおいて、加入者の識別情報と、加入者が利用するアプリケーションの識別情報とを対応づけて記憶する記憶手段と、加入者からの要求に含まれる加入者の識別情報を検出する加入者検出手段と、記憶手段が記憶する情報に基づき、加入者検出手段が検出した加入者に対応づけられたアプリケーションを検出するアプリケーション検出手段と、このアプリケーション検出手段が検出したアプリケーションが運用可能な状態にない場合に、要求を破棄する要求処理手段とを具備して構成するようにした。
【００１４】
また、記憶手段に、加入者が利用するアプリケーションの識別情報と、要求を破棄するか否かを示す破棄情報とを対応づけて記憶するようにし、要求処理手段が、運用可能な状態にないアプリケーションが存在する場合であっても、記憶手段において、運用可能な状態にないアプリケーションの識別情報に対応づけられた破棄情報が破棄しないことを示す場合には、要求を破棄しないことを特徴とする。
【発明の効果】
【００１５】
以上述べたように、この発明では、加入者からの要求に含まれる加入者の識別情報を検出し、この検出した加入者に対応づけられたアプリケーションを検出し、そしてこの検出したアプリケーションが運用可能な状態にない場合に、上記要求を破棄するようにしている。
【００１６】
したがって、この発明によれば、上記要求に関わる加入者に対応づけられたアプリケーションのうち、ファイル更新を行うなどして運用可能な状態にないものが含まれる場合でも、確実に要求を破棄することが可能なネットワーク制御システム、ネットワーク制御システムのプログラムおよびネットワーク制御システムの制御方法を提供できる。
【００１７】
またこの発明では、運用可能な状態にないアプリケーションが存在する場合であっても、記憶手段の情報により、運用可能な状態にないアプリケーションが予め設定したものの場合には、要求を破棄しないようにした。
したがって、この発明によれば、アプリケーションのファイル更新にアプリケーションを二重置きするといったプラットフォーム拡張を行わなくても、アプリケーションのファイル更新時に他のアプリケーションに影響を及ぼすことのないネットワーク制御システム、ネットワーク制御システムのプログラムおよびネットワーク制御システムの制御方法を提供できる。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照して、この発明の一実施形態について説明する。  
図１は、この発明の一実施形態に係わるネットワーク制御システムの構成を示すものである。この図に示すように、ネットワーク制御システムは、制御装置１００と、記憶部２００と、通信部３００とを備える。
【００１９】
制御装置１００は、ネットワークＮＷを通じて発着信が生じた場合に、後述するアプリケーションによって上記発着信に関わる加入者に対して種々のサービスを提供するものであって、プラットフォーム呼処理機能部１０と、ソフトウェアバス２０と、複数のサービスアプリケーション３１〜３Ｎとを搭載し、記憶部２００と通信部３００を収容する。
【００２０】
プラットフォーム呼処理機能部１０は、当該制御装置１００のプラットフォーム上で、通信部３００を制御してネットワークＮＷを通じた発呼および着呼に関わる制御を行うものであって、OpenAPI１１と呼制御／プロトコル部１２とを備える。
サービスアプリケーション（以下、アプリケーションと略称する）３１〜３Ｎは、上記OpenAPI１１を使用して動作し、種々のサービスを提供するものであって、その動作はソフトウェアバス２０を介してプラットフォーム呼処理機能部１０によって制御される。
【００２１】
記憶部２００には、アプリケーション３１〜３Ｎに予め割り振られたＩＤ−１〜ＩＤ−Ｎと、サービスを受ける加入者の識別情報とが対応づけられて記憶されている。そして、呼制御／プロトコル部１２は、発呼または着呼が生じた場合に、記憶部２００に記憶される情報に基づいて、発生した呼に関わる加入者に対応するアプリケーション３１〜３Ｎに対してイベント通知を行う。また記憶部２００は、制御装置１００の制御プログラムを記憶する。
【００２２】
次に、上記構成の制御装置１００の動作について説明する。ここでは特に、この発明に関わる発呼もしくは着呼が発生したときの呼処理に関わる動作について説明する。図２は、この動作を説明するためのフローチャートであって、発呼または着呼が発生すると、呼制御／プロトコル部１２によって実行される。この図で示される処理を実現するための制御プログラムは、記憶部２００に記憶される。
【００２３】
まずステップＳ２０１において呼制御／プロトコル部１２は、記憶部２００に記憶される加入者データを検索して、当該呼に関わる加入者を検出する。そしてこの検出した加入者が利用するものとして対応づけられたアプリケーション（３１〜３Ｎのいずれか）のＩＤを記憶部２００からすべて検出し、ステップＳ２０２に移行する。
【００２４】
ステップＳ２０２において呼制御／プロトコル部１２は、ステップＳ２０１にて検出したＩＤに対応するアプリケーションのうち、イベント通知処理を実施していないアプリケーションがあるか否かを判定する。ここで、イベント通知処理を実施していないアプリケーションがある場合には、ステップＳ２０３に移行し、一方、イベント通知処理を実施していないアプリケーションがない場合には、ステップＳ２０４に移行して、呼を継続する処理を実施し、イベント通知が成功したアプリケーションによるサービスを加入者に提供し、当該処理を終了する。
【００２５】
ステップＳ２０３において呼制御／プロトコル部１２は、ステップＳ２０１にて検出したＩＤに対応するアプリケーションのうち、イベント通知処理を実施していない１つのアプリケーションに対して、イベント通知処理を実施し、ステップＳ２０５に移行する。
【００２６】
ステップＳ２０５において呼制御／プロトコル部１２は、ステップＳ２０３にて実施したイベント通知が成功したか否かを判定する。ここで、上記アプリケーションが運用可能な状態にあって、イベント通知が成功した場合には、イベント通知されたアプリケーションが起動され、ステップＳ２０２に移行して、ステップＳ２０１にて検出したＩＤに対応するアプリケーションのうち、イベント通知処理を実施していない残りのアプリケーションについてイベント通知処理を実施する。
【００２７】
一方、イベント通知を行ったアプリケーションがファイル更新中などによって運用不可能な状態にあって、イベント通知処理が失敗した場合には、ステップＳ２０６に移行して、当該呼を呼損処理するとともに、当該処理によって起動されたアプリケーションを停止させ、以後ステップＳ２０１にて検出したＩＤに対応する残りのアプリケーションに対するイベント通知処理は行うことなく当該処理を終了し、新たな呼の発生を待機する。
【００２８】
以上のように、上記構成の制御装置１００では、イベント通知を行ったアプリケーションがファイル更新中などによってイベント通知処理が失敗した場合には、イベント通知が成功したアプリケーションがあっても当該呼を呼損処理するようにしている。
したがって、上記構成のネットワーク制御システムによれば、１つの呼に関するイベントを複数のアプリケーションに通知する際に、上記複数のアプリケーションにファイル更新中のアプリケーションが含まれる場合には、確実に呼損とすることができる。
【００２９】
なお、この発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また上記実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。
【００３０】
その一例として例えば、上記実施の形態では、図２に示す処理にしたがって、呼損処理や呼継続処理を実施するようにしたが、これに代わって例えば、図３に示す処理にしたがって、呼損処理や呼継続処理を実施するようにしてもよい。以下、図３を参照して、制御装置１００の呼処理動作について説明する。
【００３１】
この処理は、発呼または着呼が発生すると、呼制御／プロトコル部１２によって実行される。  
まずステップＳ３０１において呼制御／プロトコル部１２は、パラメータｎに「１」を設定し、ステップ３０２に移行する。
ステップＳ３０２において呼制御／プロトコル部１２は、パラメータｎが搭載アプリケーション総数Ｎより大きいか否かを判定する。ここで、パラメータｎが搭載アプリケーション総数Ｎより大きい場合には、ステップＳ３０３に移行し、一方、パラメータｎが搭載アプリケーション総数Ｎ以下の場合には、ステップＳ３０４に移行する。
【００３２】
ステップＳ３０３において呼制御／プロトコル部１２は、呼を継続する処理を実施し、イベント通知が成功したアプリケーションによるサービスを加入者に提供し、当該処理を終了する。
ステップＳ３０４において呼制御／プロトコル部１２は、記憶部２００に記憶される加入者データを検索して、当該呼に関わる加入者を検出し、ステップＳ３０５に移行する。
【００３３】
ステップＳ３０５において呼制御／プロトコル部１２は、ＩＤ−ｎに対応するアプリケーションが、ステップＳ３０４で検出した加入者が利用するものとして記憶部２００に対応づけられているか否か判定する。ここで、ＩＤ−ｎに対応するアプリケーションが上記加入者に対応づけられている場合には、ステップＳ３０６に移行し、一方、ＩＤ−ｎに対応するアプリケーションが上記加入者に対応づけられていない場合には、ステップＳ３０７に移行する。  
ステップＳ３０６において呼制御／プロトコル部１２は、ＩＤ−ｎに対応するアプリケーションに対して、イベント通知処理を実施し、ステップＳ３０８に移行する。
【００３４】
ステップＳ３０８において呼制御／プロトコル部１２は、ステップＳ３０６にて実施したイベント通知が成功したか否かを判定する。ここで、上記アプリケーションが運用可能な状態にあって、イベント通知が成功した場合には、イベント通知されたアプリケーションが起動され、ステップＳ３０７に移行して、ｎに「１」を加算して、ステップＳ３０２に移行し、残りのアプリケーションについて処理を実施する。
【００３５】
一方、イベント通知を行ったアプリケーションがファイル更新中などによって運用不可能な状態にあって、イベント通知処理が失敗した場合には、ステップＳ３０９に移行して、当該呼を呼損処理するとともに、当該処理によって起動されたアプリケーションを停止させ、残りのアプリケーションに対するイベント通知処理は行うことなく当該処理を終了し、新たな呼の発生を待機する。
【００３６】
以上のような処理においても、制御装置１００は、イベント通知を行ったアプリケーションがファイル更新中などによってイベント通知処理が失敗した場合には、イベント通知が成功したアプリケーションがあっても当該呼を呼損処理するようにしている。
このため、１つの呼に関するイベントを複数のアプリケーションに通知する際に、上記複数のアプリケーションにファイル更新中のアプリケーションが含まれる場合には、確実に呼損とすることができる。  
なお、この図３で示した処理を実現するための制御プログラムは、記憶部２００に記憶される。
【００３７】
また上記図２および図３に示した処理では、１つの呼に関するイベントを複数のアプリケーションに通知する際に、上記複数のアプリケーションにファイル更新中のアプリケーションが含まれる場合には、確実に呼損とするようにした。
これに対して例えば、図２に示したステップＳ２０６あるいは図３に示したステップＳ３０９における呼損処理において、図４に示すような処理を実施するようにしてもよい。なお、この場合、記憶部２００に記録した、アプリケーションのＩＤと加入者の識別情報とを対応づけたテーブルにおいて、さらにアプリケーション毎に呼損処理を行うか否かを示す呼損フラグを付加して記憶するようにする。
【００３８】
このような構成では、まずステップＳ４０１において呼制御／プロトコル部１２は、イベント通知に失敗したアプリケーションのＩＤに対応づけられた呼損フラグを参照し、呼損が設定されているか否（呼継続）かを判定する。ここで、呼損フラグが呼損を示す場合には、ステップＳ４０２に移行して、当該呼を呼損処理するとともに、当該処理によって起動されたアプリケーションを停止させ、当該処理を終了し、新たな呼の発生を待機する。
【００３９】
一方、呼損フラグが呼継続を示す場合には、すでにイベント通知によって起動されたアプリケーションを停止させることなく、ステップＳ２０２もしくはステップＳ３０７に移行して、処理を継続する。
このような処理を、図２に示したステップＳ２０６あるいは図３に示したステップＳ３０９における呼損処理において実施することにより、ファイル更新中のアプリケーションが含まれる場合でも、このアプリケーションを除いて、呼を継続し、ファイル更新を行っていないアプリケーションによってサービスを提供することができる。このため、上記複数のアプリケーションが異なる事業者に渡る場合でも、アプリケーションのファイル更新が他のアプリケーションに影響を及ぼすことがない。  
なお、この図４で示した処理を実現するための制御プログラムは、記憶部２００に記憶される。
【００４０】
また図２に示したステップＳ２０２や図３に示したステップＳ３０４では、記憶部２００に記憶される加入者データを検索して、当該呼に関わる加入者を検出するようにしたが、上記ステップＳ２０２およびステップＳ３０４において、図５に示すようなサブルーチン処理を実施するようにしてもよい。
【００４１】
このサブルーチン処理では、まずステップＳ５０１において呼制御／プロトコル部１２は、発信元のアドレスに基づいて、発信元が当該ネットワーク制御システムの加入者か否かを判断する。ここで、当該ネットワーク制御システムの加入者でない場合には、ステップＳ５０２に移行し、一方、当該ネットワーク制御システムの加入者である場合には、ステップＳ５０３に移行する。
【００４２】
ステップＳ５０２において呼制御／プロトコル部１２は、着信先のアドレスに基づいて、着信先が当該ネットワーク制御システムの加入者か否かを判断する。ここで、当該ネットワーク制御システムの加入者でない場合には、ステップＳ５０４に移行し、一方、当該ネットワーク制御システムの加入者である場合には、ステップＳ５０５に移行する。
【００４３】
一方、ステップＳ５０３において呼制御／プロトコル部１２は、着信先のアドレスに基づいて、着信先が当該ネットワーク制御システムの加入者か否かを判断する。ここで、当該ネットワーク制御システムの加入者でない場合には、ステップＳ５０６に移行し、一方、当該ネットワーク制御システムの加入者である場合には、ステップＳ５０７に移行する。
【００４４】
ステップＳ５０４において呼制御／プロトコル部１２は、発信元および着信先がともに当該ネットワーク制御システムの加入者でないことより、当該呼を中継呼と判断し、加入者を検索することなく当該処理を終了する。
ステップＳ５０５において呼制御／プロトコル部１２は、着信先のみが当該ネットワーク制御システムの加入者であることより、当該呼を着信呼と判断し、呼に含まれるToアドレスをキーとして、記憶部２００に記憶される加入者データを検索して、当該呼に関わる加入者を検出し、上記ステップＳ２０２もしくはステップＳ３０４の処理に復帰する。
【００４５】
ステップＳ５０６において呼制御／プロトコル部１２は、発信元のみが当該ネットワーク制御システムの加入者であることより、当該呼を発信呼と判断し、呼に含まれるFromアドレスをキーとして、記憶部２００に記憶される加入者データを検索して、当該呼に関わる加入者を検出し、上記ステップＳ２０２もしくはステップＳ３０４の処理に復帰する。
【００４６】
ステップＳ５０７において呼制御／プロトコル部１２は、発信元および着信先がともに当該ネットワーク制御システムの加入者であることより、呼に含まれるFromアドレスおよび呼に含まれるToアドレスをキーとして、記憶部２００に記憶される加入者データを検索して、当該呼に関わる加入者を検出し、上記ステップＳ２０２もしくはステップＳ３０４の処理に復帰する。
【００４７】
このようなサブルーチン処理を実施することにより、検索対象となる加入者を絞り込むことができるので、迅速な処理を行うことができる。  
なお、この図５で示した処理を実現するための制御プログラムは、記憶部２００に記憶される。
また図１に示したネットワーク制御システムでは、制御装置１００上に設けたサービスアプリケーション３１〜３Ｎを機能させる場合を例に挙げて説明したが、制御装置１００にネットワーク接続されるサーバ上に設けられたサービスアプリケーションを機能させる場合にも適用可能である。
【００４８】
さらには、サービスアプリケーションが運用不可能な状態の例として、ファイル更新時を例に挙げて説明したが、これに限定されるものではなく、その他の要因によってサービスアプリケーションが運用不可能な場合にも同様の処理により対応することができる。
【００４９】
すなわち、ステップＳ２０５やステップＳ３０８において、サービスアプリケーションに何らかの不具合があって運用不可能な場合には、イベント通知が失敗することになり、後段の呼損処理Ｓ２０６もしくはＳ３０９を実施する。  
その他、この発明の要旨を逸脱しない範囲で種々の変形を施しても同様に実施可能であることはいうまでもない。
【図面の簡単な説明】
【００５０】
【図１】この発明に係わるネットワーク制御システムの一実施形態の構成を示す図。
【図２】図１に示したネットワーク制御システムの呼処理を説明するためのフローチャート。
【図３】図１に示したネットワーク制御システムの呼処理を説明するためのフローチャート。
【図４】図２および図３に示した呼損処理を説明するためのフローチャート。
【図５】図２および図３に示した加入者検索処理を説明するためのフローチャート。
【図６】１つの呼に関するイベントを複数のアプリケーションに通知する場合の動作を説明するための図。
【符号の説明】
【００５１】
１０…プラットフォーム呼処理機能部、１１…OpenAPI、１２…呼制御／プロトコル部、２０…ソフトウェアバス、３１〜３Ｎ…サービスアプリケーション、１００…制御装置、２００…記憶部、３００…通信部、ＮＷ…ネットワーク。
【図１】
2005236647.tif 000003
【図２】
2005236647.tif 000004
【図３】
2005236647.tif 000005
【図４】
2005236647.tif 000006
【図５】
2005236647.tif 000007
【図６】
2005236647.tif 000008