JP6834060B2 - 文書整理支援システム - Google Patents

Description

本発明は、電子文書の迅速な登録、書誌情報の管理、文書の高速かつ連続的な探索・閲覧・メタ情報の編集（特にメモの付加）、更には既存環境を利用したこれらのデータの共有といった、電子文書の整理・分析・共有にかかわるすべての機能を統合的に提供するための文書整理支援システムに関する。

本発明は業務の種類を問わない広い応用範囲を有するが、もともと弁護士実務における文書整理支援を重要な目的の一つとして開発されてきた経緯がある。また、課題及び発明の意義を明らかにするために、具体的な業務に基づいた説明が有益である。そこで以下ではひとまず弁護士実務を念頭に置いた解説をおこない、その上で意義の一般化をおこなう。

弁護士の実務においては、膨大な文書資料が日常的に取り扱われている。ここでいう文書資料とは、（１）弁護士が相手方や裁判所に発信した文書の控え（紙又はＰＤＦ）、（２）相手方から訴訟に提出された文書の紙コピー、（３）依頼人から弁護士に渡された多数の企業内文書のコピー、（４）依頼人からメール添付で送付された電子データ（ワード、エクセル、ＰＤＦなど）、（５）判例・論文等の文献、などを指す。以下、単に「文書」ということもある。

弁護士の仕事は、「事件」あるいは「案件」という単位で把握されることが多い（以下、「案件」とする）。１つの案件に対しては、通常、数十点から数百点の文書が存在し、ときには数千点、数万点といった極めて膨大な分量に及ぶことがある。
こうした膨大な文書を活用するには、電子文書となっていることが望ましい。そのため、オリジナルが紙文書である場合、弁護士は文書１点ごとに１個のＰＤＦファイルを作成（スキャン）し、電子文書化する。また、デジタルネイティブな電子データは、それ自体として電子文書としてそのまま利用する。

標準的な弁護士実務において、こうした電子文書は、適当に分類されたフォルダ（ディレクトリ）内に、ファイル形式（これを「ファイル＋フォルダ方式」とする）で保管される。

特開２００９−９５５１号公報 特開２００６−４２９８号公報

しかし、上記のような「ファイル＋フォルダ方式」では、弁護士実務に必要な機能を充足できない。こうした多量の電子文書ファイル（以下、単に、電子文書という場合がある。なお、電子文書は画像その他のデジタルデータを含んでいるか又は関連付けられていてもよい。）を効果的に管理・活用するための電子的システムは知られておらず、多くの弁護士が、電子文書の管理・活用に頭を悩ませている。

本発明が解決しようとする技術的課題は、個人レベルにおけるものと、チームレベルにおけるものとに整理される。

Ｉ．個人レベルにおける課題
１．文書資料の扱い方の特徴
弁護士の文書資料の扱い方にはいくつかの特徴がある。
（１）〔メモの紐付け〕第一に、弁護士の思考・発信・文書作成等には、個別具体的な文書資料による裏付けが必要である。そのため、弁護士が案件に関する知見を蓄積する際には、そのメモと特定の文書資料とが、明確に紐付けられる必要がある（以下、弁護士が文書に紐付けた知見の記述を「紐付けメモ」と呼ぶ）。
（２）〔原本性〕第二に、文書資料は原本性の保持が必要となる。たとえば、証拠として外部へ提出する場合に、弁護士による書き込み、編集があっては困る。
（３）〔名称の無個性・膨大〕第三に、文書はしばしば膨大であり、かつ、名称が無個性である。たとえば、「準備書面」「捜査報告書」などといった、それ自体では全く内容を推測できないタイトルが多い。しかもそれが数百、数千、数万点に及ぶことがある（図１）。
（４）〔特定方法〕第四に、前記第三の事情を反映して、弁護士実務における文書は、複数のメタ情報（書誌情報）の組み合わせで特定されることが多い。典型的には、タイトル・作成者・作成日付の３要素の組み合わせが用いられ、更に枚数が組み合わせられることもある。訴訟内においては、特定の便宜のために、証拠番号（「甲１０号証」などのように、記号に一意の番号を組み合わせたもの）という文書符号が付されるので、これも併用される。図２に書誌情報のイメージを示す。
（５）〔連続的探索〕第五に、閲覧は短時間だが、頻回に探すというケースが多い。すなわち、弁護士が知見を組み立てるためには、文書資料全体から、目的のために有意な記述を探し出す必要がある。しかし、前記第三の事情（名称の無個性）から、文書の中身を目視してみなければ、当該文書が求めるものかどうか判断できないことが多い。また、文書資料は、１個１個は比較的小粒で、記載されている情報量が少ないことが多い。そのため、多数の文書を高速かつ連続的に探索・閲覧する場面がしばしば出る。

弁護士にとって有用な電子的文書整理システムは、このような特徴にマッチしなければならない。

２．ファイル＋フォルダ方式の問題点
弁護士実務において一般的なのは「ファイル＋フォルダ方式」であるが、これはその要求を満たさない。具体的には下記のような問題が生じる。
a)〔知見蓄積の困難〕前記のように、文書検討においては、特定の文書との紐付けを保持したメモ（紐付けメモ）を作ることが重要である。しかし、ファイル＋フォルダ方式においては、それができない。ファイルに対してメモを書ける場所といえば実質的にファイル名しかないが、ファイル名を変更するのは閲覧・編集共に不自由であるし、ファイル名を汚染する。一方、別のテキストファイルなどに知見を書き留めていく方法では、いちいち文書を特定する記述が必要となって大変な手間である。
b)〔原本性保持の困難〕エクセルやワードなどの編集可能データを閲覧する際には、実行ファイルを起動するのが一般的である。その際に更新日時の変動や、誤編集などのリスクが生じる。
c)〔書誌情報の管理困難〕ファイル名にしか情報を記入できないので、記載できる分量には限界がある。また、作成日付・タイトル・作成者・文書符号などの書誌情報を区分できない（情報の構造化ができない）。書誌情報の補正・改善も、ファイル名の変更が繁雑であるため、しばしば放置される。枚数情報が管理されることはほとんど無い。なお、ファイルの「作成日」データはタイムスタンプに過ぎず、文書内に記述された作成日付と一致しない
d)〔書誌情報に基づく検索の困難〕上記c)の結果、書誌情報は構造化されないので、書誌情報を個別に検索したり、ソートすることができない。
e)〔内容に基づく検索の困難〕紐付けメモを管理できないとすると、検索及び目視選別の手がかりは、いずれも無個性なタイトル（あるいはわずかな書誌情報）を記述したファイル名だけになる。「事故の場面を記述した書類」といった内容ベースの探索はできない。
f)〔閲覧の遅延〕ファイルを開くためには、所定の実行ファイル（ＰＤＦリーダー、ワードなど）の起動を待たなければならない。かつ、そのウィンドウはせいぜい数個しか起動できない。名称が無個性で膨大な文書群から１個の文書を探索するという場面において、１個１個ファイルを開かねばならないことは致命的遅延である。また、ＯＳが提供するプレビュー機能も便利なものではない。

これらの結果、弁護士の電子文書検討は、本来求められる探索能力や、思考の密度・速度に対して、極めて不十分で、かつ遅延したものとしかならない。こうした管理・探索・閲覧上の不自由や、それによって膨大に生じる思考の中断の繰り返しは、弁護士の知的生産のボトルネックとなっている。

３．既存技術の難点
他方で、既存の一般的な文書管理システムは、このような課題を解決するものではない。それらは、組織内文書のライフサイクル管理（たとえば保存期間の管理）やワークフロー管理（たとえば承認・決裁）を主眼としたものであり、弁護士にとって必要な書誌情報（文書符号等）の管理や、高速かつ連続の検索・閲覧・メタ情報編集といったニーズを十分に満たしていない。
弁護士向けの案件管理システムも存在するが事情はさほど変わらない。そもそも文書管理能力を全く持たないものさえある。

４．本発明のねらい
本発明は上記の課題を統一的に解決しようとする。
データ管理においては、電子文書ファイルを原本性を保ってシステム内に保持すると共に、これに対する必要十分なメタ情報（特に書誌情報と紐付けメモ）の登録・編集・検索機能を提供する。そして、インターフェースにおいては、画面遷移を排して、多量の文書を高速かつ連続に、探索・閲覧・編集させうる表示機能を提供する。
これによって、本発明は、（１）文書の機械検索及び目視選別、（２）文書内容の閲読、（３）それに基づくメタ情報の付加・編集、という文書検討における中核的な３つの動作を、高速、柔軟かつシームレスに実現させる。

ＩＩ．チームレベルにおける課題
ところで、弁護士は、複数人で共同して（「チーム」）、一つの案件や公益活動に従事することが多い（「プロジェクト」と総称する）。そこで、上記のような文書整理支援機能を、チームにまで拡張して実現させたいというニーズが生じる。すなわち、異なるユーザーの環境下で、同じデータを、同じように利用させたい。もちろんそれは、各メンバーが別々の環境で、かつ、任意の時点で実施した編集結果を、矛盾なく統合、保持できなければならない。本発明の課題の第２（チームレベルの課題）は、その実現手法にかかる。

１．電子文書の保存に関する弁護士の一般的意識
ここで、電子文書の保存方法に関する弁護士の一般的な意識を見ると、次の特徴を指摘できる。
（１）〔クラウド回避のニーズ〕弁護士が扱う文書は、しばしば個人情報、しかもセンシティブなものを多量に含んでいる。そのため、弁護士は、クラウド上に電子文書を保存すること（すなわち外部事業者に機密情報を預けること）を、できるだけ回避したいというニーズを持つ。
（２）〔ファイル保持のニーズ〕弁護士の保持する文書は膨大であり、かつ、必要に応じてコピー・加工できる必要がある。数十の文書を一度に印刷することもある。そのため、弁護士は、フォルダとファイルが見えなくなるシステムには不便を感じる。たとえばウェブ上のデータベースに全ての電子文書ファイルを取り込んでしまい、システムを通じて１個１個ダウンロードしなければ電子文書ファイルが利用できないような形態に、弁護士は不便を感じる。
（３）〔ローカル利用のニーズ〕弁護士にとって、ローカルにファイルを保持できることは非常に重要である。（２）の場面では、ローカル上にフォルダ＋ファイルがあることが望ましい。また、非常に機密性の高い文書を、ローカルのみで扱いたいことがある。更に、電子文書のファイルサイズは非常に大きい（５０ＭＢなど）ことがあるので、閲覧速度のためにもローカルにファイルを保持したい。

これらはいずれも絶対ではないが、少なくとも、クラウドの利用を「強制」するようなシステムは、弁護士のニーズに反することになる。また、典型的なブラウザ型の文書管理システムなども、弁護士のニーズに反している。

２．プロジェクトの一般的形態
以上のことを踏まえつつ、弁護士のプロジェクトの実態を見ていく。これを模式的に示したのが図３である。なお、プロジェクトのメンバーは、３人程度から２０人程度のケースが多い。

（１）〔単独型〕第１に、弁護士は、単独でプロジェクトに取り組むことがある。図３プロジェクトａがそのイメージである。この場合、単独で取り組むのに機密情報をインターネット上にアップする必要はないから、クラウド回避のニーズにより、データはローカル端末上に保存されやすい。
（２）〔組織内型〕第２に、弁護士は、組織内でチームを作ることがある。図３プロジェクトｂがそのイメージである。一般に弁護士事務所は、構成員１０人以下の小規模なものが多く、専用システムの構築は難しい。また、クラウド回避のニーズがあるし、弁護士のみならず事務員も同じ文書を見る。そのため、弁護士は組織内での文書共有に、所内ＮＡＳ（ＶＰＮを含む）を活用していることが多い。チームが組織内弁護士のみで構成される場合、データ共有は、ＮＡＳによるのが自然である。
（３）〔組織横断型〕第３に、弁護士は、組織を横断してチームを作ることが多い。図３プロジェクトｃがそのイメージである。この場合、弁護士は、所内ＮＡＳやＶＰＮを利用できないし、１個のプロジェクトのためだけに専用サーバーを持つこともできない。そのため、組織横断型においては、弁護士はファイル同期サービス（ｄｒｏｐｂｏｘなど）を利用することが多い。また、メールや、ＵＳＢメモリ・ＣＤＲなどの可搬媒体によるデータの受け渡しに頼ることもある。

３．求められるデータ共有形態
以上を総合すると、弁護士実務におけるデータ共有における主要な形態は、ＮＡＳ型とファイル同期サービス型の２つであると考えられる。そして、必要に応じてローカルに全てのデータを保持できることも、本質的なニーズである。
しかも、プロジェクトのメンバーは毎回異なりうる。つまり、プロジェクトによって、データ共有形態が変わりうる。たとえば、あるときはＮＡＳを用い、あるときはファイル同期サービスを用いなければならない（図３「弁２」がそのイメージ）。
弁護士のための文書整理支援システムは、これらの全てのデータ保持形態に、包括的に対応できるような仕組みを持つべきである。

４．技術的課題
ここで技術的課題が生じる。
一般的な技術では、複数人間でのデータ共有のために、ネットワーク上（クラウドを含む）のデータベースサーバーに全てのデータを保持する方式を採用する。しかし、ネットワーク上のサーバーの利用を強制することは、データ共有形態に関する前記の各要求にマッチしていない。
他方、ＮＡＳ型やファイル同期サービスの利用を前提に、共有されるフォルダ内にデータベースファイルを設置する方法が考えられる。
しかしＮＡＳ上で各ユーザーに同一ファイルにアクセスさせるような構成をとった場合、一般的な技術では、一人のユーザーがシステムを利用している間、当該データベースファイルがロックされてしまう。そのため、複数ユーザーでの同時利用に堪えない。
一方、ファイル同期サービスにおいても、別々の環境での編集が競合すると、その編集結果は統合されない（複数の編集が１ファイルに競合した場合、ファイルが複製されてしまう）。

既存技術として、表計算プログラムの機能を拡張したデータベースプログラム（マイクロソフト社のＡｃｃｅｓｓなど）も知られているが、これもファイル同期サービスを利用する場合、複数人の同時的な編集があると、編集結果を統合できない。
また、可搬媒体でのデータコピーという方法をとる場合は、ユーザーが同じデータベースファイルをばらばらに更新してしまう結果になるため、やはり編集結果を一つに統合することはできない。
すなわち、既存技術では、データ共有形態に関する本件の要求に対応することができない。

