JP2022050169A - 情報処理システム及びプログラム - Google Patents

Abstract

【課題】類似する属性の代表値への集約後でも、集約前の属性を用いた検索を可能にする。【解決手段】情報処理システムは、プロセッサを有し、プロセッサは、文書を検索する検索キーとして、文書に付与されている属性の入力を受け付け、意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに第１の属性が含まれるとき、第１の属性が属する集合の代表値を用いて文書を検索する。【選択図】図５

Description

本発明は、情報処理システム及びプログラムに関する。

文書の管理システムでは、ユーザによる任意の属性名の付与が可能な場合がある。この場合、属性名の自由度が高いため、ユーザの違い等により属性名に表記ゆれが現れやすく、類似する属性名が乱立することがある。この表記ゆれは、例えば手作業や管理システムによる別の属性名への置換により解消される。

特開２００８－３１０６２６号公報

属性名の置換により表記ゆれは解消されるが、これにより置換前の属性名は失われてしまうと、属性名の置換を知らないユーザが自身の付与した属性名で文書を検索しても、想定する文書を見つけ出せないことが起こりうる。

本発明は、類似する属性の代表値への集約後でも、集約前の属性を用いた検索を可能にすることを目的とする。

請求項１に記載の発明は、プロセッサを有し、前記プロセッサは、文書を検索する検索キーとして、文書に付与されている属性の入力を受け付け、意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の代表値を用いて文書を検索する情報処理システムである。
請求項２に記載の発明は、前記プロセッサは、前記第１の属性を要素に含む集合の代表値である前記第２の属性が付与された文書を検索する、請求項１に記載の情報処理システムである。
請求項３に記載の発明は、前記第２の属性は、文書の階層的な管理に使用するディレクトリを単位に付与される、請求項２に記載の情報処理システムである。
請求項４に記載の発明は、プロセッサを有し、前記プロセッサは、文書を検索する検索キーとして、文書に付与されている属性の入力を受け付け、意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の全ての要素を用いて文書を検索する情報処理システムである。
請求項５に記載の発明は、前記プロセッサは、前記第１の属性を要素に含む集合の全ての要素のいずれかが付与された文書を検索する、請求項４に記載の情報処理システムである。
請求項６に記載の発明は、前記第１の属性は、ユーザにより付与される、請求項５に記載の情報処理システムである。
請求項７に記載の発明は、前記プロセッサは、前記第２の属性が、文書の階層的な管理に使用するディレクトリを単位に付与される場合、前記ディレクトリに属する文書に付されている意味が類似する前記第１の属性の集合と、当該集合の代表値を与える前記第２の属性とを生成する、請求項１又は４に記載の情報処理システムである。
請求項８に記載の発明は、前記プロセッサは、前記集合の要素に変化があった場合、前記第１の属性と前記第２の属性との紐付けを更新する、請求項７に記載の情報処理システムである。
請求項９に記載の発明は、前記プロセッサは、ユーザが文書に対して前記第１の属性を付与する場合、使用の頻度の履歴に基づいて前記第２の属性を提示する、請求項１又は４に記載の情報処理システムである。
請求項１０に記載の発明は、前記プロセッサは、検索キーでの使用の頻度が高い順番に前記第１の属性を提示する、請求項９に記載の情報処理システムである。
請求項１１に記載の発明は、前記プロセッサは、前記集合としての第１の集合と第２の集合の両方に属する前記第１の属性が存在する場合、予め定めた規則に従って、当該第１の属性と前記第２の属性との紐付けを更新する、請求項１又は４に記載の情報処理システムである。
請求項１２に記載の発明は、前記プロセッサは、前記第１の集合の全体が前記第２の集合に含まれる場合、当該第１の集合の代表値を与える前記第２の属性を、当該第２の集合の要素に追加する、請求項１１に記載の情報処理システムである。
請求項１３に記載の発明は、前記プロセッサは、前記第１の集合の一部と前記第２の集合の一部が重複し、一方が他方を包含しない場合、重複部分の前記第１の属性を、要素の数が少ない方の集合の要素に設定する、請求項１１に記載の情報処理システムである。
請求項１４に記載の発明は、前記プロセッサは、前記第１の集合の一部と前記第２の集合の一部が重複し、一方が他方を包含しない場合、重複部分の前記第１の属性を、対応する文書が属するディレクトリがより下位の集合の要素に設定する、請求項１１に記載の情報処理システムである。
請求項１５に記載の発明は、コンピュータに、文書を検索する検索キーとして、文書に付与されている属性の入力を受け付ける機能と、意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の代表値を用いて文書を検索する機能と、を実現させるプログラムである。
請求項１６に記載の発明は、コンピュータに、文書を検索する検索キーとして、文書に付与されている属性の入力を受け付ける機能と、意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の全ての要素を用いて文書を検索する機能とを実現させるプログラムである。

請求項１記載の発明によれば、類似する属性の代表値への集約後でも、集約前の属性を用いた検索を実行できる。
請求項２記載の発明によれば、第１の属性が検索キーとして与えられた場合でも、第１の属性が属する集合に関連する全ての文書を検索できる。
請求項３記載の発明によれば、検索キーで検索される文書とディレクトリとの関連性を高めることができる。
請求項４記載の発明によれば、類似する属性の代表値への集約後でも、集約前の属性を用いた検索を実行できる。
請求項５記載の発明によれば、第１の属性が検索キーとして与えられた場合でも、第１の属性が属する集合に関連する全ての文書を検索できる。
請求項６記載の発明によれば、表記ゆれが想定される第１の属性を用いても関連する文書を検索できる。
請求項７記載の発明によれば、ユーザによる第２の属性の付与を不要にできる。
請求項８記載の発明によれば、第１の属性と第２の属性との紐付けの更新に伴う処理負荷を低減できる。
請求項９記載の発明によれば、ユーザが付与する第１の属性の表記ゆれを少なくできる。
請求項１０記載の発明によれば、ユーザが付与する第１の属性の表記ゆれを少なくできる。
請求項１１記載の発明によれば、集合間の関係により検索結果として出力される文書数が増えすぎないようにできる。
請求項１２記載の発明によれば、第１の集合に含まれる第１の属性が検索キーとして与えられた場合、検索結果として出力される文書を第１の集合に関連する文書に制限できる。
請求項１３記載の発明によれば、第１の集合に含まれる第１の属性が検索キーとして与えられた場合、検索結果として出力される文書の数を絞り込むことができる。
請求項１４記載の発明によれば、第１の集合に含まれる第１の属性が検索キーとして与えられた場合、検索結果として出力される文書の数を絞り込むことができる。
請求項１５記載の発明によれば、類似する属性の代表値への集約後でも、集約前の属性を用いた検索を実行できる。
請求項１６記載の発明によれば、類似する属性の代表値への集約後でも、集約前の属性を用いた検索を実行できる。

