JP2008276560A - データ共有システム、端末装置、サーバ装置及びプログラム - Google Patents

Abstract

【課題】関係のあるユーザ間で必要なデータを簡単に共有できるようにする。
【解決手段】サーバ装置１１にネットワーク１３を介して複数の端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…が接続される。端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…にはＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…が設けられ、各ユーザのＩＤタグ１４ａ，１４ｂ，１４ｃ…を非接触で検出する。端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…は、自端末の使用者以外のユーザのＩＤタグを検出し、そのユーザの端末装置にＩＤタグ検出期間中に操作されたデータを送信する。これにより、近くにいるユーザ同士で同じデータを共有できる。
【選択図】 図１

Description

本発明は、各ユーザの端末装置のデータを共有化するデータ共有システムと、このデータ共有システムに用いられる端末装置、サーバ装置及びプログラムに関する。

近年、ＲＦＩＤ（Radio Frequency Identification）などの非接触型の認証システムが普及している。ＲＦＩＤとは、個人情報や製品情報などを記録したＩＤタグを用い、これを電磁界や電波などを利用して非接触で読み出して認証する技術である。

従来、このようなＩＤタグを用いてユーザを特定し、そのユーザの端末装置にデータを送信する技術として、例えば特許文献１が知られている。この特許文献１には、ＩＤタグを用いて同一グループのメンバーの居場所を検出することにより、メール等の転送先を変更して情報伝達を行うことが開示されている。
特開２００６−３０９６０９号公報

しかしながら、前記特許文献１では、ＩＤタグを用いてユーザの位置を検出し、そこに所定のデータを一方的に転送するだけであり、各ユーザが持つデータを共有することはできない。

本発明は前記のような点に鑑みなされたもので、関係のあるユーザ間で必要なデータを簡単に共有することのできるデータ共有システム、端末装置、サーバ装置及びプログラムを提供することを目的とする。

本発明の請求項１に係るデータ共有化システムは、使用を割り当てられた端末装置を使用する各ユーザに付けられたＩＤタグと、このＩＤタグの情報を非接触で検出するタグ検出装置と、各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理する管理テーブルと、前記タグ検出装置によって検出されたＩＤタグに基づいて前記管理テーブルを参照してユーザが持つ端末装置を特定する端末特定手段と、前記タグ検出装置による前記ＩＤタグの検出期間中に前記端末特定手段によって特定された端末装置上で操作されたデータを共有用として保持するデータ保持手段と、このデータ保持手段に保持されたデータを当該ユーザの近くに存在する他のユーザが持つ端末装置との間で共有化する共有化制御手段とを具備したことを特徴とする。

また、本発明の請求項２は、請求項１記載のデータ共有化システムにおいて、前記タグ検出装置によって検出されたＩＤタグを持つユーザの端末装置を共有先として設定する共有設定手段を備え、前記共有化制御手段は、前記共有設定手段によって共有先として設定された端末装置のデスクトップを他の端末装置との間で共有化することを特徴とする。

また、本発明の請求項３は、請求項１記載のデータ共有化システムにおいて、前記データ保持手段に保持されたデータに対してアクセス許可ルールを設定するアクセス許可ルール設定手段を備え、前記共有化制御手段は、前記データ保持手段に保持されたデータを有する端末装置に他の端末装置がアクセスした際に、前記アクセス許可ルール設定手段によって設定されたアクセス許可ルールに基づいて当該データの共有化を制御することを特徴とする。

また、本発明の請求項４は、請求項１記載のデータ共有化システムにおいて、操作履歴の表示を指示する表示指示手段を備え、前記共有化制御手段は、前記表示指示手段による操作履歴の表示指示に従って、前記データ保持手段を参照して、所定期間内に操作されたデータの履歴をリスト化して表示することを特徴とする。

また、本発明の請求項５は、請求項１記載のデータ共有化システムにおいて、各ユーザのスケジュールを管理するスケジュール管理テーブルを備え、前記共有化制御手段は、前記タグ検出装置によって検出されたＩＤタグに基づいて同じ場所に存在する各ユーザを特定して、これらのユーザのスケジュールを前記スケジュール管理テーブルから読み出し、現場面に関するスケジュールが未登録のユーザに当該スケジュールを登録することを特徴とする。

また、本発明の請求項６は、請求項１記載のデータ共有化システムにおいて、前記共有化制御手段は、各ユーザが参照したデータを当該スケジュールの関連データとして前記スケジュール管理テーブルに登録することを特徴とする。

また、本発明の請求項７は、請求項１記載のデータ共有化システムにおいて、前記タグ検出装置によって検出されたＩＤタグに基づいて、互いに近くにいる頻度の高いユーザのペアを共有対象として記憶する共有対象記憶手段を備え、前記共有化制御手段は、前記共有対象記憶手段に記憶されたユーザのペアに対し、互いの端末装置が持つデータへのアクセス権限を与えることを特徴とする。

本発明の請求項８に係る端末装置は、各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理するサーバ装置にネットワークを介して接続された端末装置であって、自端末の使用者以外のユーザに付けられたＩＤタグを検出するタグ検出手段と、このタグ検出手段によるＩＤタグの検出期間中に操作されたデータを共有用として保持するデータ保持手段と、前記タグ検出手段によって検出されたＩＤタグを持つユーザの情報を前記サーバ装置に問い合わせて取得するユーザ情報取得手段と、このユーザ情報取得手段によって得られたユーザ情報に基づいて、前記データ保持手段に保持されたデータを自端末の使用者の近くに存在する他のユーザが持つ端末装置に送信するデータ送信手段とを具備したことを特徴とする。

また、本発明の請求項９は、請求項８記載の端末装置において、自端末の使用者と前記タグ検出手段によって検出されたＩＤタグを持つユーザとの間で会話が成立しているか否かを判断する会話判断手段を備え、前記データ送信手段は、前記会話判断手段によって会話が成立すると判断された場合に、前記データ保持手段に保持されたデータを会話相手であるユーザの端末装置に送信することを特徴とする。

本発明の請求項１０に係るサーバ装置は、各ユーザが使用を割り当てられた端末装置にネットワークを介して接続されたサーバ装置であって、各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理する第１の管理テーブルと、前記ＩＤタグの情報を非接触で検出するタグ検出装置の設置位置に関する情報を管理する第２の管理テーブルと、前記タグ検出装置によって検出されたＩＤタグに基づいて前記第２の管理テーブルを検索し、互いに近くに存在するユーザのグループを検出するグループ検出手段と、このグループ検出手段によって検出されたグループ内の各ユーザが持つ端末装置を前第１の管理テーブルから特定する端末特定手段と、この端末特定手段によって特定された各ユーザの端末装置から前記タグ検出装置によるＩＤタグの検出期間中に操作されたデータを取得する操作データ取得手段と、この操作データ取得手段によって得られた各データを前記各ユーザの端末装置に送信するデータ送信手段とを具備したことを特徴とする。

また、本発明の請求項１１は、請求項１０記載のサーバ装置において、前記各ユーザ間で会話が成立しているか否かを判断する会話判断手段を備え、前記データ送信手段は、前記会話判断手段によって会話が成立すると判断された場合にのみ、前記操作データ取得手段によって得られた各データを前記各ユーザの端末装置に送信することを特徴とする。

本発明の請求項１２に係るプログラムは、各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理するサーバ装置にネットワークを介して他の端末装置と共に接続された端末装置を制御するためのコンピュータによって実行されるプログラムであって、前記コンピュータに、自端末の使用者以外のユーザに付けられたＩＤタグを検出する機能と、前記ＩＤタグの検出期間中に操作されたデータを共有用として所定のメモリに保持する機能と、前記ＩＤタグを持つユーザの情報を前記サーバ装置に問い合わせて取得する機能と、前記サーバ装置から得られたユーザ情報に基づいて、前記メモリに保持されたデータを自端末の使用者の近くに存在する他のユーザが持つ端末装置に送信する機能とを実現するためのコンピュータ読み取り可能なプログラムである。

本発明の請求項１３に係るプログラムは、各ユーザが使用を割り当てられた端末装置にネットワークを介して接続されたサーバ装置を制御するためのコンピュータによって実行されるプログラムであって、前記コンピュータに、各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を第１の管理テーブルに記憶する機能と、前記ＩＤタグの情報を非接触で検出するタグ検出装置の設置位置に関する情報を第２の管理テーブルに記憶する機能と、前記タグ検出装置によって検出されたＩＤタグに基づいて前記第２の管理テーブルを検索し、互いに近くに存在するユーザのグループを検出する機能と、前記グループ内の各ユーザが持つ端末装置を前第１の管理テーブルから特定する機能と、前記各ユーザの端末装置から前記タグ検出装置によるＩＤタグの検出期間中に操作されたデータを取得する機能と、前記取得した各データを前記各ユーザの端末装置に送信する機能とを実現するためのコンピュータ読み取り可能なプログラムである。

本発明によれば、ＩＤタグを用いて関係のあるユーザ同士を特定し、そのユーザ間で必要なデータを簡単に共有できるようになる。

以下、図面を参照して本発明の実施形態を説明する。

（第１の実施形態）
図１は本発明の第１の実施形態に係るデータ共有システムの構成を示すブロック図である。

このデータ共有システムは、サーバ装置１１と、このサーバ装置１１にネットワーク１３を介して接続される端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…と、各ユーザに付けられたＩＤタグ１４ａ，１４ｂ，１４ｃ…と、タグ検出装置であるＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…とを備える。

なお、図中では、サーバ装置を「サーバ」、端末装置を「端末」と略記する。他の図面でも同様である。これらは、汎用のコンピュータからなり、ネットワーク１３への接続機能を備える。ネットワーク１３は、例えばＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などである。

また、各ユーザに付けられたＩＤタグ１４ａ，１４ｂ，１４ｃ…は、例えばＲＦＩＤ方式のタグが用いられる。ＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…は、所定の距離の範囲内でＩＤタグ１４ａ，１４ｂ，１４ｃ…を非接触で検出する。

サーバ装置１１は、本システムを利用する各ユーザを管理している上位のコンピュータであり、データベース（ＤＢ）１６を有する。このデータベース１６には、ユーザ個人情報テーブルＴＡ１（図２）と、ユーザ端末情報テーブルＴＡ２（図３）が設けられている。

ユーザ個人情報テーブルＴＡ１は、各ユーザの個人情報を記憶している。具体的には、図２に示すように、各ユーザ毎に名前とそのユーザが持つタグの番号（タグＮｏ）、メールアドレスなどの情報を記憶している。ユーザ端末情報テーブルＴＡ２は、各ユーザの端末情報を記憶している。具体的には、図３に示すように、各端末装置のＩＤとユーザ名、ＩＰアドレスなどの情報を記憶している。

端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…は、各ユーザに使用が割り当てられたものであり、例えばＰＣ（Personal Computer）の他、ＰＤＡ（Personal Digital Assistants）や携帯電話などからなる。図１では、ユーザａが端末装置１２ａ、ユーザｂが端末装置１２ｂを使用し、ユーザｃが端末装置１２ｃと端末装置１２ｄの２台を使用する例が示されている。

これらの端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…には、ＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…が搭載されていると共に、本システムを実現するための専用アプリケーションソフトがインストールされている。この専用アプリケーションソフトは、ＩＤタグリーダの制御や、サーバ装置への問い合わせ、他端末装置へのデータ転送などを行う。

