JP5212383B2 - Ｉｐ電話機、付加サービス制御プログラム - Google Patents

Description

この発明は、ユーザからサービス実行の要求を受け付け、ベンダー毎に異なる付加サービスを実行するＩＰ電話機、付加サービス制御プログラムに関する。

近年、ＷＬＡＮと３Ｇなどの複数の通信ベアラを持つデュアル型携帯電話の普及や、固定電話と移動電話の融合を狙いとしたＦＭＣサービスの浸透により、企業網と公衆網など、１人のユーザが複数のＩＰ電話サービスを使用するケースが今後増加すると考えられる（特許文献１参照）。このような場合には、１台の電話端末で複数のＩＰ電話サービスに接続する複数ベンダー対応ＩＰ電話端末が必要になる。

例えば、ＩＰ電話の呼制御プロトコルとしてはＳＩＰを用いるのが主流となっており、端末登録や通話、保留、転送などの基本的なサービスのシーケンスは標準化によりほぼ同様の実装となっている。しかし、実装される付加サービス（例えば、パーク保留やピックアップ、着信転送の設定や解除、通話予約、会議通話など）に関しては、標準化がなされておらず、ベンダー固有の実装がなされている。

そのため、各ベンダーの付加サービスすべてに対応するＳＩＰスタックの開発が困難となり、１台の電話端末で複数ベンダーのＩＰ電話サービスを利用するためには、各ベンダーに特化したＳＩＰスタックを個別に開発し端末に搭載するというアプローチがとられている。

特開２００４−３２８１９５号公報

ところで、上記の従来技術では、各ベンダーに特化したＳＩＰスタックを個別に開発し端末に搭載するので、各ベンダーの付加サービスが多種多様なサービスシーケンスを利用した実装となっていることから、呼状態遷移を適切に通知するための判断が、サービスシーケンスにより異なってしまう。

具体的には、ＩＰ電話端末が、基本サービスや付加サービスを実現するに当たって、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）で付加サービス要求などのユーザ操作をＳＩＰスタックへ要求し、さらに、ＳＩＰスタックのＳＩＰシーケンス実行部がさまざまなＳＩＰメッセージを送受信することでサービスシーケンスを実現している。

さらに、そのサービスシーケンスの過程において有意義な状態変化を呼状態遷移通知として上位モジュールであるＵＩに通知し、ＵＩがユーザへ状況通知を行うことで、さまざまな電話サービスを実現している。ここで、各ベンダーの付加サービスが多種多様なサービスシーケンスを利用した実装となっていることから、呼状態遷移を適切に通知するための判断が、サービスシーケンスにより異なってしまう。

例えば、付加サービスとして、パーク保留を実現するためのＳＩＰ実装としては、通話中の呼とは異なる別の制御用のシグナリング（制御呼）を用いて第２呼発信を特別な番号に対して行う方法と、通話中の呼をパーク保留用の特別な番号に転送する方法とがある。

この２種類の実装に対応可能な共通のＳＩＰスタックを開発した場合において、第２呼発信を特別な番号に対して行う方法では、第２呼発信の呼確立通知を受信すると、その通知が「転送」のための通話呼であるか「パーク保留」のための制御呼であるかをＵＩ（もしくはそれを利用するユーザ）が判断しなければならない。一方、パーク保留用の特別な番号に転送する方法では、転送の完了をＵＩに通知するさいに、この転送完了通知がパーク保留に基づく転送完了の通知であるのか、基本サービスとしての転送完了通知であるのかをＵＩ（もしくはそれを利用するユーザ）で判断しなければならない。

このように、適切な呼状態遷移通知の判断基準は付加サービスのシーケンスごとに異なっている結果、個別のＳＩＰスタックとして開発するので、開発工数の増加を引き起こし、複数のベンダーに対応する端末を開発するのは非常に効率が悪くなるという課題があった。

そこで、この発明は、複数ベンダーに対応したＳＩＰスタックの開発効率を向上することを目的とする。

この装置は、ユーザからサービス実行の要求を受け付けるユーザインタフェース部と、当該ユーザインタフェース部から付加サービス実行の要求を受け付け、ベンダー毎に異なる付加サービスを実行するサービス拡張部とを備えるＩＰ電話機であって、サービスを一意に識別するサービス識別子と、当該サービスの実行を要求する要求先とを対応付けて要求先管理記憶部に格納する要求先管理格納手段と、呼を一意に識別する呼識別子と、当該呼の状態遷移を示す呼状態遷移通知の通知先とを対応付けて通知先管理記憶部に格納する通知先管理格納手段と、前記ユーザインタフェース部から付加サービスの要求を受け付け、当該付加サービスのサービス識別子に対応する前記要求先を前記要求先管理記憶部から取得し、当該要求先に前記付加サービスの要求を転送する要求転送手段と、前記呼状態遷移通知を受け付け、当該呼状態遷移通知の呼識別子に対応する前記通知先を前記通知先管理記憶部から取得し、当該通知先に前記呼状態遷移通知を転送する通知転送手段と、を備えることを要件とする。