実施の形態１で使用する文書管理システムの全体構成の例を概略的に示す図である。 実施の形態１で使用する共有サーバのハードウェア構成の一例を説明する図である。 プロセッサにより実現される機能の一部を説明する図である。 文書ＤＢの構成例を説明する図である。 属性グループＤＢに記憶される属性グループの例を説明する図である。 属性グループの構造例を示す図である。 実施の形態１で使用する共有サーバで実行される処理動作のうち属性グループの登録に関する処理動作の一例を説明するフローチャートである。 実施の形態１におけるグルーピング処理後のフォルダと属性グループとの関係を説明する図である。 実施の形態１で使用する共有サーバで実行される処理動作のうち文書の検索に関する処理動作の一例を説明するフローチャートである。 実施の形態１による検索の実行の過程の一例を説明する図である。 実施の形態２で使用する共有サーバで実行される属性グループの登録に関する処理動作のうちグルーピング処理の一例を説明するフローチャートである。 実施の形態２におけるグルーピング処理の途中段階の状態を説明する図である。 実施の形態２におけるグルーピング処理の完了後の状態を説明する図である。 実施の形態２で使用する共有サーバで実行される処理動作のうち文書の検索に関する処理動作の一例を説明するフローチャートである。 実施の形態２による検索の実行の過程を説明する図である。 実施の形態３で使用する共有サーバで実行される属性グループの登録に関する処理動作のうちグルーピング処理の一例を説明するフローチャートである。 実施の形態２におけるグルーピング処理の完了後の状態を説明する図である。 実施の形態における文書の属性の表示例を説明する図である。 実施の形態４で使用する共有サーバのプロセッサにより実現される機能の一部を説明する図である。 文書ＤＢの構成例を説明する図である。 実施の形態４における属性グループの生成例を説明する図である。 実施の形態４で使用する共有サーバで実行される属性グループの登録に関する処理動作のうちグルーピング処理の一例を説明するフローチャートである。 複数の属性グループ間の関係を説明する図である。（Ａ）は一方の属性グループが他方の属性グループの全てを包含する関係を示し、（Ｂ）は一方の属性グループと他方の属性グループが一部分で重なるが、一方が他方を包含しない関係を示す。 優先度が同じ属性グループが他に存在する場合における属性グループの構造例を示す図である。 実施の形態５で使用する共有サーバのプロセッサにより実現される機能の一部を説明する図である。 新しい文書を登録するユーザ端末の表示部に表示される属性名の画面の例を示す図である。

以下、図面を参照して、本発明の実施の形態を説明する。
＜実施の形態１＞
＜システムの構成＞
図１は、実施の形態１で使用する文書管理システム１の全体構成の例を概略的に示す図である。
図１に示す文書管理システム１は、ネットワーク１０と、システムを利用するユーザが操作するユーザ端末２０と、文書の共有に使用される共有サーバ３０とで構成される。

本実施の形態における文書は、例えばオフィスソフトその他のアプリケーションプログラムで作成されたオフィス文書、電子メール、原稿から光学的に読み取ったイメージデータ、ファクシミリ文書、写真、会計データ、医療データ、データベースその他を含む。本実施の形態における文書は、複数のユーザによる共有が可能であればよい。なお、画像系の文書には、静止画像に限らず、動画像も含まれる。

ネットワーク１０には、例えばＬＡＮ（＝Local Area Network）やインターネットを使用する。もっとも、ネットワーク１０は、ＬＡＮとインターネットとの複合型の構成でもよい。
ユーザ端末２０は、例えばノート型のコンピュータ、デスクトップ型のコンピュータ、タブレット型のコンピュータ、スマートフォン、画像形成装置であり、共有サーバ３０への文書のアップロードや文書のダウンロードに使用される。

いずれのユーザ端末２０も、データを処理する回路が集積されたマザーボードと、データを記憶するストレージと、情報の表示に使用されるディスプレイと、操作の入力に使用されるタッチパネルやキーボードと、ネットワーク１０との通信に使用される通信モジュールとを有している。
マザーボードには、例えばプロセッサ、プログラムの実行領域として使用されるＲＡＭ（＝Random Access Memory）、ＢＩＯＳ（＝Basic Input / Output System）等が記憶されるＲＯＭ（＝Read Only Memory）が設けられている。

本実施の形態で想定する画像形成装置は、用紙に画像を印刷する機能に加え、原稿等の画像イメージを光学的に読み取る機能やファクシミリ通信を実行する機能も備えている。この種の画像形成装置は、複合機とも呼ばれる。なお、画像形成装置について列記した機能は一例に過ぎず、他の機能を備えることを妨げない。
また、ストレージには、ハードディスク装置や書き換えが可能な不揮発性の半導体メモリが用いられる。
図１では、複数台のユーザ端末２０を描いているが、ユーザ端末２０は１台でもよい。

共有サーバ３０は、文書の共有を支援するクラウドサービスを提供する。図１の場合、共有サーバ３０は１台であるが、物理的には複数台のサーバで構成されてもよい。例えば共有サーバ３０は、いわゆるクラウドサーバとして構成されてもよい。もっとも、共有サーバ３０は、オンプレミス型のサーバでもよい。
本実施の形態における共有サーバ３０は、情報処理システムの一例である。

＜共有サーバの構成＞
図２は、実施の形態１で使用する共有サーバ３０のハードウェア構成の一例を説明する図である。
共有サーバ３０は、装置全体の動作を制御するプロセッサ３１と、半導体メモリ３２と、ハードディスク装置３３と、通信モジュール３４とを有している。これらは、信号線やバスを通じて接続されている。

プロセッサ３１は、プログラムの実行を通じて各種の機能を実現する。本実施の形態におけるプロセッサ３１は、例えば属性名を用いた文書の検索サービスを提供する。
半導体メモリ３２は、例えばＲＯＭと、ＲＡＭとで構成される。ＲＡＭは主記憶装置の一例である。
ここでのプロセッサ３１と半導体メモリ３２は、いわゆるコンピュータを構成する。
通信モジュール３４は、例えばイーサネット（登録商標）モジュール、無線ＬＡＮ用のモジュール、第５世代移動通信システム（すなわち５Ｇ）用のモジュールである。

ハードディスク装置３３は、補助記憶装置の一例であり、例えばオペレーティングシステムやアプリケーションプログラムを記憶する。もっとも、ハードディスク装置３３に代えて、大容量の半導体メモリを用いてもよい。
本実施の形態におけるハードディスク装置３３には、共有の対象である文書を記憶する文書データベース（以下「文書ＤＢ」という）３３１と、各文書に付与されている属性のうち意味が類似する属性名の集合を管理する属性グループのデータベース（以下「属性グループＤＢ」という）３３２とが記憶されている。