本発明の第２の課題は、このようなデータ共有における技術的問題点を克服し、第１の課題に示した文書整理支援機能を、上記の全てのデータ共有形態において包括的に実現することにある。そして、第１の文書整理支援機能をチームレベルにおいても実現させる。

ここまでの課題整理は、弁護士実務を念頭に置いて記述してきた。しかしこのような課題は弁護士業務に限定されずに存在することが分かる。同様の課題を抱えうる具体的業務を例示すれば、研究者のチーム又は個人、出版・編集業の資料管理、調査委員会や第三者委員会、情報公開を活用する市民団体、個人の資料整理、小規模組織の文書管理などがある。これらの業務においては、文書を整理し、必要に応じて共有しながら、活用する必要がある。

また、データ共有方法における課題は、小規模組織や小規模チームであれば常に抱えうるものである。小規模集団は、ローカルでのデータ保存をよくおこなう。そして、データ共有にあたっては、ＮＡＳやファイル同期サービスを活用しているケースが多い。既存環境を、文書管理・整理のためにも、そのまま活用したいというニーズは常にある。そして、文書整理に重要性があるプロジェクト型の業務や、機密文書を扱うといった要因が加われば、データ共有手段を自由に選択したいというニーズは一層強いものとなる。

本発明に係る文書整理システムの一実施形態は、
文書整理システムであって、
少なくともユーザー毎に設けられる１組のデータベースファイルを管理するデータベースプログラムと、
前記１組のデータベースファイルによって記述されるテーブルの一部又は全部を視覚化するためのデータを生成する表示プログラムと、
前記表示プログラムによって生成されたデータをユーザー端末の画面上に表示する閲覧プログラムと、
を含み、
前記データベースプログラムは、
前記１組のデータベースファイルの一部又は全部を前記ユーザー端末のメモリ上に読み込むことにより、仮想データベースをメモリ上に保持する機能を有すると共に、
前記仮想データベースは、少なくとも、
前記データベースプログラムによって付与された一意の文書ＩＤと関連づけられた複数の前記電子文書の保存先パスを動的に生成するか又は前記電子文書の保存先パスを直接保持することにより、前記電子文書の読み出しが可能であり、さらに、
前記電子文書のそれぞれに割り当てられたメタ情報を保持しており、
前記メタ情報は、前記各ユーザーによる書き込みが完了した以後、ユーザー毎の入力データとして
（１）前記仮想データベースに書き込まれた後、各ユーザーに対応する前記１組のデータベースファイルの１つに書き込まれるか、又は、
（２）前記各ユーザーに対応する前記１組のデータベースファイルの１つに書き込まれた後、前記１組のデータベースファイルの一部又は全部を再度前記ユーザー端末のメモリ上に読み込むことにより前記仮想データベースを再構築され、
前記仮想データベースは、所定のイベントごとに又は所定のタイミングで、前記１組のデータベースファイルを再読み込みして前記メモリ上の保持データを更新する機能を
具備することを特徴とする（図４）。

上記の構成によれば、本システムは、データ保存方法として、各ユーザーに１個（構成により複数）割り当てられた、固有のユーザーデータベースファイル（ユーザーファイル）を用いる方式を採用している（図５。マスターファイルについては後述）。各データベースファイルは、システムが読み書き可能なファイルであればそれでよく、テキストファイルを含めた任意の形式が許容される。

そして、本システムは、上記データベースファイルに文書のメタ情報等を保持しつつも、（１）読み出し及び書き込みによるファイルロックをほとんど行わない、（２）ファイルへの書き込み権者を１ユーザーに限定する、ことで、複数ユーザーに任意のタイミングでシステムを使用させ、かつ、矛盾のないデータ共有を実現する。具体的な特徴は以下である。

第１の特徴は、本システムが、ユーザーファイルの、全部又は必要部分の読み出し結果を、メモリ上に保持することである。すなわち、本システムは、ユーザーファイルを読み出してメモリに保持したのちは、各種のデータ表示や検索処理にあたって、ディスク上にあるデータベースファイルにアクセスすることをしない。このため、本システムは、読み出しのためにデータベースファイルをロックすることがほとんどない。

第２の特徴は、本システムが、各ユーザーファイルから読み出した情報を統合し、構造化していることである。こうして作成されるメモリ上の構造化されたデータを、本明細書では「仮想データベース」と定義する。これによって、本システムは、メモリ上のデータを、あたかも１個のデータベースシステムのように扱うことができる。たとえばＳＱＬ文におけるＳＥＬＥＣＴ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥに相当する操作を、メモリ上の仮想データベースに対して実行でき（図４「クエリα」）、ユーザーに対して迅速かつ柔軟な検索・編集機能を提供する。また、このような適切な構造化は、データベースファイルの読み出しをせずに稼働し続けられるという特徴の前提となっている。

第３の特徴は、本システムが、各ユーザーによる編集結果を、各ユーザーに割り当てられたユーザーファイルにのみ保存する方式を採用することである（図５）。この構成を用いることで、特定のデータベースファイルを編集する主体は１人に限定され、複数ユーザーによるデータベースファイル編集が競合することがない。このことにより、ＮＡＳ構成においては１ファイルへの同時アクセスを回避でき、また、ファイル同期サービス構成においても、同一ファイルへの編集競合を回避できる。可搬媒体でコピーする構成においても、個々のユーザーの編集結果を独立に保存しうる。

以上を総合すると、本システムは典型的には次のように振る舞う。
まず、本システムは、起動時に全てのユーザーファイルを読み出す（データベースファイルのロック時間は１０ミリ秒前後）。このデータに基づいて、システムは、メモリ上に仮想データベースを構築する。システムはユーザーに対して、文書のメタ情報の閲覧・検索機能を提供するが、必要なメタ情報、クエリ処理機能は全て仮想データベースが提供する（ディスクアクセスを要さない。図４「クエリα」）。

ここで、ユーザーＡがシステムを利用中に、ある文書のメタ情報に対して編集作業を行うとする（図４「操作」）。システム（主として閲覧プログラム）は、編集処理を受け付けると、データベースプログラムを介して、当該ユーザーＡ固有のユーザーファイルａに当該編集情報を記録する（図４「クエリβ」→「読み書き」）。この際にデータベースファイルのロックが生じるが、これも通常１０ミリ秒前後におさまる。
仮想データベースに更新結果を反映するためには、全てのユーザーファイルの再読込（すなわち、仮想データベース全体の再構築）をする方法がある（図４「読み書き」→「構築」）。また、仮想データベース上の当該データのみを、メモリ上で直接変更する方法もある（図４「クエリα」）。

ここで、他のユーザーＢが同時にシステムを利用していても、その作業は、ユーザーＡの作業と整合性を維持できる。すなわち、ユーザーＡの操作はほとんどデータベースファイルをロックしないから、ユーザーＢが仮想データベースを構築するためにユーザーファイルａを読み込むことを妨げない。また、ユーザーＡの編集結果は、ユーザーファイルａのみを編集するから、ユーザーＢによる編集作業（すなわちユーザーファイルｂの編集）に干渉しない。

そして、最終的な同期は次のように実現する（図６）。すなわち、ユーザーＡの編集によってユーザーファイルａが編集されると、いずれかの時点で（ＮＡＳの場合は共有されて同時に）、ユーザーＢの環境下のユーザーファイルａが同期されることとなる。この時点で、ユーザーＢのシステムは、ユーザーＡによる編集結果を認識できることになる。そして、ユーザーＢのシステムが全ユーザーファイルの読み出し（すなわち仮想データベースの再構築）を行った時点で、ユーザーＢのシステムはユーザーＡによる編集結果を反映したものとなる（仮想データベースが最新状態となる）。

以上の構成から明らかな通り、特定ユーザーのユーザーファイルの同期タイミングが著しく遅れる（数日、数週間）ことも、本システムの稼働に本質的な影響を及ぼさない。なぜならそれは、当該ユーザーによる編集結果のみは反映されないという以上の意味を持たないからである。なお、データベースファイルの具体的な構造や読み出し・構造化のアルゴリズムは、実施例において説明する。

以上を総合すれば、本実施形態のシステムは、データ共有の方法として、ファイル同期サービスやＮＡＳによって、単にいくつかのデータベースファイルを同期するという方式を採用しながら、システム全体としては、トランザクション処理機能を保持した１個のデータベースシステムのように振る舞っている。

これによって、本発明はデータ共有方法における課題を解決している。

何点か補足する。
第１に、本システムにとって、ユーザーファイルの書き込み権限を制限することは、必須ではない。特定のユーザーや、特定のタイミングについて、他のユーザーファイルの編集権を付与することが考えられるし、あるいは、厳密な整合性を犠牲にして、書き込み制限を一切行わなくともシステム自体は稼働する。

なお、データ管理を合理化するためには、ユーザーファイルの他に、全ユーザーに共通するデータを保存するデータベースファイルを設置することが有効である（詳しくは実施例において、「マスターデータべースファイル（マスターファイル）」として説明する）。

第２に、複数ユーザーが同時に同一レコードの編集処理をしても、本システムの処理は破綻しない。すなわち、各ユーザーによるレコード編集結果は、それぞれのユーザーファイルに独立して保存される。詳細は実施例で述べるが、システムはユーザーファイル内の競合を自由なルールで解決できるので、たとえば、異なるユーザーによる編集結果を全て結合して表示させるといった処理も容易である。なお、ユーザーファイルでは、レコード編集について差分情報のみを記録することが通常有効である。

第３に、本システムの典型的な利用形態においては、チームメンバーは数人から最大でも数十人程度である。同時にシステムを稼働させる人数は、更に限定される。また、文書整理というシステムの目的からして、編集操作は１ユーザーあたり最大でも数秒に１回しか発生しない。そのため、本システムの稼働に支障を来すような頻度で、データベースファイルのロックが頻発するという事態は想定されない。

第４に、本システムがデータベースファイルの読み出しに要する時間は、１ファイル当たり１０ミリ秒に満たない程度である。したがって、チームメンバーが１００人を超える程度であれば、本システムの起動や基本的な動作には支障が無いと考えられる。また、運用可能人数を増やすために、ディスクファイルの読み出しの頻度を制限することも考えられる。すなわち、本システムは仮想データベースによってデータ表示を実現しているし、使用中ユーザーによる編集結果は、仮想データベースに対してメモリ上で直接反映させることもできる（図４クエリα）。そこで、データベースファイルの読み出し頻度を相当おさえても、本システムは実用上支障なく稼働する。これにより、多人数ユーザーによるファイルアクセスの競合を防止したり、多数のデータベースファイルを頻繁に読み込むことによる動作の低速化を防ぐ設計がありうる。

第５に、データ保存の仕組みから明らかなように、本システムはスタンドアロンであっても動作するし、ユーザー数は１人であってもよい。

更に、本発明は、電子文書を高速かつ連続的に検索・閲覧し、かつ編集できる機能を提供することを狙いとする。このために、閲覧プログラムの設計として、単一のウィンドウにおいて、画面遷移なく、メタ情報に基づく絞り込み検索・文書の閲覧・メタ情報の編集の、全ての機能を提供させるべきである。具体的には画面最上部にコンパクトな検索入力欄を設け、その下にはテーブルを描画して、テーブル１行に１件の分量でコンパクトな書誌情報を一覧表示させ、更に、当該書誌情報から直ちに文書画像を閲覧でき、かつ、書誌情報欄から直接レコードを編集できるようにする構成が有効である。なお、文書画像表示機能については、同一ウィンドウ内に表示する機能（大きさは画面半分程度が目安となる）と、別ウィンドウで大きく表示する機能の双方を備えることが有効である。

本発明に係る文書整理システムは、
前記仮想データベースに新たな電子文書が登録される際、所定の解析規則に基づいて前記新たな電子文書のファイル名に含まれる文字列から必要なメタ情報を抽出する機能を具備してもよい。

本発明に係る文書整理システムは、
前記閲覧プログラムを通じて前記仮想データベースに新たな電子文書が登録される際、前記ユーザー端末のユーザーによって入力された所定の文字列を所定の解析規則（例えば、「正規表現」など。）に基づいて解析し、必要なメタ情報を抽出する機能をさらに有するように構成してもよい。

この場合、前記抽出するメタ情報は、少なくとも、前記電子文書の作成日付、タイトルを含んでいてもよい。

前記閲覧プログラムは、前記ユーザー端末のユーザーによりテキストデータを入力させるための入力フィールドを有していると共に、前記入力フィールド内に、前記電子文書のファイル名から抽出したメタ情報を予め表示させておくように構成してもよい。また、前記閲覧プログラムは、登録対象のメタ情報を入力するための前記入力フィールドを表示中に、同一画面内に登録対象の電子文書の内容を画面遷移なくかつ閲読可能な大きさに表示する機能を具備してもよい。

前記閲覧プログラムは、登録された電子文書をテーブル形式で一覧表示する機能を具備すると共に、テーブル内の１行に１件の電子文書に関する全てのメタ情報を表示するように構成してもよい。この場合、前記閲覧プログラムは、さらに、登録された電子文書のメタ情報に基づいて絞り込み検索を行う機能を具備してもよい。

前記閲覧プログラムは、画面上に表示された前記テーブルに対するマウス操作を通じて登録対象となる電子文書のメタ情報の少なくとも１つを編集する機能を具備してもよい。

前記メタ情報の編集操作を単一の画面内において、画面遷移なく提供し、かつ、マウス操作を通じて文書画像を同一画面または別画面に閲読可能な大きさに表示する機能を具備してもよい。

本発明に係る文書整理システムは、カスタマイズ可能で枝番を含む文書符号を１対多で前記電子文書に付与可能であるように構成してもよい。

前記閲覧プログラムは、単一閲覧画面において、全部または一部の文書記号をボタンで一覧表示し、それをクリックすることでテーブル内の文書を、当該文書記号を有する文書に絞り込む機能を具備してもよい。