開示の装置は、付加サービスの実行時には、ＳＩＰスタックで発生する呼状態遷移通知を受けてサービスシーケンスを進め、そのサービスシーケンス状態から上位への適切な呼状態遷移通知を行うように判断し、その判断基準を要求された付加サービスに応じて切り替える。

例えば、上記パーク保留において、第２呼発信を特別な番号に対して行う方法では、パーク保留用の制御呼である第２呼の呼状態遷移通知を上位へ通知せずに、呼接続通知をパーク保留の完了として通知するような判断基準とし、一方、パーク保留用の特別な番号に転送する方法では、転送完了通知をパーク保留完了の通知として上位へ通知するような判断基準とするといった、実装に合わせた判断基準の切り替えが可能となる。

これにより、異なるＳＩＰ実装による付加サービスの実行時も上位への呼状態遷移通知を共通化することが可能となり、ＵＩやＳＩＰスタック全体を別途開発することなく、付加サービスシーケンスの開発のみで複数ベンダーのさまざまな付加サービスへ対応することが可能となり、複数ベンダーに対応したＳＩＰスタックの開発効率を向上することができる。

以下に添付図面を参照して、この発明に係るＩＰ電話機、付加サービス制御プログラムの実施例を詳細に説明する。

以下の実施例では、実施例１に係るＩＰ電話機の構成および処理の流れを順に説明し、最後に実施例１による効果を説明する。

［ＩＰ電話機の構成］
次に、図１を用いて、実施例１に係るＩＰ電話機１０の構成を説明する。図１は、実施例１に係るＩＰ電話機１０の構成を示すブロック図である。同図に示すように、このＩＰ電話機１０は、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）１１、基本ＳＩＰシーケンス実行部１２、シーケンス拡張部１３、サービス拡張部１４を備える。以下にこれらの各部の処理を説明する。

ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）１１は、ユーザの操作により付加サービス要求などを受け付けて、シーケンス拡張部１３へ要求する。また、シーケンス拡張部１３から呼状態変化通知を受け付けて、ユーザへ状況通知を出力する。

基本ＳＩＰシーケンス実行部１２は、基本サービスシーケンスを実行する。具体的には、基本ＳＩＰシーケンス実行部１２は、シーケンスに応じたＳＩＰメッセージを送受信し、シーケンスの過程における状態変化を呼状態遷移通知としてシーケンス拡張部１３に通知する。

シーケンス拡張部１３は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによってサービス要求や呼状態遷移通知を振り分ける処理を実行するが、特に本発明に密接に関連するものとしては、要求先管理テーブル１３ａ、通知先管理テーブル１３ｂ、要求監視転送部１３ｃおよび通知監視転送部１３ｄを備える。

要求先管理テーブル１３ａは、図２に例示すように、サービスＩＤに対して要求先（例えば、関数ポインタなど）を関連付けることで付加サービスの要求先を管理する。また、要求先管理テーブル１３ａは、ＳＩＰスタックの初期化時に、後述するサービス拡張部１４から各サービスＩＤに対する要求先エントリを読み出し、保存して構築される。

通知先管理テーブル１３ｂは、図３に例示するように、呼ＩＤに対してサービス状態および通知先を関連付けることで呼状態遷移の通知先を管理する。また、通知先管理テーブル１３ｂは、図４に示すように、後述する要求監視転送部１３ｃおよび通知監視転送部１３ｄにより更新される。

具体的には、通知先管理テーブル１３ｂは、「呼ＩＤ」について、呼生成要求および呼解放要求に応じて項目が作成され、作成時の通知先が作成要求元により変更される。また、通知先管理テーブル１３ｂは、「サービス状態」について、サービス要求およびサービス完了通知に基づき、対応する呼ＩＤのサービス状態が変更する。また、通知先管理テーブル１３ｂは、「通知先」について、サービス開始通知およびサービス完了通知に基づき、対応する呼ＩＤの通知先が変更される。

要求監視転送部１３ｃは、付加サービス要求を監視し、付加サービスの要求先管理テーブル１３ａを参照して要求を転送する。具体的には、要求監視転送部１３ｃは、ＵＩ１１や基本ＳＩＰシーケンス実行部１２からのサービス要求の要求元を監視し、通知先管理テーブル１３ｂを更新し、要求先管理テーブル１３ａを参照し要求先を決定する。

ここで、図５を用いて、要求監視転送部１３ｃの処理の流れを説明する。同図に示すように、要求監視転送部１３ｃは、要求を受信すると（ステップＳ１０１）、付加サービス要求であるか否かを判定する（ステップＳ１０２）。その結果、要求監視転送部１３ｃは、付加サービス要求である場合には（ステップＳ１０２肯定）、要求先管理テーブル１３ａを参照し、サービスＩＤから要求先を取得し（ステップＳ１０３）、取得した要求先に要求を転送する（ステップＳ１０４）。

また、要求監視転送部１３ｃは、付加サービス要求でない場合には（ステップＳ１０２否定）、呼生成要求であるか否かを判定する（ステップＳ１０５）。その結果、要求監視転送部１３ｃは、呼生成要求であると判定した場合には（ステップＳ１０５肯定）、通知先管理テーブル１３ｂに呼ＩＤを追加して（ステップＳ１０８）、基本ＳＩＰシーケンス実行部１２に要求を転送する（ステップＳ１０９）。