属性名は、対応する属性値との組で用いられる。属性名は属性の一例である。
属性名は、属性の性質や種類を与える。属性名には、例えば「ファイル名」、「作成者」、「作成日」、「送付先」、「承認ステータス」がある。
属性値は、属性名に対応する具体的な値である。属性値には、例えば「ＡＢＣ提案書」、「富士太郎」、「２０２０／０８／３０」、「ＸＹＺシステム」、「承認済」がある。

本実施の形態における属性グループＤＢ３３２は、意味が類似する属性名の集合を管理するデータベースである。意味が類似する属性名が複数出現するのは、ユーザがフリーワードを属性名として入力可能であることによる。意味が類似する属性名には、表記ゆれがある。なお、意味の類似は、表現の類似や汎用的な辞書における記載に限定されず、特定の業種や特定の業界における共通の知識を前提とした類似も含む。

属性グループＤＢ３３２を構成する個々の属性グループには、属性名の代表値が付与される。
本実施の形態の場合、属性グループＤＢ３３２は、文書ＤＢ３３１から文書を検索する際に用いられる。本実施の形態の場合、類似する属性名は、階層的に文書を管理する場合の文書の入れ物となるディレクトリを単位として管理される。

図３は、プロセッサ３１により実現される機能の一部を説明する図である。図３には、プロセッサ３１が実現する機能の一部として、属性付与部３１１と、属性グループ管理部３１２と、登録完了通知部３１３と、検索受付部３１４と、検索実行部３１５とを表している。これらの機能は、プロセッサ３１によるプログラムの実行を通じて実現される。

属性付与部３１１は、ユーザ端末２０（図１参照）からの指示に従い、共有サーバ３０（図１参照）に記憶されている文書に属性名を付与する機能を実現する。
属性名は、ユーザ端末２０を操作するユーザが自由に指定することが可能である。このため、表記ゆれが発生する。本実施の形態の場合、１つの文書に対して付与される属性名の数に制限は設けられていない。
文書に対する属性名の付与は、オペレーティングシステムやアプリケーションプログラムによっても可能である。

属性グループ管理部３１２は、文書ＤＢ３３１（図２参照）に記憶されている文書に付与されている属性名のうち意味が類似する属性名の集合（以下「属性グループ」ともいう）を管理する機能である。
属性グループは、ユーザが手動で生成してもよいし、オペレーティングシステムやアプリケーションプログラムが、予め定めた規則に従って生成してもよい。属性グループ管理部３１２は、例えば予め定められたスケジュール等に従って属性グループを生成する。

本実施の形態の場合、属性グループは、フォルダ（すなわちディレクトリ）を単位として生成される。すなわち、本実施の形態では、１つの階層のフォルダを単位とするが、親子関係や兄弟関係にある複数のフォルダを単位とすることも可能である。もっとも、親子関係等とは関係なく、属性グループを管理してもよい。ここでの親子関係は、文書の管理に木構造を用いる場合における上位ノードと下位ノードの関係をいう。一方、兄弟関係は、共通の上位ノードを有する複数の下位ノードの関係をいう。
本実施の形態における属性グループＤＢ３３２は、属性グループと、属性グループの代表値と、属性グループに対応するフォルダの位置を対応付けたスキーマレス構造を有する。

登録完了通知部３１３は、属性名のグルーピングが完了した場合に、処理の結果の確認をユーザに促す通知を発行する機能を実現する。
検索受付部３１４は、共有サーバ３０（図１参照）に記憶されている文書の検索を受け付ける機能を実現する。検索クエリは、ユーザ端末２０（図１参照）から与えられる。検索クエリには、例えば１つ又は複数の検索語が含まれる。本実施の形態における検索語は、属性名である。検索語は検索キーの一例である。
検索受付部３１４は、検索の実行を指示するユーザを特定する情報、検索の実行が指示された日時、検索クエリの情報等も、ユーザ端末２０から取得して記憶する。
検索実行部３１５は、指定された検索クエリを満たす文書を検索し、検索の結果をユーザ端末２０に出力する機能を実現する。

＜文書ＤＢの例＞
図４は、文書ＤＢ３３１（図２参照）の構成例を説明する図である。本実施の形態で使用する文書ＤＢ３３１は、木構造のノードに対応するフォルダに紐付けて文書を記憶する。
各フォルダには、識別用のＩＤ（＝IDentifier）が付されている。
図４の場合、ルートに位置するフォルダのＩＤは「００１」であり、その子ノードに当たるフォルダのＩＤは「００１１」である。

ルートに位置するフォルダは、親ノードを有しないフォルダである。子ノードのフォルダは、ルートのフォルダの下位に位置するフォルダである。図４では、子ノードは、ルートから数えて１つ目の階層にあるが、複数番目の階層にあってもよい。また、図４では、子ノードは１つであるが、子ノードは複数でもよい。
本実施の形態の場合、識別用のＩＤは、例えば属性グループとの紐付けに使用される。

図４の場合、識別用のＩＤ「００１１」で特定されるフォルダには複数の文書が記憶されている。図４には、複数の文書の一例として文書Ａ、文書Ｂ、文書Ｃが例示されている。
なお、文書Ａには、属性名として「作成者」と「承認済み」が付与されている。
因みに、「作成者」に対応する属性値は「Ｘさん」である。また、「承認済み」に対応する属性値は「ＴＲＵＥ」である。「ＴＲＵＥ」は、承認が済んでいる状態を表している。

文書Ｂには、属性名として「作成者」と「承認済」が付与されている。因みに、作成者に対応する属性値は「Ｙさん」である。文書ＢにＹさんが付与した属性名の「承認済」と、文書ＡにＸさんが付与した属性名の「承認済み」とは意味が同じであるが、表記が異なっている。「承認済」と「承認済み」は表記ゆれの一例である。文書Ｂの場合、「承認済」に対応する属性値は「ＦＡＬＳＥ」である。「ＦＡＬＳＥ」は、承認が済んでいない状態を表している。

文書Ｃには、属性名として「作成者」と「完了」が付与されている。因みに、作成者に対応する属性値は「Ｙさん」である。文書ＣにＹさんが付与した属性名の「完了」も、文書ＡにＸさんが付与した属性名の「承認済み」や文書ＢにＹさんが付与した属性名の「承認済」と同じ意味であるが、表記が異なっている。「承認済み」と「承認済」と「完了」は、いずれも意味が類似する属性名の一例である。
また、「完了」に対応する属性値は「ＦＡＬＳＥ」である。

図４の例では、意味が類似する属性名が付与されている文書のみを表しているが、同じフォルダに属する属性名の全てが類似するとは限らない。例えば「作成者」と「承認済み」は意味が類似しない。
また、図４の例では、各文書に２つの属性名が付与されているが、付与される属性名の数は１つでもよいし、３つ以上でもよい。

