JP2006244171A - 通信システムおよび方法、プログラム - Google Patents

Abstract

【課題】 送信側から送信されたメニュー生成情報に基いて受信側の表示手段に表示される操作メニューの構成やメニュー項目および表示順序やデザインを変更することができ、また、操作メニューの内容および表示の仕方を受信側にて変更することも可能な通信システムおよび方法、プログラムを提供する。
【解決手段】 通信端末は、通信相手から送信された識別子および状態に関するプレゼンス情報と、および通信相手が所望する操作メニューをメニュー表示手段への表示させるためのメニュー生成情報と、を受信して抽出するための相手先情報抽出手段と、操作メニューの表示に係る複数種類のテンプレートを記憶するためのテンプレート記憶手段と、相手先情報抽出部で抽出されたプレゼンス情報とメニュー生成情報に基いて、テンプレート記憶手段から対応するテンプレートを選択してメニュー表示手段へ提供するためのテンプレート情報提供手段と、を備える。
【選択図】 図１

Description

本発明は、相互通信における操作を選択および実行するための操作メニューの表示技術に係る通信システムおよび方法、プログラムに関する。

コンピュータの普及とともに、例えば携帯電話のように、使用者にとって直感的に理解しやすいグラフィカルユーザーインターフェースを使用することが可能な通信端末が増えてきた。ＩＰ電話の機能を実現するパーソナルコンピュータ（以下ＰＣと記載）はもちろんのこと、一部の非ＩＰ固定電話機もディスプレイを搭載しており、グラフィカルユーザーインターフェースを通して、使用者は端末操作を行うことができる。

このような通信端末のグラフィカルユーザーインターフェースとしては、選択肢の中から所望の操作をすることで端末操作を行うメニュー選択方式が一般的である。例えば従来のビジネスホン（登録商標）のような多機能電話では、使用者の操作対象である機能が割り付けられた多数のボタンが配置されており、例えば使用者が転送操作を行うためには、“転送”という機能を割り付けられたボタン押下を含む、決められた手順を使用者自身が覚える必要があった。

こうしたメニュー選択方式の利点は、実行可能な操作の一覧が使用者に提示され、その中から所望の操作を選択することにより、操作ごとに異なるボタン操作を覚える必要がないことである。

使用者の多様なニーズに応えるためには、多くの機能を通信端末に実装する必要がある。しかし、使用者ごとに頻繁に使用する機能はそれぞれ異なる。このことから、通信端末の多機能化に伴って、使用頻度が低く重要度が低いメニュー項目も増加してしまい、意図に反して逆に操作性を低下させてしまう、という問題を生ずる。そこで、メニュー項目の絞込み等の表示上の工夫が必要となる。例えば、端末使用者のユーザＩＤに基づいて操作メニューを最適なものに切替える方法が開示されている（特許文献１、特許文献２を参照）。
特開平５−３４６９０２号公報 特開平５−２０００６号公報

しかしながら、従来技術において実施されているような、通信端末の使用者（送信者）のユーザＩＤに基づく操作メニュー切替え方式では、通信相手（受信者）に関する情報が考慮されておらず、また、使用者が通信相手や通信相手の状態に合わせて操作メニューを提示することは困難であった。

また、従来技術におけるインスタントメッセンジャー（登録商標）などの実時間双方向通信アプリケーションにおいては、通信相手のプレゼンス情報（ＲＦＣ２７７８を参照）を参照することによって、例えば、通信相手がネットワークに現在接続されているか否かで、使用者に提示する通信手段をインスタントメッセンジャーか電子メールというように操作メニューを切替えている。

しかしながら、当該操作メニューの表示方式では、通信相手に合わせて提示する操作メニューを切替えることはなされておらず、通信相手を意識して使用者自身が操作メニューから所望する操作を選択しなければならなかった。

本発明は、上記の課題に鑑みてなされたもので、その目的とするところは、送信側から送信されたメニュー生成情報に基いて受信側の表示手段に表示される操作メニューの構成やメニュー項目および表示順序やデザインを変更することができ、また、操作メニューの内容および表示の仕方を受信側にて変更することも可能な通信システムおよび方法、プログラムを提供することにある。

上記の課題を解決するために、請求項１に記載の本発明は、自己の機能に係る操作メニューを表示するためのメニュー表示手段を備えた複数の通信端末同士でもって相互に通信可能な通信システムにおいて、前記通信端末は、通信相手から送信された識別子および状態に関するプレゼンス情報と、および前記通信相手が所望する操作メニューを前記メニュー表示手段への示させるためのメニュー生成情報と、を受信して抽出するための相手先情報抽出手段と、前記操作メニューの表示に係る複数種類のテンプレートを記憶するためのテンプレート記憶手段と、前記相手先情報抽出部で抽出されたプレゼンス情報と前記メニュー生成情報に基いて、前記テンプレート記憶手段から対応する前記テンプレートを選択して前記メニュー表示手段へ提供するためのテンプレート情報提供手段と、を備える。

また、請求項２に記載の本発明は、請求項１において、前記通信端末は、自己に係る、前記プレゼンス情報と、および前記メニュー生成情報と、を記憶するための自己情報記憶手段と、通信相手との通信時において前記自己情報記憶手段に記憶された前記プレゼンス情報と前記メニュー情報とを送信するための自己情報送信手段と、を備える。

また、請求項３に記載の本発明は、請求項１または２のいずれか１項において、前記通信端末は、前記通信相手の前記識別子に対応するメニュー生成情報と、およびその対応を決定するための対応関係情報と、を共に属性情報として記憶している属性情報記憶手段と、前記通信相手から送信されてきた前記プレゼンス情報に含まれる前記識別子に基いて前記属性情報記憶手段に記憶されたメニュー生成情報を取得するための変換情報取得手段と、を備える。

また、請求項４に記載の本発明は、請求項３において、前記属性情報記憶手段は、前記識別子と前記メニュー生成情報との関係を決定する前記対応関係情報を任意に変更するための対応関係情報変更手段を備える。

また、請求項５に記載の本発明は、請求項３または４のうちのいずれか１項において、前記通信端末は、前記通信相手の識別子と自己の操作履歴とを互いに関連付けて操作履歴情報として記憶するための操作履歴情報記憶手段と、前記操作履歴情報記憶手段に記憶された前記操作履歴情報に基いて前記属性情報を生成するための属性情報生成手段と、を備える。

また、請求項６に記載の本発明は、請求項４または５のうちのいずれか１項において、前記通信端末は、該通信端末の利用条件が定められたユーザグループ情報と、該ユーザグループ情報に所属するユーザグループを構成するユーザのユーザ情報と、を記憶するためのユーザ認証情報記憶手段と、前記ユーザグループごとに設定されたメニュー生成情報を記憶するためのグループ属性情報記憶手段と、通信相手であるユーザの識別子に基いて前記ユーザ認証情報記憶手段より該ユーザが所属する前記ユーザグループを特定し、そのユーザグループに対応するメニュー生成情報を割り当てるためのメニュー生成情報割当て手段と、を備える。