また、要求監視転送部１３ｃは、呼生成要求でないと判定した場合には（ステップＳ１０５否定）、呼解放要求か判定する（ステップＳ１０６）。その結果、要求監視転送部１３ｃは、呼解放要求である場合には（ステップＳ１０６肯定）、通知先管理テーブル１３ｂから呼ＩＤを削除して、基本ＳＩＰシーケンス実行部１２に要求を転送し（ステップＳ１０９）、呼解放要求でない場合には（ステップＳ１０６否定）、通知先管理テーブル１３ｂを変更せずに、基本ＳＩＰシーケンス実行部１２に要求を転送する（ステップＳ１０９）。

通知監視転送部１３ｄは、呼状態遷移の通知を監視し、付加サービス実行時には呼状態遷移の通知先管理テーブル１３ｂを参照して通知先を変更する。具体的には、通知監視転送部１３ｄは、基本ＳＩＰシーケンス実行部１２やサービス拡張部１４からの呼状態遷移通知の通知元、通知内容を監視し、通知先管理テーブル１３ｂを更新し、通知先管理テーブル１３ｂを参照して通知先を決定する。

ここで、図６を用いて、通知監視転送部１３ｄの処理の流れを説明する。同図に示すように、通知監視転送部１３ｄは、呼状態変化通知を受信すると（ステップＳ２０１）、通知元はどこかを判定する（ステップＳ２０２）。その結果、通知監視転送部１３ｄは、通知元が基本ＳＩＰシーケンス実行部１２である場合には、通知先管理テーブル１３ｂを参照して呼ＩＤから通知先を取得し（ステップＳ２０３）、取得した通知先に通知を転送する（ステップＳ２０４）。

また、通知監視転送部１３ｄは、通知元がサービス拡張部１４である場合には、サービス開始要求であるか判定する（ステップＳ２０５）。その結果、通知監視転送部１３ｄは、サービス開始要求である場合には（ステップＳ２０５肯定）、通知先管理テーブル１３ｂの呼ＩＤの通知先をサービス拡張部１４に更新して（ステップＳ２０８）、ＵＩ１１に呼状態変化通知を通知する（ステップＳ２０９）。

また、通知監視転送部１３ｄは、サービス開始要求でない場合には（ステップＳ２０５否定）、サービス完了要求であるか判定する（ステップＳ２０６）。その結果、通知監視転送部１３ｄは、サービス完了要求である場合には（ステップＳ２０６肯定）、通知先管理テーブル１３ｂの呼ＩＤの通知先をサービス拡張部１４に更新して（ステップＳ２０７）、ＵＩ１１に呼状態変化通知を通知する（ステップＳ２０９）。

また、通知監視転送部１３ｄは、サービス完了要求でない場合には（ステップＳ２０６否定）、通知先管理テーブル１３ｂを変更せずに、ＵＩ１１に呼状態変化通知を通知する（ステップＳ２０９）。

図１の説明に戻ると、サービス拡張部１４は、付加サービスシーケンスを実行する。具体的には、サービス拡張部１４は、シーケンス拡張部１３より通知される呼状態遷移通知を受けてＳＩＰサービスシーケンスを実行しつつ、そのＳＩＰサービスシーケンスの状態から判断して適切な呼状態遷移通知のみをシーケンス拡張部１３を通じてＵＩ１１に通知する。なお、このサービス拡張部１４は、対象とする付加サービス実装やベンダーに応じて、構成および処理が異なる。

ここで、図７を用いて、サービス拡張部１４の処理の流れを説明する。同図に示すように、サービス拡張部１４は、シーケンス拡張部１３から要求を受信すると（ステップＳ３０１）、要求を実行し（ステップＳ３０２）、また、シーケンス拡張部１３から通知を受信すると（ステップＳ３０３）、通知内容とシーケンス状態から適切な要求を実行して（ステップＳ３０４）、シーケンス状態を更新する（ステップＳ３０５）。なお、上記ステップＳ３０２およびＳ３０４の要求実行については、実装された付加サービスのベンダー毎に異なる処理となる。

そして、サービス拡張部１４は、サービス開始状態か否か判定し（ステップＳ３０６）、サービス開始状態である場合には（ステップＳ３０６肯定）、サービス開始通知を通知監視転送部１３ｄへ通知する（ステップＳ３０７）。

続いて、サービス拡張部１４は、サービス完了状態であるか判定し（ステップＳ３０８）、サービス完了状態である場合には（ステップＳ３０８肯定）、サービス完了通知を通知監視転送部１３ｄへ通知する（ステップＳ３０９）。

その後、サービス拡張部１４は、ＵＩ１１に通知すべき状態かの判断をし（ステップＳ３１０）、ＵＩ１１に通知すべき状態であると判断した場合には（ステップＳ３１０肯定）、適切な通知内容を生成して通知監視転送部１３ｄへ呼状態変化を通知する（ステップＳ３１１）。なお、上記ステップＳ３１０およびＳ３１１の判断および通知内容生成については、実装された付加サービスのベンダー毎に異なる処理となる。

