JP2005228270A - ファイル共有システム - Google Patents

Abstract

【課題】 共有ファイルと共有者の名称とを関連付けてファイルを管理するファイル共有システムを提供する。
【解決手段】 ユーザから他のユーザと共有を希望するファイルを受信したファイル共有装置は、ファイルの名称及びファイルに共有者を表す属性を付与して各共有者の作業領域に保存する。したがって、ユーザは、ファイルの名称又は共有者の名称を手掛かりに、ファイルを検索することができる。なお、ファイルの更新の有無の通知を要求することができる。さらに、各共有ファイルには、ファイルが格納されている場所を示すｕｒｌが付されており、ユーザはｕｒｌを手掛かりにファイルを取得又は更新できる。
【選択図】 図１

Description

本発明は、ファイル共有システムに関し、特に、ネットワークへの負担をかけずにファイルを共有可能なファイル共有システムに関するものである。

近年、オフィスにおけるドキュメントのほとんどが電子化されている。この電子化のメリットを活かし、オフィス文書をファイルサーバなどにおいて、チームのメンバーで共有して運用する要求が高まっている。実際、多くのグループウェアが商品化されている。さらに、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（Ｒ）オペレーティングシステムでも、チームのメンバー全員がアクセスできるいわゆる「共有フォルダ」を簡単に作成することができる。この仕組みにより電子ファイルを共有する環境を構築している例も多くみられる。

ファイルをチームメンバーで共有する場合、ネットワーク上のしかるべき場所に共有のスペースを確保する。このスペースは、チームメンバーがアクセスできるようにアクセス権が設定されていて、共有したいファイルを各ユーザが登録（コピー）して運用している。この方法は、共有したいファイルを全員に電子メールなどで送る場合と比較し、ネットワークへの負担が軽減、及び記憶領域への圧迫が少ないというメリットがある。

特許文献１は、電子メールにファイルを添付し、ファイルを共有したい相手に送信するときに、途中で添付ファイルをサーバに保存し、保存されたファイルの参照のみを送付先に送るファイル共有方法等を提案している。したがって、通常の電子メールを送信する方法で、ユーザビリティの低下、ネットワークへの負荷、記憶領域の圧迫等の問題を発生させずに、ファイルを共有することができる。
特開２００２−３４２２４９号公報

しかしながら、上記の手段は以下に述べる問題点を有している。

ネットワーク上にチームメンバーで共有するファイルを記憶するスペースを確保する方法は、サーバへの登録操作が煩雑である。さらに、ファイルをサーバへ登録するとき、ネットワークに負担がかかる。そのため、操作のレスポンスが悪く、利用者は待ち時間を強いられる。よって、利用者のユーザビリティは決して高いとは言えない。

また、上記従来技術は、操作に違いがあるが、いずれも通信制御を行うサーバにファイルを記憶しておく点で共通している。この場合、ユーザは、普段の仕事中に作成・編集したりする文書など作業領域にあるファイルと、サーバに登録されて共有状態にあるファイルとの関連性をファイル名など手掛かりにして記憶しておかなければならない。

例えば、実際のオフィスにおいては、文書を共有とした後に、その文書を改訂する場合やその文書の共有状態を維持しつつ内容を逐次更新する場合が多々みられる。そのため、文書を共有とした後、文書が更新さると、サーバに登録したファイルとの関連性が途絶えてしまう。よって、ユーザは、サーバに登録した後の編集作業を文書が記憶されているサーバ上で行うか、若しくは文書の編集作業を行った後、サーバ上の共有ファイルを検索し、編集作業を行ったファイルと置き換えるなどの煩雑な作業を強いられることとなる。つまり、個人ごとのフォルダのレイアウトと共有フォルダのレイアウトとの間で、関連性が分断される。仮に、個人の作業を共有フォルダ中心に行った場合、共有フォルダは個人の作業領域とは異なる構成をとるため、個人の作業効率は著しく低下する。

また、共有フォルダ上では、ファイル名やフォルダ内でのレイアウトがチームごとに異なる構成となっていることが多い。通常、元のファイルを作成したユーザ個人の作業領域は、共有フォルダが設けられている領域と異なる。よって、ユーザ個人の作業領域におけるフォルダのレイアウトは、ユーザごとに理由があり、仕事の種類別、作成時刻別、内容別等、千差万別である。

つまり、ユーザ個人の作成領域におけるフォルダのレイアウトは、ユーザごとの思考の違いにより作成されたものであり、ユーザは自分の思考パターンに合わせてレイアウトすることで、必要な情報を迅速に検索できる。また、仕事の優先順位を把握することができ、ユーザの作業の文脈を捉えることができる。

また、グループウェアや一般のＷｅｂサーバ上に共通の登録スペースを確保し、その登録スペースに共有ファイルを保存した場合、ユーザは、グループウェアやＷｅｂサーバ上のファイルを直接アプリケーションで開くことはできるが、上書き保存する際にローカルマシンのテンポラリファイルを書き換えにとどまる。したがって、共有フォルダ上のファイルをローカルマシン内にあるファイルと同様に編集・更新することはできない。

そこで、本発明は、個人のユーザがファイルを作成・編集する作業領域に配置された個々のファイルを、ユーザ個人の作業環境を維持しつつ、チームメンバーで共有することができるファイル共有システムを提供することを目的としている。

請求項１記載の発明は、複数の情報処理端末とファイル共有装置とがネットワークを介して接続されたファイル共有システムにおいて、各情報処理端末は、自端末が保持する情報を前記ファイル共有装置へ送信する手段と、前記情報の一覧から前記複数の情報処理端末と共有する情報を選択する手段と、前記ファイル共有装置は、前記情報処理端末から取得した情報を送信元の端末を操作する前記情報処理端末のユーザごとに格納する手段と、前記送信元の端末を操作するユーザの情報の一覧を前記送信元に表示させる手段と、前記選択された情報に共有者を表す属性を付与する手段とを有することを特徴とする。

請求項２記載の発明は、複数の情報処理端末とファイル共有装置とがネットワークを介して接続されたファイル共有システムにおいて、各情報処理端末は、自端末が保持する情報を前記ファイル共有装置へ送信する手段と、前記情報の一覧から前記複数の情報処理端末と共有する情報を選択する手段と、前記ファイル共有装置は、前記情報処理端末から取得した情報を送信元の端末を操作する前記情報処理端末のユーザごとに格納する手段と、前記送信元の端末を操作するユーザの情報の一覧を前記送信元に表示させる手段と、前記情報を共有する少なくとも１人からなるグループに固有の名称を付与する手段と、前記選択された情報に前記固有の名称を表す属性を付与する手段とを有することを特徴とする。