また、請求項７に記載の本発明は、自己の機能に係る操作メニューを表示するためのメニュー表示手段を備えた複数の通信端末同士でもって相互に通信可能な通信方法において、前記通信端末において、相手先情報抽出手段によって、通信相手から送信された識別子および状態に関するプレゼンス情報と、および前記通信相手が所望する操作メニューを前記メニュー表示手段への表示させるためのメニュー生成情報と、を受信して抽出するステップと、テンプレート記憶手段によって、前記操作メニューの表示に係る複数種類のテンプレートを記憶するステップと、テンプレート情報提供手段によって、前記相手先情報抽出部で抽出されたプレゼンス情報と前記メニュー生成情報に基いて、前記テンプレート記憶手段から対応する前記テンプレートを選択して前記メニュー表示手段へ提供するステップと、を有する。

また、請求項８に記載の本発明は、自己の機能に係る操作メニューを表示するためのメニュー表示手段を備えた複数の通信端末同士でもって相互に通信可能な通信プログラムにおいて、前記通信端末において、相手先情報抽出手段によって、通信相手から送信された識別子および状態に関するプレゼンス情報と、および前記通信相手が所望する操作メニューを前記メニュー表示手段への表示させるためのメニュー生成情報と、を受信して抽出するステップと、テンプレート記憶手段によって、前記操作メニューの表示に係る複数種類のテンプレートを記憶するステップと、テンプレート情報提供手段によって、前記相手先情報抽出部で抽出されたプレゼンス情報と前記メニュー生成情報に基いて、前記テンプレート記憶手段から対応する前記テンプレートを選択して前記メニュー表示手段へ提供するステップと、を有する。

また、請求項９に記載の本発明は、請求項８に記載の通信プログラムが、ネットワーク上に配置されたサーバにインストールして動作可能である。

本発明によれば、送信側から送信されたメニュー生成情報に基いて受信側の表示手段に表示される操作メニューの構成やメニュー項目および表示順序やデザインを変更することができ、また、操作メニューの内容および表示の仕方を受信側にて変更することも可能な通信システムおよび方法、プログラムを提供することができる。

本発明の実施の形態において、通信端末とは、複数の通信端末間で、音声情報や画像情報やテキスト情報等を含む種々のデータの送受信を実行し得る情報通信システムと、およびこの情報通信システム上で動作するアプリケーションソフトウェアを含んでいる。

こうした通信端末としては、少なくとも固定電話や携帯電話、およびインスタントメッセンジャー等の通信アプリケーションが動作可能なコンピュータなどの情報処理手段をも含んでいる。

＜第１の実施の形態＞
本実施の形態の構成図を図１に示し、以下、図５に示すフローチャートに沿って説明する。

まず、ステップＳ１において、通信相手側にある送信部（自己情報記憶手段）（自己情報送信手段）１が、当該通信相手の識別子とプレゼンス情報とメニュー生成情報を送信する。識別子は、ＳＩＰ−ＵＲＩ（ＲＦＣ３２６３参照）やメールアドレスやＩＰアドレスが使える。なお、独自のＩＤを使ってもよい。

プレゼンス情報は、通信相手の現在の状態を示す状態であり、「未接続中」「通信可能」「取込中」「退席中」「会議中」「通信中」等の状態を取りうる。

メニュー生成情報は、通信端末の使用者に提示するメニューカテゴリー、メニュー項目リスト、表示順序、通信端末の表示部における表示位置に関するレイアウト情報、背景色や文字の大きさおよび色等のデザイン情報、の任意の情報の組み合わせを含むか、同情報に対応するメニュー生成情報識別子（識別子）である。

また、メニュー生成情報識別子は文字列でもよいし、同情報が記述されたＷＷＷページへのＵＲＩのようなリンクであってもよい。本実施の形態では以下、メニュー生成情報としてメニュー生成情報識別子が送信された場合を扱う。

メニュー生成情報とメニュー生成情報識別子の関係は、例えば図６のようなテーブルで管理することができる。後述するメニューＤＢ部（テンプレート記憶手段）７にはこのような管理テーブルが含まれるが、通信相手の送信部１では必ずしもこのような管理テーブルを持つ必要はなく、メニューＤＢ部７上の管理テーブルに含まれる有効なメニュー生成情報識別子であればよい。

次に、ステップＳ２において、自分の通信端末の受信部２が、前ステップＳ１で送信された情報を受信する。

次に、ステップＳ３において、通信端末の抽出部（相手先情報抽出手段）３が、前ステップＳ２で受信された情報の中から、通信相手の識別子とプレゼンス情報がメニュー生成情報を抽出する。メニュー識別情報に関して、本実施の形態の場合は、メニュー生成情報識別子が抽出される。

次に、ステップＳ４において、加工部（テンプレート情報提供手段）４が、前ステップＳ２で抽出された通信相手の識別子とプレゼンス情報とメニュー生成情報をもとにして、メニューＤＢ部７にアクセスして、端末使用者に提示する操作メニューのテンプレートを取得してメモリ５に記憶する。メニューＤＢ部７には、図７に示すような、通信相手のプレゼンス情報とメニュー生成情報の組み合わせと、それに対応するメニューテンプレートが保持されている。

プレゼンス情報とメニュー生成情報の組み合わせに対して、メニューテンプレートが決まればよく、メニューテンプレート同士が同じものでもかまわない。例えば、どんなプレゼンス情報とメニュー生成情報の組み合わせに対しても、同じメニューテンプレートを対応されることも可能である。

また、メニューＤＢ部７は、通信端末の内部にあってもよいし、ネットワーク上の別の端末（サーバ等）にあっても構わない。各テンプレートは、メニュー生成情報に含まれる、通信端末の使用者に提示するメニューカテゴリー、メニュー項目リスト、表示順序、通信端末の表示部における表示位置に関するレイアウト情報、背景色や文字の大きさおよび色等のデザイン情報として具体的な値が定まった操作メニューのインスタンスである。

また、メニュー生成情報に合わせて、多様なテンプレートを対応させることができる。例えば、メニュー生成情報のカテゴリー情報として、「友人用メニュー」「家族用メニュー」「会社用メニュー」のいずれかを指定することで、「友人用メニュー」の場合はインスタントメッセンジャーの操作メニューを、「家族用メニュー」の場合にはテレビ電話の操作メニューを、「会社用メニュー」の場合はビジネスホン（登録商標）のような多機能電話の操作メニューが、それぞれ強調された操作メニューテンプレートを対応されること等が考えられる。