ここで、図８を用いて、各構成部間の要求および通知の送受信について具体例を用いて説明する。図８の例では、サービス拡張部１４が付加サービスとして、サービス拡張「パーク保留（ＣＡＬＬＰａｒｋ（））」、「ピックアップ（Ｐｉｃｋｕｐ（））」を実装する。また、シーケンス拡張部１３の要求先管理テーブル１３ａは、サービスＩＤ「パーク保留」と要求先「ＣａｌｌＰａｒｋ（）」とを対応付け、サービスＩＤ「ピックアップ」と要求先「Ｐｉｃｋｕｐ（）」とを対応付けて、それぞれ記憶する。

同図に例示すように、シーケンス拡張部１３の要求監視転送部１３ｃは、ＵＩ１１から要求を受信し、付加サービス要求でない場合には、基本ＳＩＰシーケンス実行部１２に要求を転送する。また、要求監視転送部１３ｃは、付加サービス「パーク保留」の要求であった場合には、要求先管理テーブル１３ａを参照し、サービスＩＤ「パーク保留」に対応する要求先「ＣａｌｌＰａｒｋ（）」を取得する。そして、要求監視転送部１３ｃは、取得された要求先であるサービス拡張部１４の「ＣａｌｌＰａｒｋ（）」に要求を転送する。

また、通知監視転送部１３ｄは、基本ＳＩＰシーケンス実行部１２またはサービス拡張部１４から呼状態変化通知を受信する。通知監視転送部１３ｄは、サービス拡張部１４から通知を受信した場合には、通知先管理テーブル１３ｂを更新してＵＩ１１に通知する。

一方、通知監視転送部１３ｄは、基本ＳＩＰシーケンス実行部１２から通知を受信した場合には、通知先管理テーブル１３ｂを参照し、呼ＩＤから通知先を取得し、その通知先に通知を転送する。つまり、図８の例では、通知監視転送部１３ｄは、呼ＩＤ「既存」である場合には、ＵＩ１１に通知し、呼ＩＤ「特番」である場合には、サービス拡張部１４に通知する。

［ＩＰ電話機による処理］
次に、図９〜図１２を用いて、実施例１に係るＩＰ電話機１０による処理を説明する。図９は、実施例１に係るＩＰ電話機による基本発信および相手切断処理の流れを示すシーケンス図であり、図１０および図１１は、実施例１に係るＩＰ電話機による付加サービス（パーク保留）処理の流れを示すシーケンス図であり、図１２は、実施例１に係るＩＰ電話機による付加サービス（ピックアップ）処理の流れを示すシーケンス図である。

図９に示すように、ＩＰ電話機１０の要求監視転送部１３ｃは、ＵＩ１１から呼生成要求を受信すると（ステップＳ４０１）、基本サービス要求であることを判定し、基本ＳＩＰシーケンス実行部１２へ呼生成要求を転送するとともに（ステップＳ４０２）、ＵＩ１１からの呼生成要求に基づき通知先管理テーブル１３ｂに呼ＩＤを追加する（ステップＳ４０３）。

そして、要求監視転送部１３ｃは、ＵＩ１１から発信要求を受信すると（ステップＳ４０４）、基本ＳＩＰシーケンス実行部１２に転送する（ステップＳ４０５）。基本ＳＩＰシーケンス実行部１２は、発信要求を受信すると、ＳＩＰサーバとの間で、呼接続処理（ステップＳ４０６〜Ｓ４０８）を行い、接続が完了した後、呼接続通知を通知監視転送部１３ｄに送信する（ステップＳ４０９）。

また、通知監視転送部１３ｄは、通知先管理テーブル１３ｂを参照して、通知先（図９の例では、通知先「ＵＩ」）を取得し（ステップＳ４１０）、呼接続通知をＵＩ１１に通知する（ステップＳ４１１）。

そして、通話が行われた後、基本ＳＩＰシーケンス実行部１２は、呼切断「ＢＹＥ」がＳＩＰサーバから通知された場合には（ステップＳ４１２）、通知監視転送部１３ｄに呼切断通知を通知する（ステップＳ４１３）。そして、通知監視転送部１３ｄは、通知先管理テーブル１３ｂを参照して、通知先（図９の例では、通知先「ＵＩ」）を取得し（ステップＳ４１４）、呼切断通知をＵＩ１１に通知する（ステップＳ４１５）。

その後、要求監視転送部１３ｃは、ＵＩ１１から呼解放要求を受信すると（ステップＳ４１６）、通知先管理テーブル１３ｂから呼ＩＤを削除して（ステップＳ４１７）、基本ＳＩＰシーケンス実行部１２に呼解放要求を転送する（ステップＳ４１８）。

続いて、実施例１に係るＩＰ電話機がパーク保留を実現するにあたり、第２呼発信による制御呼を利用する例として、図１０および図１１を用いて、付加サービス（パーク保留）処理の流れを説明する。図１０に示すように、ＩＰ電話機１０の要求監視転送部１３ｃは、ＵＩ１１からパーク保留のサービス要求を受信すると（ステップＳ５０１）、サービス要求に基づいて、通知先管理テーブル１３ｂのサービス状態を更新する（ステップＳ５０２）。