請求項３記載の発明は、請求項１又は２記載のファイル共有システムにおいて、前記ファイル共有装置は、属性が付与された前記情報の一覧を表示する第１の表示手段と、前記情報を開示する開示手段と、前記情報処理端末によって編集された前記情報を保存する保存手段と前記情報処理端末は、属性が付与された前記情報の一覧の表示を要求する手段と、前記第１の表示手段によって表示された前記情報の一覧から情報を選択する第１の選択手段と、前記開示手段によって開示された前記情報を編集する編集手段と、前記編集手段によって編集した前記情報を前記ファイル共有装置に送信する送信手段とを有することを特徴とする。

請求項４記載の発明は、請求項１から３のいずれか１項記載のファイル共有システムにおいて、前記ファイル共有装置に格納された前記情報が共有状態になったとき、前記ファイル共有装置は、前記ユーザが前記情報を参照するためのｕｒｌを生成する第１の生成手段と、前記第１の生成手段によって生成されたｕｒｌと前記情報の名称とを関連付ける手段と、前記情報の名称と関連付けられたｕｒｌと前記共有者との第１の対応表を作成する手段と前記第１の対応表を記憶する手段とを有することを特徴とする。

請求項５記載の発明は、請求項１から３のいずれか１項記載のファイル共有システムにおいて、前記ファイル共有装置に格納された前記情報が共有状態になったとき、前記ファイル共有装置は、前記ユーザが前記情報を参照するためのｕｒｌを生成する第１の生成手段と、前記第１の生成手段によって生成されたｕｒｌと前記情報の名称及び前記共有者の名称を表す情報とを関連付ける手段と、前記情報の名称及び前記共有者の名称を表す情報と関連付けられたｕｒｌと前記共有者との第２の対応表を作成する手段と、前記第２の対応表を記憶する手段とを有することを特徴とする。

請求項６記載の発明は、請求項４又は５記載のファイル共有システムにおいて、前記情報処理端末は、前記第１の対応表又は第２の対応表の表示を前記ファイル共有装置に要求する手段と、前記第１の対応表又は第２の対応表から前記情報を選択する第２の選択手段と、前記第２の選択手段によって選択された前記情報のｕｒｌを前記ファイル共有装置に送信する手段と、前記ファイル共有装置は、前記第１の対応表又は第２の対応表を前記情報処理端末に送信する手段と、前記第２の選択手段によって選択された前記情報を前記情報処理端末に送信する手段とを有することを特徴とする。

請求項７記載の発明は、請求項４から６のいずれか１項記載のファイル共有システムにおいて、前記情報処理端末は、前記第１の対応表又は第２の対応表の表示を前記ファイル共有装置に要求する手段と、前記第１の対応表１又は前記第２の対応表から更新の有無の通知が必要な前記情報のｕｒｌを選択する第３の選択手段と、前記通知が必要な情報のｕｒｌの更新時刻と前記情報処理端末に格納された情報の更新時刻とを比較する比較手段と、前記情報処理端末に格納された情報の更新時刻が前記通知が必要な情報のｕｒｌよりも古いとき、その旨を前記ユーザに表示する手段と、前記情報処理端末に格納されている前記情報を更新する手段と、前記ファイル共有装置は、前記通知が必要な情報のｕｒｌの更新時刻を前記情報処理端末に送信する手段と、前記更新された情報を前記情報処理端末に送信する手段とを有することを特徴とする。

請求項８記載の発明は、請求項３から７のいずれか１項記載のファイル共有システムにおいて、前記第１の表示手段は、前記情報の一覧を属性別に表示することを特徴とする。

請求項９記載の発明は、請求項３から７のいずれか１項記載のファイル共有システムにおいて、前記第１の表示手段は、前記情報の作成者別に表示することを特徴とする。

請求項１０記載の発明は、請求項３から７のいずれか１項記載のファイル共有システムにおいて、前記第１の表示手段は、前記ユーザが自ら共有化した前記情報と前記ユーザが自ら共有化してない前記情報とを区別して表示することを特徴とする。

請求項１１記載の発明は、請求項４から７のいずれか１項記載ファイル共有システムにおいて、前記第１の表示手段は、前記情報の一覧と前記情報のｕｒｌの一覧とを属性別に表示することを特徴とする。

請求項１２記載の発明は、請求項４から７のいずれか１項記載のファイル共有システムにおいて、前記第１の表示手段は、前記情報のｕｒｌの一覧を属性別に表示することを特徴とする。

本発明は、ユーザ個人の作業領域と共有の作業領域にあるファイルとがシームレスにつながっているため、個人の作業領域において共有ファイルを作成・編集することができ、グループワークの作業効率に著しい向上を期待できる。

本発明は、ファイルを共有する各ユーザの作業領域に共有するファイルを格納することで、ユーザは、共有化されたファイルを自分の作業領域内の好きな場所へ保存することができる。なお、ユーザは、サーバに対して共有するファイルの内容に関する更新の通知を要求できる。さらに、ユーザは、共有するファイルの一覧を共有するファイルに付された属性を利用して、該属性別に表示することができる。

図１及び図２は、本発明を適用したファイル共有システムの構成を示すブロック図である。ｃ１、ｃ２、及びｃ３は、ユーザが使用するパソコンである。各パソコンのディスク（ｄｉｓｋ１、ｄｉｓｋ２、ｄｉｓｋ３）が各ユーザの作業領域である。ユーザは、この作業領域上で、様々なアプリケーションにより電子文書ファイルを作成、編集、及び保存する。各ユーザとサーバはネットワークを介して接続されている。

図１に示すファイル共有システムにおけるユーザの作業領域（ｄｉｓｋ）は、各ユーザのパソコンに直接接続されている。一方、図２に示すファイル共有システムにおける作業領域（ｄｉｓｋ）はネットワーク上のサーバにある。各ユーザは、パソコンからその作業領域を参照してファイルの作成、編集、及び保存作業を実行する。

図３は、ユーザがパソコンから自分の作業領域であるｄｉｓｋ内のファイルを参照した場合のビューであり、現在参照しているフォルダ内のファイルの一覧である。なお、異なるフォルダへの移動などのファイルを操作するためのメニューは省略している。

それぞれのファイルは、ワープロや表計算ソフトなどで作成した文書ファイルである。このビューを生成するプログラムをｖｉｅｗｅｒと呼ぶ。ｖｉｅｗｅｒは、ＭＳ−Ｗｉｎｄｏｗｓ（Ｒ）のＥｘｐｌｏｒｅｒに相当するものであり、本発明を適用したファイル共有システムをＭＳ−Ｗｉｎｄｏｗｓ（Ｒ）で起動した場合、Ｅｘｐｌｏｒｅｒの代わりに使うものである。ｖｉｅｗｅｒは、ビューに表示されるファイルへのユーザの操作を検知し、対応する処理を実行する。ｖｉｅｗｅｒが実行する主な処理は、１）対応アプリケーションでのファイルの起動、２）Ｄｒａｇ＆Ｄｒｏｐによるフォルダ間でのファイルの移動、３）クリックによるファイルの指定とファイルの属性変更等がある。ｖｉｅｗｅｒは、ユーザが操作するパソコンにおける本発明を適用したファイル共有システムの主要なプログラムであり、ユーザが接するメインプログラムである。