また、本実施の形態では、メニューのテンプレートを取得して、それを加工することで、最終的に端末使用者に提示する操作メニューを生成する構成を示すが、図８に示すような得られたメニュー生成情報をメニューＤＢ部７に保持し、操作メニューを一から組み立てる構成であってもよい。また、本例では、図７に示すように、通信相手のプレゼンス情報とメニュー生成情報からテンプレートを取得する形になっているが、プレゼンス情報とメニュー生成情報に加えて相手の識別子の組み合わせに対してテンプレートを対応される構成でもよい。

次に、ステップＳ５において、加工部４が、前ステップＳ４で取得した操作メニューのテンプレートを、最終的に通信端末の使用者に提示する操作メニューに加工する。加工の例としては、ステップＳ３で抽出されたプレゼンス情報を利用し、例えば通信相手が「取込中」であった場合には操作メニューの一部を表示しない、といったことが考えられる。

最後に、ステップＳ６において、表示部（メニュー表示手段）６が、前ステップＳ５でつくられた操作メニューを端末使用者に対して提示する。

なお、本第１の実施の形態のステップＳ１、Ｓ２（図５）における送信されてくるデータのフォーマットについて、以下に補足説明する。

ステップＳ１で通信相手が送信してくる、通信相手の識別子、プレゼンス情報、メニュー生成情報が含まれたデータのフォーマットの一例として、図１７に示すようなＰＩＤＦ（ＦＴＣ３８６３参照）を拡張したデータフォーマットが考えられる。

この図１７で、太字で示した部分は拡張した部分である。本フォーマットでは、通信相手の識別子として＜ｐｒｅｓｅｎｃｅ＞タグのｅｎｔｉｔｙ属性値を、プレゼンス情報として＜ｕｓｅｒ−ｓｔａｔｕｓ＞ノードを、メニュー生成情報として＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードをそれぞれ対応させることができる。

図１７には、メニュー生成情報の一例として、「ｇａｍｅ」と「ｍｅｓｓｅｎｇｅｒ」という２つのメニューカテゴリーが示されている。更に、「ｇａｍｅ」カテゴリーのメニュー項目の一例として「ｓｈｏｇｉ」が示されている。同ノード内にある＜ｃｏｎｔａｃｔ＞は、メニューカテゴリーもしくはメニュー項目を実行する場合に使用する通信相手のアドレスを示している。

なお、本第１の実施の形態は、メニュー生成情報が存在する場合であり、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードが存在している。

次に、本第１の実施の形態のステップＳ３（図５）における、通信相手の識別子、プレゼンス情報、メニュー生成情報の抽出について補足説明する。

ステップＳ３は、抽出部（図１の抽出部３）が、通信相手から送られてきたデータから、通信相手の識別子、プレゼンス情報、メニュー生成情報を抽出するステップである。通信相手から送られてきたデータが図１７に示したデータ形式である場合の本ステップの処理を図１８に示すフローチャートに沿って説明する。

ステップＳ６０において、抽出部は通信相手の識別子を取得する。本例では、＜ｐｒｅｓｅｎｃｅ＞タグのｅｎｔｉｔｙ属性値「ｐｅｅｒ＠ｅｘａｍｐｌｅ．ｎｅｔ」を、通信相手の識別子として取得する。

ステップＳ６１において、抽出部はプレゼンス情報を取得する。本例では、＜ｕｓｅｒ−ｓｔａｔｕｓ＞タグで示された文字列「ｆｒｅｅ」を、プレゼンス情報として取得する。

ステップＳ６２において、抽出部はメニュー生成情報が存在するかどうかを調べる。本例では、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードが存在するかどうかで判定する。存在する場合にはステップＳ６３を、存在しない場合にはステップＳ６４を実行する。本第１の実施の形態では、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードが存在するので、ステップＳ６３に進む。

ステップＳ６３において、抽出部はメニュー生成情報存在フラグをセットする。

ステップＳ６４において、抽出部はメニュー生成情報存在フラグをクリアする。

ステップＳ６５からステップＳ６７の処理は、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードに含まれる＜ｍｅｎｕ＞ノードごとに実行する。

ステップＳ６５において、抽出部はメニュー生成情報のメニューカテゴリー情報として＜ｍｅｎｕ−ｃａｔｅｇｏｒｙ＞タグで挟まれた値を取得する。本例では、「ｇａｍｅ」および「ｍｅｓｓｅｎｇｅｒ」が取得される。

ステップＳ６６において、抽出部はメニュー生成情報のメニュー項目情報として＜ｍｅｎｕ−ｉｔｅｍ＞タグで挟まれた値を取得する。本例では、「ｓｈｏｇｉ」が取得される。

ステップＳ６７において、抽出部はメニューカテゴリーまたはメニュー項目の付加情報として＜ｃｏｎｔａｃｔ＞タグで挟まれた値を取得する。本例では、「ｇａｍｅ：ｇａｍｅ＠ｅｘａｍｐｌｅ．ｎｅｔ」および「ｉｍ：ｉｍ＠ｅｘａｍｐｌｅ．ｎｅｔ」が取得される。

次に、本第１の実施の形態のステップＳ４（図５）における、メニューテンプレートの取得について補足説明する。

ステップＳ４において、加工部（図１の加工部４）は、プレゼンス情報とメニュー生成情報をキーにして、メニューＤＢ部（図１の６）にアクセスして、端末使用者に提示する操作メニューのテンプレートを取得し、メモリ５に記憶する。

図１９に、メニューＤＢに保持されているメニューテンプレートの例を２つ示す。同図において「＄｛・・・｝」と記述された部分は、変数に対応する部分であり、続くステップＳ５において、この部分に具体的な文字列や数値が挿入されることで、最終的に端末使用者に提示される操作メニューになる。

メニュー生成情報をもとにしてメニューテンプレートを選択する方法としては、例えば、メニューカテゴリーが一致するものを選択する方法が考えられる。一つのメニューカテゴリーに対して複数のメニューテンプレートが存在する場合には、更にメニュー項目などのメニュー生成情報を比較し、一致するメニューテンプレートを選択する方法が考えられる。

このような方法により、図１７のメニュー生成情報が与えられたときに、図１９に示すメニューテンプレートを選択されるようにすることができる。

次に、本第１の実施の形態のステップＳ５（図５）における、メニューテンプレートの加工について補足説明する。

ステップＳ５において、加工部（図１の加工部４）は、前ステップＳ４において取得されたメニューテンプレートを加工して、端末使用者に提示する操作メニューを生成する。メニューテンプレートは、一般的に、表示するメニュー項目や順番、フォントの種類や大きさ、背景色等に対して、具体的な文字列や数値が与えられていない不定部分が存在する操作メニューであり、本ステップにおいて、不定部分に対して具体的な文字列や数値を与えたり、一部のメニュー項目を隠したり、強調して表示する等の加工操作を行うが、不定部分が存在しないメニューテンプレートであれば、無加工のままユーザに提示することも可能である。

