JP2006134128A

JP2006134128A - コンタクト情報管理装置およびコンタクト情報管理方法

Info

Publication number: JP2006134128A
Application number: JP2004323245A
Authority: JP
Inventors: Kenya Nishiki; 健哉西木; Erika Tanaka; 英里香田中
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-11-08
Filing date: 2004-11-08
Publication date: 2006-05-25
Anticipated expiration: 2024-11-08
Also published as: US20060165106A1; JP4541841B2; CN100521614C; CN1773926A

Abstract

【課題】認証されたユーザに特定のアドレスを公開することが可能な、安全かつ円滑にコミュニケーションを行う技術を提供することを目的とする。
【解決手段】コミュニティの参加者のみに、コミュニティメンバのコンタクトアドレスを開示するコンタクト情報管理装置とする。このコンタクト情報管理装置は、位置検出手段を設けた携帯端末から、位置情報を収集し、携帯端末の位置情報に基づいてコンタクトアドレスを、開示することも可能である。また、コンタクトアドレスのデータベースはコミュニティごとに作成する。
【選択図】図２

Description

本発明は、ユーザのコンタクト情報を管理する技術に関し、特にユーザ参加コミュニティ、所在、サービスに適した通信を行うためのアドレス情報を提供する技術に関する。

近年、ネットワークサービスを時間や場所の制約なく利用できるようになり、不特定多数のユーザがサービスを利用するようになった。一方、同種のサービスであっても利用目的や場所に応じて複数の端末（アドレス）を使い分けており、通信したい相手のアドレスを通信開始時に取得し、相手の状況に応じて選択する必要がある。また、不特定多数の相手にアドレスが公開されると、迷惑電話やスパムメールの問題が生じやすい。従って、利用者のプライバシを確保しながらユーザ同士が、相手のアドレスを容易に検索してコミュニケーション可能なシステムが必要とされている。

コミュニケーションを円滑化するためにユーザに現在コンタクト可能かどうかをオンラインで状態把握することが考えられるが、そのための技術としては、特許文献１において端末選択方法が提案されている。特許文献１に記載の発明は、マルチメディア通信が可能な二つ以上の端末と、端末を使用するユーザの情報を記憶するユーザ情報記憶手段と、端末に関する情報を記憶する端末情報記憶手段と、端末にて利用可能な１以上のコミュニケーションメディアの空塞状態を記憶するメディア情報記憶手段からなるマルチメディアコミュニケーションシステムにおいて、ユーザの動的な状況に応じてユーザの空塞状態を変更することによって、常に空き端末を選択できるようにするものである。

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

背景技術で述べた端末選択方法は、ユーザが同時に複数の端末を使用可能な場合にのみ空き端末に接続できるようにするという発信する側の利便性向上を目的としており、受信するユーザが望む手段でアクセスさせるための選択方法は提供されていない。また、発信ユーザによってコンタクト情報へのアクセス可否をコントロールすることも考慮されていない。

本発明は、認証されたユーザに特定のアドレスを公開することが可能な、安全かつ円滑にコミュニケーションを行う技術を提供することを目的とする。
また、同種のサービスで複数のアドレスを有するユーザに対して、どの通信手段を利用できるエリアにいるかを判断して最適なアドレスを選択させる。

上記目的を達成するために、コミュニティの参加者のみに、コミュニティメンバのコンタクトアドレスを開示するコンタクト情報管理装置とする。このコンタクト情報管理装置は、位置検出手段を設けた携帯端末から、位置情報を収集し、携帯端末の位置情報に基づいてコンタクトアドレスを、開示することも可能である。また、コンタクトアドレスのデータベースはコミュニティごとに作成する。

本発明によれば、サービス利用者が複数のアドレスを有している場合に、適切なアドレスに接続させることができる。また、コミュニティの参加者のみにアドレスを公開することができるので、プライバシを保護し迷惑電話やスパムメールを防止することができる。さらに、利用者が所属するコミュニティ毎に公開するアドレスを変えることができる。

本発明の実施の形態について図面を参照しながら実施例を用いて、以下詳細に説明する。以下の実施例は、職場、家庭など場所に応じて複数のコンタクト手段を提供するコミュニケーションサービスに適用した場合を例に説明する。