図３で示した文書ファイルに対して、これと一対一で対応するメタファイルが文書ファイルと同一の場所に生成される。文書ファイルとメタファイルの対応関係を表１に示す。

メタファイルは文書ファイルと同じ名前で、拡張子はｍｅｔａで表現される。メタファイルは、ユーザが直接編集するものではない。そのため、このシステムでは不可視な状態にある。したがって、図３に示すビュー上には表示されない。

ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されたメタファイルの例を図４に示す。文書ファイルとメタファイルの区別はファイル名が記述されているか否か判断する。したがって、メタファイル内に文書ファイル名を示す記載は存在しない。

次に、メタファイル内の各要素の意味を説明する。＜ｏｗｎｅｒ＞は文書ファイルの所有者（オーナー）である。通常、文書ファイルの生成と同時にメタファイルの生成、及びｏｗｎｅｒの設定が実行される。ｏｗｎｅｒはオペーレーティングシステムの標準的な記憶領域である。オペーレーティングシステムがＭＳ−Ｗｉｎｄｏｗｓ（Ｒ）の場合、ｏｗｎｅｒは、レジストリや環境変数から取得される。図４においては、「田中」である。

＜ｓｈａｒｅ＞は該当するファイルが共有状態にあるか否かを示している。ｔｒｕｅの場合は、共有状態にあり、＜ｓｈａｒｅ＿ｗｉｔｈ＞で示される要素を対象に、対応するファイルを共有状態とする。一方、ｆａｌｓｅの場合は、対応するファイルは非共有状態にある。ここで、＜ｓｈａｒｅ＿ｗｉｔｈ＞は、対応するファイルを共有する対象を示すタグである。ファイルを共有する対象としては、「グループ」と「個人」がある。「グループ」は「人」のリストである。「グループ」を共有対象として設定されている場合は、グループに含まれる人がファイルを共有する対象となる。

＜ｇｒｏｕｐｓ＞は、＜ｇｒｏｕｐ＞の集まりを表す。＜ｇｒｏｕｐｓ＞の中には、複数の＜ｇｒｏｕｐ＞を設定することができる。＜ｇｒｏｕｐ＞は、要素＜ｎａｍｅ＞と＜ｍｏｄｉｆｙ＞から構成される。＜ｎａｍｅ＞は「グループ名」又は「個人名」を表し、＜ｇｒｏｕｐ＞内に複数の＜ｎａｍｅ＞を設定することができる。一方、＜ｍｏｄｉｆｙ＞は、＜ｎａｍｅ＞で設定されているグループや個人に対して、対象ファイルの編集を許可するか否かを示している。ｔｒｕｅの場合は、グループ又は個人は対象ファイルを編集できる。一方、ｆａｌｓｅの場合は、＜ｎａｍｅ＞に設定されているグループや個人であっても対象ファイルを編集することはできない。＜ｎａｍｅ＞は、グループ名及びユーザ名を表している。なお、＜ｎａｍｅ＞を構成するリストは、ディレクトリサーバなどで別に管理されているため、ここでは記述しない。

＜ｉｎｄｉｖｉｄｕａｌｓ＞は、＜ｇｒｏｕｐ＞を構成する＜ｉｎｄｉｖｉｄｕａｌ＞の集まりを表している。ここで、＜ｉｎｄｉｖｉｄｕａｌ＞は個人を表し、＜ｉｎｄｉｖｉｄｕａｌｓ＞の中に複数の＜ｉｎｄｉｖｉｄｕａｌ＞を設定することができる。＜ｉｎｄｉｖｉｄｕａｌ＞は、＜ｇｒｏｕｐ＞と同様に＜ｎａｍｅ＞と＜ｍｏｄｉｆｙ＞から構成される。＜ｎａｍｅ＞と＜ｍｏｄｉｆｙ＞は、＜ｇｒｏｕｐ＞と＜ｉｎｄｉｖｉｄｕａｌ＞の中に少なくとも一づつ存在する。

＜ｕｒｌ＞は、＜ｓｈａｒｅ＞がｔｒｕｅの場合において、＜ｏｗｎｅｒ＞以外の対象ファイルを共有するユーザが、対象ファイルを参照するためのｕｒｌである。一方、＜ｓｈａｒｅ＞がｆａｌｓｅのときは、＜ｕｒｌ＞はｎｕｌｌで、ファイルは共有化されていない。

次に、ｖｉｅｗｅｒ起動中にユーザが新規のファイルの作成を行った場合に実行される処理について説明する。ここで、作業フォルダとは、ユーザが作業用にｖｉｅｗｅｒで指定したフォルダ以下の全フォルダを示すものとする。作業フォルダで新規ファイルが生成されると（ステップＳ５０１）、生成されたファイルと同じフォルダにメタファイルが生成される（ステップＳ５０２）。図６は、ＸＭＬで記述された初期状態のメタファイルの例である。新規ファイルが作成され、メタファイルが生成されると同時に、新規ファイルのｏｗｎｅｒが設定される。その際、メタファイルは初期状態にあるため、ファイルは共有状態にない。したがって、ファイルの共有状態を示す＜ｓｈａｒｅ＞は、ｆａｌｓｅとなっている。ファイルが非共有状態にあるため、ファイルを共有するグループや個人なども設定されていない。また、新規のファイルを参照するための＜ｕｒｌ＞もｎｕｌｌとなっている。

次に、文書ファイルの属性変更が要求された場合の動作について説明する。文書ファイルの属性変更には、（１）文書ファイルの共有化／非共有化、（２）共有対象グループの変更、（３）共有対象者の変更、（４）共有対象グループ又は共有対象者の文書ファイル編集の可否等が考えられる。

ユーザが文書ファイルの属性変更を行う際の具体的な操作手順について説明する。まず、（ｉ）ｖｉｅｗｅｒでファイルの一覧を表示する。（ii）ファイルの一覧から属性変更を行いたいファイルをマウスでクリックし、選択状態とする。（iii ）ｖｉｅｗｅｒに設置された「属性変更」メニューから上記の（１）から（４）のうち所望の項目を選択する。このとき、グラフィカルユーザインターフェース（以下、ＧＵＩとする。）は、例えばＭＳ−Ｗｉｎｄｏｗｓ（Ｒ）で標準的に用いられている手順を採用する。

（iii ）において「属性変更」メニューから所望の項目が選択されると、ＧＵＩによって入力された属性をメタファイルに反映させるために、ｖｉｅｗｅｒはファイル属性変更要求イベントを発生し（ステップＳ７０１）、ファイル属性変更要求イベントを検知すると、メタファイルの更新処理を実行する。メタファイルの更新処理は、ＧＵＩによりユーザが入力した値を先に述べた形式で書き込み、メタファイルを更新する（Ｓ７０２）。

