JP2004265174A - コミュニケーション装置，サービス制御方法，コミュニケーション装置のエージェントプログラムおよびそのエージェントプログラムを記録した記録媒体 - Google Patents

Abstract

【課題】複数の利用者間でコミュニケーションサービスを利用する場合に，サービス起動に伴うアプリケーション選択やプログラム起動などの利用者の準備作業を軽減し，円滑なコミュニケーションを実現する。
【解決手段】通信サービスにおいて相手の意思確認ステップ，利用するＡＰを調整するステップ，動作環境を整備するステップ，自装置のＡＰを起動するステップの有無を選択記述することができる記述からなるサービスシナリオを用意しておく。利用者からのサービス要求に対し，エージェントブロック１０は，要求されたサービスに対応するサービスシナリオを選択し，そのシナリオの記述内容に基づき，リモートユーザインタラクション手段１４，利用ＡＰ調整手段１５，相手ＡＰ起動手段１６，ＡＰ制御手段１７を実行することにより，サービスの開始から終了まで，一連のシナリオに従って利用者にサービスを提供する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は，ネットワーク上の複数の利用者間で行うサービスを効率的に開始および実施するためのコミュニケーション装置およびサービス制御方法に関する。
【０００２】
【従来の技術】
従来，離れた複数人の利用者がネットワークサービスを利用してコミュニケーションあるいはコラボレーションする形態としては，ネットワークを通じて利用者端末同士が直接接続するピア・ツー・ピア（ｐｉｅｒ ｔｏ ｐｉｅｒ：Ｐ２Ｐ）タイプと，ネットワーク上にサーバを配置し複数の利用者が当該サーバ上のアプリケーションプログラムを共用するクライアント・サーバタイプの２つのタイプのサービスがある。
【０００３】
これらのサービスは，いずれも利用者端末上でクライアントソフトが予め起動していることを前提に，通信相手またはサーバに接続し，コミュニケーションを開始するシーケンスとなっている。すなわち，テレビ（ＴＶ）電話のようなコミュニケーションサービスを利用する場合には，参加者がコミュニケーションを行う前に，予め定められた時間に定められた場所の端末上にクライアントソフトを起動して，相手またはサーバに接続しサービスを開始する。
【０００４】
Ｐ２Ｐタイプのサービスの場合，話し掛ける側と話し掛けられる側が決まっており，同時に話し掛けるとプログラムの多重起動などを予防するための仕組みを別途用意する必要がある。クライアント・サーバタイプのサービスの場合，サービス提供者の予め指定するアドレスを事前に他の利用者に周知しておきそこに接続することになる。
【０００５】
また，インターネットなどの多種多様な利用者が参加するサービスの場合には，参加者それぞれが互いに通信可能なプロトコル，もしくは通信可能なアプリケーション製品が予め端末にインストールされていることが前提であり，複数の通信アプリケーションが存在する場合には，その中から適切なアプリケーションを選択し起動することが利用者に期待されている。
【０００６】
また，予め決められた時間に参加できなかった利用者には，電子メールを利用するなど，別の時間と手段で情報を電子データとして配布することが考えられるが，その契機や手段の選択，起動については利用者に委ねられている。
【０００７】
今日の利用者支援技術では，ＵＮＩＸ（商標）のシェルスクリプトのように利用者の操作環境をサーバ内に配置して一連の利用者のコマンド操作を簡素化する方法や，特許文献１（アプリケーション・インタフェース制御方法）で示されるように，交換機などのネットワーク機器にエージェントプログラムとシナリオを起動させて一連のサービス処理を連携したり，非特許文献１にあるように，利用者端末上で自ら端末間移動するエージェントプログラムを起動し知識ベースやスクリプトを使用してエージェント自らが問題解決するためにその動作を制御することにより利用者の要求を実現する方法や，特許文献２（エージェントサービス提供方法及びコンピュータ読み取り可能な記憶媒体）で示されるように，利用者の利用するサービスや動作環境に応じたシナリオを選択・生成してネットワーク上で実行するマルチエージェントサービス提供方法が存在する。
【０００８】
【特許文献１】
特開２０００−２４４５７８号公報
【特許文献２】
特開２００１−１９５３７２号公報
【非特許文献１】
本位田真一，飯島正，大須賀昭彦：ソフトウェアテクノロジーシリーズ３ エージェント技術，共立出版，ｐ１５９−ｐ１６２ ，（１９９９．７）
【０００９】
【発明が解決しようとする課題】
前項で述べたとおり，コミュニケーションを開始するためには，互いの端末でコミュニケーション用のクライアントソフトが予め起動している必要がある。従来のコミュニケーション用専用端末を利用したサービスの場合には，端末の電源を入れると自動的にクライアントソフトが起動し，そのまま待機状態となるが，最近普及し始めているＰＣ端末を利用したサービスの場合には，端末起動時に自動的にクライアントソフトが起動するようにすると，端末のリソース不足に繋がるため，必要に応じて利用者が起動することが望ましい。
【００１０】
しかし，この際，ＴＶ電話のようなＰ２Ｐタイプの場合，発信者がアポイント無しで通信相手にコミュニケーションを要求しても，受信側がクライアントソフトを起動しておらず接続できない可能性が大きいという問題がある。また，事前にスケジュール調整しておいても，受信側が指定時刻にクライアントソフトを起動し忘れていれば同様である。また，ＴＶ会議のようなクライアント・サーバタイプの場合，参加者各々がクライアントソフトの起動に加えて，指定時間に指定場所（サーバ）にアクセスする必要があり，Ｐ２Ｐの場合と同様に急な開催や利用者の起動し忘れに対応できないという問題がある。
【００１１】
また，Ｐ２Ｐ／クライアント・サーバタイプに関わらず，各コミュニケーションサービス利用者がサービス利用時にクライアントソフトを起動していたとしても，各々で使用しているソフト（通信アプリケーション）間の接続確認が取れていなかったり，異なる通信プロトコルを利用したソフトであったりすると，互いに正常にコミュニケーションができない可能性が高いという問題がある。
【００１２】
サービス開始前に利用者間で十分に使用するクライアントソフトに関する情報を把握しあっていれば問題ないが，クライアントソフトに関する知識が十分でなかったり，急な参加であったり，クライアントソフトの種類が全員で統一できないといった場合，各利用者にて何らかの手段で適切なアプリケーションを調査して選択しなければならないという問題がある。
【００１３】
また，従来のコミュニケーションサービスでは，一つのサービスを利用しようとしてもコミュニケーションが成り立たなかった場合（例えば，ＴＶ電話をかけても相手に繋がらなかった場合），そこでサービスが終了してしまう。しかし，コミュニケーションをとるという目的を達成するためには，利用者は，ある１つのサービスが利用できなくても代わりの手段で要求を実現することが好ましく（例えば，電話やメール等で通信相手にクライアントソフトの起動を促すなど），その手段は時と場合によって様々である。そのため利用者は，他の適切なサービスやアプリケーションを探し，選択して自ら起動しなくてはならない。
【００１４】
利用者への支援技術には，前項の［従来の技術］で説明したように，任意のサービスを支援する枠組みとしてのエージェント技術やシナリオを利用したサービス連携技術が，利用者端末上でのユーザ支援の例としてあるが，コミュニケーションサービスを支援するためには，端末装置に格納された複数のサービス要素（アプリケーション）を適切に連携させ，一連のコミュニケーションサービスとして提供する必要がある。
【００１５】
本発明は，複数の利用者間でコミュニケーションサービスを利用する場合に，サービス起動に伴うアプリケーション選択やプログラム起動など，従来，人間が行っていた準備作業を軽減すること，および，利用者が指定した手段が利用できない場合に代替の手段を提案，起動することで，従来，人間が行っていたリカバリ処理を軽減することを目的とする。
【００１６】
【課題を解決するための手段】
上記目的を達成するため，本発明に係るコミュニケーション装置は，利用者の端末操作や通信処理を制御するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を搭載する計算機端末であって，
利用者からのサービス要求を受け付けるとともに，他利用者からのサービスリクエストなどのインタラクションを表示する入出力手段と，
ネットワークを通して相手装置と通信する通信手段と，
アプリケーションプログラム（以下，ＡＰという）を実行するためのアプリケーションブロックと，
本装置を通して提供するサービスにおいて相手の意思確認ステップと利用するＡＰを調整するステップと互いの動作環境を整備するステップと自装置のＡＰを起動するステップの有無を選択記述することができることを特徴とするサービスシナリオ（以下，単にシナリオという）と，
当該サービスとそのサービスに対応する前記シナリオや本装置内に予め格納されたＡＰなどとの対応付けを行うサービス・ＡＰ対照表と，
少なくとも前記シナリオと前記サービス・ＡＰ対照表を格納したサービス情報格納手段と，
本装置が提供するサービスの実施主体であるＡＰを含むアプリケーション格納手段と，
本装置の動作環境情報などを記述した端末情報を格納した端末情報格納手段と，
本装置上でＡＰを起動するための条件を記述したＡＰ個別情報のＡＰ情報リストおよびＡＰ相互関係表を格納したＡＰ情報格納手段と，
利用者からのサービス要求を受け付けるとともに，他利用者からのサービスリクエストへの応答などのインタラクションを行うインタフェースを提供するインタラクション手段と，
前記入出力手段およびＯＳからの要求を受け付け，それをキューイングするサービス（イベント）要求受付け手段，当該要求を前記サービス・ＡＰ対照表をもとにサービス解析を行うサービス解析手段，前記サービス情報格納手段から得られたシナリオに従ってサービスを制御するシナリオ制御手段，複数の利用者間でサービスを開始するかどうかを意思確認するためのリモートユーザインタラクション手段，前記サービス・ＡＰ対照表から得られたＡＰの中から自分と相手の装置にある前記端末情報の内容をもとにどのＡＰを利用するかを決める利用ＡＰ調整手段，相手装置のＡＰ起動を依頼する相手ＡＰ起動手段，他の装置上のエージェントブロックと連携するための通信を行うエージェント間通信手段，および自装置のＡＰの起動・終了を制御するＡＰ制御手段を含むエージェントブロックと，
前記エージェントブロックが入力情報や格納情報を加工するための作業域ブロックを有している。
【００１７】
前記サービス・ＡＰ対照表は，利用者の指定したサービス名と起動すべきシナリオとアプリケーションとその格納の有無およびサービスの属性などとの対応関係を記述しており，利用者の指定したサービス名に対して起動すべきシナリオを選択するために用いられる。そして，端末情報は，使用している装置の資源情報を記述しており，またＡＰ情報リストは，本装置が起動することができるＡＰの動作条件を記述しており，ＡＰ相互関係表は，本装置内に格納されたＡＰの相互接続性を記述している。前記端末情報とＡＰ情報リストとＡＰ相互関係表は，前記利用ＡＰ調整手段により利用され，前記サービス・ＡＰ対照表において利用者が要求したサービスに対応する１つ以上のＡＰの中から１つのＡＰを選択するための情報として用いられる。
【００１８】
前記コミュニケーション装置において，
前記サービス情報格納手段，アプリケーション格納手段，ＡＰ情報格納手段，端末情報格納手段の一部または全てを本装置外のネットワークに配置し，ネットワークを通じてアクセス可能とした構成にすることもできる。この場合，アプリケーション提供者やサービス提供者などのコミュニケーションサービス利用者以外の第三者が，ネットワーク上の当該格納手段内の情報をアップデートすることにより，一度に複数の利用者に対して情報の追加・削除・変更を行うことが可能となる。
【００１９】
また，本発明に係るサービス制御方法は，前記エージェントブロックおよび予め定められたシナリオの記述内容に基づき当該エージェントブロックの提供するインタラクション手段およびリモートユーザインタラクション手段および利用ＡＰ調整手段および相手ＡＰ起動手段およびＡＰ制御手段を実行することによりユーザ間をまたがってサービスの開始から終了まで，一連のシナリオに従って利用者にサービスを提供する。
【００２０】
そのため，本発明に係るサービス制御方法は，例えば図９に示すように，利用者あるいはエージェントブロックからのサービス要求を受け付けるステップＳ１と，
サービス要求を解析し，対応するサービスシナリオを選択して作業域ブロックへ読み込むステップＳ２と，
コミュニケーション相手の意思確認を行うステップＳ３と，
双方の端末に予め格納された前記端末情報と前記サービス・ＡＰ対照表と前記ＡＰ情報リストを利用して，自分と相手の環境に応じたアプリケーションを選択するステップＳ４と，
自分と相手のサービスを行うために前記選択されたアプリケーションを相手装置上で起動するステップＳ５と，
前記選択されたアプリケーションの自装置上での起動・終了時処理を行うステップＳ６と，
前記ステップＳ３で合意が取れなかったときや前記ステップＳ４で適切なＡＰが無かったときや前記ステップＳ６で相手のＡＰを起動できなかったときには相手に対して代替手段による情報通知を行うシナリオを選択し実行要求するステップＳ７とを有し，
各ステップは，それぞれシナリオに実行指示があるかどうかを判断するステップとエージェントブロックの関連する手段を呼び出すステップと呼び出した結果を判断するステップを含むことを特徴とする。
【００２１】
本発明の作用を，図９の例に従って説明する。本発明のコミュニケーション装置およびサービス制御方法では，入出力手段を通してインタラクション手段により表示されたサービスメニューから，利用者が本コミュニケーション装置に対しサービス要求をすると，インタラクション手段は，会話相手などの必要な入力情報を利用者から取得した後，当該要求をサービス要求受付手段により受け付ける（ステップＳ１）。当該要求メッセージは，サービス解析手段に渡され，サービス解析手段は受け取ったメッセージからサービス名を特定し，サービス情報格納手段にあるサービス・ＡＰ対照表を用いてそのサービスを実現するシナリオを決定し，当該シナリオをシナリオ制御手段に渡す。そのとき同時に，サービス・ＡＰ対照表にあるＡＰ動作可否情報が可となっている同一シナリオＩＤを持つアプリケーション情報を作業域ブロックに読み込む（ステップＳ２）。
【００２２】
シナリオ制御手段は，シナリオに書かれた手順を順次実行する。まず，シナリオ中に意思確認手段呼び出しの記述がある場合には，エージェントブロックのリモートユーザインタラクション手段（以下，ＲＩ手段という）を呼び出す。呼び出されたＲＩ手段は，エージェント間通信手段により相手装置のエージェントブロックに意思確認要求メッセージを送信し，当該メッセージを受け取った受信装置側エージェントブロックは，インタラクション手段により受信側利用者にコミュニケーションの意思を確認し，結果を返却する（ステップＳ３）。
【００２３】
意思確認が取れれば，発信側のシナリオ制御手段は，双方の端末に予め格納された端末情報とサービス・ＡＰ対照表とＡＰ個別情報のリストとＡＰ相互関係表を利用してその動作条件や接続性を確認し，自分と相手の環境に応じたＡＰを選択する（ステップＳ４）。このとき，双方の装置に対し異なるＡＰが選択されることもある。
【００２４】
次に，相手ＡＰ起動手段を呼び出し，前記相手用に選択された相手のＡＰを指定して相手装置上で起動要求する（ステップＳ５）。要求側エージェントブロックの相手ＡＰ起動手段は，エージェント間通信手段を通して相手エージェントブロックに指定されたＡＰを起動するようメッセージを送信し，受信エージェントブロックは，ＡＰ制御手段により指定されたＡＰを起動し，その結果を返却する。
【００２５】
相手装置でのＡＰ起動が成功したときには，自装置用に選択されたＡＰを自装置上での起動することにより，要求されたコミユニケーションサービスが開始される（ステップＳ６）。
【００２６】
前記ステップＳ３で合意が取れなかったときや前記ステップＳ４で適切なＡＰが無かったときや前記ステップＳ５で相手のＡＰを起動できなかったときには，相手に対して代替手段による情報通知を行うシナリオを選択し実行要求する（ステップＳ７）。
【００２７】
以上から明らかなように，本発明によれば，利用者が要求したサービス内容に応じて関連するシナリオを自動選択し，サービスを実現するアプリケーションプログラムを自装置への格納状況や通信相手の装置の格納状況や動作環境条件に応じて自動的に選択を行うことができる。
【００２８】
また，通話開始者は，アプリケーションプログラムが利用する装置内のどこに格納されているかを意識せずにサービス開始できると同時に，通話相手の在／不在やＡＰの起動状況によらずコミュニケーションを開始したり代替手段を選択したりすることにより一連のサービスを享受できる。
【００２９】
また，エージェントブロックがユーザの状況やコミュニケーションのフェーズに応じてアプリケーションプログラムを自動起動するため送信者，受信者とも，ＡＰを意識的に起動せずにコミュニケーションサービスの開始ができる。
【００３０】
【発明の実施の形態】
以下，図を参照して本発明の実施の形態を説明する。
【００３１】
図１は，本発明に係るコミュニケーション装置の構成図であり，本発明を利用するユーザ１は，ＰＣ端末やＰＤＡ等のコミュニケーション装置３を介してインターネット等のネットワーク２に繋がる。
【００３２】
入出力手段５は，ユーザからのサービス要求を受け付けるためのキーボードやマウス，他ユーザからのサービスリクエストなどのインタラクションを表示するためのディスプレイやタッチパネルである。
【００３３】
通信手段６は，ネットワーク２を介して他ユーザとＴＣＰやＨＴＴＰプロトコル，またＨ．３２３やＳＩＰ等のマルチメディア通信用のプロトコルにて通信するために必要なモデムやＬＡＮ，無線ＬＡＮ等のインタフェース装置である。
【００３４】
アプリケーションブロック７は，本装置が提供するサービスの実施主体であるＮｅｔＭｅｅｔｉｎｇ（商標）やＣＵ−ＳｅｅＭｅ（商標）などのコミュニケーション用アプリケーションプログラム（ＡＰ）を実行するためのメモリ空間である。
【００３５】
ＯＳ８は，ユーザの端末操作や通信処理を制御するＷｉｎｄｏｗｓ（商標）やＭａｃＯＳ（商標），Ｌｉｎｕｘなどのオペレーティング・システム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）である。
【００３６】
ネームサーバ９は，本発明を利用するにあたって，コミュニケーション相手を指定する場合に，ネットワーク２上で相手を特定するための識別子（ＩＰアドレス）を調査する必要があり，その識別子を管理するデータベースである。ＤＮＳサーバやダイナミックＤＮＳサーバ等により実現する。
【００３７】
サービス情報格納手段２０は，サービス・ＡＰ対照表２１とサービスシナリオ２２〜２４とを少なくとも格納するデータベースである。サービス・ＡＰ対照表２１の一例を図２に示す。サービス・ＡＰ対照表２１は，サービスとそのサービスに対応するサービスシナリオ２２〜２４や本装置内に予め格納されたＡＰなどとの対応付けを行うテーブルである。
【００３８】
サービス・ＡＰ対応表２１は，具体的には，図２に示すように本システムが提供するサービス名（ＴＶ会議，ＴＶ電話，スケジュール予約，・・・ ）と，それと１対１に対応するサービスＩＤ，そのサービスで利用可能なアプリケーション名，それと１対１に対応するＡＰＩＤ，ＡＰの属性，サービスシナリオと１対１に対応するシナリオＩＤ，サービスシナリオの属性，およびＡＰの動作可否などの情報を保持する。ＡＰの動作可否欄以外は，各ユーザ端末毎に共通な内容であるが，ＡＰの動作可否欄については，各ユーザ端末毎にインストールされているＡＰが異なることから，各ユーザ毎に，実装／未実装／不明等を表す値が設定される。この例では，サービスＩＤとシナリオＩＤが１対１に対応しているように見えるが，同じサービスＩＤでも複数のシナリオＩＤが選択できるようになっていることもある。
【００３９】
また，サービスシナリオ２２〜２４は，本装置を通して提供するサービス毎に相手の意思確認ステップと利用するＡＰを調整するステップと互いの動作環境を整備するステップと自装置にＡＰを起動するステップの有無を選択記述することができることを特徴とするサービス記述情報である。
【００４０】
サービスシナリオ２２の一例を図３に示す。図３に示すサービスシナリオ２２は，ＴＶ会議シナリオ用の例であり，接続先のユーザリストの取得や相手の意志確認や利用ＡＰの選出や相手ＡＰの起動などの必要な実行項目，および代替手段として何を選択肢に挙げるかなどの条件が書き下されている。各ユーザ端末で配備されるが内容は共通である。
【００４１】
図３に示すサービスシナリオ２２の具体例に従って説明すると，このサービスシナリオ２２は，シナリオＩＤが１００であり，このシナリオでは，まず接続先ユーザＩＤリストを取得し，それぞれのユーザの接続意思を確認し，接続意思を確認できたならば，利用ＡＰを決定し，利用ＡＰの相手端末への起動依頼を行い，利用ＡＰの自端末での起動を行うことを指示している。接続意思確認に対して，相手からの拒否応答の場合には，ユーザへ代替手段の選択誘導を行い，代替手段として選択されたシナリオを起動し，無応答の場合には，シナリオＩＤが「１」のタイムアウトの固定メールを送信するシナリオを実行し，その後にシナリオを終了することを指示している。
【００４２】
代替手段のシナリオとして，シナリオＩＤが２００のスケール予約，シナリオＩＤが３００の電子メール，シナリオＩＤが４００のボイスメール等のシナリオが指定されている。他に，サービスシナリオに互いの動作環境を整備するステップを記述することも可能である。
【００４３】
端末情報格納手段３０は，本装置のＯＳ種別，ＣＰＵ速度，回線速度等の動作環境情報を記述した端末情報が格納されるデータベースである。端末情報格納手段３０に格納される端末情報３１の一例を図４に示す。端末情報３１は，コミュニケーション装置３毎に決まる情報であり，例えば図４に示すように，メモリサイズ，ＣＰＵ速度，回線種別，回線速度，ＯＳ，Ｗｅｂブラウザ種別等の情報名と，情報を一意に識別する情報ＩＤと，情報に対するいくつかの設定値とからなり，端末情報格納手段３０に格納される。情報名や情報ＩＤについては，各コミュニケーション装置３（ユーザ端末）に共通な項目であるが，設定される値は，各ユーザ端末毎に異なる。
【００４４】
作業域ブロック４は，メモリ等のような一時的なデータの保管場所である。作業域ブロック４に保管されるテーブルやリスト等のデータの例を図５に示す。作業域ブロック４には，イベントフラグ４１，ユーザの端末環境リスト４２，ＡＰ要求条件リスト４３，代替処理ユーザリスト４４，ＡＰ調整結果表４５，インストール状態調査結果表４６が格納され利用される。これらの詳細については後述する。
【００４５】
アプリケーション格納手段４０は，本装置が提供するサービスの実施主体であるＮｅｔＭｅｅｔｉｎｇ（商標）やＣＵ−ＳｅｅＭｅ（商標）等のコミュニケーション用アプリケーションプログラムであるＡＰＬ１やＡＰＬ２やＡＰＬ４の実体プログラムを格納する。
【００４６】
エージェントブロック１０は，ユーザからのサービス要求を受け付けるとともに，他ユーザからのサービスリクエストへの応答などのインタラクションを行うインタフェースを提供するインタラクション手段（ＨＭＩ）１１と，入出力手段５およびＯＳ８からの要求を受け付け，それをキューイングするイベント受付け手段１２と，当該要求に対してサービス・ＡＰ対照表２１をもとにサービス解析を行いサービス情報格納手段２０から適切なサービスシナリオを取り出すサービス解析手段１３と，そのサービスシナリオに従ってサービスを制御するシナリオ制御手段１９と，複数のユーザ間でサービスを開始するかどうかを意思確認するためのリモートユーザインタラクション（ＲＩ）手段１４と，複数のＡＰの中から自分と相手の装置に互いに適切なＡＰを選出する利用ＡＰ調整手段１５と，相手装置のＡＰ起動を依頼する相手ＡＰ起動手段１６と，他の装置上のエージェントブロックと連携するためにＦＩＰＡ（Ｆｏｕｎｄａｔｉｏｎ ｆｏｒ Ｉｎｔｅｌｌｉｇｅｎｔ Ｐｈｙｓｉｃａｌ Ａｇｅｎｔｓ）等のエージェント間通信プロトコルに準拠した通信を行うエージェント間通信手段１８と，自装置のＡＰの起動・終了を制御するＡＰ制御手段１７を含む。
【００４７】
ＡＰ情報格納手段５０は，ＡＰ毎のＡＰ名や対応プロトコルや要求スペック等のＡＰ個別情報が記載されたＡＰ情報リスト５２と，どのＡＰとどのＡＰとが互いに通信可能かを表すＡＰ毎の相性関係を記述したＡＰ相互関係表５１と，ユーザの端末環境がＡＰの要求するスペックを充たすかどうかを調べるための情報が記載される要求条件対応表５３を格納するデータベースである。
【００４８】
コミュニケーションＡＰ間の相互関係を表すＡＰ相互関係表５１の一例を図６に示す。ＡＰ相互関係表５１には，例えば図６に示すように，縦軸，横軸にそれぞれＡＰ一覧を並べ，各マスに縦横ＡＰの相性を，通信可能な推奨される組み合わせ，仕様上通信可能な組み合わせ，通信不可（もしくは不明）の組み合わせの３パターンを表す評価値を設定した情報が格納される。パターンは３つよりも少なくても多くても構わない。各ユーザ端末で配備されるが内容は共通である。
【００４９】
ＡＰ情報リスト５２の一例を図７に示す。ＡＰ情報リスト５２には，図７に示すように，各ＡＰ毎のアプリケーション名，ＡＰを一意に識別するＡＰＩＤ，対応プロトコルのタイプ，動作ＯＳ，動作に必要なメモリ量，必要回線スピード（必要帯域），サービスタイプ，起動パラメータ等のＡＰ個別情報が格納されている。同じ内容が本システムを所有するユーザ端末に備わる。
【００５０】
要求条件対応表５３は，各ユーザ端末で配備されるが内容は共通であり，具体例を図８に示す。要求条件対応表５３には，図８に示すように，ユーザの端末環境とＡＰの要求するスペックとの組み合わせが，十分であり推奨できる，標準的であり推奨できる，コマ落ちの可能性があるが可である，組み合わせは不可であるなどの情報が記載されている。
【００５１】
アドレス帳６０は，ネームサーバ９に登録されている，自分を含めてコミュニケーションサービスを行う相手（受信ユーザ）を表すユーザＩＤやＩＰアドレス（固定ＩＰを所有している場合），および氏名や電話番号等の個人情報が格納されているデータベースである。
【００５２】
図９は，コミュニケーション装置３がサービスを制御するフローチャートである。ステップＳ１は，ユーザ１もしくは自エージェントブロック１０内部からサービスの要求を受け付けるステップである。ステップＳ２は，サービス解析，シナリオ決定，アドレス解決を行うステップであり，詳細を図１０に示す。ステップＳ３は，コミュニケーション相手の意思確認を行うステップであり，詳細を図１１に示す。ステップＳ４は，ユーザ間で利用するＡＰを適切に選び出すためのステップであり，図１３に詳細を示す。ステップＳ５は，選択された相手のアプリケーションを指定して相手装置上で起動要求するステップであり，ステップＳ６は，自端末上で選択したＡＰを起動するステップであり，ともに詳細を図１５および図１６に示す。
【００５３】
ステップＳ７は，相手と合意が取れなかったときや，適切なＡＰが無かったときや，相手のＡＰを起動できなかったときに，相手に対して代替手段による情報通知を行うためのステップであり，詳細を図１７に示す。
【００５４】
以下，実際の処理の詳細な流れについて，発信ユーザＡが５人の受信ユーザ（Ｂ〜Ｆ）と，ＴＶ会議サービスを利用する場合のシーケンスを例に，図１０〜図１７を用いて順次説明する。
【００５５】
前提として，図１０〜図１７にある発信ユーザＡ，自エージェントＡとは，それぞれ図１におけるユーザ１，エージェントブロック１０を指す。また，図１のコミュニケーション装置３は，ネットワーク２を介して接続される本システムを所有する他のユーザでも所有しており，図１０の受信ユーザ（Ｂ〜Ｆ）は，それらのユーザを指し，相手エージェント（Ｂ〜Ｆ）は，それらのユーザのエージェントブロックを指す。
【００５６】
図１０は，サービス解析，シナリオ決定，アドレス解決の処理の流れであり，図９のステップＳ１，Ｓ２の詳細な処理手順の例を示している。
【００５７】
まず，自エージェントＡのイベント受付手段１２は，発信ユーザＡから少なくともサービスＩＤを含むサービス要求（コミュニケーション相手となる受信ユーザのユーザＩＤの入力もあり得る）を，入出力手段５，ＯＳ８，およびエージェントブロック１０内のインタラクション手段１１を介して，受け付ける（ステップＳ５１）。
【００５８】
要求を受け付けると，作業域ブロック４内のイベントフラグ４１を確認し，フラグが立っていなければフラグを立てる（ステップＳ５２）。以降，イベントフラグ４１は，サービスの多重受付や起動を抑止するために参照される。既にフラグが立っていれば，現在エージェントブロック１０にて，実行中のサービスがあるため新規起動ができない旨を発信ユーザＡに表示する。ここでは，実行中のサービスは無かった（イベントフラグは立っていなかった）ものとして説明を進める。
【００５９】
その後，イベント受付手段１２で受け付けた情報は，サービス解析手段１３に渡り，サービス解析手段１３は，サービス情報格納手段２０から，要求のあったサービスＩＤに対応するシナリオをサービスシナリオ２２〜２４の中から選出し，作業域ブロック４に読み込み，シナリオ制御手段１９に処理を渡す（ステップＳ５３）。ここでサービスシナリオは，本システム提供者によりサービス数に応じて増やすことが可能である。また，サービスＩＤに対応するシナリオが複数存在する場合には，発信ユーザＡに条件を提示し選択させることも可能である。
【００６０】
次に，シナリオ制御手段１９は，必要に応じて発信ユーザＡに対してインタラクション手段１１を介して相手のユーザＩＤの入力を促し，接続相手（受信ユーザ）数分のユーザＩＤの入力を受け付ける（ステップＳ５４）。なお，ステップＳ５１や後述するステップＳ１０５にて既にユーザＩＤを得ている場合には，このステップＳ５４の処理は不要である。
【００６１】
受信ユーザのＩＤを取得した後，サービスシナリオを参照し，接続相手（受信ユーザ）のアドレス種別が，メールアドレスなのかＩＰアドレスなのかを判定し（ステップＳ５５），アドレス帳６０もしくはネームサーバ９から，ユーザＩＤをもとに各受信ユーザのアドレスを取得する（ステップＳ５６）。
【００６２】
引き続き，相手エージェントに対し，エージェント間通信手段１８を介してシナリオＩＤと発信ユーザＩＤを送信しシナリオ通知を行い，相手エージェントからのシナリオ通知受付応答を受け取る（ステップＳ５７）。このステップＳ５７を相手エージェント数分繰り返し実行する（相手エージェントＢ〜Ｆ）。エージェントＡで全ての相手エージェントからのシナリオ通知受付応答を受信後，図１１の▲２▼（ステップＳ６１）に続く。
【００６３】
図１１は，意思確認の処理の流れであり，図９のステップＳ３の詳細な処理手順の例を示している。
【００６４】
自エージェントＡのシナリオ制御手段１９は，シナリオを参照し，意思確認処理の要否を判定し（ステップＳ６１），意思確認処理が必要な場合にはリモートユーザインタラクション手段１４に処理を渡し，不要な場合には図１３のステップＳ７１まで処理をスキップさせる。
【００６５】
意思確認処理が必要であった場合，リモートユーザインタラクション手段１４は，相手エージェントへエージェント間通信手段１８を介して発信ユーザＩＤ，シナリオＩＤを送信し，ＴＶ会議サービスへの参加要求を行い，相手エージェントからの参加要求応答（回答）を受け取り，結果をメモリ上に記憶しておく（ステップＳ６２）。このステップＳ６２を相手エージェント数分繰り返し実行する（相手エージェントＢ〜Ｆ）。
【００６６】
次に，自エージェントＡのシナリオ制御手段１９は，受信ユーザ（Ｂ〜Ｆ）が全員参加かどうかを判定し（ステップＳ６３），全員参加の場合には図１３のステップＳ７１まで処理をスキップし，不参加者がいる場合には，不参加者のユーザＩＤ，コミュニケーション不成立理由，コミュニケーションの試行回数を作業域ブロック４の代替処理ユーザリスト４４に記録する。図１１の例では受信ユーザＥが参加拒否，受信ユーザＦが不在による通信タイムアウトによりコミュニケーションが不成立となり，この情報を代替処理ユーザリスト４４に記述している（ステップＳ６４）。
【００６７】
代替処理ユーザリスト４４の例を図１２に示す。代替処理ユーザリスト４４には，図１２に示すように，コミュニケーションが不成立となった受信ユーザ毎に，ユーザＩＤと不成立理由と試行回数のリストが記述され，複数回試行している場合には，不成立理由がすべて列挙される。
【００６８】
ここで，受信ユーザが全員不参加かどうか判断し（ステップＳ６５），全員不参加であった場合には，図１７のステップＳ１０１までスキップする。一人でも参加者がいる場合には，図１３の▲３▼（ステップＳ７１）に続く。
【００６９】
図１３は，利用ＡＰの調整処理の流れであり，図９のステップＳ４の詳細な処理手順の例を示している。
【００７０】
自エージェントＡのシナリオ制御手段１９は，シナリオを参照し，利用ＡＰの調整処理の要否を判定し（ステップＳ７１），利用ＡＰの調整処理が必要な場合には利用ＡＰ調整手段１５に処理を渡し，不要な場合には図１５のステップＳ８１まで処理をスキップさせる。利用ＡＰの調整処理が必要であった場合，利用ＡＰ調整手段１５は，相手エージェントに対し，発信ユーザＩＤとシナリオＩＤを送信して情報要求を行い，受信ユーザの端末情報３１，サービス・ＡＰ対照表２１を取得する（ステップＳ７２）。このステップＳ７２を相手エージェント数分繰り返す。この例では，ステップＳ６４より，受信ユーザＥと受信ユーザＦが不参加となっているため，受信ユーザＢ，Ｃ，Ｄがコミュニケーション対象であり，相手エージェントＢ，Ｃ，Ｄに対してステップＳ７２を繰り返す。
【００７１】
次に，利用ＡＰ調整手段１５は，ステップＳ７２で収集した各受信ユーザのサービス・ＡＰ対照表２１，および発信ユーザＡのサービス情報格納手段２０から取得したサービス・ＡＰ対照表２１における，ＡＰの動作可否の列を参照し，各ユーザと各ユーザ端末で動作可能なＡＰとの対応表であるインストール状態調査結果表４６を自分（発信ユーザＡのコミュニケーション装置３内）の作業域ブロック４内に作成する（ステップＳ７３）。
【００７２】
作業域ブロック４内に作成したインストール状態調査結果表４６の例を，図１４に示す。インストール状態調査結果表４６には，それぞれのユーザごとに，インストール済みのＡＰの情報が格納される。
【００７３】
次に，利用ＡＰ調整手段１５は，コミュニケーション対象である受信ユーザＢ，Ｃ，Ｄと自分（発信ユーザＡ）との間で互いに利用可能な最適ＡＰを選択するため，選択条件を発信ユーザＡから入力してもらい，選択ポリシーや各種条件に従って決定する（ステップＳ７４）。なお，このステップＳ７４は，図１９の最適ＡＰ決定フローにて詳細に説明する。
【００７４】
次に，利用ＡＰ調整手段１５は，ステップＳ７４の結果，利用できるＡＰが無く，コミュニケーション対象から漏れた受信ユーザを代替処理ユーザリスト４４に追記する（ステップＳ７５）。また，それらの受信ユーザに対応する相手エージェントに対し，対応ＡＰが無い旨を通知する（ステップＳ７６）。
【００７５】
続いて利用ＡＰ調整手段１５は，ステップＳ７５の結果，コミュニケーション対象者が残っているかどうかを判断し，残っていれば処理を継続し，誰も残っていなければ，図１７のステップＳ１０１までスキップする（ステップＳ７７）。コミュニケーション対象者が残っている場合，図１５の▲４▼（ステップＳ８１）に続く。
【００７６】
図１５および図１６は，遠隔ＡＰ起動の処理の流れであり，図９のステップＳ５の詳細な処理手順の例を示している。
【００７７】
自エージェントＡのシナリオ制御手段１９は，シナリオを参照し，遠隔ＡＰ起動処理の要否を判定し（ステップＳ８１），遠隔ＡＰ起動処理が必要な場合には相手ＡＰ起動手段１６に処理を渡し，不要な場合には図１６のステップＳ８７まで処理をスキップさせる。
【００７８】
遠隔ＡＰ起動処理が必要であった場合，相手ＡＰ起動手段１６は，ステップＳ７４で決定した受信ユーザ側で起動するＡＰに必要な起動パラメータを，ＡＰ情報リスト５２から収集し（ステップＳ８２），必要に応じて，設定するパラメータ値の入力を発信ユーザＡに促し，パラメータ値を得る（ステップＳ８３）。この例の場合には，会議開催アドレスや会議名などである。
【００７９】
次に，相手ＡＰ起動手段１６は，ステップＳ７４で決定した受信ユーザ側の起動アプリケーションを表すＡＰＩＤおよびパラメータ値を付与して，相手エージェントに対しＡＰ起動要求を行い，相手エージェントから返却されたＡＰ起動要求応答（ＡＰ起動結果）をメモリ上に記憶する（ステップＳ８４）。
【００８０】
ステップＳ８２〜Ｓ８４までの処理をコミュニケーション対象の受信ユーザ分（Ｂ，Ｃ，Ｄ）だけ繰り返し，その後，各受信ユーザのＡＰ起動結果を参照し，全員正常起動かどうかを確認する（ステップＳ８５）。全員が正常起動であったなら図１６のステップＳ８９までスキップする。一人以上起動異常であれば，起動異常であった受信ユーザを代替処理ユーザリスト４４に追記する（ステップＳ８６）。
【００８１】
その後，図１６の▲５▼（ステップＳ８８）に続き，全員が起動異常であるかどうかを判断する。全員が起動異常であれば，図１７のステップＳ１０１までスキップする。一人以上，起動正常であれば，ステップＳ８９へと進む。なお，この例では全員正常起動として説明する。また，図１６のステップＳ８７では，シナリオを参照し，自端末で起動ＡＰを決定し，ステップＳ８９へと進む。
【００８２】
ステップＳ８９では，相手ＡＰ起動手段１６は，ステップＳ７４またはステップＳ８７で決定した自分（発信ユーザＡ）が使用するＡＰにて必要なパラメータをＡＰ情報リスト５２から取得し（ステップＳ８９），必要に応じて，設定するパラメータ値の入力を発信ユーザＡに促し，パラメータ値を得る（ステップＳ９０）。この場合には，会議開催アドレスや会議名などであり，ステップＳ８３で収集した情報と同じであるため，相手ＡＰ起動手段１６にてステップＳ８３で収集した情報を覚えておき，発信ユーザＡの入力を補完するようにしてもよい。
【００８３】
その後，相手ＡＰ起動手段１６は，入力されたパラメータ値をシナリオ制御手段１９に渡し，シナリオ制御手段１９は，該パラメータを用いて，ＡＰ制御手段１７を介して，アプリケーション格納手段４０にあるアプリケーションプログラム（例えばＡＰＬ２）を起動する（ステップＳ９１）。
【００８４】
ここで，本例においては，発信ユーザＡ，および受信ユーザＢ〜Ｄが所有するコミュニケーション用のＡＰが起動され，該ユーザ（Ａ，Ｂ，Ｃ，Ｄ）間でＴＶ会議サービスの準備が整ったこととなる。
【００８５】
その後，コミュニケーション対象に漏れた受信ユーザＥ，Ｆに対して，代替手段による情報通知を行うために，シナリオ制御手段１９は，図１７の▲６▼（ステップＳ１０１）の処理を続ける。
【００８６】
図１７は，代替処理の流れであり，図９のステップＳ７の詳細な処理手順の例を示している。
【００８７】
自エージェントＡのシナリオ制御手段１９は，代替処理ユーザリスト４４を参照し（ステップＳ１０１），代替処理ユーザリスト４４に登録されているユーザがいるかどうかを判断し（ステップＳ１０２），誰もいなければイベントフラグ４１をクリアし処理を終了する（ステップＳ１１２）。登録ユーザがいれば，ステップＳ１０３へ進む。
【００８８】
ステップＳ１０３では，現在実行中のシナリオを参照し，現在のサービスから続けることができる新たなサービス（代替処理）の候補を取得し，図１８に示すような代替選択画面１００に反映して発信ユーザＡに表示する。代替選択画面１００には，図１８に示すように，各ユーザＩＤ，不成立理由，試行回数，代替手段を選択するためのメニュー，実行ボタン等が表示される。この代替選択画面１００をもとに，発信ユーザＡに対し，実行ボタン１０１や代替手段選択メニュー１０２などより一人分のユーザＩＤと代替手段として実行するサービスＩＤの入力を促し（ステップＳ１０３），イベントフラグ４１のクリア，実行中のサービスシナリオの開放を行う（ステップＳ１０４）。
【００８９】
その後，発信ユーザＡから代替手段を行うユーザＩＤとサービスＩＤを取得し（ステップＳ１０５），該ユーザを代替処理リスト４４から削除し，代替選択画面１００を更新する（ステップＳ１０６）。その後，ステップＳ１０５で得たサービスＩＤとユーザＩＤをもとにイベント受付手段１２に対し新たなサービスの要求を行う（ステップＳ１０７）。
【００９０】
その後の処理については，ユーザＩＤ，サービスＩＤは異なるが，前述の流れと同様である。すなわち，シナリオ決定，アドレス解決の処理ステップＳ１０８（ステップＳ５２〜Ｓ５７），意思決定処理ステップＳ１０９（Ｓ６１〜Ｓ６５），利用ＡＰの調整処理ステップＳ１１０（Ｓ７１〜Ｓ７６），遠隔ＡＰ起動処理ステップＳ１１１（Ｓ８１〜Ｓ９１）を行い，その後にステップＳ１０１に戻る。
【００９１】
次に，上記の処理の流れにおける，相手エージェント側の処理の流れについて説明する。
【００９２】
図１０において，相手エージェントは，エージェントＡからのシナリオ通知のイベントを受け付ける（ステップＳ１５１）。この際，エージェントＡから相手エージェントへの信号の流れは，図１におけるネットワーク２を介して受信ユーザ側の通信手段６を経由し，ＯＳ８を経由し，エージェントブロック１０内のエージェント間通信手段１８を経由し，イベント受付手段１２に届くことになる。ここでイベントフラグ４１を設定し，以降，サービスの多重受付や起動を抑止するために参照する（ステップＳ１５２）。その後，エージェントＡに対してシナリオ通知受付応答を返却する（ステップＳ１５３）。このステップＳ１５１〜Ｓ１５３は，本例においては，受信ユーザＢ〜Ｆにおける相手エージェントＢ〜Ｆにて実施される。
【００９３】
図１１において，相手エージェントは，エージェントＡからの参加要求を受け付け，受信ユーザに対して参加確認画面を表示し，参加するかどうかの入力を促し，回答を得る（ステップＳ１６１）。その後，エージェントＡに対して，受信ユーザの回答を参加要求応答として返却する（ステップＳ１６２）。このステップＳ１６１〜Ｓ１６２は，本例においては，受信ユーザＢ〜Ｆにおける相手エージェントＢ〜Ｆにて実施される。また，受信ユーザＢ，Ｃ，Ｄは参加，受信ユーザＥ，Ｆは不参加（理由は拒否と不在）が返却される。その後，不参加を返却した場合には，イベントフラグ４１をクリアする（ステップＳ１６３）。
【００９４】
図１３において，相手エージェントは，エージェントＡからの情報要求を受け付け，受信ユーザ側のサービス情報格納手段２０からサービス・ＡＰ対照表２１を取得し（ステップＳ１７１），端末情報格納手段３０から端末情報３１を取得し（ステップＳ１７２），取得したサービス・ＡＰ対照表２１と端末情報３１をエージェントＡへ応答として送信する（ステップＳ１７３）。このステップＳ１７１〜Ｓ１７３は，本例においては，受信ユーザＢ，Ｃ，Ｄにおける相手エージェントＢ，Ｃ，Ｄにて実施される（受信ユーザＥ，Ｆについては，前述のとおり不参加であるため）。
【００９５】
また，利用ＡＰの調整の結果，使用可能なＡＰを持たないユーザのエージェントには，その旨の通知が自エージェントＡから通知される。それを契機に相手エージェントはイベントフラグ４１をクリアし（Ｓ１７４），受信ユーザに調整結果を通知する。
【００９６】
図１５において，相手エージェントは，エージェントＡからのＡＰ起動要求を受け付け，受信したパラメータをもとに受信ユーザ側のアプリケーション格納手段４０内のアプリケーションを起動する（ステップＳ１８１）。次に，アプリケーションの起動結果をＡＰ起動要求応答としてエージェントＡに返却する（ステップＳ１８２）。その後，作業域ブロック４内のイベントフラグ４１をクリアする（ステップＳ１８３）。
【００９７】
次に，図１３のステップＳ７４において，ある互いに利用可能な最適なＡＰを決定する処理フローを，図１９に従って詳細に説明する。
【００９８】
本例では，最適ＡＰを選択するために，ＡＰの要求条件と受信ユーザの端末環境との相性チェックの一例として，ＡＰが必要とする回線速度と各受信ユーザ端末の回線速度環境との整合性をチェックする。
【００９９】
具体的には，図７に示すＡＰ情報リスト５２における必要回線スピード欄，および図１４に示すインストール状態調査結果表４６を参照して，各受信ユーザが所有するＡＰの一覧（ＯＲ条件で作成）と各々のＡＰで必要とする帯域との対応を表すＡＰ要求条件リスト４３を作成する（ステップＳ３０１）。
【０１００】
図２０に，ここで作成したＡＰ要求条件リスト４３の例を示す。ＡＰ要求条件リスト４３を作成する際には，要求条件の高い順（より大きい値を必要とするＡＰの順）に並べる。この例では回線速度を例にしているが，ＡＰが対応するＯＳと，ユーザ端末のＯＳとの対応を表すようなＡＰ要求条件リストを作成する場合には，ＡＰを並べる順は特に気にしなくて良い。
【０１０１】
また，発信ユーザ，および受信ユーザの端末情報３１における回線速度欄を参照してその値を読み取り，各ユーザと各々の持つ端末の回線速度環境との対応を表すユーザの端末環境リスト４２を作成する（ステップＳ３０２）。図２１に，作成したユーザの端末環境リスト４２の例を示す。
【０１０２】
次に，ＡＰ要求条件リスト４３からＡＰ一覧を，またユーザの端末環境リスト４２からユーザ一覧を取得し，ユーザ数，ＡＰ数に応じたＡＰ調整結果表４５の雛型を作成する（ステップＳ３０３）。作成したＡＰ調整結果表（雛型）４５−１の例を図２２（Ａ）に示す。ここで，ＡＰ一覧は要求条件の高い順に左から右，あるいは上から下へ並べる。
【０１０３】
次に，インストール状態調査結果表４６を参照し，各ユーザがインストールしていないＡＰをＡＰ調整結果表に反映させる（ステップＳ３０４）。これは，図２２（Ｂ）に示すＡＰ調整結果表４５−２における網掛け（斜線）部に該当する。
【０１０４】
図２３に，本実施の形態におけるＡＰ調整結果表への格納イメージを示す。各ユーザがインストールしていないＡＰをＡＰ調整結果表４５に反映させる処理は，具体的には，図２３における４８個の配列のうち，前記網掛け部に該当する各配列の３つの要素［ｎ＝ａ，ｂ，ｃ］に無効を表す値“−１”を設定する作業である。なお，この配列は，ユーザＩＤ（ｉ＝１）と，ＡＰＩＤ（ｊ＝１〜４）と，相手ＩＤ（ｋ＝１〜３）と，相手ＡＰＩＤ（ｌ＝１〜４）とを添字とする配列である。ＡＰＩＤ（ｊ）と相手ＡＰＩＤ（ｌ）における１〜４というのは，ＡＰ調整結果表におけるＡＰ１〜ＡＰ４に相当する。また，相手ＩＤ（ｋ）における１〜３というのは，ユーザＢ〜ユーザＤに相当する。
【０１０５】
その後，ＡＰ相互関係表５１（図６）を参照しながら，残りのエリアにＡＰ仕様上の相性を格納していく。ＡＰ調整結果表４５における◎，○，△，×が仕様相性を表す（ステップＳ３０５）。例えば，ＡＰ調整結果表４５の縦軸ユーザＡのＡＰ１と横軸ユーザＢのＡＰ１が直交するマスに対しては，ＡＰ１とＡＰ１との相性をＡＰ相互関係表５１から調べ，評価値（◎）を記入する。同様にして他のマスに対して相性を記述する。この処理は，具体的には，図２３（Ａ）における４８個の各配列の要素［ａ］（仕様相性要素）７１に，評価値に対応する数値を，図２３（Ｂ）に示す評価値と数値の対応例に基づいて代入していく作業である。ただし，既に無効（−１）が設定されていた場合には何も設定しない。このＡＰ調整結果表４５に対する作業は，以降でも同様である。要素［ａ］への設定例を図２３（Ｃ）に示す。
【０１０６】
次に，ＡＰ要求条件リスト４３，ユーザの端末環境リスト４２，要求条件対応表５３（図８）を参照し，各端末と各ＡＰの必要条件の相性を記述し，ＡＰ調整結果表４５−３（図２４）を作成する（ステップＳ３０６）。例えば，ユーザＡの端末環境は，ユーザの端末環境リスト４２の欄４２１（図２１）から２Ｍと分かり，ＡＰ１の必要条件は，ＡＰ要求条件リスト４３の欄４３１（図２０）から１０Ｍと分かり，これらの情報を要求条件対応表５３に照らし合わせると，そのマス５３１（図８）の相性は“△”であることが分かる。この値を，ユーザＡのＡＰ１のマス４５ｃ（図２４）に設定する。
【０１０７】
同様な手順でＡＰ４まで繰り返し設定した結果が自端末相性欄４５ａである。また，同様に受信ユーザＢ〜ＤのＡＰ１〜ＡＰ４についても実施した結果が相手端末相性欄４５ｂである。具体的には，図２３における４８個の各配列の要素［ｂ］（自端末相性要素）７２，および，要素［ｃ］（相手端末相性要素）７３に対して，評価値に対応する数値を，図２３（Ｂ）に示す評価値と数値の対応例に基づいて代入していくことになる。要素［ｂ］，要素［ｃ］への設定例を，それぞれ図２３の（Ｄ），（Ｅ）に示す。
【０１０８】
ＡＰ調整結果表４５−２（図２２）における評価値と，ＡＰ調整結果表４５−３（図２４）における評価値（４５ａ，４５ｂ）をマージした形で表したＡＰ調整結果表４５−４のイメージを，図２５に示す。図２５のＡＰ調整結果表４５−４における各マスの３つの記号は，上段左が自端末相性，上段右が相手端末相性，下段が仕様相性をそれぞれ表している。
【０１０９】
次に，各受信ユーザにおいて，発信ユーザ端末の各ＡＰ毎に，最適なＡＰを選出する（ステップＳ３０７）。
【０１１０】
具体的には図２６のＡＰ調整結果表４５−５における，ゾーン４５ｄ〜ゾーン４５ｌの各ゾーン内で最適なＡＰを選出する。これらを選出する際の選択ポリシーは，図２７のフローとなる。
【０１１１】
ＡＰ選択ポリシーを図２７に従って説明する。まず，共通条件であるステップＳ３２１を実行した後，発信ユーザから入力のあった選択条件を参照し，ステップＳ３２２（ア）〜Ｓ３２２（ウ）の中からポリシーを決定し，それに従い各ゾーンの中から選出する。ここでは，選択条件を「（ア）安定性よりも画質を重視」のステップＳ３２２（ア）に従っている。その結果が図２６の９個の丸印４５ｍの付いたマスの配列の各要素（ａ：仕様相性，ｂ：自端末相性，ｃ：相手端末相性）である。
【０１１２】
次に，上記で決定した９個の丸印４５ｍの付いたマスの配列の各要素を選択ポリシーに照らし合わせて，発信ユーザＡのＡＰを選出する（ステップＳ３０８）。「（ア）安定性よりも画質を重視」のステップＳ３２２（ア）のポリシーに従った結果が，図２８の組み合わせ４５ｎである。すなわち，発信ユーザはＡＰ１，受信ユーザＢはＡＰ１，受信ユーザＣはＡＰ２，受信ユーザＤはＡＰ３となる。
【０１１３】
この他，選択条件を（イ）とした場合の結果を図２９，選択条件を（ウ）とした場合の結果を図３０に示す。それぞれ選択されたＡＰが選択条件によって異なることが分かる。
【０１１４】
本実施の形態においては，イベントフラグ４１を１つ利用し，あるサービス実行中は他のサービスは競合するものとして受け付けないようにしたが，サービス毎にイベントフラグを用意し，サービス毎の競合条件を加味しながらサービス起動を制御することで，同時に複数のサービス利用が可能となる。
【０１１５】
以上のエージェントブロック１０における各手段は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムはコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。
【０１１６】
【発明の効果】
以上の説明で明らかなように，本発明によれば以下の効果が得られる。
（１）プロトコルによらないサービスの選択が可能になる。
（２）異なるアプリケーションプログラムによるサービス開始が可能になる。
（３）サービス開始からサービス終了までの一連のサービスのナビゲーションにより円滑なコミュニケーションが可能になる。
（４）通信相手環境での事前起動を前提としない遠隔地間サービス開始が可能になる。
【０１１７】
以上により，相手方も同じコミュニケーション装置を利用していれば，サービスと相手を指定するだけで，自動的に最適な通信方法およびアプリケーションプログラムの選択および制御を行うことができ，利用者に負担の少ない円滑なコミュニケーションが実現できるようになる。
【図面の簡単な説明】
【図１】本発明に係るコミュニケーション装置の構成図である。
【図２】サービス・ＡＰ対照表の例を示す図である。
【図３】サービスシナリオ（ＴＶ会議サービス用）の例を示す図である。
【図４】端末情報の例を示す図である。
【図５】作業域ブロックの例を示す図である。
【図６】ＡＰ相互関係表の例を示す図である。
【図７】ＡＰ情報リストの例を示す図である。
【図８】要求条件対応表の例（回線速度編）を示す図である。
【図９】コミュニケーション装置によるサービスを制御するフローチャートである。
【図１０】ＴＶ会議サービスにおける図９のステップＳ２の例を示す図である。
【図１１】ＴＶ会議サービスにおける図９のステップＳ３の例を示す図である。
【図１２】代替処理ユーザリストの例を示す図である。
【図１３】ＴＶ会議サービスにおける図９のステップＳ４の例を示す図である。
【図１４】インストール状態調査結果表の例を示す図である。
【図１５】ＴＶ会議サービスにおける図９のステップＳ５，Ｓ６の例を示す図である。
【図１６】ＴＶ会議サービスにおける図９のステップＳ５，Ｓ６の例を示す図である。
【図１７】ＴＶ会議サービスにおける図９のステップＳ７の例を示す図である。
【図１８】代替選択画面（表示画面）およびＧＵＩの例を示す図である。
【図１９】互いに利用可能な最適なＡＰを決定する処理フローの例を示す図である。
【図２０】ＡＰ要求条件リストの例（回線速度編）を示す図である。
【図２１】ユーザの端末環境リストの例（回線速度編）を示す図である。
【図２２】ＡＰ調整結果表の例を示す図である。
【図２３】ＡＰ調整結果表への格納イメージを示す図である。
【図２４】ＡＰ調整結果表の例（その２）を示す図である。
【図２５】ＡＰ調整結果表の例（その３）を示す図である。
【図２６】ＡＰ調整結果表の例（選択条件（ア）その１）を示す図である。
【図２７】ＡＰ選択ポリシーの例を示す図である。
【図２８】ＡＰ調整結果表の例（選択条件（ア）その２）を示す図である。
【図２９】ＡＰ調整結果表の例（選択条件（イ））を示す図である。
【図３０】ＡＰ調整結果表の例（選択条件（ウ））を示す図である。
【符号の説明】
１ 本発明を利用するユーザ
２ ネットワーク
３ コミュニケーション装置
４ 作業域ブロック
５ 入出力手段
６ 通信手段
７ アプリケーションブロック
８ オペレーティング・システム（ＯＳ）
９ ネームサーバ
１０ エージェントブロック
１１ インタラクション手段
１２ イベント受付手段
１３ サービス解析手段
１４ リモートユーザインタラクション手段
１５ 利用ＡＰ調整手段
１６ 相手ＡＰ起動手段
１７ ＡＰ制御手段
１８ エージェント間通信手段
１９ シナリオ制御手段
２０ サービス情報格納手段
２１ サービス・ＡＰ対照表
２２〜２４ サービスシナリオ
３０ 端末情報格納手段
４０ アプリケーション格納手段
５０ ＡＰ情報格納手段
５１ ＡＰ相互関係表
５２ ＡＰ情報リスト
５３ 要求条件対応表

