JP4488206B2

JP4488206B2 - ドキュメント処理装置

Info

Publication number: JP4488206B2
Application number: JP2004353361A
Authority: JP
Inventors: 隆史新元
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2004-12-06
Filing date: 2004-12-06
Publication date: 2010-06-23
Anticipated expiration: 2024-12-06
Also published as: JP2006165916A

Description

本発明は、再実行の仕組みを持つドキュメント処理装置に関する。

従来のコピー、ファクス、プリンタ、イメージスキャナ等の各種機能を提示するためのアプリケーションソフトウェアは、個別に開発されており、各機能においては同様な処理を行っているにもかかわらず方式はそれぞれ異なっており、品質も人や組織に依存してしまっていた。このようなアプリケーションソフトウェアの不統一は、アプリケーション開発者およびアプリケーションのユーザの双方に対して様々な問題を引き起こすものとなっていた。

この問題を解決すべく、画像入出力システムに備えられた各画像入出力装置における共通構造としてドキュメント、ページ、オーナー、サーバを抽出してフレームワーク化し、フレームワークの各操作をアプリケーション毎に継承し、動作を実装するドキュメント処理アプリケーションが構築されている。

１以上のアプリケーションで作成されたドキュメントを容易に編集、印刷、仕分けを行えるドキュメント編集システムが提案されている。これは、アプリケーションデータＩ／Ｆ部は、アプリケーションから必要なドキュメント情報を獲得する。獲得したドキュメント情報はドキュメント仮想表示部で一覧表示してユーザのドキュメント編集に供する。ドキュメント変更表示部は、ユーザがユーザインターフェイス部で行ったドキュメントの編集指示を受け取り、変更情報を生成して変更情報蓄積部に蓄積する。編集が終了すると、仕分け情報生成部は変更情報から仕分け情報を生成する。また、ドキュメント情報出力部は、編集後のドキュメントを構成するドキュメント情報を印刷できる情報に変換して、新ドキュメント情報として仕分け情報とともに出力する（例えば、特許文献１参照）。

また、データ形式の異なる複数の文書を簡単に入力して一元管理し、紙文書を他の電子文書と同様に一元管理および再利用できるようにし、さらにデータ形式の異なる複数の文書をシームレスに検索できる統合型文書管理システムおよび統合型文書管理方法、並びに前記方法をコンピュータに実行させるためのプログラムを格納した記憶媒体が提案されている。

これは、データ形式の異なる複数の文書を処理対象として、それぞれの文書から予め定めた文書構造ファイルを生成し、少なくとも一つ生成した文書構造ファイルを保管し、文書構造ファイルが少なくとも、データ形式の異なる複数の文書そのものから成るオリジナル文書ファイルと、オリジナル文書ファイルから生成したテキストファイルと、個々の文書構造ファイルを管理するための文書管理ファイルとから構成され、該文書構造ファイルを介してデータ形式の異なる複数の文書を統合的に管理する（例えば、特許文献２参照）。

また、マルチユーザ・マルチファクション環境において、拡張性と再利用性に優れたサービスソフトウェアを実現するＯＡ機器制御用インターフェイス構造が提案されている。これは、ＯＡ機器を用いてコピー機能、ファクシミリ機能、プリンタ機能、スキャナ機能などの複合機能を実行する際に、紙および電子ドキュメントを操作するアプリケーションソフトウェアとアプリケーションソフトウェアに対するソフトウェアを提供するサービスソフトウェアとの間にインターフェイス制御処理を実行するＯＡ機器制御用インターフェイス構造において、アプリケーションソフトウェアは、ユーザドキュメントを要求の単位としてサービスソフトウェアに処理を依頼し、該依頼したユーザドキュメントに対すべきユーザページを追加あるいは削除する（例えば、特許文献３参照）。