本発明に係る文書整理支援システムは、電子文書について、文書の登録（メタ情報の登録と、電子文書ファイルの保持）、文書の高速かつ柔軟な探索（機械検索及び目視選別）、探索した電子文書のシームレスな閲読、閲読結果に基づくメタ情報の編集（書誌情報の編集やメモの付加）、複数文書に紐付けられたレポートの作成、といったすべての機能を統合的に提供する。かつ、これを、大量の文書に対して、柔軟・高速かつ連続的に実施できる。
このことは、膨大な文書を連続的に探索・閲覧・分析し、知見を蓄積するという業務において、「ファイル＋フォルダ方式」とは比較にならない優位を持つ。また、文書整理・分析支援を視野に入れない一般的な文書管理システムと比べても、高度な優位がある。

更に本システムは、専用のサーバーを設置することなく、ファイルを用いたデータ保存・共有における基本的な形態（ローカル保存・ＮＡＳ・ファイル同期サービス）全てに順応して、データの同期を実現することができる。そして、トランザクション処理機能を有した単一のデータベースシステムのように振る舞う。これは、小規模組織の既存環境をそのまま利用したり、自組織内で全てのデータを持ちたいというセキュリティ上の要求も満たしうる。そして、ローカル上に全てのデータを保持できる構成を選択した場合には、検索・閲覧・編集等の全ての動作が特に高速となる。
そして、データ共有機能の恩恵として、ユーザーたちは、システム内に、当該プロジェクトに対する知見を次々に蓄積してゆくことができる。これによって、チームは知的生産性を大きく向上させることができる。

以上によれば、本発明に係る文書整理支援システムは、個々のユーザーが行う電子文書の整理・分析作業を強力にサポートすると共に、多様な既存環境に溶け込んでデータ共有を実現する。これによって、本システムは個人及びチームの知的生産性を大きく向上させる。

また、本発明は、複数のユーザーが同一のデータベースを扱う場合において、データベースファイルのロックを回避するための具体的な解決策を提供している。これにより、単純に各ユーザーのデータベースファイルを共有・同期するのみで、単一のデータベースシステムと同様な振る舞いを実現させている。本発明は、文書管理・整理システムの運用におけるデータ共有の形態を大きく弾力化する意義を有する。

無個性な文書の例を示す図である。 書誌情報のイメージを示す図である。 プロジェクトの一般的形態を示す模式図。ａは単独型、ｂは組織内型、ｃは組織横断型のプロジェクトを示す。 本発明に係る文書整理システムの一実施形態を示す図である。 各ユーザーに１個（構成により複数）割り当てられた、固有のユーザーデータベースファイル（ユーザーファイル）を用いる方式を採用した構成を示す図である。 実施形態のユーザーファイルの同期及び仮想データベースへの反映について説明する図である。 実施形態のフォルダ構成の一例を示す図である。 実施形態の具体的なテーブル構造の一例を示す図である。 実施形態の具体的なテーブル構造の一例を示す図である。 実施例における「文書ＤＢ」画面（文書整理・分析関連の機能を提供する中核的画面）を示す図である。 実施例におけるメモ機能に関する画面構成例を示す図である。 実施例におけるプロジェクト切替機能のためのインターフェースである。 実施例における電子文書の登録作業中の画面表示例を示す図である。 実施例におけるレポート記事の単票画面を示す画面構成例である。 実施例におけるテーブルの実装例を示す図である。

（発明の実施形態）
−用語の一覧−
本明細書で用いている用語を以下に一覧で示しておく。なお、用語の定義に関しては、本文内でも適宜言及している。

・ファイル＋フォルダ方式
電子文書のファイルを適宜の分類のもとにフォルダに保管し、それ以上には技術的な工夫を加えないような電子文書管理方式。
・文書ＩＤ
システム内で、個々の文書に一意に付加される数値又は文字列データ。
・紐付けメモ
ユーザーが文書資料を検討した結果を短く（おおむね１００文字以下）記述したテキスト情報であり、文書資料と１対１に紐付けられているもの。文書のメタ情報の１つと位置づける。
・メタ情報
情報に対する付加情報をいう一般用語であるが、本明細書では文書に対して１対１で付随する情報全般をいう。
主要な例：文書ＩＤ、タイトル、作成日付、作成者、文書符号、文書の枚数、紐付けメモ
・文書符号
記号と番号の組み合わせで文書に付加される情報。記号のみの場合もある。
具体例：甲１０号証 資（※記号のみ）
・書誌情報
文書のメタ情報のうちで、特に文書の特定のために用いられやすい情報。本明細書では基本的に下記の６項目を想定する。（なお、文書ＩＤは編集が許されない）
文書ＩＤ、タイトル、作成日付、作成者、文書符号、枚数
・文書の検索／目視選別／探索
文書を探す過程においては、（１）テキストや数値データによる機械的な検索（絞り込み表示）、（２）書誌情報や文書画像を目視することによる選別、という２つのプロセスがある。本明細書で、「検索」という言葉を用いる場合には、おおむね（１）の機械的な検索（システム上は絞り込み表示に相当）を想定している（必要に応じて「機械的」と明記する）。他方、（２）は目視選別と表現する。「探索」という表現は、（１）（２）の、双方を合わせた、文書を探すプロセス全体を想定する。
・プロジェクト
ユーザーは単独で、又は複数人で共同して、一つの活動に取り組むことがある（弁護士であれば１個の訴訟事件など）。そのような取り組みの対象となる活動の１単位を、プロジェクトと総称する。
・チーム／メンバー（構成員）
ユーザーが複数人で共同してプロジェクトに取り組む場合の、その複数人の総体を「チーム」とする。各個人については、「メンバー」「構成員」などと表記する。
・ファイル同期サービス
クラウド上のストレージにフォルダ構造を保ったまま電子文書ファイルを保存すると共に、オーナー又は共有を許されたユーザーのローカル端末内の所定フォルダに、当該フォルダ構造及び電子文書ファイルを同期させる機能を有するサービス（ｄｒｏｐｂｏｘなど）をいう。
・プロジェクトフォルダ／共有フォルダ
典型的な実装において、プロジェクトごとに１個設置されるフォルダをプロジェクトフォルダという。配下にデータベースファイルや電子文書ファイルが保存される。階層化されうるが、基本的に最上位のフォルダ（ルートフォルダ）を想定する。プロジェクトフォルダをユーザー間で共有又は同期する場合には、特にそれを共有フォルダということがある。
・データベースファイル
プロジェクトごとの情報を記録するための読み書き可能なファイル。基本的にはマスターファイルとユーザーファイルの２種類が想定される。典型的にはＳＱｌｉｔｅが適するが、テキストファイルなどでも足りる。
・マスターファイル
データベースファイルの１形態。プロジェクト内で全ユーザーに共通する初期情報を記録する。典型的には文書ＩＤを初めとする、文書の書誌情報を記録する。
・ユーザーファイル
データベースファイルの１形態。ユーザー毎の更新情報等を記録する。マスターファイルを設置しない形態においては、マスターファイルが保持するような情報も、ユーザーファイルに保持させる。
・アプリケーションフォルダ
配布プログラム（アプリケーション）を端末にインストールする構成をとった場合に、プログラムやシステムの設定を保存するために端末内に設置されるフォルダ。
・設定ファイル
配布プログラムを端末にインストールする構成をとった場合に、アプリケーションフォルダ内に設置されるファイル。システムの基本情報を記録する。たとえばユーザー名、管理するプロジェクトの一覧などである。ファイル形式は問わないが、テキストファイルあるいはＳＱｌｉｔｅなどが適する。共有対象としない。

本発明は、以下のＡ．〜Ｃ．を実施形態の基本構成とする、システムである。
Ａ．データベースプログラム
本発明の実施形態のシステムは、少なくともユーザー毎に１個のデータベースファイル（ユーザーファイル）を用いる。ユーザーファイルは、ユーザー毎に固有であり、データ共有に用いるフォルダ内に配置して、同期の対象とする。これに加えて、全てのユーザーに共通する初期データを保持するデータベースファイル（マスターファイル）を少なくとも１個設置することが望ましい（必須ではない）。

データベースファイルは、一般的にはＳＱｌｉｔｅを代表とするリレーショナルデータベース機能を有した単一ファイルが適しているが、データが読み書きできればそれで足り、テキストファイルなどを用いても差し支えない。後述のように、データベースプログラムは、各データベースファイルを読み書きし、かつ、それらをメモリ上に読み込んで統合する機能を持つこととなる。

アクセス権については、全てのユーザーは、全てのデータベースファイルに対して読取権限を有するものとする（以下、図５参照）。一方、個々のファイルの編集が競合することを防ぐため、マスターファイルの編集権は、原則として管理権限を有する単一のユーザーに限定する。また、ユーザーファイルの編集権は、当該ファイルが割り当てられた単一ユーザーのみに原則として限定する（管理ユーザーも他人のユーザーファイルの編集権を持たない）。

データベースファイルには、チームにおいて共有される電子文書に関する各種のメタ情報等が記録される。マスターファイルを設置する態様を前提にすると、まず、文書登録時に、データベースプログラムによって文書ごとに一意の文書ＩＤが付与され、これがマスターファイルに記録される。そしてこの文書ＩＤと紐付けて、文書登録時に入力された各種のメタ情報が、同じくマスターファイルに記録される。中核的なメタ情報としては、文書の特定に必要な書誌情報（タイトル、日付、作成者、文書符号、枚数）と、紐付けメモが想定される。その後、ユーザーがシステムを通じてメタ情報に編集を加えた場合、その結果は、当該ユーザーに割り当てられたユーザーファイルのみに記録されることとなる。

マスターファイルを設置しない形態においては、上記の各情報は、ユーザーファイルに記録する。この場合の文書ＩＤは、ユーザーごとに一意のＰＩＮを含ませるなどして、データベースファイル全体を通じて一意のものとする。
なお、いずれの形態であっても、電子文書そのものはフォルダ内にファイル形式で保存し、データベースファイルにはパス情報のみを記録することが合理的である。複数ユーザーでの共有を前提とする場合には、パスは共有フォルダをルートとする、相対パスとすることがふさわしい。

データベースプログラムは、これらのデータベースファイルの全部（場合により一部）を一括して読み出した上、所定の統合処理を行い、メモリ上に構造化して保持することで、ローカル端末のメモリ上にデータベースを構築する。このように、メモリ上に読み込まれた「データベース」を本願明細書では、「仮想データベース」と定義する。なお、メモリ上の仮想データベースのデータ型ないし構造化方法は種々ありうるが、一般には各種プログラミング言語で実装されている連想配列（キーによってバリューを引き出せる形式）を利用することが合理的である。

ユーザーがシステム上で検索操作を行った場合などには、後記表示プログラムはメモリ上の仮想データベースにデータの読み出しクエリを発行し、仮想データベースがこれに応答する。この際、システムは、ディスク上のデータベースファイルには一切アクセスしない。

他方、ユーザーがシステム上で編集操作を行うなどした場合は、データ編集のクエリが発行される。データベースプログラムはこれを受け付けると、ディスク上にあるユーザーファイルを編集して、更新情報を記録する（構成及び操作内容によってはマスターファイルに記録することもある）。

ここで、システムは、仮想データベースが保持するテーブル内のレコードを、先行してメモリ上で直接更新することもできる。この方式を採用すれば、データベースファイルを再読込せずとも、仮想データベースには当該ユーザーの編集結果が反映される。これには、データベースファイルのロック頻度を減らす効果もある。

このように、データベースプログラムは、（１）仮想データベースを構築する、（２）ユーザーによる編集結果をデータベースファイルに反映する、という２つのタイミングで、データベースファイルを一瞬だけロックするが、それ以外の殆どの時間はデータベースファイルをロックしない。そのため、複数ユーザーが同時にシステムを利用しても、データベースファイルの読み書き及び共有・同期は妨げられない。

データベースファイルは、ＮＡＳ（ネットワークフォルダ）を用いることで共有してもよいし、ファイル同期サービスで同期してもよい。ピアツーピアでコピーしてもよく、また、ネットワークが利用できない場合、原始的な方法では、ＵＳＢメモリーディスクなどの可搬媒体を通じてコピーしてもよい。

ここで、電子文書は、例えばＭＳ−Ｗｏｒｄ、ＭＳ−Ｅｘｃｅｌ、ＰＤＦなど所定のデータフォーマットで記録された電子文書であり、これらのファイルを閲覧するためのプログラムが各ユーザー端末に予めインストールされている必要がある（専用の実行プログラムは必須でなく、閲覧能力を有する一般的プログラム（ウェブブラウザなど）を援用することでも足りる）。

電子文書の保存場所は、端末からパスを認識できれば足り、ローカルエリアネットワーク内のネットワークフォルダでも、ユーザー端末内のローカルフォルダでもよい。
システムは電子文書データの所在を認識できる必要がある。典型的には、データベースファイル内に、電子文書のパスを記録する（通常はプロジェクトのルートフォルダからの相対パスによる）。ただし、電子文書のパスは、システムで動的に生成することも可能であり（例：保存先ディレクトリを固定し、電子文書ファイルの名前を文書ＩＤと一致させておくなど）、データベースファイル内に必ずパスを記録しなければならないわけではない。

なお、データベースファイル内に、直接電子文書を保存する構成を採用してもよい。たとえば、ＳＱｌｉｔｅはバイナリデータを保存できる。この場合、仮想データベースは、電子文書が保存されたデータベースファイルのパスを保持し、または、動的に生成して、そこから電子文書を読み出してもよい。この構成においては、電子文書データ保存専用のデータベースファイルを設けることが望ましい。

以上のようにユーザー毎に固有のデータベースファイルを各ユーザー端末間で同期しながら保持しつつ、それぞれのユーザー端末のメモリ上に仮想データベースを構築することにより、データベースサーバーを利用することなく全てのユーザー間で同一のテーブルを矛盾なく共有し、かつ、全てのユーザーが任意のタイミングでテーブルを編集することが可能となる。

Ｂ．表示プログラム
表示プログラムとは、データベースのレコードを検索するクエリを発行したり検索結果を受け取ってユーザー端末上に表示させたりするためのプログラムである。設計が容易な方法の１つは、ローカル端末上でウェブサーバープログラム（ローカルサーバー）を実行することである。この場合、ウェブサーバープログラムは仮想データベースからテーブル内のデータを受け取ったのち、ウェブブラウザが閲覧画面を描画するのに必要なデータを生成し、ウェブブラウザに引き渡す（ＨＴＭＬ形式のデータを直接引き渡してもよいし、ａｊａｘを用いるなどして、ブラウザでＨＴＭＬを生成してもよい）。ウェブサーバープログラムを用いる理由は、ＨＴＭＬ，ＣＳＳ，ＪａｖａＳｃｒｉｐｔ（登録商標）等の柔軟な表現能力を援用できる利点があるからである。ローカルに保存されたファイルの利用に対応させる設計であるため、外部に設置されたウェブサーバーは用いない。