Claims (7)

1. ネットワークを介して接続される利用者の装置間で，利用可能な通信サービスを連携させるコミュニケーション装置であって，
   利用者との入出力インタフェースを持つ入出力手段と，
   ネットワークを通して相手装置と通信する通信手段と，
   利用者間の通信サービスに利用するアプリケーションプログラムを格納するアプリケーション格納手段と，
   本装置を通して提供するサービスにおいて相手の意思確認ステップと利用するアプリケーションプログラムを調整するステップと相互の動作環境を整備するステップと自装置のアプリケーションプログラムを起動するステップの有無を選択し記述することが可能であり，個々のステップの結果を以降のステップの入力として利用することができることを特徴とするサービス記述からなるサービスシナリオを格納するとともに，各サービスとそのサービスに対応する前記サービスシナリオや本装置内に予め格納されたアプリケーションプログラムとの対応付けを行うサービス・ＡＰ対照情報を格納するサービス情報格納手段と，
   本装置の動作環境情報を記述した端末情報を格納する端末情報格納手段と，
   本装置上でアプリケーションプログラムを起動するための条件を記述したＡＰ個別情報および複数のアプリケーションプログラム間の相互関係を記述したＡＰ相互関係情報を格納するＡＰ情報格納手段と，
   利用者のサービス要求を解析し，要求に対応するサービスシナリオを選択し，そのサービスシナリオに従って，相手の意思確認，通信サービスに利用するアプリケーションプログラムの選択，自装置および相手装置における前記選択したアプリケーションプログラムの起動制御を行うエージェントブロックと，
   前記エージェントブロックが入力情報や格納情報を加工するための作業域ブロックとを備える
   ことを特徴とするコミュニケーション装置。