本発明の実施例１を図１ないし図１３を用いて説明する。ここで、図１は、本発明の実施例のコミュニケーションシステムの構成図である。図２は、本発明の実施例のコンタクト情報管理装置の機能ブロック図である。図３は、コンタクト情報管理装置の各機能ブロックのハードウェア構成を示すブロック図である。図４は、コミュニティ登録手順を説明するシーケンス図である。図５は、コミュニティ参加登録の動作フロー図である。図６は、コミュニティ会員情報データベースのテーブルである。図７は、アドレス選択ポリシデータベースのテーブルである。図８は、資格情報を説明する図である。図９は、コンタクト情報問合せのシーケンス図である。図１０は、位置情報取得部の動作フロー図である。図１１は、情報検索部の動作フロー図である。図１２は、セッション確立の動作フロー図である。図１３は、携帯端末の画面表示を説明する図である。

図１に戻って、VoIPサービスプロバイダ300は、コンタクト情報管理装置310およびVoIPサーバ311をインターネットであるＷＡＮ360に接続している。コミュニティ管理者X、コミュニティメンバY、コミュニティメンバZはRFIDタグ20が装着された携帯端末342、322、352を所持している。利用場所である自宅320、オフィス330の自席340、会議室350は、ＷＡＮ360に接続されており、それぞれの場所にRFIDタグを読み取ってコンタクト情報管理装置310に送信可能な位置リーダ10が設置されている。なお、RFIDタグと位置リーダが離れている場合は、自らの電源で駆動して電波を受発信するアクティブ型ＲＦＩＤタグや、UHF帯の電波を利用する使用のＲＦＩＤタグを用いる。

コンタクト情報管理装置310は、図２に示すような機能ユニットにより構成される。すなわち、外部の位置リーダから端末の位置情報を収集して管理する位置情報取得部102、ユーザ端末からリクエストを受け付けて処理を振り分け、処理結果を応答するユーザインターフェース部101、コミュニティメンバの電話番号やメールアドレス・ＵＲＬ等のコンタクト情報を登録するコンタクト情報登録部103、コミュニティメンバのアドレス情報を選択する条件を設定するアドレス選択ポリシ設定部105、コミュニティメンバのコンタクト情報をアドレス選択ポリシに基づいて検索するコンタクト情報検索部104、プロキシを経由して各種サーバを呼び出すプロキシ呼出し部110、ＶｏＩＰサーバ311を呼び出すＶｏＩＰプロキシ111、メールサーバ122を呼び出すメールプロキシ112、Ｗｅｂサーバ123を呼び出すＷｅｂプロキシ113、コミュニティ会員情報データベース106、アドレス選択ポリシデータベース107で構成される。

図３は本システムに用いるハードウェア構成図である。図２に示したコンタクト情報管理装置100の各機能ユニット（ユーザインターフェース部101、位置情報取得部102、コンタクト情報登録部103、コンタクト情報検索部104、アドレス選択ポリシ設定部105、プロキシ呼出し部110、ＶｏＩＰプロキシ111、メールプロキシ112、Ｗｅｂプロキシ113）は、ＣＰＵ201、メモリ202、入出力インターフェース203、表示装置204、入力装置205、記憶装置206、ネットワーク装置207、のハードウェアを搭載したコンピュータ上に構築することができる。この場合、コンタクト情報管理プログラム200は、メモリ202に読み込まれ、実行時にプロセスとして起動される。また位置リーダ10、VoIPサーバ121、メールサーバ122、Webサーバ123、ユーザ端末322、352、ＷＡＮ360等外部のシステム208とはネットワーク装置207を介して接続される。