また、これらの端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…は、それぞれにデータベース（ＤＢ）１７ａ，１７ｂ，１７ｃ，１７ｄ…を有する。これらのデータベース１７ａ，１７ｂ，１７ｃ，１７ｄ…には、会話履歴テーブルＴＢ１（図４）と、会話参加者テーブルＴＢ２（図５）と、アイテムテーブルＴＢ３（図６）が設けられている。

会話履歴テーブルＴＢ１は、会話の履歴情報を記憶している。具体的には、図４に示すように、会話が成立したときに発行される会話ＩＤと、その会話の開始時間と終了時間を記憶している。

会話参加者テーブルＴＢ２は、会話に参加したユーザの情報を記憶している。具体的には、図５に示すように、会話が成立したときに発行される会話ＩＤと、その会話に参加したユーザ名を記憶している。

アイテムテーブルＴＢ３は、会話中に端末上で操作されたアイテムの情報を記憶している。具体的には、図６に示すように、会話が成立したときに発行される会話ＩＤと、端末のＩＤ、タイプ、アイテム、そのアイテムの操作開始時間と終了時間を記憶している。

なお、アイテムとは、各ユーザの端末上で操作可能なすべてのデータ類のことを言い、ファイルやＷｅｂサイトのＵＲＬ（Uniform Resource Locators）などを含む。

また、ＩＤタグ１４ａ，１４ｂ，１４ｃ…には、予めユーザ固有のＩＤ情報（図２のタグＮｏ）が記録されている。なお、図１のユーザｃのように複数の端末装置を使用する場合でも、１ユーザに対してＩＤタグは１個である。

ＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…は、ＩＤタグ１４ａ，１４ｂ，１４ｃ…に記録されたＩＤ情報を非接触で読み出してサーバ装置１１に転送する。第１の実施形態において、これらのＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…は、端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…に搭載されている。

次に、サーバ装置１１、端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…、ＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…のそれぞれの構成について説明する。

（ａ）サーバ装置の構成
図７は同実施形態におけるデータ共有システムに用いられるサーバ装置１１の構成を示すブロック図である。

サーバ装置１１は、コンピュータとしてのＣＰＵ２１を備えると共に、このＣＰＵ２１に内部バス２２を介してＲＯＭ２３、ＲＡＭ２４、外部記憶装置２５、補助記憶装置２６、キー入力装置２７、表示装置２８、通信インタフェース（以下、通信Ｉ／Ｆと称す）２９が接続されている。

ＣＰＵ２１は、本装置全体の制御を司るものであり、予めＲＯＭ２３に記憶された制御プログラム２３ａを読み込むことにより、所定の処理を実行する。ＲＯＭ２３は、制御プログラム２３ａなどの情報を記憶している。ＲＡＭ２４は、ＣＰＵ２１の処理動作に必要なデータを一時的に記憶するためのワークエリアとして使用される。外部記憶装置２５および補助記憶装置２６は、例えばハードディスク装置などからなり、記録媒体に対する情報の読み書きを行う。図１に示したデータベース１６は、この外部記憶装置２５または補助記憶装置２６に設けられている。

キー入力装置２７は、キーボードやマウスなどからなり、本装置を操作するユーザが各種データの入力や指示を行う場合に用いられる。表示装置２８は、ＬＣＤ（Liquid Crystal Display）などからなり、各種データの表示を行う。通信Ｉ／Ｆ２９は、端末装置１２ａ，１２ｂ，１２ｃ，１２ｄ…やＩＤタグリーダ１５ａ，１５ｂ，１５ｃ，１５ｄ…との間でネットワーク１３を介して通信するためのインタフェースである。

（ｂ）端末装置の構成
図８は同実施形態におけるデータ共有システムに用いられる端末装置１２ａの構成を示すブロック図である。なお、ここでは端末装置１２ａを代表として、その構成を示すが、他の端末装置１２ｂ，１２ｃ，１２ｄ…についても同様の構成である。

端末装置１２ａは、コンピュータとしてのＣＰＵ３１を備えると共に、このＣＰＵ３１に内部バス３２を介してＲＯＭ３３、ＲＡＭ３４、外部記憶装置３５、補助記憶装置３６、キー入力装置３７、表示装置３８、通信インタフェース（以下、通信Ｉ／Ｆと称す）３９が接続されている。

ＣＰＵ３１は、本装置全体の制御を司るものであり、予めＲＯＭ３３に記憶された制御プログラム３３ａを読み込むことにより、所定の処理を実行する。ＲＯＭ３３は、制御プログラム３３ａなどの情報を記憶している。ＲＡＭ３４は、ＣＰＵ３１の処理動作に必要なデータを一時的に記憶するためのワークエリアとして使用される。外部記憶装置３５および補助記憶装置３６は、例えばハードディスク装置などからなり、記録媒体に対する情報の読み書きを行う。図１に示したデータベース１７ａは、この外部記憶装置３５または補助記憶装置３６に設けられている。

キー入力装置３７は、キーボードやマウスなどからなり、本装置を操作するユーザが各種データの入力や指示を行う場合に用いられる。表示装置３８は、ＬＣＤ（Liquid Crystal Display）などからなり、各種データの表示を行う。通信Ｉ／Ｆ３９は、サーバ装置１１とネットワーク１３を介して通信するためのインタフェースである。

また、第１の実施形態において、この端末装置１２ａにはＩＤタグリーダ１５ａが搭載されており、このＩＤタグリーダ１５ａで読み取ったＩＤタグの情報（タグＮｏ）がネットワーク１３を介してサーバ装置１１に転送されるようになっている。

（ｃ）ＩＤタグリーダの構成
図９は同実施形態におけるデータ共有システムに用いられるＩＤタグリーダ１５ａの構成を示すブロック図である。なお、ここではＩＤタグリーダ１５ａを代表として、その構成を示すが、他のＩＤタグリーダ１５ａ，１５ｃ，１５ｄ…についても同様の構成である。

ＩＤタグリーダ１５ａは、コンピュータとしてのＣＰＵ４１を備えると共に、このＣＰＵ１に内部バス４２を介してＲＯＭ４３、ＲＡＭ４４、通信インタフェース（以下、通信Ｉ／Ｆと称す）４５、ＩＤタグ通信インタフェース（以下、ＩＤタグ通信Ｉ／Ｆと称す）４６が接続されている。

ＣＰＵ４１は、ＩＤタグリーダの制御を司るものであり、予めＲＯＭ４３に記憶された制御プログラム４３ａを読み込むことにより、所定の処理を実行する。ＲＯＭ４３は、制御プログラム４３ａなどの情報を記憶している。ＲＡＭ４４は、ＣＰＵ４１の処理動作に必要なデータを一時的に記憶するためのワークエリアとして使用される。

通信Ｉ／Ｆ４５は、端末装置１２ａと通信するためのインタフェースである。ＩＤタグ通信Ｉ／Ｆ４６は、各ユーザが持つＩＤタグ１４ａ，１４ｂ，１４ｃ…との間で所定距離の範囲内で無線通信を行うためのインタフェースである。

次に、第１の実施形態の処理動作について説明する。

第１の実施形態では、ＩＤタグの情報をもとに、ユーザ同士の会話を検出し、その会話中に参照されたファイルやＵＲＬ等のアイテムを会話相手のユーザに送信するようにしたものである。

今、説明を簡単にするため、図１０に示すように、例えばオフィス内において、ユーザａが端末装置１２ａを操作している場所にユーザｂが来た場合を想定する。ユーザａとユーザｂは、それぞれにＩＤタグ１４ａ、１４ｂが付けられている。ユーザｂの端末装置１２ｂは携帯していても良いし、他の場所にあっても良い。端末装置１２ａにはＩＤタグリーダ１５ａ、端末装置１２ｂにはＩＤタグリーダ１５ｂが搭載されている。

なお、以下の各フローチャートで示される処理は、それぞれにプログラムコードの形態で各装置にインストールされている。各装置に搭載されたＣＰＵがそのプログラムを読み込むことにより、以下のような処理を実行する。後述する他の各実施形態についても同様であり、それぞれの実施形態に対応した処理がプログラムコードの形態で各装置にインストールされており、各装置のＣＰＵがそのプログラムを読み込むことで当該実施形態の処理を実行する。

（１）会話履歴の作成・データ送信
まず、データ送信側の端末装置１２ａの処理について説明する。
図１１および図１２は同実施形態における端末装置１２ａの処理動作を示すフローチャートであり、図１１は端末装置１２ａの会話履歴の作成・データ送信処理、図１２は端末装置１２ａの操作履歴の記録処理を示している。

図１１に示す処理は、ＩＤタグ１４ｂを持つユーザｂが端末装置１２ａで作業しているユーザａに接近することをトリガにして発生する。なお、フローチャート上では、ユーザｂの持つＩＤタグ１４ｂを「ＩＤタグ２」として表記している。

すなわち、端末装置１２ａ内のＩＤタグリーダ１５ａによって、ユーザｂの持つＩＤタグ１４ｂが検出されると（ステップＡ１１）、端末装置１２ａ（ＣＰＵ３１）は、操作履歴の記録を開始する（ステップＡ１２）。

詳しくは、図１２に示すように、まず、端末装置１２ａは、前回の操作履歴記録後にファイルのオープンや編集、また、ブラウザの起動によりＷｅｂサイトを開くなど、何らかのアイテムが操作されたか否かを判断する（ステップＢ１１）。アイテムが操作されていれば（ステップＢ１１のＹｅｓ）、端末装置１２ａは、そのアイテムを共有用として、そのときの操作時間（開始時間と終了時間）、会話ＩＤ、端末ＩＤと関連付けてアイテムテーブルＴＢ３（図６）に記録する（ステップＢ１２）。また、アイテムが操作されていなければ（ステップＢ１１のＮｏ）、そのまま処理を終了する。

操作履歴の記録処理が終了すると、端末装置１２ａは、ユーザｂのＩＤタグ１４ｂがＩＤタグリーダ１５ａの検出領域内に滞在しているか否かを判定する（ステップＡ１３）。ＩＤタグ１４ｂがＩＤタグリーダ１５ａの検出領域内に滞在していれば（ステップＡ１３のＹｅｓ）、端末装置１２ａは、再び操作履歴の記録処理を行いながら（ステップＡ１２）、操作の監視を続ける。

ここで、ユーザｂがＩＤタグ１４ｂとともにユーザａから離れ、ＩＤタグリーダ１５ａの検出領域内にいなくなったら（ステップＡ１３のＮｏ）、端末装置１２ａは、ユーザａとユーザｂとの間で会話が成立していたか否かを判定する（ステップＡ１４）。この場合、以下のような条件を満たす場合には、会話が成立していたものと見なす。

条件１：ユーザｂがユーザａの近くで所定時間以上滞在していること。これは、ユーザｂの持つＩＤタグ１４ｂを検出してからの経過時間を図示せぬタイマなどを用いて計時することで分かる。

条件２：ユーザａの操作が頻繁でないこと。これは、端末装置１２ａのキー入力装置３７の操作間隔を監視することで分かる。ユーザａの操作が所定時間以上連続していれば、ユーザｂはたまたま近づいただけであり、ユーザａはそのまま作業していた可能性が高い。

なお、端末装置１２ａにマイクが設置されば、マイクを通じて会話音声を検出できたことを条件に加えても良い。