2. 請求項１記載のコミュニケーション装置において，
   前記エージェントブロックは，
   前記入出力手段から利用者のサービス要求を受け付けるサービス要求受付け手段と，
   前記サービス要求について前記サービス・ＡＰ対照情報をもとに解析を行い，要求されたサービスに対応するサービスシナリオを選択するサービス解析手段と，
   サービスの解析結果に基づき，前記サービス情報格納手段から得られたサービスシナリオに従ってサービスを制御するシナリオ制御手段と，
   複数の利用者間でサービスを開始するかどうかを意思確認するためのリモートユーザインタラクション手段と，
   前記サービス・ＡＰ対照情報から得られたアプリケーションプログラムの中から自装置と相手装置にある前記端末情報の内容をもとにどのアプリケーションプログラムを利用するかを決める利用ＡＰ調整手段と，
   相手装置におけるアプリケーションプログラムの起動を依頼する相手ＡＰ起動手段と，
   他の装置上のエージェントブロックと連携するための通信を行うエージェント間通信手段と，
   自装置のアプリケーションプログラムの起動，終了を制御するＡＰ制御手段とを備える
   ことを特徴とするコミュニケーション装置。
3. 請求項１または請求項２記載のコミュニケーション装置において，
   前記サービス情報格納手段，前記アプリケーション格納手段，前記ＡＰ情報格納手段，前記端末情報格納手段の全てを，本コミュニケーション装置内に備える代わりに，前記サービス情報格納手段，前記アプリケーション格納手段，前記ＡＰ情報格納手段，前記端末情報格納手段の一部または全てを，本コミュニケーション装置外のネットワーク上の装置に配置し，それらの外部に配置された格納手段をネットワークを通じてアクセスする手段を備える
   ことを特徴とするコミュニケーション装置。