＜属性グループＤＢの例＞
図５は、属性グループＤＢ３３２（図２参照）に記憶される属性グループの例を説明する図である。
図５に示す属性グループは、図４に示すフォルダＩＤの「００１１」に属する文書に付与されている属性名のうち意味が類似する属性名の集合を表している。このため、属性グループには、前述した「承認済み」と「承認済」と「完了」が要素として含まれている。「承認済み」と「承認済」と「完了」は、第１の属性の一例である。

また、図５の場合、同じ属性グループに属する３つの属性名の代表値として「承認済」が指定されている。代表値としての「承認済」は第２の属性の一例である。図５の場合、代表値は、要素である属性名の１つと同じであるが、要素である属性名と同じであるとは限らない。
本実施の形態の場合、代表値は、ユーザが指定する。もっとも、オペレーティングシステムやアプリケーションプログラムが代表値を与えることも可能である。

図６は、属性グループの構造例を示す図である。図６の例は、代表値が「承認済」である属性グループを表している。
図６の場合、属性グループに属する属性名として「承認済」、「承認済み」、「完了」が例示されている。また、属性グループとして更新フラグが「ＴＲＵＥ」に設定されている。

本実施の形態における更新フラグは、グルーピング処理の実行が必要か否かを表している。
「ＴＲＵＥ」は、グルーピング処理が必要であることを示し、例えば代表値が変更された場合、要素である属性名の数が増減した場合、要素である属性名の内容に変更があった場合に使用される。換言すると、属性グループに変化があった場合には更新フラグが「ＴＲＵＥ」に設定される。
本実施の形態の場合、属性グループの管理は、例えば毎日午前１時のように定期的に実行される。グルーピング処理が終了すると、更新フラグは「ＴＲＵＥ」から「ＦＡＬＳＥ」に変更される。

更新フラグが「ＴＲＵＥ」の属性グループは、属性グループ管理部３１２によるグルーピング処理の対象となる。グルーピング処理では、属性名が属する属性グループと、要素である属性名が付与されている文書とが紐付けられる。一方、更新フラグが「ＦＡＬＳＥ」の属性グループは、属性グループ管理部３１２によるグルーピング処理の対象から除外される。

＜処理動作＞
＜属性グループの登録＞
図７は、実施の形態１で使用する共有サーバ３０（図１参照）で実行される処理動作のうち属性グループの登録に関する処理動作の一例を説明するフローチャートである。図中に示す記号のＳはステップを意味する。
なお、図７に示す処理動作は、プロセッサ３１（図２参照）が実行する。

プロセッサ３１は、属性グループとその代表値を、属性グループＤＢ３３２（図２参照）に登録する（ステップ１）。
本実施の形態の場合、属性グループの代表値や属性グループの要素とする属性名は、サービスを利用するユーザや登録の権限を有する管理者（以下「ユーザ等」という）が指定する。
ここでの登録には、新規の登録だけでなく、既存の属性グループに対する変更も含まれる。

次に、プロセッサ３１は、処理の対象とするフォルダの各文書の属性名が属性グループに属するか否かを判定する（ステップ２）。
文書の属性名がステップ１で登録された属性グループの要素に含まれていない場合、プロセッサ３１は、ステップ２で否定結果を得る。一方、文書の属性名がステップ１で登録された属性グループの要素に含まれる場合、プロセッサ３１は、ステップ２で肯定結果を得る。

ステップ２で否定結果が得られた場合、プロセッサ３１は、登録完了通知部３１３の機能を通じ、ユーザ端末２０（図１参照）に対し、登録の完了を通知する（ステップ４）。
一方、ステップ２で肯定結果が得られた場合、プロセッサ３１は、属性グループ管理部３１２の機能を通じてグルーピング処理を実行し（ステップ３）、その後、登録の完了を通知する（ステップ４）。

本実施の形態におけるグルーピング処理では、属性グループとその要素を属性名に含む文書のフォルダとの紐付けが行われる。属性グループとフォルダとが紐付けられることで、属性グループの要素である属性名のいずれかが検索クエリとして与えられた場合に、属性グループの要素である属性名を有する文書が検索の結果に含まれるようになる。
本実施の形態では、図６に示すように、属性グループとフォルダＩＤとの紐付けが実行される。
本実施の形態では、１つの属性グループは１つのフォルダに紐付けられるが、複数のフォルダを紐付けることも可能である。

図８は、実施の形態１におけるグルーピング処理後のフォルダと属性グループとの関係を説明する図である。図８には、図４との対応部分に対応する符号を付して示している。
図８の場合、フォルダＩＤが「００１１」のフォルダと属性グループの「承認済」グループとが紐付けられている。グループ名には、代表値である「承認済」を用いている。
「承認済」グループには、フォルダＩＤが「００１１」であるフォルダに紐付けられた文書Ａ、文書Ｂ及び文書Ｃに付与されている属性名の「承認済み」、「承認済」、「完了」を要素に含んでいる。

＜文書の検索＞
図９は、実施の形態１で使用する共有サーバ３０（図１参照）で実行される処理動作のうち文書の検索に関する処理動作の一例を説明するフローチャートである。図中に示す記号のＳはステップを意味する。
文書の検索では、ユーザがユーザ端末２０（図１参照）を操作し、検索クエリを入力する。入力された検索クエリは、共有サーバ３０に与えられる。
検索クエリを受け取ったプロセッサ３１（図２参照）は、ユーザが入力した検索クエリから検索語を抽出する（ステップ１１）。

次に、プロセッサ３１は、検索語を要素に含む属性グループがあるか否かを判定する（ステップ１２）。例えば抽出された検索語が、前述した「承認済」グループに含まれるか否かを判定する。判定の対象となる属性グループは複数存在してもよい。
ステップ１２で肯定結果が得られた場合、プロセッサ３１は、属性グループを用いた新たな検索クエリを生成する（ステップ１３）。本実施の形態では、プロセッサ３１は、属性グループに属する属性名を並列に列記した新たな検索クエリを生成する。
ステップ１３の終了後、又は、ステップ１２で否定結果が得られた後、プロセッサ３１は、検索クエリによる検索を実行する（ステップ１４）。

図１０は、実施の形態１による検索の実行の過程の一例を説明する図である。
前述したように、まず、検索語が抽出される。図１０では、「承認済み」が抽出されている。
次に、抽出された「承認済み」を含む属性グループが検索される。ここでは、「承認済」グループが発見されている。「承認済」グループの要素は、「承認済」と「承認済み」と「完了」の３つである。
このため、検索クエリは、「承認済」又は「承認済み」又は「完了」に書き換えられる。