前記条件１，２を満たさなかった場合、端末装置１２ａは、ユーザａとユーザｂとの間で会話が成立していないものと判断して（ステップＡ１４のＮｏ）、何もせずに、ここでの処理を終了する。

一方、前記条件１，２を満たした場合、端末装置１２ａは、ユーザａとユーザｂとの間で会話が成立したものと判断して（ステップＡ１４のＹｅｓ）、サーバ装置１１に対し、ＩＤタグ１４ｂを持つユーザの情報を問い合わせる（ステップＡ１５）。なお、前記条件１，２のうち、少なくとも条件１を満たしていれば、ユーザａとユーザｂとの間で会話が成立したものと判断することでも良い。

また、前記ステップＡ１５では、ＩＤタグ１４ｂからＩＤ情報（タグＮｏ）をＩＤタグリーダ１５ａによって読み取り、これをサーバ装置１１に送信して、ＩＤタグ１４ｂを持つユーザの情報を問い合わせる。サーバ装置１１では、この問い合わせに対し、ユーザ名、メールアドレスや、端末のＩＤやＩＰアドレス等、後のデータ送信に必要となる情報を返す。なお、このときのサーバ装置１１側の処理については、後に図１３を参照して説明する。

端末装置１２ａは、サーバ装置１１から会話相手であるユーザｂの情報を取得すると（ステップＡ１６）、その情報を用いてデータベース１７ａに新規会話履歴を追加する（ステップＡ１７）。データベース１７ａを構成する各テーブルは、以下の通りである。

会話履歴テーブルＴＢ１（図４）：会話の開始時間・終了時間を記録する。
会話参加者テーブルＴＢ２（図５）：会話の参加者を記録する。
アイテムテーブルＴＢ３（図６）：会話中に操作されたアイテム情報（ファイルの場所・ＵＲＬ，使われた時間等）を記録する。

会話履歴テーブルＴＢ１において、会話の開始時間・終了時間は、前記ステップＡ１１にてＩＤタグ１４ｂを検出した時間と、前記ステップＡ１３にてＩＤタグ１４ｂの検出が不可となった時間に相当し、これらの時間は図示せぬタイマによって計時されている。

会話参加者テーブルＴＢ２において、会話の参加者とは、ここではユーザａとユーザｂである。会話の参加者が誰であるのかは、前記ステップＡ１６にてサーバ装置１１から得られる。

アイテムテーブルＴＢ３において、アイテム情報の記録は、前記ステップＡ１２にて行われている。

このようにして、会話履歴を保存すると、端末装置１２ａは、例えば「会話中のデータをユーザｂに送りますか？」といったようなメッセージを自端末の表示装置３８に表示するなどして、送信予定のデータを当該端末装置の使用者であるユーザａに確認する（ステップＡ１８）。そして、ユーザａが所定の操作により送信ＯＫの指示を行うと、端末装置１２ａは、会話履歴テーブルＴＢ１に記録された会話履歴と、アイテムテーブルＴＢ３に記録された操作アイテム（ファイル・ＵＲＬ等）をユーザｂが持つ端末装置１２ｂに送信する（ステップＡ１９）。

このときのデータ送信方法としては、例えば電子メールにデータを添付して送信する方法や、Ｐ２Ｐ（peer to peer）によってデータを送信する方法などがある。なお、会話相手の端末装置１２ｂに直接送るのではなく、共有サーバへアップロードしたり、共有サーバ上のアイテムへのアクセス権限を与えることでも良い。

この他、会話相手ユーザが会話履歴とアイテムへアクセスできる環境を作れるならば、どのような送信方法でも良い。また、送信アイテムは、ファイル・ＵＲＬそのものを送るのではなく、定期的にキャプチャした端末のデスクトップ画面の画像を送ることでも良いし、録音した会話音声ファイルを送るなどしても良い。

以上で端末装置１２ａ上での会話履歴の作成・送信の処理は終了する。

なお、上述した例では会話相手は１人であり、ユーザａ以外のＩＤタグが１個であるとして説明したが、複数のＩＤタグが同時に会話成立条件を満たした場合には、同一グループ内のユーザとみなして、これらのユーザの端末装置に対して操作アイテムを送信することになる。

また、ユーザｂが自分の端末装置１２ｂを持ってユーザａのところに来た場合には、端末装置１２ｂでも同様の処理が行われる。これにより、端末装置１２ｂ上で操作したアイテム（ユーザａの端末装置１２ａにはないアイテム）が端末装置１２ａに送信されるので、全端末に会話中に操作された全アイテムが行き渡ることになる。

（２）ユーザ情報送信
次に、サーバ装置１１の処理について説明する。
図１３は同実施形態におけるサーバ装置１１によるユーザ情報送信処理を示すフローチャートである。

前記ステップＡ１５において、ユーザａの端末装置１２ａから会話相手のユーザ情報の問い合わせがあると、サーバ装置１１（ＣＰＵ２１）は以下のような処理を実行する。

すなわち、ユーザ情報の問い合わせを受信すると（ステップＣ１１のＹｅｓ）、サーバ装置１１は、まず、その問い合わせと共に送られて来るＩＤ情報（タグＮｏ）に基づいて、図２に示すユーザ個人情報テーブルＴＡ１からユーザ名とメールアドレスを取得する（ステップＣ１２）。

続いて、サーバ装置１１は、ユーザ個人情報テーブルＴＡ１から得たユーザ名に基づいて、図３に示すユーザ端末情報テーブルＴＡ２を検索することにより、端末ＩＤとＩＰアドレスを取得する（ステップＣ１３）。そして、サーバ装置１１は、これらの情報をユーザａの会話相手のユーザ情報として端末装置１２ａに返信する（ステップＣ１４）。

このように、サーバ装置１１では、各ユーザのＩＤタグ、名前、端末、アドレスなどを管理しており、ユーザからの問い合わせに対し、これらの情報を即座に返せるように構成されている。

（３）会話履歴のデータ受信・保存
次に、データ受信側の端末装置１２ｂの処理について説明する。
図１４は同実施形態における端末装置１２ｂの会話履歴のデータ受信・保存処理を示すフローチャートである。この処理は、ユーザｂの端末装置１２ｂがユーザａの端末装置１２ａから送信された会話履歴のデータを受信することで実行される。

すなわち、端末装置１２ｂ（ＣＰＵ３１）が会話履歴情報とアイテム（ファイル・ＵＲＬ）を受信すると（ステップＤ１１）、まず、受信したアイテムを送信元の端末ＩＤ（ここではユーザａの端末ＩＤ）と共に端末装置１２ｂのアイテムテーブルＴＢ３（図６）に記録すると共に、そのデータ内容を記憶装置３５または３６内に保存する（ステップＤ１２）。

次に、端末装置１２ｂは、会話履歴テーブルＴＢ１（図４）に会話履歴情報を保存する（ステップＤ１３）。この場合、自端末に既に受信した会話履歴と同一のものが存在すれば、アイテム情報のみを補完登録（アイテムテーブルＴＢ３のみに登録）し、同一の会話履歴が存在しなければ、会話履歴情報とアイテム情報を新規に作成（会話履歴テーブルＴＢ１とアイテムテーブルＴＢ２に登録）する。

なお、端末装置１２ａにおけるデータの送信処理で、ファイルが共有サーバに置かれていれば、そのファイルを自端末内に保存する必要はない。この場合、アイテムテーブルＴＢ３に記録されるファイルの置き場所は、共有サーバ上のアドレスとなる。

（４）データ表示
次に、会話履歴をユーザが利用する場合の処理について説明する。

図１５は同実施形態における端末装置１２ｂのデータ表示処理を示すフローチャートである。この処理は、ユーザが端末上で会話履歴表示用のアプリケーションを起動することで実行される。

今、ユーザｂが所定の操作により会話履歴表示用のアプリケーションを起動したとする（ステップＥ１１）。端末装置１２ｂ（ＣＰＵ３１）は、データベース１７ｂ内の各テーブルＴＢ１〜ＴＢ３を参照して会話履歴のリストを作成し（ステップＥ１２）、これを自端末の表示装置３８に表示する（ステップＥ１３）。

図１６は同実施形態における端末装置１２ｂの会話履歴リストの表示画面の一例を示す図である。この会話履歴リストには、ユーザが過去に会話した相手と時間とそれに関連して保存されたアイテム（ファイル・ＵＲＬ）が記述されている。これにより、アイテムを受け取った際に、誰といつ会話したものであるかを一目で確認することができ、他のアイテムと混同せずに管理することができる。

なお、この会話履歴リストの表示形態は、図１６の例に特に限定されるものではない。また、すべての会話履歴を表示しても良いし、例えば現在から一週間以内の会話履歴など、所定単位で会話履歴を部分的に表示することでも良い。

また、会話履歴リスト上のアイテム名をクリックするなどして、ユーザが所望のアイテムを指定すると（ステップＥ１４のＹｅｓ）、端末装置１２ｂは、その指定アイテムを開く（ステップＥ１５）。この場合、指定アイテムがファイルであれば、そのファイルに対応したアプリケーションを起動して開き、ＵＲＬであれば、ブラウザを起動して開くことになる。ユーザが会話履歴表示アプリケーションの終了ボタンを押下すると（ステップＥ１６のＹｅｓ）、ここでの処理が終了する。

以上のように本発明の第１の実施形態によれば、ユーザ同士の会話中に操作されたファイル・ＵＲＬ等のアイテムがその会話に参加したユーザに与えられる。したがって、会話に参加したユーザ（前記の例ではユーザｂ）は、その場に自分の端末装置を持参していなくとも、後でその会話中で使用したアイテムを確認することができる。

また、会話中に操作されたアイテムの送信は、会話参加者のＩＤタグを利用して自動的に行われるので、そのアイテムを持つユーザ（前記の例ではユーザａ）が会話参加者全員の送信先を調べて送信するといった面倒な操作をしなくとも、会話参加者全員に簡単に共有用として保持されたアイテムを送ることができる。

また、会話が成立したと判定された場合にのみ、その会話中のアイテムを送信することで、単に近くを通っただけのユーザにアイテムを誤送信してしまうことを防ぐことができる。

また、図６に示したように、会話の時間や会話参加者とアイテムとを関連付けて保存するようにしたことで、多数の人との会話で得たアイテムを混同せずに管理することができ、例えば「＊＊月頃の会議で見たファイル」、「誰と一緒に見たファイル」といったような情報からでも、所望のアイテムをすぐ見つけ出すことができる。

（変形列）
なお、前記第１の実施形態では、会話履歴情報やファイル・ＵＲＬ等のアイテムの送信に際し、特に制限は設けなかったが、以下のような制限を設けておくことでも良い。

（ａ）特定のユーザだけにアイテムを送る／送らない。
（ｂ）特定の部署の人だけにアイテムを送る／送らない（同じ部署の人だけ送る等）。
（ｃ）特定のアプリケーションのファイルのみ送る／送らない（アプリがメーラの場合には送らない等）。
（ｄ）特定のフォルダ内のファイルのみ送る／送らない。
（ｅ）特定のドメインのサイトのＵＲＬのみ送る／送らない。
（ｆ）一定以上の会話参加者がいる時だけ送る／送らない（大勢のいる会議では送らない等）。
（ｇ）特定メンバーが揃った時だけ送る／送らない（このメンバーの会議だけ送る等）。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。