4. 各利用者の装置を通して提供するサービスにおいて相手の意思確認ステップと利用するアプリケーションプログラムを調整するステップと相互の動作環境を整備するステップと自装置のアプリケーションプログラムを起動するステップの有無を選択し記述することが可能であり，個々のステップの結果を以降のステップの入力として利用することができることを特徴とするサービス記述からなるサービスシナリオを，各利用者の装置が保持し，ネットワークを介して接続される利用者の装置間で，要求されたサービスに対応するサービスシナリオに基づいて利用可能な通信サービスを連携させるエージェントブロックにより利用者間の通信サービスを実現するサービス制御方法であって，
   利用者または前記エージェントブロックからのサービス要求を受け付ける過程と，
   サービス要求を解析し，対応するサービスシナリオを選択する過程と，
   前記サービスシナリオに基づき，相手の意思確認を行う過程と，
   自装置が持つアプリケーションプログラム情報および相手装置が持つアプリケーションプログラム情報と，自装置と相手装置の端末情報とをもとに，自装置と相手装置の動作環境に応じたアプリケーションプログラムを選択する過程と，
   通信サービスを行うために前記選択されたアプリケーションプログラムを相手装置上で起動する過程と，
   前記選択されたアプリケーションプログラムの自装置上での起動，終了制御を行う過程とを有する
   ことを特徴とするサービス制御方法。