そして、要求監視転送部１３ｃは、要求先管理テーブル１３ａを参照して要求先（図１０の例では、「ＣａｌｌＰａｒｋ＿Ａ」）を決定し、サービス拡張部１４の「ＣａｌｌＰａｒｋ＿Ａ」を呼び出す（ステップＳ５０３）。そして、要求監視転送部１３ｃは、特殊番号の呼生成要求をサービス拡張部１４から受信し（ステップＳ５０４）、その呼生成要求を基本ＳＩＰシーケンス実行部１２に転送するとともに（ステップＳ５０５）、特殊番号の呼生成要求に基づき、呼ＩＤ「特番」の項目を追加する（ステップＳ５０６）。

そして、要求監視転送部１３ｃは、特殊番号への第二呼発信要求をサービス拡張部１４から受信し（ステップＳ５０７）、その発信要求を基本ＳＩＰシーケンス実行部１２に転送する（ステップＳ５０８）。その後、基本ＳＩＰシーケンス実行部１２は、第二呼接続処理として、「ＩＮＶＩＴＥ」をＳＩＰサーバに送信する（ステップＳ５０９）。

そして、通知監視転送部１３ｄは、サービス拡張部１４からサービス開始通知を受信すると（ステップＳ５１０）、サービス開始通知を契機に、既存呼の通知先をサービス拡張部１４に変更する（ステップＳ５１１）。その後、通知監視転送部１３ｄは、サービス開始通知をＵＩ１１に転送する（ステップＳ５１２）。これにより、以降の呼状態遷移通知がすべてサービス拡張部１４に通知され、付加サービスシーケンスをサービス拡張部１４で実行可能となる。

また、図１１に示すように、基本ＳＩＰシーケンス実行部１２は、ＩＮＶＩＴＥをＳＩＰサーバに送信した後（図１０のステップＳ５０９）、第二呼接続を行って（ステップＳ５１３、Ｓ５１４）、特殊番号の呼接続通知を通知監視転送部１３ｄに通知する（ステップＳ５１５）。そして、通知監視転送部１３ｄは、通知先管理テーブル１３ｂを参照し（ステップＳ５１６）、対応する通知先に特殊番号の呼接続要求を送信する（ステップＳ５１７）。

そして、通知監視転送部１３ｄは、サービス拡張部１４からサービス完了通知を受信すると（ステップＳ５１８）、既存呼通知先をＵＩに変更し（ステップＳ５１９）、サービス完了通知をＵＩ１１に通知する（ステップＳ５２０）。

続いて、基本ＳＩＰシーケンス実行部１２が特殊番号の呼切断「ＢＹＥ」がＳＩＰサーバから通知されると（ステップＳ５２１）、通知監視転送部１３ｄは、特殊番号の呼切断通知を基本ＳＩＰシーケンス実行部１２から受信し（ステップＳ５２２）、通知先管理テーブル１３ｂを参照して通知先（図１１の例では、「サービス拡張Ａ」）を取得し（ステップＳ５２３）、サービス拡張部１４のサービス拡張Ａに呼切断通知を通知する（ステップＳ５２４）。

続いて、要求監視転送部１３ｃは、サービス拡張部１４から特殊番号の呼解放要求を受信すると（ステップＳ５２５）、呼解放要求に基づき、通知先管理テーブル１３ｂの項目（図１１の例では、呼ＩＤ「特番」の項目）を削除する（ステップＳ５２６）。そして、要求監視転送部１３ｃは、呼解放要求を基本ＳＩＰシーケンス実行部１２に転送する（ステップＳ５２７）。

その後、基本ＳＩＰシーケンス実行部１２は、既存呼の呼切断「ＢＹＥ」がＳＩＰサーバから通知されると（ステップＳ５２８）、既存呼の呼切断通知を通知監視転送部１３ｄに通知する（ステップＳ５２９）。そして、通知監視転送部１３ｄは、既存呼の呼切断通知を受信すると、通知先管理テーブル１３ｂを参照して通知先（図１１の例では、「ＵＩ」）を取得し（ステップＳ５３０）、ＵＩ１１に呼切断通知を転送する（ステップＳ５３１）。

続いて、図１２を用いて、実施例１に係るＩＰ電話機が通話中の呼をパーク保留用の特別な番号に転送する例として、図１２を用いて、付加サービス（ピックアップ）処理の流れを説明する。同図に示すように、要求監視転送部１３ｃは、付加サービスとしてパーク保留の要求をＵＩ１１から受信すると（ステップＳ６０１）、サービス要求に基づいて、通知先管理テーブル１３ｂのサービス状態を更新する（ステップＳ６０２）。