前記第１の実施形態では、ユーザ間の会話発生の判断やファイル・ＵＲＬの送信は端末装置側で行っていたが、第２の実施形態では、これをサーバ装置で行うようにしたものである。この場合、ＩＤタグリーダは端末装置に搭載する必要はなく、オフィス内の扉・壁・床・机等の任意の場所に設置される。

図１７は本発明の第２の実施形態に係るデータ共有システムの構成を示すブロック図である。なお、図１７において、前記第１の実施形態における図１の構成と同一部分には同一符号を付して、その説明を省略するものとする。

図１の構成と異なる点は、端末装置１２ａ，１２ｂ…にＩＤタグリーダは搭載されてなく、代わりに、リーダ＋通信デバイス１８ａ，１８ｂ…がオフィス内の扉・壁・床・机・端末等に配置される点である。リーダ＋通信デバイス１８ａ，１８ｂ…は、ＩＤタグリーダに通信機能を備えたものであり、所定距離内に存在するＩＤタグの情報を非接触で読み取り、これをネットワーク１３を介してサーバ装置１１に転送する。

また、サーバ装置１１に備えられたデータベース１６には、ユーザ個人情報テーブルＴＡ１（図２）、ユーザ端末情報テーブルＴＡ２（図３）に加え、デバイス位置情報テーブルＴＡ３（図１８）とＩＤタグ位置履歴情報テーブルＴＡ４（図１９）、さらに、会話履歴テーブルＴＡ５が設けられている。

デバイス位置情報テーブルＴＡ３は、リーダ＋通信デバイス１８ａ，１８ｂ…の位置情報を記憶している。具体的には、図１８に示すように、リーダ＋通信デバイス１８ａ，１８ｂ…に固有のデバイスＩＤと、それらの設置位置を示す座標情報を記憶している。

ＩＤタグ位置履歴情報テーブルＴＡ４は、各ユーザがそれぞれに持つＩＤタグ１４ａ，１４ｂ…の位置の履歴情報を記憶している。具体的には、図１９に示すように、ＩＤタグ１４ａ，１４ｂ…に付けられたタグＮｏと、ＩＤタグ１４ａ，１４ｂ…を検出した位置を示す座標情報と、検出した時刻を記憶している。

また、会話履歴テーブルＴＡ５は、図４の会話履歴テーブルＴＢ１と同様であり、会話相手の履歴情報を記憶している。

なお、端末装置１２ａ，１２ｂ…には、前記第１の実施形態と同様に、本システムに対応するための専用アプリケーションがインストールされている。この専用アプリケーションは、サーバ装置１１の要求に応じて自端末の操作履歴を返したり、サーバ装置１１へのファイル・ＵＲＬの送信などを行う。

次に、第２の実施形態の処理動作について説明する。

今、説明を簡単にするため、図２０に示すように、例えばオフィス内において、リーダ＋通信デバイス１８ａが設置されている場所にユーザａとユーザｂが来た場合を想定する。ユーザａとユーザｂには、それぞれにＩＤタグ１４ａ、１４ｂが付けられている。なお、ここでは、ユーザａは端末装置１２ａを携帯し、ユーザ１２ｂは端末装置１２ｂを携帯しているものとするが、どちらか一方の端末装置は他の場所にあっても良い。

（１）サーバ上の会話履歴の作成・データ送信
図２１は同実施形態におけるサーバ装置１１の会話履歴の作成・データ送信処理を示すフローチャートである。この処理は、オフィス内の任意の場所に設置されたリーダ＋通信デバイス１８ａが新規のＩＤタグを検出し、そのＩＤをサーバ装置１１に送信することをトリガに実行される。

すなわち、サーバ装置１１（ＣＰＵ２１）は、まず、リーダ＋通信デバイス１８ａによりユーザａが持つＩＤタグ１４ａの検出情報を受信すると（ステップＦ１１）、そのＩＤ送信元のリーダ＋通信デバイス１８ａの位置をデバイス位置情報テーブルＴＡ３（図１８）から取得する。このリーダ＋通信デバイス１８ａの位置が現在のＩＤタグ１４ａの位置に相当し（ステップＦ１２）、サーバ装置１１は、その位置情報をＩＤタグ位置履歴情報テーブルＴＡ４（図１９）にそのときの時刻と共に記録する（ステップＦ１３）。

次に、会話開始の検出処理に入る。
サーバ装置１１は、ＩＤタグ位置履歴情報テーブルＴＡ４（図１９）を参照して、今検出されたＩＤタグの近傍に他のＩＤタグが存在するか否かを判断する（ステップＦ１４）。ここで言うＩＤタグの近傍とは、当該ＩＤタグと同じリーダ＋通信デバイスにて検出される範囲内のことである。該当するＩＤタグが存在しなければ（ステップＦ１４のＮｏ）、ステップＦ１１に戻る。

ここで、図２０に示すように、ユーザｂがユーザａの近くに来たとすると、ユーザｂの持つＩＤタグ１４ｂがリーダ＋通信デバイス１８ａによって検出され、その位置情報がＩＤタグ位置履歴情報テーブルＴＡ４（図１９）にそのときの時刻と共に記録される（ステップＦ１１〜Ｆ１３）。この場合、ＩＤタグ１４ｂの位置は、ＩＤタグ１４ａと同様にリーダ＋通信デバイス１８ａの位置に相当する。

サーバ装置１１は、ＩＤタグ位置履歴情報テーブルＴＡ４（図１９）を参照して、ＩＤタグ１４ｂの近傍にＩＤタグ１４ａが存在することを検出すると（ステップＦ１４のＹｅｓ）、ユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を用いて、ＩＤタグ１４ａを持つユーザａとＩＤタグ１４ｂを持つユーザｂを同じグループとしてみなし、これらの端末装置を特定する（ステップＦ１５）。この場合、ＩＤタグ１４ａからユーザａの端末装置１２ａ、ＩＤタグ１４ｂからユーザｂの端末装置１２ｂが特定される。

サーバ装置１１は、この特定した端末装置１２ａ，１２ｂに対し、ユーザの操作履歴を記録するように指令を出す（ステップＦ１６）。この指令を受け、端末装置１２ａ，１２ｂでは、サーバ装置１１の終了指令があるまで、図１２に示した操作履歴記録処理を繰り返す。さらに、会話終了の検出と会話履歴の保存を行う。

次に、サーバ装置１１は、直前まで近傍にあったが、距離が離れてしまったＩＤタグが存在するか否かを判断する（ステップＦ１７）。該当するＩＤタグが存在する場合には（ステップＦ１７のＹｅｓ）、サーバ装置１１は、これらのＩＤタグを持つユーザの端末装置を特定した後（ステップＦ１８）、その全端末に操作履歴の終了指令を出すとともに、端末装置からその時点までに操作されたアイテムの操作履歴を受け取り、そのアイテムを共有用として例えばＲＡＭ２４などのバッファメモリに一時的に保持しておく（ステップＦ１９）。

すなわち、図２０の例において、ユーザｂのＩＤタグ１４ｂがユーザａのＩＤタグ１４ａから離れたとすれば、サーバ装置１１は、そのことをＩＤタグ１４ａ，１４ｂの位置情報から判断し、ユーザａの端末装置１２ａとユーザｂの端末装置１２ｂに対して操作履歴の終了指令を出すとともに、これらの端末装置１２ａ，１２ｂから操作履歴を受け取ることになる。

続いて、サーバ装置１１は、ＩＤタグ１４ａ，１４ｂの位置履歴から、タグ同士がどのくらいの時間近傍にあったかを算出し、それがユーザａとユーザｂとの会話の成立条件を満たしているかを判定する（ステップＦ２０）。この場合、図１１のステップＡ１４と同様に、所定時間以上近くにいれば、会話が成立とみなす。

会話が成立してと判定された場合（ステップＦ２０のＹｅｓ）、サーバ装置１１は、ユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を参照して、会話に参加したユーザａ，ｂの情報を取得する（ステップＦ２１）。そして、サーバ装置１１は、会話履歴テーブルＴＡ５（図４と同様）に会話履歴を新規追加すると共に（ステップＦ２２）、会話参加ユーザの端末装置に対し、前記バッファメモリに共有用として保持したアイテム（ファイル・ＵＲＬ）を送信する（ステップＦ２３）。この時の送信方法について、図１１のステップＡ１９の場合と同じである。

以上でサーバ装置１１上の会話履歴作成・データ送信処理は終了である。なお、データ受信側の端末装置の処理は、図１４と図１５と同様であるため、ここでは、その説明を省略する。

以上のように、本発明の第２の実施形態によれば、前記第１の実施形態と同様に、ユーザ同士の会話中に操作されたファイル・ＵＲＬ等のアイテムがその会話に参加したユーザに与えられるので、後でそのアイテムを確認することができる。

また、会話中に操作されたアイテムの送信は、会話参加者のＩＤタグを利用して自動的に行われるので、会話参加者全員の送信先を調べて送信するといった面倒な操作を必要とせずに、会話参加者全員に簡単に共有用として保持されたアイテムを送ることができる。

また、会話が成立したと判定された場合にのみ、その会話中のアイテムを送信することで、同一グループのユーザではなく、単に近くを通っただけのユーザにアイテムを誤送信してしまうことを防ぐことができる。

さらに、第２の実施形態では、前記第１の実施形態のように会話参加者の検出範囲が端末装置に搭載されたタグリーダの検出範囲に限定されないので、会議時等、会話参加者がある程度広範囲に広がる場合にも対応できるといった利点がある。

また、ＩＤタグ同士の相対距離を利用するので、ユーザが会話を維持しながら自分の端末装置を離れて、他の端末装置の前に移動する場合にも対応できる。

また、サーバ装置１１上に過去の全ユーザの会話履歴を蓄積しているので、微妙なグループ境界判定を要する場合等に利用できる。つまり、本実施形態では、会話しているグループ同士が比較的近くにいる場合に、グループ境界に微妙な判定を要するケースが想定される。そのような場合は、サーバ装置１１に過去の会話履歴を蓄積しておくことで、頻繁に会話しているグループで境界を設定することができる。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。

第３の実施形態では、近傍にあるＩＤタグを検出し、そのＩＤタグを持つユーザの端末装置に複雑な設定操作なしに、リモートデスクトップで接続して、その端末装置を共有操作できるようにしたものである。

なお、本実施形態は、前記第１の実施形態のシステム構成（図１）でも、前記第２の実施形態のシステム構成（図１７）でも実現できる。

図２２は本発明の第３の実施形態におけるデータ共有システムのデスクトップ共有処理を示すフローチャートであり、図２２（ａ）はデスクトップ共有のホストとなる端末装置側の処理を示すフローチャート、同図（ｂ）はデスクトップ共有のクライアントとなる端末装置側の処理を示すフローチャートである。

今、ホスト側をユーザａが持つ端末装置１２ａ、クライアント側をユーザｂが持つ端末装置１２ｂとして、それぞれの処理に分けて説明する。なお、フローチャート上では、ユーザａの持つＩＤタグ１４ａを「ＩＤタグ１」として表記し、ユーザｂの持つＩＤタグ１４ｂを「ＩＤタグ２」として表記している。また、ユーザａの持つ端末装置１２ａを「端末１」、ユーザｂの持つ端末装置１２ｂを「端末２」として表記している。