結果的に、書き換え後の検索クエリを用いると、「承認済み」との属性名が付与されている文書Ａだけでなく、意味が類似の属性名が付与されている文書Ｂと文書Ｃも検索の結果に含まれることになる。
以上のように、不特定のユーザが自由に属性名を付与した文書が検索の対象となる場合において、意味が類似する属性名の全てを知らなくても、ユーザは、自身が知っている属性名を指定するだけで、関連する文書を検索の結果として取得することが可能になる。

＜実施の形態２＞
前述の実施の形態では、文書ＤＢ３３１（図２参照）に記憶されている文書の属性名が登録時のままの場合を想定しているが、本実施の形態では、属性グループの代表値を関連する各文書の属性名に追加する場合について説明する。

＜属性グループの登録＞
図１１は、実施の形態２で使用する共有サーバ３０（図１参照）で実行される属性グループの登録に関する処理動作のうちグルーピング処理の一例を説明するフローチャートである。図１１には、図７との対応部分に対応する符号を付して示している。
なお、グルーピング処理以外の処理動作は、図７の処理動作と同様である。

図１１に示すグルーピング処理はステップ３Ａである。ステップ３Ａは、ステップ２（図７参照）で肯定結果が得られた場合に実行される。
まず、プロセッサ３１は、文書に付与されている属性名が属性グループの代表値と同じか否かを判定する（ステップ３１）。同じ場合は、ステップ３１で肯定結果が得られ、異なる場合は、ステップ３１で否定結果が得られる。

ステップ３１で肯定結果が得られた文書について、プロセッサ３１は、本実施の形態におけるグルーピング処理の必要がない。このため、プロセッサ３１は、該当する文書についてはステップ４に進む。
一方、ステップ３１で否定結果が得られた文書について、プロセッサ３１は、１つの文書内に、複数の属性グループに属する属性名があるか否かを判定する（ステップ３２）。

ステップ３２で否定結果が得られた場合、プロセッサ３１は、対象とする文書の属性名に代表値を追加する（ステップ３３）。これにより、文書は、特定の属性グループに紐付けられる。
一方、ステップ３２で肯定結果が得られた場合、プロセッサ３１は、グルーピングの未処理をユーザに通知する（ステップ３４）。この場合、ユーザは、個別に、文書に付与する属性名を検討することになる。

図１２は、実施の形態２におけるグルーピング処理の途中段階の状態を説明する図である。図１２には、図８との対応部分に対応する符号を付して示している。
図１２の場合、「承認済」グループは、フォルダＩＤが「００１１」のフォルダと紐付けられている。なお、「承認済」グループの更新フラグは「ＴＲＵＥ」であり、グルーピング処理の対象であることが示されている。図１２の段階では、「承認済」グループと文書との紐付けはない。

図１３は、実施の形態２におけるグルーピング処理の完了後の状態を説明する図である。図１３には、図１２との対応部分に対応する符号を付して示している。
図１３の場合、「承認済」グループの代表値と同じ属性名が付与されている文書Ｂ以外の文書Ａと文書Ｃに対し、代表値である「承認済」が追加されている。結果的に、意味が類似する属性名が付与されている文書には、属性グループの代表値が含まれる状態になる。

＜文書の検索＞
図１４は、実施の形態２で使用する共有サーバ３０（図１参照）で実行される処理動作のうち文書の検索に関する処理動作の一例を説明するフローチャートである。図１４には、図９との対応部分に対応する符号を付して示している。
本実施の形態の場合も、ユーザがユーザ端末２０（図１参照）を操作し、検索クエリを入力する。

検索クエリを受け取ったプロセッサ３１（図２参照）は、ユーザが入力した検索クエリから検索語を抽出する（ステップ１１）。
次に、プロセッサ３１は、検索語を要素に含む属性グループがあるか否かを判定する（ステップ１２）。例えば抽出された検索語が、前述した「承認済」グループに含まれるか否かを判定する。判定の対象となる属性グループは複数存在してもよい。

ステップ１２で肯定結果が得られた場合、プロセッサ３１は、属性グループの代表値を用いた新たな検索クエリを生成する（ステップ１３Ａ）。
本実施の形態の場合、検索クエリの検索語が属性グループの代表値と同じであれば、入力された検索語がそのまま用いられるが、検索クエリの検索語が属性グループの代表値と異なるときは検索語が代表値に書き換えられる。
ステップ１３Ａの終了後、又は、ステップ１２で否定結果が得られた後、プロセッサ３１は、検索クエリによる検索を実行する（ステップ１４）。

図１５は、実施の形態２による検索の実行の過程を説明する図である。
前述したように、まず、検索語が抽出される。図１５では、「承認済み」が抽出されている。
次に、抽出された「承認済み」を含む属性グループが検索される。ここでは、「承認済」グループが発見されている。「承認済」グループの要素は、「承認済」と「承認済み」と「完了」の３つである。
本実施の形態の場合、検索クエリは、「承認済」グループの代表値である「承認済」に書き換えられる。

結果的に、書き換え後の検索クエリを用いると、「承認済み」との属性名が付与されている文書Ａだけでなく、意味が類似の属性名が付与されている文書Ｂと文書Ｃも検索の結果に含まれることになる。本実施の形態の場合、各文書の属性名には「承認済」が含まれるからである。

以上のように、不特定のユーザが自由に属性名を付与した文書が検索の対象となる場合において、意味が類似する属性名の全てを知らなくても、ユーザは、自身が知っている属性名を指定するだけで、関連する文書を検索の結果として取得することが可能になる。
なお、本実施の形態の場合も、実施の形態１の場合のように、「承認済」グループの要素は、「承認済」と「承認済み」と「完了」の３つを含めた検索クエリを用いて検索を実行することも可能である。

＜実施の形態３＞
本実施の形態では、各文書の属性名を属性グループの代表値で置換する場合について説明する。本実施の形態は、実施の形態２の変形例に当たる。

＜属性グループの登録＞
図１６は、実施の形態３で使用する共有サーバ３０（図１参照）で実行される属性グループの登録に関する処理動作のうちグルーピング処理の一例を説明するフローチャートである。図１６には、図１１との対応部分に対応する符号を付して示している。
なお、グルーピング処理以外の処理動作は、図７の処理動作と同様である。

図１６に示すグルーピング処理はステップ３Ｂである。ステップ３Ｂは、ステップ２（図７参照）で肯定結果が得られた場合に実行される。
まず、プロセッサ３１は、文書に付与されている属性名が属性グループの代表値と同じか否かを判定する（ステップ３１）。同じ場合は、ステップ３１で肯定結果が得られ、異なる場合は、ステップ３１で否定結果が得られる。
ステップ３１で肯定結果が得られた文書について、プロセッサ３１は、本実施の形態におけるグルーピング処理の必要がない。このため、プロセッサ３１は、該当する文書についてはステップ４に進む。