次に、メタファイルの＜ｓｈａｒｅ＞をｆａｌｓｅに設定する場合（ステップＳ７０３／ＮＯ）、メタファイルのｕｒｌが設定されているか否かを判別する（ステップＳ７０４）。メタファイルのｕｒｌが設定されているときは（ステップＳ７０４／ＹＥＳ）、これを削除する（ステップＳ７０５）。一方、メタファイルのｕｒｌが設定されていないときは（ステップＳ７０４／ＮＯ）、メタファイルの更新処理は終了する。

メタファイルの＜ｓｈａｒｅ＞をｔｒｕｅに設定する場合（ステップＳ７０３／ＹＥＳ）、メタファイルの＜ｕｒｌ＞がｎｕｌｌならば（ステップＳ７０６／ＹＥＳ）、サーバに対しｕｒｌの割り当てを要求する（ステップＳ７０７）。サーバからユニークなｕｒｌを取得すると（ステップＳ７０８）、更新したメタファイルと文書ファイルで＜ｕｒｌ＞に規定されるｕｒｌを更新する（ステップＳ７０９、ステップＳ７１０）。すなわち、ｕｒｌに対してメタファイルと文書ファイルとを上書きする。具体的には、ｕｒｌ／ｄｏｃ及びｕｒｌ／ｍｅｔａを文書ファイルとメタファイルで上書きする。

次に、ｖｉｅｗｅｒ起動中にユーザが文書ファイルを更新した場合の動作について、図８を用いて説明する。ファイルが更新されると（ステップＳ８０１）、ｖｉｅｗｅｒはそのファイルに対応するメタファイルを参照する（ステップＳ８０２）。参照したメタファイルの＜ｓｈａｒｅ＞がｆａｌｓｅの場合は（ステップＳ８０３／ＮＯ）、メタファイルの＜ｕｒｌ＞の更新は実行されず、更新処理は終了する。一方、参照したメタファイルの＜ｓｈａｒｅ＞がｔｒｕｅの場合は（ステップＳ８０３／ＹＥＳ）、メタファイルの＜ｕｒｌ＞を参照し、更新されたファイルでｕｒｌを更新する（ステップＳ８０４）。

次に、ｖｉｅｗｅｒ起動中にユーザが文書ファイルを削除する動作について図９を用いて説明する。ファイルが削除されると（ステップＳ９０１）、ｖｉｅｗｅｒはその文書ファイルに対応するメタファイルを参照する（ステップＳ９０２）。参照したメタファイルの＜ｓｈａｒｅ＞がｔｒｕｅの場合は（ステップＳ９０３／ＹＥＳ）、ｕｒｌが削除され（ステップＳ９０４）、同時にメタファイルも削除される（ステップＳ９０５）。一方、参照したメタファイルの＜ｓｈａｒｅ＞がｆａｌｓｅの場合は（ステップＳ９０３／ＮＯ）、メタファイルが削除され（ステップＳ９０５）、文書ファイルを削除する処理は終了する。

次に、本発明を適用したファイル共有システムのサーバが実行する動作について図１０を用いて説明する。図１に示すネットワーク上にあるサーバは、図１０に示すサービスプロセスを実行している。サーバが有するサービスプロセスは、ディレクトリサービス１００、メタファイル登録サービス１０１、メタファイル更新サービス１０２、メタファイル削除サービス１０３、Ｗｅｂサービス１０４、文書ファイル登録サービス１０５、文書ファイル更新サービス１０６、文書ファイル削除サービス１０７、ＵＲＬ割り当てサービス１０８、ストレージサービス１０９、ＵＲＬ削除サービス１１０、及びＵＲＬ通知サービス１１１からなる。

ディレクトリサービス１００は、ユーザ名及びグループ名を管理している。グループ名は、運用する組織に対応して管理者によって予め設定されている。グループは、ユーザ名のリストである。グループ名はアカウントを有するユーザが自由に設定することができる。例えば、規定の組織では記述できない、いつも一緒に仕事するメンバーを「○○開発グループ」と定義することもできる。ディレクトリサービス１００は、「ファイル属性変更」のセクションで述べた属性を変更するプロセスで、ユーザがファイルを共有する対象者や共有するグループを指定するときに呼び出される。共有名による共有対象者の指定ができるので、「○○開発グループ」などといった共有名によりグループを意識したファイルの共有を可能とし、グループワークの効率を著しく向上させることができる。

ＵＲＬ割り当てサービス１０８は、ユーザからファイルを共有設定にしたいという要求があった場合に（ユーザの作業領域におけるメタファイルの＜ｓｈａｒｅ＞がｔｒｕｅとした場合に）、ユニークなｕｒｌを生成する。ストレージサービス１０９は、生成されたｕｒｌを参照する領域を確保する。ｕｒｌ通知サービス１１１は、ｕｒｌをユーザのパソコンに通知するサービスである。確保されたｕｒｌの下には、ｕｒｌ／ｄｏｃ及びｕｒｌ／ｍｅｔａが生成される。ｄｏｃは、ユーザが共有設定としたいファイルのコピーである。ｍｅｔａは、ユーザパソコンで生成されたｍｅｔａファイルのコピーである。ｕｒｌ／ｄｏｃは、Ｗｅｂサービス１０４によって公開され、共有設定の対象となっているユーザはこれにアクセスすることができる。

ＵＲＬ削除サービス１１０、メタファイル削除サービス１０３、及び文書ファイル削除サービス１０７は、ユーザが共有状態を解除したとき又はユーザがユーザ作業領域から共有対象ファイルを削除したときに、ＵＲＬ、メタファイル、及び文書ファイルを削除するサービスである。

メタファイル登録サービス１０１及び文書ファイル登録サービス１０５は、ユーザがユーザの作業領域にあるファイルを共有設定としたときに、ＵＲＬ割り当てサービス１０８によって割り当てられ、ＵＲＬ通知サービス１１１によって通知されたＵＲＬにｕｒｌ／ｄｏｃ及びｕｒｌ／ｍｅｔａを登録するサービスである。

メタファイル更新サービス及び文書ファイル更新サービス１０６は、ユーザがユーザの作業領域にあるファイルを更新したときに、ｕｒｌ／ｄｏｃ及びｕｒｌ／ｍｅｔａを更新するサービスである。

次に、ｖｉｅｗｅｒが提供するビューについて説明する。通常の作業を行うときは、図３に示すようなビューが表示され、先に述べたような操作が可能である。一方、ファイルを共有している共有対象者には、図１１に示すようなビューが示される。