そして、要求監視転送部１３ｃは、要求先管理テーブル１３ａを参照して要求先（図１２の例では、「ＣａｌｌＰａｒｋ＿Ｂ」）を決定し、サービス拡張部１４の「ＣａｌｌＰａｒｋ＿Ｂ」を呼び出す（ステップＳ６０３）。そして、要求監視転送部１３ｃは、転送要求をサービス拡張部１４から受信し（ステップＳ６０４）、その転送要求を基本ＳＩＰシーケンス実行部１２に転送する（ステップＳ６０５）。

そして、基本ＳＩＰシーケンス実行部１２は、通話中の呼をパーク保留用の特別な番号に転送する旨を要求する「ＲＥＦＥＲ」をＳＩＰサーバに送信する（ステップＳ６０６）。また、通知監視転送部１３ｄは、サービス開始通知をサービス拡張部１４から受信すると（ステップＳ６０７）、通知先管理テーブル１３ｂの呼ＩＤ「既存」の通知先を「サービス拡張Ｂ」に変更する（ステップＳ６０８）。

その後、基本ＳＩＰシーケンス実行部１２が転送が完了した旨の「ＮＯＴＩＦＹ」をＳＩＰサーバから受信すると（ステップＳ６０９）、通知監視転送部１３ｄは、サービス開始通知をＵＩ１１に通知する（ステップＳ６１０）。

そして、通知監視転送部１３ｄは、転送完了通知を基本ＳＩＰシーケンス実行部１２から受信すると（ステップＳ６１１）、通知先管理テーブル１３ｂを参照し、呼ＩＤ「既存」から通知先「サービス拡張Ｂ」を取得し（ステップＳ６１２）、サービス拡張部１４に転送完了通知を転送する（ステップＳ６１３）。続いて、通知監視転送部１３ｄは、サービス完了通知をサービス拡張部１４から受信すると（ステップＳ６１４）、既存呼通知先を「ＵＩ」に変更し（ステップＳ６１５）、サービス完了通知をＵＩ１１に転送する（ステップＳ６１６）。

その後、基本ＳＩＰシーケンス実行部１２が既存呼の呼切断「ＢＹＥ」がＳＩＰサーバを受信すると（ステップＳ６１７）、通知監視転送部１３ｄは、呼切断通知を基本ＳＩＰシーケンス実行部１２から受信し（ステップＳ６１８）、通知先管理テーブル１３ｂを参照して、呼ＩＤ「既存」から通知先「ＵＩ」を取得し（ステップＳ６１９）、呼切断通知をＵＩ１１に通知する（ステップＳ６２０）。

[実施例１の効果]
上述してきたように、ＩＰ電話機１０は、異なるＳＩＰ実装による付加サービスの実行時も上位モジュールであるＵＩ１１への呼状態遷移通知を共通化することが可能となり、ＵＩやＳＩＰスタック全体を別途開発することなく、付加サービスシーケンスの開発のみで複数ベンダーのさまざまな付加サービスへ対応することが可能となり、複数ベンダーに対応したＳＩＰスタックの開発効率を向上することが可能である。

また、実施例１によれば、サービス拡張部１４を異なるモジュールで実現することで、端末開発ベンダー以外の開発、たとえばＩＰ電話サービス提供ベンダーによる開発も可能となり、モジュールの追加や置き換えによる新規サービス対応などの機能拡張も容易に実現可能であるといった効果もある。さらに、複数ベンダーに対応する際に、ＳＩＰスタックなどの共通利用可能なモジュールが多くなるため、端末のストレージ領域やメモリ領域の消費を抑えることができ、動作リソースの少ない携帯型ＩＰ電話端末においても有利であるという効果も奏する。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例２として本発明に含まれる他の実施例を説明する。

（１）ベンダーＩＤ
また、本発明は、これに限定されるものではなく、ベンダーを一意に識別するベンダーＩＤとサービス内容を一意に識別するサービスＩＤの組に対するモジュールＩＤを管理するモジュール管理テーブルを備えるようにしてもよい。

具体的には、図１３に示すように、実施例２に係るＩＰ電話機のモジュール管理テーブルは、ベンダーＩＤ、サービスＩＤ、モジュールＩＤをそれぞれ対応付けて記憶する。このモジュール管理テーブルは、ベンダー拡張モジュール導入時に、拡張モジュールが対象とするベンダーＩＤおよびサービスＩＤに関連付けてテーブルを更新される。

そして、ＩＰ電話機は、要求先管理テーブルの更新するために、利用ベンダー決定時に、当該決定された利用ベンダーのベンダーＩＤに対応するサービスＩＤと拡張モジュールＩＤとの組み合わせをモジュール管理テーブルから取得する。その後、ＩＰ電話機は、拡張モジュールＩＤから要求先エントリを取得し、サービスＩＤと要求先の組み合わせとして要求先管理テーブルに保存する。

このように、モジュール拡張部を複数のモジュールで構成し、要求の転送先をベンダーＩＤとサービスＩＤから決定することで、複数ベンダーへの対応を容易にすることが可能である。

（２）排他制御
また、本発明は、サービス状態を参照して付加サービス実行の排他制御を行うようにしてもよい。具体的には、図１４に示すように、実施例２に係るＩＰ電話機の要求監視転送部は、付加サービス要求を受け取った場合に、該当する付加サービスのサービスＩＤに対応するサービス状態を通知先管理テーブルで参照し、サービス要求の可否を判断する。例えば、ＩＰ電話機は、サービス実行中である場合には、受け取ったサービス要求を棄却するように排他制御を行う。