コンタクト情報を共有するコミュニティの新規作成およびメンバの登録に関する処理を図４のシーケンス図を用いて説明する。
まず、コミュニティ管理者Xは、その端末342からコンタクト情報管理装置310に新規コミュニティ作成要求メッセージを送る（T401）。指定されたコミュニティＩＤのコミュニティが作成されると、コミュニティ管理者にＯＫメッセージ、作成できない場合はＮＧメッセージが返される（T402）。コミュニティ管理者は、メール等の手段で、コミュニティ開設をコミュニティメンバ候補者に公告する。コミュニティメンバ候補者のうち参加希望者Ｗがその端末420から、コミュニティへの参加要求メッセージをコンタクト管理装置310に送ると（T403）、コミュニティ管理者Xに対して参加要求を出したユーザの参加許可を問合せるメッセージが送られる（T404）。管理者Xは参加を許可するか不許可にするかを応答する（T405）。コンタクト情報管理装置310は管理者Xからの応答を受けて参加要求を出した希望者に参加OKメッセージ、あるいはNGメッセージを送る（T406）。参加OKを受け取った希望者は、後述するコンタクトに必要なアドレス情報、アドレス選択ポリシ、端末に装着されているタグのIDなどをコンタクト情報管理装置310に送る（T407）。前記コンタクト情報の登録が完了すると、参加要求を出した希望者にコミュニティメンバであることを証明する資格情報が送られる（T408）。資格情報の詳細は図８に譲るが、電子署名を付与することによって、資格情報の正当性がチェックできる。

図５は、コンタクト情報管理装置310のコンタクト情報登録部103およびアドレス選択ポリシ設定部105の動作を説明するフローチャートである。まず、ユーザからの参加要求があると、コミュニティ管理者にユーザの参加許可を問い合わせ（S601）、管理者から参加許可の応答が得られた場合は（S602）、ユーザからのコンタクトに必要なアドレス情報、アドレス選択ポリシ、端末に装着されているタグのIDなどの送信を受けて、コミュニティ会員情報データベース106にこのユーザのコンタクト情報を追加し（S603）、アドレス選択ポリシデータベース107にアドレス選択条件を設定する（S604）。管理者から参加不許可の応答があった場合はユーザにその旨を通知する（S605）。
なお、コンタクトに必要なアドレス情報、アドレス選択ポリシ、端末に装着されているタグのIDなどに変更が生じた場合は、図５と同様な手順で、管理者に変更許可を申請することで、対応できる。

ここで、図６はコンタクト情報管理装置が作成するコミュニティ会員情報データベースのテーブルを示す。すなわち、テーブルのエントリは、コミュニティID＝”KawasakiSystemLab@xyz.co.jp”901、管理者ID＝“nishiki”902、メンバ１のID＝“tanaka”903、メンバ１が利用可能な電話サービスの種別とアドレスとして、(1)＝”個人携帯、090-999-1234”904、(2)＝”会社固定外線、044-999-1234”905、(3)＝”会社固定内線、8-99-1234”906、(4)＝”会社IP携帯、5555@xyz.co.jp”907、(5)＝”自宅IP固定、050-1111-9999”908、メンバ１が利用可能なメールサービスの種別とアドレスとして、(1)＝“会社、tanaka@xyz.co.jp”909、(2)＝”個人、k-tanaka@freemail.jp”910、メンバ１の所持する端末に付けられた電子タグID＝”QQQABCDE”911、メンバ１の最新の所在地＝｛HOME,Desk,Meeting,Unknown｝のいずれか、プロキシ利用＝｛有り、無し｝のいずれかを記載する。以下コミュニティに所属するユーザの数分繰り返し、で構成される。
なお、符号904から符号911までが、ユーザから送信を受けた情報であり、プロキシ利用は、デフォルトで利用有りとしておくと、IPアドレスを隠すこととなり、セキュリティ上好ましい。

図７は、コンタクト情報管理装置が作成するアドレス選択ポリシデータベース107のテーブルである。テーブルのエントリは、メンバIDに対応する列＝”nishiki”1010,”tanaka”1011,”takahashi”1012と、所在に対応する行＝“HOME”1020,”OFFICE-Desk”1021,”OFFICE-Meeting“1022、”Unknown(所在が不明)”1023で構成され、選択すべきアドレスを設定する。例えば、ユーザ”nishiki”が”HOME”にいる場合は”自宅IP固定”アドレスを選択することを示している。符号1020から符号1023までが、ユーザから送信を受けた情報である。