（１）ホスト側
デスクトップ共有のホストとなる端末装置１２ａの処理を図２２（ａ）に示す。この処理は、端末装置１２ａを使用するユーザａが共有を許可することをトリガとして実行される。

すなわち、所定の操作により共有モードが設定されると（ステップＧ１１）、端末装置１２ａ（ＣＰＵ３１）は、他端末からの共有リクエストを受ける（ステップＧ１２）。今、端末装置１２ｂから共有リクエストがあったとすると、端末装置１２ａは、サーバ装置１１に端末装置１２ｂに関する情報を問い合わせることで、端末装置１２ｂの使用者がユーザｂであり、ＩＤタグ１４ｂを持つことを確認する。なお、このときに、サーバ装置１１では、データベース１６に設けられたユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を用いて、端末装置１２ａからの問い合わせに対して応答している（図１３参照）。

ここで、端末装置１２ａの近傍にユーザｂの持つＩＤタグｂがＩＤタグリーダ１５ａによって検出されたならば（ステップＧ１３）、端末装置１２ａは、そのときの共有リクエストに応えて、表示装置３８に現在表示されているデスクトップ画面を端末装置１２ｂに送信する（ステップＧ１４）。

その後は、ユーザａが端末装置１２ａを操作した場合に（ステップＧ１５のＹｅｓ）、端末装置１２ａは、それに応じて画面を更新すると共に新規操作アイテム（ファイル・ＵＲＬ）があれば、これをアイテムテーブルＴＢ３（図６）に記録し（ステップＧ１６）、更新後の画面を端末装置１２ｂに送信する（ステップＧ１８）。

また、ユーザｂが端末装置１２ｂを操作した内容を受信すると（ステップＧ１８のＹｅｓ）、それに応じて画面を更新し、新規操作アイテム（ファイル・ＵＲＬ）があれば、これをアイテムテーブルＴＢ３（図６）に記録し（ステップＧ１９）、更新後の画面を端末装置１２ｂに送信する（ステップＧ２０）。

このような処理を、端末装置１２ａ側または端末装置１２ｂ側で共有モードをＯＦＦするか（ステップＧ２１〜Ｇ２３）、ユーザｂのＩＤタグ１４ｂが検出できなくなるまでの間、繰り返す（ステップＧ２４）。

共有モードが終了すると、端末装置１２ａは、アイテムテーブルＴＢ３を参照して共有中に操作されたアイテム（ファイル・ＵＲＬ）を判断し、そのデータを端末装置１２ｂに送信する（ステップＧ２５）。

以上でホスト側の処理は終了する。
なお、ホストをサーバ装置１１とし、そのサーバ装置１１上で動くバーチャルなデスクトップを共有することでも良い。その場合、処理のトリガはユーザの誰かがサーバ装置１１にアクセスしてバーチャルデスクトップを起動することになる。また、ステップＧ１３とステップＧ２４におけるＩＤタグの検出は、バーチャルデスクトップにアクセスするユーザ同士が近傍にいるか否かの判定になる。

（２）クライアント側
デスクトップ共有のクライアントとなる端末装置１２ｂの処理を図２２（ｂ）に示す。

ＩＤタグリーダ１５ａによってユーザａのＩＤタグ１４ａが検出されている状態で（ステップＨ１１）、端末装置１２ｂを使用するユーザｂが所定の操作により共有モードをＯＮすると、端末装置１２ｂは、サーバ装置１１にＩＤタグ１４ａを持つユーザａに関する情報を問い合わせて、ホストとなる端末装置１２ａのＩＰアドレスを取得する（ステップＨ１２）。なお、このときに、サーバ装置１１では、データベース１６に設けられたユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を用いて、端末装置１２ｂからの問い合わせに対して応答している（図１３参照）。

ホストとなる端末装置１２ａのＩＰアドレスを取得すると、端末装置１２ｂは、このＩＰアドレスに基づいて端末装置１２ａにアクセスし、共有リクエストを送る（ステップＨ１３）。この共有リクエストに応答して、端末装置１２ａからデスクトップ画面が送られて来る。端末装置１２ｂでは、このデスクトップ画面を受信して自身の自端末の表示装置３８に表示する（ステップＨ１４）。

以降は、ユーザａの操作によって更新された画面を受信したら（ステップＨ１５のＹｅｓ）、その更新画面を表示する（ステップＨ１６）。また、ユーザｂが端末装置１２ｂ上で共有デスクトップを操作したら（ステップＨ１７のＹｅｓ）、その操作内容を端末装置１２ａに送信し（ステップＨ１８）、それに応じて更新された画面を端末装置１２ａから受信して表示する（ステップＨ１９）。

このような処理を、端末装置１２ａ側または端末装置１２ｂ側で共有モードをＯＦＦするか（ステップＨ２０〜Ｈ２２）、ユーザａのＩＤタグ１４ａが検出できなくなるまでの間、繰り返す（ステップＨ２３）。

共有モードが終了すると、端末装置１２ｂは共有開始直前の画面に復帰する（ステップＨ２４）。

以上でクライアント側の処理は終了するが、後でホストであった端末装置１２ａから共有中に操作したアイテムの情報が送られて来るので、それを受信して保存する。この処理は図１４と同じである。

なお、ここではクライアントとなる端末装置が１つの場合を想定して説明したが、クライアントとなる端末装置が多数存在しても良い。このような場合には、ホストとなる端末装置のデスクトップを当該端末装置の近くに存在する多数の端末装置で共有操作することになる。

以上のように本発明の第３の実施形態によれば、近傍のＩＤタグを検出し、そのＩＤタグが付けられたユーザの端末装置を共有先として自動で設定することで、面倒な接続設定を必要とせずに当該端末装置のデスクトップを共有して、各ユーザで共通の作業を行うことができるようになる。

（第４の実施形態）
次に、本発明の第４の実施形態について説明する。

前記第１および第２の実施形態では、ファイル・ＵＲＬ等のアイテムのデータを会話相手に送信するものとしたが、第４の実施形態では、そのアイテムのアクセスキーを会話相手に与えて、オリジナルデータに直接アクセスさせるようにしたものである。

なお、本実施形態は、前記第１の実施形態のシステム構成（図１）でも、前記第２の実施形態のシステム構成（図１７）でも実現できる。

端末装置１２ａに備えられたデータベース１７ａには、アイテムテーブルＴＢ３（図６）に代わって、図２３に示すようなアクセス許可方式のアイテムテーブルＴＢ４が設けられる。他の端末装置１２ｂ，１２ｃ，１２ｄ…についても同様であり、アクセス許可方式のアイテムテーブルＴＢ４が設けられている。

このアクセス許可方式のアイテムテーブルＴＢ４には、図６に示した基本情報の他に、アクセスキー、コピー世代、そして、アクセス許可ルールが追加されている。アクセスキーは、外部からアイテムをアクセスするために必要なキーワードのことであり、各アイテム毎に設定されている。コピー世代とは、アイテムのコピー回数のことである。アクセス許可ルールとは、アクセスを許可する条件を定めたものである。なお、ＵＲＬのコピーはアクセス許可方式では使えないので、アイテムテーブルＴＢ４のアイテム欄はＵＲＬ自体ではなくサイトのタイトルになっている。

以下に、端末装置１２ａを代表して具体的な処理動作について説明する。

（１）アクセス許可ルールの設定
図２４は同実施形態における端末装置１２ａのアクセス許可ルールの設定処理を示すフローチャートである。

ユーザａが所定の操作によりアクセス許可ルールの設定モードを指示すると、端末装置１２ａ（ＣＰＵ３１）は、ＲＯＭ３３などに記憶されている各種画面データから設定対象入力画面を読み出し、これを自端末の表示装置３８に表示する（ステップＩ１１）。この設定対象入力画面には、アクセス許可を設定する対象（××フォルダ内のファイル、ＵＲＬ全部、△△ドメインのＵＲＬ等）を指定するフォームがある。

ユーザａがキー入力装置３７を操作して設定対象を入力すると（ステップＩ１１ａのＹｅｓ）、端末装置１２ａは、次にアクセス許可ルール入力画面を読み出して、これを自端末の表示装置３８に表示する（ステップＩ１２）。ここでは、前記設定対象に対するアクセス許可ルール（何世代まで編集可、○○さんのみ編集可等）を入力する。

ユーザａがキー入力装置３７を操作してアクセス許可ルールを入力すると（ステップＩ１２ａのＹｅｓ）、端末装置１２ａは、その入力されたルールを前記設定対象と関連付けて図２５に示すようなアクセス許可ルールテーブルＴＢ５に保存する（ステップＩ１３）。

（２）会話履歴の作成・データ送信
基本的な処理の流れは、前記第１の実施形態で説明した「会話履歴の作成・データ送信」と同じであるが、図１２のステップＢ１２で会話中に操作されたアイテムを記録する際に、当該アイテムに対するアクセス許可ルールを図２５に示したアクセス許可ルールテーブルＴＢ５から判断して、これを図２３に示したアクセス許可方式のアイテムテーブルＴＢ４に記録することになる。

また、図１１のステップＡ１９において、アイテム（ファイル・ＵＲＬ）のデータ本体を送信する代わりに、アイテムへのアクセスキー、コピーの世代数、アクセス許可ルールを送信すると共に、ファイルについてファイル名、ＵＲＬについてサイトのタイトルを送信することになる。

（３）会話履歴のデータ受信・保存
基本的な処理の流れは、前記第１の実施形態で説明した「会話履歴のデータ受信・保存」と同じであるが、図１４のステップＤ１１，Ｄ１２において、データ受信側である端末装置１２ｂは、アイテム（ファイル・ＵＲＬ）のデータ本体に代わって、アイテムへのアクセスキー、コピーの世代数、アクセス許可ルールを受信し、これを自端末内のアイテムテーブルＴＢ４に保存することになる。

（４）データ表示
基本的な処理の流れは、前記第１の実施形態で説明した「データ表示」と同じであるが、図１５のステップＥ１５において、データ受信側である端末装置１２ｂは、アイテム（ファイル・ＵＲＬ）を開く場合に、オリジナルデータを有する端末装置１２ａに対してアクセス要求を行う。その際、端末装置１２ｂは、アイテムテーブルＴＢ４から当該アイテムのアクセスキーを読み出して、これをアクセス要求と共に端末装置１２ａに送信する。アクセス要求を受けた端末装置１２ａは、アイテムがファイルであれば、図２７に示すような処理を実行する。

図２７は同実施形態における端末装置１２ａのファイルへのアクセス判定処理を示すフローチャートである。

端末装置１２ａ（ＣＰＵ３１）は、ファイルへのアクセス要求を受信すると（ステップＫ１１）、そのアクセス要求と共に送られてくるアクセスキーが要求対象ファイルのアクセスキーと一致するかを自端末内のアイテムテーブルＴＢ４（図２３）を用いて判定する（ステップＫ１２）。

アクセスキーが一致したら（ステップＫ１２のＹｅｓ）、端末装置１２ａは、要求対象ファイルのアクセス許可ルールを自端末内のアクセス許可ルールテーブルＴＢ５（図２５）から取得する（ステップＫ１３）。

このアクセス許可ルールに基づいて編集権限があると判定されたら（ステップＫ１４のＹｅｓ）、端末装置１２ａは、要求元の端末装置１２ｂに当該ファイルを編集可能なモードで開くことを許可する（ステップＫ１５）。