メニューテンプレートの加工処理の一例としては、図１７で与えられた通信相手の識別子およびメニュー生成情報を利用して、図１９で示したメニューテンプレートの不定分に具体的な文字列を埋めることが考えられる。図１８のステップＳ６５〜ステップＳ６７で取得したメニュー生成情報を利用することで、図２０に示すような操作メニューを生成することができる。

本例の図２０は、図１９左のメニューテンプレートの＄｛ｉｔｅｍ１｝に、ステップＳ６６で取得した「ｓｈｏｇｉ」に対応する「将棋」を挿入し、図１９右のメニューテンプレートの＄｛ｎａｍｅ｝に、ステップＳ６０で取得した「ｐｅｅｒ＠ｅｘａｍｐｌｅ．ｎｅｔ」を挿入し、上記２つのメニューテンプレートを統合することで生成された操作メニューである。

また、図２０では、＄｛ｉｔｅｍ２｝および＄｛ｉｔｅｍ３｝に対応する部分には、それぞれ「囲碁」「チェス」が挿入されているが、これらのメニュー項目は、メニュー生成情報に「将棋」のような指定がない場合に表示するカテゴリーごとのデフォルトのメニュー項目としてメニューＤＢに用意しておくとよい。

＜第２の実施の形態＞
本実施の形態は、通信相手から受信した情報の中に、メニュー生成情報を含まない場合のメニュー表示方式である。

本実施の形態の構成図を図２に示し、以下、図９に示すフローチャートに沿って説明する。通信相手から受信した情報の中にメニュー生成情報が含まれないことと、受信の通信相手の識別子を使ってメニュー生成情報を取得すること以外は第１の実施の形態と同じである。

まず、ステップＳ１０において、第１の実施の形態のフローチャートにおけるステップＳ１と同様に、通信相手側にある送信部１が、当該通信相手の識別子とプレゼンス情報を送信する。ただし、本実施の形態では、送信される情報の中にメニュー生成情報は含まれない。

次に、ステップＳ１１において、第１の実施の形態のフローチャートにおけるステップＳ２と同様に、自分の通信端末の受信部２が、前ステップＳ１０で送信された情報を受信する。

次に、ステップＳ１２において、第１の実施の形態のフローチャートにおけるステップＳ３と同様に、通信端末の抽出部３が、前ステップＳ２で受信された情報の中から、通信相手の識別子とプレゼンス情報とメニュー生成情報とメニュー生成情報の抽出処理を行う。本実施の形態は、メニュー生成情報が含まれていない場合を扱っているので、同情報は抽出されない。

次に、ステップＳ１３において、加工部４が、前ステップＳ１２において抽出された情報の中に、メニュー生成情報があるかどうかを調べる。本実施の形態では、メニュー生成情報は見つからないので、変換部（変換情報取得手段）９に通信相手の識別子を送信し、ステップＳ１４に続く。もし、メニュー生成情報が抽出されていればステップＳ１６に続く。

ステップＳ１４においては、変換部９が、加工部４から通信相手の識別子を受け取り、属性ＤＢ部（属性情報記憶手段）８にアクセスして、同識別子に対応するメニュー生成情報を取得（対応関係情報）し加工部４に送る。属性ＤＢ部８には、図１０に示すような、通信相手の識別子とメニュー生成情報の対応テーブルか、もしくは通信相手の識別情報とメニュー生成情報識別子の対応テーブルが保持されている。なお、変換部９および属性ＤＢ部８は通信端末の内部にあってもよいし、ネットワーク上の別の端末にあっても構わない。

ステップＳ１５においては、第１の実施の形態のフローチャートにおけるステップＳ４と同様に、加工部４が、通信相手の識別子とプレゼンス情報とメニュー生成情報をもとにして、メニューＤＢ部７にアクセスして、端末使用者に提示する操作メニューのテンプレートを取得する。

メニューＤＢ部７には、図７に示すような、通信相手のプレゼンス情報とメニュー生成情報の組み合わせと、それに対応するテンプレートメニューが保持されている。本実施の形態では、メニューのテンプレートを取得してそれを加工することで、最終的に端末使用者に提示する操作メニューを生成する構成を示すが、図８に示すような得られたメニュー生成情報をメニューＤＢ部７に保持し、操作メニューを一から組み立てる構成であってもよい。

また、本例では、図７に示すように、通信相手のプレゼンス情報とメニュー生成情報からテンプレートを取得する形になっているが、プレゼンス情報とメニュー生成情報に加えて相手の識別子の組み合わせに対してテンプレートを対応される構成でもよい（対応関係情報変更手段）。

次に、ステップＳ１６において、第１の実施の形態のフローチャートにおけるステップＳ５と同様に、加工部４が、前ステップＳ１５で取得した操作メニューのテンプレートを、最終的に通信短端末の使用者に提示する操作メニューに加工する。

最後に、ステップＳ１７において、表示部６が、前ステップＳ１６でつくられた操作メニューを端末使用者に対して提示する。

次に、第２の実施の形態のステップＳ１０、Ｓ１１（図９）における、送信されてくるデータのフォーマットについて補足説明する。

Ｓ１で通信相手が送信してくる、通信相手の識別子、プレゼンス情報、メニュー生成情報が含まれたデータのフォーマットの一例として、図１７に示すようなＰＩＤＦ（ＦＴＣ３８６３参照）を拡張したデータフォーマットが考えられる。

図１７で、太字で示した部分は拡張した部分である。本フォーマットでは、通信相手の識別子として＜ｐｒｅｓｅｎｃｅ＞タグのｅｎｔｉｔｙ属性値を、プレゼンス情報として＜ｕｓｅｒ−ｓｔａｔｕｓ＞ノードを、メニュー生成情報として＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードをそれぞれ対応させることができる。

図１７には、メニュー生成情報の一例として、「ｇａｍｅ」と「ｍｅｓｓｅｎｇｅｒ」という２つのメニューカテゴリーが示されている。更に、「ｇａｍｅ」カテゴリーのメニュー項目の一例として「ｓｈｏｇｉ」が示されている。同ノード内にある＜ｃｏｎｔａｃｔ＞は、メニューカテゴリーもしくはメニュー項目を実行する場合に使用する通信相手のアドレスを示している。

なお、本第２の実施の形態では、メニュー生成情報が存在しない場合であり、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードが存在しない。

次に、本第２の実施の形態のステップＳ１２（図９）における、通信相手の識別子、プレゼンス情報、メニュー生成情報の抽出について補足説明する。