「人」は共有対象者を表している。共有対象者ごとにファイルを表示している。よって、複数の共有対象者を設定しているファイルは、複数表示されている。例えば、「新規案ドラフト」は、伊藤、加藤、斎藤、鈴木が共有対象者になっているため、４回表示されている。このときの「新規案ドラフト」のメタファイルをＸＭＬで記述した例を図１２に示す。なお、ディレクトリサーバ上での「担当チーム」グループのメンバーは、伊藤、加藤、斎藤である。図１２では、＜ｓｈａｒｅ＿ｗｉｔｈ＞の＜ｇｒｏｕｐｓ＞が「担当チーム」で、＜ｉｎｄｉｖｉｄｕａｌｓ＞が鈴木なので、上記４名がファイルの共有対象者となっている。図１３も図１１と同様にファイルの共有対象者に表示されるビューである。共有対象者ごとにファイルが表示されるため、ファイルを共有する人が複数いるときは、ファイルが複数表示されている。例えば、「予算検討案」は、「スタッフ」及び「担当チーム」が共有対象となっているため、２回表示されている。なお、このときの「新規案ドラフト」のメタファイルをＸＭＬで記述した例を図１２に示す。

次に、各ファイルのｕｒｌを参照する動作について図１４を用いて説明する。ユーザが、図３、図１１、又は図１３で示したビューにおいて、所望のファイルをクリックにより指定し、メニュー操作から「ＵＲＬを参照」の項目を選択することで（ステップＳ１２０１）、そのファイルに対応するメタファイルの＜ｕｒｌ＞を参照することができる（ステップＳ１２０２）。メタファイルファイルの＜ｕｒｌ＞がｎｕｌｌのときは（ステップＳ１２０３／ＹＥＳ）、ｕｒｌは表示されず、動作が終了する。一方、メタファイルの＜ｕｒｌ＞が設定されているときは（ステップＳ１２０３／ＮＯ）、＜ｕｒｌ＞で示される文字列が表示される（ステップＳ１２０４）。表示されたファイルのｕｒｌは、クリップボードにコピーされる（ステップＳ１２０５）。以上の処理により、ユーザは、各ファイルのｕｒｌを参照することができる。

上記においては、ファイルを作成し、相手に対し共有する側（ｏｗｎｅｒ）が行う操作について説明してきたが、以下ではファイルを共有されたユーザ（ファイルを配布されたユーザ）の動作について図１５を用いて説明する。図１５は、図１に示すファイル共有装置の構成を例にしたものである。Ｃｌｉｅｎｔ１のユーザ領域１は、ユーザ１が使用するパソコンに設置されたハードディスクである。Ｓｅｒｖｅｒのユーザ１領域は、クライアントとは別のサーバコンピュータに設置されたハードディスクの内部でユーザ１に割り当てられた記憶領域である。なお、クライアントとサーバは、ネットワークで接続されている。ユーザ１は、ユーザ２とユーザ３とを対象に、ａａａ．ｄｏｃとｃｃｃ．ｐｐｔというファイルを共有設定としている。

ユーザ１がａａａ．ｄｏｃとｃｃｃ．ｐｐｔを共有対象とすると、図７に示した処理によって、それぞれのファイルのメタファイルと共にサーバのユーザ１領域に送信される。サーバは、受信したファイル（ａａａ．ｄｏｃ）に対し、例えばｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ａａａというｕｒｌを割り当てて、このファイルを公開する。このとき、ｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ａａａは、ユーザ１及びユーザ２に対してのみアクセスを許可するようにアクセス制限を付けて公開される。同様にして、ｃｃｃ．ｐｐｔにｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ｃｃｃというｕｒｌを割り当て、ファイルを公開することも可能である。図１５においては、ｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ｃｃｃは、ユーザ１及びユーザ３に対してのみアクセスを許可するようにアクセス制限を付して公開されている。

ファイルを共有設定とする処理が行われると、サーバ上ではファイルを共有する対象者ごとのファイル対応表が作成される。ユーザ２及びユーザ３の各ファイル対応表を表２、表３に示す。表２は、ユーザ２に対してどのファイルが共有対象となっているかが、ｕｒｌの一覧表として格納されている。表３は、ユーザ３に対してどのファイルが共有対象となっているかが、ｕｒｌの一覧表として格納されている。具体的には、図７に示した処理のもとで、ファイルとメタファイルがサーバに送られると、ファイルに対応するメタファイルを参照して＜ｓｈａｒｅ＿ｗｉｔｈ＞と＜ｕｒｌ＞の要素を抜き出し、＜ｓｈａｒｅ＿ｗｉｔｈ＞の要素ごとにｕｒｌを列挙する。

共有設定とされたファイルは共有対象者のパソコンのファイル一覧に表示される。図１５において、Ｃｌｉｅｎｔ３は、ユーザ３が使用するパソコンであり、ユーザ３領域はこのパソコンに設置されたハードディスク内の領域である。ファイル一覧は、ユーザ３がＣｌｉｅｎｔ３で起動するプログラム（以下、ファイル一覧プログラムとする。）によって提供される。なお、ファイル一覧プログラムは、ログイン機能により、利用者がユーザ３であることを認識しているものとする。ファイル一覧プログラムが初期設定にあるとき、ファイルの共有機能をうけるサーバ名が書き込まれ、ファイル一覧プログラムはサーバを認識している。

ファイル一覧プログラムの基本的な機能としては、ユーザ領域３にあるユーザ３が作成したファイルと、サーバ上のユーザ３が共有対象となっているファイルのｕｒｌを表示する。図１５では、ユーザ３領域にサーバ上のファイルｃｃｃ．ｐｐｔのｕｒｌ、ｗｗｗ．ｄｏｃ、ｘｘｘ．ｐｐｔ、ｗｗｗ．ｍｅｔａ、及びｘｘｘ．ｍｅｔａを説明のために表示したが、ｗｗｗ．ｍｅｔａ、及びｘｘｘ．ｍｅｔａは非表示ファイルとして一覧される。

サーバ上にｕｒｌを表示するために、ファイル一覧プログラムは、所定の時間間隔でサーバ上にある共有対象者ごとの一覧表を参照し、ファイル一覧プログラムの表示を更新し、現在の共有対象ファイルを表示する。ファイル一覧プログラムが実行する共有対象者ごとの一覧表を作成する処理を図１６を用いて説明する。ファイル一覧プログラムを起動すると、ユーザのログインが実行される（ステップＳ１６０１）。そして、図示しない認証処理によりユーザの認証が実行される。ログインが終了すると、待機状態に入る。ファイルの一覧の更新が行われると（ステップＳ１６０２）、ファイル一覧プログラムは、サーバにログインしている共有対象者ごとの一覧表を要求し、共有設定となっているファイルのｕｒｌの一覧を取得する（ステップＳ１６０３）。さらに、取得したｕｒｌの一覧の各ｕｒｌに対応するメタファイルをユーザのパソコンに取り込み所定の領域に格納する。次に、ファイル一覧プログラムは、ログインしているユーザが利用するパソコンのユーザ領域にある所定の場所にあるファイル（ローカルファイル）の一覧を取得する（ステップＳ１６０４）。共有対象のｕｒｌの一覧、又はメタファイルとローカルファイルの一覧は、ビューを生成する処理によって所定のビューに変換され（ステップＳ１６０５）、共有対象者のパソコン上に表示される（ステップＳ１６０６）。共有対象者のパソコン上のファイル一覧から表示されたｕｒｌ（ｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ｃｃｃ）をクリックすると、サーバからユーザのパソコンにｕｒｌ（ｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ｃｃｃ）が転送される。ユーザは、パソコン上のアプリケーションを利用してファイルを開くことができる。