一方、ステップ３１で否定結果が得られた文書について、プロセッサ３１は、１つの文書内に、複数の属性グループに属する属性名があるか否かを判定する（ステップ３２）。
ステップ３２で否定結果が得られた場合、プロセッサ３１は、対象とする文書の属性名に代表値に置換する（ステップ３３Ａ）。これにより、文書は、特定の属性グループに紐付けられる。実施の形態２との違いは、属性名の数が増えない点と、ユーザが付与した属性名が文書に残らない点である。
一方、ステップ３２で肯定結果が得られた場合、プロセッサ３１は、グルーピングの未処理をユーザに通知する（ステップ３４）。この場合、ユーザは、個別に、文書に付与する属性名を検討することになる。

図１７は、実施の形態２におけるグルーピング処理の完了後の状態を説明する図である。図１７には、図１３との対応部分に対応する符号を付して示している。
なお、グルーピング処理の途中段階の状態は、実施の形態２で説明した図１２と同じである。
図１７の場合、「承認済」グループの代表値と同じ属性名が付与されている文書Ｂ以外の文書Ａと文書Ｃの属性名が、属性グループの代表値である「承認済」に置換されている。本実施の形態の場合、属性名が同じ属性グループに属する文書における属性名は全て同じ代表値に統一される。

＜文書の検索＞
本実施の形態の場合に文書の検索に関する処理動作は、実施の形態２で説明した処理動作と同じである。すなわち、図１４に示した処理動作を本実施の形態でも使用する。すなわち、実際の検索は、属性グループの代表値を用いて実行される。このため、検索の実行の過程は、実施の形態２で説明した図１５と同じ内容になる。

このため、文書の属性名に表記ゆれがあったとしても、属性グループの要素が検索語に含まれる場合には、入力された検索語に一致する属性名を有する文書Ｂと文書Ｃも検索の結果に含まれることになる。

ただし、本実施の形態の場合には、文書の属性名が登録者であるユーザの意思とは無関係に書き換えられてしまう。このため、ユーザが文書の属性を確認する場合に、自身の付与した属性名との違いに驚く可能性がある。
図１８は、実施の形態における文書の属性の表示例を説明する図である。図１８の場合、文書Ａを例示している。

文書Ａの属性名は、前述した属性名とは異なり、［Ｇ］のマークが追加されている。この［Ｇ］のマークは属性グループの代表値に置換されたことを表している。このため、「承認済［Ｇ］」の表記を確認したユーザは、代表値への書き換えの事実を知ることが可能になる。
以上のように、不特定のユーザが自由に属性名を付与した文書が検索の対象となる場合において、意味が類似する属性名の全てを知らなくても、ユーザは、自身が知っている属性名を指定するだけで、関連する文書を検索の結果として取得することが可能になる。

＜実施の形態４＞
前述の実施の形態の場合、属性グループとその代表値は事前に与えられる場合を想定している。本実施の形態では、共有サーバ３０（図１参照）が属性グループとその代表値を自動的に生成する機能を有する場合について説明する。

＜システムの構成＞
図１９は、実施の形態４で使用する共有サーバ３０のプロセッサ３１Ａにより実現される機能の一部を説明する図である。図１９には、図３との対応部分に対応する符号を付して示している。
図１９に示すプロセッサ３１Ａでは、属性グループ生成部３１６が追加されている点で前述した他の実施の形態と異なっている。

属性グループ生成部３１６は、文書ＤＢ３３１（図２参照）に記憶されている文書を順番に読み出し、それぞれに付与されている属性名を抽出する。また、抽出された属性名を集めて属性グループを生成する。
意味が類似するか否かの判定には、例えば予め用意した類語辞書を使用する。類語辞書は、人手で編集されてもよいし、機械学習により生成されてもよい。
本実施の形態の場合、フォルダ単位で意味が類似する属性名を集める。同じフォルダに属する文書の内容は、関連性が高いと推測されるためである。また、関連性の低い文書が検索の結果に含まれないようにするためでもある。

＜文書ＤＢの例＞
図２０は、文書ＤＢ３３１（図２参照）の構成例を説明する図である。本実施の形態で使用する文書ＤＢ３３１も、木構造のノードに対応するフォルダに紐付けて文書を記憶している。
図２０の場合、ルートに位置するフォルダのＩＤは「００１」であり、その子ノードの位置に２つのフォルダが存在する。１つは、ＩＤが「００１１」の「契約」フォルダであり、１つは、ＩＤが「００１２」の「設計」フォルダである。
「契約」フォルダは第１の集合の一例であり、「設計」フォルダは第２の集合の一例である。

図２０に示す「設計」フォルダには２つの文書、すなわち文書ＡＡと文書ＢＢが記憶されている。なお、文書ＡＡの作成者に対応する属性値は「Ｐさん」であり、「設計済み」に対応する属性値は「ＴＲＵＥ」である。文書ＢＢの作成者に対応する属性値は「Ｑさん」であり、「完了」に対応する属性値は「ＦＡＬＳＥ」である。
図２０の例では、属性名の「完了」を有する文書として文書Ｃと文書ＢＢを例示しているが、同じ文書Ｃが「契約」フォルダと「設計」フォルダの両方に含まれてもよい。

図２０の場合、「契約」フォルダには、属性グループの「承認済」グループが既に紐付けられている。なお、「承認済」グループの更新フラグは「ＦＡＬＳＥ」である。
図２０では、ルートフォルダに属性グループを新規に登録する。この場合、前述した属性グループ生成部３１６は、子ノードに位置する２つのフォルダから５つの文書を取得し、それぞれに付与されている属性名のうち意味が類似する属性名のグループを生成する。

図２１は、実施の形態４における属性グループの生成例を説明する図である。
図２１に示す属性グループの例は、図２０に示したルートフォルダに属する５つの文書から生成されている。
図２１に示すように、５つの文書に付与されている属性名は、２つの属性グループに分類が可能である。１つは、他の実施の形態でも説明した「承認済」グループであり、１つは、「納品完了」グループである。代表値は、集合の要素である属性名の中から１つを選んでもよいが、図２１の例では、ユーザが事前に与えている。

図２１の場合、属性名の「完了」が２つの属性グループに属している。すなわち、属性名の「完了」は、２つの属性グループの重複部分に存在する。この場合、例えばステップ３２（図１１参照）等で肯定結果が得られる。
この場合、「完了」の属性名が付与されている文書をどちらの属性グループと紐付けるかが問題となる。