（３）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、要求監視転送部１３ｃと通知監視転送部１３ｄを統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

（４）プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図１５を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１５は、付加サービス制御プログラムを実行するコンピュータを示す図である。

同図に示すように、ＩＰ電話機としてのコンピュータ６００は、ＨＤＤ６１０、ＲＡＭ６２０、ＲＯＭ６３０およびＣＰＵ６４０をバス６５０で接続して構成される。

そして、ＲＯＭ６３０には、上記の実施例と同様の機能を発揮するＩＰ電話機、つまり、図１５に示すように、要求監視転送プログラム６３１および通知監視転送プログラム６３２が予め記憶されている。なお、プログラム６３１〜６３２については、図１に示したＩＰ電話機の各構成要素と同様、適宜統合または分散してもよい。

そして、ＣＰＵ６４０が、これらのプログラム６３１〜６３２をＲＯＭ６３０から読み出して実行することで、図１５に示すように、各プログラム６３１〜６３２は、要求監視転送プロセス６４１および通知監視転送プロセス６４２として機能するようになる。各プロセス６４１〜６４２は、図１に示した要求監視転送部１３ｃ、通知監視転送部１３ｄにそれぞれ対応する。

また、ＨＤＤ６１０には、図１５に示すように、要求先管理テーブル６１１および通知先管理テーブル６１２が設けられる。なお、要求先管理テーブル６１１および通知先管理テーブル６１２は、図１に示した要求先管理テーブル１３ａおよび通知先管理テーブル１３ｂに対応する。そして、ＣＰＵ６４０は、要求先管理テーブル６１１および通知先管理テーブル６１２に対してデータを登録するとともに、要求先管理テーブル６１１および通知先管理テーブル６１２から要求先管理データ６２１および通知先管理データ６２２を読み出してＲＡＭ６２０に格納し、ＲＡＭ６２０に格納された要求先管理データ６２１および通知先管理データ６２２に基づいて情報を管理する処理を実行する。

以上のように、本発明に係るＩＰ電話機、付加サービス制御プログラムは、ユーザからサービス実行の要求を受け付け、ベンダー毎に異なる付加サービスを実行することに有用であり、特に、複数ベンダーに対応したＳＩＰスタックの開発効率を向上する場合に適する。

図１は、実施例１に係るＩＰ電話機の構成を示すブロック図である。 図２は、要求先管理テーブルを説明するための図である。 図３は、通知先管理テーブルを説明するための図である。 図４は、通知先管理テーブルの構築と変更について説明するための図である。 図５は、要求監視転送部の処理の流れを説明するためのフローチャートである。 図６は、通知監視転送部の処理の流れを説明するためのフローチャートである。 図７は、サービス拡張部の処理の流れを説明するためのフローチャートである。 図８は、各構成部間の要求および通知の送受信について具体例を用いて説明するための図である。 図９は、実施例１に係るＩＰ電話機による基本発信および相手切断処理の流れを示すシーケンス図である。 図１０は、実施例１に係るＩＰ電話機による付加サービス（パーク保留）処理の流れを示すシーケンス図である。 図１１は、実施例１に係るＩＰ電話機による付加サービス（パーク保留）処理の流れを示すシーケンス図である。 図１２は、実施例１に係るＩＰ電話機による付加サービス（ピックアップ）処理の流れを示すシーケンス図である。 図１３は、実施例２に係るＩＰ電話機について説明するための図である。 図１４は、実施例２に係るＩＰ電話機について説明するための図である。 図１５は、付加サービス制御プログラムを実行するコンピュータを示す図である。

１０ ＩＰ電話機
１１ ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）
１２ 基本ＳＩＰシーケンス実行部
１３ シーケンス拡張部
１３ａ 要求先管理テーブル
１３ｂ 通知先管理テーブル
１３ｃ 要求監視転送部
１３ｄ 通知監視転送部
１４ サービス拡張部

Claims (10)

1. ユーザからサービス実行の要求を受け付けるユーザインタフェース部と、当該ユーザインタフェース部から付加サービス実行の要求を受け付け、ベンダー毎に異なる付加サービスを実行するサービス拡張部とを備えるＩＰ電話機であって、
   サービスを一意に識別するサービス識別子と、当該サービスの実行を要求する要求先とを対応付けて要求先管理記憶部に格納する要求先管理格納手段と、
   呼を一意に識別する呼識別子と、当該呼で実行するサービスの状態と、当該呼の状態遷移を示す呼状態遷移通知の通知先とを対応付けて通知先管理記憶部に格納する通知先管理格納手段と、
   前記ユーザインタフェース部から付加サービスの要求を受け付け、当該付加サービスのサービス識別子に対応する前記要求先を前記要求先管理記憶部から取得し、当該要求先に前記付加サービスの要求を転送する要求転送手段と、
   前記呼状態遷移通知を受け付け、当該呼状態遷移通知の呼識別子および当該呼で実行するサービスの状態に対応する前記通知先を前記通知先管理記憶部から取得し、当該通知先に前記呼状態遷移通知を転送する通知転送手段と、
   を備えることを特徴とするＩＰ電話機。