5. 請求項４記載のサービス制御方法において，
   前記意思確認を行う過程で相手側の合意が得られなかったとき，または前記アプリケーションプログラムを選択する過程で，要求されたサービスを実現するためのアプリケーションプログラムが存在しなかったとき，または前記選択されたアプリケーションプログラムを相手装置上で起動する過程で，相手装置上でアプリケーションプログラムを起動できなかったときに，相手装置に対して要求されたサービスの代替手段による情報通知を行う所定のサービスシナリオを選択し，前記エージェントブロックにより，代替手段として選択したサービスシナリオに基づく処理を実行する過程を有する
   ことを特徴とするサービス制御方法。
6. 各利用者の装置を通して提供するサービスにおいて相手の意思確認ステップと利用するアプリケーションプログラムを調整するステップと相互の動作環境を整備するステップと自装置のアプリケーションプログラムを起動するステップの有無を選択し記述することが可能であり，個々のステップの結果を以降のステップの入力として利用することができることを特徴とするサービス記述からなるサービスシナリオを保持し，ネットワークを介して接続される利用者の装置間で，利用可能な通信サービスを前記サービスシナリオに基づいて連携させるコミュニケーション装置のコンピュータに実行させるためのエージェントプログラムであって，
   利用者からのサービス要求を受け付けるサービス要求受付け手段と，
   前記サービス要求に対して，要求されたサービスに対応する前記サービスシナリオや本装置内に予め格納されたアプリケーションプログラムとの対応付けを行うサービス・ＡＰ対照情報をもとにサービス解析を行うサービス解析手段と，
   前記要求されたサービスに対応するサービスシナリオに従ってサービスを制御するシナリオ制御手段と，
   複数の利用者間でサービスを開始するかどうかを意思確認するためのリモートユーザインタラクション手段と，
   前記サービス・ＡＰ対照情報から得られたアプリケーションプログラムの中から自装置と相手装置の動作環境に応じたアプリケーションプログラムを選択する利用ＡＰ調整手段と，
   相手装置におけるアプリケーションプログラムの起動を依頼する相手ＡＰ起動手段と，
   他の装置上のエージェントプログラムと連携するための通信を行うエージェント間通信手段と，
   自装置のアプリケーションプログラムの起動，終了を制御するＡＰ制御手段ととして，
   コンピュータを機能させるためのコミュニケーション装置のエージェントプログラム。