因みに、「完了」の属性名が付与されている文書Ｃと文書ＢＢの両方を、「承認済」グループと「納品完了」グループの両方に紐付けることも可能である。
ただし、１つの属性名を複数の属性グループに紐付けると、検索結果に、ユーザが想定する文書だけでなく、関連性がない文書が多く混ざり混む可能性がある。例えば文書ＡＡと文書ＢＢを検索したい場合に、文書Ａ、文書Ｂ、文書Ｃも検索の結果に含まれることが起こり得る。

そこで、本実施の形態におけるプロセッサ３１Ａ（図１９参照）では、予め定めた規則に従ってグルーピング処理を実行する。すなわち、属性グループと文書との紐付け処理を実行する。予め定めた規則の具体例は、以下で説明する。

＜属性グループの登録＞
図２２は、実施の形態４で使用する共有サーバ３０（図１参照）で実行される属性グループの登録に関する処理動作のうちグルーピング処理の一例を説明するフローチャートである。図２２には、図７との対応部分に対応する符号を付して示している。
なお、グルーピング処理以外の処理動作は、図７の処理動作と同様である。

図２２に示すグルーピング処理はステップ３Ｃである。ステップ３Ｃは、ステップ２（図７参照）で肯定結果が得られた場合に実行される。
まず、プロセッサ３１は、処理の対象とする属性グループに、他の属性グループにも属する属性名があるか否かを判定する（ステップ３０１）。具体的には、図２１の「完了」に対応する属性名が含まれるか否かが判定される。

処理の対象とする属性グループに判定の条件を満たす属性名が存在する場合、ステップ３０１で肯定結果が得られる。一方、処理の対象とする属性グループに判定の条件を満たす属性名が存在しない場合、ステップ３０１で否定結果が得られる。
ステップ３０１で否定結果が得られた場合、プロセッサ３１は、処理対象とする属性グループとその要素である属性名を有する文書のグルーピングを実行する（ステップ３０２）。ここでのグルーピングは、実施の形態１～３で説明したいずれかの方法により行う。

ステップ３０１で肯定結果が得られた場合、プロセッサ３１は、共通する属性名を有する複数の属性グループの一方が他方の全部と重なるか否かを判定する（ステップ３０３）。
図２３は、複数の属性グループ間の関係を説明する図である。（Ａ）は一方の属性グループが他方の属性グループの全てを包含する関係を示し、（Ｂ）は一方の属性グループと他方の属性グループが一部分で重なるが、一方が他方を包含しない関係を示す。
図２３（Ａ）の例は、属性グループの「保管文書」に属性グループの「納品完了」の全部が含まれる場合である。なお、図２３（Ｂ）の例は、２つの属性グループ間で属性名の「完了」だけが重複する例である。

図２２の説明に戻る。
ステップ３０３で肯定結果が得られた場合、プロセッサ３１は、包含される側の属性グループの代表値を、対応する文書の属性名に追加する（ステップ３０４）。図２３（Ａ）の例であれば、属性名の「設計済み」と「完了」は、「納品完了」グループに紐付けられているフォルダの５つの文書に紐付けられる。
この例は、実施の形態２で説明したグルーピング処理に対応する。なお、グルーピング処理の方法には、実施の形態１で説明した方法や実施の形態３で説明した方法を用いることも可能である。

一方、ステップ３０３で否定結果が得られた場合、プロセッサ３１は、各属性グループに対応するフォルダに含まれる文書の数を求め、文書の数が少ない方の属性グループの優先度を上位とする（ステップ３０５）。
次に、プロセッサ３１は、優先度が同じ属性グループが複数あるか否かを判定する（ステップ３０６）。
優先度が同じ属性グループが複数存在しない場合、プロセッサ３１は、ステップ３０６で否定結果を得、優先度が高い順にグルーピングを実行する（ステップ３０７）。

具体的には、属性グループに対応する文書の数が少ない方について属性名が紐付けられる。図２３（Ｂ）の例であれば、属性名の「完了」は、「承認済」グループに紐付けられる。
なお、優先度が同じ属性グループが複数存在する場合、プロセッサ３１は、ステップ３０６で肯定結果を得、グルーピングの未処理をユーザに通知する（ステップ３０８）。この場合、ユーザは、個別に、文書に付与する属性名を検討することになる。

本実施の形態の場合、複数の属性グループに属する属性名は、属性グループに対応するフォルダの文書の数が少ない方に紐付けられる。
このため、与えられた検索語を用いた検索の結果としてユーザに提示される文書の数は、別の属性グループに紐付けられる場合に比して少なくなる。
提示される文書の数が多すぎると、目的とする文書を特定するまでの時間が長くなり易い。しかし、本実施の形態のように、紐付けられる文書の数が少ない方の属性グループに文書が紐付けられるので、属性グループを用いた検索の結果の数が少なくなり、目的とする文書が特定されるまでの時間が短く済む。

同じ属性名を含み、かつ、対応するフォルダに含まれる文書が一部又は全部重なるような属性グループどうしは、類似の属性グループとみることができる。そこで、類似の属性グループを関連付けて属性グループＤＢ３３２に記憶させてもよい。
図２４は、属性グループＤＢ３３２に記憶される「承認済」グループの構造例を示している。図２４には、図６との対応部分に対応する符号を付して示している。
図２４の場合も、属性グループに属する属性名として「承認済」、「承認済み」、「完了」が例示されている。また、属性グループとして更新フラグが「ＴＲＵＥ」に設定されている。ここで、「承認済」グループと「保管文書」グループとは、同じ「承認済み」という属性名を含み、かつ対応するフォルダに含まれる文書が一部重複している状態であり、類似の属性グループどうしである。

図２４に示す属性グループの構造と図６に示す属性グループの構造との違いは、図２４の場合、“Similar Group”として類似の属性グループに関する項目が存在する点である。このように類似の属性グループを記憶させておくことで、ユーザが「承認済」グループの代表値又は「承認済」グループに属する属性名で検索を実行した際に、類似の属性グループとして「保管文書」があることをユーザに提示して、再検索を促してもよい。
また、図２４に示す属性グループの構造には、図６に示す属性グループの構造と違って、”Priority”として優先度の項目も存在する。このように、上述した優先度を数値化して属性グループに対応付けて属性グループＤＢ３３２に記憶させてもよい。新たにグルーピング処理の対象となったフォルダに、以前に判定された優先度が記憶されている複数のフォルダが含まれ、それらの優先度の関係性が変わらない場合、優先度を再度判定する処理を省いてもよい。

＜実施の形態５＞
本実施の形態では、共有サーバ３０（図１参照）が、ユーザによる属性名の付与を補助する機能を有する場合について説明する。

＜システムの構成＞
図２５は、実施の形態５で使用する共有サーバ３０のプロセッサ３１Ｂにより実現される機能の一部を説明する図である。図２５には、図１９との対応部分に対応する符号を付して示している。
図２５に示すプロセッサ３１Ｂでは、属性名入力補助部３１７が追加されている点で前述した実施の形態４と異なっている。