但し、表示プログラムは、仮想データベースやデータベースプログラムにクエリを発行しうる何らかの表示プログラムであれば足り、ローカル端末上でウェブサーバープログラムを実行することやウェブブラウザに表示可能な形式に変換することは、必須ではない。上記の通り、ローカル側のコンピューターに複数のデータベースファイルを保持してそれらをメモリ上で統合した仮想データベースとして利用する（かつ、データベースのフィールドを編集中にデータベースファイルをロックさせない状態を作る）ことが本発明の特徴であり、全てのデータベースファイルから読み出したデータをメモリ上に読み込んで保持できれば、ウェブサーバープログラムを用いず、例えば、各種のＧＵＩのライブラリを利用することでも、同じ結果が得られる。この意味において、ローカルサーバーを利用することは、実施が容易で有用性の高い実装の一実施例という位置づけになる。

Ｃ．閲覧プログラム
閲覧プログラムは、表示プログラムのプロトコルに対応した閲覧プログラムであって、表示プログラムと通信し、データベースプログラムを通じて仮想データベースからデータを読み出したり、レコードを編集したりする機能を有する。表示プログラムがｈｔｔｐプロトコルを用いたウェブサーバーであれば、ウェブブラウザが利用できる。表示プログラムに対応した閲覧のための専用プログラム（グラフィカルユーザーインターフェースプログラム）を作成してもよい。

本発明は、電子文書を高速かつ連続的に検索・閲覧し、かつ編集できる機能を提供することを狙いとする。このためには、単一の画面において、画面遷移なく、検索・文書閲覧・レコード編集の全ての機能を提供することが望ましい。具体的には画面最上部にコンパクトな検索入力欄を設け、その下にはテーブルを描画して、１行に１件程度の分量でコンパクトな書誌情報を一覧表示させ、更に、当該書誌情報から直ちに文書画像を閲覧でき、かつ、書誌情報欄から直接レコードを編集できるようにする構成が考えられる。

文書画像の閲覧については、例えば、検索結果としてリストアップされた電子文書名の上にマウスホバーするとその電子文書の中身が画面半分程度の大きさに表示されるように構成する機能が有用である。これを実現するには、仮想データベースが保持するパス情報に基づいて表示プログラムが当該電子文書ファイルにアクセスし、その内容を画像形式に変換して、閲覧プログラムに引き渡し、閲覧プログラムはその画像を同画面内で大きく表示させるなどの方法がある。また、ポップアップを固定する機能、別ウインドウで全画面閲覧する機能を併せて提供することが考えられる。ここで、電子文書ファイルをローカルに保持しうることは、電子文書閲覧を高速に実現する利点を生んでいる。

なお、典型的な実施形態においては、表示プログラム（たとえばローカルサーバー）と閲覧プログラム（たとえばウェブブラウザ）は区別しうる。もっとも、独自のＧＵＩプログラムを用いる場合などには、表示プログラム及び閲覧プログラムの機能を、実質的に単一のプログラムの中で、一体として実現することも考えられる。したがって、実施形態の１つとして、表示プログラム及び閲覧プログラムが一体となったものも存在しうる。その実装方法は、本明細書を踏まえれば容易（実質的に同じ）と考えられる。

以上の実施形態によれば、個々のユーザーは、システム内において文書の検索・閲覧・メタ情報の編集（書誌の編集やメモ付け）という基本的な動作を、常に高速かつシームレスに繰り返すことができる。このことは、膨大な文書を連続的に探索・閲覧・分析し、知見を蓄積するという業務において、「ファイル＋フォルダ方式」とは比較にならない優位を生み出す。また、文書整理・分析支援を視野に入れない一般的な文書管理システムと比べても、高度な優位がある。
そして、全てのユーザーは、上記作業によって各ユーザーが蓄積したメタ情報をほぼ同時に共有でき、チームとしての知的生産性を大きく向上させることができる。更にプロジェクトごとに相違しうるデータ保存環境に適応し、柔軟なデータ共有を実現する。

以上が本発明の実施形態の骨格部分である。ここから実施例を示しながら、更に本発明について具体的に説明してゆく。実施例は開発されたプロトタイプの１つで、弁護士業務を念頭にカスタマイズされたものに基づいている。機能の主要部分は他の業務にも適用できるので、典型的な実施形態を示すのに十分である。

（実施例）
Ｉ．基本的なハードウェア構成、全体構成、導入方法等
１．ハードウェア
本システムは、典型的には一般的なＰＣでの利用が想定される。すなわち、ユーザー端末としては、ハードディスク等のストレージデバイス、ＣＰＵ、表示デバイス、キーボード及びマウスなどの入力デバイスを備えたコンピューター（デスクトップパソコンやノートパソコン等）を用いることができる。

必要なファイルを保持し、プログラムを実行することができる限り、オペレーティングシステム（ＯＳ）を含めて、ハードウェア構成については特に限定されない。例えば、タブレットやスマートフォンなどで利用できるように設計・プログラミングすることも可能である。

本実施例は、ウィンドウズ（登録商標）１０がインストールされたＰＣで稼働させている。これは想定される利用環境として主要なものの１つである。

２．プログラムの実装方法
本実施例では、ローカルサーバーを実行し、ウェブブラウザを閲覧画面として用いる形態（以下、「ローカルサーバー構成」とする）をとっている（後に詳述）。
本件発明者はｐｙｔｈｏｎ（及びｂｏｔｔｌｅをはじめとする一部のライブラリ）を用いてデータベースファイル操作、仮想データベース構築、ローカルサーバーの実行等の主要な機能を実装した。これらの機能は、ｐｙｔｈｏｎに限らず、一般的なプログラミング言語であれば、実装可能と考えられる。また、ＧＵＩは、ウェブブラウザの利用を前提に、ＪａｖａＳｃｒｉｐｔ（登録商標）を利用して実装した。
ローカルサーバー構成を利用したのは、ウェブブラウザ（ＨＴＭＬ，ＣＳＳ、ＪａｖａＳｃｒｉｐｔ（登録商標））の柔軟な表現力やＧＵＩ機能を援用できる利点があるからである。
ただし、ローカルサーバー構成は、効果的かつ容易な実装例の１つという位置づけにとどまる。データベースファイル操作、仮想データベース構築、閲覧画面の提供という機能を満たす限り構成は自由であり、たとえばｐｙｔｈｏｎであれば、適宜のＧＵＩライブラリを利用すれば、ローカルサーバーやウェブブラウザは必要ない。

３．ソフトウェアのセットアップ等
本システムは、典型的には配布プログラムを準備し、これを予めユーザー端末にインストールさせることが想定される（ただし、７．で述べるように端末にインストールしないこともできる）。
本実施例ではユーザーにインストールプログラムを配布する。ユーザーがインストールプログラムを実行すると、システムはユーザー端末内の所定のパスに、システム用のフォルダ（以下、「アプリケーションフォルダ」）を１個設け、その中にプログラム及びシステム用の設定ファイル（以下、「設定ファイル」）を設置する。本実施例では、設定ファイルとしてＳＱｌｉｔｅを利用しているが、テキストファイル等でも足りる。

本実施例は、配布プログラムそのものの中にローカルサーバープログラムも含んでいる。また、ウェブブラウザはＪａｖａＳｃｒｉｐｔ（登録商標)を実行できる一般的なもの（たとえばＣｈｒｏｍｅ）であれば足りる。したがって、本実施例は、ユーザーに対して、配布プログラム以外のソフトウェアの事前インストールを要求しない。
なお、ｐｙｔｈｏｎのようなスクリプト言語を利用する場合でも、各種ライブラリなどでソースをバイナリ化（実行ファイル化）できるので、予めｐｙｔｈｏｎインタープリターをインストールさせるといったことも必須ではない。

４．プロジェクトフォルダの準備
本システムはプロジェクト単位での文書管理を前提としている。そこで、プロジェクトごとに単一のフォルダを準備し、その中にプロジェクト内の全てのデータ（データベースファイルや電子文書ファイル）を保持させる構成が合理的である。
この構成をとる場合、ユーザーは、プロジェクトごとに、利用対象となる単一のフォルダ（「プロジェクトフォルダ」）を準備する。そして、システムを起動して所要の登録操作を行い、システムに当該プロジェクトフォルダを認識させる（具体的には、当該ユーザー端末上での、当該プロジェクトフォルダのパスを、設定ファイルに記録する。通常は絶対パスが適している）。

このとき、システムは同時に、プロジェクトフォルダの初期化処理（後述）を行う。これによって、システムは当該プロジェクトフォルダを認識するようになる。
そして、システムには、当該プロジェクトフォルダ（ルートフォルダ）からの相対パスで各ファイルにアクセスさせる方法が合理的である。もちろん、ルートフォルダの配下は階層化できる。

なお、以下の点を補足する。（１）プロジェクトフォルダは、ユーザーが事前に準備することは必須でなく、システムによって生成させてもよい。（２）上記は新規プロジェクトの作成を前提とした説明である。既存プロジェクトに参加する場合については後述する。（３）厳密には、プロジェクトフォルダが単一のものでなくともシステムは稼働しうる。たとえばデータベースファイルのみをファイル同期サービスで共有し、機密性の高い電子文書を共有・同期させないローカルフォルダに保持させ、システムには双方のフォルダを認識させる（各ファイルには相対パスでアクセスする）といった実装がありうる。もっとも、そのような構成はやや例外的と思われるので、本明細書では、単一フォルダ構成を前提として説明する。

５．プロジェクトフォルダの共有
本システムはスタンドアロンで動作しうるので、プロジェクトフォルダをローカル端末内に設置し、１人で利用してもよい。また、プロジェクトフォルダ内のファイルを、可搬媒体でのデータコピーなどで同期してもよい。しかし、チームでプロジェクトに取り組む場合には、プロジェクトフォルダそのものを共有又は同期する方法が合理的である。

典型的にはＮＡＳまたはファイル同期サービスを用いて、プロジェクトフォルダを全メンバーの間で共有又は同期する。ＮＡＳ構成を用いるプロジェクトならば、ネットワーク上の特定のフォルダをプロジェクトフォルダとし、共有する（同一のディスクに全員がアクセスする）。ファイル同期サービスを利用するプロジェクトにおいては、プロジェクトフォルダを同期対象とする（各ユーザー端末上の所定フォルダに対象のフォルダが設置され、同期される。なお、この場合、ユーザーごとにディスクは別であるから、同一のフォルダにアクセスするわけではない）。本明細書では双方を「共有フォルダ」と称する。

なお、当然のことながら、共有フォルダのパスはユーザー端末毎に異なりうる（ＮＡＳ構成ならばネットワークドライブレターの割当などによる相違が生じる。ファイル同期サービスにおいては、同期対象フォルダの設置場所が任意である）。
いずれにしても、システムに対しては、ユーザー端末ごとに、当該プロジェクトで利用する共有フォルダ（ルートフォルダ）を認識させる（登録する）。

６．ネットワーク接続・インターネット接続
前記のように、本システムはスタンドアロンで稼働するから、ネットワーク接続は必須ではない。ただし、データ共有のためには、ネットワークを利用することが通常望ましい。

ＮＡＳ構成をとっているプロジェクトについては、ＮＡＳ上にプロジェクトフォルダがある。したがって、当該プロジェクトを利用するためには、ＮＡＳのあるネットワークに接続している必要がある。
ファイル同期サービス構成をとっているプロジェクトについては、ローカル上にプロジェクトフォルダがある。したがって、ネットワーク（インターネット）接続は必須ではない。ただし、インターネット接続があれば、おおむね数秒から数分の遅延でデータの同期をすることができる。
他方、既述のように、同期が著しく（数日あるいは数週間）遅延したとしても、それは特定のユーザーの更新情報がシステムに反映されないという以上の意味はなく、本システムの稼働に本質的な影響を及ぼさない。この点で、ファイル同期サービスにおいて、インターネット接続をどのタイミングでするかには、かなりの自由度がある。いずれの同期方法を採用する場合でも、同期タイミングの自由度は大きく、任意のタイミングで同期することができる。

ここで、プロジェクトフォルダの共有方法は、プロジェクトによって相違して差し支えないことを改めて指摘する。すなわち、本システムは、プロジェクトフォルダを、当該ユーザー端末におけるパスによって把握している。したがって、プロジェクトフォルダは、パスによって認識可能であればそれでよく、それがＮＡＳ上にあるか、ローカル上にあるかは、システムにとって重要ではない。これによって、本システムは、複数のデータ共有形態に順応できるという長所を実現している（既述であるが、プロジェクトの形態について図３）。

７．ソフトウェアを事前にインストールしない構成について
なお、本システムのプログラムは、厳密には、端末に予めインストールしなくともよい。
少なくとも一般的なＯＳならば、本システムの全てのプログラムをプロジェクトフォルダ内に保持させる方法でも稼働する。このようにすると、本システムのライセンスを受けていないユーザーであっても、単にフォルダを共有するだけで、直ちにプロジェクトに参加できるようになる利点がある。活用法として、たとえば、本システムの形態として、端末インストール型と、フォルダインストール型の２種類を準備することが考えられる。そして、フォルダインストール型をライセンスされた者は、上記の方法で、ライセンスの無いユーザーをプロジェクトに参加させてよいものとする。これは、プロジェクトをオープンにしたいというニーズに答える。

ユーザー識別機能については、起動時にユーザー情報を入力させるか、ローカルにユーザー情報を保持させる方法で実現できる（たとえばブラウザならばクッキーで足りる）。
また、派生形態として、閲覧機能だけを有した（編集を許さない）ビューアープログラムのみを、共有フォルダ内に保持させるという設計もできる。これもプロジェクトのオープン化の一手法となる。もしここで編集権をごく少数のユーザーだけに保持させるようにすれば、本システムを一方向的な情報発信手段として使うこともできる。

