(57)【要約】【課題】ＡＰＩ利用者ごとの認可制御を容易に実現し、また悪意呼を適切に監視して規制する。【解決手段】ＡＰＩ利用者ごとの状態数４４１−１〜４４１−Ｍを管理する認可情報管理部４４０を設け、認可された状態の最大数である最大状態数４４２−ｊを超えた状態生成を中止する。また、短時間で終了した呼である短時間保留呼をＡＰＩ利用者ごとに数える短時間保留呼数管理部４６０を追加し、短時間保留呼数４６１−ｋが予め決定された閾値４６３を超過した場合に、当該ＡＰＩ利用者を悪意ある利用者と判断し、ＡＰＩ呼び出しを中止するための閉塞フラグ４６２−ｋをＯＮにする。【選択図】図２
2010288021.tif 000002
【特許請求の範囲】
【請求項１】
ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを提供するＡＰＩゲートウェイ装置において、
ＡＰＩ利用者ごとに、生成された呼状態及びメディア状態それぞれの状態の状態数と予め決定された最大許容状態数とを含む認可情報を記憶する認可情報記憶手段と、
一のＡＰＩ利用者から前記ＡＰＩ呼出し要求を受けたとき、前記記憶された認可情報から、前記一のＡＰＩ利用者に対応する、前記ＡＰＩ呼出し要求に応じた状態の状態数と最大許容状態数とを参照し、前記状態数が前記最大許容状態数以下である場合に状態を生成する認可制御手段と、
を備えたことを特徴とするＡＰＩゲートウェイ装置。
【請求項２】
ＡＰＩ呼出し要求に応じて呼制御ＡＰＩを提供するＡＰＩゲートウェイ装置において、
ＡＰＩ利用者ごとに、呼状態の生成後、呼接続状態に移行することなく呼切断状態へ移行した状態である保留状態の単位時間あたりの保留呼数を記憶する保留呼数記憶手段と、
一のＡＰＩ利用者からＡＰＩ呼出し要求を受けて前記保留状態になった場合に、前記記憶された保留呼数を１つ増やして更新記憶し、その更新記憶された保留呼数が予め決定された閾値よりも大きい場合に、前記一のＡＰＩ利用者に対応する閉塞フラグを設定する閉塞フラグ設定手段と、
一のＡＰＩ利用者からのＡＰＩ呼出し要求に応じた呼状態の生成に際し、前記一のＡＰＩ利用者に対応する前記閉塞フラグが設定されていない場合にのみ呼状態の生成を許可する悪意呼閉塞処理手段と、
を備えたことを特徴とするＡＰＩゲートウェイ装置。
【請求項３】
ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを提供するＡＰＩ提供方法において、
一のＡＰＩ利用者から前記ＡＰＩ呼出し要求を受付ける要求受付ステップと、
ＡＰＩ利用者ごとの、生成された呼状態及びメディア状態それぞれの状態の状態数と予め決定された最大許容状態数とを含む認可情報から、前記一のＡＰＩ利用者に対応する、前記ＡＰＩ呼出し要求に応じた状態の状態数と最大許容状態数とを参照し、前記状態数が前記最大許容状態数以下である場合に状態を生成する認可制御ステップと、
を有したことを特徴とするＡＰＩ提供方法。
【請求項４】
ＡＰＩ呼出し要求に応じて呼制御ＡＰＩを提供するＡＰＩ提供方法において、
一のＡＰＩ利用者から前記ＡＰＩ呼出し要求を受付ける要求受付ステップと、
前記一のＡＰＩ利用者に対応する閉塞フラグが設定されていない場合にのみ呼状態の生成を許可する呼状態生成許可ステップと、
前記呼状態生成許可ステップにおいて呼状態の生成が許可された場合に、呼状態を生成する呼状態生成ステップと、
前記呼状態の生成後、呼接続状態に移行することなく呼切断状態へ移行した状態である保留状態になった場合には、前記保留状態の単位時間あたりの保留呼数を１つ増やして更新し、その更新された保留呼数が予め決定された閾値よりも大きい場合に、前記閉塞フラグを設定する閉塞フラグ設定ステップと、
前記呼状態生成ステップにおける呼状態の生成後に呼接続状態に移行した場合には、前記一のＡＰＩ利用者に対して前記呼制御ＡＰＩを提供するＡＰＩ提供ステップと、
を有したことを特徴とするＡＰＩ提供方法。
【請求項５】
コンピュータを、
一のＡＰＩ利用者からＡＰＩ呼出し要求を受付ける要求受付手段と、
ＡＰＩ利用者ごとの、生成された呼状態及びメディア状態それぞれの状態の状態数と予め決定された最大許容状態数とを含む認可情報から、前記一のＡＰＩ利用者に対応する、前記ＡＰＩ呼出し要求に応じた状態の状態数と最大許容状態数とを参照し、前記状態数が前記最大許容状態数以下である場合に状態を生成する認可制御手段と、
前記認可制御手段において状態が生成された場合に、前記ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを選択し、前記一のＡＰＩ利用者に対して提供するＡＰＩ提供手段と、
して機能させるためのＡＰＩゲートウェイ用プログラム。
【請求項６】
コンピュータを、
一のＡＰＩ利用者からＡＰＩ呼出し要求を受付ける要求受付手段と、
前記一のＡＰＩ利用者に対応する閉塞フラグが設定されていない場合にのみ呼状態の生成を許可する呼状態生成許可手段と、
前記呼状態生成許可手段において呼状態の生成が許可された場合に、呼状態を生成する呼状態生成手段と、
前記呼状態の生成後、呼接続状態に移行することなく呼切断状態へ移行した状態である保留状態になった場合には、前記保留状態の単位時間あたりの保留呼数を１つ増やして更新し、その更新された保留呼数が予め決定された閾値よりも大きい場合に、前記閉塞フラグを設定する閉塞フラグ設定手段と、
前記呼状態生成手段における呼状態の生成後に呼接続状態に移行した場合には、前記一のＡＰＩ利用者に対して呼制御ＡＰＩを提供するＡＰＩ提供手段と、
して機能させるためのＡＰＩゲートウェイ用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信事業者の管理するネットワークに接続された通信端末に対する呼制御やメディア制御を外部のネットワーク側から行うための、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を提供する技術に関する。
【背景技術】
【０００２】
電話等のサービスを提供する通信事業者が管理するネットワーク（以下、通信事業者ネットワークという。）に接続された通信端末やシステムを、インターネット等の外部のネットワーク（以下、情報ネットワークという。）上のアプリケーション側から制御するためのＡＰＩを提供するＡＰＩゲートウェイ装置が利用されている。
【０００３】
このＡＰＩゲートウェイ装置で提供されるＡＰＩの種類には様々なものがあり、例えば、呼制御ＡＰＩやメディア制御ＡＰＩのように、そのＡＰＩの提供に際してＡＰＩゲートウェイ装置上で状態を管理する必要のあるものがある。ここで、呼制御とは、電話等のセッションの確立、切断、繋ぎ変え等の制御のことである。また、メディア制御とは、電話におけるガイダンス音声の再生、ＤＴＭＦ（Ｄｕａｌ  Ｔｏｎｅ  Ｍｕｌｔｉ  Ｆｒｅｑｕｅｎｃｙ）信号の検出、音声合成メッセージの再生、入力音声の認識等の、音声や映像等のメディアに関する制御のことである。
【０００４】
呼制御ＡＰＩとしては、Ｐａｒｌａｙ  Ｘ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ（以下、Ｐａｒｌａｙ  Ｘと略記する。）のＴｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌが知られている（例えば、非特許文献１参照）。このＴｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌは、アプリケーションからＷｅｂサービス形式のＡＰＩ呼び出しを受けて呼制御を行うための標準ＡＰＩである。
【０００５】
また、メディア制御ＡＰＩとしては、Ｐａｒｌａｙ  ＸのＡｕｄｉｏ  Ｃａｌｌが知られている（例えば、非特許文献２参照）。このＡｕｄｉｏ  Ｃａｌｌは、Ｔｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌ等のＰａｒｌａｙ  Ｘの呼制御ＡＰＩと組み合わせてメディア制御を行うためのＡＰＩである。Ａｕｄｉｏ  Ｃａｌｌは、例えば、Ｔｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌ等で生成された呼状態中のセッション参加者に対して、ガイダンス音声の再生等のメディア制御を行うためのＡＰＩを提供している。
【０００６】
従来の、呼制御ＡＰＩ及びメディア制御ＡＰＩを提供するＡＰＩゲートウェイ装置は、アプリケーションからのＡＰＩ要求を受付けてＡＰＩを提供する機能であるＡＰＩ提供機能を備えている。このＡＰＩ提供機能は、要求されたＡＰＩの種類に応じて呼制御やメディア制御を行い、アプリケーションからのＡＰＩ呼出しや通信端末からの着信・切断、時間の変化等の契機（トリガ）によって呼状態やメディア状態の生成及び解放を行う。
【０００７】
このようなＡＰＩゲートウェイ装置を用いた場合のＡＰＩの提供に際しては、悪意のある利用者からのアクセスを適切に監視して防止する必要があるが、その監視及び防止の方法として、利用者の認可制御が重要である。
【０００８】
従来のＡＰＩゲートウェイ装置を用いた場合の利用者単位の認可制御は、ＯＭＡ（Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ）においてＰｏｌｉｃｙ  Ｅｎｆｏｒｃｅｒの一つとして定義されたＰＥＥＭ（Ｐｏｌｉｃｙ  Ｅｖａｌｕａｔｉｏｎ，  Ｅｎｆｏｒｃｅｍｅｎｔ  ａｎｄ  Ｍａｎａｇｅｍｅｎｔ）に代表されるポリシに基づいて、ポリシ制御装置が行っている（例えば、非特許文献３参照）。
【０００９】
また、悪意のある利用者からのアクセスとして、悪意呼と呼ばれる通信事業者ネットワークの擾乱を目的とした発呼がされる場合がある。従来、このような悪意呼に対しては、発呼の監視機能と、悪意呼の発信元と判断した場合にその発信元からの発信を規制する閉塞機能とを備えたネットワーク監視装置を通信事業者ネットワークに接続して対応している。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】Ｐａｒｌａｙ  Ｇｒｏｕｐ，“Ｏｐｅｎ  Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  （ＯＳＡ）；Ｐａｒｌａｙ  Ｘ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ；Ｐａｒｔ  ２：Ｔｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌ  （Ｐａｒｌａｙ  Ｘ  ３）”，ＥＴＳＩ  ＥＳ  ２０２  ５０４−２  ｖ０．０．５  Ｊｕｎ．２００７．
【非特許文献２】Ｐａｒｌａｙ  Ｇｒｏｕｐ，“Ｏｐｅｎ  Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  （ＯＳＡ）；Ｐａｒｌａｙ  Ｘ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ；Ｐａｒｔ  １１：Ａｕｄｉｏ  Ｃａｌｌ  （Ｐａｒｌａｙ  Ｘ  ３）”，ＥＴＳＩ  ＥＳ  ２０２  ５０４−１１  ｖ０．０．３  Ｊｕｎ．２００７．
【非特許文献３】Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ，“Ｐｏｌｉｃｙ  Ｅｖａｌｕａｔｉｏｎ，  Ｅｎｆｏｒｃｅｍｅｎｔ  ａｎｄ  Ｍａｎａｇｅｍｅｎｔ  Ａｒｃｈｉｔｅｃｔｕｒｅ”，ＯＭＡ−ＡＤ−Ｐｏｌｉｃｙ＿Ｅｖａｌｕａｔｉｏｎ＿Ｅｎｆｏｒｃｅｍｅｎｔ＿Ｍａｎａｇｅｍｅｎｔ−Ｖ１＿０−２００８０８０５−Ｃ，Ａｕｇ．２００８．
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記のポリシ制御装置で管理できる機能は、ポリシに記述可能な範囲内で、且つＡＰＩゲートウェイ装置で管理した場合と、ポリシ制御装置で管理した場合との間に処理時間の差が殆ど無いか、又はポリシ制御装置で管理した方が効率のよい場合に限定される。例えば、あるＡＰＩ利用者が１秒間に呼び出し可能なＡＰＩの数をポリシに記述した場合に、ＡＰＩゲートウェイ装置において呼出されたＡＰＩの数を数えた場合も、途中で通過するポリシ制御装置において数えた場合も、性能的にはいずれも同じである。また例えば、複数のＡＰＩゲートウェイ装置に対するＡＰＩ呼出し数を合算して数えたい場合もあり、そのような場合には、ポリシ制御装置でＡＰＩ呼出し数を数えた方が効率がよい。
【００１２】
一方、ポリシ制御装置では管理の困難な機能もある。例えば、呼状態数を制限する機能である。ＡＰＩゲートウェイ装置における呼状態の生成契機には２種類あり、一方は呼制御ＡＰＩによる生成であり、他方は電話機等の通信端末からの発呼による生成である。また、呼状態の解放契機についても、呼制御ＡＰＩの呼切断命令による解放と、通信端末からの切断要求（電話機の受話器を置くなど）、さらにＡＰＩゲートウェイ装置で何らかの故障が発生した場合の切断等、幾つかの解放契機がある。
【００１３】
一般的に、ポリシ制御装置は、アプリケーションからのＡＰＩ要求の通信が行われる情報ネットワーク上にあるため、呼状態の生成契機及び解放契機が情報ネットワーク側を除く部分で発生する場合には、ポリシ制御装置はこれを検知することができない。通信事業者ネットワーク側の要求の通信についてポリシ制御装置を経由させる方法が考えられるが、この方法によってもなお、実際にＡＰＩゲートウェイ装置で状態の生成が行われたか否かについては検知することができない。
【００１４】
したがって、ＡＰＩゲートウェイ装置で各種状態を管理してその状態数に制限を加えるような認可制御については、ポリシ制御装置での管理は難しく、ＡＰＩゲートウェイ装置で実行する必要がある。
【００１５】
また、従来、通信事業者ネットワークに接続されたネットワーク監視装置で監視及び規制していた悪意呼については、ＡＰＩゲートウェイ装置に対しては、情報ネットワーク側からも呼制御ＡＰＩの発呼命令の呼び出しによって通信事業者ネットワークに対する擾乱を行うことができるという問題がある。単に呼制御ＡＰＩの発呼命令の大量の呼び出しであれば、発呼命令要求の送信経路上のポリシ制御装置によって要求数に制限を加えて対処することができるが、発信と着信前の呼切断を行う短時間保留呼の繰り返しによるＡＰＩゲートウェイ装置及び通信事業者ネットワークに対する擾乱については、これを制限する手段がない。
【００１６】
さらに、認可制御機能による状態数制限によって呼状態数に制限を加える場合であっても、発呼と切断を常にセットで行う悪意呼については呼状態数が最大数に達することなく呼状態の生成・解放が繰り返される可能性があり、悪意呼対策にはならない。
【００１７】
そこで、本発明は上記問題に鑑みてなされたものであり、ＡＰＩ利用者からのアクセスを適切に監視し規制するために、ＡＰＩ利用者ごとに状態を管理して制限を加える認可制御を容易に実現することのできるＡＰＩゲートウェイ装置、ＡＰＩ提供方法、及びＡＰＩゲートウェイ用プログラムを提供することを目的とする。
【００１８】
また、ＡＰＩ利用者からのアクセスを適切に監視し規制するために、情報ネットワークからの呼制御ＡＰＩの発呼命令による呼を適切に監視して規制することのできるＡＰＩゲートウェイ装置、ＡＰＩ提供方法、及びＡＰＩゲートウェイ用プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明は、上記の課題を解決するために、以下［１］−［６］の手段を提供するものである。
［１］  ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを提供するＡＰＩゲートウェイ装置において、
ＡＰＩ利用者ごとに、生成された呼状態及びメディア状態それぞれの状態の状態数と予め決定された最大許容状態数とを含む認可情報を記憶する認可情報記憶手段と、
一のＡＰＩ利用者から前記ＡＰＩ呼出し要求を受けたとき、前記記憶された認可情報から、前記一のＡＰＩ利用者に対応する、前記ＡＰＩ呼出し要求に応じた状態の状態数と最大許容状態数とを参照し、前記状態数が前記最大許容状態数以下である場合に状態を生成する認可制御手段と、
を備えたことを特徴とするＡＰＩゲートウェイ装置。
［２］  ＡＰＩ呼出し要求に応じて呼制御ＡＰＩを提供するＡＰＩゲートウェイ装置において、
ＡＰＩ利用者ごとに、呼状態の生成後、呼接続状態に移行することなく呼切断状態へ移行した状態である保留状態の単位時間あたりの保留呼数を記憶する保留呼数記憶手段と、
一のＡＰＩ利用者からＡＰＩ呼出し要求を受けて前記保留状態になった場合に、前記記憶された保留呼数を１つ増やして更新記憶し、その更新記憶された保留呼数が予め決定された閾値よりも大きい場合に、前記一のＡＰＩ利用者に対応する閉塞フラグを設定する閉塞フラグ設定手段と、
一のＡＰＩ利用者からのＡＰＩ呼出し要求に応じた呼状態の生成に際し、前記一のＡＰＩ利用者に対応する前記閉塞フラグが設定されていない場合にのみ呼状態の生成を許可する悪意呼閉塞処理手段と、
を備えたことを特徴とするＡＰＩゲートウェイ装置。
［３］  ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを提供するＡＰＩ提供方法において、
一のＡＰＩ利用者から前記ＡＰＩ呼出し要求を受付ける要求受付ステップと、
ＡＰＩ利用者ごとの、生成された呼状態及びメディア状態それぞれの状態の状態数と予め決定された最大許容状態数とを含む認可情報から、前記一のＡＰＩ利用者に対応する、前記ＡＰＩ呼出し要求に応じた状態の状態数と最大許容状態数とを参照し、前記状態数が前記最大許容状態数以下である場合に状態を生成する認可制御ステップと、
を有したことを特徴とするＡＰＩ提供方法。
［４］  ＡＰＩ呼出し要求に応じて呼制御ＡＰＩを提供するＡＰＩ提供方法において、
一のＡＰＩ利用者から前記ＡＰＩ呼出し要求を受付ける要求受付ステップと、
前記一のＡＰＩ利用者に対応する閉塞フラグが設定されていない場合にのみ呼状態の生成を許可する呼状態生成許可ステップと、
前記呼状態生成許可ステップにおいて呼状態の生成が許可された場合に、呼状態を生成する呼状態生成ステップと、
前記呼状態の生成後、呼接続状態に移行することなく呼切断状態へ移行した状態である保留状態になった場合には、前記保留状態の単位時間あたりの保留呼数を１つ増やして更新し、その更新された保留呼数が予め決定された閾値よりも大きい場合に、前記閉塞フラグを設定する閉塞フラグ設定ステップと、
前記呼状態生成ステップにおける呼状態の生成後に呼接続状態に移行した場合には、前記一のＡＰＩ利用者に対して前記呼制御ＡＰＩを提供するＡＰＩ提供ステップと、
を有したことを特徴とするＡＰＩ提供方法。
［５］  コンピュータを、
一のＡＰＩ利用者からＡＰＩ呼出し要求を受付ける要求受付手段と、
ＡＰＩ利用者ごとの、生成された呼状態及びメディア状態それぞれの状態の状態数と予め決定された最大許容状態数とを含む認可情報から、前記一のＡＰＩ利用者に対応する、前記ＡＰＩ呼出し要求に応じた状態の状態数と最大許容状態数とを参照し、前記状態数が前記最大許容状態数以下である場合に状態を生成する認可制御手段と、
前記認可制御手段において状態が生成された場合に、前記ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを選択し、前記一のＡＰＩ利用者に対して提供するＡＰＩ提供手段と、
して機能させるためのＡＰＩゲートウェイ用プログラム。
［６］  コンピュータを、
一のＡＰＩ利用者からＡＰＩ呼出し要求を受付ける要求受付手段と、
前記一のＡＰＩ利用者に対応する閉塞フラグが設定されていない場合にのみ呼状態の生成を許可する呼状態生成許可手段と、
前記呼状態生成許可手段において呼状態の生成が許可された場合に、呼状態を生成する呼状態生成手段と、
前記呼状態の生成後、呼接続状態に移行することなく呼切断状態へ移行した状態である保留状態になった場合には、前記保留状態の単位時間あたりの保留呼数を１つ増やして更新し、その更新された保留呼数が予め決定された閾値よりも大きい場合に、前記閉塞フラグを設定する閉塞フラグ設定手段と、
前記呼状態生成手段における呼状態の生成後に呼接続状態に移行した場合には、前記一のＡＰＩ利用者に対して呼制御ＡＰＩを提供するＡＰＩ提供手段と、
して機能させるためのＡＰＩゲートウェイ用プログラム。
【発明の効果】
【００２０】
本発明によれば、ＡＰＩ利用者ごとに状態を管理して制限を加える認可制御を容易に実現することができる。また、呼制御ＡＰＩの発呼命令による呼を適切に監視して、例えば悪意呼を規制することができる。したがって、ＡＰＩ利用者からのアクセスを適切に監視して規制することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態であるＡＰＩゲートウェイ装置を適用したＡＰＩ提供システムの構成図である。
【図２】本実施形態であるＡＰＩゲートウェイ装置の概略の機能ブロック図である。
【図３】本実施形態であるＡＰＩゲートウェイ装置における、新規に状態を生成する契機が発生したときの処理を説明するためのフローチャートである。
【図４】本実施形態であるＡＰＩゲートウェイ装置において、新規に呼制御ＡＰＩにおける呼状態を生成する発呼命令が呼び出されたときの処理を説明するためのフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明を実施するための形態について、図面を参照して詳細に説明する。図１に、本発明の実施形態であるＡＰＩゲートウェイ装置を適用したＡＰＩ提供システムの構成図を示す。同図において、ＡＰＩ提供システム１は、ＡＰＩの要求側である情報ネットワーク３０を介してそれぞれ接続されたアプリケーション端末１０−１〜１０−３と、ポリシ制御装置２０と、ＡＰＩゲートウェイ装置４０と、ＡＰＩの提供側である通信事業者ネットワーク６０を介してそれぞれ接続された通信端末５０−１〜５０−３とを含んで構成されている。
【００２３】
ＡＰＩ提供システム１において、情報ネットワーク３０は、インターネット等のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークである。また、通信事業者ネットワーク６０は電話等のサービスを提供する通信事業者の管理するネットワークであり、例えばＮＧＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）やＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍｓ）等のＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）によって呼接続を行うことのできるネットワークである。
【００２４】
ＡＰＩゲートウェイ装置４０によって実行される認可制御を除く認可制御は、アプリケーション端末１０−１〜１０−３とＡＰＩゲートウェイ装置４０との間に設けられたポリシ制御装置２０によって実行される。ポリシ制御装置２０は、従来のポリシ制御装置を用いることができる。
【００２５】
ＡＰＩゲートウェイ装置４０は、情報ネットワーク３０と通信事業者ネットワーク６０との間に設けられ、アプリケーション端末１０−１〜１０−３からのＡＰＩ呼出し要求を受け取ると通信端末５０−１〜５０−３に対する制御を行い、通信端末５０−１〜５０−３からの呼制御要求を受け取るとアプリケーション端末１０−１〜１０−３に対してその呼制御要求を受付けた結果の変化等を通知する。
【００２６】
具体的には、ＡＰＩゲートウェイ装置４０は、Ｐａｒｌａｙ  Ｘの呼制御ＡＰＩやメディア制御ＡＰＩに代表される、ネットワーク制御系のＷｅｂサービス形式のＡＰＩを提供するものである。Ｐａｒｌａｙ  Ｘの呼制御系ＡＰＩを提供するＴｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌパートでは、アプリケーション端末１０からの発呼命令を受けたＡＰＩゲートウェイ装置４０が、通信事業者ネットワーク６０に対して要求された命令により指示される通信端末５０に対し、通信事業者ネットワーク６０における呼制御用プロトコルによって発呼を行う。例えば、通信事業者ネットワーク６０がＳＩＰネットワークの場合は、ＳＩＰのＩＮＶＩＴＥ要求を発行する。
【００２７】
同様に、通信ネットワーク側からの要求をアプリケーションに通知するＡＰＩを提供するＰａｒｌａｙ  ＸのＣａｌｌ  Ｎｏｔｉｆｉｃａｔｉｏｎパート（Ｐａｒｌａｙ  Ｇｒｏｕｐ，“Ｏｐｅｎ  Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ（ＯＳＡ）；Ｐａｒｌａｙ  Ｘ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ；Ｐａｒｔ  ３：Ｃａｌｌ  Ｎｏｔｉｆｉｃａｔｉｏｎ  （Ｐａｒｌａｙ  Ｘ  ３）”，ＥＴＳＩ  ＥＳ  ２０２  ５０４−３  ｖ０．０．３，Ｊｕｎ．２００７．）では、通信端末５０からの発呼要求（例えば、ＳＩＰにおけるＩＮＶＩＴＥ要求）を受け取ったＡＰＩゲートウェイ装置４０が、アプリケーション端末１０に対してＷｅｂサービス形式の要求を送ることにより通知する。
【００２８】
Ｐａｒｌａｙ  Ｘのメディア制御系ＡＰＩを提供するＡｕｄｉｏ  Ｃａｌｌパートでは、既存の呼状態を指定してアプリケーション端末１０からＡＰＩゲートウェイ装置４０に対してメディア制御命令を呼び出すことにより、通信事業者ネットワーク６０におけるメディア送信用プロトコル（例えば、通信事業者ネットワーク６０がＳＩＰネットワークである場合はＲＴＰ（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ））を用いて通信端末５０に対してガイダンス音声の再生等の各種メディア制御を行う。
【００２９】
また、ＡＰＩゲートウェイ装置４０は、通信端末５０からの各種メディア入力（例えば、ＤＴＭＦ信号や音声入力等）を受信し、アプリケーション端末１０に対してＷｅｂサービス形式の要求を送ることで通知する機能をも備える。
【００３０】
本実施形態における呼状態とは、呼の継続に必要な各種情報（すなわち、どの通信端末とどの通信端末とを接続した呼であるのか、又は呼は現在どのような段階にあるのか等の情報）を保持するものであり、Ｐａｒｌａｙ  ＸにおけるＣａｌｌ  Ｓｅｓｓｉｏｎに相当する。また、メディア状態とは、メディア制御の開始時に生成され、現在その制御がどのような段階にあるのかといった情報を保持するものである。Ｐａｒｌａｙ  Ｘにおけるメディア状態としては、メディア再生の情報を保持するＭｅｄｉａ  Ｍｅｓｓａｇｅと、メディアの再生と通信端末からの各種メディア入力（ＤＴＭＦ信号、音声入力等）の受け付けを行うＭｅｄｉａ  Ｉｎｔｅｒａｃｔｉｏｎとがある。
【００３１】
図２に、ＡＰＩゲートウェイ装置４０の概略の機能ブロック図を示す。同図において、ＡＰＩゲートウェイ装置４０は、ＡＰＩ提供処理部４１０と、ＡＰＩ状態管理部４２０と、認可制御部４３０と、認可情報管理部４４０と、悪意呼閉塞処理部４５０と、短時間保留呼数管理部４６０とを備えている。ＡＰＩ提供処理部４１０は、要求されたＡＰＩの種類に応じて呼制御やメディア制御を行い、ＡＰＩ呼び出しや通信端末５０−１〜５０−３からの着信・切断、時間の変化等の契機によって、ＡＰＩ状態管理部４２０の呼状態４２１やメディア状態４２２の生成・解放を行う。
【００３２】
認可情報管理部４４０は、ＡＰＩ利用者単位で、ＡＰＩゲートウェイ装置４０の対象である状態ごとに、状態数４４１と最大許容状態数（最大状態数）４４２との組を保持する。本実施形態においては、ＡＰＩ利用者一人につき、呼状態４２１についての状態数４４１と最大状態数４４２との組、及びメディア状態４２２についての状態数４４１と最大状態数４４２との組を保持する。
【００３３】
ここで、本実施形態におけるＡＰＩ利用者について定義する。ＡＰＩ利用者とは、例えば契約によって一意に識別可能なＩＤの払い出しを受け、そのＩＤによって認証装置から認証された場合に、ＡＰＩゲートウェイ装置４０から提供されるＡＰＩを取得することのできる主体である。ＡＰＩ利用者の識別によるＡＰＩゲートウェイ装置４０の動作の違いの例として、ＡＰＩゲートウェイ装置４０に、あるＡＰＩ利用者が生成した状態への操作はその同一のＡＰＩ利用者にしか行わせないといった制限を加える場合がある。これは、一方のＡＰＩ利用者のアプリケーションにより生成された状態に対して、他方のＡＰＩ利用者のアプリケーションからの制御を許容する場合、一方のＡＰＩ利用者の想定しなかったアプリケーションの挙動が現れるおそれがあるためである。
【００３４】
また、このＡＰＩ利用者という単位は認可制御の単位としても用いられる。例えば、あるアプリケーションプロバイダが、ＡＰＩゲートウェイ装置４０について、音声・映像処理命令について利用を認可されていたものが、音声のみを扱うアプリケーションを新規に作成する際に、音声処理命令のみの利用を認可された新しいＩＤを音声・映像処理命令の両方を認可されたものよりも安価に取得するといった例に適用できる。
【００３５】
短時間保留呼数管理部４６０は、接続状態に移行する前に切断された呼状態の単位時間あたりの数を、短時間保留呼数（保留呼数）４６１−１〜４６１−ＮとしてＡＰＩ利用者単位で保持する。このうち短時間保留呼数４６１−ｉ（ｉ≦Ｎ）が閾値４６３を超えた場合に、該当するＡＰＩ利用者（ｉ）に閉塞フラグ４６２−ｉを設定し、以後この閉塞フラグ４６２−ｉの設定されたＡＰＩ利用者（ｉ）からの状態生成要求を悪意呼閉塞処理部４５０が遮断する。
【００３６】
認可情報管理部４４０において、ＡＰＩ利用者単位で最大状態数４４２を保持することの理由は、同一のＡＰＩゲートウェイ装置４０に収容されるＡＰＩ利用者であっても、契約形態によっては利用可能な状態数の最大値に相違のある場合があるためである。また、状態ごとに状態数４４１と最大状態数４４２を定めているのも、例えば、メディア制御ＡＰＩを全く用いることなく呼制御ＡＰＩを多数用いたいというＡＰＩ利用者がいる場合に、呼状態の最大状態数を多く確保し、メディア状態の最大状態数を少なく確保するといった契約形態があり得るためである。
【００３７】
また、短時間保留呼数管理部４６０において、閾値４６３をＡＰＩゲートウェイ装置４０単位で設定するものとし、ＡＰＩ利用者単位では設定しないとしているのは、「ＡＰＩゲートウェイ装置４０及び通信事業者ネットワーク６０の擾乱」であると判断される閾値はＡＰＩ利用者の契約に依存しないと考えられるためである。
【００３８】
次に、本実施形態であるＡＰＩゲートウェイ装置における、新規に状態を生成する契機が発生したときの処理についてのフローチャートを図３に示し動作を説明する。状態生成契機が発生すると、認可情報管理部４４０は、状態数４４１−１〜４４１−Ｍと最大状態数４４２−１〜４４２−Ｍの中から該当するＡＰＩユーザ利用者（ｊ）の状態数４４１−ｊ（ｊ≦Ｍ）と最大状態数４４２−ｊとを参照して値を比較する（Ｓ３１）。
【００３９】
状態数４４１−ｊが最大状態数４４２−ｊを超えている場合（Ｓ３１  ＹＥＳ）は、認可情報管理部４４０は状態の生成処理を中止する（Ｓ３２）。次に、認可制御部４３０は、状態生成契機を発生させた要求元に対してエラー応答を送信することにより、状態数４４１−ｊが最大状態数４４２−ｊを超えたために状態生成を中止した旨を通知する（Ｓ３３）。
【００４０】
一方、ステップＳ３１の比較処理において、状態数４４１−ｊが最大状態数４４２−ｊ以下である場合は（Ｓ３１  ＮＯ）は、認可情報管理部４４０は状態数４４１−ｊを１増やし（Ｓ３４）、状態生成処理を行う（Ｓ３５）。
【００４１】
次に、本実施形態であるＡＰＩゲートウェイ装置における、新規に呼制御ＡＰＩにおける呼状態を生成する発呼命令が呼び出されたときの処理についてのフローチャートを図４に示し動作を説明する。ＡＰＩ利用者（ｋ）からＡＰＩゲートウェイ装置４０の呼状態生成命令が呼び出されると、短時間保留呼数管理部４６０は、呼状態生成命令を呼び出したＡＰＩ利用者について閉塞フラグ４６２−ｋ（ｋ≦Ｎ）の状態を確認する（Ｓ４１）。
【００４２】
閉塞フラグ４６２−ｋが設定されていない状態の場合（Ｓ４１  ＯＦＦ）は、ＡＰＩゲートウェイ装置４０は呼状態を生成する（Ｓ４２）。一方、閉塞フラグ４６２−ｋが設定されている状態の場合（Ｓ４１  ＯＮ）は、悪意呼閉塞処理部４５０は、当該ＡＰＩ利用者（ｋ）は悪意呼によるＡＰＩゲートウェイ装置４０及び通信事業者ネットワーク６０に対する擾乱を行った者であると判断し、この新規の呼状態生成要求については処理を中止してエラー応答を送信する（Ｓ４３）。
【００４３】
ステップＳ４２の処理において呼状態を生成して発呼を行った後、着信側で受話器を取る等の応答があった後に、通話が確立する前段階で中断処理（ＡＰＩによる発呼の停止や着信側の通信端末による着信拒否等）が行われた場合（Ｓ４４  ＹＥＳ）、ＡＰＩゲートウェイ装置４０は、該当する呼状態を切断状態に移行させる（Ｓ４５）。一方、ステップＳ４４の処理において中断処理が行われなかった場合（Ｓ４４  ＮＯ）は、呼の接続処理を行って呼を確立させる（Ｓ４６）。ここで、ステップＳ４２の処理とステップＳ４４の処理との間では、実際には図３に示した呼状態の状態数に基づく認可制御処理が実行されることになる。
【００４４】
ステップＳ４５の処理において該当する呼状態を切断状態に以降させた後、短時間保留呼数管理部４６０は、呼状態生成命令を呼び出したＡＰＩ利用者（ｋ）の短時間保留呼数４６１−ｋを１増やす（Ｓ４７）。次に、悪意呼閉塞処理部４５０は、増加した短時間保留呼数４６１−ｋが短時間保留呼数管理部４６０に設定された閾値４６３を超過したか否かを判定する（Ｓ４８）。
【００４５】
超過したと判定された場合（Ｓ４８  ＹＥＳ）は、悪意呼閉塞処理部４５０は、当該ＡＰＩ利用者は悪意呼によるＡＰＩゲートウェイ装置４０及び通信事業者ネットワーク６０に対する擾乱を行った者と判断し、該当するＡＰＩ利用者（ｋ）に閉塞フラグ４６３を設定（ＯＮにする）する（Ｓ４９）。これによって、後に当該ＡＰＩ利用者（ｋ）から要求された呼状態の生成命令はステップＳ４１の処理において遮断されることとなる。
【００４６】
一方、ステップＳ４８の処理において超過していないと判定された場合（Ｓ４８  ＮＯ）は、この段階では当該ＡＰＩ利用者（ｋ）はＡＰＩゲートウェイ装置４０及び通信事業者ネットワーク６０に対する擾乱を行っていないと判断して処理を終了する。
【００４７】
以上の説明により、本実施形態であるＡＰＩゲートウェイ装置によれば、ＡＰＩ利用者ごとに呼状態及びメディア状態を管理して制限を加える認可制御を容易に実現することができる。また、インターネット等の情報ネットワーク側からの呼制御ＡＰＩの発呼命令による悪意呼を適切に監視して規制することができる。したがって、本実施形態であるＡＰＩゲートウェイ装置を用いることによって、ＡＰＩ利用者からのアクセスを適切に監視し規制することができる。
【００４８】
なお、上述した実施形態であるＡＰＩゲートウェイ装置の少なくとも一部の処理機能をコンピュータで実現するようにしてもよい。この場合、その処理機能を実現するためのＡＰＩゲートウェイ用プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたＡＰＩゲートウェイ用プログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や周辺機器のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、光ディスク、メモリカード等の可搬型記録媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持するものを含んでもよい。また上記のプログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせにより実現するものであってもよい。
【００４９】
以上、本発明の実施形態について図面を参照して詳述したが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【００５０】
１  ＡＰＩ提供システム
１０−１〜１０−３  アプリケーション端末
２０  ポリシ制御装置
３０  情報ネットワーク
４０  ＡＰＩゲートウェイ装置
５０−１〜５０−３  通信端末
６０  通信事業者ネットワーク
４１０  ＡＰＩ提供処理部
４２０  ＡＰＩ状態管理部
４２１−１〜４２１−Ｌ  呼状態
４２２−１〜４２２−Ｌ  メディア状態
４３０  認可制御部
４４０  認可情報管理部
４４１−１〜４４１−Ｍ  状態数
４４２−１〜４４２−Ｍ  最大許容状態数
４５０  悪意呼閉塞処理部
４６０  短時間保留呼数管理部
４６１−１〜４６１−Ｎ  短時間保留呼数
４６２−１〜４６２−Ｎ  閉塞フラグ
４６３  閾値
【図１】
2010288021.tif 000003
【図２】
2010288021.tif 000004
【図３】
2010288021.tif 000005
【図４】
2010288021.tif 000006