さらに、図８はコンタクト情報管理装置がコミュニティメンバに付与する資格情報を示す。すなわち、資格情報はXMLデータ形式で生成され、情報種別＝“資格チケット”1100、発行者＝”Contact-ALL.ne.jp”1110、所属コミュニティID＝”KawasakiSystemLab@xyz.co.jp”1120、ユーザID=”tanaka”1130、属性＝｛admin, member, guest}のいずれか、有効期限＝”2005/02/10 24:00”1150、発行者署名＝“XML署名データ”1160、で構成される。

コンタクト情報を共有するコミュニティにおいて、通信を行いたいメンバのアドレス問合せと呼び出しに関する処理を、図９を用いて説明する。なお、このシーケンスはプロキシの利用を前提としている。
まず、メンバYは、端末322からコンタクト情報管理装置310にメンバZのアドレス問合せのメッセージを送る（T501）。問合せメッセージには、相手のID、サービス名（本実施例では、電話）、資格情報を含んでいる。コンタクト情報管理装置310は、問合せメッセージの資格情報がコミュニティに対応しているかどうかを確認した後で、アドレスを検索した結果をメンバYの端末322に返す（T502）。さらに実際の通信を開始する場合は、メンバY端末322からコンタクト情報管理装置310にセッション確立要求メッセージを送る（T503）。これは対応するVoIPサーバ311を経由してメンバZの端末352に呼び出しをかける（T504）。メンバZの端末352が呼び出しに応じると応答メッセージがVoIPサーバ311及びコンタクト情報管理装置310を経由してメンバYに返る（T505,T506）。さらにメンバYの端末322からセッション確立確認メッセージがメンバZの端末352に送られる（T507,T508）。これでセッションが確立し、端末間で通話が開始される（T509）。

上述の実施例では、電話について説明したが、メールの場合メールサーバを用いて同様の手順でセッションを確立し、データの送達を行う。Webについても同様である。また、上記セッションの確立において、最初に呼び出したアドレスに応答がない場合に、登録されている別のアドレスで再度呼び出しを試みるようにしてもよい。

図１０は、コンタクト情報管理装置310における位置情報取得部102の詳細を示すフローチャートである。まず位置リーダ10からタグ検出あるいは不検出の通知を受ける（S701）。タグIDに該当するコミュニティ会員情報DB 106を検索する（S702）。通知されたタグIDに該当するエントリが存在する場合は(S703)、同じエントリの位置情報を更新する（S704）。

ここで位置情報の決定方法としては、位置リーダ10の識別子（例えばネットワークアドレス等）と位置リーダ10の設置場所（例えばｘｘビルの3階会議室等）の対応テーブルを予め作成しておくことにより可能である。また、複数の位置リーダが同一タグについて取得した距離データをもとに無線タグの相対位置を求める方法を用いてもよいし、電界強度のかわりに電波の到達時間を測定し、より精度の高い距離データを求める方法を用いてもよい。さらに、無線タグのかわりにGPSアダプタを端末に装着し、人工衛星から取得した緯度経度情報を位置リーダを介して収集するようにしてもよい。もちろん携帯端末から直接送達しても良い。なお、RFIDタグと位置リーダとの組み合わせ、GPSアダプタはともに位置検出手段である。

図１１を用いて、コンタクト情報検索部104の詳細を説明する。まず、コミュニティメンバからのアドレス問合せを受け付ける（S801）。添付された資格情報をもとにコミュニティメンバの資格の正当性を確認し、正当である場合（S802）、コミュニティ会員情報DBを検索して問合せ対象メンバのエントリを見つけ出す。さらに問合せ先の現在の所在をもとにアドレス選択ポリシDBを参照して選択すべきアドレスを決定する（S803）。該当するアドレスが見つかった場合（S804）、コンタクト情報（アドレス及び所在等）を問合せたユーザに応答する（S805）。資格情報がない、あるいは資格情報が適切でない場合は、問合せを拒否する（S807）。また検索した結果、該当するアドレスが登録されていない場合は、該当なしと応答する（S806）。