ＩＩ．データの管理方法について
次に、アプリケーション用設定ファイル及びデータベースファイルの具体例を示しながら、本システムのデータの管理方法について説明する。

１．アプリケーション用設定ファイル（設定ファイル）
既述のように、設定ファイルは、ソフトウェアを端末にインストールした際に設置され、システム稼働に必要な情報を記録する。本実施例ではＳＱｌｉｔｅを用いているが、テキストファイルなどでも足りる。設定ファイルの個数は任意である。設定ファイルを他のユーザーと同期することは想定されない。
以下に、設定ファイルへの記録が想定されるデータで主要なものを挙げる。

〔設定ファイルにおける主要なデータの例〕
基本データ
−ユーザー名
−ライセンス認証に利用する情報
プロジェクト関連（１プロジェクトごとに）
−プロジェクトＩＤ（当該端末内において一意のもの）
−プロジェクト名（ユーザーが任意に設定）
−プロジェクトのルートフォルダのパス
−プロジェクトへの最終アクセス日

特に重要なのはプロジェクト関連の情報である。これを保持することで、プロジェクト情報の管理機能や切替機能を容易に実装できる（後述）。ただし、前記の「フォルダインストール型」のように、実装方法によっては、アプリケーションフォルダ自体を設置しないこともありうる。

２．プロジェクトフォルダ及びデータベースファイルの概要
既述のように、本システムは、フォルダ内にデータベースファイル（図５）を保存して、必要に応じてこれを共有又は同期させている。ここまで説明したプロジェクトの概念から明らかなように、データベースファイルはプロジェクトごとに設置されることになる。典型的には、プロジェクトフォルダ（ルートフォルダ）の下位にある適宜のフォルダに保存される。
なお、既述のように、データベースファイルは任意の形式が許容されるが、データ管理の効率からすれば、典型的にはＳＱｌｉｔｅなどのリレーショナルデータベース機能を有した単一ファイルの利用が合理的である。
以下では、マスターファイルを設置する形態を前提にして、フォルダ構成や、データベースファイルに記録すべき主要な情報について説明する。

３．フォルダ構成
図７はフォルダ構成の一例である。この例では、「C:\Dropbox\民事事件\京都事件プロジェクト」がプロジェクトフォルダ（すなわちルートフォルダ）となっており、その配下に、DocumentとprogramDataという２つのフォルダが配置されている（初期化時に自動設置）。

Documentフォルダは、文書ファイルデータを保存することが想定されている（文書登録時に、システムによって、当該フォルダ内にファイルを自動でコピーまたは移動することが合理的である）。
programDataというフォルダが、データベースファイル保存用のフォルダである。ここでは、master.sqliteがマスターファイルである。そして、usernameA.sqlite、usernameB.sqlite、usernameC.sqliteがユーザーファイルである（ユーザーは３人である）。この例では、ユーザーファイルにユーザー名をそのまま用いることで、ユーザーファイルの所有者を判定する。このような特定方法をとる場合、ユーザー名は常に一意とすることが必要である（通常はライセンス管理と連動させる）。

上記は一例であるが、フォルダ構成に関してはシステム上一定のものを予め定め、全てのプロジェクトフォルダを同じフォルダ構成で初期化することが合理的である。
なお、システムが利用しないフォルダは、ユーザーが自由に利用することができる。たとえば、京都事件プロジェクトの直下に、「草稿保存」などといったフォルダを設けて、文書作成用のワードファイルを管理するなどといった運用も許される。このように、本システムは、共有フォルダの本来的な機能をなんら制限しない。これにより、ユーザーは従来の共有フォルダ利用の延長線上で本システムを設置できる（いわば共生できる）。この点も本発明の特長である。

また、Documentフォルダ内の電子文書ファイルは、通常の電子文書ファイルであるから、ユーザーが操作することもできる。したがって、たとえば全てのファイルを可搬媒体に一括でコピーして第三者に提供したり、、数十通の文書をまとめてプリントアウトするなどといった操作が、フォルダ上で容易に行える。このようにフォルダとファイルを活かすことのできる柔軟性も、本システムの特長である。

４．マスターファイル
マスターファイルは、全てのユーザーに共通するデータを保存するためのファイルである。以下にデータの例を示す。

〔マスターファイルにおける主要なデータ（テーブル）の例〕
文書テーブル
−文書ＩＤ
−タイトル
−作成者
−作成日付
−文書符号
−枚数
−紐付けメモ
−登録日・更新日
−文書の全文テキスト情報
−電子文書ファイルへの相対パス（プロジェクトフォルダをルートとするもの）

文書符号テーブル
−文書符号ＩＤ
−文書符号名（例：「甲号証」）
−符号の短縮表示（例：「甲」）

図８は、これに基づく具体的なテーブル構造の一例である。なお、文書符号（codeinfosテーブル）については、のちに文書符号のカスタマイズ機能（後述）として詳しく説明する。また、文書の全文テキスト情報についても、後述する。
仮想データベースの構築時には、一旦、上記のテーブル内の情報をメモリ上に読み込む。これが仮想データベースの初期値となる。後述のように、ここにユーザーファイルの更新情報を反映させる。
なお、文書ＩＤは単一のプロジェクト内では一意でなければならないが、異なるプロジェクト間では重複することが許される（プロジェクトＡの文書ＩＤ１００と、プロジェクトＢの文書ＩＤ１００は、別の文書であってよい）。

５．ユーザーファイル
ユーザーファイルは、ユーザー１人に１個割り当てられる。以下に管理すべきデータの例を示す。

〔マスターファイルにおける主要なデータ（テーブル）の例〕
文書更新情報テーブル
−更新情報ＩＤ（このテーブルにおける主キー）
−更新対象となる文書ＩＤ（例：１２０００）
−更新対象となる文書レコードのフィールド名（例：ｔｉｔｌｅ）
−更新後の値（例：陳述書）
−更新日時

図９は、これに基づく具体的なテーブル構造の一例である。
なお、本実施例においては、レポート機能に関連する情報も、ユーザーファイルに記録しているが、これについてはレポートの項目で詳述する。

ここで、本システムにおいて、ユーザーファイルを仮想データベースに反映する方法を具体化して述べる。
本実施例では、「document_updates」テーブルが、文書のメタ情報の更新情報を記録するテーブルとなっている。たとえばユーザーが、2018年11月15日午前12時に、id12000の文書のタイトルを『陳述書』に変更するという更新処理を行った場合、同テーブルには「doc_id:12000, key:”title” value:”陳述書” updated_at:2018/11/15/12:00 created_at:2018/11/15/12:00」というレコードが記録される。このレコードは、メモリ上への読み込み後、プログラムによって、「文書ＩＤ12000（doc_id）である文書のタイトル（key=>title）を、『陳述書』（value）に更新する。かつその更新は2018年11月15日午前12時（updated_at）のクエリである」と解釈される。これにしたがって、プログラムは、仮想データベースの初期値に更新を加える。

ここで、異なるユーザーファイルのdocument_updatesテーブルにおいて、同じdoc_id、同じkeyに対する更新処理が併存した場合が、本実施例における編集の競合である。本実施例では、日付の新しい更新情報のみを採用して仮想データベースに反映する方法で競合を解決するが、全ての更新情報を活かしてユーザー名と共に結合表示するといった解決も可能である。

以上の通り、マスターファイルの情報を一旦メモリ上に読み込み、ユーザーファイルの更新情報（通常は差分情報）にしたがってメモリ上の当該データを変更することで、最新の情報を保持した仮想データベースを構築することができる。
なお、マスターファイルを設置しない形態においては、マスターファイルに記録すべき各情報を、ユーザーファイルに記録することができる。この場合の文書ＩＤは、ユーザーごとに一意のＰＩＮを含ませるなどして、全ユーザーファイルを通じて一意のものとする。仮想データベース上においては、全ユーザーファイルに含まれる全文書情報をまとめて１個のテーブルにすればよい。また、文書ＩＤが一意である限り、更新情報の記録・反映も前記同様の方法で実現できる。

６．アクセス権について
アクセス権については既に詳しく述べたが（図５）、原則形態としては、各ユーザーは自身のユーザーファイルのみの編集権を有し、マスターファイルについては、管理ユーザーのみが編集権を有する。他方、読取権限は、全ユーザーが全ファイルに対して有する。

７．仮想データベースについて
既述のように、メモリ上の仮想データベースは、マスターファイル及びユーザーファイルの読み出しによって更新される。この読み出しは、一定頻度あるいは一定のイベントごとに行うことが合理的である。たとえば読み出しが無いまま一定の時間が経過したときや、システム内に設置されたリロードボタンをユーザーが押したときである（当然ながらデータベースファイルのロックをごく短い時間に保つため、更新頻度は合理的な範囲にとどめる）。

ここで、仮想データベースの構造について言及する。既述のように、仮想データベースは、連想配列などによって実装することができる。この場合のデータ構造は典型的には下記のようなものが考えられる

〔データ構造例（おおむね文書テーブルに相当するもの）〕
{...,
13000:{'author': '特許太郎',
'codes': [[1, [30,0,0]],[3,[10,5,2]]],
'created_at': '2018-09-21 09:24:49 +0000',
'date': [2018, 9, 20],
'id': 13000,
'link': 'Document\\H300920陳述書[ID16755].pdf',
'memo': '事故状況',
'num_pages': 3,
'textdata': '（文書のテキスト情報）',
'title': '陳述書',
'updated_at': '2018-09-21 09:24:49 +0000'},
13001:{.....},
13002:......
}

すなわち、最上位のキーを文書ＩＤとし、第二階層のキーを、タイトル（title）、作成日（date）などのメタ情報とする。valueはその値である。
なお、codesは文書符号を意味する（詳細はＶＩ．文書符号機能で述べる）。

ＩＩＩ．閲覧機能・検索機能等の構成
次に、実施例の画面をもとに、閲覧画面（閲覧プログラム）について説明する。検索機能についても言及する。

１．検索及びテーブル表示
図１０は、本実施例における、「文書ＤＢ」画面（文書整理・分析関連の機能を提供する中核的画面）を示したものである。
最上部は、ページ切替のためのメニューバーとなっている。右上にある「テストプロジェクト」というボタンは、プロジェクト切替機能（後述）に関連する。
「タイトル・作成者・ｍｅｍｏを検索」という表記が見えるボックスが検索ボックスであり、文字列を打ち込んでエンターキーを押下すると、タイトル・作成者・ｍｅｍｏ（紐付けメモ）の各情報を一括して検索し、文書を絞り込む。また、日付などによるソート機能もある。

「検索オプション」では、日付指定、除外検索など、より細かな検索方法を提供する。「甲号証」などとあるボタンは、符号に基づく絞り込み機能を提供する。このエリアは「検索オプション」ボタンのクリックによって開閉する。
検索・ソートの実装方法には大きく２種類あり、（ａ）仮想データベース上で連想配列をフィルタ・ソートした上で閲覧プログラムに引き渡す方法（仮想データベースに対するクエリ）、（ｂ）閲覧プログラム上で既に保持しているレコード情報をフィルタ・ソートする方法（たとえばブラウザのメモリ上で、ＪａｖａＳｃｒｉｐｔ（登録商標）の配列型として保持しているレコード群に対して、フィルタ・ソート関数を実行し、その結果に基づいてテーブルを再描画する）がある。本実施例では、（ａ）を中心とするが、（ｂ）も一部の場面で併用している。

下部のテーブルが、文書のメタ情報を表示するエリアである。テーブル１行に対して、１件の文書が割り当てられており、多数の文書を一覧するのに適している。行内には、各種の書誌情報と共に、ｍｅｍｏとして紐付けメモも表示されている。
本実施例では、初期状態で最大５００件の文書を表示させる（更に５００件ずつの追加表示も許す）。この検索処理は、メモリ上のデータ（仮想データベース）に対する検索であるため、相当多数の文書を一括表示させても、動作は重くならない。膨大な文書を取り扱うという利用場面において、大量のレコードを表示できる利点は大きい（数十件程度の表示件数では不十分である）。この点も、本発明の特長の１つである。

２．文書閲覧機能
「＊＊＊規則の基本と対応例」と記載のあるところには、文書の画像が表示されている（ページをめくって読み進むこともできる）。
本実施例での表示方法は次の３種類を採用している。
すなわち、本実施例においては、初期状態では文書画像は表示されていない（メタ情報だけが一覧表示されている）。

ここで、左端にある「ＰＤＦ」「ＤＯＣ」などと記載されたボタンにマウスホバーすることで、図１０の通り、表の下半分の領域が電子文書の画像表示となる。マウスホバーを解除すると、画像は消える。これは迅速なプレビュー機能として利用できる（１つめの表示方法）。

そして、文書をそのまま読み進めたい場合などは、マウスホバーしたのち、そのままボタンを左クリックする。すると文書の画像表示は固定され、マウスホバーを解除しても文書は消えない（２つめの表示方法）。この際、本実施例では、文書画像が中央に来るように、画面全体をスクロールさせる。
なお、１つめ、２つめの表示方法共に、文書画像の表示のために、後続のレコード表示（行）を隠す必要はない。たとえば、２つめの表示方法で文書画像を固定したのち、そのままスクロールして、後続のレコードを確認することができるし、文書画像を追加で開くこともできる。実装としては、テーブルの該当レコードの直後に「行（trタグ）」を動的に追加し、その中に画像情報を埋め込む方法がある。

更に、修飾キーと組み合わせながらクリックすることで、別ウィンドウ（ブラウザによっては別タブ）をオープンして、全画面で文書を閲覧することができる（３つめの表示方法）。

このように構成することで、ユーザーは文書を探索する際に、高速かつ連続的に文書画像を目視して、必要な文書を選別することができる。また、必要に応じて、そのまま中身を閲読して分析することもできる。

３．メタ情報（レコード）編集機能
本実施例においては、同一画面上でのメタ情報（レコード）編集機能が提供されている。
図１１はメモ機能に関する画面構成例を示す図である。ユーザーは図１１ボタン２０２をクリックすることで、入力ウインドウ２０３をオープンさせることができる。ここでユーザーがテキストデータを編集し、ＯＫボタンをクリック（又はエンターキーを押下）すると、編集内容が確定する。
本実施例ではこのとき直ちに、ブラウザがメモリ上に保持しているＨＴＭＬデータを書き換えている（ＪａｖａＳｃｒｉｐｔ（登録商標）による）。これにより、ユーザーはレコード編集の際に待機させられることがなく（データベースファイルの更新を待たないし、仮想データベースの更新すら待たない）、高速かつ連続で編集作業を継続できる。