属性名入力補助部３１７は、共有サーバ３０にアップロードされる新しい文書に付与する属性名の入力を補助する。
本実施の形態における属性名入力補助部３１７は、既存の属性グループをユーザの使用の頻度が高い順に並び替え、その代表値を属性名の候補としてユーザに提示する。これにより、属性名の表記ゆれを抑制する。ユーザの使用の頻度は、使用の頻度の履歴として記憶されている。

ここで、ユーザの使用の頻度には、例えば検索を実行する場合の入力率や属性名の付与率を使用する。入力率は、ユーザの検索の総回数に対する検索語として入力された回数の商として計算される。また、付与率は、ユーザが属性名を付与した総回数に対する特定の属性名が付与された回数の商として計算される。

図２６は、新しい文書を登録するユーザ端末２０（図１参照）の表示部に表示される属性名の画面１００の例を示す図である。
図２６に示す画面１００には、文書名１０１として「文書Ａ」が表示され、１つ目の属性名１０２として「作成者」が表示され、２つ目の属性名１０３として４つの候補１０３Ａが表示されている。

図２６の場合、代表名である「承認済」が１番目の候補であり、２番目の候補が「承認済み」であり、３つ目の候補が「完了」であり、４番目の候補が「その他」である。候補の並びは、入力率や付与率に基づいて決定される。この例の場合、ユーザの使用する頻度は、候補１が最も高く、次が候補２であり、次が候補３である。
なお、候補１０３Ａの下には、ユーザの操作を促す説明文１０４が表示されている。
図２６に示す画面１００が文書をアップロードするユーザに提示することにより、属性名の表記ゆれが少なくなる。

＜他の実施の形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

前述の実施の形態では、属性名を検索キーに用いる場合を想定しているが、属性値を検索キーに用いてもよい。属性値についても、ユーザが自由に登録することで表記ゆれが生じるが、類似する属性値の集合を管理することにより、表記ゆれによる検索漏れが解消される。属性値も属性の一例である。

前述した各実施の形態におけるプロセッサは、広義的な意味でのプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ等）の他、専用的なプロセッサ（例えばＧＰＵ、ＡＳＩＣ（＝Application Specific Integrated Circuit）、ＦＰＧＡ、プログラム論理デバイス等）を含む。
また、前述した各実施の形態におけるプロセッサの動作は、１つのプロセッサが単独で実行してもよいが、物理的に離れた位置に存在する複数のプロセッサが協働して実行してもよい。また、プロセッサにおける各動作の実行の順序は、前述した各実施の形態に記載した順序のみに限定されるものでなく、個別に変更してもよい。

１…文書管理システム、１０…ネットワーク、２０…ユーザ端末、３０…共有サーバ、３１、３１Ａ、３１Ｂ…プロセッサ、３２…半導体メモリ、３３…ハードディスク装置、３４…通信モジュール、１００…画面、１０１…文書名、１０２、１０３…属性名、１０３Ａ…候補、１０４…説明文、３１１…属性付与部、３１２…属性グループ管理部、３１３…登録完了通知部、３１４…検索受付部、３１５…検索実行部、３１６…属性グループ生成部、３１７…属性名入力補助部、３３１…文書ＤＢ、３３２…属性グループＤＢ

Claims (16)

1. プロセッサを有し、
   前記プロセッサは、
   文書を検索する検索キーとして、文書に付与されている属性の入力を受け付け、
   意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の代表値を用いて文書を検索する
   情報処理システム。
2. 前記プロセッサは、
   前記第１の属性を要素に含む集合の代表値である前記第２の属性が付与された文書を検索する、請求項１に記載の情報処理システム。
3. 前記第２の属性は、文書の階層的な管理に使用するディレクトリを単位に付与される、請求項２に記載の情報処理システム。
4. プロセッサを有し、
   前記プロセッサは、
   文書を検索する検索キーとして、文書に付与されている属性の入力を受け付け、
   意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の全ての要素を用いて文書を検索する
   情報処理システム。
5. 前記プロセッサは、
   前記第１の属性を要素に含む集合の全ての要素のいずれかが付与された文書を検索する、請求項４に記載の情報処理システム。
6. 前記第１の属性は、ユーザにより付与される、請求項５に記載の情報処理システム。
7. 前記プロセッサは、
   前記第２の属性が、文書の階層的な管理に使用するディレクトリを単位に付与される場合、
   前記ディレクトリに属する文書に付されている意味が類似する前記第１の属性の集合と、当該集合の代表値を与える前記第２の属性とを生成する、請求項１又は４に記載の情報処理システム。
8. 前記プロセッサは、
   前記集合の要素に変化があった場合、前記第１の属性と前記第２の属性との紐付けを更新する、請求項７に記載の情報処理システム。
9. 前記プロセッサは、
   ユーザが文書に対して前記第１の属性を付与する場合、使用の頻度の履歴に基づいて前記第２の属性を提示する、請求項１又は４に記載の情報処理システム。
10. 前記プロセッサは、
    検索キーでの使用の頻度が高い順番に前記第１の属性を提示する、請求項９に記載の情報処理システム。
11. 前記プロセッサは、
    前記集合としての第１の集合と第２の集合の両方に属する前記第１の属性が存在する場合、予め定めた規則に従って、当該第１の属性と前記第２の属性との紐付けを更新する、請求項１又は４に記載の情報処理システム。
12. 前記プロセッサは、
    前記第１の集合の全体が前記第２の集合に含まれる場合、当該第１の集合の代表値を与える前記第２の属性を、当該第２の集合の要素に追加する、請求項１１に記載の情報処理システム。
13. 前記プロセッサは、
    前記第１の集合の一部と前記第２の集合の一部が重複し、一方が他方を包含しない場合、重複部分の前記第１の属性を、要素の数が少ない方の集合の要素に設定する、請求項１１に記載の情報処理システム。
14. 前記プロセッサは、
    前記第１の集合の一部と前記第２の集合の一部が重複し、一方が他方を包含しない場合、重複部分の前記第１の属性を、対応する文書が属するディレクトリがより下位の集合の要素に設定する、請求項１１に記載の情報処理システム。
15. コンピュータに、
    文書を検索する検索キーとして、文書に付与されている属性の入力を受け付ける機能と、
    意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の代表値を用いて文書を検索する機能と、
    を実現させるプログラム。
16. コンピュータに、
    文書を検索する検索キーとして、文書に付与されている属性の入力を受け付ける機能と、
    意味が類似する複数の第１の属性を要素に含む集合の代表値として第２の属性が設定されている場合において、受け付けた検索キーに当該第１の属性が含まれるとき、当該第１の属性が属する集合の全ての要素を用いて文書を検索する機能と
    を実現させるプログラム。

Images