2. 前記要求転送手段は、前記ユーザインタフェース部から基本サービスの要求を受け付け、当該要求が呼生成要求である場合には、生成される呼の識別子を前記通知先管理記憶部に追加し、当該要求が呼解放要求である場合には、解放される呼の識別子を前記通知先管理記憶部から削除することを特徴とする請求項１に記載のＩＰ電話機。
3. 前記通知転送手段は、前記呼状態遷移通知を受け付け、当該呼状態遷移通知の通知元が前記サービス拡張部からであって、前記呼状態遷移通知がサービス開始要求通知である場合には、サービスが開始される呼識別子の通知先を前記サービス拡張部となるように前記通知先管理記憶部を更新し、前記呼状態遷移通知の通知元が前記サービス拡張部からであって、前記呼状態遷移通知がサービス完了要求通知である場合には、サービスが完了する呼識別子の通知先を前記ユーザインタフェース部となるように前記通知先管理記憶部を更新することを特徴とする請求項１に記載のＩＰ電話機。
4. ベンダーを一意に識別するベンダー識別子と、当該ベンダーのサービス識別子と、当該サービスを実行するモジュールを一意に識別するモジュール識別子とを対応付けてモジュール管理記憶部に格納するモジュール管理格納手段をさらに備えることを特徴とする請求項１に記載のＩＰ電話機。
5. 前記通知先管理格納手段は、前記呼識別子および前記通知先とともに、サービス実行状態を対応付けて前記通知先管理記憶部に記憶し、
   前記要求転送手段は、前記ユーザインタフェース部からサービスの要求を受け付けた場合に、前記通知先管理記憶部に記憶された前記サービス実行状態を参照し、サービス実行中であれば、受け付けられたサービスの要求を棄却することを特徴とする請求項１に記載のＩＰ電話機。
6. ユーザインタフェース部がユーザからサービス実行の要求を受け付け、サービス拡張部がベンダー毎に異なる付加サービスを実行する付加サービス制御方法をコンピュータに実行させる付加サービス制御プログラムであって、
   サービスを一意に識別するサービス識別子と、当該サービスの実行を要求する要求先とを対応付けて要求先管理記憶部に格納する要求先管理格納手順と、
   呼を一意に識別する呼識別子と、当該呼で実行するサービスの状態と、当該呼の状態遷移を示す呼状態遷移通知の通知先とを対応付けて通知先管理記憶部に格納する通知先管理格納手順と、
   前記ユーザインタフェース部から付加サービスの要求を受け付け、当該付加サービスのサービス識別子に対応する前記要求先を前記要求先管理記憶部から取得し、当該要求先に前記付加サービスの要求を転送する要求転送手順と、
   前記呼状態遷移通知を受け付け、当該呼状態遷移通知の呼識別子および当該呼で実行するサービスの状態に対応する前記通知先を前記通知先管理記憶部から取得し、当該通知先に前記呼状態遷移通知を転送する通知転送手順と、
   をコンピュータに実行させることを特徴とする付加サービス制御プログラム。
7. 前記要求転送手順は、前記ユーザインタフェース部から基本サービスの要求を受け付け、当該要求が呼生成要求である場合には、生成される呼の識別子を前記通知先管理記憶部に追加し、当該要求が呼解放要求である場合には、解放される呼の識別子を前記通知先管理記憶部から削除することを特徴とする請求項６に記載の付加サービス制御プログラム。
8. 前記通知転送手順は、前記呼状態遷移通知を受け付け、当該呼状態遷移通知の通知元が前記サービス拡張部からであって、前記呼状態遷移通知がサービス開始要求通知である場合には、サービスが開始される呼識別子の通知先を前記サービス拡張部となるように前記通知先管理記憶部を更新し、前記呼状態遷移通知の通知元が前記サービス拡張部からであって、前記呼状態遷移通知がサービス完了要求通知である場合には、サービスが完了する呼識別子の通知先を前記ユーザインタフェース部となるように前記通知先管理記憶部を更新することを特徴とする請求項６に記載の付加サービス制御プログラム。
9. ベンダーを一意に識別するベンダー識別子と、当該ベンダーのサービス識別子と、当該サービスを実行するモジュールを一意に識別するモジュール識別子とを対応付けてモジュール管理記憶部に格納するモジュール管理格納手順をさらにコンピュータに実行させることを特徴とする請求項６に記載の付加サービス制御プログラム。
10. 前記通知先管理格納手順は、前記呼識別子および前記通知先とともに、サービス実行状態を対応付けて前記通知先管理記憶部に記憶し、
    前記要求転送手順は、前記ユーザインタフェース部からサービスの要求を受け付けた場合に、前記通知先管理記憶部に記憶された前記サービス実行状態を参照し、サービス実行中であれば、受け付けられたサービスの要求を棄却することを特徴とする請求項６に記載の付加サービス制御プログラム。

Images