ステップＳ３は、抽出部（図２の抽出部３）が、通信相手から送られてきたデータから、通信相手の識別子、プレゼンス情報、メニュー生成情報を抽出するステップである。通信相手から送られてきたデータが図１７に示したデータ形式である場合の本ステップの処理を図１８に示すフローチャートに沿って説明する。

ステップＳ６０において、抽出部は通信相手の識別子を取得する。本例では、＜ｐｒｅｓｅｎｃｅ＞タグのｅｎｔｉｔｙ属性値「ｐｅｅｒ＠ｅｘａｍｐｌｅ．ｎｅｔ」を、通信相手の識別子として取得する。

ステップＳ６１において、抽出部はプレゼンス情報を取得する。本例では、＜ｕｓｅｒ−ｓｔａｔｕｓ＞タグで示された文字列「ｆｒｅｅ」を、プレゼンス情報として取得する。

ステップＳ６２において、抽出部はメニュー生成情報が存在するかどうかを調べる。本例では、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードが存在するかどうかで判定する。存在する場合にはステップＳ６３を、存在しない場合にはステップＳ６４を実行する。本第２の実施の形態では、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードが存在しないので、ステップＳ６４に進む。

ステップＳ６３において、抽出部はメニュー生成情報存在フラグをセットする。

ステップＳ６４において、抽出部はメニュー生成情報存在フラグをクリアする。

ステップＳ６５からステップＳ６７の処理は、＜ｍｅｎｕ−ｈｉｎｔｓ＞ノードに含まれる＜ｍｅｎｕ＞ノードごとに実行する。

ステップＳ６５において、抽出部はメニュー生成情報のメニューカテゴリー情報として＜ｍｅｎｕ−ｃａｔｅｇｏｒｙ＞タグで挟まれた値を取得する。本例では、「ｇａｍｅ」および「ｍｅｓｓｅｎｇｅｒ」が取得される。

ステップＳ６６において、抽出部はメニュー生成情報のメニュー項目情報として＜ｍｅｎｕ−ｉｔｅｍ＞タグで挟まれた値を取得する。本例では、「ｓｈｏｇｉ」が取得される。

ステップＳ６７において、抽出部はメニューカテゴリーまたはメニュー項目の付加情報として＜ｃｏｎｔａｃｔ＞タグで挟まれた値を取得する。本例では、「ｇａｍｅ：ｇａｍｅ＠ｅｘａｍｐｌｅ．ｎｅｔ」および「ｉｍ：ｉｍ＠ｅｘａｍｐｌｅ．ｎｅｔ」が取得される。

次に、第２の実施の形態のステップＳ１３（図９）における、メニュー生成情報の存在の判定について補足説明する。

ステップＳ１３において、加工部（図２の加工部４）は、図１８のステップＳ６３もしくステップＳ６４で設定されたメニュー生成情報フラグを調べ、同フラグがセットされているならばステップＳ１４に進み、同フラグがクリアされているならばステップＳ１５に進む。

次に、第２の実施の形態のステップＳ１５（図９）における、メニューテンプレートの取得について補足説明する。

ステップＳ１５において、加工部（図２の加工部４）は、プレゼンス情報とメニュー生成情報をキーにして、メニューＤＢ部（図２のメニューＤＢ部７）にアクセスして、端末使用者に提示する操作メニューのテンプレートを取得する。

図１９に、メニューＤＢに保持されているメニューテンプレートの例を２つ示す。同図において「＄｛・・・｝」と記述された部分は、変数に対応する部分であり、続くステップＳ１６において、この部分に具体的な文字列や数値が挿入されることで、最終的に端末使用者に提示される操作メニューになる。

メニュー生成情報をもとにしてメニューテンプレートを選択する方法としては、例えば、メニューカテゴリーが一致するものを選択する方法が考えられる。一つのメニューカテゴリーに対して複数のメニューテンプレートが存在する場合には、更にメニュー項目などのメニュー生成情報を比較し、一致するメニューテンプレートを選択する方法が考えられる。

このような方法により、図１７のメニュー生成情報が与えられたときに、図１９に示すメニューテンプレートを選択されるようにすることができる。

次に、第２の実施の形態のステップＳ１６（図９）における、メニューテンプレートの加工について補足説明する。

ステップＳ１６において、加工部（図２の加工部４）は、前ステップＳ１５において取得されたメニューテンプレートを加工して、端末使用者に提示する操作メニューを生成する。メニューテンプレートは、一般的に、表示するメニュー項目や順番、フォントの種類や大きさ、背景色等に対して、具体的な文字列や数値が与えられていない不定部分が存在する操作メニューであり、本ステップにおいて、不定部分に対して具体的な文字列や数値を与えたり、一部のメニュー項目を隠したり、強調して表示する等の加工操作を行うが、不定部分が存在しないメニューテンプレートであれば、無加工のままユーザに提示することも可能である。

メニューテンプレートの加工処理の一例としては、図１７で与えられた通信相手の識別子およびメニュー生成情報を利用して、図１９で示したメニューテンプレートの不定分に具体的な文字列を埋めることが考えられる。図１８のステップＳ６５〜ステップＳ６７で取得したメニュー生成情報を利用することで、図２０に示すような操作メニューを生成することができる。

本例の図２０は、図１９左のメニューテンプレートの＄｛ｉｔｅｍ１｝に、ステップＳ６６で取得した「ｓｈｏｇｉ」に対応する「将棋」を挿入し、図１９右のメニューテンプレートの＄｛ｎａｍｅ｝に、ステップＳ６０で取得した「ｐｅｅｒ＠ｅｘａｍｐｌｅ．ｎｅｔ」を挿入し、上記２つのメニューテンプレートを統合することで生成された操作メニューである。

また、図２０では、＄｛ｉｔｅｍ２｝および＄｛ｉｔｅｍ３｝に対応する部分には、それぞれ「囲碁」「チェス」が挿入されているが、これらのメニュー項目は、メニュー生成情報に「将棋」のような指定がない場合に表示するカテゴリーごとのデフォルトのメニュー項目としてメニューＤＢに用意しておくとよい。

＜第３の実施の形態＞
本実施の形態は、操作メニュー作成に使用する情報として、２台以上の通信端末の識別子とプレゼンス情報とメニュー生成情報を利用する点のみが第２の実施の形態と異なる点である。

そこで本第２の実施の形態と同様に図２に示す構成図を用いて、以下、図１１に示すフローチャートに沿って説明する。

ステップＳ２０、ステップＳ２１の処理内容は、それぞれ第２の実施の形態のステップＳ１０、ステップＳ１１と同じであり、２台以上の通信端末の識別子とプレゼンス情報を受信部２で受信するところが異なる。本実施の形態では、Ｎ台の通信相手となる通信端末が存在している。