一方、編集権限がなかったら（ステップＫ１４のＮｏ）、端末装置１２ａは、前記アクセス許可ルールに基づいて読取権限があるか否かを判断する（ステップＫ１６）。読取権限があったら（ステップＫ１６のＹｅｓ）、端末装置１２ａは、要求元の端末装置１２ｂに読取専用モードでのみファイルを開くことを許可する（ステップＫ１８）。

また、読取権限もなかった場合には（ステップＫ１６のＮｏ）、端末装置１２ａは、当該ファイルへのアクセスを拒否する（ステップＫ１７）。具体的には、要求元の端末装置１２ｂに対して当該ファイルへのアクセスができない旨の通知を行う。

以上は要求アイテムがファイルの場合であるが、ＵＲＬであった場合には、編集権限の判定（ステップＫ１４）がないだけで、前記同様の処理である。読取権限があったら、要求元のユーザｂは当該ＵＲＬを取得して、サイトを開くことができる。

（５）第二世代以降のユーザへのアクセス許可
本実施形態では、アイテムのオリジナルデータはコピーされないため、アクセス権を持ったユーザが他のユーザにもアクセスさせたい場合は、そのユーザに対してアクセスを許可していくことになる。

今、ユーザｂがアクセス権を持ち、ユーザｃに対してアクセス許可を与える場合を想定して説明する。

図２６は同実施形態における端末装置１２ｂのアクセス許可処理を示すフローチャートである。この処理は、アクセス権を持ったユーザｂが自分の端末装置１２ｂ上で所定の操作によりアクセス許可機能を起動することをトリガにして実行される。

アクセス許可機能が起動されると、端末装置１２ｂは、自端末内のアクセス許可方式のアイテムテーブルＴＢ４（図２３）を参照して、処理対象とするアイテムに設定されたアクセス許可ルールを取得する（ステップＪ１１）。そして、端末装置１２ｂは、このアクセス許可ルールに含まれているコピー世代やユーザ名等の条件から、ユーザｃにアクセスを許可できるか否かを判定する（ステップＪ１２）。

アクセスを許可できる場合には（ステップＪ１２のＹｅｓ）、端末装置１２ｂは、ユーザｃの持つ端末装置１２ｃに当該アイテムに関する情報を送信する（ステップＪ１３）。この場合、当該アイテムのコピー世代は、自分の次の代になるので＋１にして送る。これを受けて、アクセスが許可されたユーザｃでは、許可元のユーザｂと同じようにして当該アイテムのオリジナルデータにアクセスすることになる。

以上のように本発明の第４の実施形態によれば、アクセスキーを用いてオリジナルデータに直接アクセスすることができる。この場合、前記第１または第２の実施形態では、各ユーザに送られるアイテムのデータは会話終了時のコピーだったため、アイテムがファイルであった場合にはその後に更新されても反映されなかったが、第４の実施形態では、直接オリジナルデータを読みに行くことができるので、常に最新版のデータを得ることができるといった利点がある。

また、オリジナルデータを有するユーザがアクセス許可ルールを設定することができるので、勝手にコピーすることを防止することができる。

（第５の実施形態）
次に、本発明の第５の実施形態について説明する。

第５の実施形態は、近づいてきたＩＤタグを検出し、そのＩＤタグが付けられたユーザの最近の操作履歴を表示するようにしものである。操作履歴からそのユーザが最近編集したファイルや、参照したＷｅｂサイト等をすぐ呼び出せる。

なお、本実施形態は、前記第１の実施形態のシステム構成（図１）でも、前記第２の実施形態のシステム構成（図１７）でも実現できる。

また、本実施形態では、ユーザの端末装置にインストールされたアプリケーションが会話の有無に関わらず常に操作履歴を記録している。

以下に、端末装置１２ａを代表して具体的な処理動作について説明する。

（１）操作履歴の表示
図２８は本発明の第５の実施形態における端末装置１２ａの操作履歴の表示処理を示すフローチャートである。この処理は、ユーザａが端末装置１２ａ上で所定の操作により操作履歴の表示機能を起動することをトリガにして実行される。

ユーザａが操作履歴の表示機能を指示すると（ステップＬ１１）、端末装置１２ａ（ＣＰＵ３１）は、その指示を受けて、まず、自端末の近傍にあり、会話の条件を満たしているユーザのＩＤタグを検出する（ステップＬ１２）。具体的には、前記第１の実施形態のシステム構成（図１）であれば、端末装置１２ａに設置されたＩＤタグリーダ１５ａによって、ユーザａの近くに所定時間以上滞在しているユーザのＩＤタグを検出する。

次に、端末装置１２ａは、そのＩＤタグを持つユーザをサーバ装置１１に問い合わせることにより（ステップＬ１３）、操作履歴を表示可能なユーザの候補リストを自端末の表示装置３８に表示する（ステップＬ１４）。なお、サーバ装置１１では、データベース１６に設けられたユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を用いて、端末装置１２ａからの問い合わせに対して応答している（図１３参照）。

ここで、ユーザａがキー入力装置３７を通じて前記ユーザ候補リストの中で操作履歴を表示するユーザを指定する。今、ユーザｂが指定されたものとして説明する。

ユーザｂが操作履歴の表示対象者として指定されると（ステップＬ１５のＹｅｓ）、端末装置１２ａは、ユーザｂが使用する端末装置１５ｂの操作履歴を取得して（ステップＬ１６）、そのリストを自端末の表示装置３８に表示する（ステップＬ１７）。これは、ユーザｂが最近操作したアイテム（ファイル・ＵＲＬ）を所定の形式で列挙したものである。ここで言う「最近」とは、例えば一週間以内などであり、その期間は予め任意に設定可能である。

ユーザａがキー入力装置３７を通じて前記アイテム候補リストの中で表示したいアイテムを指定すると（ステップＬ１８のＹｅｓ）、端末装置１２ａはその指定アイテムを操作履歴の持ち主であるユーザｂの端末装置１２ｂに要求して取得し（ステップＬ１９）、これを自端末の表示装置３８に表示する（ステップＬ２０）。この場合、指定アイテムがファイルであれば、そのファイルの対応アプリケーションで開き、ＵＲＬであればブラウザで開く。

なお、前記の例では、ユーザが別ユーザの端末装置を受け取ることに特にアクセス制限を設けなかったが、望まない操作履歴を見られてしまうのを避けるため、下記のようなアクセス制限を設けることが望ましい。

（ａ）予め指定されたユーザにしか操作履歴を公開しない。
（ｂ）予め指定されたアプリケーションの操作履歴は公開しない。
（ｃ）会話頻度の高いユーザにしか操作履歴を公開しない。
（ｄ）メール等の秘密性の高いアプリケーションの操作履歴は公開しない。

以上のように本発明の第５の実施形態によれば、会話中にその相手が最近操作したアイテムを見ることができる。したがって、前記第１または第２の実施形態のように、会話の後でアイテムを取得するのと違い、会話中にリアルタイムで所望のアイテムを得て、話を進めることができる。

（第６の実施形態）
次に、本発明の第６の実施形態について説明する。

第６の実施形態では、位置情報とスケジューラを連動する。つまり、ＩＤタグを用いてユーザ同士の会話が成立したことが判断された際に、サーバ装置が各ユーザのスケジュール情報をチェックし、各ユーザに共通のスケジュール（例えば会議）が存在する場合に、そのスケジュールが未登録のユーザに補完登録する。また、その会話中に各ユーザが参照したファイルやサイトを当該スケジュールの関連アイテムとして各ユーザのスケジュール情報に自動登録する。

図２９は本発明の第６の実施形態に係るデータ共有システムの構成を示すブロック図である。基本的な構成は、前記第２の実施形態のシステム構成（図１７）と同様であるため、ここではその説明を省略する。

本実施形態において、サーバ装置１１は、各ユーザの端末装置１２ａ，１２ｂ…にスケジューラ（スケジュール管理ソフト）を提供する機能を備える。このサーバ装置１１は、各ユーザのスケジュール情報を管理するためのスケジュール管理テーブルＴＡ６を有する。このスケジュール管理テーブルＴＡ６には、スケジュールに関連させて会話中の操作アイテムが記憶される。また、端末装置１２ａ，１２ｂ…は、それぞれにスケジュール情報を登録しておくためのスケジュール管理テーブルＴＢ６を有する。

以下に、サーバ装置１１の具体的な処理動作について説明する。

（１）スケジューラと連動した会話履歴の作成・データ送信
図３０は同実施形態におけるサーバ装置１１のスケジューラと連動した会話履歴の作成・データ送信の処理動作を示すフローチャートである。

今、オフィス内で複数のユーザが会話している状況を想定する。そのオフィス内の任意の場所にはリーダ＋通信デバイス１８ａが設置されており、所定の距離内に存在するＩＤタグの情報がリーダ＋通信デバイス１８ａを介してサーバ装置１１に送信されるものとする（図２０参照）。

まず、サーバ装置１１（ＣＰＵ２１）は、リーダ＋通信デバイス１８ａから送られてくるＩＤタグの情報に基づいて各端末装置における操作履歴の作成処理を行う（ステップＭ１１）。なお、この操作履歴作成処理については、図２１のステップＦ１１〜Ｆ１９と同じであるため、その詳しい説明は省略する。この操作履歴作成処理によって得られたアイテム（ファイル・ＵＲＬ）の情報は、共有用として例えばＲＡＭ２４などのバッファメモリに一時的に保持されている（図２１のステップＦ１９参照）
また、ステップＭ１２は、ＩＤタグを用いてユーザ同士で会話が成立したか否かを判定する処理である。これは、図２１のステップＦ２０と同様の基準で判定を行う。

会話が成立していたと判定されたら（ステップＭ１２のＹｅｓ）、サーバ装置１１は、ユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を参照して、会話に参加した各ユーザの情報を取得する（ステップＭ１３）。

続いて、サーバ装置１１は、会話に参加した各ユーザのスケジュール情報を取得する（ステップＭ１４）。詳しくは、ユーザ個人情報テーブルＴＡ１（図２）とユーザ端末情報テーブルＴＡ２（図３）を参照して、会話に参加した各ユーザの端末装置を特定し、それぞれの端末装置に設けられたスケジュール管理テーブルＴＢ６から当該ユーザのスケジュール情報を取得する。このようにして得られた各ユーザのスケジュール情報は、サーバ装置１１に設けられたスケジュール管理テーブルＴＡ６にユーザ名と共に登録される。

このようにして、会話に参加した各ユーザのスケジュール情報が得られると、サーバ装置１１は、スケジュール管理テーブルＴＡ６を参照して、会話に参加した各ユーザのいずれかに、複数の人が集まって会話するような会議類のスケジュールがあるか否かを調べる（ステップＭ１５）。これは、各ユーザのスケジュール時間を調べ、同じ時間帯に少なくとも２人以上のユーザで共通のスケジュールが登録されているものを調べることで分かる。

該当するスケジュールがあった場合（ステップＭ１５のＹｅｓ）、サーバ装置１１は、その中で会話参加者が最も共通に持つスケジュールを検出し、これを現場面に対応したスケジュールであると判断する（ステップＭ１６）。

そして、サーバ装置１１は、スケジュール管理テーブルＴＡ６を参照して、このスケジュールが登録されていないユーザに対してスケジュールの補完登録を行う（ステップＭ１７）。具体的には、サーバ装置１１が持つスケジュール管理テーブルＴＡ６の当該ユーザの欄に前記ステップＭ１６で検出したスケジュールの内容を登録すると共に、そのスケジュールの内容を当該ユーザの端末装置にも送ってスケジュール管理テーブルＴＢ６に書き込むといった処理を行う。