また、複数の入力元と結合順序を指定するという簡単な操作により、複数の入力元から入力される情報を所望の順序で組合せて出力する、データ処理装置およびデータ処理方法およびコンピュータが読み出し可能なプログラムを格納した記憶媒体を提案している。これは、指示された複数の入力元からそれぞれ入力される情報の結合順序を各入力情報を示すアイコンの配列で表示し、該表示される各入力情報を示すアイコンの配列順序をマウス等により変更指示し、実行指示に基づき、ＣＰＵが、指示された複数の入力元からそれぞれ入力される情報を配列表示される順序で結合して複数の周辺機器による複合機能を制御する（例えば、特許文献４参照）。

また、ドキュメント処理アプリケーション開発を効率よく行うことができるドキュメント処理アプリケーション構築方法が提案されている。これは、画像入出力システムに備えられた各画像入出力装置における共通構造としてドキュメント情報を集約するドキュメント、ページ情報を集約するページ、ドキュメントおよびページに係る情報の生成・消滅権を持つオーナー、ドキュメントに対する処理であるドキュメント処理またはページに対する処理であるページ処理を行うサーバを抽出してフレームワーク化する。これにより、フレームワークの各操作をアプリケーション毎に継承し、動作を実装する。（例えば、特許文献５参照）。
特開平１１−９１１８７号公報特開平１１−１２０２０２号公報特開２０００−１１２８６５号公報特開２０００−３１５１３０号公報特開２００２−３１４７３１号公報

昨今の複合機は、複数のアプリケーションが膨大な機能を有し、これらの機能は目的が類似したものや、機能が重複して存在している場合もある。

このような目的の類似した機能を個別に開発するという非効率な状況で、開発に関わるコストが増大してしまったり、各アプリケーションで個別の制御が行われるため、アプリケーションによって処理が統一されていないという欠点があった。
本発明は、トラブルによって機能の実行が中断した際に、ユーザの要求を満たすために機能を再実行（リトライ）し、ドキュメント処理を３階層に分解することによって、リトライ時に発生する処理の複雑さを分散させることを目的とする。

請求項１にかかる発明は、ユーザがリクエストする処理の単位を扱うリクエスト管理部と、ドキュメント／ページという単位を扱うドキュメント管理部と、ドキュメント／ページを構成する最小のデータ単位（ブロックデータ）を扱うブロックデータ管理部とを備えた３階層から構成されるドキュメント処理装置であって、画像データを入出力する入出力手段と、画像データを含むドキュメント情報およびページ情報を画像入出力する装置で操作する操作手段と、を有し、前記ドキュメント管理部は、ドキュメントの問題の発生を前記リクエスト管理部に通知する手段を有し、前記リクエスト管理部は、前記ドキュメント管理部から前記ドキュメントの問題の発生の通知を受けたときに、要求の変更または処理の中止のいずれか一方を前記ドキュメント管理部に通知する手段を有し、前記ブロックデータ管理部は、前記ブロックデータの入出力の問題の発生を前記ドキュメント管理部に通知する手段を有し、前記ドキュメント管理部は、前記ブロックデータ管理部から前記ブロックデータの入出力の問題の発生の通知を受けたときに、前記リクエスト管理部への当該ブロックデータの入出力の問題の発生の通知または前記ブロックデータ管理部への再度処理の実行の通知のいずれか一方を行う手段を有することを特徴とする。

請求項２にかかる発明は、前記ブロックデータ管理部は、機器の処理で問題が発生したという通知を当該機器から受けたときに、前記ドキュメント管理部への前記ブロックデータの入出力で問題が発生したという通知または前記機器への再度処理を実行するという通知のいずれか一方を行う手段を有することを特徴とする。

請求項１に記載の発明により、ユーザがリクエストする単位、ドキュメント／ページという単位、ドキュメント／ページを構成する最小のデータ単位は、全て該３階層で構成でき、コピー・ファクス・プリンタといったどのアプリケーションにおいても前記３つの階層に分解することが可能であり、同じ構成でドキュメント処理を実現でき、リトライの処理も統一できる。その結果、ドキュメント処理装置の開発を効率よく行うことが可能になり、品質の水準の確保、開発人員の削減、開発期間の短縮が可能となる。