ステップＳ２２以降の処理で、Ｎ台分のメニュー生成情報を取得して、通信端末の使用者に提示する操作メニューをつくる。

ステップＳ２２において、抽出部３は、前ステップＳ２１で受信した情報の中に、未抽出の通信相手の識別子およびプレゼンス情報およびメニュー生成情報があるかどうかを調べる。あれば、ステップＳ２３に進む。なければ、ステップＳ２７に進む。最初にステップＳ２１から本ステップに遷移した場合には、Ｎ台分の未抽出情報がある。

ステップＳ２３においては、抽出部３は、未抽出情報のうち、１台分の通信相手の識別子とプレゼンス情報とメニュー生成情報の抽出処理を行う。

次にステップＳ２５において、加工部４は、ステップＳ２３で抽出された情報の中に、メニュー生成情報が存在するかどうかを調べる。存在するならば、ステップＳ２６に進む。存在しなければ、ステップＳ２４に進む。本実施の形態は、メニュー生成情報が存在しない場合を扱っているので、ステップＳ２４に進む。

ステップＳ２４においては、第２の実施の形態のステップＳ１４と同様に、変換部９が、加工部４から通信相手の識別子を受け取り、属性ＤＢ部８にアクセスして、同識別子に対応するメニュー生成情報を取得する。続いて、変換部９は、取得した情報を加工部４に渡す。

ステップＳ２６においては、加工部４は、ステップＳ２３で取得した通信相手の識別子とプレゼンス情報、ステップＳ２３もしくはステップＳ２４で取得したメニュー生成情報をメモリ５に蓄積し、ステップＳ２２に進む。

ステップＳ２７においては、第２の実施の形態と同様に、加工部４が、通信相手の識別子とプレゼンス情報とメニュー生成情報をもとにして、メニューＤＢ部７にアクセスして、端末使用者に提示する操作メニューのテンプレートを取得する。

ただし、複数台の通信相手のメニュー生成情報を扱う場合には、複数台のプレゼンス情報とメニュー生成情報の組み合わせごとに対応するメニューテンプレートをメニューＤＢ部７に保持する。

次に、ステップＳ２８においては、第２の実施の形態におけるステップＳ１６と同様に、加工部４が、前ステップＳ２７で取得した操作メニューのテンプレートを、最終的に通信短端末の使用者に提示する操作メニューに加工する。

最後に、表示部６がステップＳ２８でつくられた操作メニューを端末使用者に対して提示する。

＜第４の実施の形態＞
本実施の形態は、通信相手の識別子からメニュー生成情報を取得する方法として、通信端末の使用者の操作履歴情報を利用する点のみが第３の実施の形態にない部分である。

そこで、本実施の形態の構成図を図３に示し、第３の実施の形態にはない部分である、通信相手の識別子からメニュー生成情報を取得する方法として、通信端末の使用者の操作履歴情報を利用する部分、より具体的には属性ＤＢの構築方法を、図１２に示すフローチャートに沿って説明する。

なお、以下で、属性生成部（属性情報生成手段）１２および操作履歴ＤＢ部（操作履歴情報記憶手段）１１は、通信端末の内部にあっても、ネットワーク上の別の端末上にあっても構わない。

まず、ステップＳ３０で、操作入力部１０に対して端末使用者が操作を入力する。操作入力部１０は、入力された操作に対応する操作識別子とその操作とその時の通信相手の識別子を操作履歴ＤＢ部１１に記録する。

次に、ステップＳ３１において、属性生成部１２が、操作履歴ＤＢ部１１を参照し、操作履歴ＤＢ上に存在する各通信相手に対するメニュー生成情報を生成する。通信相手に対するメニュー生成情報の生成方法は多数考えられるが、メニュー生成情報としてメニューカテゴリーを得る一例を説明する。ここで言うメニューカテゴリーとしては、例えば、「友人向けメニュー」「家族向けメニュー」「職場向けメニュー」といったカテゴリーが考えられる。

本実施の形態では、メニューカテゴリーはＡとＢとＣの３つがあるとする。属性生成部１１は、各端末操作の各メニューカテゴリーに対する関連度を示す数値が入っている図１３に示すような関連度テーブルを参照して、操作履歴ＤＢ部１１に保持されている通信相手と端末操作の記録から、通信相手ごとに各メニューカテゴリー使用度を計算し、結果を図１４に示すようなテーブルに結果を得る。メニューカテゴリー使用度は、例えば、履歴ＤＢ上に記録されている操作ごとに、メニューカテゴリー関連度を足していくことで求めることができる。

最後に、ステップＳ３２において、属性生成部１２が、前ステップＳ３１で得られた各通信相手に対するメニュー生成情報を、属性ＤＢ部８に反映する。本実施の形態では、前ステップＳ３１で得た図１４に示すような通信相手ごとのメニューカテゴリー使用度を属性ＤＢ部８に反映する。例えば、通信相手に対して、最も使用度の高いメニューカテゴリーを当該通信相手に対応するメニュー生成情報に決めてもよいし、各メニューカテゴリー使用度を要素として持つベクトル値をメニュー生成情報としてもよい。

＜第５の実施の形態＞
本実施の形態は、通信相手の識別子からメニュー生成情報を取得する方法として、ユーザごとの端末利用条件等が管理されている認証データベースを利用する点のみが第３の実施の形態にない部分である。

そこで、本実施の形態の構成図を図４に示し、第３の実施の形態にはない部分である、通信相手の識別子からメニュー生成情報を取得する方法として、ユーザごとの端末利用条件等が管理されている認証データベースを利用する部分、より具体的には属性ＤＢの構築方法を、図１５に示すフローチャートに沿って説明する。

なお、以下で、属性生成部１２および認証ＤＢ部１３およびグループ属性ＤＢ部１４は、通信端末の内部にあっても、ネットワーク上の別の端末上にあっても構わない。

まず、ステップＳ４０で、属性生成部１２が、認証ＤＢ部１３にアクセスして、データベース上の全ユーザのリストと、各ユーザが所属するグループ（ユーザグループ）の情報（ユーザグループ情報）を取得する。

次に、ステップＳ４１において、属性生成部１２が、グループ属性ＤＢ部１４にアクセスして、各グループに対応するメニュー生成情報を取得する。

最後に、ステップＳ４２において、属性生成部１２が、ステップＳ４０で取得したユーザのリストを参照しながら、通信相手に対するメニュー生成情報を構築していく。生成するメニュー生成情報の例としては、「管理者向けメニュー」「一般ユーザ向けメニュー」等の実行に際して権限のチェックが必要になるようなメニューカテゴリーが考えられる。このようなメニューカテゴリーをメニュー生成情報として利用すると、権限が無い使用者に対しては不要なメニュー項目を隠すことが可能になるので、機密情報へのアクセスを制限することに役に立つ。