また、サーバ装置１１は、前記ステップＭ１１の操作履歴作成処理で得られたアイテム（ファイル・ＵＲＬ）を前記バッファメモリから読み出し、これを当該スケジュールの関連アイテムとしてスケジュール管理テーブルＴＡ６に登録する（ステップＭ１８）。その際、操作アイテムのオリジナルデータに対して会話参加者全員にアクセス権限を付与する等、後で参加者がアイテムを自由に閲覧できるようにしておく。

なお、参加者が多い場合は、無駄なアイテム（特に関連していないが開いたものなど）でアイテム数が膨大になる可能性があるので、関連アイテムの判定条件として以下のような条件を設けておくことでも良い。

（ａ）プロジェクタに接続された端末で表示されたアイテム。
（ｂ）多くの参加者がアクセスしたアイテム。
（ｃ）プレゼンテーション用のアプリケーション（ＰｏｗｅｒＰｏｉｎｔ等）で作られたファイル。

一方、複数の人が集まる会議類のスケジュールがなければ（ステップＭ１５のＮｏ）、サーバ装置１１は、通常の会話扱いで、会話履歴テーブルＴＡ５（図４と同様）に会話履歴を新規追加すると共に（ステップＭ１９）、会話参加ユーザの端末装置に対し、会話履歴とアイテム（ファイル・ＵＲＬ）を送信する（ステップＭ２０）。この時の送信方法について、図１１のステップＡ１９の場合と同じである。

ここで、サーバ装置１１のスケジューラ画面の一例を図３１に示す。ユーザａ，ユーザｂ，ユーザｃ，ユーザｄが会話参加者であるとする。

図３１（ａ）は、会話参加ユーザの会議前のスケジューラ画面である。ユーザａとユーザｂは会議のスケジュールを登録しているが、ユーザｃとユーザｄはそのスケジュールの登録を忘れている。この状態で各ユーザａ〜ｄが同じ場所（会議室）に集まると、上述した図３０のステップＭ１２移行の処理により、この会議のスケジュールが未登録であったユーザｃとユーザｄに対してスケジュールの補完登録がなされ、図３１（ｂ）のようになる。

図３１（ｃ）は、会議が終わった後、スケジューラ上で見られる会議の関連アイテム画面である。会議前は関連アイテムがないか、ユーザが手動でアップロードしたものしかないが、会議後は各ユーザａ〜ｄが開いたファイルやＵＲＬが当該スケジュールの関連アイテムとして自動登録される。会議参加者である各ユーザａ〜ｄは、サーバ装置１１にアクセスすることで、この画面上の関連アイテムを任意に参照できる。

このように本発明の第６の実施形態によれば、ＩＤタグを用いた会話検出システムとスケジューラとを連携したことで、会議などで使用したアイテムをスケジュールと関連付けて管理することができ、後に参考にする際に非常に役立つ。

また、そのときのスケジュールが未登録であっても、会話参加者の中の少なくとも１人がスケジュール登録していれば、そのスケジュールが補完登録されるので、後に操作アイテムとの関係を把握することができる。

（第７の実施形態）
次に、本発明の第７の実施形態について説明する。

第７の実施形態では、ユーザ間におけるアイテムの自動共有を特徴とする。すなわち、サーバ装置がよく会話しているユーザ同士を見つけ、そのユーザ間ではファイルやサイトへのアクセスを許可するものである。

なお、本実施形態は、前記第２の実施形態のシステム構成（図１７）で実現できる。すなわち、サーバ装置１１がオフィス内の任意の場所に設置されたリーダ＋通信デバイス１８ａ，１８ｂ…から各ユーザが持つＩＤタグ１４ａ，１４ｂ…の情報を得て、ユーザがどこで誰と会話しているのかを把握できる構成にある。

なお、本実施形態において、サーバ装置１１に備えられたデータベース１６には、図３３に示すような自動共有情報テーブルＴＡ７が設けられる。この自動共有情報テーブルＴＡ７は、アイテムの自動共有条件を満たすユーザのペアを管理するためのテーブルである。

以下に、サーバ装置１１の具体的な処理動作について説明する。

（１）アイテムの自動共有判定
図３２は本発明の第７の実施形態におけるサーバ装置１１のアイテムの自動共有判定処理を示すフローチャートである。この処理は、例えば一日一回といったように定期的に行われる処理であり、アイテムの自動共有条件を満たすユーザのペアを見つけ、図３３に示す自動共有情報テーブルＴＡ７に書き込む。この自動共有情報テーブルＴＡ７に登録されたユーザ同士は、会話の成立有無に関係なく、相手端末内のアイテムに直接アクセスできるようになる。

図３２に示すように、サーバ装置１１は、まず、処理対象とするユーザを示す変数ｎに１をセットして（ステップＮ１１）、その１人目のユーザについて、データベース１６内の会話履歴テーブルＴＡ５（図４と同様）から会話履歴を取得する（ステップＮ１２）。そして、サーバ装置１１は、この会話履歴に基づいて自動共有条件を満たすユーザがいるか否かを判断する（ステップＮ１３）。自動共有条件を満たすユーザがいる場合には（ステップＮ１３のＹｅｓ）、サーバ装置１１は、その相手ユーザの名前を当該ユーザに対応付けて自動共有情報テーブルＴＡ７（図３３）に登録する（ステップＮ１４）。

ここで、自動共有情報テーブルＴＡ７に登録されるのは、自動共有条件を満たすユーザのペアの情報である。また、自動共有条件としては、例えば以下のような条件が挙げられる。

（ａ）会話する回数が所定回数以上。
（ｂ）互いのアイテム（ファイル・ＵＲＬ）をアクセスする回数が所定回数以上。
（ｃ）互いにメールのやり取りが所定回数以上。

なお、前記（ａ）の会話回数については、会話履歴テーブルＴＡ５に記録された会話履歴から分かる。前記（ｂ）のアイテムのアクセス回数や前記（ｃ）のメール回数など、ＩＤタグに基づいて各端末装置から取得した操作履歴（図２１のステップＦ１９参照）から分かる。

また、サーバ装置１１は、過去に自動共有条件を満たして自動共有情報テーブルＴＡ７に登録されていたが、現在は上述したような自動共有条件を満たさなくなったユーザを会話履歴から検出する（ステップＮ１５）。該当するユーザが存在した場合には（ステップＮ１５のＹｅｓ）、サーバ装置１１は、自動共有情報テーブルＴＡ７からそのユーザの自動共有情報を削除する（ステップＮ１６）。

続いて、サーバ装置１１は、ｎを＋１更新して（ステップＮ１７）、次のユーザについて前記同様の処理を行う。すべてのユーザに対する処理が終わったら（ステップＮ１８のＹｅｓ）、ここでの一連の処理を終了する。

以後、サーバ装置１１は、自動共有情報テーブルＴＡ７に登録されたユーザのペアに対し、会話成立の有無に関係なく、互いのアイテムをアクセスできる権限を与える（ステップＮ１９）。具体的には、図３３に示した自動共有情報テーブルＴＡ７に記録された自動共有情報を各ユーザの端末装置に与える。これにより、各ユーザの端末装置では、他の端末装置からアクセスを受けた際に、前記自動共有情報に基づいて共有相手であるか否かを判断し、共有相手であれば、共有可能なアイテムのリストを送信する。

図３３の例であれば、ユーザａから見た共有相手はユーザｂとユーザｃである。したがって、ユーザｂの端末装置１２ｂとユーザｃの端末装置１２ｃからアクセスがあれば、共有相手であると判断して、共有可能なアイテムのリストを送信することになる。

図３４および図３５にアイテムリスト画面の一例を示す。図３４は共有相手が最近見たアイテムのリストを表示した例、図３５は共有相手がよくアクセスするアイテムのランキングを表示した例である。これらのアイテムリストは、アイテムテーブルＴＢ３（図６）を参照して作成される。このアイテムリスト画面上で所望のアイテムを指定すると、自分の端末装置から共有相手の端末装置に対してアイテム要求が送られ、その応答として当該アイテムのデータが返信されることになる。

このように本発明の第７の実施形態によれば、アイテムを相互に共有する可能性が高いユーザのペアを検出し、そのアイテムへのアクセス権限を自動付与することによって、その共有相手のアイテムを簡単に入手できるようになる。

また、共有相手がアクセスするアイテムの統計データをとることによって、そのユーザにとって重要そうなアイテムを発見することができる。

なお、前記各実施形態では、ＲＦＩＤ方式のタグを用いてユーザの位置を検出する構成としたが、ＲＦＩＤに限らず、例えば無線ＬＡＮ（Local Area Network）や赤外線通信、可視光通信などを利用して、ユーザ位置を検出するような構成であっても良い。

要するに、本発明は前記各実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、前記各実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態で示される全構成要件から幾つかの構成要件が削除されても、「発明が解決しようとする課題」で述べた効果が解決でき、「発明の効果」の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

また、上述した各実施形態において記載した手法は、コンピュータに実行させることのできるプログラムとして、例えば磁気ディスク（フレキシブルディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）、半導体メモリなどの記録媒体に書き込んで各種装置に適用したり、そのプログラム自体をネットワーク等の伝送媒体により伝送して各種装置に適用することも可能である。本装置を実現するコンピュータは、記録媒体に記録されたプログラムあるいは伝送媒体を介して提供されたプログラムを読み込み、このプログラムによって動作が制御されることにより、上述した処理を実行する。