請求項１に記載の発明により、リクエスト管理部はドキュメント管理部にドキュメント出力の指示を出し、問題発生の通知を受けた場合、リクエストの実行をやり直すという一定の手順で、リクエストのリトライ処理を実現することができる。また、リクエストをやり直す判断や処理に変化が生じても、リクエスト管理部を変更するだけで解決でき、他の階層に影響を与えることがない。他の階層に影響の出ないような構成により、ドキュメント処理装置の開発を効率よく行うことが可能となる。

請求項１に記載の発明により、ドキュメント管理部はブロックデータ管理部にドキュメントを構成しているデータ入出力の指示を出し、問題発生の通知を受けた場合、ドキュメント入出力の実行をやり直す、もしくはドキュメント管理部では判断できない問題であれば、リクエスト管理部に問題発生を通知するという一定の手順で、ドキュメント入出力のリトライ処理を実現することができる。また、ドキュメント入出力をやり直す判断や処理に変化が生じても、ドキュメント管理部を変更するだけで解決でき、他の階層に影響を与えることがない。他の階層に影響の出ないような構成により、ドキュメント処理装置の開発を効率よく行うことが可能となる。

請求項２に記載の発明により、ブロックデータ管理部は機器に指示を出し、問題発生の通知を受けた場合、データ入出力の実行をやり直す、もしくはブロックデータ管理部では判断できない問題であれば、ドキュメント管理部に問題発生を通知するという一定の手順で、データ入出力のリトライ処理を実現することができる。また、データ入出力をやり直す判断や処理に変化が生じても、ブロックデータ管理部を変更するだけで解決でき、他の階層に影響を与えることがない。他の階層に影響の出ないような構成により、ドキュメント処理装置の開発を効率よく行うことが可能となる。

次に、本発明の実施形態について図面を参照して説明する。

図１には、本実施形態におけるドキュメント処理装置の接続構成が示されている。

図１に示すように、ドキュメント処理装置は、ＣＰＵ（Central Processing Unit）１と、画像バス２と、ＲＯＭ（Read Only Memory）３と、ＲＡＭ（Random Access Memory）４と、ＮＶＲＡＭ５と、ネットワーク６と、通信制御部７と、パネル制御部８と、操作パネル９とエンジン制御部１０と、スキャンプリントエンジン１１と、ディスクドライバ１２と、記憶装置１３と、モデム１４とから構成されている。

次に、図１の接続構成および各ブロックの説明をする。

ドキュメント装置は、マイコンを主体として各部を集中的に制御するＣＰＵ１を内蔵している。ＣＰＵ１は、コンピュータの中で各装置の制御やデータの計算から、加工を行う中枢部分である。メモリに記憶されたプログラムを実行する装置で、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。

前記ＣＰＵ１には、画像バス２を介してプログラム等の固定データを予め格納するＲＯＭ３、各種データを書き換え自由に格納するＲＡＭ４、データを消滅させることなく格納する不揮発性ＲＡＭであるＮＶＲＡＭ５が接続されている。

前記画像バス２は、コンピュータ内部で各回路がデータをやり取りするための伝送路である。本発明では、ネットワーク６との接続を担う通信制御部７、パネル制御部８を介してユーザとのインターフェイスを司るＬＣＤタッチパネルを有する操作パネル９、エンジン制御部１０を介してイメージデータの入出力（紙原稿の読み取りと転写紙への印刷）をスキャナ部やプリンタ部に対して実行させるスキャンプリントエンジン１１、ディスクドライバ１２を介してイメージデータや制御プログラム等の記憶蓄積に利用されるＨＤＤ（Hard Disk Drive）である記憶装置１３、公衆回線等を通じて外部機器とのデータ通信を可能とするモデム１４が接続されている。

次に、図２を参照して記憶装置１３に格納されている制御プログラムについて説明する。

図２には、本実施の形態における制御プログラムのソフトウェア構造が示されている。

図２に示すように、制御プログラムは、アプリケーション層、ハードウェア層で構成された２層に大別される構造になっている。

アプリケーション層は、コピー、ファクス、スキャナ、プリンタ等の各種機能についてのアプリケーションを形成する層である。