次に、共有対象者のパソコン上のファイル一覧に表示された共有対象のファイルをユーザの操作によってダウンロードする具体的な操作について図１７を用いて説明する。パソコン上に表示されたファイル一覧で共有対象となっているファイルのｕｒｌを指定する。そして、マウスの右ボタンをクリックし、表示されたメニューから「ファイルのダウンロード」を選択すると、ファイルのダウンロードが実行される。ファイルのダウンロードが要求されると、ｕｒｌが指定するファイルのダウンロードの要求がサーバ上のダウンロードサービスに対し行われる（ステップＳ１７０１）。このときダウンロード先のユーザ名も同時にサーバに通知される。サーバ上の所定の認証／アクセス制御処理を経て、ファイルのダウンロードの要求が正当なものと判断されると、ファイルのダウンロードサービスはユーザのパソコンに対してファイルとメタファイルと転送する（ステップＳ１７０２）。転送されたファイルとメタファイルは、パソコン上の所定の領域に格納される。ｖｉｅｗｅｒは、所定の領域に格納されたファイルの一覧をビューとして生成し（ステップＳ１７０３）、表示する（ステップＳ１７０４）。図１５のＣｌｉｅｎｔ２のユーザ２領域における表示は、共有ファイルのｕｒｌであるｈｔｔｐ：／／ｓｅｒｖｅｒ．ｘ．ｃｏ．ｊｐ／ｕｓｅｒ１／ａａａをファイル（ａａａ．ｄｏｃ）としてＣｌｉｅｎｔ２にダウンロードし、表示した例である。なお、先にも述べたように、メタファイル（ａａａ．ｍｅｔａ）は、説明のために表記したが、実際のビューにおいては非表示ファイルである。

次に、共有対象ファイルのｕｒｌをユーザのパソコンにダウンロードした場合に、サーバ上のファイルが更新されたことをユーザに通知する処理について図１８を用いて説明する。ファイルが更新されたことの通知は、ユーザが共有しているファイルを指定し、明示的に更新の通知を要求したときに、ファイル一覧プログラムにおいて実行される。例えば、ファイルの一覧で所望のファイルを指定し、メニューを表示する。ここで、メニューの中から「更新通知」を選択すると、ファイルの更新通知の要求が実行される。または、ファイル一覧プログラムからファイルを開くと、ファイルの更新通知の要求が実行される。

ファイルの更新通知の要求がなされると、更新通知の要求がなされたファイルのメタファイルのｕｒｌをファイル一覧プログラムが参照する（ステップＳ１８０１）。そして、更新の通知を希望するｕｒｌのファイルが格納されているサーバの更新通知サービスに対してｕｒｌのタイムスタンプを要求する（ステップＳ１８０２）。タイムスタンプの要求を受けた更新通知サービスは、更新の通知を希望するファイルのタイムスタンプをユーザのパソコンに通知する（ステップＳ１８０３）。タイムスタンプの通知を受けたユーザは、ユーザのパソコンに格納されたファイルのタイムスタンプと更新通知サービスからのタイムスタンプとを比較する（ステップＳ１８０４）。更新通知サービスから通知されたタイムスタンプがユーザのパソコンに格納されたファイルのタイムスタンプよりも新しいときは（ステップＳ１８０４／ＹＥＳ）、ユーザのパソコンに格納される共有対象のファイルとメタファイルとを更新（ダウンロード）する（ステップＳ１８０５）。なお、共有対象のファイルとメタファイルのダウンロードが実行中は、ファイル一覧プログラムによって表示されるファイルを開くことはできない。共有対象のファイルとメタファイルのダウンロードが終了すると、ユーザのパソコンのｖｉｅｗｅｒによってビューが生成され（ステップＳ１８０６）、ファイルの一覧も更新される（ステップＳ１８０７）。

次に、サーバに格納された共有対象のファイルとそのメタファイル、及びユーザのパソコンに格納されたファイルを表示するビューについて説明する。図１９に、サーバ又はユーザのパソコンに格納されたファイルの一覧を表示するビューの例を示す。ファイルの一覧を表示するビューはパソコンが有するプログラム（ｖｉｅｗｅｒ）によって生成され、ユーザに提供される。ビュー全体を形成するメインウィンドウの最上部には、現在のログインしているユーザが表示されている。ログインする処理は、ビューを生成するプログラムによって行われる。具体的には、このプログラムがプロンプトを出してログイン処理をする。または、オペレーティングシステムがログイン機能を有する場合は、オペレーティングシステムによって認証された「現在のユーザ」は、ビューを生成するプログラムが取得する。図１９においては、ｏｍｕｒａというユーザがログインしていることを表している。

図１９に示すビューの左側には、ファイルを格納するフォルダの一覧（以下、フォルダペインとする）が表示されている。フォルダペインの「受信文書」、「発信文書」は特別な機能を有するフォルダである。これらのフォルダは、オペレーティングシステム上の所定のフォルダであり、その位置（パス）はプログラム内で予め設定されている固定的なフォルダである。フォルダペインに示されるその他のフォルダは、ユーザが任意に作成したフォルダである。

図１９の例は、「ＭＡＲＳ開発プロジェクト」トップフォルダとして、ユーザが任意のツリー構造で作成したものである。ユーザは、オペレーティングシステムが提供するファイル操作機能（例えば、マイクロソフト社のＷｉｎｄｏｗｓ（Ｒ）オペレーティングシステムのＥｌｐｌｏｒｅｒ）によって、フォルダ間でのファイルの移動・コピー、ファイルの新規作成、フォルダ間でのフォルダの移動・コピー、及びフォルダの新規作成が可能である。

図１９に示すビューの右側には、フォルダペイン上のフォルダに格納されているファイルの一覧（以下、ファイルペインとする）が示されている。ファイルペインの最上部にある「ファイル名」と「人」等によってファイルペインの表示方式を変更することができる。

次に、フォルダペインの「受信文書」フォルダが有する機能を説明する。受信文書フォルダには、他のユーザと共有するファイルが格納されている。フォルダ内のファイルは、図１６に示す処理に基づいてサーバ上にある共有対象者ごとのファイルの一覧表に対応して表示される。なお、図１６のフォルダペインの表示は、「ファイル名」が選択されている例であり、フォルダに格納されるファイルの一覧はファイル名または更新日時で整列されている。一方、受信文書のフォルダに対応するフォルダペインの表示方式に「人」が選択されている場合は、受信文書のフォルダ内のメタファイルを参照し、ｏｗｎｅｒごとにファイルを分類して表示される。すなわち、ファイルが誰をｏｗｎｅｒに共有とされたかを根拠に分類して表示する。