図１は本発明の第１の実施形態に係るデータ共有システムの構成を示すブロック図である。 図２は同実施形態におけるデータ共有システムのサーバ装置に設けられるユーザ個人情報テーブルの構成を示す図である。 図３は同実施形態におけるデータ共有システムのサーバ装置に設けられるユーザ端末情報テーブルの構成を示す図である。 図４は同実施形態におけるデータ共有システムの端末装置に設けられる会話履歴テーブルの構成を示す図である。 図５は同実施形態におけるデータ共有システムの端末装置に設けられる会話参加者テーブルの構成を示す図である。 図６は同実施形態におけるデータ共有システムの端末装置に設けられるアイテムテーブルの構成を示す図である。 図７は同実施形態におけるデータ共有システムに用いられるサーバ装置の構成を示すブロック図である。 図８は同実施形態におけるデータ共有システムに用いられる端末装置の構成を示すブロック図である。 図９は同実施形態におけるデータ共有システムに用いられるＩＤタグリーダの構成を示すブロック図である。 図１０は同実施形態におけるデータ共有システムのサーバ装置と端末装置とＩＤタグリーダとの関係を説明するための図である。 図１１は同実施形態における端末装置の会話履歴の作成・データ送信処理を示すフローチャートである。 図１２は同実施形態における端末装置の操作履歴の記録処理を示すフローチャートである。 図１３は同実施形態におけるサーバ装置のユーザ情報送信処理を示すフローチャートである。 図１４は同実施形態における端末装置の会話履歴のデータ受信・保存処理を示すフローチャートである。 図１５は同実施形態における端末装置のデータ表示処理を示すフローチャートである。 図１６は同実施形態における端末装置の会話履歴リストの表示画面の一例を示す図である。 図１７は本発明の第２の実施形態に係るデータ共有システムの構成を示すブロック図である。 図１８は同実施形態におけるデータ共有システムのサーバ装置に設けられたデバイス位置情報テーブルの構成を示す図である。 図１９は同実施形態におけるデータ共有システムのサーバ装置に設けられたＩＤタグ位置履歴情報テーブルの構成を示す図である。 図２０は同実施形態におけるデータ共有システムのサーバ装置と端末装置とＩＤタグリーダとの関係を説明するための図である。 図２１は同実施形態におけるサーバ装置の会話履歴の作成・データ送信処理を示すフローチャートである。 図２２は本発明の第３の実施形態におけるデータ共有システムのデスクトップ共有処理を示すフローチャートであり、図２２（ａ）はデスクトップ共有のホストとなる端末装置側の処理を示すフローチャート、同図（ｂ）はデスクトップ共有のクライアントとなる端末装置側の処理を示すフローチャートである。 図２３は本発明の第４の実施形態における端末装置に設けられたアクセス許可方式のアイテムテーブルの構成を示す図である。 図２４は同実施形態における端末装置のアクセス許可ルールの設定処理を示すフローチャートである。 図２５は同実施形態における端末装置に設けられたアクセス許可ルールテーブルの構成を示す図である。 図２６は同実施形態における端末装置のアクセス許可処理を示すフローチャートである。 図２７は同実施形態における端末装置のファイルへのアクセス判定処理を示すフローチャートである。 図２８は本発明の第５の同実施形態における端末装置の操作履歴の表示処理を示すフローチャートである。 図２９は本発明の第６の実施形態に係るデータ共有システムの構成を示すブロック図である。 図３０は同実施形態におけるサーバ装置のスケジューラと連動した会話履歴の作成・データ送信の処理動作を示すフローチャートである。 図３１は同実施形態におけるサーバ装置のスケジューラ画面の一例を示す図であり、図３１（ａ）は会話参加ユーザの会議前のスケジューラ画面、同図（ｂ）は会話参加ユーザの会議後のスケジューラ画面、同図（ｃ）は会話参加ユーザの会議後の関連アイテム画面を示す図である。 図３２は本発明の第７の実施形態におけるサーバ装置のアイテムの自動共有判定処理を示すフローチャートである。 図３３は同実施形態におけるサーバ装置に設けられた自動共有情報テーブルの構成を示す図である。 図３４は同実施形態における端末装置のアイテムリスト画面の一例を示す図である。 図３５は同実施形態における端末装置のアイテムリスト画面の一例を示す図である。

符号の説明

１１…サーバ装置、１２ａ，１２ｂ，１２ｃ，１２ｄ…端末装置、１３…ネットワーク、１４ａ，１４ｂ，１４ｃ…ＩＤタグ、１５ａ，１５ｂ，１５ｃ，１５ｄ…ＩＤタグリーダ、１６…データベース、１７ａ，１７ｂ，１７ｃ，１７ｄ…データベース、１８ａ，１８ｂ…リーダ＋通信デバイス、２１…ＣＰＵ、２２…ＲＯＭ、２３ａ…制御プログラム、２４…ＲＡＭ、２５…外部記憶装置、２６…補助記憶装置、２７…キー入力装置、２８…表示装置、２９…通信インタフェース（通信Ｉ／Ｆ）、３１…ＣＰＵ、３２…ＲＯＭ、３３ａ…制御プログラム、３４…ＲＡＭ、３５…外部記憶装置、３６…補助記憶装置、３７…キー入力装置、３８…表示装置、３９…通信インタフェース（通信Ｉ／Ｆ）、４１…ＣＰＵ、４２…ＲＯＭ、４３ａ…制御プログラム、４４…ＲＡＭ、４５…通信インタフェース（通信Ｉ／Ｆ）、４６…ＩＤタグ通信Ｉ／Ｆ、ＴＡ１…ユーザ個人情報テーブル、ＴＡ２…ユーザ端末情報テーブル、ＴＡ３…デバイス位置情報テーブル、ＴＡ４…ＩＤタグ位置履歴情報テーブル、ＴＡ５…会話履歴テーブル、ＴＡ６…スケジュール管理テーブル、ＴＡ７…自動共有情報テーブル、ＴＢ１…会話履歴テーブル、ＴＢ２…会話参加者テーブル、ＴＢ３…アイテムテーブル、ＴＢ４…アクセス許可方式のアイテムテーブル、ＴＢ５…アクセス許可ルールテーブル、ＴＢ６…スケジュール管理テーブル。

Claims (13)

1. 使用を割り当てられた端末装置を使用する各ユーザに付けられたＩＤタグと、
   このＩＤタグの情報を非接触で検出するタグ検出装置と、
   各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理する管理テーブルと、
   前記タグ検出装置によって検出されたＩＤタグに基づいて前記管理テーブルを参照してユーザが持つ端末装置を特定する端末特定手段と、
   前記タグ検出装置による前記ＩＤタグの検出期間中に前記端末特定手段によって特定された端末装置上で操作されたデータを共有用として保持するデータ保持手段と、
   このデータ保持手段に保持されたデータを当該ユーザの近くに存在する他のユーザが持つ端末装置との間で共有化する共有化制御手段と
   を具備したことを特徴とするデータ共有化システム。
2. 前記タグ検出装置によって検出されたＩＤタグを持つユーザの端末装置を共有先として設定する共有設定手段を備え、
   前記共有化制御手段は、前記共有設定手段によって共有先として設定された端末装置のデスクトップを他の端末装置との間で共有化することを特徴とする請求項１記載のデータ共有化システム。
3. 前記データ保持手段に保持されたデータに対してアクセス許可ルールを設定するアクセス許可ルール設定手段を備え、
   前記共有化制御手段は、前記データ保持手段に保持されたデータを有する端末装置に他の端末装置がアクセスした際に、前記アクセス許可ルール設定手段によって設定されたアクセス許可ルールに基づいて当該データの共有化を制御することを特徴とする請求項１記載のデータ共有化システム。
4. 操作履歴の表示を指示する表示指示手段を備え、
   前記共有化制御手段は、前記表示指示手段による操作履歴の表示指示に従って、前記データ保持手段を参照して、所定期間内に操作されたデータの履歴をリスト化して表示することを特徴とする請求項１記載のデータ共有化システム。
5. 各ユーザのスケジュールを管理するスケジュール管理テーブルを備え、
   前記共有化制御手段は、前記タグ検出装置によって検出されたＩＤタグに基づいて同じ場所に存在する各ユーザを特定して、これらのユーザのスケジュールを前記スケジュール管理テーブルから読み出し、現場面に関するスケジュールが未登録のユーザに当該スケジュールを登録することを特徴とする請求項１記載のデータ共有化システム。
6. 前記共有化制御手段は、各ユーザが参照したデータを当該スケジュールの関連データとして前記スケジュール管理テーブルに登録することを特徴とする請求項１記載のデータ共有化システム。
7. 前記タグ検出装置によって検出されたＩＤタグに基づいて、互いに近くにいる頻度の高いユーザのペアを共有対象として記憶する共有対象記憶手段を備え、
   前記共有化制御手段は、前記共有対象記憶手段に記憶されたユーザのペアに対し、互いの端末装置が持つデータへのアクセス権限を与えることを特徴とする請求項１記載のデータ共有化システム。
8. 各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理するサーバ装置にネットワークを介して接続された端末装置であって、
   自端末の使用者以外のユーザに付けられたＩＤタグを検出するタグ検出手段と、
   このタグ検出手段によるＩＤタグの検出期間中に操作されたデータを共有用として保持するデータ保持手段と、
   前記タグ検出手段によって検出されたＩＤタグを持つユーザの情報を前記サーバ装置に問い合わせて取得するユーザ情報取得手段と、
   このユーザ情報取得手段によって得られたユーザ情報に基づいて、前記データ保持手段に保持されたデータを自端末の使用者の近くに存在する他のユーザが持つ端末装置に送信するデータ送信手段と
   を具備したことを特徴とする端末装置。
9. 自端末の使用者と前記タグ検出手段によって検出されたＩＤタグを持つユーザとの間で会話が成立しているか否かを判断する会話判断手段を備え、
   前記データ送信手段は、前記会話判断手段によって会話が成立すると判断された場合に、前記データ保持手段に保持されたデータを会話相手であるユーザの端末装置に送信することを特徴とする請求項８記載の端末装置。
10. 各ユーザが使用を割り当てられた端末装置にネットワークを介して接続されたサーバ装置であって、
    各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理する第１の管理テーブルと、
    前記ＩＤタグの情報を非接触で検出するタグ検出装置の設置位置に関する情報を管理する第２の管理テーブルと、
    前記タグ検出装置によって検出されたＩＤタグに基づいて前記第２の管理テーブルを検索し、互いに近くに存在するユーザのグループを検出するグループ検出手段と、
    このグループ検出手段によって検出されたグループ内の各ユーザが持つ端末装置を前第１の管理テーブルから特定する端末特定手段と、
    この端末特定手段によって特定された各ユーザの端末装置から前記タグ検出装置によるＩＤタグの検出期間中に操作されたデータを取得する操作データ取得手段と、
    この操作データ取得手段によって得られた各データを前記各ユーザの端末装置に送信するデータ送信手段と
    を具備したことを特徴とするサーバ装置。
11. 前記各ユーザ間で会話が成立しているか否かを判断する会話判断手段を備え、
    前記データ送信手段は、前記会話判断手段によって会話が成立すると判断された場合にのみ、前記操作データ取得手段によって得られた各データを前記各ユーザの端末装置に送信することを特徴とする請求項１０記載のサーバ装置。
12. 各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を管理するサーバ装置にネットワークを介して他の端末装置と共に接続された端末装置を制御するためのコンピュータによって実行されるプログラムであって、
    前記コンピュータに、
    自端末の使用者以外のユーザに付けられたＩＤタグを検出する機能と、
    前記ＩＤタグの検出期間中に操作されたデータを共有用として所定のメモリに保持する機能と、
    前記ＩＤタグを持つユーザの情報を前記サーバ装置に問い合わせて取得する機能と、
    前記サーバ装置から得られたユーザ情報に基づいて、前記メモリに保持されたデータを自端末の使用者の近くに存在する他のユーザが持つ端末装置に送信する機能と
    を実現するためのコンピュータ読み取り可能なプログラム。
13. 各ユーザが使用を割り当てられた端末装置にネットワークを介して接続されたサーバ装置を制御するためのコンピュータによって実行されるプログラムであって、
    前記コンピュータに、
    各ユーザが使用を割り当てられた端末装置と各ユーザに付けられたＩＤタグに関する情報を第１の管理テーブルに記憶する機能と、
    前記ＩＤタグの情報を非接触で検出するタグ検出装置の設置位置に関する情報を第２の管理テーブルに記憶する機能と、
    前記タグ検出装置によって検出されたＩＤタグに基づいて前記第２の管理テーブルを検索し、互いに近くに存在するユーザのグループを検出する機能と、
    前記グループ内の各ユーザが持つ端末装置を前第１の管理テーブルから特定する機能と、
    前記各ユーザの端末装置から前記タグ検出装置によるＩＤタグの検出期間中に操作されたデータを取得する機能と、
    前記取得した各データを前記各ユーザの端末装置に送信する機能と
    を実現するためのコンピュータ読み取り可能なプログラム。

Images