(57)【要約】【課題】文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をする際の処理の確実性を向上させる。【解決手段】入力系プラグインから１ページでも正常に取り込むことができなかったドキュメントが有り、エラーとなった場合、当該エラーがデコードエラーの場合は再デコードを依頼し（ステップＳＴ１２）、取得エラーの場合は再取得を依頼した（ステップＳＴ１３）後、入力プラグインからドキュメントを再度取り込む（ステップＳＴ１４）。一方、入力系プラグインから取り込んだドキュメントの各ページに対して、処理系プラグインの処理及び出力系プラグインへの配信を行っている途中でエラーが発生した場合は、当該エラーが発生したページに対する処理系プラグインの処理及び出力系プラグインへの配信を再実行する（ステップＳＴ２０）。【選択図】  図８
2004274150.tif 000002
【特許請求の範囲】
【請求項１】
文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をするサービス処理システムであって、
前記処理過程において、前記文書データに関してエラーが発生した場合に、当該エラーに該当する箇所について、前記エラーが発生した処理を再実行させるように制御する制御手段を備える、
ことを特徴とするサービス処理システム。
【請求項２】
前記制御手段は、前記エラーが発生した時点で前記所定の処理を一時中断し、前記エラーが発生した処理を再実行し、当該再実行後に前記中断を解除する、
ことを特徴とする請求項１に記載のサービス処理システム。
【請求項３】
前記制御手段は、前記エラーに該当する箇所以外の文書データについて前記所定の処理を継続させ、当該継続させた前記所定の処理とは別処理で前記再実行を行う、
ことを特徴とする請求項１に記載のサービス処理システム。
【請求項４】
文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をするサービス処理プログラムであって、
コンピュータに、
前記処理過程において、前記文書データに関してエラーが発生した場合に、当該エラーに該当する箇所について、前記エラーが発生した処理を再実行させる、
ことを特徴とするサービス処理プログラム。
【請求項５】
前記コンピュータに、
前記エラーが発生した時点で前記所定の処理を一時中断させ、前記エラーが発生した処理を再実行させ、当該再実行後に前記中断を解除させる、
ことを特徴とする請求項４に記載のサービス処理プログラム。
【請求項６】
前記コンピュータに、
前記エラーに該当する箇所以外の文書データについて前記所定の処理を継続させ、当該継続させた前記所定の処理とは別処理で前記再処理を行わせる、
ことを特徴とする請求項４に記載のサービス処理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、サービス処理システム及びプログラムに係わり、特に、入力装置から入力された文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をするサービス処理システム及びプログラムに関する。
【０００２】
【従来の技術】
従来より、スキャナ、ファクシミリ（以下「ＦＡＸ」という。）、複写機、又はこれらを複合した複合機、パーソナルコンピュータ、メールサーバをネットワークで接続して、紙文書と電子情報の共有化を図ったネットワークシステムがある。
【０００３】
このようなネットワークシステムは、原稿を読み取るスキャナ、ペーパーレスＦＡＸ等の入力系からの文書ファイルを取り込み、イメージ加工、文字認識等の処理系を経て、プリンタやメールサーバ等の出力系を介して文書ファイルを外部に配信する。
【０００４】
通常、文書ファイルの取り込み、加工、配信はそれぞれ独立して行われる。このため、オペレータは、文書ファイルの取り込み、加工、配信を連続して実行したい場合は、取り込み、加工、配信のそれぞれについて所定の設定を行わなければならない。つまり、オペレータは、取り込み、加工、配信に関するウィンドウを１つずつ開いて、所定の入力操作を行わなければならず、非常に不便であった。
【０００５】
このため、従来より、入力から出力までの一連の処理をネットワーク上で連携して予め定義した順番で実行するワークフローシステムが導入されている。ワークフローシステムは、承認や回覧などオフィスで汎用的に使用されるワークフローを想定して、既存の紙ベースの業務システムをそのまま電子化することによって開発されることが多い（例えば、特許文献１、特許文献２、特許文献３を参照。）。
【０００６】
【特許文献１】
特開２００２−９９６８６号公報
【特許文献２】
特開２００１−３２５３８９号公報
【特許文献３】
特開２００１−１９５２９５号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、従来のワークフローシステムは、特定のサービスを提供するものであり、イレギュラーな処理には対応できなかった。すなわち、ＦＡＸ受信中の受信エラーなど、処理の途中でエラーが発生すると、処理が中止されてしまい、途中までの処理結果しか得ることができなかった。特に、処理の確実性を要求しているユーザに対しては、このような途中までの処理結果となってしまうと、不具合になってしまう。
【０００８】
本発明は上記問題点を解消するためになされたもので、文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をする際の処理の確実性を向上させることができるサービス処理システム及びプログラムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、請求項１に記載のサービス処理システムは、文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をするサービス処理システムであって、前記処理過程において、前記文書データに関してエラーが発生した場合に、当該エラーに該当する箇所について、前記エラーが発生した処理を再実行させるように制御する制御手段を備えることを特徴としている。
【００１０】
このサービス処理システムによれば、文書データに関して所定の処理を行っている途中でエラーが発生しても、制御装置により当該エラーに該当する箇所について、当該エラーが発生した処理を再実行される。すなわち、エラーにより正常に実行されなかった処理の再実行により当該エラーの解消を図ることができ、従来よりも確実性が向上する。
【００１１】
なお、文書データに関するエラーには、文書データを入力した際に発生したエラー（例えば、ＦＡＸ受信エラーや受信データの出コードエラーなど）や、所定の処理の実行中に発生したエラーなどが含まれる。
【００１２】
上記のサービス処理システムにおいては、請求項２に記載されているように、前記制御手段は、前記エラーが発生した時点で前記所定の処理を一時中断し、前記エラーが発生した処理を再実行し、当該再実行後に前記中断を解除するようにするとよい。この場合、エラーが発生した時点で直ちに再実行を行って当該エラーの解消を図ることができる。
【００１３】
或いは、請求項３に記載されているように、前記制御手段は、前記エラーに該当する箇所以外の文書データについて前記所定の処理を継続させ、当該継続させた前記所定の処理とは別処理で前記再実行を行うようにしてもよい。この場合、例えば、複数ページの文書データに関して所定の処理を行う場合に、あるページの文書データに関してエラーが発生しても、当該ページ以外のページの文書データに関する所定の処理は継続され、文書データに関する所定の処理全体を中断させずに済み、処理効率が高い。
【００１４】
なお、予め定めた所定回数再実行を行っても、エラーが解消されなかった場合には、再実行を中止し、ユーザにエラーを報知するとよい。
【００１５】
上記のサービス処理システムは、ネットワーク上のコンピュータに以下のようなサービス処理プログラムを実行させることにより実現できる。
【００１６】
すなわち、請求項４に記載されているように、文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をするサービス処理プログラムであって、コンピュータに、前記処理過程において、前記文書データに関してエラーが発生した場合に、当該エラーに該当する箇所について、前記エラーが発生した処理を再実行させる、ことを特徴とするサービス処理プログラムをコンピュータに実行させればよい。
【００１７】
なお、上記サービス処理プログラムにおいては、請求項５に記載されているように、前記コンピュータに、前記エラーが発生した時点で前記所定の処理を一時中断させ、前記エラーが発生した処理を再実行させ、当該再実行後に前記中断を解除させる、ようにするとよい。
【００１８】
或いは、請求項６に記載されているように、前記コンピュータに、前記エラーに該当する箇所以外の文書データについて前記所定の処理を継続させ、当該継続させた前記所定の処理とは別処理で前記再処理を行わせる、ようにしてもよい。
【００１９】
【発明の実施の形態】
次に、図面を参照して本発明に係る実施形態の１例を詳細に説明する。
【００２０】
［システム構成］
図１は、本発明の実施の形態に係る文書共有ネットワークシステム１の概略的な構成を示す図である。
【００２１】
上記文書共有ネットワークシステム１は、プリント機能、スキャナ機能及びファクシミリ機能を兼ね備えた複数の複合機１０と、電子メールの送受信等を行うメールサーバ２０と、複数の端末装置２５と、ドキュメントを所定の取り込み先から取り込んで所定の加工を施した後、所定の配信先に配信する制御を行う制御装置３０と、を備えている。ここにいうドキュメントは、本発明の文書データに対応し、主に文書に関するイメージデータであるが、加工処理の状態に応じてテキストデータを含むものであってもよく、特に限定されるものではない。
【００２２】
複合機１０、メールサーバ２０、各端末装置２５及び制御装置３０は、ネットワーク５を介して相互に接続されている。なお、ネットワーク５には、図示しないが、プリンタ、スキャナ、ファクシミリ装置がそれぞれ接続されてもよい。
【００２３】
図２は、文書共有ネットワークシステム１の処理の概要を説明する図である。複合機１０、メールサーバ２０及び端末装置２５は、ネットワーク５を介して相互に接続されているものの、通常は独立して動作する。そこで、制御装置３０は、文書共有ネットワークシステム１における取り込み先、加工方法、配信先を設定し、ドキュメントの取り込み、加工及び配信までの一連の処理を自動化／定型化して、コアサービスを提供するものである。
【００２４】
ここで、一連の処理を自動化／定型化するための定義したものを「ルール」という。ルールの設定については後述する。また、取り込み、加工方法、配信のそれぞれの特定の機能を提供するアプリケーションプログラムを、入力系プラグイン、処理系プラグイン、出力系プラグインという。
【００２５】
図３は、複合機１０の構成を示すブロック図である。
【００２６】
複合機１０は、入力系プラグインや出力系プラグインの機能を提供し得るものであり、原稿に記録された画像を読み取るスキャナ部１１と、感光体に静電潜像を記録し、静電潜像をモノクロトナーまたはカラートナーを用いて現像し、現像した画像を記録紙に転写して出力するプリンタ部１２と、ファクシミリ電文の送受信を行うファクシミリ（以下「ＦＡＸ」という。）部１３とを備えている。
【００２７】
複合機１０は、さらに、全体を制御するコントローラ１４と、スキャナ部１１で読み取られた画像データやネットワーク５を介して受信した画像データ、ＦＡＸ受信電文のデータ等を記憶するメモリ１５と、アイコンを有する操作画面を表示すると共にアイコンへの接触に応じて操作情報を入力する表示パネル１６と、データを入出力するための入出力ポート１７と、ネットワークに接続された機器と通信を行う通信制御ユニット１８とを備えている。
【００２８】
スキャナ部１１、プリンタ部１２、ＦＡＸ部１３、コントローラ１４、メモリ１５、表示パネル１６及び入出力ポート１７は、バスを介して相互に接続されている。入出力ポート１７は、通信制御ユニット１８を介してネットワーク５に接続されている。なお、スキャナ部１１は、ＦＡＸ部１３の一部として組み込まれてもよい。
【００２９】
なお、通常、複合機１０では、処理中にエラーが発生した場合に、そのエラーの内容を示す障害情報１９を生成し、メモリ１５の所定記憶領域をエラー履歴メモリ１５Ａとして、生成した障害情報１９をエラー履歴メモリ１５Ａに蓄積記憶するようになっている（図８参照）。障害情報には、ジョブを識別するためのジョブＩＤ、エラーを起こしたページ番号、及びエラー要因などが含まれる。エラー要因としては、例えば、ＦＡＸ受信時の通信エラー（所謂Ｋ７エラー）、受信データやスキャニングデータのデコードに失敗したデコードエラー、自動原稿送り機能を使用したスキャニング時に読取り原稿が紙詰まりを起こしたなどハードウェア的なエラーなどがある。
【００３０】
また、本実施形態に係る複合機１０では、メモリ１５の所定記憶領域が複数の親展ＢＯＸ１５Ｂとして仕切られており、各親展ＢＯＸ１５Ｂは、ＢＯＸ番号（例えばＢＯＸ番号１〜３００）により管理されている。複合機１０は、スキャナ部１１でスキャニングしたドキュメントやＦＡＸ部で受信したドキュメントにファイル名を付けて、親展ＢＯＸ１５Ｂに保存し、当該親展ＢＯＸ１５に対して予め設定された送信先へ送信することもできるようになっている。
【００３１】
メールサーバ２０は、入力系プラグインや出力系プラグインの機能を提供し得るものであり、ネットワーク５に接続された各端末装置２５の電子メールの送受信を行うサーバである。
【００３２】
端末装置２５は、入力系プラグイン、処理系プラグイン及び出力系プラグインの機能を提供し得るものであり、いわゆるパーソナルコンピュータである。端末装置２５は、例えばメールサーバ２０を介して外部と電子メールの送受信を行ったり、ファイルフォルダにドキュメントを保管したり、ドキュメントに対して所定の画像処理を行う。
【００３３】
制御装置３０は、ワークフローとしてのルールを設定したり、ルールに基づいてドキュメントの取り込み、加工及び配信までの一連の処理を実行するものである。なお、制御装置３０は、処理系プラグインになってもよい。
【００３４】
図４は、制御装置３０の構成を示すブロック図である。
【００３５】
制御装置３０は、全体を制御するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）３１、ワークエリアとしてデータを一時格納するＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）３２、ＣＰＵ３１の制御プログラム等を記憶するＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）３３、ルールを設定するためのルール設定画面などを表示するディスプレイ３４、ＣＤ−ＲＯＭドライブ３５を備えている。
【００３６】
制御装置３０は、さらに、ドキュメントの取り込み、加工及び配信までの一連の処理を自動化／定型化するためのプログラム、処理系プラグインとして機能するためのアプリケーションプログラムや所定のデータ等を記憶したり読み出すハードディスクドライブ３６、文章や記号等を入力するキーボード３７、ポインティングデバイスであるマウス３８、これらが接続されたインタフェース３９、入出力ポート４０及び通信制御ユニット４１を備えている。
【００３７】
ＣＰＵ３１、ＲＡＭ３２、ＲＯＭ３３、インタフェース３９及び入出力ポート４０は、ネットワーク５に接続された複合機１０等の他の機器と通信を行う通信制御ユニット４１に接続されている。
【００３８】
なお、キーボード３７は、ディスプレイ３４に様々な設定画面が表示されたときに、オペレータの指示する情報を直接入力するときに用いられる。また、マウス３８は、ディスプレイ３４に様々な設定画面が表示されたときに、表示されたものを選択したり、設定指示の内容を入力するとき使用される。
【００３９】
［ルールの一例］
図５は、制御装置３０によって入力系プラグイン、処理系プラグイン、出力系プラグインを任意に組み合わせて生成することができるルールの一例を説明する図である。
【００４０】
例えば、ルール１は、複数の入力系プラグイン（ＦＡＸ受信サービス、ファイルフォルダ、スキャンサービス）からドキュメントを取り込み、複数の処理系プラグイン（イメージ加工、光学文字認識（ＯＣＲ）、属性付与／分配）を経て、これらの処理を経たドキュメントを複数の出力系プラグイン（ファイルフォルダ、プリント出力）に配信することを定義している。
【００４１】
ルール２は、ファイルフォルダ及びＭａｉｌ＿ＭＡＰＩ入力からドキュメントを取り込み、イメージ加工、属性付与／分配の処理を経て、処理済みのドキュメントを外部サービス連携フォルダに配信することを定義している。
【００４２】
ルール３は、ファイルフォルダからドキュメントを取り込み、イメージ加工、ＯＣＲ連携モジュール、属性付与／分配の処理を経て、処理済みのドキュメントをファイルフォルダに配信することを定義している。
【００４３】
ルール４は、所定のＢＯＸ番号の親展ＢＯＸ１５Ｂからドキュメントを取り込み、自動成立、ＯＣＲ、ファイル名生成・付与、画像＆テキストのバインドの処理を経て、これらの処理を経たドキュメントを複数の出力系プラグイン（ファイルフォルダ、プリント出力）に配信することを定義している。
【００４４】
なお、ルール１からルール４は、各処理系プラグインの前後において次の処理に必要なフォーマット（ＦＭＴ）変換を行っている。
【００４５】
ここで、入力系プラグインとしては、図５に示すように、例えばＦＡＸ受信サービス、ファイルフォルダ、スキャンサービス、Ｍａｉｌ＿ＳＭＴＰ入力、ＰＯＰクライアント、Ｍａｉｌ＿ＭＡＰＩ入力などがある。また、図１に示す親展ボックスも該当する。
【００４６】
処理系プラグインとしては、イメージ加工、ＯＣＲ、属性付与／分配、ＯＣＲ連携モジュール等がある。
【００４７】
出力系プラグインとしては、例えばファイルフォルダ、外部サービス連携フォルダ、ｆｔｐ出力、ファイルメッセージ、Ｍａｉｌ＿ＳＭＴＰ出力、Ｍａｉｌ＿ＭＡＰＩ出力などがある。なお、入力系、処理系及び出力系の各プラグインは、上述したものに限定されるものではない。
【００４８】
［制御装置の機能構成］
次に、図６を参照して、本実施の形態に係る制御装置３０における、上記ルールの作成、及びドキュメントの取り込み、加工及び配信までの一連の処理を自動化／定型化するための機能を説明する。図６は、ＣＰＵ３１でのプログラム実行により、図４で示したハードウェア資源を利用して制御装置３０に構築される機能構成を示す図である。
【００４９】
図６に示すように、制御装置３０には、コアサービス部５０、アプリケーションサービス部６０、及び通信部７０の機能が構築されるようになっている。
【００５０】
コアサービス部５０は、制御装置３０の起動時にメモリに常駐される制御プログラムをＣＰＵ３１で実行することにより構築されるものであり、ルール生成・管理部５１、ルールチェック部５２、及びプラグイン状態チェック部５３を備えている。
【００５１】
ルール生成・管理部５１は、ルールを生成すると共に生成したルールを管理するものである。詳しくは、ルール設定用の画面（図示省略）をディスプレイ３４に表示し、該ルール設定用の画面を介してユーザにより入力された情報に基づいて、取り込み先、加工方法、配信先を設定し、ドキュメントの取り込み、加工及び配信までの一連の処理を定義したルールを生成する。生成したルールは、ＲＡＭ３２を介してハードディスクドライブ３６に保存したり、図示しない外部記憶媒体に記憶させる。
【００５２】
また、ルール生成・管理部５１では、ルール設定用の画面を介して、該画面により設定中のルールに対して、当該ルールに従った処理中に何らかのエラーが発生した際に、当該エラーに該当するページについて、当該エラーが発生した処理、すなわちエラーによって正常に行われなかった処理を再実行するリカバリーモードの選択をユーザから受け付け、この選択結果に基づいて、当該ルールに対してリカバリーモードを設定することができるようになっている。
【００５３】
具体的に、本実施の形態では、リカバリーモードとして、エラーが発生した時点で、ルールに従った一連の処理を一時中断して当該エラーが発生した処理を再実行し、再実行後に、一連の処理の中断を解除する第１のリカバリーモードと、エラーに該当する箇所の処理のみを中止して、エラーに該当する箇所以外の処理は継続させる第２のリカバリーモードの何れかを選択可能となっている。
【００５４】
また、ルール生成・管理部５１は、ルール設定用の画面（図示省略）から、保存後のルールの修正も受付け、修正結果に基づいて保存後のルールを更新することもできる。さらに、ルール生成・管理部５１は、生成したルールの中から、現在実行可能なルールのみ実行可能に管理する。
【００５５】
ルールチェック部５２は、生成したルールの適否をチェックするものである。詳しくは、各プラグインの入出力可能なデータフォーマットに基づいて、前後に接続されたプラグイン間でのフォーマット不一致の有無を判断することで、ルールの適否をチェックする。このチェック結果に基づいて、ルール生成・管理部５１は、ユーザにエラー報知してルール修正を促し、ルール修正を受け付ける。
【００５６】
プラグイン状態チェック部５３は、各プラグインの状態（動作可能／不能）をチェックするものである。ルール生成・管理部５１は、このプラグイン状態チェック部５３のチェック結果に基づいて、現在実行可能なルールを判別し、実行不能なルールの起動が指示された場合には、エラーを報知する。
【００５７】
アプリケーションサービス部６０は、ルールの所定の実行タイミングとなったら動作する、すなわちＣＰＵ３１がルールに従って処理を実行する場合に構築されるものであり、ルール実行部６１及びエラー履歴メモリ６２を備えている。
【００５８】
ルール実行部６１は、ルールに従って一連の処理が成されるように制御処理を行うものである。また、ルール実行部６１は、リカバリーモードが設定されたルールについては、何らかのエラーが発生した際に、当該ルールに対して設定されているリカバリーモードに従って、当該発生したエラーの解消を図るようになっている。すなわち、ルール実行部６１が、本発明の制御手段の機能を担っている。なお、ルール実行部６１で実行するルールについては、ルール生成・管理部５１により制御される。
【００５９】
また、ルール実行部６１は、ルール実行中に何らかのエラーが発生した場合には、そのエラー要因、ジョブ番号、ページ番号といった情報をエラー履歴として、エラー履歴メモリ６２に記憶する。このエラー履歴メモリ６２が本発明の記憶手段に対応し、エラー履歴メモリ６２としては、例えばハードディスクドライブ３６の所定の記憶領域を用いることができる。
【００６０】
このエラー履歴メモリ６２の記憶されたエラー履歴は、ルール実行中のエラー有無の判別、エラーが発生した処理の再実行、及び再実行によってもエラーの解消に失敗した場合にはエラー報知に用いられる。
【００６１】
通信部７０は、コアサービス部５０やアプリケーションサービス部６０により、他の装置とデータの送受信、他の装置で実現されるプラグインの状態チェック、他の装置へエラー報知するために、他の装置とネットワーク５を介して通信を行うものである。
【００６２】
［ルールの実行］
制御装置３０は、ルール実行の所定タイミングとなると、ハードディスクドライブ３６や外部記憶媒体に記憶されたルールに基づいて、文書共有ネットワークシステム１の中からドキュメントの取り込み、ドキュメントを加工した後、所定の配信先に配信するまの一連の処理を実行する。
【００６３】
このようにルールに従って一連の処理を実行している途中で何らかのエラーが発生した場合、制御装置では、当該ルールに対してリカバリーモードが設定されていなければ、エラーが発生した時点で当該ルールに基づく一連の処理を中止し、リカバリーモードが設定されていれば、エラーが解消されるように、エラーが発生した処理を再実行（リトライ）する。
【００６４】
以下、リカバリーモードが設定されているルールの実行時の制御装置３０の処理を説明する。
【００６５】
なお、ここでは、図５に示したルール４を例に挙げて説明する。このルール４では、スキャナ部１１或いはＦＡＸ部１３により、原稿をスキャニング或いはＦＡＸ受信して得たドキュメントが、所定のＢＯＸ番号の親展ＢＯＸ１５Ｂに格納された場合に実行される。すなわち、スキャナ部１１或いはＦＡＸ部１３が本発明の入力手段として用いられ、複合機１０が、本発明の所定の処理の対象となる文書データを入力したネットワーク上の装置になる。
【００６６】
また、複合機１０では、この親展ＢＯＸ１５Ｂへのドキュメント格納の際、すなわちスキャニング時やＦＡＸ受信時にエラーが発生した場合には、一般に、図８に示すように、当該発生したエラーの内容（ジョブＩＤ、ページ番号、エラー要因）を示す障害情報１９がエラー履歴メモリ１５Ａに格納されている。
【００６７】
＜第１のリカバリーモード＞
図７は、制御装置３０のＣＰＵ３１が第１のリカバリーモードが設定されているルールに従って処理を実行するときの手順を示すフローチャートである。
【００６８】
すなわち、制御装置３０のＣＰＵ３１は、第１のリカバリーモードが設定されているルールに従って処理を実行する場合、図７に示すように、まず、ステップＳＴ１で、ルールの「取り込み先」として設定された入力系プラグイン（親展ＢＯＸ１５Ｂ）からジョブに関連するドキュメントをページ単位で順次取り込む。そして、全ページのドキュメントを正常に取り込むことができた場合は、エラー無しとして、次のステップＳＴ２から後述のステップＳＴ５にそのまま進む。
【００６９】
一方、１ページでも正常に取り込むことができなかったドキュメントが有った場合は、エラー有りとして、ステップＳＴ２からステップＳＴ３に進み、エラー履歴メモリ６２に当該エラーの内容を記憶してから、ステップＳＴ４に進む。
【００７０】
具体的には、エラーの有無については、制御装置３０から複合機１０側のエラー履歴メモリ１５Ａを参照し、対応するジョブＩＤの障害情報１９の有無により判断することができ、エラーが有った場合には、エラー履歴メモリ１５Ａから対応する障害情報１９を読み出してエラー履歴メモリ６２に格納する。
【００７１】
或いは、複合機１０から制御装置３０へエラー履歴メモリ１５Ａに新規登録された障害情報１９を読み出して送信することによって、エラーの有無が判断されるようにしてもよい。また、或いは、取り込んだドキュメントの各ページが正常なものであるか否かによって、エラーの有無を判断することもできる。
【００７２】
ステップＳＴ４では、図８に示すリトライ処理を実行する。このとき入力プラグインからのドキュメントの取込み時のエラーにより当該リトライ処理が開始されたので、図８のステップＳＴ１０からステップＳＴ１１に進み、エラー履歴メモリ６２に格納した障害情報１９に基づいて、発生したエラーがドキュメントのデコードエラーであるのか取得エラーであるのかを判断する。そして、発生したエラーがデコードエラーである場合には、ステップＳＴ１１からステップＳＴ１２に進み、エラーとなったドキュメントの再デコードを依頼する。
【００７３】
具体的に、ルール４の場合は、スキャナ部１１でスキャニングしたドキュメントやＦＡＸ部で受信したドキュメントにファイル名を付けて、所定のファイル形式のファイルとして親展ＢＯＸ１５Ｂに格納されるが、この所定のファイル形式へのスキャニングしたドキュメントや受信したドキュメントの変換に失敗した場合にデコードエラーとなる。
【００７４】
制御装置３０では、複合機１０に対して、スキャナ部１１でスキャニングした、或いはＦＡＸ部１３でのＦＡＸ受信して得られたデータの再デコードを依頼すればよい。
【００７５】
通常、複合機１０では、スキャニングしたデータやＦＡＸ受信したデータをメモリのバッファ領域に格納し、ユーザにより処理済みデータの即時消去設定がなされていない限り、電源ＯＦＦ、メモリーフル、ユーザによる強制消去指示入力など、所定のタイミングとなるまではこのデータを保持しているため、再デコードの実行は可能である。逆に、ルール設定画面（図示省略）を介してユーザがリカバリーモードを選択した際に、複合機１０が即時消去設定がなされていたら、該設定を解除するようにユーザに促すとよい。
【００７６】
また、デコードエラーの場合、所定のファイル形式への変換に失敗したページのドキュメントも、本来の原稿を完全に再現することはできない状態ではあるが親展ＢＯＸ１５Ｂに格納されるため、この親展ＢＯＸ１５Ｂ内のドキュメントを用いて、再デコードを行うようにしてもよい。
【００７７】
なお、デコードはソフトウェアでの処理であるため、複合機１０以外の装置でも再デコードを実行可能であり、例えば制御装置３０にデコード処理を行うためのプログラムをインストールしておき、制御装置３０で再デコードが行われるようにしてもよい。
【００７８】
なお、デコードエラーは、他にも、例えば、スキャニングした文書に定型サイズのものと不定形サイズのものが混在している場合にも発生する。また、例えば、インターネットＦＡＸサービスの場合、ドキュメントとして、ページ毎に異なるカラープロファイルのデータや、ＴＩＦＦファイルとＰＤＬファイルのようにファイル形式の異なるデータを受信することがあり、このように異なるフォーマットのドキュメントがバインドされたデータを受信した場合にも発生する。
【００７９】
一方、発生したエラーがデコードエラーではない場合、すなわち取得エラーである場合には、ステップＳＴ１１からステップＳＴ１３に進み、ドキュメントの再取得を依頼する。
【００８０】
具体的にルール４の場合は、スキャナ部１１でのスキャニング中に原稿の紙詰まりが発生したり、ＦＡＸ部１３でのＦＡＸ受信中に通信エラーが発生した場合に、入力エラーとなる。
【００８１】
制御装置３０では、複合機１０に対して、スキャナ部１１でのスキャニングの再実行を依頼したり、或いはＦＡＸ部１３にＦＡＸ再受信を依頼して、ＦＡＸ部１３から相手先（ＦＡＸ送信元）へＦＡＸ再送を要求させて、ドキュメントの再取得を依頼すればよい。
【００８２】
なお、ＦＡＸ再送の要求方法としては、ＦＡＸ再受信が依頼された場合に、ＦＡＸ部１３が相手先との通信が接続状態であれば、当該接続中に、取得エラーとなったページのドキュメントについてＦＡＸ再送を相手先へ要求すればよい。また、相手先との通信が切断状態である場合には、例えば、ＦＡＸ部１３に相手先のＦＡＸ番号を頼りに相手先との接続を復旧させて、ＦＡＸ再送を相手先に要求したり、相手先のユーザに再送を要求するＦＡＸを送信するようにすればよい。相手先のユーザの操作によりＦＡＸが再送された場合には、相手先のＦＡＸ番号により、何れのジョブに関する再送であるのかを識別すればよい。
【００８３】
このように、ステップＳＴ１２で再デコードを依頼、或いはステップＳＴ１３で再取得を依頼した後は、ステップＳＴ１４に進み、ドキュメントの再取り込みを行う。ルール４の場合は、再デコード依頼を受けて、複合機１０で再デコードされて親展ＢＯＸ１５Ｂに格納されたドキュメント、或いは、再取得依頼を受けて、複合機１０で再スキャン又は再ＦＡＸ受信して親展ＢＯＸ１５Ｂに格納されたドキュメントを取り込む。
【００８４】
その後は、前述のステップＳＴ１で正常に取り込むことができなかったページのドキュメント（エラードキュメント）がステップＳＴ１４で正常に取り込まれるまで、次のステップＳＴ１５からステップＳＴ１１に戻り、同様の処理を繰返し、エラードキュメントを正常に取り込むことができたら、次のステップ１５で肯定判定されて、図７に戻る。
【００８５】
すなわち、制御装置３０では、図８のリトライ処理により、入力系プラグインからのドキュメントの取り込み時にエラーが発生した場合に、再デコードや再受信を促して、再デコード或いは再受信後のドキュメントを再取り込みして、エラーの解消に努める。そして、エラードキュメントを正常に取り込むことができ、エラーが解消されたら、すなわち全ページのドキュメントを正常に取り込んだ状態となって、図７の処理に戻る。
【００８６】
なお、図では省略するが、所定回数以上繰り返しても、エラードキュメントを正常に取り込むことができなかった場合には、リカバリー失敗として、ユーザにエラーを報知し、ルールに従った処理を中止するとよい。
【００８７】
図７に戻るとステップＳＴ５に進み、取り込んだドキュメントの各ページに対して、ルールの「加工方法」として設定された処理系プラグインの処理を実行し、「配信先」として設定された出力系プラグイン（例えば、ファイルフォルダ）に対して、配信条件に従って配信する。
【００８８】
具体的に、ルール４の場合、ステップＳＴ４では、適宜フォーマット変換を行いながら、ドキュメント（画像）が正立されるように回転させる自動正立、光学文字認識（ＯＣＲ）の後、認識した文字の一部を用いてファイル名を生成してＯＣＲ処理後のテキストに付与し、ドキュメントの画像をバインドして、ファイルフォルダに格納すると共に、プリント出力する。
【００８９】
なお、フォーマット変換は、設定された処理系プラグインに基づいて自動的に実行してもよいし、オペレータのマニュアル設定によって実行してもよい。
【００９０】
そして、この処理系プラグインの処理、及び出力系プラグインへの配信は、取り込んだドキュメントの全ページに対して終了するまでは、次のステップＳＴ６を介してステップＳＴ９からステップＳＴ５に戻り、繰返し実行されるが、例えばフォーマット変換に失敗したなど、途中でエラーが発生した場合には、ステップＳＴ６からステップＳＴ７に進む。
【００９１】
ステップＳＴ７では、当該エラーの内容を示す障害情報をエラー履歴メモリ６２に記憶した後、ステップＳＴ８に進んで図８のリトライ処理を実行する。ここでは、処理系プラグインでの処理又は出力系プラグインへの格納時のエラーによりこのリトライ処理が開始されたので、図８のステップＳＴ１０からステップＳＴ２０に進み、エラーが発生したドキュメント（エラードキュメント）のページに対する処理系プラグインの処理及び出力系プラグインへの格納を再実行する。なお、エラードキュメントに対する処理系プラグインによる処理の最初から再実行するのではなく、エラーとなった処理以降の処理や格納のみを再実行するようにしてもよい。
【００９２】
そして、このエラードキュメントに対する処理系プラグインの処理及び出力系プラグインへの格納が正常に処理されるまで、次のステップＳＴ２１からステップＳＴ２０に戻り、正常に処理できたら、ステップ２１で肯定判定されて図７に戻る。
【００９３】
すなわち、制御装置３０では、図７のリトライ処理により、エラードキュメントに対する処理系プラグインの処理及び出力系プラグインへの格納を再実行して発生したエラーの解消に努め、当該処理及び格納が正常に実行され、エラーが解消されたら、図７の処理に戻る。
【００９４】
なお、図では省略するが、所定回数以上繰り返しても、エラードキュメントに対する処理系プラグイン、出力系プラグインの処理が正常にできなかった場合には、リカバリー失敗として、ユーザにエラーを報知し、ルールに従った処理を中止するとよい。
【００９５】
図７に戻るとステップＳＴ９に進み、未処理のページが残っている場合はステップＳＴ９からステップＳＴ５に戻る。取り込んだドキュメントの各ページに対する処理系プラグインの処理及び出力系プラグインへの格納が終了したら、ステップＳＴ９で肯定判定されて、図７の処理は終了する。
【００９６】
このような処理により、第１のリカバリーモードでは、ルールに従った一連の処理を実行中にエラーが発生した場合、当該エラーが発生した時点で、ルールに従った一連の処理を一時中断する。そして、エラーに該当するページについて、当該エラーが発生した処理を再実行することで、当該エラーの解消を図り、エラーを解消することができたら、中断を解除して、ルールに基づく一連の処理を継続する。すなわち、第１のリカバリーモードでは、エラーが発生した時点で直ちに当該エラーが発生した処理を再実行する（リトライ処理）して、当該エラーの解消に図るようになっている。
【００９７】
＜第２のリカバリーモード＞
図９は、制御装置３０のＣＰＵ３１が第１のリカバリーモードが設定されているルールに従って処理を実行するときの手順を示すフローチャートである。なお、図９では、図７と同様の処理については、同一のステップ番号を付与して示しており、ここでは詳細な説明を省略する。
【００９８】
すなわち、制御装置３０のＣＰＵ３１は、第２のリカバリーモードが設定されているルールに従って処理を実行する場合、図９に示すように、まず、ステップＳＴ１で、入力系プラグイン（親展ＢＯＸ１５Ｂ）からドキュメントをページ単位で順次取り込む。そして、全ページのドキュメントを正常に取り込むことができた場合は、次のステップＳＴ２から後述のステップＳＴ５Ａにそのまま進み、エラーが有った場合には、ステップＳＴ２からステップＳＴ３に進み、エラー履歴メモリ６２に当該エラーの内容を記憶して、次のステップＳＴ４Ａで図１０に示すリトライ処理（後述）を図９の処理とは別の処理として起動してから、ステップＳＴ５Ａに進む。
【００９９】
ステップＳＴ５Ａでは、取り込んだドキュメントをページ単位に正常であるか否かを判別して、正常に取り込まれた正常ドキュメントの各ページに対してのみ、ルールの「加工方法」として設定された処理系プラグインの処理を実行し、「配信先」として設定された出力系プラグイン（例えば、ファイルフォルダ）に対して、配信条件に従って配信する。
【０１００】
なお、取り込んだ各ページのドキュメントが正常であるか否かは、例えばエラー履歴メモリ６２に格納した障害情報１９を参照することで容易に判断することができる。
【０１０１】
すなわち、入力系プラグインから全ページのドキュメントを正常に取り込むことができた場合には、ステップＳＴ５Ａでは、全ページに対して、処理系プラグインの処理及び出力系プラグインへの格納を行う。一方、取り込んだドキュメントにエラーがあった場合には、ステップＳＴ５Ａでは、エラーがあったページについては処理系プラグインの処理及び出力系プラグインへの格納を行わなず、正常に取り込むことができたページについてのみ、処理系プラグインの処理及び出力系プラグインへの格納を行う。
【０１０２】
処理系プラグインの処理及び出力系プラグインへの配信は、正常ドキュメントの各ページに対して終了するまでは、次のステップＳＴ６を介してステップＳＴ９からステップＳＴ５Ａに戻り繰返し実行されるが、例えばフォーマット変換に失敗したなど、途中でエラーが発生した場合には、当該エラーが発生したページに関する処理が中止されて、ステップＳＴ６からステップＳＴ７に進む。
【０１０３】
ステップＳＴ７では、当該エラーの内容を示す障害情報をエラー履歴メモリ６２に記憶し、次のステップＳＴ８Ａで、図１０に示すリトライ処理（後述）を図９の処理とは別の処理として起動してから、ステップＳＴ９に進み、未処理のページが残っている場合はステップＳＴ９からステップＳＴ５Ａに戻る。なお、エラーが発生したページについての処理は、エラー発生時点で中止させてもよいし、エラーが発生した状態のまま最後まで、すなわち出力系プラグインへ配信してもよい。
【０１０４】
正常に取り込んだドキュメントの各ページに対する処理系プラグインの処理及び出力系プラグインへの格納が終了したら、ステップＳＴ９で肯定判定されて、図９の処理は終了する。
【０１０５】
一方、ステップＳＴ４Ａ、ステップＳＴ８Ａでリトライ処理が起動されると、制御装置３０では、図９の処理と平行して、図１０に示す処理を行う。なお、図９では、図７と同様の処理については、同一のステップ番号を付与して示しており、ここでは詳細な説明を省略する。
【０１０６】
図９に示すように、リトライ処理では、入力プラグインからのドキュメントの取込み時のエラーにより当該リトライ処理が起動された場合は、ステップＳＴ１０からステップＳＴ１１に進み、エラー履歴メモリ６２に格納した障害情報１９に基づいて、発生したエラーがドキュメントのデコードエラーであるのか取得エラーであるのかを判断する。
【０１０７】
そして、発生したエラーがデコードエラーである場合には、ステップＳＴ１２に進み、エラーとなったドキュメントの再デコードを依頼し、デコードエラーではない、すなわち取得エラーである場合には、ステップＳＴ１３に進み、ドキュメントの再取得を依頼した後、ステップＳＴ１４に進んで、ドキュメントの再取り込みを行う。
【０１０８】
この再取り込みによっても、エラードキュメントが正常に取得できなかった場合には、次のステップＳＴ１５からステップＳＴ１１に戻り、エラードキュメントが正常に取得されるまで同様の処理を繰返し実行し、エラードキュメントを正常に取得することができたら、ステップＳＴ１５からステップＳＴ１６Ａに進む。
【０１０９】
なお、図では省略するが、所定回数以上繰り返しても、エラードキュメントを正常に取り込むことができなかった場合には、リカバリー失敗として、ユーザにエラーを報知し、ルールに従った処理を中止するとよい。
【０１１０】
ステップ１６Ａでは、正常に取り込むことができたこのエラードキュメントに対して、処理系プラグインによる処理及び出力系プラグインへの格納を順次行う。
【０１１１】
この処理系プラグインによる処理や出力系プラグインへの格納を行っている途中でエラーが発生した場合には、次のステップ１７ＡからステップＳＴ１８Ａに進んで、当該エラーの内容を示す障害情報をエラー履歴メモリ６２に記憶して、後述のステップＳＴ２０に進む。
【０１１２】
一方、この正常に取り込むことができたエラードキュメントに対する、処理系プラグインによる処理及び出力系プラグインへの格納が正常に行われたら、次のステップＳＴ１７で肯定判定されて、図１０のリトライ処理は終了する。
【０１１３】
また、リトライ処理では、処理系プラグインでの処理中や出力系プラグインへの格納中のエラーにより当該リトライ処理が起動された場合は、ステップＳＴ１０からステップＳＴ２０に進み、エラーが発生したドキュメント（エラードキュメント）のページに対する処理系プラグインの処理及び出力系プラグインへの格納を再実行する。そして、このエラードキュメントに対する処理系プラグインの処理及び出力系プラグインへの格納が正常に処理されるまで、次のステップＳＴ２１からステップＳＴ２０に戻り、正常に処理できたら、ステップＳＴ２１で肯定判定されて、図１０のリトライ処理は終了する。
【０１１４】
なお、図では省略するが、所定回数以上繰り返しても、エラードキュメントに対する処理系プラグイン、出力系プラグインの処理が正常にできなかった場合には、リカバリー失敗として、ユーザにエラーを報知し、ルールに従った処理を中止するとよい。
【０１１５】
このような処理により、第２のリカバリーモードでは、エラーが発生したら、当該エラーが発生したページ、すなわちエラーに該当する箇所の処理のみ中止して、エラーが発生したページ以外、すなわちエラーに該当する箇所以外の文書データについては一連の処理をそのまま継続して実行させる。そして、継続させた処理とは別処理で、エラーが発生したページ、すなわちエラーに該当する箇所の処理を再実行して、当該エラーの解消を図る。
【０１１６】
すなわち、第２のリカバリーモードでは、エラーが発生しても可能な限りルールに従った一連の処理を継続させ、当該エラーが発生した処理を別処理で再実行する（リトライ処理）して、当該エラーの解消を図るようになっている。
【０１１７】
また、第２のリカバリーモードは、エラーの解消に成功した場合には、本来あるべき全ページのドキュメントのルールに従った一連の処理の処理結果を得ることができ、失敗した場合でも、エラーが発生したページに対する一連の処理結果が得られないだけであり、その他のページについての処理結果は得ることができるという特徴がある。
【０１１８】
なお、図９では、エラーが発生した時点で図１０のリトライ処理を起動し、図９の処理と同時並行で、エラーが発生した処理の再実行が行われるようにしたが、リトライ処理の起動タイミングについては、これに限定されるものではない。すなわち、リトライ処理の起動タイミングは、例えば、図９の処理終了後など、エラーが発生した時点以外の所定タイミングであってもよい。この場合は、エラー履歴メモリ６２の障害情報１９の登録順に、発生した各エラーを解消するためのリトライ処理を起動すればよい。
【０１１９】
このように、本実施の形態に係る文書共有ネットワークシステム１では、ルールに従った一連の処理中にエラーが発生した場合には、制御装置３０の制御により、当該エラーが発生した処理を再実行して、当該エラーの解消を図るようにしたので、従来よりも確実性を向上させることができる。
【０１２０】
また、特に、ルールに従った処理の開始トリガーとなる入力系プラグイン（ルール４の場合は親展ＢＯＸ１５Ｂ）でのドキュメント入力時のエラーについても、再実行により当該エラーの解消を図るようにしたので、従来技術では、ドキュメント入力時にエラーが発生すると、ルールに従った処理が全く行われなくなってしまったのと比べて、より処理効率を向上させることができる。
【０１２１】
ここで、入力系プラグインでのドキュメント入力時にエラーが有った場合について図１１、図１２を参照して具体的に説明する。なお、以下では、第２のリカバリーモードの設定時を例に説明する。
【０１２２】
図１１は、スキャナ部１１により原稿をスキャニングして、或いはＦＡＸ部１３によりＦＡＸ受信してドキュメントを取得して親展ＢＯＸ１５Ｂに格納している途中で、例えば全４ページ中の３ページ目で入力エラーが発生し、スキャニング或いはＦＡＸ受信が中止され、親展ＢＯＸ１５Ｂに１ページ目と２ページ目しか正常ドキュメントとして格納されなかった場合を示している。
【０１２３】
この場合、上記の如く処理することで、制御装置３０では、親展ＢＯＸ１５Ｂから取り込んだ１ページ目と２ページ目の正常ドキュメントに対してはルールに従った通常処理を継続させると共に、エラー履歴メモリ１５Ａから、エラーが発生した３ページ目のエラー内容を示す障害情報１９を取得して、該制御装置３０側のエラー履歴メモリ６２に格納する。そして、この障害情報１９に基づいて、スキャナ部１１或いはＦＡＸ部１３に再スキャン或いはＦＡＸ再受信を依頼し、再スキャン或いはＦＡＸ再受信によって親展ＢＯＸ１５Ｂに新たにドキュメントが格納されたら、当該ドキュメントを取り込み、全４ページのドキュメントのうち、エラーによって行われなかった３ページ目以降のドキュメントに対するルールに従った通常処理を実行する。これにより、入力エラーが発生しても当該エラーを解消することができる。
【０１２４】
また、図１２は、スキャナ部１１により原稿をスキャニングして、或いはＦＡＸ部１３によりＦＡＸ受信してドキュメントを取得して親展ＢＯＸ１５Ｂに格納している途中で、例えば全４ページ中の３ページ目でデコードエラーが発生し、当該エラー後の最終ページの４ページのドキュメントは正常に取得された場合を示している。
【０１２５】
この場合、制御装置３０では、親展ＢＯＸ１５Ｂから取り込んだ１、２、４ページ目の正常ドキュメントに対しては、ルールに従った通常処理を継続させると共に、エラー履歴メモリ１５Ａから、エラーが発生した３ページ目のエラー内容を示す障害情報１９を取得して、該制御装置３０側のエラー履歴メモリ６２に格納する。そして、この障害情報１９に基づいて、スキャナ部１１或いはＦＡＸ部１３に３ページ目のドキュメントの再デコードを依頼し、再デコードされた３ページ目のドキュメントが親展ＢＯＸ１５Ｂに新たに格納されたら、当該ドキュメントを取り込み、エラーによって行われなかった３ページ目のドキュメントに対するルールに従った通常処理を実行する。これにより、デコードエラーが発生しても当該エラーを解消することができる。
【０１２６】
なお、上記では、ネットワーク５上に制御装置３０を設け、制御装置３０の制御により、ワークフローとして予め定めたルールに従って、ドキュメント取り込みから、加工、配信までの一連の処理を行うサービスをネットワーク５上で連携して処理されるようにした文書共有ネットワークシステム１をサービス処理システムとして、本発明を適用した例に説明したが、本発明はこれに限定されるものではない。本発明を適用するサービス処理システムは、ワークフローに従って一連の処理を連続して実行することができれば、如何なる形態であっても構わない。
【０１２７】
【発明の効果】
上記に示したように、本発明は、文書データに関して所定の処理を行うサービスをネットワーク上で連携して処理をするサービス処理システムにおいて、処理の確実性を向上させることができるという優れた効果を有する。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る文書共有ネットワークシステムの概略図である。
【図２】文書共有ネットワークシステムの処理の概要を説明する図である。
【図３】複合機の構成を示すブロック図である。
【図４】制御装置の構成を示すブロック図である。
【図５】入力系プラグイン、処理系プラグイン、出力系プラグインを任意に組合せて生成することができるルールの一例を説明する図である。
【図６】制御装置の機能構成を示すブロック図である。
【図７】制御装置のＣＰＵが第１のリカバリーモードが設定されたルールに従って処理を実行するときの手順を示すフローチャートである。
【図８】図７の処理で実行されるリトライ処理（サブルーチン）である。
【図９】制御装置のＣＰＵが第２のリカバリーモードが設定されたルールに従って処理を実行するときの手順を示すフローチャートである。
【図１０】図９の処理により起動されて、図９と並行処理されるリトライ処理である。
【図１１】ドキュメントをスキャニング或いはＦＡＸ受信して、入力系プラグインとしての親展ＢＯＸに格納している途中で入力エラーが発生した場合の処理を説明するための概念図である。
【図１２】ドキュメントをスキャニング或いはＦＡＸ受信して、入力系プラグインとしての親展ＢＯＸに格納している途中でデコードエラーが発生した場合の処理を説明するための概念図である。
【符号の説明】
１      文書共有ネットワークシステム
５      ネットワーク
１０  複合機
１５  メモリ
１５Ａ            エラー履歴
１５Ｂ  親展ＢＯＸ
１９  障害情報
２５  端末装置
３０  制御装置
３１  ＣＰＵ
３６  ハードディスクドライブ
５０  コアサービス部
６０  アプリケーションサービス部
６２  エラー履歴メモリ
【図１】
2004274150.tif 000003
【図２】
2004274150.tif 000004
【図３】
2004274150.tif 000005
【図４】
2004274150.tif 000006
【図５】
2004274150.tif 000007
【図６】
2004274150.tif 000008
【図７】
2004274150.tif 000009
【図８】
2004274150.tif 000010
【図９】
2004274150.tif 000011
【図１０】
2004274150.tif 000012
【図１１】
2004274150.tif 000013
【図１２】
2004274150.tif 000014