(57)【要約】【課題】通信システムにおいて有益なセッション階層管理を行うこと。【解決手段】サーバ３００は、セッション制御部３１０で、セッション管理データ３１２に基づいて、セッションの階層管理を行う。セッション管理データ３１２は、セッション階層管理データとイベント動作管理データとからなる。前者は、セッションＩＤおよびセッションＩＤの親子関係を示し、後者は、セッションＩＤまたはセッションＩＤの親子関係が変化する際にサーバ３００が行う処理動作（イベント処理動作）情報を示す。サーバ３００は、たとえば、通話セッションとカタログ制御セッションの親子設定と、相手の通話端末２００へのアンケート送信の予約とにより、通話セッション終了時に子セッション終了とアンケート送信の処理動作を実行する。【選択図】      図１
2004206459.tif 000002
【特許請求の範囲】
【請求項１】
セッション開設要求を受信する受信手段と、
受信されたセッション開設要求に応じて、指定された装置との間にセッションを開設する開設手段と、
開設された複数のセッション間の階層関係を記憶する記憶手段と、
前記階層関係に変更が生じたときに実行される予約処理を設定する設定手段と、
前記階層関係に変更が生じたとき、設定された予約処理を実行する実行手段と、
を有することを特徴とするセッション管理装置。
【請求項２】
前記階層関係は、各セッションに付与されたセッションＩＤによって規定されていることを特徴とする請求項１記載のセッション管理装置。
【請求項３】
セッション階層操作要求を受信する第２受信手段と、
受信されたセッション階層操作要求に応じて、前記階層関係を変更する変更手段と、をさらに有し、
前記記憶手段は、
変更後の階層関係を記憶する、
ことを特徴とする請求項１記載のセッション管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、セッション管理装置に関する。
【０００２】
【従来の技術】
今日のネットワークの普及と発展に伴い、たとえば、通信端末間でマルチメディア通信セッション条件をネゴシエーションした後、マルチメディア通信セッションを開設して映像通話するテレマーケティングサービスシステムが考案されている。このようなシステムでは、端末間のピアツーピア接続またはサーバ経由による端末間の接続においてリアルタイム通信を行うために、ＳＩＰ（Session Initiation Protocol：セッション開始手順）の使用が検討されている。ＳＩＰは、ＩＰ（Internet Protocol）ネットワーク上でマルチメディアセッションを確立・変更・終了するための、アプリケーション層のシグナリングプロトコルであり、現在、ＲＦＣ３２６１で標準化されている。
【０００３】
たとえば、特許文献１には、コンテンツ提供端末と交換装置サーバとが接続されたネットワークに新たな享受端末を接続し、コンテンツリスト要求およびコンテンツ送信要求を受けてコンテンツ配信処理し、さらに、双方向通信要求を受けて、享受端末からコンテンツ配信端末に対してコンテンツを送信し、双方向通信を可能にする技術が開示されている。
【０００４】
【特許文献１】
特開２００２−０７３５１６号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、従来の技術においては、ただ単に、まず享受端末をネットワークに受信端末として接続し、次いで送信セッションを追加制御して、多くの端末接続と双方向機能の都度実現を可能にしているだけであって、双方向通信環境で、通話を維持しながら各種の付加通話サービスを提供する端末間の通話セッションの実現方法については、何ら開示されていない。
【０００６】
テレマーケティングサービスとしては、たとえば、広告提供サービス、アンケートサービス、インタビュー／座談会サービスなど、いろいろな付加通話サービスが考えられる。このような各種サービスにおいて、特に複数のセッションを用いたテレマーケティング付加通話サービスにおいて、あるセッションが別のセッションの状態に応じて開設またはクローズ（終了）動作可能であること、つまり、セッションの階層管理が可能であることは、テレマーケティングサービス事業者にとって非常に有益である。
【０００７】
たとえば、セールスマンが、通話端末を用いた顧客との通話セールスにおいて顧客アンケートを提示する場合、顧客に対してアンケートを送付する旨を伝え、通話セールスを終了した直後に、顧客の通話端末に表示させること、また、通話の終了とともに、商品カタログや資料などの提示を同時に終了させることが可能な場合には、それぞれ、必ずしも通話を継続しなくてもよい資料を提示しその回答の収集を自動的に行い、その間、次の顧客へのセールスに取り掛かることができ、また、多くのセッションを終了するために煩雑な操作入力を行う必要がなくなるため、いずれの場合もシステムとして効率的なセールスの実現が期待されることになる。
【０００８】
本発明は、かかる点に鑑みてなされたものであり、通信システムにおいて有益なセッション階層管理を行うことができるセッション管理装置を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明のセッション管理装置は、セッション開設要求を受信する受信手段と、受信されたセッション開設要求に応じて、指定された装置との間にセッションを開設する開設手段と、開設された複数のセッション間の階層関係を記憶する記憶手段と、前記階層関係に変更が生じたときに実行される予約処理を設定する設定手段と、前記階層関係に変更が生じたとき、設定された予約処理を実行する実行手段と、を有する構成を採る。
【００１０】
この構成によれば、開設された複数のセッション間の階層関係を設定し、この階層関係に変更が生じたときに実行される予約処理を設定しておき、各セッション間の階層関係に変更が生じたとき、設定された予約処理を実行するため、通信システムにおいて有益なセッション階層管理を行うことができる。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００１２】
図１は、本発明の一実施の形態に係るセッション管理装置を含む通信システムの構成の一例を示す図である。ここでは、通信システムとして、ＳＩＰを用いたテレマーケティングサービスシステムを例にとって説明する。
【００１３】
図１に示すシステムは、セールスマンの通話端末１００、顧客の通話端末２００、およびテレマーケティングサービスサーバ（以下単に「サーバ」という）３００を有する。通話端末１００、通話端末２００、およびサーバ３００は、図２に示すように、インターネット４００を介して相互に接続されている。
【００１４】
各通話端末１００、２００には、テレビモニタ１０２、２０２、カメラ１０４、２０４、およびマイク１０６、２０６が接続されており、ユーザに対して映像を入出力するとともに、図示しない入力装置（たとえば、リモコンやフロントパネルの操作キー、キーボード、タッチパネル、マウスなど）による各種制御のユーザ操作入力を受け付けながら、相手となる通話端末２００、１００との間でサーバ３００を介してマルチメディアデータによる付加通話サービスを行う。
【００１５】
ここで、マルチメディアデータは、少なくとも映像、音声、画像、テキストのいずれかを含むデータである。また、付加通話サービスは、たとえば、広告提供サービス、アンケートサービス、インタビュー／座談会サービスなどである。
【００１６】
サーバ３００は、セッション管理装置としてのセッション制御部３１０と、データ通信制御部３２０とを有する。セッション制御部３１０には、あらかじめセッション管理データ３１２が格納され、データ通信制御部３２０には、あらかじめ各種モジュールデータ３２２が格納されている。セッション制御部３１０は、セッション管理データ３１２に基づいて、各通話端末１００、２００との間で制御命令通信を行ってセッション制御、具体的には、セッションの開設・クローズ処理の制御を行う。データ通信制御部３２０は、各種モジュールデータ３２２に基づいて、開設されたセッションでのマルチメディアデータ通信、具体的には、マルチメディアデータの付加サービスを制御する。モジュールデータとしては、たとえば、特定商品の電子カタログのデータおよびプレーヤ機能を含むカタログモジュールや、顧客アンケートモジュールなどがある。なお、セッション管理データ３１２については、後で詳述する。
【００１７】
このように、図１のシステムにおいて、各通話端末１００、２００は、各種制御命令をサーバ３００に送信しまたはサーバ３００から受信して、サーバ３００との間にマルチメディアデータ用のデータ通信セッションを開設し、さらに、この開設したセッションでのデータ通信を制御する機能を有する。一方、サーバ３００は、各通話端末１００、２００から受信した各種制御命令に応じて、各通話端末１００、２００とのセッション開設・クローズ処理、および、開設したセッションでのデータ通信制御を行う機能を有する。
【００１８】
なお、図１に示すように、通話端末１００、２００間では、サーバ３００での処理を必要とする付加通話サービス以外について、サーバ３００を経由しないピアツーピア接続によるマルチメディアデータ通信も可能である。
【００１９】
以下、本実施の形態では、ダウンロードモジュールの応用例としてアンケートモジュールを実現する場合について説明する。その際、本実施の形態では、セッションの階層管理（つまり、セッション間を階層付けした管理）に加えてセッション状態の変化時に実行する「予約処理」の登録をそれぞれ可能にする仕組みとともに、情報をサーバで管理し、セッションの開設・クローズ時にサーバへ各種階層情報を通知・登録する仕組みを実現している。そのため、本実施の形態では、開設したセッションに「セッションＩＤ」（単に「ＩＤ」とも略記する）を付与・設定して、セッションを階層管理するようにしている。セッションＩＤは、開設されたマルチメディアセッションを識別するための論理的な識別子である。
【００２０】
まず、セッションの管理方法について説明する。ここでは、図３〜図９を用いて、通話端末１００、２００間でメッセージを送受信し、各種セッションを階層管理する手順について説明する。なお、セッション管理データ３１２は、上記のように、サーバ３００内に格納されている。
【００２１】
（１）セッションの概念
図３および図４は、それぞれ、セッション管理処理の一例を示すシーケンス図である。
【００２２】
各通話端末１００、２００は、要求メッセージとこれに対する応答メッセージとを送受信して通信セッションを開設した後、通話データを送受信する、または、ファイルモジュールをダウンロードする、といった、1つのまとまりのセッション処理を実行する。そこで、このようなメッセージ処理セッションを単位として、該当するメッセージ交換処理にセッションＩＤを割り当てて、セッションの管理を行う。
【００２３】
たとえば、図３は、通話端末１００が通話端末２００に対して、サーバ３００からのモジュールダウンロードを要求して、ダウンロード処理する際に、次の２つの処理セッションを含む様子を示している。
【００２４】
セッション１（ＩＤ＝１）：通話端末１００が、通話端末２００に対して「サーバ３００からモジュールをダウンロード」することを要求し、通話端末２００から実行結果の応答を受ける。
【００２５】
セッション２（ＩＤ＝２）：通話端末２００が、サーバ３００に対して「モジュールダウンロード通信セッションの開設」を要求し、ダウンロード処理終了後、当該セッションをクローズする。
【００２６】
また、図４は、通話端末１００が、通話端末２００へのモジュールダウンロード処理の実行をサーバ３００に伝達依頼して、ダウンロード処理させる場合の一例を示し、次の３つの処理セッションを含む様子を示している。
【００２７】
セッション３（ＩＤ＝３）：通話端末１００が、サーバ３００に対して「『サーバ３００からモジュールをダウンロード』するよう、通話端末２００に伝達する」ことを要求し、通話端末２００から実行結果の応答を受ける。
【００２８】
セッション４（ＩＤ＝４）：サーバ３００が、『サーバ３００からモジュールをダウンロード』するよう、通話端末２００に要求し、通話端末２００から実行結果の応答を受ける。
【００２９】
セッション５（ＩＤ＝５）：通話端末２００が、サーバ３００に対して「モジュールダウンロード用の通信セッションの開設」を要求し、ダウンロード処理終了後、当該セッションをクローズする。
【００３０】
なお、後述するシステム全体の処理シーケンス（図１５〜図１８参照）では、要求・応答メッセージの送受信を確認する予備的なメッセージを送受信しているが、図３および図４では、簡単化のため、それらを含めて１つのセッションとしている。
【００３１】
（２）セッションＩＤの発行とセッションの階層管理
セッションＩＤの利用管理は、たとえば、次に示すセッションＩＤ利用規則１〜５に従って行われる。
【００３２】
まず、セッションを識別するセッションＩＤを生成し使用するためのセッションＩＤ利用規則１〜２は、たとえば、次に示すとおりである。
【００３３】
セッションＩＤ利用規則１：セッションの開始を要求するメッセージを発行する装置が、グローバルで一意のＩＤを生成し、要求メッセージに付加して、送信する。
【００３４】
セッションＩＤ利用規則２：新規のセッションＩＤが付加された要求メッセージを受信した装置は、メッセージに同一のセッションＩＤを付加して応答する。
【００３５】
ここで、ＩＤの具体例としては、グローバルな一意の付与規則に基づいて設定すればどのようなものでもよく、たとえば、localID@hostのような構造で、localID値については、ＲＦＣ１７５０に規定されている"Randomness Recommendations for Security"などを使用することもできる。
【００３６】
また、セッションを階層管理するための、特にサーバ３００で処理されるセッションＩＤ利用規則３〜５は、たとえば、次に示すとおりである。
【００３７】
セッションＩＤ利用規則３：サーバ３００は、自己の発行したセッションＩＤに加えて、通話端末１００、２００から受信したメッセージを参照して、通話端末１００、２００の発行したそのセッションの存在中、記憶保持する。
【００３８】
セッションＩＤ利用規則４：サーバ３００は、記憶するセッションＩＤをセッションＩＤ間の親子関係情報と共に記憶し、通話端末１００、２００からの階層関係を操作するメッセージを受けて階層関係情報を変更可能とする。
【００３９】
セッションＩＤ利用規則５：サーバ３００は、セッションＩＤ、または、セッションＩＤの親子関係が変化する際にサーバ３００が行う処理動作（イベント処理動作）情報を記憶し、通話端末１００、２００からの動作設定メッセージにより設定する。
【００４０】
これらの規則３〜５に基づく動作例としては、たとえば、通話セッションとカタログ制御セッションの親子設定と、相手の通話端末へのアンケート送信の予約とにより、通話セッション終了時に子セッション終了とアンケート送信の処理動作を実行すること（たとえば、後述する図１６〜図１８中の（ｃ）〜（ｅ）のステージ参照）が挙げられる。また、これ以外にも、たとえば、子セッションの増減や最大値への到達、セッション開始からの経過時間などのように、サーバ３００での管理状態に応じた動作契機を設定してもよい。
【００４１】
（３）セッション管理処理方法
ここでは、セッション管理データを記憶し、受信したメッセージに応じてセッション管理処理を行うサーバ３００の動作について説明する。
【００４２】
まず、セッション管理データ３１２について説明する。セッション管理データ３１２は、セッション階層管理データとイベント動作管理データとからなり、それぞれテーブル形式で記憶・管理されている。図５は、セッション階層管理データの構成の一例を示し、図６は、イベント動作管理データの構成の一例を示している。セッション階層管理データは、図５に示すように、セッションＩＤと、そのセッションが別のセッションの子である場合はその親のセッションＩＤとを示すデータである。ここで、図５（Ａ）は、セッション管理開始前の初期状態を示し、図５（Ｂ）は、セッション管理開始後の状態を示している。また、イベント動作管理データは、図６に示すように、イベント処理動作が登録されたセッションのＩＤと、その動作開始条件であるイベントデータと、動作処理内容であるアクションデータとを示すデータである。
【００４３】
なお、同図中（他の図面でも同様）、「Ｕ１」は通話端末１００、「Ｕ２」は通話端末２００、「Ｓ」はサーバ３００をそれぞれ示している。
【００４４】
次に、サーバ３００におけるセッション管理処理について、図７〜図９のフローチャートを用いて説明する。なお、ここでは、便宜上、通話セッション開設後におけるセッション管理処理について説明する。図５（Ａ）に示す初期状態から通話セッションを開設するまでの処理については、後で説明する（後述する図１５および図１６中の（ａ）のステージ参照）。
【００４５】
図７は、サーバ３００におけるセッション管理処理手順の一例を示すメインフローチャートである。
【００４６】
まず、ステップＳＴ１０００では、通話端末１００、２００からのメッセージを受信する。
【００４７】
そして、ステップＳＴ１１００では、ステップＳＴ１０００で受信したメッセージの宛先を判断する。この判断の結果としてメッセージの宛先が通話端末の場合は、ステップＳＴ１２００に進み、メッセージの宛先がサーバの場合は、ステップＳＴ１５００に進む。
【００４８】
ステップＳＴ１２００では、通話端末宛のメッセージの内容を判断し、それがセッションの開設または終了の要求メッセージであるか、これ以外の他の要求メッセージであるかを判断する。この判断の結果として通話端末宛のメッセージがセッション開設／終了要求メッセージである場合は（Ｓ１２００：ＹＥＳ）、ステップＳＴ１３００に進み、通話端末宛のメッセージがセッション開設／終了要求メッセージ以外の他の要求メッセージである場合は(Ｓ１２００：ＮＯ)は、ただちにステップＳＴ１４００に進む。
【００４９】
ステップＳＴ１３００では、セッションのサブ管理処理を実行する。
【００５０】
図８は、図７のステップＳＴ１３００のセッションサブ管理処理の内容を示すフローチャートである。
【００５１】
ステップＳＴ１３１０では、通話端末宛のメッセージの内容を判断し、それがセッション開設要求メッセージかセッション終了要求メッセージかを判断する。この判断の結果としてメッセージがセッション開設要求メッセージの場合は、ステップＳＴ１３２０に進み、メッセージがセッション終了要求メッセージの場合は、ステップＳＴ１３３０に進む。
【００５２】
ステップＳＴ１３２０では、セッションの開設要求の場合に、セッション管理データテーブルにレコード（セッション階層管理レコードを含む）を追加し、メッセージ内のセッションＩＤを記憶した後、図７のメインフローチャートにリターンする。
【００５３】
一方、ステップＳＴ１３３０では、セッションの終了要求の場合に、まず対象セッションに対する予約処理を検索する。
【００５４】
そして、ステップＳＴ１３４０では、ステップＳＴ１３３０で検索した予約処理に伴って発生する予約処理をすべて実行する。
【００５５】
具体的には、実行すべき予約処理のリストを受け取った後、そのリストから１つの予約処理を取り出し、この取り出した予約処理に伴って発生する予約処理を検索する。そして、この検索結果として該当する予約処理があれば、当該予約処理に伴って発生する予約処理をすべて実行する。これに対し、検索結果として該当する予約処理がなければ、実行すべき予約処理を実行して、セッション階層管理レコードを削除する。そして、リスト内に次の予約処理があるか否かを判断し、この判断結果として次の予約処理があれば、リストから１つの予約処理を取り出す処理に戻って上記と同様の処理を繰り返し、次の予約処理がなければ、当該サブルーチンを終了する。
【００５６】
そして、ステップＳＴ１３５０では、対象セッションに対する予約処理を実行する。
【００５７】
そして、ステップＳＴ１３６０では、セッション階層管理レコードを削除した後、図７のメインフローチャートにリターンする。
【００５８】
すなわち、ステップＳＴ１３３０〜ステップＳＴ１３６０では、セッションの終了要求の場合に、メッセージ内のセッションＩＤを記憶するセッション管理データテーブルのレコードを削除する。ただし、削除対象のセッションの終了を対象として設定されているイベント動作管理データレコードが存在する場合は、その処理を実行する。
【００５９】
そして、ステップＳＴ１４００では、宛先の通話端末にメッセージを転送した後、ステップＳＴ２２００に進む。すなわち、セッション開設／終了要求メッセージの場合は、メッセージに応じたセッションサブ管理処理を実行した後、宛先の通話端末にメッセージを転送し、セッション開設／終了要求メッセージ以外のメッセージの場合は、そのまま宛先の通話端末にメッセージを転送する。
【００６０】
これに対し、メッセージの宛先がサーバの場合は、ステップＳＴ１５００〜ステップＳＴ１８００でそのメッセージの内容を判断し、それがダウンロード（ＤＬ）セッション開設要求メッセージ、モジュール（たとえば、カタログやアンケート）ダウンロード（ＤＬ）要求メッセージ、セッション階層操作要求メッセージ、および予約処理設定要求メッセージのいずれであるかを判断する。そして、前二者の場合は、メッセージに応じたサーバ処理（セッション開設、ダウンロード）を実行する。また、後二者の場合は、メッセージに応じたセッションサブ管理処理を実行する。
【００６１】
すなわち、ステップＳＴ１５００では、サーバ宛のメッセージの内容を判断し、それがダウンロードセッション開設要求メッセージであるか否かを判断する。この判断の結果としてメッセージの内容がダウンロードセッション開設要求メッセージの場合は(Ｓ１５００：ＹＥＳ)、ステップＳＴ１９００に進み、そうでない場合は(Ｓ１５００：ＮＯ)、ステップＳＴ１６００に進む。
【００６２】
ステップＳＴ１９００では、要求先の通話端末とのダウンロードセッションを開設した後、ステップＳＴ２２００に進む。
【００６３】
一方、ステップＳＴ１６００では、さらにサーバ宛のメッセージの内容を判断し、それがモジュールダウンロード要求メッセージであるか否かを判断する。この判断の結果としてメッセージの内容がモジュールダウンロード要求メッセージの場合は(Ｓ１６００：ＹＥＳ)、ステップＳＴ２０００に進み、そうでない場合は(Ｓ１６００：ＮＯ)、ステップＳＴ１７００に進む。
【００６４】
ステップＳＴ２０００では、要求元の通話端末へのモジュールダウンロードを開始した後、ステップＳＴ２２００に進む。
【００６５】
一方、ステップＳＴ１７００では、さらにサーバ宛のメッセージの内容を判断し、それがセッション階層操作要求メッセージであるか否かを判断する。この判断の結果としてメッセージの内容がセッション階層操作要求メッセージの場合は(Ｓ１７００：ＹＥＳ)、ステップＳＴ２１００に進み、そうでない場合は(Ｓ１７００：ＮＯ)、ステップＳＴ１８００に進む。
【００６６】
ステップＳＴ１８００では、さらにサーバ宛のメッセージの内容を判断し、それが予約処理設定要求メッセージであるか否かを判断する。この判断の結果としてメッセージの内容が予約処理設定要求メッセージの場合は(Ｓ１８００：ＹＥＳ)、ステップＳＴ２１００に進み、そうでない場合は(Ｓ１８００：ＮＯ)、ただちにステップＳＴ２２００に進む。
【００６７】
ステップＳＴ２１００では、セッションのサブ管理処理を実行する。
【００６８】
図９は、図７のステップＳＴ２１００のセッションサブ管理処理の内容を示すフローチャートである。
【００６９】
ステップＳＴ２１１０では、サーバ宛のメッセージの内容を判断し、それがセッション階層操作要求メッセージか予約処理設定要求メッセージかを判断する。この判断の結果としてメッセージがセッション階層操作要求メッセージの場合は、ステップＳＴ２１２０に進み、メッセージが予約処理設定要求メッセージの場合は、ステップＳＴ２１３０に進む。
【００７０】
ステップＳＴ２１２０では、セッション階層操作要求の場合に、当該メッセージに基づいて、セッション階層管理データテーブル（特に図５（Ｂ）参照）のレコードの親セッションＩＤを操作設定（修正）した後、図７のメインフローチャートにリターンする。
【００７１】
一方、ステップＳＴ２１３０では、予約処理設定要求の場合に、当該メッセージに基づいて、イベント動作管理データテーブル（図６参照）のレコードの追加・削除または値の設定（修正）を行った後、図７のメインフローチャートにリターンする。
【００７２】
そして、ステップＳＴ２２００では、当該セッション管理処理を終了するか否かを判断し、終了しない場合は(Ｓ２２００：ＮＯ)、ステップＳＴ１０００に戻って、終了するまでステップＳＴ１０００〜ステップＳＴ２１００の一連の処理を繰り返す。
【００７３】
なお、ステップＳＴ１３００のセッションサブ管理処理では、セッション終了のイベントのみに基づく予約処理の実行（図８参照）を例示したが、これに限定されるわけではなく、他のイベント処理についても、セッション管理データに登録し、検索・実行する同様の手順を追加することにより、実行することができる。
【００７４】
また、サーバ宛のメッセージの内容を判断する順番は、ステップＳＴ１５００〜ステップＳＴ１８００に示す順番に限定されないことはもちろんである。すなわち、ダウンロードセッション開設要求メッセージ、モジュールダウンロード要求メッセージ、セッション階層操作要求メッセージ、および予約処理設定要求メッセージにおいて任意の順番をとることができる。
【００７５】
次に、各装置間で送受信するメッセージ（命令）について、図１０（Ａ）〜図１２（Ｇ）を用いて説明する。図１０（Ａ）〜図１２（Ｇ）は、通話端末１００とサーバ３００間、および、サーバ３００と通話端末２００間で送受信される各種メッセージの構成例を示している。
【００７６】
各メッセージは、メッセージの送信元、メッセージの送信先、およびメッセージ名を示すメッセージヘッダ部と、メッセージに応じた内容を示すボディ部とで構成されている。なお、メッセージヘッダ部の送信元・送信先の表記について、通話端末の表記の場合、たとえば、通話端末１００（Ｕ１）を同図中では「Ｕ１＠Ｓ」と表記しているが、これは、インターネット上で「サーバ３００（Ｓ）が管理するドメインＳ内の端末Ｕ１」であることを明示的に表しており、実際上このように表記してもよい。以下、図１０（Ａ）〜図１２（Ｇ）の説明において、通話端末１００を「端末Ｕ１」、通話端末２００を「端末Ｕ２」、サーバ３００を「サーバＳ」とそれぞれ略記する。
【００７７】
＜ダウンロード要求処理＞
図１０（Ａ）は、端末Ｕ１が端末Ｕ２に対してカタログモジュールのダウンロードを要求するメッセージの一例を示し、次のデータにより構成されている。
【００７８】
メッセージヘッダ部は、
メッセージＩＤ：「1100_u1」
送信元：「Ｕ１」
送信先：「Ｕ２」
メッセージの内容：「カタログモジュールダウンロード要求」
を示し、ボディ部は、
ダウンロードモジュールの格納場所：「サーバＳ内のカタログ０１（ファイル）」
カタログ制御セッションの開設先：「Ｕ１」
を示している。
【００７９】
ここで、カタログ制御セッションの開設先データは、図１１（Ｄ）に示すカタログ制御セッション開設要求メッセージの送信先を示し、当該メッセージは、カタログモジュールをダウンロードし、ダウンロードモジュール実行時に端末Ｕ１に対してカタログ制御セッションを開設することを要求している。
【００８０】
特に、制御セッションの接続先データをカタログモジュール内に埋め込まず、メッセージ送信時に指定することにより、複数のセールスマンが各自の通話端末でセールスする場合、各セールスマンの通話端末に合わせたモジュールを用意することなく同一のカタログモジュールを使用することができるという利点がある。
【００８１】
＜ダウンロード処理＞
図１０（Ｂ）は、端末Ｕ２がサーバＳに対してダウンロードセッションの開設を要求するメッセージの一例を示し、次のデータにより構成されている。
【００８２】
メッセージヘッダ部は、
メッセージＩＤ：「2100_u2」
送信元：「Ｕ２」
送信先：「Ｓ」
メッセージの内容：「ダウンロードセッション開設要求」
を示している。なお、ボディ部は、存在しない。
【００８３】
図１０（Ｃ）は、端末Ｕ２がサーバＳに対してカタログのダウンロード開始を要求するメッセージの一例を示し、次のデータにより構成されている。
【００８４】
メッセージヘッダ部は、
メッセージＩＤ：「2102_u2」
送信元：「Ｕ２」
送信先：「サーバＳ」
メッセージの内容：「ダウンロード開始要求」
を示し、ボディ部は、
ダウンロードモジュールの格納場所：「サーバＳ内のカタログ０１（ファイル）」
を示している。
【００８５】
ここで、通話端末は一般に同一機種・形式であるとは限らないため、カタログ内容が同等相当で機種ごとのモジュールをサーバＳに格納し、通話端末に適するダウンロードモジュールを提供することが望ましい。これは、たとえば、カタログモジュールのダウンロード要求メッセージ（図１０（Ａ）参照）のダウンロードモジュール格納場所データに、モジュールファイルのＵＲＬを指定する代わりに、各種別のモジュールで構成されるモジュールセット名を指定し、ダウンロードセッションの開設要求メッセージ（図１０（Ｂ）参照）のボディ部にセット名を指定するレコードを設け、その応答として、モジュールファイル名とその適合機種とからなるリスト情報を受け、自端末の機種に相当するモジュールファイルをダウンロード開始要求メッセージ（図１０（Ｃ））のダウンロードモジュール格納場所レコードに指定することにより、実行可能である。
【００８６】
なお、アンケートモジュール（ダウンロード処理）についても、同様なメッセージ形式である。
【００８７】
＜カタログ制御処理＞
図１１（Ｄ）は、端末Ｕ２が端末Ｕ１に対してカタログ制御セッションの開設を要求するメッセージの一例を示し、次のデータにより構成されている。
【００８８】
メッセージヘッダ部は、
メッセージＩＤ：「2103_u2」
送信元：「Ｕ２」
送信先：「Ｕ１」
メッセージの内容：「カタログ制御セッションの開設要求」
を示し、ボディ部は、
カタログ制御セッションの開設先：「Ｕ２」
カタログ操作命令の種類：「NextPage（次ページへ），BackPage（前のページへ），JumpPage[#]（指定ページ［ページ番号＃］へ）」
を示している。
【００８９】
ここでは、カタログ操作命令の種類として、シーケンシャルに配置表示され、ページめくり操作可能なカタログを想定し、「NextPage,BackPage,JumpPage[#]」などとしているが、表示商品のオブジェクトの操作であれば、「CloseUp Item1（商品１を拡大表示）」などとしてもよい。また、商品の動きを見せるビデオやシミュレーション動作するコンテンツであれば、「Play（再生）」、「Stop（停止）」、あるいは、「Open Door1（扉１を開ける）」、「TurnOn Light1（ライト１を点灯）」などとしてもよい。
【００９０】
＜カタログ表示操作処理＞
図１１（Ｅ）は、端末Ｕ１から端末Ｕ２に対するカタログ表示操作メッセージの一例を示し、次のデータにより構成されている。
【００９１】
メッセージヘッダ部は、
メッセージＩＤ：「2103_u2」
送信元：「Ｕ１」
送信先：「Ｕ２」
メッセージの内容：「カタログ表示操作」
を示し、ボディ部は、
カタログ操作命令：「NextPage」
を示している。
【００９２】
ここで、サーバＳ経由での端末Ｕ１、Ｕ２間のカタログ表示操作メッセージの更新は、直接端末Ｕ１、Ｕ２間で通信するセッションを開設して制御情報を交換する場合は、カタログ制御セッションの開設要求メッセージにて、ボディ部に当該セッションの通信条件を記述することにより実行可能である。その際、メッセージの構造は、当然、上記のメッセージ構造に限定されるわけではなく、モジュールで規定した独自形式のメッセージでもよい。
【００９３】
＜階層操作要求＞
図１２（Ｆ）は、端末Ｕ１がサーバＳに対してセッションＩＤ＝１１（1001_u1）の親セッションをセッションＩＤ＝１(1000_u1)に設定要求するメッセージの一例を示し、次のデータにより構成されている。
【００９４】
メッセージヘッダ部は、
メッセージＩＤ：「1103_u1」
送信元：「Ｕ１」
送信先：「Ｓ」
メッセージ：「セッション階層操作要求」
を示し、ボディ部は、
操作種別：「親データの設定」
対象セッション：「セッション1001_u1」
親セッション：「セッション1000_u1」（設定解除の場合は空欄とする）
を示している。
【００９５】
なお、操作種別を変更して親データの変更・解除または設定状態の問い合わせ処理とする場合も、当該メッセージ形式で実行可能である。
【００９６】
＜予約処理設定要求＞
図１２（Ｇ）は、端末Ｕ１がサーバＳに対して、セッションＩＤ＝１（1000_u1）の終了時に、サーバＳから端末Ｕ２に対してアンケートモジュールのダウンロード要求を送信することを予約するメッセージの一例を示し、次のデータにより構成されている。
【００９７】
メッセージヘッダ部は、
メッセージＩＤ：「1104_u1」
送信元：「Ｕ１」
送信先：「Ｓ」
メッセージの内容：「予約処理設定要求」
を示し、ボディ部は、
操作種別：「予約データの設定」
対象セッション：「セッション1000_u1」
状態変化イベント:「セッションの終了」
処理内容：「アンケートモジュールのダウンロード、サーバＳ、アンケート＃１」
を示している。
【００９８】
ここで、処理内容については、各装置へ送信するメッセージを生成するための情報を格納している。また、操作種別を変更して設定の変更・解除または設定状態の問い合わせ処理とする場合も、当該メッセージ形式で実行可能であることはもちろんである。
【００９９】
次に、アンケートモジュールの構成およびモジュール動作処理フローについて、図１３および図１４を用いて説明する。
【０１００】
図１３は、サーバ３００から通話端末２００にダウンロードされるアンケートモジュールの構成の一例を示している。図１３に示すアンケートモジュール３２４は、アンケートデータ３２６と、アンケート表示制御プレーヤデータ３２８とで構成されている。
【０１０１】
アンケートデータ３２６は、たとえば、テキストやイメージ、音声、映像などで作成された質問内容とその回答方法、選択肢、回答参考資料などで構成される設問データと、質問内容や選択肢の配置・提示順序、回答結果に応じた設問提示順序などで構成される設問レイアウトデータと、回答データの送付先や送信方法などで構成される回収方法データとを有する。
【０１０２】
アンケート表示制御プレーヤデータ３２８は、たとえば、アンケートデータ３２６に基づいて、各設問を提示し、ユーザ入力操作を受けながら、回答データを生成して、アンケート回答結果として集計サーバへ送付処理をするプログラムデータを有する。
【０１０３】
通話端末２００は、このようなアンケートモジュール３２４をサーバ３００からダウンロードすると、内部動作プログラムに従って、アンケート表示制御プレーヤデータ３２８をロード・起動し、アンケートモジュール３２４を再生実行する。
【０１０４】
図１４は、通話端末２００におけるアンケートモジュール再生処理手順の一例を示すフローチャートである。
【０１０５】
まず、ステップＳＴ３０００では、アンケート内容の初期表示画面（１つ目の設問）を表示出力する。
【０１０６】
そして、ステップＳＴ３１００では、ユーザ入力を受け付ける。
【０１０７】
そして、ステップＳＴ３２００では、ステップＳＴ３１００で受け付けたユーザ入力が回答条件に合致するか否かを判断する。この判断の結果としてユーザ入力が回答条件に合致する場合は(Ｓ３２００：ＹＥＳ)、ステップＳＴ３３００に進み、ユーザ入力が回答条件に合致しない場合は(Ｓ３２００：ＮＯ)、ステップＳＴ３１００に戻って、回答条件に合致するまでユーザ入力を繰り返す。
【０１０８】
ステップＳＴ３３００では、回答条件に合致するユーザ入力を回答データとして蓄積する。
【０１０９】
すなわち、ステップＳＴ３１００〜ステップＳＴ３３００では、ユーザ入力を受け付けて、回答データを蓄積する。ただし、回答条件に合致するか否かをチェックし、合致しない場合は、合致するまでユーザ入力を繰り返す。
【０１１０】
そして、ステップＳＴ３４００では、全設問が終了したか否かを判断する。この判断の結果として全設問が終了した場合は(Ｓ３４００：ＹＥＳ)、ステップＳＴ３５００に進み、全設問が終了していない場合は(Ｓ３４００：ＮＯ)、ステップＳＴ３０００に戻って、次の設問を検索・出力表示し、ステップＳＴ３１００〜ステップＳＴ３３００の処理を繰り返す。
【０１１１】
ステップＳＴ３５００では、出力表示する設問がなくなったため、アンケート回収方法データに基づいて、蓄積している回答データをすべて送付先に送信する。
【０１１２】
なお、アンケートの表示処理内容は、特に限定されるわけではなく、文字や図形、写真のみならず、音声や映像などによる表現形式であってもよい。また、アンケートの表示中にユーザ入力を受け付けるようにしてもよいし、表示後に受け付けるようにしてもよい。
【０１１３】
また、ステップＳＴ３１００におけるユーザ入力装置および入力データ（回答データ）形式は、特に限定されるわけではなく、通話端末のリモコン・フロントパネルの操作ボタン、キーボードなどによる選択番号データや文字データのみならず、タッチパネル、マウス装置などによる図形データ、または、マイク、カメラ装置による発言音声データ、手振り・ジェスチャ映像データであってもよいのはもちろんである。
【０１１４】
次に、全体の処理シーケンスの具体例について、図１５〜図１８のシーケンス図を用いて説明する。図１５〜図１８は、通話端末１００でのユーザ操作入力に応じて、通話端末２００に対してカタログを配付・表示し、相互にカタログ表示操作する処理に加え、さらに、通話端末１００でのユーザ操作入力に応じて、通話端末２００に対してアンケートモジュールを送信・表示し、アンケート回答を得る場合の本実施の形態における処理シーケンスを、セッションの状態と共に示している。なお、以下、通話端末１００を「端末Ｕ１」、通話端末２００を「端末Ｕ２」、サーバ３００を「サーバＳ」とそれぞれ略記する。
【０１１５】
ここで、図１５〜図１８に示すシステム全体の処理シーケンスは、６つの処理ステージ、具体的には、映像通話処理（図１５および図１６の（ａ）参照）、モジュールダウンロード処理（図１６の（ｂ）参照）、制御セッション開設・表示制御処理（図１６および図１７の（ｃ）参照）、アンケート送信予約処理（図１７の（ｄ）参照）、通話セッションクローズ処理（図１７および図１８の（ｅ）参照）、およびアンケートモジュールダウンロード・アンケート回答処理（図１８の（ｆ）参照）の各ステージから構成されている。以下、各ステージを順に説明する。なお、サーバＳには、たとえば、車の電子カタログモジュールに加えて、顧客アンケートモジュールがあらかじめ格納されているとする。
【０１１６】
映像通話処理（図１５および図１６の（ａ）参照）
ステップＳＴ１：端末Ｕ１から、サーバＳを介して端末Ｕ２に通話セッション開設通知を送信し、映像通話セッション（ＩＤ＝１）を開設して、映像通信を開始する。
【０１１７】
具体的には、まず、端末Ｕ１から、通話セッション開設メッセージを、サーバＳを介して端末Ｕ２に送信する。この開設メッセージに対して、端末Ｕ２は、呼び鈴動作応答、および、通話を承諾する場合は承諾応答を、サーバＳを介して端末Ｕ１に送信する。この承諾応答に対して、端末Ｕ１は、ＡＣＫ（Acknowledgement：肯定応答）を、サーバＳを介して端末Ｕ２に送信する。この一連の処理により、端末Ｕ１と端末Ｕ２の間にマルチメディア通信のセッションが開設され、双方向の映像データの通信が開始される。
【０１１８】
モジュールダウンロード処理（図１６の（ｂ）参照）
ステップＳＴ２：端末Ｕ１から、カタログモジュールのダウンロード要求メッセージを、サーバＳを介して端末Ｕ２に送信する。
【０１１９】
ステップＳＴ３：端末Ｕ２は、サーバＳに対して、ダウンロードセッション開設要求メッセージを送信し、サーバＳとのダウンロードセッション（ＩＤ＝２）を開設する。
【０１２０】
ステップＳＴ４：さらに、端末Ｕ２は、モジュールダウンロード要求メッセージをサーバＳに送信し、カタログモジュールを受信する。そして、カタログモジュールの受信後、ダウンロードセッション（ＩＤ＝２）をクローズする。
【０１２１】
制御セッション開設・表示制御処理（図１６および図１７の（ｃ）参照）
ステップＳＴ５：端末Ｕ２は、カタログモジュールを実行・表示し、サーバＳに対して、端末Ｕ１とのカタログ制御セッションの開設要求メッセージを送信する。
【０１２２】
ステップＳＴ６：サーバＳは、端末Ｕ１にメッセージを伝達し、端末Ｕ１と端末Ｕ２とを接続するカタログ制御セッション（ＩＤ＝３）を開設する。
【０１２３】
ステップＳＴ７：続けて、端末Ｕ１から、カタログ制御セッション（ＩＤ＝３）を通話セッション（ＩＤ＝１）の子セッションとして登録するセッション階層制御要求メッセージを送信する（ＩＤ＝４）。また、同時に、通話セッションがクローズされた時にカタログ制御セッションもクローズする処理を予約するメッセージ（予約設定要求メッセージ）も送信する（ＩＤ＝５）。
【０１２４】
ステップＳＴ８：端末Ｕ１は、ユーザのカタログ表示操作入力を受け付けて、表示を変更するとともに、端末Ｕ２に表示操作メッセージを送信する。
【０１２５】
ステップＳＴ９：端末Ｕ１から表示操作メッセージを受信した端末Ｕ２は、そのメッセージ内容に応じて、カタログ表示を変更する。
【０１２６】
アンケート送信予約処理（図１７の（ｄ）参照）
ステップＳＴ１０：端末Ｕ１は、ユーザのアンケート送信操作入力を受け付けて、通話セッション（ＩＤ＝１）がクローズされた時に、「端末Ｕ２にアンケートモジュールのダウンロード要求メッセージを送信する」動作を予約する予約設定要求メッセージをサーバＳに送信・設定する（ＩＤ＝６）。
【０１２７】
通話セッションクローズ処理（図１７および図１８の（ｅ）参照）
ステップＳＴ１１：端末Ｕ１は、ユーザの通話終了操作入力を受け付けて、通話セッション（ＩＤ＝１）をクローズする要求メッセージをサーバＳに送信する。
【０１２８】
ステップＳＴ１２：サーバＳは、通話セッション（ＩＤ＝１）のクローズ処理とともに、ステップＳＴ７で予約された、カタログ制御セッションの終了処理（ＩＤ＝３）を実行し、当該終了処理が完了したことを端末Ｕ１に通知する（ＩＤ＝６）。また、ステップＳＴ１０で予約された、端末Ｕ２へのダウンロード要求メッセージの送信処理（ＩＤ＝７）を実行する。
【０１２９】
アンケートモジュールダウンロード・アンケート回答処理（図１８の（ｆ）参照）
ステップＳＴ１３：端末Ｕ２は、サーバＳに対して、ダウンロードセッション開設要求メッセージを送信し、サーバＳとのダウンロードセッション（ＩＤ＝８）を開設する。
【０１３０】
ステップＳＴ１４：さらに、端末Ｕ２は、モジュールダウンロード要求メッセージをサーバＳに送信し、アンケートモジュールを受信する。そして、アンケートモジュール受信後、ダウンロードセッション（ＩＤ＝８）をクローズする。また、その結果を端末Ｕ１に通知する（ＩＤ＝６）。
【０１３１】
ステップＳＴ１５：端末Ｕ２は、アンケートモジュールを実行・表示処理する。
【０１３２】
ステップＳＴ１６：ユーザのアンケート回答入力および回答終了入力を受け付けて、回答データを生成し、サーバＳを介して端末Ｕ１に送信する（ＩＤ＝９）。
【０１３３】
なお、本実施の形態では、ステップＳＴ７において、セッションのクローズ時の処理内容を設定登録する処理メッセージ（予約設定要求メッセージ）を、セッションの階層を設定登録する処理メッセージ（セッション階層制御要求メッセージ）とは独立した個別のメッセージとして、続けて送信する場合について説明したが、これに限定されるわけではなく、図１５および図１６の（ｃ）に示すように、セッションクローズ時の動作属性値として、セッション階層制御要求メッセージに含めて同時に送信し、サーバＳでそれぞれ設定処理するようにしてもよい。
【０１３４】
また、ステップＳＴ１２において、サーバの処理を、通話セッションのクローズ処理、カタログ表示制御セッションのクローズ処理、アンケートモジュールのダウンロード要求メッセージ送信処理の順で列挙して説明したが、これに限定されるわけではなく、セッションのクローズ処理の前に予約処理を実行する、または、動作が前後しても結果が変わらないような処理について順序を交換し、もしくは同時に並行処理するようにして実行してもよい。
【０１３５】
また、ステップＳＴ１４において、サーバＳから端末Ｕ２へのダウンロード処理が完了したことを端末Ｕ１が確認できるように、結果を通知しているが、これに限定されるわけではなく、予約処理の結果をセッションＩＤや予約内容と共に通知するようにしてもよい。また、これは、ステップＳＴ１０で予約登録することによっても実行可能である。さらには、端末側からサーバに結果を問い合わせ、サーバが応答する機能を設けることなどによっても、容易に実行可能である。
【０１３６】
また、ステップＳＴ１６において、アンケート回答データをインスタントメッセージ（ＩＭ）通信手順で送信する場合について説明したが、これに限定されるわけではなく、カタログまたはアンケートモジュールのダウンロード時のようなダウンロード（アップロード）セッションを開設して送信する通信手順を用いてもよい。また、ファイル転送手順プロトコル（ＦＴＰ）、電子メール、または、独自のデータ送信手順によって送信してもよい。
【０１３７】
また、ステップＳＴ１６において、アンケートモジュールについては回答の送信先が端末Ｕ１であることをあらかじめ設定しているとして説明したが、これに限定されるわけではなく、サーバＳまたはサーバＳとは異なるインターネット上の回答集計サーバに送信するように設定してもよいことはもちろんである。
【０１３８】
このように、本実施の形態によれば、各セッション間の階層関係を設定し、セッションのクローズなど、セッションの接続状態が変更された時に実行する処理をセッションごとに予約登録することにより、複数セッションを用いたテレマーケティング通話サービスにおいて、有益なセッション階層管理を行うことができ、あるセッションが別のセッションの状態に応じて開設またはクローズ動作を行うテレマーケティング付加通話サービスを実現することができる。
【０１３９】
この結果、たとえば、セールスマンが、通話端末を用いた顧客との通話セールスにおいて、顧客アンケートを提示する場合、顧客に対してアンケートを送付する旨を伝え、通話セールスを終了した直後に、顧客の端末に表示させることが可能なシステムを実現することができる。また、通話の終了とともに、商品カタログや資料などの提示を同時に終了させることが可能なシステムを実現することができる。このように、必ずしも通話を継続しなくてもよい資料を提示しその回答の収集を自動的に行い、その間、次の顧客へセールスに取り掛かることができ、また、多くのセッションを終了するために煩雑な操作入力を行う必要がなくなるため、システム上、有益なセッション階層管理を行うことができ、効率的なセールスの実現を図ることができる。
【０１４０】
なお、本実施の形態では、適用対象の通信システムとして、ＳＩＰを用いた通信システム（テレマーケティングサービスシステム）を例にとって説明したが、これに限定されるわけではなく、本発明はＳＩＰ以外の任意の通信プロトコルを用いた通信システムに適用可能である。
【０１４１】
【発明の効果】
以上説明したように、本発明によれば、通信システムにおいて有益なセッション階層管理を行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態に係るセッション管理装置を含む通信システムの構成の一例を示す図
【図２】図１の各装置間の接続構成を示す図
【図３】本実施の形態におけるセッション管理処理の一例を示すシーケンス図
【図４】本実施の形態におけるセッション管理処理の他の一例を示すシーケンス図
【図５】図１のセッション管理データを構成するセッション階層管理データの構成の一例を示す図
【図６】図１のセッション管理データを構成するイベント動作管理データの構成の一例を示す図
【図７】図１のサーバにおけるセッション管理処理手順の一例を示すメインフローチャート
【図８】図７のステップＳＴ１３００のセッションサブ管理処理の内容を示すフローチャート
【図９】図７のステップＳＴ２１００のセッションサブ管理処理の内容を示すフローチャート
【図１０】（Ａ）：カタログモジュールのダウンロード要求メッセージの一例を示す図
（Ｂ）：ダウンロードセッションの開設要求メッセージの一例を示す図
（Ｃ）：カタログのダウンロード開始要求メッセージの一例を示す図
【図１１】（Ｄ）：カタログ制御セッションの開設要求メッセージの一例を示す図
（Ｅ）：カタログ表示操作メッセージの一例を示す図
【図１２】（Ｆ）：セッション階層操作要求メッセージの一例を示す図
（Ｇ）：予約処理設定要求メッセージの一例を示す図
【図１３】図１のモジュールデータに含まれるアンケートモジュールの構成の一例を示す図
【図１４】顧客の通話端末におけるアンケートモジュール再生処理手順の一例を示すフローチャート
【図１５】本実施の形態におけるシステム全体の処理シーケンスの一部を示すシーケンス図
【図１６】本実施の形態におけるシステム全体の処理シーケンスの、図１５に続く一部を示すシーケンス図
【図１７】本実施の形態におけるシステム全体の処理シーケンスの、図１６に続く一部を示すシーケンス図
【図１８】本実施の形態におけるシステム全体の処理シーケンスの、図１７に続く一部を示すシーケンス図
【符号の説明】
１００、２００  通話端末
３００  サーバ
３１０  セッション制御部
３１２  セッション管理データ
４００  インターネット
【図１】
2004206459.tif 000003
【図２】
2004206459.tif 000004
【図３】
2004206459.tif 000005
【図４】
2004206459.tif 000006
【図５】
2004206459.tif 000007
【図６】
2004206459.tif 000008
【図７】
2004206459.tif 000009
【図８】
2004206459.tif 000010
【図９】
2004206459.tif 000011
【図１０】
2004206459.tif 000012
【図１１】
2004206459.tif 000013
【図１２】
2004206459.tif 000014
【図１３】
2004206459.tif 000015
【図１４】
2004206459.tif 000016
【図１５】
2004206459.tif 000017
【図１６】
2004206459.tif 000018
【図１７】
2004206459.tif 000019
【図１８】
2004206459.tif 000020