(57)【要約】      （修正有）【課題】文書に文書ＩＤを割り振って管理する技術において、文書ＩＤの発行を何等制限することなく発行することによる管理対象の文書ＩＤの増大を抑制する。【解決手段】ユーザが指定するジョブを実行し、該ジョブの実行により生成された文書を文書ＩＤにより管理する装置において、前記ユーザを特定する手段と、前記特定されたユーザと前記ジョブの対象文書の作成者とが一致するか否かを判定する手段と、前記判定の結果に応じ、一致する場合のみ，前記ジョブの実行により生成される文書の文書ＩＤを取得する手段と、を備える。【選択図】図６
2012088903.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが指定するジョブを実行し、該ジョブの実行により生成された文書を文書ＩＤにより管理する装置において、
前記ユーザを特定する手段と、
前記特定されたユーザと前記ジョブの対象文書の作成者とが一致するか否かを判定する手段と、
前記判定の結果に応じて、前記ジョブの実行により生成される文書の文書ＩＤを取得する手段と、
を備えたことを特徴とする装置。
【請求項２】
前記取得する手段は、前記特定されたユーザと前記対象文書の作成者とが一致すると判定された場合には前記対象文書の文書ＩＤを前記ジョブの実行により生成される文書の文書ＩＤとして継承し、前記特定されたユーザと前記対象文書の作成者とが一致しないと判定された場合には新規の文書ＩＤを前記ジョブの実行により生成される文書の文書ＩＤとして取得することを特徴とする請求項１に記載の装置。
【請求項３】
前記判定する手段は、前記ジョブの対象文書の作成者を、該対象文書のメタデータ内の情報から特定して、前記特定されたユーザと前記ジョブの対象文書の作成者とが一致するか否かを判定することを特徴とする請求項1又は２に記載の装置。
【請求項４】
前記メタデータ内の情報は、間接的にユーザを特定可能な情報であることを特徴とする請求項３に記載の装置。
【請求項５】
ユーザが指定するジョブを実行する装置において、該ジョブの実行により生成された文書を文書ＩＤにより管理する方法であって、
前記ユーザを特定するステップと、
前記特定されたユーザと前記ジョブの対象文書の作成者とが一致するか否かを判定するステップと、
前記判定の結果に応じて、前記ジョブの実行で生成される文書の文書ＩＤを取得するステップと、
を含むことを特徴とする方法。
【請求項６】
請求項５に記載の方法をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、識別情報の付された文書を管理する装置、方法及びプログラムに関する。
【背景技術】
【０００２】
従来より、文書を一意に識別可能な情報（文書ＩＤ）を文書毎に割り当てて、文書を管理することが広く行われている。例えば、特許文献１には、文書に文書ＩＤを付与して蓄積し、該文書ＩＤをキー入力又は文書ＩＤを付したページを光学的に読み取らせることで参照対象の文書を取得するという文書の管理方法が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−３３９２９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述したような従来技術においては、基本的に文書毎に一意の文書ＩＤが割り振られる。つまり、文書のコピー（紙文書→紙文書）や、ＳＥＮＤ／ＢＯＸ機能による送信（紙文書→電子文書）などで新たに文書が生成される度に新規に文書ＩＤが発行されることになる。そして、新規の文書ＩＤの発行に際しては、既存の文書ＩＤとの関連性が考慮されることはない。例えば、コピーの場合、コピー元となった文書の文書ＩＤとの関係などは一切考慮されずに、文書ＩＤはコピーされる度に無制限に発行されていく。その結果、管理対象の文書ＩＤの数が膨大となり、管理上の負荷が増大するという懸念があった。
【０００５】
また、実際のユースケースを考慮すると、文書ＩＤを新規に発行せず、既存の文書ＩＤを流用したほうが望ましい場合もあった。例えば、自分が作成した電子文書を繰り返し印刷する場合や他の記憶領域にコピーする場合等において、その都度異なる文書ＩＤを発行したのではそのすべてが別文書として管理され、文書相互の関連性を把握することができない。上記のような場合には、むしろ同一の文書ＩＤで管理した方がその電子文書に対して行われた操作（ジョブ）が一元的に履歴として管理されるため、ある電子文書をどのように利用したかを知るうえでは望ましい。
【課題を解決するための手段】
【０００６】
本発明は、ユーザが指定するジョブを実行し、該ジョブの実行により生成された文書を文書ＩＤにより管理する装置において、前記ユーザを特定する手段と、前記特定されたユーザと前記ジョブの対象文書の作成者とが一致するか否かを判定する手段と、前記判定の結果に応じて、前記ジョブの実行により生成される文書の文書ＩＤを取得する手段と、を備えたことを特徴とする。
【発明の効果】
【０００７】
本発明によれば、新規の文書ＩＤが必要に応じて発行されるので、文書ＩＤの管理負荷を軽減することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明に係る文書管理システムの構成の一例を示す図である。
【図２】ＭＦＰの内部構成を示した図である。
【図３】二次元コードが付加された紙文書（原稿）の一例を示す図である。
【図４】イメージサーバに保存される電子文書（電子データ）のデータ構成の一例を示す図である。
【図５】ＭＦＰにおいてジョブを実行する際の処理の流れを示すフローチャートである。
【図６】図５のステップ５０４における処理の詳細な流れを示すフローチャートである。
【図７】新規の文書ＩＤを取得しなかった場合のメタデータの更新結果の一例を示す図である。
【図８】新規の文書ＩＤを取得した場合のメタデータの更新結果の一例を示す図である。
【図９】ユーザ操作履歴の一例を示す図である。
【図１０】ログサーバに登録されるログの状態を示した図である。
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１０】
［実施形態１］
図１は、本発明に係る文書管理システムの構成の一例を示す図である。
【００１１】
文書管理システム１００は、ＰＣ１０１、ＭＦＰ１０２、イメージサーバ１０３、文書ＩＤサーバ１０４、ログサーバ１０５、認証サーバ１０６が、ネットワーク１０７を介して相互に接続される構成で成り立っている。
【００１２】
ＰＣ１０１は、各種の電子文書を生成可能なパーソナルコンピュータである。
【００１３】
ＭＦＰ１０２は、複写機能、印刷機能、ＢＯＸ機能、ＳＥＮＤ機能等を搭載する画像形成装置としての複合機（Multifunction Peripheral）である。ここで、ＢＯＸ機能とはスキャン等で取得した画像データを画像形成装置やサーバのＨＤＤ等に保存しておく機能である。ＳＥＮＤ機能とは、スキャン等で取得した画像データを外部機器に対して送信する機能である。なお、画像形成装置は、画像をメモリ上あるいは紙上に形成できるものであれば何でもよく、ＭＦＰに限られない。
【００１４】
イメージサーバ１０３は、ＰＣ１０１やＭＦＰ１０２から送られた電子文書（電子データ）を保存するサーバである。
【００１５】
文書ＩＤサーバ１０４は、文書ＩＤを発行するサーバである。
【００１６】
ログサーバ１０５は、ＰＣ１０１やＭＦＰ１０２からユーザが指定し実行されたジョブの履歴（ログ）を管理するサーバである。
【００１７】
認証サーバ１０６は、ＰＣ１０１やＭＦＰ１０２にログインしようとしているユーザが正規のユーザかどうかを認証する処理を行うサーバである。認証サーバには、個々のユーザを特定することが可能な各種の情報（以下、「ユーザ特定情報」という。）が格納される。ユーザ特定情報には、ユーザＩＤ、パスワード、ユーザ名、メールアドレスなどのユーザに１対１で対応する直接にユーザを特定可能な情報に加え、ユーザを間接的に特定可能な情報も含まれる。例えば、あるＭＦＰを専ら使用する者が決まっている場合、そのＭＦＰのシリアル番号が分かれば、仮にユーザＩＤ等が分からなくても当該ＭＦＰを使って原稿をコピーしようとしている者を間接的に特定することができる。そこで、普段使用するＭＦＰのシリアル番号やその製造会社名等の情報もユーザを間接的に特定可能な情報として「ユーザ特定情報」に含まれ得る。
【００１８】
なお、本実施形態に係る文書管理システムにおいては、上述の通り、電子文書の保存、文書ＩＤの発行、ログの管理、ユーザ認証といった機能毎に個別のサーバを設けている。しかしながら、すべての機能が個別のサーバで構成される必要はない。例えば、認証サーバ１０６や文書ＩＤサーバ１０４を設けることなく、ＭＦＰ１０２の内部にこれらの機能を持たせてもよい。そして、イメージサーバ１０３とログサーバ１０５の機能を併せ持つ１のサーバを用いてもよい。このように本発明に係る文書管理システムは必要に応じてそのシステム構成を変更することが可能である。
【００１９】
図２は、ＭＦＰ１０２の内部構成を示した図である。
【００２０】
ＣＰＵ２００は、後述する各装置を統括的に制御するプロセッサであり、メモリ２０４に記憶されたＯＳやアプリケーション等のプログラムを実行する。
【００２１】
表示装置２０１は、タッチパネルなどの画面を表示するための装置である。ユーザは、ログイン時の入力操作、ＢＯＸコピーや印刷といった所望の処理を行うための指示等を表示装置２０１に表示される操作画面（不図示）を介して行う。
【００２２】
スキャナ装置２０２は、不図示の原稿台にセットされた原稿を走査（スキャン）して画像データを得るための原稿読取装置である。
【００２３】
ネットワークＩ／Ｆ２０３は、各サーバやＰＣと通信を行い各種指示やデータ等のやりとりを行うためのインタフェースである。
【００２４】
メモリ２０４は、ＲＯＭやＲＡＭで構成され、ＣＰＵ２００がＭＦＰ１０１を制御するために実行する各種命令（ＯＳやアプリケーションプログラム）や実行結果等を記憶する。
【００２５】
ＨＤＤ２０５は、スキャナ装置２０２でスキャンした画像データ等の保存に使用される。
【００２６】
プリンタ装置２０６は、画像データを印刷出力する。
【００２７】
図３は、二次元コード３０２が付加された紙文書（原稿）３０１の一例を示す図である。二次元コードには様々な種類が存在するが、ここでは一般的に使用されることの多いＱＲコードの例を示している。
【００２８】
図３から明らかなように、二次元コード３０２は、紙文書上では可視化された画像として印字される。二次元コードに含まれる情報は、デコード（復号化）されて画像データに付随する。すなわち、電子文書の場合、二次元コード３０２は原稿３０１の画像データから分離することになる。
【００２９】
二次元コード３０２には、まず、文書を一意に識別し他の文書と区別することを可能にする、文字列や数字で構成される文書ＩＤが含まれる。この文書ＩＤを、原稿３０１の画像データと紐付けてイメージサーバ１０３に保存することにより、多くの画像データの中から特定の画像データを識別することが可能となる。文書ＩＤは基本的には文書単位で付与される。すなわち、１の文書に対して唯一無二の文書ＩＤが１つ割り当てられることを基本とするが、ページ単位やジョブ単位で与えるようにしてもよい。文書ＩＤには、重複や偶然の一致が起こり得ない既知の仕組み、例えばＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）を利用してもよい。
【００３０】
また、二次元コードには、ユーザが付した当該文書の名称（文書名）の情報も含まれる。
【００３１】
そして、メタデータの一部として、誰が当該文書の出力（作成）を指示したのかを追跡するのに必要な情報（以下、「追跡情報」という。）が含まれる。追跡情報の中身としては、例えば、文書の出力を指示したユーザのユーザ名（作成者）やメールアドレス、文書の出力日時、ＭＦＰのシリアル番号や生産会社名などがある。なお、本明細書において「作成者」とは、あくまでその文書の出力を指示した者を意味する。したがって、ユーザＡが最初に作った文書の画像データを利用してユーザＢがプルプリントした場合の「作成者」はユーザＢである。この場合のユーザＡは「原作成者」として別途その情報が保存されることになる。
【００３２】
さらに、メタデータの一部として、その文書がコピー禁止か、コピー許可か、パスワードによる条件付きコピー許可かといった文書のセキュリティに関する情報（以下、「セキュリティ情報」という。）が含まれる。セキュリティ情報には、コピー許可／不許可の他にも、例えば、スキャン許可／不許可に関する情報、外部への送信の許可／不許可に関する情報、ＭＦＰ内部のメモリ等への格納の許可／不許可に関する情報なども含まれ得る。
【００３３】
図４は、イメージサーバ１０３に保存される電子文書（電子データ）のデータ構成の一例を示す図である。
【００３４】
電子文書のデータは、文書ＩＤフィールド、文書名フィールド、画像情報フィールドからなり、画像情報フィールドには、画像データとそれに付随するメタデータが含まれる。
【００３５】
画像データは例えばＰＤＦやＰＤＬ等の形式で保存される。そして、メタデータは、その内容が随時変化することが想定されるため、画像データとは分離して保存される。ここでは、メタデータには、原作成者、作成者、作成者のメールアドレス、出力日時、出力を行ったＭＦＰのシリアル番号及びコピーの可否を示す情報が含まれる。
【００３６】
図４の例では、文書ＩＤ「Ox00112233445566778899aabbccddeeff」、文書名「document1」、の画像データがＰＤＦ形式で保存されている。そして、メタデータフィールドには、原作成者「Hiroshi Makino」、作成者「Taro Yamada」、メールアドレス「t-yamada.ABC.co.jp」の各情報が格納されている。さらに、出力日時「2010年9月7日、10時57分」、ＭＦＰのシリアル番号「A10093831」の情報が格納されている。そして、セキュリティ情報として、コピーが可能であることを示す情報が格納されている。
【００３７】
次に、本実施形態に係る文書管理システムにおいて、文書がどのように管理されるのかを具体例を用いて説明する。
【００３８】
図５は、ＭＦＰ１０２においてジョブを実行する際の処理の流れを示すフローチャートである。なお、本実施形態においては、メモリ２０４に格納されたアプリケーション（プログラム）がユーザの操作指示で起動し、ＣＰＵ２００がこれを実行することにより以下の各ステップが実現される。
【００３９】
ＭＦＰ１０２を起動すると、ステップ５０１において、ＣＰＵ２００は、各サーバへの問い合わせを行い、各サーバが正常に動作する状態かどうかを確認する。各サーバが正常に動作することが確認されると、ステップ５０２に進む。
【００４０】
ステップ５０２において、ＣＰＵ２００は、ログインしようとするユーザの認証処理を行う。具体的には、まず、ＣＰＵ２００は、表示装置２０１の操作画面等を介してログインしようとするユーザにユーザＩＤやパスワード等の情報の入力を促し、入力された情報を認証サーバ１０６に送信する。認証サーバ１０６は、受け取った情報から正規のユーザであることを確認すると、認証に成功した旨の通知及び当該ユーザのユーザ特定情報をＭＦＰ１０２に送信する。そして、ＣＰＵ２００は、受け取ったユーザ特定情報を記憶手段（メモリ２０４やＨＤＤ２０５等）に格納する。
【００４１】
ステップ５０３において、ＣＰＵ２００は、ログインユーザからジョブの指定を受け付ける。例えば、プルプリントの場合、ユーザは、表示装置２０１の操作画面上でプルプリント機能を指定し、さらにイメージサーバ１０３に登録された電子文書の中から印刷対象の文書を選択して、印刷出力の指示を行う。印刷対象となる文書の選択は、文書名や文書ＩＤの入力、或いは操作画面上に表示されたプレビュー画像から任意の画像を指定する等により行うことができる。
【００４２】
ステップ５０４において、ＣＰＵ２００は、選択された文書の画像データとそのメタデータとをイメージサーバ１０３からネットワークＩ／Ｆ２０３を介して取得して記憶手段に格納する。そして、格納したメタデータから画像データに関連する情報を抽出する。そして、抽出した情報とステップ５０２で格納したログインユーザのユーザ特定情報とを比較判定し、判定結果に応じて新たな文書ＩＤを文書ＩＤサーバ１０４から取得する。さらに、必要なメタデータの更新処理を行う。このステップ５０４における処理の詳細については後述する。
【００４３】
ステップ５０５において、ＣＰＵ２００は、選択された文書の画像データを用いて指定されたジョブを実行する。指定されたジョブがプルプリントの場合には、更新したメタデータをエンコードして二次元コードを作成した上で、該二次元コードを画像データに合成し、プリンタ装置２０６から印刷出力する。
【００４４】
そして、ステップ５０６において、ＣＰＵ２００は、ネットワークＩ／Ｆ２０３を介して、実行されたジョブに関する情報をログサーバ１０５に送信する。実行されたジョブに関する情報とは、具体的には、ステップ５０３で指定されたジョブの内容（例えば、文書ＩＤ：Ox001122334455666778899aabbccddeeffのプルプリント）である。実行されたジョブの情報を受け取ったログサーバ１０５は、履歴情報（ログ）として所定の記憶領域に保存する。ログサーバ１０５においてログがどのように保存されるかについては後述する。
【００４５】
なお、ステップ５０１における問い合わせの結果、イメージサーバ１０２がダウンしていることが判明した場合には、イメージサーバ１０４に登録された電子文書にアクセスすることができない。そうなると、プルプリントやボックスコピーといった種類のジョブの処理はできないことになる。したがって、例えば、前述のステップ５０３でのジョブの受付時に、ＰＣから印刷データを送信して行う印刷や紙文書から紙文書へのコピー等、イメージサーバ１０３へのアクセスを要しないジョブしか実行できない旨のメッセージを表示装置２０１に表示させる。
【００４６】
また、問い合わせの結果、文書ＩＤサーバ１０４がダウンしていることが判明した場合には、新規の文書ＩＤを取得することができない。そこで、前述のステップ５０３でのジョブの受付時に、例えばその旨のメッセージを表示装置２０１に表示する。或いは、前述のステップ５０３でジョブ自体を受け付けできないようにしてもよい。
【００４７】
また、問い合わせの結果、ログサーバ１０５がダウンしていることが判明した場合には、ログサーバ１０５にログを登録することができない。そこで、前述のステップ５０３でのジョブの受付時にその旨のメッセージを表示装置２０１に表示した上で、ステップ５０６において実行したジョブの情報をログサーバ１０５に送信せずに、一時的にＨＤＤ２０５に保存するようにしてもよい。この場合、ＭＦＰ１０２は、ログサーバ１０５が復旧した後、保存しておいたジョブの情報をログサーバ１０５に送信して登録させるようにしてもよい。或いは、前述のステップ５０３でジョブ自体を受け付けできないようにしてもよい。
【００４８】
さらに、問い合わせの結果、認証サーバ１０６がダウンしていることが判明した場合には、ユーザが正規のユーザかどうかを確認できないことになる。この場合、例えばＭＦＰ１０２は現在使用できない旨のメッセージを表示装置２０１に表示し、前述のステップ５０３でジョブ自体を受け付けできないようにする等の処理を行う。
【００４９】
次に、本実施形態の特徴である図５のフローチャートのステップ５０４における処理の詳細について、プルプリントの場合を例に説明する。
【００５０】
図６は、ステップ５０４における処理の詳細な流れを示すフローチャートである。
【００５１】
ステップ６０１において、ＣＰＵ２００は、指定されたジョブの対象となる文書の入力態様（入力情報ソース）が電子データかどうかを判定する。指定されたジョブがプルプリントの場合、イメージサーバ１０３に登録された電子文書を用いて印字出力がなされる。よって、ジョブの対象文書の入力態様は電子データであると判定され、ステップ６０２に進む。仮に、指定されたジョブが原稿台にセットされた紙文書のコピー印刷である場合、コピー印字出力は紙文書をスキャンして得られた画像データが用いられるので、ジョブの対象文書の入力態様は電子データではないと判定され、ステップ６０８に進むことになる。
【００５２】
ステップ６０２において、ＣＰＵ２００は、ネットワークＩ／Ｆ２０３を介して、指定されたジョブの処理で使用する電子文書（すなわち、図５のステップ５０３で選択された文書の電子データ）をイメージサーバ１０３に対して要求し、取得する。
【００５３】
ステップ６０３において、ＣＰＵ２００は、取得した電子データにメタデータが含まれるかどうかを判定する。メタデータが含まれていればステップ６０４に進み、含まれていない場合はステップ６０８に進む。
【００５４】
ステップ６０４において、ＣＰＵ２００は、取得した電子データに文書ＩＤが含まれているかどうかを判定する。文書ＩＤが含まれていればステップ６０５に進み、含まれていない場合はステップ６０８に進む。
【００５５】
ステップ６０５において、ＣＰＵ２００は、前述のステップ５０２で記憶手段に格納された、ログインユーザのユーザ特定情報を読み出し、取得する。
【００５６】
ステップ６０６において、ＣＰＵ２００は、取得したユーザ特定情報とメタデータ内の作成者の情報とを比較し、ログインユーザとジョブの対象文書の作成者とが一致するかどうかを判定する。例えば、取得したユーザ特定情報にユーザ名、メールアドレス及び使用するＭＦＰのシリアル番号の各情報が含まれていたとする。したがって、作成者としてのユーザ名がメタデータから分かる場合には、ここでの判定はユーザ名同士を比較することでなされる。一方、何らかの理由によりメタデータの作成者欄にデータが入っていない或いはその内容が認識できないといったことも考えられる。そこで、ユーザ名から両者が一致するかどうかを判定することができないような場合には、ユーザ名以外の情報を用いてこの判定処理を行うようにしてもよい。例えば、「メールアドレス」や「使用するＭＦＰのシリアル番号」を用いて判定するようにしてもよい。具体的には、ユーザ特定情報及びメタデータに共通して含まれるこれらの情報を比較し、双方或いはいずれかが一致していればログインユーザとジョブの対象文書の作成者は一致すると判定するようにしてもよい。ログインユーザとジョブの対象文書の作成者が一致すると判定された場合はステップ６０８に進む。一致しないと判定された場合はステップ６０７に進む。
【００５７】
ステップ６０７において、ＣＰＵ２００は、ネットワークＩ／Ｆ２０３を介して、文書ＩＤサーバ１０４に対し新規の文書ＩＤの発行を依頼し、ジョブの実行により生成される文書に付与するための新たな文書ＩＤを取得する。
【００５８】
ステップ６０８において、ＣＰＵ２００は、メタデータを更新し、今回の出力画像データに付加するメタデータを生成する。この際、ステップ６０７で新たな文書ＩＤを取得した場合には当該新たな文書ＩＤの基でメタデータの更新を行う。新たな文書ＩＤを取得しなかった場合にはジョブの対象文書の文書ＩＤの基でメタデータの更新を行う。すなわち、ステップ６０７で新たな文書ＩＤを取得しなかった場合には、ジョブの対象文書の文書ＩＤを継承して、メタデータ内の必要な情報の更新のみを行う。
【００５９】
図７は、新規の文書ＩＤを取得しなかった場合のステップ６０８における処理結果の一例である。ここでは、図４の「Document1」を、その作成者である「Taro Yamada」が2010年9月22日 13時2分」に同じＭＦＰを使用してプルプリントした場合の処理結果を示している。文書ＩＤをはじめほとんどの内容がジョブの対象となった文書の電子データから変わっておらず、出力日時の情報だけが今回の出力日時に変更されている。
【００６０】
一方、図８は、新規の文書ＩＤを取得した場合のステップ６０８における処理結果の一例である。ここでは、図４の「Document1」を、その作成者ではない「Seiji Suzuki」が「2010年9月28日 9時33分」に異なるＭＦＰ（シリアル番号：B10073816）を使用してプルプリントした場合の処理結果を示している。出力日時の情報に加え、文書ＩＤは新たに発行された「Tx99887766554433221100gghhiijjkkll」、文書名は「Document2」、作成者は「Seiji Suzuki」、メールアドレスは「s-suzuki.ABC.co.jp」、シリアル番号は「B10073816」に変更されている。ちなみに、「Document1」の原作成者である「Hiroshi Makino」が「Document1」を利用してプルプリントを行った場合も作成者は一致しないと判定されるので、これと同様の処理結果となる。もっとも、原作成者が自己の作成した文書の印刷物を必要とするときは、自身が作成した文書（電子データ）を用いたジョブを実行すれば足りるから、新たな文書ＩＤが発行されるケースは稀である。
【００６１】
以上、ユーザがプルプリントを指示した場合を例に説明したが、本発明はあらゆる種類のジョブについて適用可能であることは言うまでもない。例えば、紙文書をスキャナで読み取って画像データに変換した後メモリに記憶する「スキャンtoメモリ」や、変換した電子データを電子メールにより送信する「ＳＥＮＤ」等、あらゆるジョブに適用することができる。ただし、紙文書を入力情報ソースとする場合は、紙文書の同一性を保つため、加筆や修正を行わない等、運用上の制約を加える必要となるであろう。
【００６２】
次に、ログサーバ１０５におけるログの管理について説明する。
【００６３】
図９は、ある文書についてのユーザ操作履歴の一例を図にしたものである。この図で示されるユーザ操作の内容を古い順に並べると以下のようになる。
【００６４】
１）ユーザＡがＰＣで作成した電子文書（画像データａ）をＢＯＸ保存
２）ユーザＡが画像データａをＢＯＸコピー
３）ユーザＡが画像データａを印刷
４）ユーザＢが画像データａをＢＯＸコピー（画像データｂを生成）
５）ユーザＡが画像データａを印刷
６）ユーザＢが画像データｂをＢＯＸコピー
７）ユーザＢが画像データｂを印刷
８）ユーザＣが画像データｂを印刷（画像データｃを生成）
【００６５】
図１０は、上記ユーザ操作によるジョブが順次実行された場合において、ログサーバ１０５にどのようにログが登録されるかを示した図である。
【００６６】
従来の技術においては、ジョブが実行される度に新たな文書ＩＤが付与される。そのため、図１０の（ｂ）に示すように、実行されたジョブの情報（ログ）は単に時系列で登録されて管理される。
【００６７】
本実施形態においては、ログインユーザとジョブの対象文書の作成者が一致している場合には新たな文書ＩＤが発行されないので、図１０の（ａ）に示すように、作成者が共通する同一の文書については単一の文書ＩＤでログが管理される。図１０の（ａ）において「ＬＯＧ１」は、当該文書を用いたジョブの実行者が作成者自身である場合の履歴情報を示し、「ＬＯＧ２」は当該文書を用いたジョブの実行者が作成者以外のユーザである場合の履歴情報を示している。したがって、ある画像データの作成者が繰り返し同じ画像データを用いてジョブを実行する場合、それらの操作履歴はすべて「ＬＯＧ１」内に保存されることになる。
【００６８】
図１０の（ａ）からは、例えば文書ＩＤ「１」の画像データａについて、以下のことを理解することができる。まず、ユーザＡが作成者であり、ユーザＡ自身がこれを用いて「Box in」、「Box copy」、「print」、「print」の各ジョブを実行したことが分かる。さらに、ユーザＡ以外のユーザが画像データａを用いて「Box copy」を行ったことも分かる。図１０の（ｂ）からこのような事実を把握することは不可能である。
【００６９】
このように、本実施形態に係る文書管理システムによれば、「作成者」が同一である限り、内容が同一の文書（画像データ）は一つの文書ＩＤの基に一元的に管理される。したがって、文書ＩＤの管理上の負荷を軽減することができる。また、本実施形態においては、文書ＩＤ単位で登録される履歴情報を見れば、作成者自身が文書（電子データ）をどのように利用し、作成者以外のユーザにどのように利用されたかを容易に知ることができる。
【００７０】
さらに、１つの文書ＩＤに対応する画像データを１つだけ保存しておけば足りるので、画像データを保存するためのイメージサーバ等の記憶領域を効率的に使用することができる。
【００７１】
［実施形態２］
実施形態１では、ログインユーザと入力情報ソースの作成者が一致する場合に新規の文書ＩＤを発行せずに既存の文書ＩＤを流用する態様について説明した。
【００７２】
しかし、本発明は上記のような態様に限られるものではなく、例えば以下のような場合においても新規の文書ＩＤの発行を抑制することができる。
【００７３】
まず、ログインユーザがシステム管理者やサービスマン等の一定の権限を有する者である場合である。この場合には、例えば、新規の文書ＩＤを発行する代わりに、一般ユーザの場合に付与される文書ＩＤとは異なる固有の文書ＩＤを付与するようにしてもよい。
【００７４】
また、ジョブ単位でユーザを特定する必要がなく、運用上のユーザを特定できれば足りるという場合も考えられる。この場合には、例えば、同一ユーザによる１つのログイン期間中は、その間のすべてのジョブで出力される文書について１の文書ＩＤのみを付与するようにしてもよい。これにより複数のジョブをまとめて管理することが可能となる。
【００７５】
さらに、社外などログ管理の範囲外にある外部装置との間で画像データの送受信を行う場合には、ジョブの内容に応じて新規に文書ＩＤを発行するかどうかを決定するようにしてもよい。具体的には、まず、ログ管理の範囲外から受信した画像データを利用するジョブの場合は、例えその画像データに付与されている文書ＩＤがログ管理を行う範囲内で付与されたものであったとしても、新規に文書ＩＤを発行する。画像データの内容が編集されている可能性があり文書の同一性が担保できないからである。これに対し、ＦＡＸやＳＥＮＤなどのログ管理の範囲外に画像データを送信するジョブの場合には、新規の文書ＩＤを発行せずに既存の文書ＩＤを流用する。外部に送信される文書であり、新たに文書ＩＤを発行して管理するメリットが少ないためである。
【００７６】
このように本実施形態においては、様々な場面に応じて文書ＩＤの発行を抑制できるので文書ＩＤの管理上の負荷を軽減することができる。
【００７７】
（その他の実施例）
また、本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【図１】
2012088903.tif 000003
【図２】
2012088903.tif 000004
【図４】
2012088903.tif 000005
【図５】
2012088903.tif 000006
【図６】
2012088903.tif 000007
【図７】
2012088903.tif 000008
【図８】
2012088903.tif 000009
【図９】
2012088903.tif 000010
【図１０】
2012088903.tif 000011
【図３】
2012088903.tif 000012