ファイルペインに表示された一覧の中で矢印が付されているファイル（オブジェクト本体のショートカット）は、ユーザのパソコンにダウンロードされていないことを表している。したがって、ユーザは図１７に示した処理を行わなければ、矢印が付されたファイルを開くことはできない。つまり、矢印が付されたファイルは、メタファイルのみがユーザのパソコンにダウンロードされた状態を示している。一方、矢印が付されていないファイルは、メタファイルとファイルとがともにユーザのパソコンにダウンロードされていることを示している。

矢印が付されているファイルをダブルクリックすると、そのファイルに対応するメタファイルのｕｒｌを参照し、サーバに格納されているファイルが検索され、所定のアプリケーションを起動してファイルが開く。ファイルは、内容を編集し、保存することができる。ただし、受信文書のフォルダ内には保存できない。しかし、フォルダペインに表示されている任意のフォルダ内に保存できる。任意のフォルダに保存する場合は、保存したユーザがｏｗｎｅｒとなり、新しいメタファイルが生成される。

次に、受信文書フォルダ内のショートカットやファイル（オブジェクト本体）をフォルダペインに表示される任意のフォルダに対してコピーする操作について説明する。図２１は、図１９のファイルペインにおいて表示した「実験報告」（ショートカット）と「追加実験生データ」（ショートカット）とをフォルダペインの「構想」フォルダにコピーした状態を示す図である。コピーされたファイルはいずれもサーバに格納されているオブジェクト本体のショートカットである。その他のファイル「Ｋ産業への連絡」、「新規案ドラフト」、「鈴木さんの情報」等は、ユーザ自身が作成したファイルである。

図２２は、図１９の受信文書フォルダに格納されている「調査書」（オブジェクト本体）を「企画仕様」フォルダにコピーした例を示す図である。受信文書フォルダ内のオブジェクト本体は、ショートカットを利用して図１７に示す処理で受信文書フォルダ内に格納できる。なお、受信文書フォルダ内のオブジェクト本体を任意のフォルダにコピーした場合、受信文書フォルダ内のオブジェクト本体は削除され、ショートカットのみが受信文書フォルダに残る。

図２３は、「企画仕様」フォルダの表示形式を「人」に切り換えた場合の表示例である。なお、図２２に示したように、「企画仕様」フォルダ内に含まれるファイルは、「機能仕様に関する検討」、「予算検討案」、及び「調査書」の３つである。「調査書」は、他のユーザから共有されたファイルである。つまり、ｏｗｎｅｒがｏｍｕｒａでないファイルである。この場合、図２３に示すように、「調査書」は作成者である「伊藤」の欄に表示され、下向きの矢印が付される。したがって、「調査書」のメタファイルには、＜ｏｗｎｅｒ＞伊藤＜／ｏｗｎｅｒ＞が記述される。「機能仕様に関する検討」と「予算検討案」とは、ｏｍｕｒａが作成して「小林」、「斎藤」、及び「田中」を共有対象としたファイルである。したがって、小林、斎藤、及び田中のぞれぞれの欄にファイルが表示される。このとき、「機能仕様に関する検討」と「予算検討案」のメタファイルには、図２４に示す記述がある。なお、「アイディア素案」ファイルは、田中から配信されたファイルであり、ｏｗｎｅｒがｏｍｕｒａではないので、ｏｍｕｒａから田中に配信されたファイルと共に田中の欄に表示される。

ファイルペインには、ファイルのｏｗｎｅｒが自分の場合は配布先、ｏｗｎｅｒが自分以外の場合は配布先のユーザ名が表示される。なお、表示形式を「グループ」に切り換えた場合、ファイルの配布先のグループ名が表示される。

図２５は、「企画仕様」フォルダの表示形式を「受発信」に切り換えた場合の表示例である。「企画仕様」フォルダに格納されているファイルを受信・発信別にソートして表示している。図２５には、「なし」の欄には、自分がｏｗｎｅｒのファイルであって、共有設定としていないファイルが表示される。

本発明は、複数の共有対象者に１つの共有名を付与して、グループを意識した共有が可能なため、定常的なグループワークの効率を著しく向上することができる。

また、本発明は、個人の作業領域にある共有化されたファイルのｕｒｌを容易に参照できるため、ｕｒｌをメールに添付するなど、ｕｒｌの交換を容易にでき、グループワークの効率を著しく向上することができる。

また、本発明は、自分の作業領域にあるファイルの共有状態を共有対象者ごとに一覧でき、共有対象を意識したファイルの検索が容易に可能である。例えば、キーワードなどで機械的に情報在処を検索する以外の手法では、経験的に「あの人に送ったファイル」、「あの人と一緒に仕事した時のファイル」など、「人」を中心にした文脈がファイルを検索する場合の重要なキーとなることが一般的に言われている。したがって、本発明により、共有状態を維持しつつ、個人の作業の文脈を生かした情報の検索が可能となり、グループワークの効率を著しく向上することができる。

また、本発明は、個人の観点での自由な情報レイアウト機能を維持しつつ、共有対象者（配布先）または共有元（発信者）を単位として、ビューを切りあえて参照できる。さらに、ｕｒｌにより共有対象を表現できるため、オリジナルのファイルに確実にアクセスすることができ、グループワークの効率を著しく向上することができる。

また、本発明は、自分に配信されたファイルのｕｒｌの配置を自分の観点で整理しつつ、オリジナルのｕｒｌに確実にアクセスすることができる状態を確保できる。さらに、ｕｒｌを実際のファイルとしてダウンロードすることで、オリジナルのファイルを編集することができる。なお、アクセスされる頻度が高いファイルに関しては、ファイルを自分の作業領域に格納することができるため、障害に強く、レスポンスも上がり、さらには、閲覧効率も向上する。高い閲覧効率を維持しつつ、オリジナルの更新状況に応じて、簡単に最新のファイルにアクセスすることができ、グループワークの効率を著しく向上させる。

また、本発明は、自分が作成したファイルと相手から配信されたファイル、利用頻度が高いファイルと低いファイル等を自分の観点で整理することができるため、情報の管理や活用に利便性を著しく向上させる。その結果、グループワークの効率を著しく向上させる。

本発明を適用したファイル共有システムの構成を示す図である。 本発明を適用したファイル共有システムの構成を示す図である。 ユーザの作業領域のビューを示す図である。 メタファイルの表示例を示す図である。 新規ファイルを作成する処理のフローチャートである。 メタファイルの初期状態の表示例を示す図である。 ファイルの属性を変更する処理のフローチャートである。 ファイルを更新する処理のフローチャートである。 ファイルを削除する処理のフローチャートである。 サーバが有する機能の一覧を示す図である。 共有ファイルを共有対象者別の一覧を示すビューの図である。 共有ファイルのメタファイルの表示例を示す図である。 共有ファイルを共有対象者別の一覧を示すビューの図である。 ｕｒｌを参照する処理のフローチャートである。 ファイルを共有する各ユーザに示されるファイルの一覧を示す図である。 共有するファイルの一覧を更新する処理のフローチャートである。 共有するファイルをダウンロードする処理のフローチャートである。 共有するファイルが更新されたことを通知する処理のフローチャートである。 ファイルの一覧を示すビューの図である。 ファイルの一覧を示すビューの図である。 ファイルの一覧を示すビューの図である。 ファイルの一覧を示すビューの図である。 ファイルの一覧を示すビューの図である。 共有されているファイルのメタファイルの表示例を示す図である。 ファイルの一覧を示すビューの図である。