7. 各利用者の装置を通して提供するサービスにおいて相手の意思確認ステップと利用するアプリケーションプログラムを調整するステップと相互の動作環境を整備するステップと自装置のアプリケーションプログラムを起動するステップの有無を選択し記述することが可能であり，個々のステップの結果を以降のステップの入力として利用することができることを特徴とするサービス記述からなるサービスシナリオを保持し，ネットワークを介して接続される利用者の装置間で，利用可能な通信サービスを前記サービスシナリオに基づいて連携させるコミュニケーション装置のコンピュータに実行させるためのエージェントプログラムを記録したコンピュータ読み取り可能な記録媒体であって，
   利用者からのサービス要求を受け付けるサービス要求受付け手段と，
   前記サービス要求に対して，要求されたサービスに対応する前記サービスシナリオや本装置内に予め格納されたアプリケーションプログラムとの対応付けを行うサービス・ＡＰ対照情報をもとにサービス解析を行うサービス解析手段と，
   前記要求されたサービスに対応するサービスシナリオに従ってサービスを制御するシナリオ制御手段と，
   複数の利用者間でサービスを開始するかどうかを意思確認するためのリモートユーザインタラクション手段と，
   前記サービス・ＡＰ対照情報から得られたアプリケーションプログラムの中から自装置と相手装置の動作環境に応じたアプリケーションプログラムを選択する利用ＡＰ調整手段と，
   相手装置におけるアプリケーションプログラムの起動を依頼する相手ＡＰ起動手段と，
   他の装置上のエージェントプログラムと連携するための通信を行うエージェント間通信手段と，
   自装置のアプリケーションプログラムの起動，終了を制御するＡＰ制御手段ととして，
   コンピュータを機能させるためのコミュニケーション装置のエージェントプログラムを記録した記録媒体。

Images