図１２を用いて、プロキシ呼出し部110の詳細を説明する。なお、以下のフローは、図１１のアドレス問合せに引き続いて行うことを前提としている。まず、発呼端末からのセッション確立要求を受け付ける（S151）。アドレス問合せ時のサービスが電話だったので、VoIPプロキシ111を呼び出す（S152）。VoIPプロキシ111は、VoIPサーバ311にセッション確立要求を送る（S153）。着呼側端末からの応答を受信したとき（S154）、発呼端末にセッション確立ＯＫを送信する（S155）。発呼端末からのセッション確立確認を受信して、VoIPサーバにセッション確立確認を送信する（S156）。S154で着呼側端末からの応答が無くタイムアウトしたときには、発呼端末にセッション確立ＮＧを送信する（S157）。なお、S155で発呼端末にセッション確立ＯＫを送信した後、発呼端末からの応答が無くタイムアウトしたときも終了する。
なお、発呼者が予め着呼アドレスを分かっている場合（アドレス問合せに引き続いて行わない場合）は、コンタクト情報管理装置を介さずに、当該サーバに対してセッション確立要求を行って、端末間を接続する。

図１３を用いて、携帯端末の表示画面を説明する。起動画面1410は、メッセージ表示エリア1420、ダイヤルキー1430、コマンドボタン1441〜1443、検索条件設定エリア1451〜1453で構成されている。アドレスを検索する場合は、検索条件エリアのプルダウン選択によって、コミュニティ名（“KawasakiSystemLab”）、ユーザID(“tanaka”)、サービス種別（”電話“）を設定し、検索ボタンを押下する。検索結果はメッセージ表示エリアに、例えば、”tanaka OFFICE:会議室 5555@xyz.co.jp”のように表示される。ここで接続ボタンを押下すると、表示されたアドレスに対する接続要求が送られる。

なお、図１３では、GUIソフトウェアが、電話クライアントであるが、メールクライアント、Webブラウザ、インスタントメッセンジャー等のソフトウェアに同様の検索インターフェースを追加することにより、各種サービスに対して共通のコンタクト情報管理サービスを提供することができる。

本実施例に拠れば、サービスに関して複数のアドレス（契約）を有する通信相手に対し、相手の所在場所に応じて適切なアドレスを選択して通信を行うことができる。

本発明の実施例２を図１４と図１５を用いて説明する。ここで、図１４は、本発明の実施例のコミュニケーションシステムの構成図である。また、図１５は、本発明の実施例のユーザ所有の登録管理のテーブルである。

図１４において、ユーザ1210およびユーザの所持する端末1211は、複数のコミュニティ、すなわち家族や親戚で構成されているコミュニティＡ1240、職場の構成員で構成されているコミュニティＢ1250、ボランティア活動を行っているコミュニティＣ1260に所属している。各コミュニティは、それぞれVoIPサーバ1241、1251、1261、メールサーバ1242、1252、1262、Webサーバ1243、1253、1263を運用しており、WAN1230を介して利用できる。さらに共通的に利用可能なコンタクト情報管理装置310が接続されている。

本実施例では、コンタクト情報管理装置310のハードウェア構成、ソフトウェア構成は、実施例１と同じである。しかし、実施例１では、VoIPサービスプロバイダ300が、自分の管理下のVoIPサービスを受けるユーザのみにサービスしていたのに対し、実施例２では、自分の管理下でないVoIPサーバのユーザにも利用できるコンタクト情報管理サービスを行っている。

図１５を用いて、ユーザ1210が所属するコミュニティ毎にアドレス登録／非登録を判断する登録管理テーブルを説明する。表の横方向は、コミュニティ名に対応する列＝“コミュニティＡ”1310、”コミュニティＢ”1311、“コミュニティＣ”1312である。表の縦方向には、登録されたアドレスに対応する行＝電話（1）アドレス〜電話(5)アドレス、メール(1)アドレス、メール(2)アドレスで構成されている。電話アドレスおよびメールアドレスのそれぞれの属性は、図６の符号904から符号910の各欄に記載したものである。