符号の説明

１ ｃ１（ユーザのパソコン）
２ ｃ２（ユーザのパソコン）
３ ｃ３（ユーザのパソコン）
４ サーバ
５ ｄｉｓｋ１
６ ｄｉｓｋ２
７ ｄｉｓｋ７
１００ ディレクトリサービス
１０１ メタファイル登録サービス
１０２ メタファイル更新サービス
１０３ メタファイル削除サービス
１０４ Ｗｅｂサービス
１０５ 文書ファイル登録サービス
１０６ 文書ファイル更新サービス
１０７ 文書ファイル削除サービス
１０８ ＵＲＬ割り当てサービス
１０９ ストレージサービス
１１０ ＵＲＬ削除サービス
１１１ ＵＲＬ通知サービス

Claims (12)

1. 複数の情報処理端末とファイル共有装置とがネットワークを介して接続されたファイル共有システムにおいて、
   各情報処理端末は、
   自端末が保持する情報を前記ファイル共有装置へ送信する手段と、
   前記情報の一覧から前記複数の情報処理端末と共有する情報を選択する手段と、
   前記ファイル共有装置は、
   前記情報処理端末から取得した情報を送信元の端末を操作する前記情報処理端末のユーザごとに格納する手段と、
   前記送信元の端末を操作するユーザの情報の一覧を前記送信元に表示させる手段と、
   前記選択された情報に共有者を表す属性を付与する手段とを有することを特徴とするファイル共有システム。
2. 複数の情報処理端末とファイル共有装置とがネットワークを介して接続されたファイル共有システムにおいて、
   各情報処理端末は、
   自端末が保持する情報を前記ファイル共有装置へ送信する手段と、
   前記情報の一覧から前記複数の情報処理端末と共有する情報を選択する手段と、
   前記ファイル共有装置は、
   前記情報処理端末から取得した情報を送信元の端末を操作する前記情報処理端末のユーザごとに格納する手段と、
   前記送信元の端末を操作するユーザの情報の一覧を前記送信元に表示させる手段と、
   前記情報を共有する少なくとも１人からなるグループに固有の名称を付与する手段と、
   前記選択された情報に前記固有の名称を表す属性を付与する手段とを有することを特徴とするファイル共有システム。
3. 前記ファイル共有装置は、
   属性が付与された前記情報の一覧を表示する第１の表示手段と、
   前記情報を開示する開示手段と、
   前記情報処理端末によって編集された前記情報を保存する保存手段と、
   前記情報処理端末は、
   属性が付与された前記情報の一覧の表示を要求する手段と、
   前記第１の表示手段によって表示された前記情報の一覧から情報を選択する第１の選択手段と、
   前記開示手段によって開示された前記情報を編集する編集手段と、
   前記編集手段によって編集した前記情報を前記ファイル共有装置に送信する送信手段とを有することを特徴とする請求項１又は２記載のファイル共有システム。
4. 前記ファイル共有装置に格納された前記情報が共有状態になったとき、
   前記ファイル共有装置は、
   前記ユーザが前記情報を参照するためのｕｒｌを生成する第１の生成手段と、
   前記第１の生成手段によって生成されたｕｒｌと前記情報の名称とを関連付ける手段と、
   前記情報の名称と関連付けられたｕｒｌと前記共有者との第１の対応表を作成する手段と、
   前記第１の対応表を記憶する手段とを有することを特徴とする請求項１から３のいずれか１項記載のファイル共有システム。
5. 前記ファイル共有装置に格納された前記情報が共有状態になったとき、
   前記ファイル共有装置は、
   前記ユーザが前記情報を参照するためのｕｒｌを生成する第１の生成手段と、
   前記第１の生成手段によって生成されたｕｒｌと前記情報の名称及び前記共有者の名称を表す情報とを関連付ける手段と、
   前記情報の名称及び前記共有者の名称を表す情報と関連付けられたｕｒｌと前記共有者との第２の対応表を作成する手段と、
   前記第２の対応表を記憶する手段とを有することを特徴とする請求項１から３のいずれか１項記載のファイル共有システム。
6. 前記情報処理端末は、
   前記第１の対応表又は第２の対応表の表示を前記ファイル共有装置に要求する手段と、
   前記第１の対応表又は第２の対応表から前記情報を選択する第２の選択手段と、
   前記第２の選択手段によって選択された前記情報のｕｒｌを前記ファイル共有装置に送信する手段と、
   前記ファイル共有装置は、
   前記第１の対応表又は第２の対応表を前記情報処理端末に送信する手段と、
   前記第２の選択手段によって選択された前記情報を前記情報処理端末に送信する手段とを有することを特徴とする請求項４又は５記載のファイル共有システム。
7. 前記情報処理端末は、
   前記第１の対応表又は第２の対応表の表示を前記ファイル共有装置に要求する手段と、
   前記第１の対応表１又は前記第２の対応表から更新の有無の通知が必要な前記情報のｕｒｌを選択する第３の選択手段と、
   前記通知が必要な情報のｕｒｌの更新時刻と前記情報処理端末に格納された情報の更新時刻とを比較する比較手段と、
   前記情報処理端末に格納された情報の更新時刻が前記通知が必要な情報のｕｒｌよりも古いとき、その旨を前記ユーザに表示する手段と、
   前記情報処理端末に格納されている前記情報を更新する手段と、
   前記ファイル共有装置は、
   前記通知が必要な情報のｕｒｌの更新時刻を前記情報処理端末に送信する手段と、
   前記更新された情報を前記情報処理端末に送信する手段とを有することを特徴とする請求項４から６のいずれか１項記載のファイル共有システム。
8. 前記第１の表示手段は、前記情報の一覧を属性別に表示することを特徴とする請求項３から７のいずれか１項記載のファイル共有システム。
9. 前記第１の表示手段は、前記情報の作成者別に表示することを特徴とする請求項３から７のいずれか１項記載のファイル共有システム。
10. 前記第１の表示手段は、前記ユーザが自ら共有化した前記情報と前記ユーザが自ら共有化してない前記情報とを区別して表示することを特徴とする請求項３から７のいずれか１項記載のファイル共有システム。
11. 前記第１の表示手段は、前記情報の一覧と前記情報のｕｒｌの一覧とを属性別に表示することを特徴とする請求項４から７のいずれか１項記載のファイル共有システム。
12. 前記第１の表示手段は、前記情報のｕｒｌの一覧を属性別に表示することを特徴とする請求項４から７のいずれか１項記載のファイル共有システム。

Images