また、上記では、第３の実施の形態のステップＳ２４で変換部９が通信相手の識別子をもとにメニュー生成情報を取得するより前に、ステップＳ４０〜ステップＳ４２の処理で属性ＤＢが構築される例を示したが、以下に示すように、第３の実施の形態のステップＳ２４を、図１６に示すフローチャートに置き換えることで同様の動作を実現できる。

ステップＳ５０において、変換部９が、認証ＤＢ部（ユーザ認証情報記憶手段）１３にアクセスして、通信相手が所属するグループを調べる。

次に、ステップＳ５１において、変換部９が、グループ属性ＤＢ部（グループ属性情報記憶手段）１４にアクセスして、通信相手の所属グループに対応するメニュー生成情報を取得する。なお、通信相手の情報が認証ＤＢ上に無い場合にも対応するためには、所属グループがない通信相手のためのメニュー生成情報をグループ属性ＤＢ部１４に用意すればよい（メニュー生成情報割当て手段）。

このように、以上に説明した本発明の第１〜５の実施の形態においては、通信相手から一定の時間間隔もしくは通信相手の状態変化があった時もしくは自通信端末の要求時に送信されてくるプレゼンス情報に付加情報を追加している。

具体的には、通信相手の識別子および「取り込み中」や「退席中」や「会議中」や「電話中」等の通信相手の現在の状態に関するプレゼンス情報に加えて、メニュー生成情報を追加し、それらを受信する通信端末で操作メニュー生成に利用する構成をとる。

メニュー生成情報は、通信相手に合わせて操作メニューを端末の使用者に提示するための情報であり、操作メニューの表示方法を変化させるための情報として利用できるという点で従来のプレゼンス情報と同じであるが、更に、通信相手ごとに操作メニューの構成やメニュー項目の表示順序やデザインを変更することができる点と、操作メニューの内容および表示の仕方を通信相手が変更しうる点において異なる。

メニュー生成情報には、通信端末の使用者に提示するメニューカテゴリー、メニュー項目リスト、表示順序、通信端末の表示部における表示位置に関するレイアウト情報、背景色や文字の大きさおよび色等のデザイン情報、の任意の情報の組み合わせを直接記述するか、もしくは同情報の組み合わせと対応関係にある数字や文字列を使用して間接的に記述している。

数字や文字列などのメニュー生成情報識別子を使用してメニュー生成情報を間接的に記述する場合には、メニュー生成情報の送信者側端末と受信者側端末の間で、メニュー生成情報とそのメニュー生成情報識別子の対応関係を事前に共有する構成が、アクセス可能なネットワーク上のデータベースに同対応関係の情報保持し、同データベースを参照する構成により、送信者側端末が送信してきた上記のメニュー生成情報識別子を受信者側端末がメニュー生成情報に変換することができる。

なお、必ずしも上記のメニュー生成情報識別子を、メニューカテゴリー、メニュー項目リスト、表示順序、レイアウト情報、デザイン情報等のメニュー生成情報に変換する必要はない。

さらに、メニュー生成情報もしくはメニュー生成情報の識別子と、プレゼンス情報を利用して、通信端末の使用者に提示する操作メニューを作成する。操作メニューの作成には、通信相手からもたらされるメニュー生成情報をもとに毎回一から生成する方法でもよい。

あるいは、メニュー項目リスト、表示順序、通信端末の表示部における表示位置に関するレイアウト情報、背景色や文字の大きさおよび色等のデザイン情報として具体的な値を与えられたテンプレートをいくつか用意しておき、プレゼンス情報と操作メニュー生成情報をもとにテンプレートを選択して加工することで作成する方法でもよい。

なお、通信相手から受信した情報の中に、メニュー生成情報を含まない場合であっても、通信相手を特定できるメールアドレスやＳＩＰ−ＵＲＩなどの識別子をもとにして、メニュー生成情報を得てもよい。

なお、通信相手の識別子をもとにして得られたメニュー生成情報は、通信相手に対して固定的であり、明示的に同メニュー生成情報を与えない限り変化しないことから、通信相手の識別子をもとにして得られたメニュー生成情報は変化しない当該通信相手の一つの属性と考えることができる。また、属性という言葉は、通信相手の識別子をもとに得られたメニュー生成情報を指している。

また、本発明における属性生成手段の一つの例として、個々の通信相手に対する操作履歴を使用する方法を用いてもよい。この方法を採用した場合、操作履歴が残っていない通信相手に対してはメニュー生成情報を構築することができないので、そのような場合に対処するため、デフォルトのメニュー生成情報を用意しておくことが好ましい。

また、通信端末の使用に際して使用されている認証データベースを利用してもよい。この場合は、認証データベース上でユーザがグループという単位で管理されており、ユーザは少なくとも一つのグループに属していることが前提となる。

まず、認証データベースに登録されているグループそれぞれに対してメニュー生成情報を対応させ、通信相手のメニュー生成情報を得るためには、通信相手の属するユーザグループに対応するメニュー生成情報を読み出す構成をとる。

ユーザが２つ以上のユーザグループに属する可能性がある場合には、認証データベースに登録されているユーザグループの組み合わせそれぞれに対してメニュー生成情報を対応させ、通信相手のメニュー生成情報を得るためには、通信相手の属する１つ以上のユーザグループの組み合わせ対応するメニュー生成情報を読み出す構成をとる。

また、認証データベースに登録されていないユーザグループに対するメニュー生成情報も用意することで、通信相手が認証データベースに登録されていない場合にも対処することができる。

以上、本発明の実施の形態によれば、送信側から送信されたメニュー生成情報に基いて受信側の表示手段に表示される操作メニューの構成やメニュー項目および表示順序やデザインを変更することができ、また、操作メニューの内容および表示の仕方を受信側にて変更することも可能な通信システムおよび方法、プログラムを提供することができる。