図１５で、行と列との交差するセルに、アドレスをコミュニティメンバに対して公開（登録）あるいは公開不可（非登録）を記載している。例えば、コミュニティＡ（家族・親戚）において、電話(1)アドレス（属性：個人携帯）は、家族・親戚に公開（登録）し、電話(4)アドレス（会社IP携帯）は、家族・親戚に公開しない（非登録）。

具体的には、実施例１の図４のT407（図５のS602とS603の間）で、ユーザからのコンタクトに必要なアドレス情報、アドレス選択ポリシ、端末に装着されているタグのIDなどの送信をする際、非登録のアドレスを空白にして送信する。この結果、図６のコミュニティ会員情報データベースのテーブルの非公開部分は、空白になる。この結果、ユーザ1210は、公開するアドレスをコミュニティごとにすることができる。また、自分の所在を知られたくなければ、電子タグのID欄を空白で送信すれば、最新の所在地情報は無効状態になる。この結果、アドレスの問合せを受けたコンタクト情報管理装置310は、公開されたアドレス全てを端末に表示する。

本実施例に拠れば、複数のコミュニティに所属しているユーザがコミュニティの種別に応じて特定のアドレスを隠蔽することができる。

本発明の実施例のコミュニケーションシステムの構成図である。本発明の実施例のコンタクト情報管理装置の機能ブロック図である。本発明の実施例のコンタクト情報管理装置の各機能ブロックのハードウェア構成を示すブロック図である。本発明の実施例のコミュニティ登録手順を説明するシーケンス図である。本発明の実施例を説明するコミュニティ参加登録のフロー図である。本発明の実施例を説明するコミュニティ会員情報データベースのテーブルである。本発明の実施例を説明するアドレス選択ポリシデータベースのテーブルである。本発明の実施例を説明する資格情報を示す図である。本発明の実施例を説明するコンタクト情報問合せのシーケンス図である。本発明の実施例の位置情報取得部のフロー図である。本発明の実施例のコンタクト情報検索部のフロー図である。本発明の実施例のセッション確立のフロー図である。本発明の実施例のコミュニケーション端末のＧＵＩを説明する図である。本発明の実施例のコミュニケーションシステムの構成図である。本発明のユーザ所有の登録管理のテーブルである。

符号の説明

10…位置リーダ、20…RFIDタグ、101…ユーザインターフェース部、102…位置情報取得部、103…コンタクト情報登録部、104…コンタクト情報検索部、105…アドレス選択ポリシ設定部、106…コミュニティ会員情報データベース、107…アドレス選択ポリシデータベース、110…プロキシ呼出し部、111…ＶｏＩＰプロキシ、112…メールプロキシ、113…Ｗｅｂプロキシ、122…メールサーバ、123…Ｗｅｂサーバ、201…CPU、202…メモリ、203…入出力インターフェース部、204…表示装置、205…入力装置、206…記憶装置、207…ネットワーク装置、208…外部のシステム、121…VoIPサーバ、122…メールサーバ、123…Webサーバ、130…ユーザ端末、300…VoIPサービスプロバイダ、310…コンタクト情報管理装置、311VoIPサーバ、320…自宅、330…オフィス、340…自席、350…会議室、360…WAN。

Claims