本実施例においては、それと並行して、データベースプログラムにクエリを発行し、ディスク上のユーザーファイルを更新する。また、同時に仮想データベースをメモリ上で更新し、該当データのみを書き換える（図１１であれば、ＩＤ１７５１１のレコードの、ｍｅｍｏキーに保持されるｖａｌｕｅのみを「本文書はＢＢＢ資料である。」に変更する）。

もしユーザーファイルの更新に失敗した場合には（システムでエラーを検知する）、その時点で、ブラウザのデータ及び仮想データベースのデータを復旧させる（メモリ上でバックアップしておく）。

また、符号・タイトル・日付・作成者の各表示についてもダブルクリックすることで、同様の編集ウィンドウが開き、ユーザーによる編集が許される。

なお、本実施例では、データベースファイル及び電子文書をローカルに保存する構成（ファイル同期サービスの併用を含む）を採用している。サーバー上のデータベース（ネットワーク上であり、かつ、ディスクアクセスもある）を利用する方法と比較すると、文書の検索・レコードの編集・文書の画像表示など、全てにわたって動作が高速となる。

４．全文検索機能
更に、システムには全文検索機能を保持させることが望ましい。膨大な文書群から目当ての文書を探すためには、全文検索機能が有効である。
まず、文書登録時などに、当該文書のテキスト情報を抽出して、データベースファイルに記録する機能を実装する。テキスト情報の抽出はファイル形式に合わせ、適宜のライブラリを利用するこどで実装できる。
テキスト情報についても、仮想データベースに同時に読み込むことが望ましい（単純なテキストデータであり、メモリを圧迫するほどのデータ量となることは考えにくい）。システム内の各種の検索処理に対応して、全文検索結果を表示する機能を実装する。

なお、システム内には、文書の画像表示とは別に、テキスト情報を表示する機能を設けることが望ましい。また、テキスト情報については、キーワード検索を許し、かつ、キーワードがマッチした行の前後一定行数（たとえば前後５行）や文字数のみを抽出表示する機能を実装することが望ましい。このような抽出処理は、たとえば、テキスト情報を改行毎に分割して配列形式に整理し、キーワードを含む要素とその前後の５要素を抜き出し、連結させるなどの方法で実装できる。

ＩＶ．チームによる使用の具体的な流れ
ここで、チームがファイル同期サービスと共に本実施例のシステムを利用する場合をシミュレーションしてみる。

〔前提事項〕前提として、本実施例では、電子文書の登録を管理者ユーザーのみの権限としている。本実施例はマスターファイルに文書の初期情報を記録するが、本実施例では、マスターファイルの編集権を完全に管理者ユーザーのみに限定しているからである。

〔シミュレーション〕典型的な流れを記述する。
まず１人の管理者ユーザーが、当該プロジェクトで用いるフォルダ（プロジェクトフォルダ）を作成する。管理者ユーザーは、ファイル同期サービスで所定の操作を行って、プロジェクトフォルダをチームメンバー（一般ユーザー）に共有する。更に、管理者ユーザーは、自身の端末上のシステムで所定の操作を行って、当該フォルダをシステムに登録する。

ここで管理者ユーザー端末内のシステムは、当該フォルダにマスターファイルを設置するなどの初期化を実施する（プロジェクトフォルダの初期化）。また、アプリケーションの設定ファイル（インストールフォルダ内）に、当該プロジェクトのパス等を登録する。この時点で管理者ユーザー端末内のシステムはプロジェクト（及びフォルダの所在）を認識するようになる。

一方、一般ユーザーたちのローカル端末には、ファイル同期サービスによって、当該プロジェクトフォルダが同期されるに至っている。ここで一般ユーザーは、自身の端末のシステム上で、当該共有フォルダを指定して、プロジェクトへの参加操作を行う。これにより、一般ユーザーの端末上のシステムは、それぞれ当該フォルダ内に、自身のユーザー名を持ったユーザーファイルを設置し、かつ、プロジェクトを認識する（プロジェクトへの「参加」）。このユーザーファイルも、ファイル同期サービスを通じて、全ユーザーに共有されることになる。

その後、管理者ユーザーは文書登録作業を進めてゆく。文書の書誌データは随時マスターファイルに記録されていく。また、電子文書ファイルは所定のフォルダに保存される。これらのマスターファイルと電子文書ファイルは、いずれもファイル同期サービスを通じて、全ユーザーのローカル端末に同期される。この時点で、各ユーザーのシステムは文書を表示できるようになる。

ある程度の文書が登録されると、ユーザーたちは、おのおののシステムで文書の検索・閲読・分析作業に入る。このステップで、ユーザーたちは、それぞれ任意のタイミングで、閲覧画面を通じて、書誌情報の記述の改善や、メモの記述などを行う。これらのメタ情報に対する編集は、全て当該ユーザー（ユーザーＡとする）自身のユーザーファイル（ユーザーファイルａとする）に記録される。更新されたユーザーファイルａは、ファイル同期サービスを通じて、随時全ユーザーの端末に共有される。この時点で他のユーザーは、更新後のユーザーファイルａを読み出せる。そして、ユーザーＡの行った編集作業を自身のシステムの仮想データベースに反映できる。ファイル同期サービスによれば、遅延はおおむね数秒から数分である。
他方、既述のように、同期タイミングにはかなりの自由度があるから、たとえばオフラインで作業を進めて、数時間後や翌日に同期するといったこともできる。

このようにして、全ユーザーはおのおのが自由なタイミングでシステムを利用して、知見の蓄積を行える。もちろん全ユーザーは、本システムの高速かつ連続の検索・閲覧・編集機能の恩恵を受けるので、作業は効率的に進めることができる。このようにして、チームは全体として高度の知的生産性を発揮する。

なお、新たにユーザーを追加したいときは、ファイル同期サービスでそのユーザーにフォルダを共有させた上、当該新ユーザーの端末上にインストールした本システムで、当該フォルダを指定して、所定の参加操作を行えばよい。

Ｖ．プロジェクトの管理・切替機能
次にプロジェクトの管理に関する機能を説明する。

１．プロジェクトの基本的考え方
既述のように、本発明は複数のプロジェクトでの利用を想定している。
一般に、プロジェクトは独立性が高いという特徴を持つ。すなわち、プロジェクト内の文書は相互に深い関係を有するのに対して、プロジェクトＡの文書をプロジェクトＢで利用するといった事態は稀である。

そこで、本システムにおける文書の管理も、プロジェクト単位で独立させることが合理的である。すなわち、文書テーブルはプロジェクトごとに独立させ、プロジェクト単位で独立した文書ＩＤが付与されるようにすることができる。この場合、文書ＩＤの付番もプロジェクト単位で行う（プロジェクトＡの文書ＩＤ１００と、プロジェクトＢの文書ＩＤ１００は別の文書とする）。

システム上も、プロジェクトの区切りをはっきりさせる。すなわち、あるプロジェクトを利用している際の検索操作は、原則として当該プロジェクト内の文書のみを対象とする。そして、ユーザーが明示的に切替をしない限り（あるいは管理用画面などでない限り）、他のプロジェクトの情報はユーザーの目に入らないようにする。これにはユーザーの操作をシンプルかつ高速に保つ効果や、ユーザーの集中力を維持する効果もある。

このような原則的考え方にもとづいて、本システムのプロジェクト関連機能は実装されることが望ましい。なお、このような発想は一般的な文書管理システム（様々なフォルダを垣根なく自由に移動させるのが一般的である）には見られない。

２．プロジェクト切替機能
図１２は、本実施例に実装されているプロジェクト切替機能のためのインターフェースである。画面右上に配置されている。
「京都事件」とある部分（ボタン）が現在のプロジェクト名を示す。このボタンにマウスホバーすると、下に他のプロジェクトが表示される（個人研究（ローカル）、所内文書管理（ＮＡＳ）、など）。本実施例では、プロジェクト名での検索機能も提供している（「名前で検索」とあるボックスにテキストを入力すると、表示が絞り込まれる）。
切り替えたい対象の事件名を選択して、クリックすると、当該プロジェクトに切り替わる。

このとき、内部的には、データベースファイルの再読込を行い、当該プロジェクトの仮想データベースを再構築している（本実施例では、仮想データベースは、アクティブなプロジェクトのもののみをメモリ上に保持する）。
そして、文書情報のテーブル表示なども、そのプロジェクトのものに再描画される。

３．プロジェクト管理機能
上記のような機能に伴い、プロジェクトに関する管理機能を提供することが望ましい。これは、システム内に適宜の管理画面などを設けて、ユーザーによる設定編集を許せばよい（アプリケーションの設定ファイルに反映する）。実施例においては、図１２最下部の「追加・編集」をクリックすることで画面遷移する。

典型的には、（１）プロジェクトの新規設置／参加、（２）プロジェクトフォルダのパスの再指定、（３）プロジェクト名の変更、という３つの機能を提供する。
（１）のプロジェクトの新規設置は、ＩＶで述べたところの、管理者ユーザーによるプロジェクトフォルダの初期化にあたる。「参加」とは、初期化済みのプロジェクトフォルダを登録することであり、ＩＶで述べたところの、一般ユーザーによるプロジェクトへの参加操作にあたる。
（２）は、プロジェクトのフォルダのパスが事後的に変わる場合に対応する（たとえば共有フォルダ名が変更されるケース）。（３）に関して、プロジェクト名は、ユーザーごとに自由に指定できるものとしておく。プロジェクト名は設定ファイルに保存するが、設定ファイルは同期対象ではないので、ユーザーごとに独自の名称を付加できる。ユーザーはシステム画面を通じて、いつでもプロジェクト名を編集できるものとする。

ＶＩ．文書符号機能
文書管理・整理において、書誌情報として文書符号を保持することは重要な機能である。弁護士実務に限らず、比較的規模の大きい企業・団体や官公庁などでは組織内文書に文書符号を付する例が多いし、個人や小規模チームであっても独自の整理記号を導入するニーズがある。そこで、システムには、文章符号について十分な管理機能を保持させることが望ましい。

１．基本的な要求
文書符号は、記号と番号が組み合わさったものである。この基本形態に加え、次の３点を考慮する必要がある。（１）文書符号は、１通の文書に複数付加されることがある。（２）記号の種類はプロジェクトによって変動する。（３）文書符号の番号では、「枝番」が用いられる（例：甲１０の２）。
システムはこれらのニーズを満たす必要がある。

２．データの保存方法
以上より、システムにおいては、文書符号を固定するのではなく、必要に応じてカスタマイズできるようにする必要がある。そのため、文書符号はプログラム内に書き込むのではなく、外部的に管理できるようにする。
本実施例においては、マスターファイルの項で述べた、文書符号テーブルがこれにあたる（図８：codeinfosテーブル）。

〔再掲〕
文書符号テーブル
−文書符号ＩＤ
−文書符号名（例：「甲号証」）
−符号の短縮表示（例：「甲」）

文書符号名は、正式な文書符号の呼称である（「甲号証」）。 符号の短縮表示は、これの略記である（「甲」）。一般的な記述方法では、短縮表示に数字を連結させる記述が用いられる（例：甲１０）。短縮表示は、文書一覧テーブルにおける表示や、ファイル名の解析（後述）に利用される。
上記のように文書符号には文書符号ＩＤが付されているため、documentsテーブル（マスターファイル）においても、仮想データベース上のテーブルにおいても、一次的には文書符号ＩＤを利用してデータは管理されている。

仮想データベース上の最終的なデータ構造は、[1, [10,5,2]]（＝[文書ＩＤ, [基本番号,枝番１,枝番２]]）というものである。文書ＩＤ１が「甲」ならば、この例は甲１０の５の２（枝番）と解釈される。
データの保持方法は種々ありうるが、本実施例の実装では、documentsテーブルの、codesフィールドに、"[1, [10,5,2]]"といった文字列データを記録し（ＪＳＯＮ形式）、プログラム上で配列形式に解釈しなおしている。

３．関連機能
ユーザーによる文書符号のカスタマイズ機能は、適宜の管理画面を準備し、その画面を通じて、文書符号テーブルを編集させる機能を実装すれば足りる。この編集結果は、通常は、仮想データベースに即時に反映させる。
また、文書閲覧画面においては（実施例では「文書ＤＢ」）、文書符号に対する検索機能を実装することが望ましい。本実施例においては、メインの検索ボックスの直下に、文書符号名が表示されたラジオボタンを設置しており、これをクリックすることで、直ちに該当する文書記号の文書のみに表示を絞り込める。特定の文書記号のみの文書をまとめて閲覧するというニーズは多く、ワンクリックでの切替が可能であることは利便性を大きく高める。

また、検索オプションエリアにおいて、記号と番号を指定しての検索機能を提供している。

ＶＩＩ．文書登録機能
次に、文書登録について説明する。
本システムは膨大な文書が登録されることを想定している。１万点の文書が登録されるときに、１通３０秒かかるのと（８３時間）、１通１０秒で済むのと（２８時間）では、大変な違いがある。また登録作業はしばしば退屈なものとなりやすく、登録作業者の心理的な快適性にも配慮する必要がある（作業効率にも影響する）。そこで、登録作業についてもシステムによって十分な支援が与えられることが望まれる。

既存技術における登録作業では、各書誌情報に対応する形で複数の入力フォームを設けて、ユーザーにそれぞれのデータを記入させるものが多かった（「フォーム移動方式」とする）。しかしこのような方法では、マウスクリックなどによるフォーム移動が何度も発生し、その点が時間のロス、作業の不快さを生む。逆に、書誌情報の登録をほとんどさせずに、単純にファイル名とタイムスタンプだけを利用するような形態もある。これは書誌情報の登録というニーズを満たさない。
より合理的かつ効果的な技術が望まれる。