本発明の通信システムの第１の実施の形態に係る、全体構成を説明するための構成図を示す。 本発明の通信システムの第２の実施の形態および第３の実施の形態に係る、全体構成を説明するための構成図を示す。 本発明の通信システムの第４の実施の形態に係る、全体構成を説明するための構成図を示す。 本発明の通信システムの第５の実施の形態に係る、全体構成を説明するための構成図を示す。 本発明の通信システムの第１の実施の形態に係る、動作を説明するためのフローチャートを示す。 本発明の通信システムの実施の形態に係る、メニュー生成情報識別子とメニュー生成情報の対応テーブルの一つの例を示す。 本発明の通信システムの実施の形態に係る、メニュー生成情報識別子とプレゼンス情報の組み合わせに対するメニューテンプレートの対応テーブルの一つの例を示す。 本発明の通信システムの実施の形態に係る、メニュー生成情報識別子とプレゼンス情報の組み合わせに対するメニューテンプレートの対応テーブルの一つの例を示す。 本発明の通信システムの第２の実施の形態に係る、動作を説明するためのフローチャートを示す。 本発明の通信システムの実施の形態に係る、通信相手の識別子とメニュー生成情報の対応テーブルの一つの例を示す。 本発明の通信システムの第３の実施の形態に係る、動作を説明するためのフローチャートを示す。 本発明の通信システムの第４の実施の形態に係る、属性ＤＢを構築する処理を説明するためのフローチャートを示す。 本発明の通信システムの実施の形態に係る、端末操作に対する各メニューカテゴリーの関連度を示すテーブルの一つの例を示す。 本発明の通信システムの実施の形態に係る、通信相手に対する各メニューカテゴリーの使用度を示すテーブルの一つの例を示す。 本発明の通信システムの第５の実施の形態に係る、属性ＤＢを構築する処理を説明するためのフローチャートを示す。 本発明の通信システムの第５の実施の形態に係る、通信相手の識別子からメニュー生成情報を取得する処理を説明するためのフローチャートを示す。 本発明の通信システムの第１および第２の実施の形態に係る、データフォーマットの一つの例を示す。 本発明の通信システムの第１および第２の実施の形態に係る、処理を説明するためのフローチャートを示す。 本発明の通信システムの第１および第２の実施の形態に係る、メニューテンプレートの一つの例を示す。 本発明の通信システムの第１および第２の実施の形態に係る、メニューテンプレートの一つの例を示す。

符号の説明

１ 送信部
２ 受信部
３ 抽出部
４ 加工部
５ メモリ
６ 表示部
７ メニューＤＢ部
８ 属性ＤＢ部
９ 変換部
１０ 操作入力部
１１ 属性履歴ＤＢ部
１２ 属性生成部
１３ 認証ＤＢ部
１４ グループ属性ＤＢ部

Claims (9)

1. 自己の機能に係る操作メニューを表示するためのメニュー表示手段を備えた複数の通信端末同士でもって相互に通信可能な通信システムにおいて、
   前記通信端末は、
   通信相手から送信された識別子および状態に関するプレゼンス情報と、および前記通信相手が所望する操作メニューを前記メニュー表示手段へ表示させるためのメニュー生成情報と、を受信して抽出するための相手先情報抽出手段と、
   前記操作メニューの表示に係る複数種類のテンプレートを記憶するためのテンプレート記憶手段と、
   前記相手先情報抽出部で抽出されたプレゼンス情報と前記メニュー生成情報に基いて、前記テンプレート記憶手段から対応する前記テンプレートを選択して前記メニュー表示手段へ提供するためのテンプレート情報提供手段と、
   を備えることを特徴とする通信システム。
2. 前記通信端末は、
   自己に係る、前記プレゼンス情報と、および前記メニュー生成情報と、を記憶するための自己情報記憶手段と、
   通信相手との通信時において前記自己情報記憶手段に記憶された前記プレゼンス情報と前記メニュー情報とを送信するための自己情報送信手段と、
   を備えることを特徴とする請求項１に記載の通信システム。
3. 前記通信端末は、
   前記通信相手の前記識別子に対応するメニュー生成情報と、およびその対応を決定するための対応関係情報と、を共に属性情報として記憶している属性情報記憶手段と、
   前記通信相手から送信されてきた前記プレゼンス情報に含まれる前記識別子に基いて前記属性情報記憶手段に記憶されたメニュー生成情報を取得するための変換情報取得手段と、
   を備えることを特徴とする請求項１または２のいずれか１項に記載の通信システム。
4. 前記属性情報記憶手段は、
   前記識別子と前記メニュー生成情報との関係を決定する前記対応関係情報を任意に変更するための対応関係情報変更手段
   を備えることを特徴とする請求項３に記載の通信システム。
5. 前記通信端末は、
   前記通信相手の識別子と自己の操作履歴とを互いに関連付けて操作履歴情報として記憶するための操作履歴情報記憶手段と、
   前記操作履歴情報記憶手段に記憶された前記操作履歴情報に基いて前記属性情報を生成するための属性情報生成手段と、
   を備えることを特徴とする請求項３または４のうちのいずれか１項に記載の通信システム。
6. 前記通信端末は、
   該通信端末の利用条件が定められたユーザグループ情報と、該ユーザグループ情報に所属するユーザグループを構成するユーザのユーザ情報と、を記憶するためのユーザ認証情報記憶手段と、
   前記ユーザグループごとに設定されたメニュー生成情報を記憶するためのグループ属性情報記憶手段と、
   通信相手であるユーザの識別子に基いて前記ユーザ認証情報記憶手段より該ユーザが所属する前記ユーザグループを特定し、そのユーザグループに対応するメニュー生成情報を割り当てるためのメニュー生成情報割当て手段と、
   を備えることを特徴とする請求項４または５のうちのいずれか１項に記載の通信システム。
7. 自己の機能に係る操作メニューを表示するためのメニュー表示手段を備えた複数の通信端末同士でもって相互に通信可能な通信方法において、
   前記通信端末において、
   相手先情報抽出手段によって、通信相手から送信された識別子および状態に関するプレゼンス情報と、および前記通信相手が所望する操作メニューを前記メニュー表示手段への表示させるためのメニュー生成情報と、を受信して抽出するステップと、
   テンプレート記憶手段によって、前記操作メニューの表示に係る複数種類のテンプレートを記憶するステップと、
   テンプレート情報提供手段によって、前記相手先情報抽出部で抽出されたプレゼンス情報と前記メニュー生成情報に基いて、前記テンプレート記憶手段から対応する前記テンプレートを選択して前記メニュー表示手段へ提供するステップと、
   を有することを特徴とする通信方法。
8. 自己の機能に係る操作メニューを表示するためのメニュー表示手段を備えた複数の通信端末同士でもって相互に通信可能な通信プログラムにおいて、
   前記通信端末において、
   相手先情報抽出手段によって、通信相手から送信された識別子および状態に関するプレゼンス情報と、および前記通信相手が所望する操作メニューを前記メニュー表示手段への表示させるためのメニュー生成情報と、を受信して抽出するステップと、
   テンプレート記憶手段によって、前記操作メニューの表示に係る複数種類のテンプレートを記憶するステップと、
   テンプレート情報提供手段によって、前記相手先情報抽出部で抽出されたプレゼンス情報と前記メニュー生成情報に基いて、前記テンプレート記憶手段から対応する前記テンプレートを選択して前記メニュー表示手段へ提供するステップと、
   を有することを特徴とする通信プログラム。
9. 請求項８に記載の通信プログラムは、ネットワーク上に配置されたサーバにインストールして動作可能なことを特徴とする通信プログラム。

Images