コミュニティに参加しているメンバのコンタクトアドレスを保持しているコミュニティ会員情報データベースと、前記コミュニティ会員情報データベースに接続されたコンタクト情報検索部と、を含み
第１のメンバからの、第2のメンバのアドレス問合せを受信して、
前記コンタクト情報検索部は、前記第１のメンバの資格情報を確認し、前記コミュニティ会員情報データベースから前記第2のメンバのコンタクトアドレスを検索し、
前記第1のメンバに、前記コンタクトアドレスを送信することを特徴とするコンタクト情報管理装置。
コミュニティに参加しているメンバのコンタクトアドレスを保持しているコミュニティ会員情報データベースと、前記コミュニティ会員情報データベースに接続されたコンタクト情報検索部と、を含み
第１のメンバからの、第2のメンバのアドレス問合せを受信して、
前記コンタクト情報検索部は、前記第１のメンバの資格情報を確認し、前記コミュニティ会員情報データベースから前記第2のメンバのコンタクトアドレスを検索し、
検索した前記第2のメンバのコンタクトアドレスを含むコンタクトアドレス情報を生成し、
前記第1のメンバに、前記コンタクトアドレス情報を送信することを特徴とするコンタクト情報管理装置。
コミュニティに参加しているメンバのコンタクトアドレスを保持し、メンバからの前記コンタクトアドレスに関する問合せに応答するコンタクト情報管理装置であって、
コンタクトアドレスをコミュニティ会員情報データベースに格納するコンタクト情報登録ユニットと、
メンバの複数のコンタクトアドレスからメンバの状況に適したアドレスを選択するためのポリシをアドレス選択ポリシデータベースに格納するアドレス選択ポリシ設定ユニットと、
メンバからのコンタクトアドレス問合せを受けたとき、前記コミュニティ会員情報データベースと前記アドレス選択ポリシデータベースを参照して、応答すべきコンタクトアドレス情報を生成するコンタクト情報検索ユニットと、
を有するコンタクト情報管理装置。
請求項２または請求項３に記載のコンタクト情報管理装置であって、
メンバの所有する携帯端末に設置した位置検出手段からの位置情報を取得する位置情報取得部をさらに備え、
前記位置情報取得部が取得した前記携帯端末の位置情報に基づいて、コンタクトアドレス情報を生成することを特徴とするコンタクト情報管理装置。
請求項２または請求項３に記載のコンタクト情報管理装置であって、
VoIPサーバと接続するVoIPプロキシと、メールサーバに接続するメールプロキシと、前記VoIPプロキシと前記メールプロキシとに接続しサーバを呼び出すプロキシ呼出し部とを、さらに備え、
前記コンタクトアドレス情報に基づいて、プロキシ呼出しすることを特徴とするコンタクト情報管理装置。
コミュニティに登録したメンバのコンタクトアドレスを保持するコミュニティ会員情報データベースを含むコンタクト情報管理装置であって、
前記コミュニティへの参加希望者からの、参加要求を受けたとき、前記コミュニティの管理者へ参加許可問合せを送信し、
前記管理者からの第１の参加許可を受信したとき、前記参加希望者に第2の参加許可を送信し、
前記第2の参加許可を受信した前記参加希望者からの前記参加希望者のアドレス情報を、前記コミュニケーション会員情報データベースに記録し、
前記参加希望者に、資格情報を送信することを特徴とするコンタクト情報管理装置。
複数のコミュニティのコンタクトアドレスを管理するコンタクト情報管理装置であって、
コミュニティ会員情報データベースと、前記コミュニティ会員情報データベースの検索を行うコンタクト情報検索部と、を含み、
複数のコミュニティに参加しているメンバについて、少なくとも第1のコミュニティのメンバに開示する第１のコンタクトアドレス情報と、第２のコミュニティのメンバに開示する第２のコンタクトアドレス情報と、の２種類のコンタクトアドレス情報を保持することを特徴とするコンタクト情報管理装置。
コミュニティに参加しているメンバのコンタクト情報管理方法であって、
第1のメンバから、第2のメンバのアドレス情報の問合せを受信し、
前記第１のメンバの資格情報を確認し、
前記第2のメンバのコンタクトアドレスを検索し、
前記第1のメンバに前記コンタクトアドレスを送信することを特徴とするコンタクト情報管理方法。
コミュニティに参加しているメンバのコンタクト情報管理方法であって、
第1のメンバから、第2のメンバのアドレス情報の問合せを受信し、
前記資格情報を確認し、
前記第2のメンバのコンタクトアドレスを検索し、
検索した前記第2のメンバのコンタクトアドレスを含むコンタクトアドレス情報を生成し、
前記第1のメンバに前記コンタクトアドレス情報を送信することを特徴とするコンタクト情報管理方法。
請求項９に記載のコンタクト情報管理方法であって、
前記第1のメンバの前記コンタクトアドレス情報受信を受けた前記第1のメンバの、セッション確立要求を受信し、
サーバに相手呼び出しを送信し、
前記第2のメンバの応答を受けたサーバからの応答信号を受信し、
前記第１のメンバにセッション確立応答を送信することを特徴とするコンタクト情報管理方法。