(57)【特許請求の範囲】
【請求項１】
第一の情報管理手段においてツリー構造によって管理されている情報をノードごとに順番に第二の情報管理手段に移管する情報移管手段と、
順番に移管される過程において現在処理対象とされている第一のノードに関する情報を記憶する処理対象情報記憶手段と、
前記第一のノードの親ノードに関する情報を記憶する親情報記憶手段とを有し、
前記情報移管手段は、前記親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親情報記憶手段に記憶されている情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする情報処理装置。
【請求項２】
前記情報移管手段は、前記親ノードの親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親ノードの祖先ノードに関する情報を、当該祖先ノードに対応するノードが前記第二の情報管理手段より検索されるまで第一の情報管理手段より取得して蓄積手段に蓄積し、蓄積順と逆順に前記蓄積手段に蓄積されている情報を取り出し、取り出された情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記情報移管手段は、前記第一のノードを移管する前に前記第一のノード対応するノードが前記第二の情報管理手段に存在するときは、前記処理対象情報記憶手段に記憶されている情報に基づく前記第二の情報管理手段へのノードの作成は行わないことを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
コンピュータが実行する情報処理方法であって、
第一の情報管理手段においてツリー構造によって管理されている情報をノードごとに順番に第二の情報管理手段に移管する情報移管手順と、
順番に移管される過程において現在処理対象とされている第一のノードに関する情報を記憶する処理対象情報記憶手順と、
前記第一のノードの親ノードに関する情報を記憶する親情報記憶手順とを有し、
前記情報移管手順は、前記親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親情報記憶手順において記憶されている情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする情報処理方法。
【請求項５】
前記情報移管手順は、前記親ノードの親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親ノードの祖先ノードに関する情報を、当該祖先ノードに対応するノードが前記第二の情報管理手段より検索されるまで第一の情報管理手段より取得して蓄積手段に蓄積し、蓄積順と逆順に前記蓄積手段に蓄積されている情報を取り出し、取り出された情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする請求項４記載の情報処理方法。
【請求項６】
前記情報移管手順は、前記第一のノードを移管する前に前記第一のノード対応するノードが前記第二の情報管理手段に存在するときは、前記処理対象情報記憶手順において記憶されている情報に基づく前記第二の情報管理手段へのノードの作成は行わないことを特徴とする請求項４又は５記載の情報処理方法。
【請求項７】
コンピュータを、
第一の情報管理手段においてツリー構造によって管理されている情報をノードごとに順番に第二の情報管理手段に移管する情報移管手段と、
順番に移管される過程において現在処理対象とされている第一のノードに関する情報を記憶する処理対象情報記憶手段と、
前記第一のノードの親ノードに関する情報を記憶する親情報記憶手段として機能させ、
前記情報移管手段は、前記親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親情報記憶手段に記憶されている情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする情報処理プログラム。
【請求項８】
前記情報移管手段は、前記親ノードの親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親ノードの祖先ノードに関する情報を、当該祖先ノードに対応するノードが前記第二の情報管理手段より検索されるまで第一の情報管理手段より取得して蓄積手段に蓄積し、蓄積順と逆順に前記蓄積手段に蓄積されている情報を取り出し、取り出された情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする請求項７記載の情報処理プログラム。
【請求項９】
前記情報移管手段は、前記第一のノードを移管する前に前記第一のノード対応するノードが前記第二の情報管理手段に存在するときは、前記処理対象情報記憶手段に記憶されている情報に基づく前記第二の情報管理手段へのノードの作成は行わないことを特徴とする請求項７又は８記載の情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、及び情報処理プログラムに関し、特に管理情報の移管を実行する情報処理装置、情報処理方法、及び情報処理プログラムに関する。
【背景技術】
【０００２】
従来、文書情報を電子的に管理するため文書管理システムが広く利用されている。文書管理システムにおいては、基本的に実体ファイルと書誌情報とが文書ごとに保存され、管理される。
【０００３】
ところで、或る文書管理システムから他の文書管理システムへ管理情報を移管したい場合がある。ここで、移管元と移管先との文書情報の管理形態（書誌情報の構成等）が異なる場合、いわゆる文書情報のコンバート作業が必要とされる。
【０００４】
一般的に、コンバート作業中は、移管元はもとより移管先においてもシステムの利用は制限される。これは、コンバート中に移管先の文書情報の構成が編集されてしまっては、適切に文書情報を移管することができなかったからである。
【特許文献１】特開２００４−３４１７７７号公報
【特許文献２】特開２００６−３１８２８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、文書管理システムは日常業務に密接に関連している場合が多く、その利用が制限されることにより、業務の円滑な遂行が妨げられる可能性がある。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、管理情報の移管時における当該管理情報の利用制限を緩和させることのできる情報処理装置、情報処理方法、及び情報処理プログラムの提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、本発明は、第一の情報管理手段においてツリー構造によって管理されている情報をノードごとに順番に第二の情報管理手段に移管する情報移管手段と、順番に移管される過程において現在処理対象とされている第一のノードに関する情報を記憶する処理対象情報記憶手段と、前記第一のノードの親ノードに関する情報を記憶する親情報記憶手段とを有し、前記情報移管手段は、前記親ノードに対応するノードが前記第二の情報管理手段に存在しないときに、前記親情報記憶手段に記憶されている情報に基づいて前記第二の情報管理手段にノードを作成することを特徴とする。
【０００８】
このような情報処理装置では、管理情報の移管時における当該管理情報の利用制限を緩和させることができる。
【発明の効果】
【０００９】
本発明によれば、管理情報の移管時における当該管理情報の利用制限を緩和させることのできる情報処理装置、情報処理方法、及び情報処理プログラムを提供することができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における文書情報コンバートシステムの構成例を示す図である。同図において、文書管理装置１０ｄ及び文書管理装置１０ｓ（以下、総称する場合「文書管理装置１０」という。）は、ＬＡＮ（Local Area Network）等のネットワークを介して接続されている。
【００１１】
文書管理装置１０ｄ及び１０ｓは、文書管理システム１１ｄ又は１１ｓ（以下、総称する場合「文書管理システム１１」という。）を備える。文書管理システム１１ｄ及び１１ｓは、いずれも文書情報を管理するためのいわゆるデータベースシステムを実現するソフトウェアである。本実施の形態では、文書管理システム１１ｄにおいて管理されている文書情報を文書管理システム１１ｓへ移管（コピーも含む）する例について説明する。なお、文書管理システム１１ｄと文書管理システム１１ｓとでは、文書情報の管理形態、すなわち、文書情報の形式又は構成等（以下、「文書形式」という。）が異なる。
【００１２】
図２は、二つの文書管理システムにおける文書形式の相違を説明するための図である。同図において、左側は、移管元である文書管理システム１１ｓの文書情報（文書情報Ｓ）を示し、右側は、移管先である文書管理システム１１ｄの文書情報（文書情報Ｄ）を示す。図示されるように、いずれもツリー構造（階層構造）によって文書情報が管理される。
【００１３】
文書管理システム１１ｓにおいて、ツリーのノードの種別は、「キャビネット」、「フォルダ」、又は「文書」のいずれかに分類される。文書管理システム１１ｄの各ノードの名前は、「名称」という属性によって示される。各ノードは、当該ノードのシリアル番号と親ノードのシリアル番号とを有する。シリアル番号は、ノードの種別ごとに一意な番号である。したがって、同一のシリアル番号を有するフォルダと文書が存在しうるが、これらはノードの種別によって区別される。なお、子フォルダの方が親フォルダよりシリアル番号は大きいこととする。また、兄弟フォルダ間においては、シリアル番号の小さい方を兄フォルダと呼び、大きい方を弟フォルダと呼ぶ。
【００１４】
各ノードの種別の意味については、公知の文書管理システムにおけるものと同様であるため、ここでは詳細については言及しない。なお、文書管理システム１１ｓにおいてキャビネットは複数定義されうる。すなわち、複数のツリー構造が構成されうる。
【００１５】
一方、文書管理システム１１ｄにおいて、ツリーのノードの種別は、「フォルダノード」「文書ノード」のいずれかに分類される。また、各ノードの名前は「名前」という属性によって示される。
【００１６】
このように、二つの文書管理システム１１では、ノードの種別の定義や各ノードにおける書誌情報の構成等が異なる。そこで、文書管理装置１０ｄはコンバータ１２を備える。コンバータ１２は、文書管理システム１１ｓにおける文書形式（以下、「文書形式Ｄ」という。）から文書管理システム１１ｄにおける文書形式（以下、「文書形式Ｄ」という。）への変換を実行する。図２における文書情報Ｄは、文書情報Ｄをコンバートした結果を示す。
【００１７】
なお、本実施の形態では、移管先（文書管理装置１１ｄ）にコンバータ１２が備えられた例について説明するが、コンバータ１２は、移管元（文書管理装置１１ｓ）に備えられていてもよい。
【００１８】
図３は、第一の実施の形態におけるコンバータの構成例を示す図である。同図では、コンバータ１２の機能と、当該機能を実現するためにコンバータ１２において保持される情報（保持情報）とが示されている。
【００１９】
コンバータ１２の機能は、文書情報取得部１２１、文書情報変換部１２２、文書情報登録部１２３、及びマッピングテーブル１２４等によって実現される。文書情報取得部１２１は、文書管理システム１１ｓより文書情報を取得する。文書情報変換部１２２は、取得された文書情報について文書形式Ｓから文書形式Ｄへの変換を実行する。文書情報登録部１２２は、文書形式Ｄに変換された文書情報を文書管理システム１１ｄに登録する。なお、文書情報変換部１２２は、文書形式の変換に際し、マッピングテーブル１２４を参照する（用いる）。
【００２０】
図４は、マッピングテーブルの構成例を示す図である。同図では、マッピングテーブル１２４として、属性マッピングテーブル１２４ａ及びノードマッピングテーブル１２４ｂが例示されている。属性マッピングテーブル１２４ａには、移管元の文書情報における属性（書誌情報）と移管先の文書情報における属性との対応関係が登録されている。図中では、移管元における「名称」は、移管先の「名前」に対応することが示されている。ノードマッピングテーブル１２４ｂには、移管元と移管先とのノードの種別の対応関係が登録されている。図中では、移管元におけるキャビネット、フォルダ、文書は、それぞれ移管先におけるフォルダノード、フォルダノード、文書ノードに対応することが示されている。すなわち、マッピングテーブル１２４には、文書形式の相違に関する各種の対応関係が登録されている。
【００２１】
保持情報は、処理対象情報１２５、元親情報１２６、先親情報１２７、及び処理待ちスタック１２８等より構成され、物理的にはメモリ装置１０３に格納される。処理対象情報１２５は、処理対象とされているノードに関する情報（名称、フォルダ又は文書の別、親情報等）を保持するための変数である。元親情報１２６は、基本的に処理対象とされているノードの移管元の親ノードに関する情報を保持するための変数である。先親情報１２７は、基本的に処理対象とされているノードの移管先の親ノードに関する情報を保持するための変数である。処理待ちスタック１２８は、後述される親ノードの再作成処理おいて利用されるスタック型の変数である。
【００２２】
文書管理装置１０ｄ及び１０ｓ（文書管理装置１０）のハードウェア構成について説明する。図５は、本発明の実施の形態における文書管理装置のハードウェア構成例を示す図である。図５の文書管理装置１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有するように構成される。
【００２３】
文書管理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００２４】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って文書管理装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００２５】
以下、コンバータ１２によって実行される処理手順について説明する。本実施の形態では、コンバート中（移管中）であっても、移管先の文書管理システム１１ｄの文書情報の編集は可能であるとする。処理手順の理解を容易とするため、本実施の形態では、文書管理システム１１ｓに管理されている次のような文書情報をコンバート（移管）対象として説明する。
【００２６】
図６は、処理手順の説明においてコンバート対象とされる文書情報の構成を示す図である。同図に示される文書情報Ｓでは、Ｒｏｏｔキャビネットの下に一つのフォルダ（フォルダ１）が存在する。フォルダ１の下には二つのフォルダ（フォルダ２及びフォルダ３）が存在する。フォルダ２の下には一つのフォルダ（フォルダ４）と一つの文書（文書１）が存在する。フォルダ３の下には二つの文書（文書２及び３）が存在する。なお各名前の末尾に付加されている番号は、当該フォルダ又は文書のシリアル番号を示す。
【００２７】
図７は、第一の実施における形態のコンバータによる処理概要を説明するためのフローチャートである。ここでは、文書情報Ｓにおける一つのキャビネット以下を全てコンバートする例について説明する。なお、処理対象情報１２５、元親情報１２６、先親情報１２７、及び処理待ちスタック１２７の初期値は空である。
【００２８】
まず、文書管理システム１１ｓにおけるＲｏｏｔキャビネットを文書管理システム１１ｄに作成する（Ｓ１０１）。続いて、Ｒｏｏｔキャビネットに属する全てのノードについてのループ処理Ｌ１が実行される。まず、処理対象とするノードを決定し、当該ノードに関する情報（書誌情報等）を処理対象情報１２５に取得する（Ｓ１０２）。処理対象情報１２５が取得できた場合（Ｓ１０３でＹＥＳ）、処理対象情報１２５に係るノードを文書管理システム１１ｄに作成する（Ｓ１０４）。処理対象情報１２５に係るノードがフォルダである場合（Ｓ１０５でＹＥＳ）、処理対象情報１２５の内容を元親情報１２６に格納し（Ｓ１０６）、作成された文書管理システム１１ｄ側のノードの情報（書誌情報等）を先親情報１２７に格納する（Ｓ１０７）。一方、処理対象情報１２５に係るノードが文書の場合（Ｓ１０５でＮＯ）、ステップＳ１０６及びＳ１０７は実行されず、元親情報１２６及び先親情報１２７の値は更新されない。
【００２９】
キャビネットに属する全てのノードについて処理が完了したとき、又は途中で中断指示が入力されたときはループＬ１を抜ける。中断指示が入力された場合は（Ｓ１０８でＹＥＳ）、中断ファイルを文書管理装置１１ｄの補助記憶装置１０２に作成し、中断ファイル内にルートのキャビネットに関する情報を記録する（Ｓ１０９）。これにより、ユーザは、いずれのキャビネットのコンバートに失敗したのかを確認することができる。
【００３０】
続いて、ステップＳ１０１におけるキャビネットのコンバート処理について説明する。図８は、第一の実施の形態におけるキャビネットのコンバート処理を説明するためのフローチャートである。
【００３１】
ステップＳ１５１において、文書情報取得部１２１は、文書管理システム１１ｓよりキャビネットの情報を取得し（Ｓ１５１）、取得された情報を元親情報１２６に格納する（Ｓ１５２）。この時点で、初めて元親情報１２６に値が格納される。続いて、文書情報変換部１２２は、元親情報１２６に格納されている情報をマッピングテーブル１２４に基づいて変換する（Ｓ１５３）。続いて、文書情報登録部１２３は、変換後の情報を示すノード（ルートのフォルダノード）が、文書管理システム１１ｄに存在するか否かを確認する（Ｓ１５４）。この確認は、当該ノードに関する検索を文書管理システム１１ｄに対して実行することにより行えばよい。
【００３２】
変換後のノードが存在しない場合（Ｓ１５４でＹＥＳ）、文書情報登録部１２３は、当該ノードを文書管理システム１１ｄに登録し（Ｓ１５５）、作成されたノードに関する情報を先親情報１２７に格納する（Ｓ１５６）。
【００３３】
一方、変換後のノードが存在する場合（Ｓ１５４でＮＯ）、文書情報登録部１２３は、当該ノードに関する情報を文書管理システム１１ｄより取得し（Ｓ１５７）、取得された情報を先親情報１２７に格納する（Ｓ１５８）。
【００３４】
図８の処理すなわち、図７におけるステップＳ１０１が終了した時点において、コンバータ１２の保持情報の値は次のようになる。図９及び図１０は、コンバート処理に応じた移管先のノード及び保持情報の値の遷移を示す図である。
【００３５】
同図では、ノードの作成完了時点（Ｓ１０１、Ｓ１０４又はＳ１０７）、処理対象情報取得処理終了時点（Ｓ１０２）ごとに、移管先の文書管理システム１１ｄに作成されているノードを示す図形と、保持情報の値とが示されている。キャビネットが作成された時点については、図中（１）に示されている。すなわち、Ｒｏｏｔキャビネットに対応するノードが生成され、元親情報１２６、先親情報１２７のいずれについてもＲｏｏｔノードに関する情報が格納されている。元親情報１２６は、図８のステップＳ１５２において格納されたものである。先親情報１２７は、図８のステップＳ１５６又はＳ１５８において格納されたものである。なお、この時点では、処理対象情報１２５は、まだ空である。
【００３６】
続いて、図７のステップＳ１０２において文書情報取得部１２１によって実行される処理対象情報の取得処理について説明する。図１１は、第一の実施の形態における文書情報取得部による処理対象情報の取得処理を説明するためのフローチャートである。当該処理は、ループＬ２の条件（処理対象情報１２５が取得されるか、又は処理対象情報１２５が空となるか）が満たされるまで移管元である文書情報Ｓのノードが探索される。なお、ここでは、ノードの探索のアルゴリズムとして深さ優先探索を採用した例を示すが、他のアルゴリズムを採用してもよい。
【００３７】
ステップＳ２０１において、処理対象情報１２５に値が格納されているか否かを判断する。初期値は空であるため、最初はステップＳ２０２に進む。ステップＳ２０２において元親情報１２６に係るノードの子フォルダの中で、シリアル番号が最も小さいものの情報を取得する。現在、元親情報１２６に係るノードは、「Ｒｏｏｔキャビネット」である（図９（１）参照）。したがって、「フォルダ１」の情報が取得される（図６参照）。子フォルダの情報が取得できた場合（Ｓ２０５でＹＥＳ）、取得された情報（ここでは「フォルダ１」の情報）を処理対象情報１２５に格納する（Ｓ２０９）。続いて、処理対象情報１２５に現在の元親情報１２６及び先親情報１２７を追加し（Ｓ２１０）、ループＬ２を抜ける。したがって、処理対象情報１２５には、当該ノードの情報と共に、親のノードについて移管元及び移管先のそれぞれの情報が格納される。なお、この時点の保持情報等は、図９の（２）に示される通りである。
【００３８】
この後、フォルダ１を処理対象として図７のＳ１０４〜Ｓ１０７が実行されることにより、保持情報等は図９（３）に示されるように変化する。すなわち、Ｓ１０４において、Ｒｏｏｔフォルダノードの下にフォルダ１ノードが生成され、元親情報１２６及び先親情報１２７に、処理対象情報１２５（フォルダ１）の値が格納される（Ｓ１０６、Ｓ１０７）。なお、ステップＳ１０６において、処理対象情報１２５を元親情報１２６に格納するのは、深さ方向に探索を進めるためである。
【００３９】
図９（３）の状態で、図１１の処理が実行される場合（以下、「ケースＡ」という。）について説明する。この場合、処理対象情報１２５は空ではないため（Ｓ２０１でＹＥＳ）、ステップＳ２０３に進む。ステップＳ２０３において処理対象のノード（処理対象情報１２５に係るノード）の種別を判定する。当該ノードがフォルダの場合（ここでは、当該ノードは「フォルダ１」であるためこの場合に相当する）、ステップＳ２０４に進む。ステップＳ２０４において、元親情報１２６に係るノードの子フォルダの中で、処理対象情報１２５に係るノードよりもシリアル番号の大きいノードの情報を取得する。現在、元親情報１２６に係るノードは、「フォルダ１」である（図９（３）参照）。したがって、「フォルダ２」の情報が取得される（図６参照）。すなわち、処理対象情報１２５と元親情報１２６とが同じノードを指す場合、ステップＳ２０４では、処理対象情報１２５に係るノードの子フォルダの情報が取得され、深さ方向に探索が行われる。
【００４０】
以降、上述したステップ２０５、Ｓ２０９、及びＳ２１０を経て、「フォルダ２」の情報、元親情報１２６、及び先親情報１２７が処理対象情報１２５に格納され、ループＬ２を抜ける。この時点の保持情報等は、図９の（４）に示される通りである。この後、フォルダ２を処理対象として図７のＳ１０４〜Ｓ１０７が実行されることにより、保持情報等は図９（５）に示されるように変化する。すなわち、Ｓ１０４において、フォルダ１ノードの下にフォルダ２ノードが生成されている。
【００４１】
この状態で、図１１の処理が実行される場合、ケースＡと同じパス（フローチャート上におけるパス）によって処理が実行される。その結果、フォルダ２の子フォルダであるフォルダ４が処理対象とされ、ループＬ２を抜けた時点の保持情報等は図９（６）に示される通りになる。また、フォルダ４を処理対象として図７のＳ１０４〜Ｓ１０７が実行されることにより、保持情報等は図９（７）に示されるように変化する。すなわち、Ｓ１０４において、フォルダ２ノードの下にフォルダ４ノードが生成されている。
【００４２】
続いて、図９（７）の状態で、図１１の処理が実行される場合（以下、「ケースＢ」という。）について説明する。この場合、ステップＳ２０１→Ｓ２０３→Ｓ２０４→Ｓ２０５まではケースＡと同じパスによって処理が実行される。但し、元親情報１２６（ここでは、処理対象情報１２５と同じ）に係るノードであるフォルダ４に子フォルダはないため（Ｓ２０５でＮＯ）、ステップＳ２０６に進む。ステップＳ２０６において、元親情報１２６（処理対象情報１２５）に係るノードの子文書の中でシリアル番号が最も小さい子文書の情報を取得する。すなわち、深さ方向のフォルダの探索に失敗したため、深さ方向の文書を探索するのである。現在、元親情報１２６に係るノードはフォルダ４であり、子文書も存在しない。したがって、ステップＳ２１１に進み、元親情報１２６に係るノードがＲｏｏｔ（キャビネット）であるか否かを判定する（Ｓ２１１）。ここでは、Ｒｏｏｔではないため、ステップＳ２１２に進み、元親情報１２６によって処理対象情報１２５を更新する（Ｓ２１２）。続いて、移管元の親ノード（フォルダ２）の情報を処理対象情報１２５内より取得し（Ｓ２１３）。取得された情報を元親情報１２６に格納する（Ｓ２１４）。続いて、処理対象情報１２５から移管先の親ノードの情報を取得し（Ｓ２１５）、取得された情報を先親情報１２７に格納する（Ｓ２１６）。この時点における保持情報等は、図９の（８）に示される通りである。すなわち、ステップＳ２１２〜Ｓ２１７は、深さ方向において末端（フォルダ４）に到達してしまったため、探索位置を親ノードに戻すための処理である。続いて、図１１の処理を再帰的に実行する（Ｓ２１７）。
【００４３】
なお、ステップＳ２１３及びステップＳ２１５において、処理対象情報１２５より移管元又は移管先の親ノードの情報を取得できるのは、処理対象情報１２５には常にこれらの情報が格納されているからである（ステップＳ２１０参照）。また、当該ステップにおける処理対象情報１２５の内容は、ステップＳ２１２において元親情報１２６によって更新されたものであるが、元親情報１２６には、処理対象情報１２５の内容がコピーされているため（図７のステップＳ１０６参照）、この事情（処理対象情報１２５に移管元又は移管先の親ノードの情報が格納されているということ）に変わりはない。
【００４４】
続いて、図９（８）の状態において図１１の処理が再帰的に呼び出された場合（以下「ケースＣ」という。）について説明する。この場合、ステップＳ２０３に進み、処理対象情報１２５における処理対象のノードの種別を判定する。ここではフォルダであるため、ステップＳ２０４に進み、処理対象のノードの弟フォルダの情報の取得を試みる。ここで、フォルダ４には、弟フォルダは無いため（Ｓ２０５でＮＯ）、ステップＳ２０６に進み、元親情報１２６に係るノード（フォルダ２）の子文書の中でシリアル番号が最も小さい子文書の情報を取得する（Ｓ２０６）。したがって、ここでは、文書１の情報が取得される。子文書の情報が取得された場合（Ｓ２０８でＹＥＳ）、取得された子文書の情報（ここでは「文書１」の情報）を処理対象情報１２５に格納する（Ｓ２０９）。続いて、ステップＳ２１０を実行し、ループＬ２を抜ける。したがって、この時点の保持情報等は、図９の（９）に示される通りになる。また、文書１を処理対象として図７のＳ１０４が実行されることにより、移管先のノード構成は図９（１０）に示されるように変化する。すなわち、Ｓ１０４において、フォルダ２ノードの下に文書１ノードが生成されている。
【００４５】
続いて、この状態で図１１の処理が実行される場合（以下、「ケースＤ」という。）について説明する。この場合、ステップＳ２０１及びＳ２０３を経てステップＳ２０７に進む。ステップＳ２０７において、処理対象情報１２５に係る文書よりシリアル番号の大きい文書（すなわち、処理対象の文書の弟文書）の情報の取得を試みる。ここでは、文書１の弟文書は無いため（Ｓ２０８でＮｏ）、ステップＳ２１２〜Ｓ２１６において探索位置が親に戻される。したがって、この時点における保持情報等は、図９の（１１）に示される通りになる。この状態で、図１１の処理が再帰的に呼び出される（Ｓ２１７）。
【００４６】
続いて、図９（１１）の状態において図１１の処理が再帰的に呼び出された場合について説明する。この場合、ステップＳ２０１及びＳ２０３を経てステップＳ２０４に進み、処理対象のノード（フォルダ２）の弟フォルダ（フォルダ３）の情報を取得する。すなわち、処理対象情報１２５と元親情報１２６とが異なるノードを指す場合、ステップＳ２０４では、処理対象情報１２５に係るノードの弟フォルダの情報が取得され、幅方向に探索が行われる。
【００４７】
以降、ステップ２０５、Ｓ２０９、及びＳ２１０を経て、「フォルダ３」の情報、元親情報１２６、及び先親情報１２７が処理対象情報１２５に格納され、ループＬ２を抜ける。この時点の保持情報等は、図９の（１２）に示される通りである。この後、フォルダ３を処理対象として図７のＳ１０４〜Ｓ１０７が実行されることにより、保持情報等は図１０（１３）に示されるように変化する。すなわち、Ｓ１０４において、フォルダ１ノードの下にフォルダ３ノードが生成されている。
【００４８】
続いて、図１０（１３）の状態において図１１の実行される場合について説明する。この場合、ケースＣ（図９（８）の状態）と同じパス（Ｓ２０１→Ｓ２０３→Ｓ２０４→Ｓ２０５→Ｓ２０６→Ｓ２０８→Ｓ２０９→Ｓ２１０）を経て、文書２の情報等が処理対象情報１２５に格納され、ループＬ２を抜ける。したがって、この時点の保持情報等は図１０の（１４）に示される通りになる。また、文書２を処理対象として図７のＳ１０４が実行されることにより、移管先のノード構成は図１０（１５）に示されるように変化する。すなわち、Ｓ１０４において、フォルダ３ノードの下に文書２ノードが生成されている。
【００４９】
続いて、図１０（１５）の状態において図１１の処理が実行される場合について説明する。この場合、ステップＳ２０１及びＳ２０３を経てＳ２０７に進む。ステップＳ２０７において、処理対象の文書（文書２）の弟文書（文書３）の情報を取得する。続いて、ステップＳ２０９及びＳ２１０を実行し、ループＬ２を抜ける。したがって、この時点における保持情報等は、図１０（１６）に示される通りになる。また、また、文書３を処理対象として図７のＳ１０４が実行されることにより、移管先のノード構成は図１０（１７）に示されるように変化する。すなわち、Ｓ１０４において、フォルダ３ノードの下に文書３ノードが生成されている。
【００５０】
続いて、図１０（１７）の状態において図１１の処理が実行される場合について説明する。この場合、ケースＤ（図９（１０）の状態）と同様にステップＳ２１２〜Ｓ２１６が実行され、探索位置が親に戻される。したがって、保持情報等は図１０（１８）に示される通りになり、再帰的に図１１の処理が呼び出される（Ｓ２１７）。再帰的な呼び出しにおいてもＳ２１２〜Ｓ２１６が実行され、探索位置が親に戻される。したがって、保持情報等は図１０（１９）に示される通りになり、再帰的に図１１の処理が呼び出される（Ｓ２１７）。
【００５１】
続いて、図１０（１９）の状態で図１１の処理が呼び出された場合について説明する。この場合、Ｓ２０１、Ｓ２０３、Ｓ２０７、及びＳ２０８を経てステップＳ２１１に進む。ここで、元親情報１２６は、Ｒｏｏｔを指しているため（Ｓ２１１でＮＯ）、処理対象情報を空にし（Ｓ２１８）、ループＬ２を抜ける。したがって、保持情報等は図１０（２０）に示される通りになる。この場合、図７の処理では、ステップＳ１０３でＮＯとなり、更に、全てのノードが完了したためループＬ１を抜けることになる。
【００５２】
次に、図７のステップＳ１０４における処理対象情報の登録処理について説明する。図１２は、第一の実施の形態における処理対象情報の登録処理を説明するためのフローチャートである。
【００５３】
ステップＳ２５１において、文書情報変換部１２２は、処理対象情報１２５に格納されている情報をマッピングテーブル１２４に基づいて変換する。続いて、文書情報登録部１２３は、変換後の情報を示すノードが、文書管理システム１１ｄに存在するか否かを確認する（Ｓ２５３）。変換後のノードが存在した場合（Ｓ２５２でＮＯ）、文書情報登録部１２３は、当該ノードに関する情報を文書管理システム１１ｄより取得する（Ｓ２５３）。この場合、ここで取得された情報が図７のステップＳ１０７において先親情報１２７に格納される。
【００５４】
一方、変換後のノードが存在しない場合（Ｓ２５２でＹＥＳ）、文書情報登録部１２３は、変換後の情報に基づいて当該ノードを文書管理システム１１ｄに作成する（Ｓ２５４）。作成に成功した場合（Ｓ２５５でＹＥＳ）、当該処理は終了する。この場合、ステップＳ２５１において生成された変換後の情報が、図７のステップＳ１０７において先親情報１２７に格納される。
【００５５】
変換後のノードの作成に失敗した場合（Ｓ２５５でＮＯ）、文書情報登録部１２３は、処理対象情報１２５に係るノードの親ノードを移管先の文書管理システム１１ｄに再作成する処理を実行する（Ｓ２５６）。親ノードが再生された後、改めて現在の処理対象情報１２５について図１２の処理が再帰的に呼び出される。すなわち、ここでは、ノードの作成の失敗の原因を親ノードが存在しないことに限定することとして説明する。本実施の形態では、移管先の文書管理システム１１ｄは、コンバート中であっても編集可能とされている。また、本実施の形態では、親から順にコンバートを行う。したがって、既にコンバートされた親ノードがユーザの編集によって削除又は移動等されてしまう可能性がある。斯かる事態の発生に対してステップＳ２５６が実行される。
【００５６】
続いて、図１２のステップＳ２５６における親ノードの再作成処理について説明する。ここでは、図１０（１４）まで（フォルダ３の作成まで）が完了した状態において、文書管理システム１１ｄ上でフォルダ３が削除されたケースを例として説明する。
【００５７】
図１３は、親ノードの再作成処理の際の移管先のノード及び保持情報の遷移を説明するための図である。同図において（１４）は、図１０（１４）に対応する。ここで、フォルダ３が削除されることにより、移管先のノード構成は（１５）に示されるようになる。但し、フォルダ３の削除は、ユーザによる入力に基づいて文書管理システム１１ｄによって実行されるため、コンバータ１２の保持情報は影響を受けない。したがって、（１５）文書情報登録部１２３は、フォルダ３の子ノード（ここでは、文書２ノード）を作成しようとするが、フォルダ３が無いため失敗してしまう（図１２のＳ２５５でＮＯ）。そこで、親ノード（フォルダ３）の再作成処理（Ｓ２５６）が実行される。
【００５８】
図１４は、第一の実施の形態における文書情報登録部による親ノードの再作成処理を説明するためのフローチャートである。当該フローチャートは、図１３を参照しつつ説明する。したがって、当該フローチャートの開始時の状態は、図１３（１５）に示される通りである。
【００５９】
まず、ループＬ３が実行される。ステップＳ３０１において、処理対象情報１２５を処理待ちスタック１２８（図３参照）にコピー（蓄積）する。続いて、元親情報１２６を処理対象情報１２５にコピーする（Ｓ３０２）。この時点において、保持情報の状態は、図１３（１６）に示される通りになる。続いて、処理対象情報１２５に係るノード（フォルダ３）の親ノード（フォルダ１）の情報を移管元の文書管理システム１１ｓより検索する（Ｓ３０３）。続いて、検索された情報を元親情報１２６に格納する（Ｓ３０４）。続いて、元親情報１２６に対応するノードを移管先の文書管理システム１１ｄより検索する（Ｓ３０５）。検索された場合、検索された情報を先親情報１２７に格納し（Ｓ３０６）、ループＬ３を抜ける。なお、検索されなかった場合は、ループＬ３は抜けずに、更に親のノードを探索する。すなわち、ループＬ３では、当初処理対象だったノードの祖先のノードの中で、削除されずに残っているものまで遡る。この際、処理待ちスタック１２８には、そのループ時における処理対象情報１２５が蓄積される。ここでは、ループＬ３を抜けた時点における保持情報は、図１３（１７）に示される通りになる。これより明らかなように、処理対象情報１２５には、削除されてしまったノードの情報が格納されている。
【００６０】
続いて、処理待ちスタック１２８の内容が空になるまでループＬ４が実行される。ステップＳ３０７において、処理対象情報１２５に係るノードに対応するノード（フォルダ３ノード）を文書管理システム１１ｄに再作成する。厳密には、処理対象情報１２５が文書情報変換部１２２によって変換された情報に基づいてノードが生成される。再作成により、移管先のノード構成は、図１３（１８）に示される通りになる。
【００６１】
続いて、処理対象情報１２５を元親情報１２６に格納する（Ｓ３０８）。続いて、文書情報変換部１２２に再作成されたノードに関する情報を先親情報１２７に格納する（Ｓ３０９）。続いて、処理待ちスタック１２８から蓄積されている情報をポップし（蓄積順とは逆順に取り出し）（Ｓ３１０）、取り出された情報を処理対象情報１２５に格納する（Ｓ３１１）。処理待ちスタック１２８が空になるまでループＬ４が繰り返されることにより、当初処理対象だったノードの全ての祖先ノードが再生される。なお、再生されたフォルダについては、そのことをユーザが識別可能なように名前に所定の符号を付加するようにしてもよい。
【００６２】
図１３（１８）は、フォルダ３が削除される前の状態（図３（１４））と同様である。したがって、この状態において図１２のステップＳ２５７が実行されることにより、当初処理対象だったノードが適切に作成される。
【００６３】
ところで、図１２のステップＳ２５２では、処理対象情報１２５に対応するノードが既に作成されている場合を予定している。斯かる事態は、例えば、コンバート中にユーザによって移管先に当該ノードが作成された場合、又はコンバート中に処理が中断され、その後再開された場合等おいて発生する。以下、それぞれの場合について説明する。
【００６４】
まず、コンバート中にユーザの操作に応じて処理対象のノードが既に作成されている場合について説明する。図１５は、処理対象のノードが既に作成されている際の移管先のノード及び保持情報の遷移を説明するための図である。ここでは、同図における（１２）の状態（図９の（１２）に相当）において、文書管理システム１１ｄ上でフォルダ３ノードが作成されたケースを例として説明する。フォルダ３ノードがユーザの操作に基づいてフォルダ１の下に作成されることにより、移管先のノード構成は（１３）に示される通りになる。図１２のステップＳ２５３、図７のステップＳ１０６及びＳ１０７が実行されることにより、保持情報は、（１４）に示される通りになる。この状態は、図９における（１３）の状態と同じである。したがって、以降は既に説明した処理手順によってコンバートが可能となる。
【００６５】
次に、ユーザによる指示入力や障害等によりコンバートが途中で中断してしまった後、再開する場合について説明する。ここでは、中断後に、移管元の文書管理システム１１ｓにおいて、コンバート対象だった文書情報の構成が変更された場合も考慮する。当該変更によりコンバート再開時の移管元の文書情報は次の
図１６は、コンバート再開時の移管元の文書情報の構成を示す図である。同図に示されるように、図１６では、フォルダ１（図６参照）がフォルダ５に置き換えられている。
【００６６】
また、中断時における移管先のノード構成は、図９（９）に示される通りであるとする。すなわち、フォルダ１、２、及び４までの作成が完了した状態である。
【００６７】
図１７は、コンバートが再開された際の移管先のノード及び保持情報の遷移を説明するための図である。
【００６８】
コンバートが再開されると、図７の処理が最初から実行される。したがって、Ｒｏｏｔのキャビネットの作成処理（Ｓ１０１、図８）が実行される。それにより、元親情報１２６及び先親情報１２７には、（１）に示される情報が格納される（図８のステップＳ１５２、Ｓ１５８）。
【００６９】
続いて、ステップＳ１０２（すなわち図１１）が実行されることにより、Ｒｏｏｔ直下のフォルダ５の情報が処理対象情報１２５に格納される。したがって、ステップＳ１０２完了時における保持情報等は、（２）に示される通りになる。
【００７０】
続いて、フォルダ５を処理対象として図７のＳ１０４〜Ｓ１０７が実行されることにより、保持情報等は（３）に示されるように変化する。すなわち、Ｓ１０４において、Ｒｏｏｔフォルダノードの下にフォルダ５ノードが生成され、元親情報１２６及び先親情報１２７に、処理対象情報１２５（フォルダ５）の値が格納される。
【００７１】
（３）の状態は、図９の（３）の状態のフォルダ１をフォルダ５に置き換えたものに相当する。したがって、その後、図９の（３）の状態以降に実行される処理と同様の処理によって、移管先のノード構成は、図１７（４）に示されるようになる。すなわち、中断前に作成されたノードとは別に、新たなノードが作成される。
【００７２】
次に、第二の実施の形態について説明する。図１８は、第二の実施の形態における文書情報コンバートシステムの構成例を示す図である。図１８中図１と同一部分には同一符号を付し、その説明は省略する。
【００７３】
図１８において、移管元である文書管理装置１０ｓは、エクスポータ１３を備える。また、移管先である文書管理装置１０ｄは、インポータ１４を備える。エクスポータ１３は、文書管理システム１１ｓの文書情報をコンバートファイル１５及びコンバート処理順ファイル１６に出力するソフトウェアである。コンバートファイル１５はノード単位に作成され、そのノードに関して文書形式Ｄに変換後の書誌情報等が格納される。コンバート処理順ファイル１６は、コンバートファイル１５の処理順序が記録されたファイルである。具体的には、コンバートファイル１３のファイル名が処理順に記載されている。
【００７４】
インポータ１４は、コンバートファイル１５及びコンバート処理順ファイル１６に基づいて、文書管理システム１１ｄにエクスポートされた文書情報（ノード構成）を構築するソフトウェアである。
【００７５】
すなわち、第二の実施の形態では、コンバートファイル１５等を媒介としてコンバートが実行されるため、文書管理装置１０ｓ及び１０ｄは、必ずしもネットワークを介して接続されていなくてもよい。但し、コンバートファイル１５等は、ネットワークを介して転送されてもよい。
【００７６】
図１９は、第二の実施の形態におけるエクスポータ及びインポータの構成例を示す図である。同図では、エクスポータ１３及びインポータ１４のそれぞれについて、その機能と、当該機能を実現するための処理を実行する上でそれぞれによって保持される情報（保持情報）とが示されている。
【００７７】
エクスポータ１３の機能は、文書情報取得部１３１、文書情報変換部１３２、コンバートファイル作成部１３３、及びマッピングテーブル１３５等によって実現される。このうち、文書情報取得部１３１、文書情報変換部１３２、及びマッピングテーブル１３５の機能は、図３における文書情報取得部１２１、文書情報変換部１２２、及びマッピングテーブル１２５と同様である。コンバートファイル作成部１３３は、文書形式Ｄに変換された文書情報をコンバートファイル１５及びコンバート処理順ファイル１６に出力する。
【００７８】
エクスポータ１３の保持情報は、処理対象情報１３、元親情報１３６、及び前回のエクスポート終了日時１３７等より構成される。処理対象情報１３及び元親情報１３６の役割は、図３における処理対象情報１２５、元親情報１２６と同様である。前回のエクスポート終了日時１３７には、前回のエクスポート処理の終了日時が保持される。なお、前回のエクスポート終了日時１３７は、不揮発性の記録媒体（例えば、補助記憶装置１０２）に記録される。
【００７９】
一方、インポータ１４の機能は、コンバート処理順リスト作成部１４１及びコンバートファイルインポート部１４２等によって実現される。コンバート処理順リスト作成部１４１は、コンバート処理順ファイル１６を解析し、コンバートファイル１５の処理順を示す情報（コンバート処理順リスト）を作成する。コンバートファイルインポート部１４２は、コンバートファイル１５に基づいて文書管理システム１１ｄにノードを作成する。
【００８０】
インポータ１４の保持情報は、コンバート処理順リスト１４３、処理対象情報１４４、先親情報１４５、及び処理待ちスタック１４６等より構成され、物理的にはメモリ装置１０３に格納される。コンバート処理順リスト１４３には、コンバート処理順リスト作成部１４１によって作成されるコンバート処理順リストを格納するための変数である。処理対象情報１４４、先親情報１４５、及び処理待ちスタック１４６の役割は、図３における処理対象情報１２５、先親情報１２７、処理待ちスタック１２８と同様である。
【００８１】
以下、第二の実施の形態における処理手順について説明する。図２０は、第二の実施の形態におけるエクスポータによる処理概要を説明するためのフローチャートである。
【００８２】
まず、文書管理システム１１ｓにおけるルートのキャビネットのコンバートファイル１５を作成する（Ｓ５０１）。続いて、キャビネットに属する全てのノードについてのループ処理Ｌ１１が実行される。まず、処理対象とするノードを決定し、当該ノードに関する情報を処理対象情報１３５に取得する（Ｓ５０２）。処理対象情報１３５が取得できた場合（Ｓ５０３でＹＥＳ）、処理対象情報１３５に係るノードのコンバートファイル１５を作成する（Ｓ５０４）。処理対象情報１３５に係るノードがフォルダである場合（Ｓ５０５でＹＥＳ）、処理対象情報１３５の内容を元親情報１３６に格納する（Ｓ５０６）。
【００８３】
キャビネットに属する全てのノードについて処理が完了したとき、又は途中で中断指示が入力されたときはループＬ１１を抜ける。中断指示が入力された場合は（Ｓ５０７でＹＥＳ）、中断ファイルを文書管理装置１１ｄの補助記憶装置１０２に作成し、中断ファイル内にルートのキャビネットに関する情報を記録する（Ｓ５０８）。一方、中断されなかった場合は（Ｓ５０７でＮＯ）、現在の日時を前回のエクスポート終了日時１３７に記録する。
【００８４】
続いて、ステップＳ５０１におけるキャビネットのコンバートファイルの作成処理について説明する。図２１は、第二の実施の形態におけるキャビネットのコンバートファイルの作成処理を説明するためのフローチャートである。
【００８５】
文書情報取得部１３１は、文書管理システム１１ｓよりキャビネットの情報を取得し（Ｓ５５１）、取得された情報を元親情報１２６に格納する（Ｓ５５２）。続いて、文書情報変換部１３２は、処理対象情報１２５に格納されている情報をマッピングテーブル１３４に基づいて変換する（Ｓ５５３）。続いて、コンバートファイル作成部１３３は、コンバートファイル１５を作成し、作成されたコンバートファイル１５に変換後の情報を出力する（Ｓ５５４）。なお、コンバートファイル１５のファイル名は、例えば、ノードの名称に基づいて定めればよい。続いて、コンバートファイル作成部１３３は、コンバート処理順ファイル１６に、当該コンバートファイル１５のファイル名を書き込む（Ｓ５５５）。
【００８６】
続いて、図２０のステップＳ５０２において文書情報取得部１３１によって実行される処理対象情報の取得処理について説明する。図２２は、第二の実施の形態における文書情報取得部による処理対象情報の取得処理を説明するためのフローチャートである。図２２の処理手順は、図１１の処理手順とほぼ同様である。したがって、図２２中、図１１と対応するステップには同一ステップ番号を付している。
【００８７】
但し、図２２では、処理主体が文書情報取得部１３１である点、及び保持情報として処理対象情報１３５及び元親情報１３６が利用される点が異なる。また、図２２では、ステップＳ２１５及びＳ２１６は実行されない。エクスポータ１３は、先親情報１２７に対応する情報を扱わないからである。同様に、ステップＳ２１０では、元親情報１３６のみが処理対象情報１３５に追加される。
【００８８】
なお、前回のエクスポート終了日時１３７に値が記録されている場合は、処理対象とされるノードは、前回の終了日時より後に作成又は更新されたものに限定される。
【００８９】
続いて、図２０のステップＳ５０４におけるコンバートファイルの作成処理について説明する。図２３は、第二の実施の形態におけるコンバートファイルの作成処理を説明するためのフローチャートである。
【００９０】
ステップＳ６０１において、文書情報変換部１３２は、処理対象情報１３５に格納されている情報をマッピングテーブル１３４に基づいて変換する。なお、処理対象情報１３５には、処理対象のノードのみならず、その親ノードの情報も含まれている（図２２のＳ２１０参照）。したがって、ここでは、親ノードの情報も変換される。続いて、コンバートファイル作成部１３３は、新たなコンバートファイル１５を作成し、作成されたコンバートファイル１５に変換後の情報を出力する（Ｓ６０２）。したがって、処理対象のノードのみならず、その親ノードの情報もコンバートファイル１５に出力される。続いて、コンバートファイル作成部１３３は、コンバート処理順ファイル１６の最後尾に当該コンバートファイル１５のファイル名を追加する（Ｓ６０３）。
【００９１】
次に、インポータ１４による処理手順について説明する。図２４は、第二の実施の形態におけるインポータによる処理手順を説明するためのフローチャートである。同図の処理は、エクスポータ１３によって作成されたコンバートファイル１５及びコンバート処理順ファイル１６が、記録媒体又はネットワークを介して文書管理装置１１ｄの補助記憶装置１０２に保存された後に実行される。なお、第二の実施の形態においては、図２０の処理が実行されている間はもちろん、図２４の処理が実行されている間も、文書管理システム１１ｄにおける文書情報の編集は可能とされる。
【００９２】
まず、コンバート処理順リスト作成部１４１は、コンバート処理順ファイル１６を読み込み（Ｓ７０１）。コンバート処理順ファイル１６に記載されているファイル名の記載順に基づいて、ファイル名のリストをコンバート処理順リスト１４３に格納する（Ｓ７０２）。
【００９３】
続いて、コンバートファイルインポート部１４２は、コンバート処理順リスト１４３に記録されている全てのファイル名についてループＬ１２を実行する。ステップＳ７０３において、コンバートファイルインポート部１４２は、コンバート処理順リスト１４３の順番に従って、一つのコンバートファイル１５を読み込み、当該コンバートファイル１５に係るノードの情報を処理対象情報１４４に格納し、その親ノードの情報を先親情報１４５に格納する。続いて、先親情報１４５に係るノード（親ノード）を文書管理システム１１ｄより検索する（Ｓ７０４）。当該親ノードが検索された場合（Ｓ７０５でＹＥＳ）、処理対象情報１４４に係るノードを当該親ノードの下に作成する（Ｓ７０７）。作成に成功した場合（Ｓ７０８でＹＥＳ）、コンバート処理順リスト１４３において次の順番のコンバートファイル１５が処理対象とされる。
【００９４】
一方、ノードの作成に失敗した場合（Ｓ７０８でＮＯ）、コンバートファイルインポート部１４２は、処理対象情報１４４に基づいて当該ノードの種別（フォルダノード又は文書ノード）を判定する（Ｓ７０９）。当該ノードの種別が文書ノードである場合、コンバートファイルインポート部１４２は、文書管理システム１１ｄにおける登録失敗文書フォルダの有無を判定する（Ｓ７１０）。ここで、登録失敗文書フォルダとは、登録に失敗した文書を保管しておくためのフォルダをいい、文書管理システム１１ｄ上の所定の場所（例えば、ルートフォルダノードの直下）に作成される。
【００９５】
登録失敗文書フォルダが無い場合（Ｓ７１０でＹＥＳ）、コンバートファイルインポート部１４２は、登録失敗文書フォルダを文書管理システム１１ｄ上の所定の場所に作成する（Ｓ７１１）。続いて、コンバートファイルインポート部１４２は、作成（登録）に失敗した文書ノードを処理対象情報１４５に基づいて登録失敗文書フォルダの下に生成する（Ｓ７１２）。すなわち、文書ノードについては、重要な資産である文書の実データをも伴っている。したがって、当該文書ノードの失敗により、文書の実体が失われてしまうのは好ましくない。そこで、登録に失敗した文書ノードについては、登録失敗文書フォルダの下に登録し、文書実データを当該文書ノードに登録しておくのである。
【００９６】
一方、ステップＳ７０５において、親ノードの検索に失敗した場合（Ｓ７０５）、処理対象がＲｏｏｔノードの場合を除きステップＳ７０６に進み、コンバートファイルインポート部１４２は、親ノードの再作成処理を実行する（Ｓ７０６）。その後ステップＳ７０７以降が実行される。
【００９７】
なお、親ノードが検索できない場合とは、第一の実施の形態においても説明したように、例えば、インポート処理中に、ユーザによって親ノードが削除又は移動されてしまった場合等が相当する。
【００９８】
続いて、ステップＳ７０６における親ノードの再作成処理について説明する。図２５は、第二の実施の形態におけるコンバートファイルインポート部による親ノードの再作成処理を説明するためのフローチャートである。図２５の処理手順は、図１４の処理手順とほぼ同様である。したがって、図２５中、図１４と対応するステップには同一ステップ番号を付している。
【００９９】
但し、図２５では、処理主体がコンバートファイルインポート部１４２である点、及び保持情報として処理対象情報１４４及、先親情報１４５、及び処理待ちスタック１４６が利用される点が異なる。また、図２５では、ステップＳ３０３、Ｓ３０４、及びＳ３０８は実行されない。インポータ１１４は、元親情報１２６に対応する情報を扱わないからである。更に、ステップＳ３０５ａでは、処理対象情報１４４に係るノードの親ノードの情報が文書管理システム１１ｄより検索される。他については、図１４と同様でよい。
【０１００】
上述したように、本実施の形態における文書情報コンバートシステムによれば、文書情報のノードを順番に移管する過程において、移管対象とされたノードの親ノード又は祖先ノードが存在しない場合は、当該親ノード又は祖先ノードを再生成する。したがって、移管先において、移管中に任意のノードが削除又は移動された場合であっても、適切に文書情報の移管を遂行することができる。また、移管対象とされたノードが移管先に既に存在する場合は、当該ノードに関する移管はスキップして次のノードを移管対象とする。したがって、移管先において、移管中に任意のノードが作成された場合であっても、適切に文書情報の移管を遂行することができる。よって、移管中であっても、移管先の文書情報の編集をユーザに許可することができる。
【０１０１】
なお、本発明は、文書情報のコンバート（文書形式の変換）を伴わない移管（例えば、各ノードを順番にコピーするような移管）においても適用可能である。また、一台の装置内において、文書情報を移管する場合に本発明を適用してもよい。更に、本発明の適用可能な情報は文書情報に限られない。ツリー構造によって管理されている情報であれば、各種の情報に適用可能である。
【０１０２】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１０３】
【図１】第一の実施の形態における文書情報コンバートシステムの構成例を示す図である。
【図２】二つの文書管理システムにおける文書形式の相違を説明するための図である。
【図３】第一の実施の形態におけるコンバータの構成例を示す図である。
【図４】マッピングテーブルの構成例を示す図である。
【図５】本発明の実施の形態における文書管理装置のハードウェア構成例を示す図である。
【図６】処理手順の説明においてコンバート対象とされる文書情報の構成を示す図である。
【図７】第一の実施の形態におけるコンバータによる処理概要を説明するためのフローチャートである。
【図８】第一の実施の形態におけるキャビネットのコンバート処理を説明するためのフローチャートである。
【図９】コンバート処理に応じた移管先のノード及び保持情報の値の遷移を示す図である。
【図１０】コンバート処理に応じた移管先のノード及び保持情報の値の遷移を示す図である。
【図１１】第一の実施の形態における文書情報取得部による処理対象情報の取得処理を説明するためのフローチャートである。
【図１２】第一の実施の形態における処理対象情報の登録処理を説明するためのフローチャートである。
【図１３】親ノードの再作成処理の際の移管先のノード及び保持情報の遷移を説明するための図である。
【図１４】第一の実施の形態における文書情報登録部による親ノードの再作成処理を説明するためのフローチャートである。
【図１５】処理対象のノードが既に作成されている際の移管先のノード及び保持情報の遷移を説明するための図である。
【図１６】コンバート再開時の移管元の文書情報の構成を示す図である。
【図１７】コンバートが再開された際の移管先のノード及び保持情報の遷移を説明するための図である。
【図１８】第二の実施の形態における文書情報コンバートシステムの構成例を示す図である。
【図１９】第二の実施の形態におけるエクスポータ及びインポータの構成例を示す図である。
【図２０】第二の実施の形態におけるエクスポータによる処理概要を説明するためのフローチャートである。
【図２１】第二の実施の形態におけるキャビネットのコンバートファイルの作成処理を説明するためのフローチャートである。
【図２２】第二の実施の形態における文書情報取得部による処理対象情報の取得処理を説明するためのフローチャートである。
【図２３】第二の実施の形態におけるコンバートファイルの作成処理を説明するためのフローチャートである。
【図２４】第二の実施の形態におけるインポータによる処理手順を説明するためのフローチャートである。
【図２５】第二の実施の形態におけるコンバートファイルインポート部による親ノードの再作成処理を説明するためのフローチャートである。
【符号の説明】
【０１０４】
１０ｄ、１０ｓ    文書管理装置
１１ｄ、１１ｓ    文書管理システム
１２          コンバータ
１３          エクスポータ
１４          インポータ
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１２１        文書情報取得部
１２２        文書情報変換部
１２３        文書情報登録部
１３１        文書情報取得部
１３２        文書情報変換部
１３３        コンバートファイル作成部
１３５        マッピングテーブル
１４１        コンバート処理順リスト作成部
１４２        コンバートファイルインポート部
Ｂ            バス
【図１】
0005137562.tif 000002
【図２】
0005137562.tif 000003
【図３】
0005137562.tif 000004
【図４】
0005137562.tif 000005
【図５】
0005137562.tif 000006
【図６】
0005137562.tif 000007
【図７】
0005137562.tif 000008
【図８】
0005137562.tif 000009
【図９】
0005137562.tif 000010
【図１０】
0005137562.tif 000011
【図１１】
0005137562.tif 000012
【図１２】
0005137562.tif 000013
【図１３】
0005137562.tif 000014
【図１４】
0005137562.tif 000015
【図１５】
0005137562.tif 000016
【図１６】
0005137562.tif 000017
【図１７】
0005137562.tif 000018
【図１８】
0005137562.tif 000019
【図１９】
0005137562.tif 000020
【図２０】
0005137562.tif 000021
【図２１】
0005137562.tif 000022
【図２２】
0005137562.tif 000023
【図２３】
0005137562.tif 000024
【図２４】
0005137562.tif 000025
【図２５】
0005137562.tif 000026