前記アプリケーション層は、ドキュメントマネージャ２０、サービスマネージャ２１、デバイスマネージャ２２、オペレーションマネージャ２３、データベースマネージャ２４の各機能ブロックにより構成されている。

前記ドキュメントマネージャ２０は、コピー、ファクス、スキャナ、プリンタ等のシナリオに沿ってドキュメントをハンドリングするアプリケーションの中心となる機能ブロックである。

前記サービスマネージャ２１は、ドキュメントをハンドリングする際、各機能に共通して必要な機能ブロックであって、各種サービスの管理、実行を行うものである。

前記デバイスマネージャ２２は、各種デバイスの管理、実行を行うものであって、スキャナ部１５、プリンタ部１６、画像バス２等のデバイス動作を決定する機能ブロックである。

前記オペレーションマネージャ２３は、前述した操作パネル９の制御する機能ブロックであって、ＬＣＤタッチパネルのボタンの表示、ボタンオペレーションのノーティファイ・アラートの通知等を行うものである。

前記データベースマネージャ２４は、フォント、定型フォーム、ファクシミリ受信履歴、利用履歴等の永続データの維持、管理等を行う。

ハードウェア管理層は、ＣＰＵ１により制御可能なデバイスを保持し、各デバイスの駆動制御を実行させるための各種機能ブロックによって構成されている層である。

制御可能なデバイスとして、スキャナ部１５、プリンタ部１６、画像バス２、ＲＯＭ３、ＲＡＭ４、ＮＶＲＡＭ５、通信制御部７、記憶装置１３、モデム１４等が存在する。

次に、図３、４は、本実施の形態におけるソフトウェア構造の概略図であって、図２記載のドキュメントマネージャ２０をさらに詳細化したものである。

図３に示すように、各階層にはそれぞれリクエスト、ドキュメント、ページ、ブロックデータといった管理対象が存在する。

例として、コピーを実行したときの各階層の管理対象を図４に示す。

コピーを実行する際、まずリクエスト管理部からドキュメント管理部の階層へコピー情報が移行され、コピー情報が読取ドキュメントから読取ページへ、また、印刷ドキュメントから印刷ページへと移る。

次に、ドキュメント管理部に蓄積された情報がブロックデータ管理部の階層へ移され、読取ページ情報がスキャナ部からのブロックデータへ分散され、また印刷ページ情報がプリンタ部へのブロックデータへ分散される。これによりコピーが実行され、リトライを階層化で対応することができる。

次に、図５には、本実施の形態におけるドキュメント管理部から問題発生が通知された際の処理フローが示されている。

はじめに、ドキュメント管理部からリクエスト管理部へ、ドキュメントの問題が発生したという通知がされる。

次に、その通知に対して、リクエスト管理部からドキュメント管理部へ要求を変更して継続する、または処理を中止するという通知がされる。

この例として、メモリフルで、これ以上原稿の読み取りが継続できないときの処理フローを図６に示す。

まず、ドキュメント管理部からリクエスト管理部へ、メモリが一杯でこれ以上読取を継続できないという通知がされる。

次に、その通知に対して、リクエスト管理部からドキュメント管理部へ、読み取ったところまで印刷する、または処理を中止するという通知がされる。以上により、リクエスト単位にリトライすることができる。

次に、図７には、本実施の形態におけるブロックデータ管理部から問題発生が通知された際の処理フローが示されている。

まず、ブロックデータ管理部からドキュメント管理部へ、ブロックデータの入出力で問題発生したという通知がされる。

次に、その通知に対して、ドキュメント管理部からリクエスト管理部へ、ドキュメントの入出力で問題が発生したという通知、あるいは、ドキュメント管理部からブロックデータ管理部へ再度処理を実行するという通知がされる。

この例として、回線使用中で、処理装置が継続できないときの処理フローを、図８に示す。

まず、ブロックデータ管理部からドキュメント管理部へ、回線使用中でブロックデータが送信できないという通知がされる。