１．ファイル名情報の利用機能
ここで、電子文書ファイル名に関する一般的な慣習に注目すると、そこにはタイトルと共に、一定程度の書誌情報が書き込まれることが多いことに気が付く。たとえば実務上よくあるのは、次のようなファイル名である。
甲50H301105陳述書.pdf
ここには「甲50」という文書符号、「H301105」という作成日付、「陳述書」というタイトル情報が含まれる。ファイルの命名方法に関して具体的な規約が存在するわけではないが、慣習上はおおむね似通った記述方式が用いられている。なお、作成者やメモは記述されないことが多いため、文書符号と作成日付以外はタイトルとなっていることが多い。

そこで、このような典型的なファイル名を捉えて、正規表現を用いて解析し、書誌情報として解釈できるようにすれば、登録作業を大きく効率化することができる。また、ファイル名の情報をそのまま活用できる点で無駄がない。

２．単一入力フォーム方式の採用及び入力規則
一方、入力方法に目を向けると、一般的な技術であるフォーム移動方式の難点は、多数の入力フォームの移動を繰り返しながらデータを入力しなければならない点にあった。
前記のように、そもそもファイル名にはある程度の法則性が存在し、かつそれは正規表現で解析できるようなものである。そこで、入力フォームについては、これをそもそも単一のものにしてしまうという解決策が考えられる。その入力フォームには、ファイル名を引き継ぐようにする。そして、上記の慣習的な記述方法を一歩拡大した入力規則を設け、ユーザーがそれに沿ってテキストデータを入力・補正すれば（いわゆるベタ打ち）、システムがそれを自動的に書誌として解析するという入力枠組みが成り立つ。この入力枠組みは、フォーム移動方式と比較すれば、圧倒的に高速な入力を期待できる。

この解析規則（すなわち入力規則）の一例は次のようなものである。

〔解析（入力）規則〕
文書符号 → 文書記号の文字のあとに数値が続くもの
例： 甲120 乙15 資30
作成日付 → いくつかの付随条件のもとで数値が6つまたは8つ連続する（主要なパターンを例示する）
例： 20171121、171121、H291121、2017.11.21、H29.11.21
作成者 → ＠に続く文字
紐付けメモ→ ＞に続く文字
タイトル → 上記に該当しない文字列の全てをタイトルとみなす

なお、上記は骨子であり、誤認識を防ぐためには、若干の精緻化をすることが望ましい。

３．具体例
以下、実施例の画面例により説明する。ここでは、以下のファイル名：

「証拠の一覧表を改善するための三つの提言（判例時報）171121.pdf」

という電子文書をシステムに登録する場合を例にとって説明する。
図１３は、登録作業中の画面表示例を示している。 最初に、ユーザーは、図１３の画面で「ファイル選択」をクリックして、登録しようとするファイルを選択する（複数ファイルの同時選択を許すことが望ましい）。
これによりシステムは、当該ファイルのファイル名を認識する。そしてシステムは、入力フィールド２１１に、当該ファイル名（拡張子を除く）をそのまま反映させる。ここでシステムは、入力フィールド２１１に存在するテキストデータを正規表現で解析し、所要のメタ情報を取り出して、表示フィールド２１２に反映させる。
更にユーザーは、入力フィールド２１１のテキスト情報をそのまま編集することができる。ここで、システムには入力フィールド２１１を常時監視させることが望ましい。本実施例ではそのように実装し、ユーザーが１文字編集するたびに、表示フィールド２１２の解析結果をリアルタイムに更新させている。

たとえばユーザーが、図１３のように、
「証拠の一覧表を改善するための三つの提言＠山本了宣171121 ＞ 判例時報の論文 甲３」
という入力を終えると、入力フィールド２１２の通りに、解析結果が表示されている。そしてユーザーがエンターキーを押下すれば、文書の登録は完了する。ファイル選択時に複数ファイルを選択していた場合は、画面表示は直ちに次の文書に切り替わり、連続して入力を続けることができる。

フォーム移動方式を採用する一般的なシステムにおいては、フォーム移動の手間が非常に大きい。また、登録中に文書の中身が表示できないことがある。しかし本システムの方法によれば、入力フォームは１個に集約される。そして、簡易明快な入力規則を用いて、文書画像を見ながら、迅速に書誌情報を記入できる。更に、編集結果は即時に目視確認できる。ユーザーは慣れれば１件あたり数秒から１０秒前後で文書登録を行うことができ、従来のシステムと比較して圧倒的に高速な登録を実現できる。

４．自動登録方式への拡大
更に、システムには、文書の自動登録（または半自動登録）機能を設けることが望ましい。具体的には、（１）ファイル選択（複数）によって直ちに登録作業を完了させる、（２）ファイル選択（複数）後に書誌情報の確認画面を表示し、簡易な補正作業をさせた上で、それにより登録の完了とする、（３）システムに所定のフォルダを巡回させて、そこに所在するファイルを自動的にシステムに登録する、といった方法である。

たとえば、数個のファイルのみを登録するような場合は、システムの登録画面を起動するよりも、ファイル名に直接書誌情報を書き込むほうが簡便な場合が多い。また、既に書誌情報の書き込まれたファイルを外部から大量に（たとえば数百個）引き継いだ場合などは、そこに記載された書誌情報を流用して、一括してシステムに登録できることが期待される。

この場合にも上記の入力規則は有効に機能する。
前述のように、一般的なファイル名では、日付・文書符号・タイトルの３要素が記入されていることが多く、かつ、日付・文書符号のパターンはほぼ確立している。したがって、命名者が本システムの入力規則を知らない場合でも、日付と文書符号はほとんどの場合に正しく認識される。そして、それ以外の情報は全てタイトルとして登録される。本システムの典型的な実装では、タイトル・メモ・作成者の３つをまとめて検索させるから、これでも大きな支障はない。（「＠」「＞」が利用されることは稀であり、誤認識のリスクは低い。）

他方、命名者が本システムの入力規則を知っている場合には、ファイル名にも入力規則をそのまま持ち込めば良い。たとえば、「171121証拠の一覧表を改善するための三つの提言＠山本了宣.pdf」などと初めから入力してしまえばよい。これは、書誌情報の入力作業をシステム画面から分離できる利点を示す。すなわち、ユーザーはシステムを起動することなく、ファイル名（それ自体は構造化されていないテキストデータ）を通じて、書誌情報（構造化されたデータ）が入力できることになる。これは書誌情報入力の手段、タイミングを柔軟にし、利便性を高める。たとえばフォルダ上での操作だけで登録作業を完了できることは、それ自体便利である。また、外部事業者に書誌情報の入力を委託する場合も、ＰＤＦファイルを渡して入力規則にしたがったファイル名に変更するよう依頼すればそれでよい。

５．符号のカスタマイズ機能との対応
なお、システムは、文書符号のカスタマイズ機能を提供する。したがって、上記解析規則は、カスタマイズ後の符号に対応できるように設計することが望ましい。具体的には、テーブルに記録されたカスタマイズ後の符号情報（符号の短縮表示）に基づき、動的に正規表現を生成させればよい。
また、上記の具体例は弁護士業務を想定したものであったが、同様の枠組みは他業種でも容易に適用できる。本実施例であっても、文書符号のカスタマイズを許すから、文書記号＋番号の組み合わせがどのようなものでも解釈できる。更に日付の記述方法は他業種においてもおおむね共通している。また、そもそも管理する書誌情報や入力規則をアレンジすれば、どのような業務でも適用できる。

６．文書登録権者について
本実施例においては、文書登録権者を管理者ユーザーに限定している。ただし、マスターファイルを設置せず、各ユーザーファイルに直接文書情報を登録させる構成をとる場合には、文書登録権者を制限する必要はない。また、マスターファイルを設置する構成をとる場合であっても、ユーザーファイル上に文書を仮登録させた上で、管理者ユーザーがシステムを起動した際に当該仮登録情報をマスターファイルに移行させるなどの方法で、全ユーザーによるデータ登録は実現できる。

ＶＩＩＩ．レポート機能
１．レポート機能の意義と考え方
本システムの紐付けメモ機能は、電子文書に対する短いコメントとして入力・表示することが予定されている。また、電子文書と１対１にしか対応しない。そのため、メモ機能のみでは、電子文書群に対する詳細な分析を記述することはできない。そこで別途複数の電子文書と関連づけたレポートを作成する機能を設けることが望ましい。特にチームにおいては、内容をテキスト検索可能な長文のレポートを共有できることに高い価値がある。

なお、レポートは複数の文書と関連づけてもよいし、いずれの文書とも関連づけなくともよい。文書とレポートとの基本的な関係は多対多となる。なお、レポートの表現形式としては、
・データベースのレコード内にテキストを保持する、
・保持したデータをＩＤ等をもとに関連づけする
といった態様が考えられる。また、レポート内に画像データなど付加的なデジタルデータ等が含まれている場合、ＨＴＭＬを前提にすると、リンク（自動生成を含む）としてテキスト内に埋め込みすることができる。

２．基本機能と保存形式等
基本的な機能として、新規投稿・編集・削除・コメントを実装することが望ましい。
レポートは、典型的には表題と本文（テキスト情報）で構成される。また、画像や他の電子文書ファイルの添付を許すことが望ましい。表現形式としては、いわゆるブログ記事などと似た実装となりうる。図１４は本実施例の画面例（記事の単票画面）である。本実施例においては、レポートを「Ｎｏｔｅ」と称している。

レポートは全ユーザーが随時投稿するものであるから、そのデータはユーザーファイルに記録するのが自然である。本実施例におけるテーブルの実装は、図１５のものである。notesテーブルにおいて、レポートに一意の文字列（article_code）、タイトル（title）、本文（body）などを管理している。コメントについては、notecommentsテーブルで別途管理している。なお、article_codeはユーザー名とシリアルナンバー（オートインクリメント）が組み合わせられた文字列形式であり、プロジェクト内で常に一意である。

３．レポート本文とＩＤ解析機能
そして、システムには、レポート本文を解析して、ＩＤを抽出する機能を設けることが望ましい。たとえば本文に次のような記述があったとする。
「平成３０年１０月２１日の事実経過は総合すると次のようなものと言える。
まずＸが自宅へ移動した（文書ＩＤ１５４００）。次にＹがそこへ訪れた（文書ＩＤ１２０００、ＩＤ９３７）。Ｚはこれに反する供述をするが→文書ＩＤ４００、○○という点（文書ＩＤ６２５６）と矛盾すると思われる・・・。」

このような記述に対して、システムは正規表現による解析を実施し、文書ＩＤ○○○の記述を文書ＩＤとして認識する。システムはこの情報に基づいて仮想データベースからデータを取得することで、レポート画面の表示をアレンジできる。たとえば、文書ＩＤ○○○の記述を、文書を画像表示可能なボタン又はリンクに自動的に変換できる。記述自体を、文書の書誌情報の短縮表示等に変換することもできる。また、当該レポートが参照する文書の一覧表示等の機能を提供することもできる。

逆に、各レポートが参照する文書ＩＤが分かっていれば、ある文書ＩＤがどのレポートから参照されているかを特定することも容易である。そこで、文書一覧画面において、当該文書を参照しているレポートの一覧やリンクを提供する機能を実装することができる。

なお、レポートからの文書参照については、ノートの投稿・編集画面に専用の入力フォーム（選択形式のものなど）を設けたり、文書一覧表示をクリックして関連づけるといった実装もありうる。ただし、上記のように直接本文中にＩＤを書き込む実装が、実際には迅速であろうと考えられる。

４．レポートの検索機能
レポートについては、検索機能を設けることが望ましい。典型的には、所定のフォームにユーザーにテキスト情報を入力させ、これに基づいて、タイトル及び本文のテキスト情報を検索させる方法が考えられる。
本実施例においては、検索（絞り込み）結果は、レポートのタイトル及びリードの一覧として表示される。

ＩＸ．連続編集機能について
閲覧画面におけるメタ情報編集機能の延長として、本実施例では、連続編集機能を実装する。

ユーザーの利用場面として、たとえば文書符号甲１から３０までの文書を、順に閲覧しながらメモを付加したいといったものがあり得る。すなわち、閲覧画面（図１０）内において、同画面のテーブルに表示された文書の表示順に従って、次々に文書を閲覧し、かつ、メタ情報を編集したいというニーズが生じる。連続編集機能は、これを実現することをねらいとする。

具体的には次のように実装することが考えられる。
たとえば閲覧画面で適宜のボタンを押すことなどによって、システムを連続編集モードに移行させる。
連続編集モード下でユーザーが文書の画像を表示させると、システムは同時に、当該レコードにおける所定のメタ情報の欄を、編集状態にする。たとえば、ｍｅｍｏのみを連続編集対象とする実装であれば、ちょうど図１０と同じ表示になる。
以下、ｍｅｍｏのみを連続編集対象とする実装を例に説明する。たとえば次のような処理手順となる。
（１）ユーザーが文書１００の画像を開く。すると、文書１００のｍｅｍｏが編集状態となる。
（２）ユーザーは文書１００の画像を見ながら、文書１００のｍｅｍｏを編集する。
（３）ユーザーが文書１００のｍｅｍｏの編集を終え、同フォーム内でエンターキーを押下する。
（４）文書１００のｍｅｍｏの編集は確定される。
（５）それと同時に、文書１００の文書画像がとじる。
（６）システムは、直ちに文書１０１の文書画像を開く。同時に、文書１０１のｍｅｍｏを編集状態にする。
（７）システムは、入力フォーカスを、文書１０１のｍｅｍｏ欄にうつす。
（８）ユーザーは、文書１０１の画像を見ながら、文書１０１のｍｅｍｏを編集する→（２）と同様。そして（３）の手順へ

以上のようにして、ユーザーは、次々に文書を閲覧しながら、ｍｅｍｏ欄を編集できる。この操作手順において、ユーザーはｍｅｍｏへのテキストデータの入力と、エンターキーの押下を繰り返しているだけである。これによって、高速かつ連続的にｍｅｍｏの編集を繰り返すことができる。

なお、閲覧画面の表示方法については、以下の工夫をすることが考えられる。（１）文書画像の表示は、ほぼ全画面に等しいサイズとする。ユーザーは１度に１件の文書だけを見て作業することが想定されているからである。（２）上記の通り、次々にレコードを移動することを想定するから、閲覧プログラムには自動スクロール機能を持たせることが望ましい。１件移動するたびに１件分画面をスクロールさせる。