次に、その通知に対して、ドキュメント管理部からリクエスト管理部へ、ドキュメントの送信が実行できないという通知、あるいは、ドキュメント管理部からブロックデータ管理部へ、再度送信を実行するという通知がされる。以上により、ドキュメントの入出力単位にリトライすることができる。

次に、図９には、本実施の形態における機器から問題発生が通知された際の処理フローが示されている。

まず、機器からブロックデータ管理部へ、機器の処理で問題が発生したという通知がされる。

次に、その通知に対して、ブロックデータ管理部からドキュメント管理部へ、ブロックデータの入出力で問題が発生したという通知、あるいは、ブロックデータ管理部から機器へ、再度処理を実行するという通知がされる。

この例として、回線が混んでいて、データパケットがうまく送れなかったときの処理フローを図１０に示す。

まず、機器からブロックデータ管理部へ、回線が混んでいてうまくデータを送れなかったという通知がされる。

次に、その通知に対して、ブロックデータ管理部からドキュメント管理部へ、ブロックデータの送信ができなかったという通知、あるいは、ブロックデータ管理部から機器へ、データの再送を実行するという通知がされる。以上により、データの入出力単位にリトライすることができる。

本発明の一実施形態のドキュメント処理装置の接続構成図である。本発明の一実施形態の制御プログラムのソフトウェア構造を示す説明図である。本発明の一実施形態のソフトウェア構造の概要図である。本発明の一実施形態の図３におけるコピーを実行した際の各階層の管理対象図である。本発明の一実施形態のドキュメント管理部から問題発生が通知された際の処理フローである。本発明の一実施形態の図５におけるメモリフルとなった際の例を示す処理フローである。本発明の一実施形態のブロックデータ管理部から問題発生が通知された際の処理フローである。本発明の一実施形態の図７における回線使用中となった際の例を示す処理フローである。本発明の一実施形態の機器から問題発生が通知された際の処理フローである。本発明の一実施形態の図９における回線が混んでいた際の例を示す処理フローである。

符号の説明

１ＣＰＵ
２画像バス
３ＲＯＭ
４ＲＡＭ
５ＮＶＲＡＭ
６ネットワーク
７通信制御部
８パネル制御部
９操作パネル
１０エンジン制御部
１１スキャンプリントエンジン
１２ディスクドライバ
１３記憶装置
１４モデム
１５スキャナ部
１６プリンタ部
２０ドキュメントマネージャ
２１サービスマネージャ
２２デバイスマネージャ
２３オペレーションマネージャ
２４データベースマネージャ

Claims

ユーザがリクエストする処理の単位を扱うリクエスト管理部と、ドキュメント／ページという単位を扱うドキュメント管理部と、ドキュメント／ページを構成する最小のデータ単位（ブロックデータ）を扱うブロックデータ管理部とを備えた３階層から構成されるドキュメント処理装置であって、
画像データを入出力する入出力手段と、
画像データを含むドキュメント情報およびページ情報を画像入出力する装置で操作する操作手段と、を有し、
前記ドキュメント管理部は、
ドキュメントの問題の発生を前記リクエスト管理部に通知する手段を有し、
前記リクエスト管理部は、
前記ドキュメント管理部から前記ドキュメントの問題の発生の通知を受けたときに、要求の変更または処理の中止のいずれか一方を前記ドキュメント管理部に通知する手段を有し、
前記ブロックデータ管理部は、
前記ブロックデータの入出力の問題の発生を前記ドキュメント管理部に通知する手段を有し、
前記ドキュメント管理部は、
前記ブロックデータ管理部から前記ブロックデータの入出力の問題の発生の通知を受けたときに、前記リクエスト管理部への当該ブロックデータの入出力の問題の発生の通知または前記ブロックデータ管理部への再度処理の実行の通知のいずれか一方を行う手段を有することを特徴とするドキュメント処理装置。
前記ブロックデータ管理部は、機器の処理で問題が発生したという通知を当該機器から受けたときに、前記ドキュメント管理部への前記ブロックデータの入出力で問題が発生したという通知または、
前記機器への再度処理を実行するという通知のいずれか一方を行う手段を有することを特徴とするドキュメント処理装置。