Ｘ．一括ダウンロード機能について
本発明では、ユーザーが大量の文書を一度に取り扱うことが想定される。たとえば、数十通の文書を一度にプリントアウトするとか、数百の電子文書のデータを外部にまとめて提供するといった場面がありうる。こうした場合、ユーザーは、フォルダ上でファイルを直接操作できるのが便利である。

本実施例では、プロジェクトフォルダ内のDocumentフォルダを開けば、そこに全ての電子文書ファイルがある。しかし、フォルダを直接ユーザーに開かせることは必ずしも便利ではない。また、システムが保持する最新の書誌情報を、ファイル名にも反映させたい。

そこで、本実施例では、システム内に、電子文書ファイルの一括ダウンロード機能を実装している。具体的には次のようなものである。

〔機能〕
閲覧画面内で表示されているレコードのうちで、ユーザーが選択したもの（あるいは全部）について、その電子文書ファイルを一括ダウンロードさせる。デスクトップ上など、適宜のローカルフォルダを指定させる。

ダウンロードされるファイル名は、仮想データベース上のレコード情報（つまり最新情報）に基づいて生成する。

かつ、ファイル名にある程度の選択肢を持たせる。たとえば、（１）文書符号を先頭にする、（２）日付を先頭にする、（３）文書ＩＤを先頭にする、といった選択肢である。なぜなら、フォルダ上でファイル名のソートをおこなえば、先頭に記述されている要素にしたがった並び順を実現できるからである。フォルダ内でファイルを扱う場合、単一の書誌要素であれ、ユーザーが並び順を自由にできるメリットは大きい。

例：（次の３形態を選択できる）
甲020_H301120陳述書＠特許太郎ID2500.pdf
H301120_甲020陳述書＠特許太郎ID2500.pdf
ID2500_H301120甲020陳述書＠特許太郎.pdf

〔実装方法〕
「ダウンロード」について、プログラムの実装としては、コピー操作によるのが合理的である。ユーザーの視点から「ダウンロード」と記述したが、プログラム上の実装としてはコピーでよい。ＮＡＳ構成でも「コピー」でよい。

ファイル名については、仮想データベース上のレコード情報をもとにして、適宜の順序で書誌情報の文字列を連結させる。連結順は、ユーザーの指定した方式に従う。コピー時にリネーム操作を組み合わせる。
インターフェースは、文書閲覧画面に適宜のボタンを設置するなどすればよい。

なお、後記の自動暗号化・閲覧機能を採用する場合、パスワードの付加・解除機能もあわせて実装することが望ましい。

ＸＩ．自動暗号化・閲覧機能について
本発明は、機密文書の取扱いも想定する。したがって、文書の暗号化に関する機能を提供することが望まれる。特にファイル同期サービスを利用する場合などは、クラウド上に電子文書ファイルを保持するので、暗号化のニーズは一層高まる。
一方で、暗号化したファイルを閲覧するたびに、ユーザーに毎回パスワードを入力させることは、本システムの高速・連続閲覧という特性を大きく損なう。
そこで、下記のような枠組みを導入することで、文書の暗号化と、連続閲覧とを両立することができる。

〔枠組み〕
（１）プロジェクトごとに固有の、強固なパスワード（「プロジェクトパスワード」）を定める。
（２）ローカル端末内（たとえばアプリケーションフォルダ内）に、プロジェクトパスワードを保存する。
（３）文書登録時に（あるいはユーザーの操作などにより）、システムによって、電子文書ファイルにプロジェクトパスワードを自動で付加する。
（４）ユーザーが文書を閲覧する際には、閲覧プログラムにおいて、当該電子文書ファイルに自動でプロジェクトパスワードを引き渡す。
（５）電子文書ファイルのプロジェクトパスワードを解除したファイルを一括生成する機能を提供する（たとえば一括ダウンロード機能のオプションとする）。
なお、暗号化機能を適用するか否かは、プロジェクトごとに選択可能とすることが望ましい。

〔効果〕
以上の枠組みにおいて、パスワードは、ローカル端末内にのみ保持されている。したがって、たとえばクラウド上に不正アクセスを受けた場合でも、電子文書ファイルの秘密は保持される。
他方、ユーザーはシステムの使用中に、パスワードの存在を一切意識することなく、暗号化された文書を取り扱える。すなわち、文書登録時にはパスワードが自動で付加される。閲覧時にもパスワードが自動で引き渡される。電子文書ファイル自体を利用したいときには、パスワード解除されたファイルを利用できる。
このようにして、利便性とセキュリティとを両立できる。

〔実装方法〕
プロジェクトパスワードは、システムによって自動生成することが望ましい。たとえば、１６桁の強固なものを生成する。パスワードはプロジェクトごとに単一のものとするのが便利であるが、複数のものとする実装も不可能ではない。
パスワードはアプリケーションフォルダ内など、ローカル端末内の適宜の場所に保存する。チームでパスワードを共有する際は、たとえば管理者ユーザーにパスワードを生成させるものとし、それを適宜の方法で他のユーザーに伝達し、他のユーザーは自身のシステムでパスワードの登録作業をおこなう。
パスワードの付加や引き渡しは適宜のライブラリ等の利用によって実現できる。たとえば、主要なデータ形式であるＰＤＦファイルならば、パスワードの付加についてはｐｏｐｐｌｅｒ、閲覧時のパスワードの引渡についてはＰＤＦ．ｊｓなどのライブラリが知られている。
もちろん、データ形式によってはこのような処理を実装できないことがありうる。もっとも、少なくとも主要なデータ形態であるＰＤＦファイルで上記の実装が可能であるから、たとえば、機密文書は必ずＰＤＦ形式とする、といった規約にユーザーがしたがえば、実質的に支障はない。
そして、前記一括ダウンロード機能には、パスワードの一括付与及び一括解除機能をあわせて付与することが望ましい。これも一括ダウンロードプログラムに、適宜のライブラリ（ｐｏｐｐｌｅｒなど）を組み合わせればよい。

ここまで、実施例に基づいて説明をおこなってきたが、以上の実施例の機能のうち、ハードウェア構成に関わらない部分、すなわち、文書一覧画面の表示形態・書誌情報の編集形態・文書登録機能・レポート機能等については、本発明のハードウェア構成に依存しないことに注意する必要がある。たとえば、文書一覧画面において、書誌情報を表示しつつ、検索・編集・閲覧の全てを画面遷移なく連続で実現する機能は、それ自体ユーザーに高度の利便性を提供するものであるが、このような表示・検索・編集機能は、クラウド型文書管理システムや、サーバー型データシステム、完全なローカル型個人向けデータベースシステムなどにおいてもそのまま適用可能である。また、ウェブブラウザ上において、レコード編集結果をメモリ上で確定してＨＴＭＬを先行更新することで、ユーザーの待機時間を削除する方法は、ウェブブラウザを利用するクラウド型のシステムにも適用できる。文書登録機能、レポート機能、一括ダウンロード機能についても、クラウド型・サーバー型・ローカル型を問わず、あらゆる形態で適用できる。この点で各実施例にかかる各種の工夫は、ハードウェア構成に限定されない普遍性を有している。

ユーザー（メンバー）たちが使用を重ねるにつれて、本システムには、プロジェクトに関するメンバーたちの知見（メモやレポート）が多数蓄積されていく。複数のメンバーによる多角的な気付きがシステム内に多量に保存され、しかも、それをメンバーが自由に検索することができるようになる。更に、文書の書誌情報やメモが充実することで、「無個性」な文書はどんどん減っていく。

このように、メンバーたちが本システムを使い込むほどに、そのプロジェクトの情報は豊かになってゆく。そのこと自体が、メンバーの思考を援助し、更に多くの知見を生み出してゆく。こうした好循環のもとで、本システムはチームの知的生産を大きく改善することができる。もちろん、個人利用であっても同じ恩恵がある。

本システムは、文書整理機能やインターフェース、データ共有方法において優れた特徴を持つが、最終的には、上記のように個人あるいはチームが大きな知恵を育てるための統合的な環境を提供することを究極のねらいとする。

本発明は、発明者である弁護士自身が、実際の実務の中で試作品を作成し、改良を重ねて考え出したものである。そのような由来もあって、本明細書では弁護士業務を主要な例として取り上げ、記述してきた。しかし、（１）一定量以上の電子文書をフォルダ内に管理したい（ファイルを持ちたい）、（２）文書群に適宜の書誌情報を付して、効果的に管理したい、（３）文書群に対して高速かつ連続的（あるいは快適）な探索・閲読・編集をしたい、（４）特別のサーバーやクラウドを用いずに、フォルダベースのユーザー既存環境内でのデータ保管・共有をしたい、（５）高速化などのためにローカル端末にデータを持ちたい、（６）文書符号を利用したい、といった要求のいくつかに合致したタスクであれば、本システムは高い有効性を持つ。たとえば、研究者のチーム又は個人、出版・編集業の資料管理、調査委員会や第三者委員会、情報公開を活用する市民団体、個人の資料整理、小規模組織の文書管理などが想定できる。

本発明は、業務内容に合わせて多少のカスタマイズを施すことで、幅広い業務に容易に適用しうる。本発明は業種に限定されない普遍性を持ち、広い活用可能性を持つものと考えられる。

Claims (16)

1. 文書整理システムであって、
   少なくともユーザー毎に設けられる１組のデータベースファイルを管理するデータベースプログラムと、
   前記１組のデータベースファイルによって記述されるテーブルの一部又は全部を視覚化するためのデータを生成する表示プログラムと、
   前記表示プログラムによって生成されたデータをユーザー端末の画面上に表示する閲覧プログラムと、
   を含み、
   前記１組のデータベースファイルは、
   前記ユーザー毎に少なくとも一個割り当てられた１つ又は複数のユーザーファイルから構成されると共に、
   前記ユーザー端末の使用者に割り当てられたユーザーファイルに対する編集権は、前記使用者に対してのみ付与され、
   前記データベースプログラムは、
   前記１組のデータベースファイルの一部又は全部を前記ユーザー端末のメモリ上に読み込むことにより、仮想データベースをメモリ上に保持する機能を有すると共に、
   前記仮想データベースは、少なくとも、
   前記データベースプログラムによって付与された一意の文書ＩＤと関連づけられた複数の電子文書の保存先パスを動的に生成するか又は前記電子文書の保存先パスを直接保持することにより、前記電子文書の読み出しが可能であり、さらに、
   前記電子文書のそれぞれに割り当てられたメタ情報を保持しており、
   前記メタ情報は、前記各ユーザーによる書き込みが完了した以後、ユーザー毎の入力データとして
   （１）前記仮想データベースに書き込まれた後、
   前記ユーザー端末の使用者によって編集されるユーザーファイルに書き込まれるか、又は、
   （２）前記ユーザー端末の使用者によって編集されるユーザーファイルに書き込まれた後、前記１組のデータベースファイルの一部又は全部を再度前記ユーザー端末のメモリ上に読み込むことにより前記仮想データベースを再構築され、
   前記仮想データベースは、所定のイベントごとに又は所定のタイミングで、前記１組のデータベースファイルを再読み込みして前記メモリ上の保持データを更新する機能を具備することを特徴とする、
   文書整理システム。
2. 前記閲覧プログラムはスクリプト言語により記述されたプログラムを読み込むことにより、前記表示プログラムによって生成されたデータに基づいて生成された画面表示を変更し、それにより、前記メタ情報の閲覧又は編集を開始させる機能を実行させることを特徴とする請求項１記載の文書整理システム。
3. 前記表示プログラムは、ウェブサーバープログラムであり、前記閲覧プログラムはウェブブラウザであることを特徴とする請求項２記載の文書整理システム。
4. 前記１組のデータベースファイルは、初期情報を記録したマスターファイルを更に含むことを特徴とする請求項１乃至３のいずれか１項記載の文書整理システム。
5. 前記メタ情報は、前記電子文書の作成日付、タイトル、種類、及び作成者に関する情報の少なくともいずれか１つを含むことを特徴とする、請求項１乃至４のいずれか１項記載の文書整理システム。
6. 前記仮想データベースは、キーとバリューとで構成されたキーバリュー型データベーステーブルであることを特徴とする請求項１乃至５のいずれか１項記載の文書整理システム。
7. 前記キーは、前記電子文書に割り当てられる一意の文書ＩＤであることを特徴とする請求項６記載の文書整理システム。
8. 前記１組のデータベースファイルは、前記データベースプログラムの起動中にも、他の端末とネットワークを通じて共有されることを特徴とする請求項１乃至７のいずれか１項記載の文書整理システム。
9. 前記１組のデータベースファイルは、前記データベースプログラムの起動中にも、他の端末と任意のタイミングで同期されることを特徴とする請求項１乃至７のいずれか１項記載の文書整理システム。
10. 前記１組のデータベースファイルの同期は、ピアツーピア、ローカルエリアネットワーク内に設けられた共有フォルダ又はクラウド上のサーバー、のいずれかを介して同期されることを特徴とする請求項９記載の文書整理システム。
11. 前記表示プログラムは、前記閲覧プログラムにマウスホバー又はクリックで前記電子文書の内容を表示させるプログラムコードを実行させることを特徴とする請求項１乃至１０のいずれか１項記載の文書整理システム。
12. 複数の電子文書のいずれかと関連づけられた又はいずれとも関連づけられていないテキストデータを作成する機能を更に具備する請求項１乃至１１のいずれか１項記載の文書整理システム。
13. 前記表示プログラムと前記閲覧プログラムとは、同一のプログラムであることを特徴とする請求項１乃至１２のいずれか１項記載の文書整理システム。
14. 前記１組のデータベースファイルは、１つのプロジェクトに対応づけられると共に、１つのユーザー端末内に複数組設けられ、プロジェクト単位で独立した文書ＩＤが付与されることを特徴とする請求項１乃至１３のいずれか１項記載の文書整理システム。
15. 前記閲覧プログラムは、単一プロジェクト内の電子文書のみを検索又は表示させることを特徴とする請求項１乃至１４のいずれか１項記載の文書整理システム。
16. 前記閲覧プログラムは、異なる組のデータベースファイルを読み込むことにより、異なるプロジェクト内の電子文書を検索又は表示させるために切り替える機能を有することを特徴とする請求項１乃至１４のいずれか１項記載の文書整理システム。

Images