JP2014175978A - 情報処理装置、その制御方法及びプログラム - Google Patents

Abstract

【課題】適切な形式のビジネス文書を自動的に配信可能にする。
【解決手段】文書データに所定の処理を施す配信サーバ１００には、前記文書データの種別を特定するデータ種別特定部１１５と、前記文書データの種別に応じて設定される、定型フォーマット文書の構成に関する条件情報に基づいて、特定した前記文書データの種別に応じたデータ処理を前記文書データに対して実行するデータ処理部１２０と、を備える文書チェックプラグイン１１１がインストールされている。
【選択図】図３

Description

本発明は、情報処理装置、その制御方法及びプログラムに関し、特に、適切な形式のビジネス文書を自動的に配信可能にする技術に関する。

データ配信ソリューション分野においては、例えば、特許文献１に記載されているような技術が従来知られている。特許文献１には、複合機（画像形成や画像読取やファクシミリ送信などの複数の機能を組み合わせて利用できる装置のことを指す。本願においても同じ。）がネットワークでつながった配信サーバに文書データを送信し、配信サーバでワークフロー定義にしたがった文書データへの画像処理を実行して配信する技術が記載されている。

このようなデータ配信ソリューションは、複合機に入力された文書に対してフォーマット変換や文書プロパティの追加や変更を行い、他の文書管理サーバに配信するサービスである。このサービスにおける従来技術にておいては、入力データへの加工処理として画像のフォーマット変換や白紙除去、画像補整、ＯＣＲ（Optical Character Recognition）処理など、画像に対して処理を行うことが一般的であった。

しかしながら、上記従来技術においては、複合機のスキャナ等で文書を読み取った文書データに対する画像処理を実行することについては記載されているが、文書データの構成を適切に編集する機能を提供するものではない。

例えば、送り手へ契約書や発注書などを送る場合、送付状を追加する必要があったり、入力データの順序を変える必要があったりするなど、適切なビジネス文書の形式である必要がある。

データ配信サービスに入力される文書データに、ページの並び順があらかじめ定められた所定の様式に沿っていなかったり、余計なページがあったり、必要なページがなかったりすると、ビジネス文書として不適切な形式で出力されてしまい、ユーザに不利益を及ぼす可能性がある。

本発明は、上記実情に鑑みてなされたものであって、適切な形式のビジネス文書を自動的に配信可能にすることをを目的とする。

上記目的を達成するために本発明の一態様は、文書データに所定の処理を施す情報処理装置であって、前記文書データの種別を特定するデータ種別特定部と、前記文書データの種別に応じて設定される、定型フォーマット文書の構成に関する条件情報に基づいて、特定した前記文書データの種別に応じたデータ処理を前記文書データに対して実行するデータ処理部と、を備えることを特徴とする。

本発明によれば、適切な形式のビジネス文書を自動的に配信可能にすることが可能となる。

本発明の第１の実施形態に係るシステム構成を例示するブロック図である。 上記実施形態に係る配信サーバ１００の構成を示すブロック図である。 上記実施形態に係る文書チェックプラグイン１１１の機能構成を示すブロック図である。 上記実施形態に係る条件情報のデータ構成例を示す図である。 上記実施形態の全体動作の流れを示す図である。 上記実施形態に係る文書チェックプラグイン１１１の処理の流れを示すフローチャート図である。 上記実施形態に係るデータ削除部１２２の処理の流れを示すフローチャート図である。 上記実施形態に係るデータソート部１２４の処理の流れを示すフローチャート図である。 上記実施形態に係るデータ追加部１２１の処理の流れを示すフローチャート図である。 上記実施形態に係るデータ確認部１２３の処理の流れを示すフローチャート図である。 上記実施形態による文書データの編集例（その１）を示す図である。 上記実施形態による文書データの編集例（その２）を示す図である。 本発明の第２の実施形態に係るワークフロー例を示す図である。 上記実施形態によるワークフロー例と文書データの編集例を示す図である。

以下、本発明の実施形態について、図面を参照しながら説明する。

＜第１の実施形態＞
図１に、本実施形態に係るシステム構成を例示する。図１中の配信サーバ１００によりデータ配信ソリューションが提供される。配信サーバ１００が実行されるコンピュータないし電子機器としては、具体的には、図１（ａ）に示すように、文書配信サーバ１１が利用できる。あるいは、図１（ｂ）に示すように、ＭＦＰ（Multi-Functional Peripherals：複合機）１４が利用できる。

文書配信システム１は、図示のように、ネットワークを介して互いに通信可能に接続する文書配信サーバ１１、ファイルサーバ１２、メールサーバ１３、ＭＦＰ１４、管理者端末１５、利用者端末１６を有する。図１（ａ）は、配信サーバ１００をネットワークホストとして独立させた構成例であり、図１（ｂ）は、配信サーバ１００の機能をＭＦＰ１４が備えた場合の構成例である。本発明はいずれの構成によっても実現でき、また、配信サーバ１００の機能の一部のみをＭＦＰが備えるような構成であってもよい。

配信サーバ１００から配信された文書データを、ファイルサーバ１２は、蓄積する。メールサーバ１３は、電子メールに添付するなどして指定された送信先に送信する。管理者端末１５と利用者端末１６は、例えば汎用のパーソナルコンピュータやＰＤＡ、タブレット端末、携帯端末等の情報処理装置を利用できる。

ＭＦＰ１４は、本実施形態においては、スキャン機能、すなわち画像読取の機能を有するものであるが、本発明において、ＭＦＰ１４は一例であり、ワークフロー処理の対象となる入力データを生成する入力装置の一例である。入力データとしては、文書（原稿）をスキャナで読み取り生成された画像データだけでなく、カメラ等の撮像により読み取られて生成された画像データや、所定のフォーマットデータ（例えば帳票フォーマット等）に対して値が入力された電子データであってもよい。つまり、入力データ（ワークフロー処理の対象となる処理対象データ）を生成する入力装置であれば、ＭＦＰ１４に限らず、カメラ機能付の携帯端末や、ＰＣ等の情報処理装置であってもよい。

図２に、本実施形態に係る配信サーバ１００の構成を示す。図示のように、配信サーバ１００は、機能ブロックとして、ワークフロー制御部１０１、ジョブ受信部１０２、ジョブ取得部１０３、ワークフロー設定部１０４、ジョブキュー保持部１０５、画面定義情報保持部１０６、ワークフロー定義情報保持部１０７を有し、プラグインとして、各種の処理プラグイン１１０と文書チェックプラグイン１１１を備える。

ワークフロー制御部１０１は、配信サーバ１００の各プラグインを用いて実行するワークフロー処理全体を制御する。ＭＦＰ１４や利用者端末１６から送信される「ワークフロー実行要求」は、ジョブ受信部１０２により受信され、ジョブ受信部１０２はジョブキュー保持部１０５のジョブキューにワークフロー実行要求（実行ジョブ）を登録する。ジョブ取得部１０３は、ジョブキュー保持部１０５のジョブキューからジョブを取得し、ワークフロー制御部１０１に取得したジョブに基づくワークフローの実行を要求する。実行されるワークフローの定義（一連の処理の順番の定義）は、ワークフロー設定部１０４により設定され、設定登録されたワークフローの定義情報が、ワークフロー定義情報保持部１０７に保持される。ワークフローの設定は、例えば管理者の利用者端末１６によって行われ、ワークフロー設定部１０４は管理者の利用者端末１６に、ワークフロー設定用のツール（ワークフロー設定用ＵＩ画面等）を提供する。ＭＦＰ１４や利用者端末１６から送信される「ワークフロー実行要求（実行ジョブ）」には、ワークフロー定義情報保持部１０７が保持するワークフロー定義情報（１以上のワークフロー定義が設定された情報）の中から選択された所望のワークフローを指定する情報と、ワークフローを実行するときの各種設定値（例えば配信先等）が設定された情報が含まれる。画面定義情報保持部１０６は、ＭＦＰ１４や利用者端末１６においてワークフロー実行要求の内容を設定するための各種画面情報を保持し、ＭＦＰ１４や利用者端末１６等、ワークフロー処理を実行したい機器からのアクセスに応じて、画面情報が提供される。ジョブ取得部１０３が必要なジョブを取得する。

各種処理プラグイン１１０及び文書チェックプラグイン１１１は、ワークフローにおける各処理を実行するプラグインモジュールである（つまり、文書チェックプラグイン１１１も処理プラグインの１つである。）。定義されるワークフローには、各種の処理プラグインの中から１以上の処理プラグインを用いて実行される処理の順序が規定されている。ワークフロー制御部１０１は、実行ジョブの内容に基づき、ワークフローの順番に沿って、処理プラグイン１１０か文書チェックプラグイン１１１に入力データや、入力データに処理を施した処理後のデータと、各処理における設定値等を入力し、各プラグインは処理内容と設定値（設定値は必須ではない。）に基づいてデータ処理を実行し、処理後のデータをワークフロー制御部１０１に返す。処理プラグイン１１０の例としては、例えば、ＯＣＲ、ノイズ除去、バーコード読取、メール配信、ファイル蓄積、ファイル形式変換などが挙げられ、設定値の例としては、処理を施す領域に関する情報（文書データのどの部分を処理対象とするかを設定する情報）、配信先、変換したいデータ形式等がある。

例えば、ある「ワークフロー実行要求」のワークフローが、ＭＦＰ１４でスキャンした画像をＯＣＲしてバーコードを読み取り、バーコードから得られるＵＲＩに配信すると定義されていた場合、ＯＣＲ、バーコード読取、メール配信の３つのプラグインにその順番で処理を実行させる。

本実施形態の特徴的な処理動作は、主として文書チェックプラグイン１１１により行われるが、一部、他の処理プラグイン１１０を利用してもよい。また、図２の例では文書チェックプラグイン１１１が１つのプラグインとなっている例が示されているが、複数のプラグインとなる実装を行ってもよく、各プラグインを利用したワークフローの実行形態はあくまで一例であり、全ての処理を１つのプログラムモジュールが実行するようになっていてもよい。つまり、プラグインによる実装は、顧客が、複数あるプラグインの中から所望のプラグインを購入し、配信サーバ１００にインストールすることで、各顧客に応じた配信システムを構築できるという利点の提供に貢献しているが、提供方法はこれに限らない。

図３に、文書チェックプラグイン１１１の機能構成を示す。文書チェックプラグイン１１１は、図３に示すように、機能ブロックとして、条件設定部１１２、追加データ登録部１１３、定型データ登録部１１４、データ種別特定部１１５、データ処理判定部１１６、データ処理部１２０を備える。また、データ処理部１２０は、データ追加部１２１、データ削除部１２２、データ確認部１２３、データソート部１２４を有する。

条件設定部１１２は、管理者がワークフロー設定時に、この文書チェックプラグイン１１１を選択した場合に（定義するワークフローの処理の中に本プラグインによる処理を含めるよう選択された場合に）、条件情報を設定するための機能部である。追加データ登録部１１３は、管理者がワークフロー設定時に表紙データ等の追加データを登録するための機能部である。条件情報、表紙データ等は、ワークフロー定義情報保持部１０７に記憶される。この記憶情報は、データ追加部１２１などが処理を実行するときに利用する。

定型データ登録部１１４は、追加データ登録部１１３と同じ要領で、データ削除及びソートの際の判定に利用される定型データを登録する。ソートの判定にも利用されるため、定型データは順番が分かるように登録される。定型データは、ワークフロー定義情報保持部１０７に記憶される。

データ種別特定部１１５は、「見積書」「請求書」などといった定型フォーマットの文書データ種別を特定する。特定の方法については、例えば、配信サーバ１００が処理プラグイン１１０を利用してＯＣＲやバーコード読取といった処理を行うことによって行ってもよい。また、罫線分析や埋込情報の抽出等によって特定しても良いし、ＭＦＰ１４や利用者端末１６からワークフロー実行要求を受信する際に定型フォーマットを特定する情報を受信し、その情報に基づいて特定してようにしてもよい。データ処理判定部は、追加、削除、確認、ソートなどのデータ処理部１２０の処理を実行するかどうかを、データ種別と条件設定部１１２に設定された条件情報に基づいて判定する。また、判定結果に基づく処理の実行をデータ処理部１２０に要求する。

図４に、条件情報のデータ構成例を示す。条件情報は、管理者が管理者端末１５を用いて配信サーバ１００にアクセスして図４に示すような情報を設定する。条件情報は、図示のように、データ種別ごとに設定される。データ種別は「見積書」「請求書」といった単位に限らず、「請求書」の中でも「請求書１」と「請求書２」のように２種類の請求書のそれぞれに応じて追加処理を行う条件情報も設定できる。また、条件情報は、定型フォーマット文書の構成に関する条件が設定された情報であり、定型フォーマット文書を構成するページデータを特定する、定型フォーマット文書を構成するページデータの順番を特定する、定型フォーマット文書を構成する固定ページデータ（利用者に応じて編集されることなく用いられるページデータ）を追加（挿入）する、定型フォーマット文書を構成するページデータ以外のページデータを含ませないようにする、といった目的のために設定される情報である。

図５に、本実施形態の全体動作の流れを示す。図５はデータの流れに注目した模式図である。図５に示すように、利用者はオペレーションパネル等の操作表示部やカードリーダー等を利用して認証情報を入力する等の処理を行い、ＭＦＰ１４にログイン処理を行う（Ｓ１０１）。ＭＦＰ１４において利用者のログインが許可されると、オペレーションパネル（利用者端末１６からログインした場合には利用者端末のタッチパネルディスプレイ等の操作表示部）の画面にどのようなアプリケーションを利用するかプロンプトが開くので、利用者は選択する（Ｓ１０２）。選択できるアプリケーションはＭＦＰ１４にインストールされているアプリケーションや、ネットワークを介して接続するサーバ等の装置を利用して実行できるアプリケーションであり、ＭＦＰ１４はアプリケーションを選択できるための（選択画面を表示するための）情報を保持している。利用者が画面から配信アプリケーションを利用するための選択ボタンとして「配信アプリ」を選択すると、認証された利用者のユーザＩＤなどとともに、ＭＦＰ１４から配信サーバ１００にアクセスが行われる（Ｓ１０３）。

次に、アクセスに応じてフロー設定画面が配信サーバ１００からＭＦＰ１４に送信される（Ｓ１０４）。ユーザはフロー設定画面を用いて、定義されている１以上のワークフローの中から実行したいワークフローを選択する（Ｓ１０５）。その後、利用者が選択したワークフローについて、必要に応じて各種の設定値を設定し、「実行」ボタンを押下してワークフローの実行を指示すると（Ｓ１０６）、利用者がＭＦＰ１４の原稿読取部に載置した原稿のスキャン（スキャナによって原稿を読み取り、画像データを生成する処理）が始まる（Ｓ１０７）。

ＭＦＰ１４は、原稿をスキャンした画像データとともに、選択されたワークフローに係るワークフロー実行要求を、配信サーバ１００に送信する（Ｓ１０８）。配信サーバ１００は受信した画像データとワークフロー実行要求に基づきワークフローを実行し、配信先に配信するデータ（配信データ）を作成する（Ｓ１０９）。配信サーバ１００は、受信した画像データとワークフロー実行要求に基づいて、作成された配信データをファイルサーバ１２やメールサーバ１３などの配信先に送信する（Ｓ１１０）。

次に、図６に、配信サーバ１００の文書チェックプラグイン１１１が実行する処理の流れを示す。図６の各処理は、上述したように、実行するワークフローの一部あるいは全部として文書チェックプラグイン１１１が定義され、ワークフロー実行要求として実行が要求された場合に、図５のＳ１０９において行われる文書チェックプラグイン１１１の処理の詳細にあたる。まず、ワークフロー制御部１０１が、ジョブ取得部１０３によりジョブキュー保持部１０５から取得されたジョブを受け取り、文書チェックプラグイン１１１が、ワークフロー制御部１０１から処理の実行要求を受信することで、文書チェックプラグイン１１１の処理が開始する。

すると、文書チェックプラグイン１１１のデータ種別特定部１１５は、入力されたジョブの文書データ（入力データや、他のプラグインが入力データに処理を施した処理データ）の種別を特定する（Ｓ２０１）。特定の方法については、上述した用に種々の方法の中から適切な方法を選択することができる。データ種別特定部１１５により文書データの種別が特定できない場合はエラーとなる。

次に、データ処理判定部１１６が特定した種別に対応するデータ処理の内容を判定する（Ｓ２０３）。実行すべきデータ処理は、種別ごとに条件と処理内容が設定されて、条件情報として保持されている（図４）。特定した種別が例えば「見積書」であれば、データ処理判定部１１６は、「見積書」に係るデータ処理を行う者と判定する。判定できない場合はエラーとなる。

データ処理部１２０は、判定結果に基づき、文書データに対するデータ処理を条件に従って実行していく（Ｓ２０５〜Ｓ２０８、図７〜図１０）。図示のように、いずれも、処理を行うか否かのフラグが立っているか否かを確認して立っている場合に処理を行う。好ましくは、削除処理、ソート処理、データ（ページ）追加処理、ページ数確認処理の順番に行うことが考えられるが、処理の順番は、適切に条件情報やデータ処理を設定することで入れ替えが可能である。

図７はデータ削除部１２２の処理の流れを示すフローチャート図である。図８はデータソート部１２４の処理の流れを示すフローチャート図である。図９はデータ追加部１２１の処理の流れを示すフローチャート図である。図１０はデータ確認部１２３の処理の流れを示すフローチャート図である。

図７において、まず、種別に対応する定型フォーマットを取得する（Ｓ２０５−１）。定型フォーマットは、あらかじめ定型データ登録部１１４（第１の登録部）によりワークフロー定義情報保持部１０７に登録されている。次に、定型フォーマットと文書データを照合する（Ｓ２０５−２）。なお、照合の方法については既知の技術を用いればよいが、例えば、罫線によって入力フォームが決まっている定型フォーマットであれば、罫線の構造が一致するかどうかを照合すればよいし、特定の領域に特定のキーワードがあらかじめ入力されている定型フォーマット（例えば定型フォーマットの１ページ目の領域Ａには「見積書」の文字が、２ページ目の領域Ｂには「見積内容」の文字が記入されている等である。）であれば、定型フォーマットと文書データそれぞれの特定領域に対するキーワードを照合する方法でもよい。つまり、定型フォーマットの原稿やフォームデータを編集した後に、ＭＦＰ等から入力されて作成された文書データであれば、定型フォーマットの備えるフォームやキーワード等といった特徴を利用することで、定型フォーマットと文書データの照合を行うことができる。照合の結果、あらかじめ定められている定型フォーマットに合致しないフォーマットで記載されたページがあれば（定型フォーマットを構成する各ページの定型フォーマットデータのいずれとも照合しない文書データのページデータがあれば）、該当ページを削除する（Ｓ２０５−４）。

図８においても同じく、まず、種別に対応する定型フォーマットを取得する（Ｓ２０６−１）。次に、定型フォーマットと文書データを照合する（Ｓ２０６−２）。照合の結果、あらかじめ定められている定型フォーマットの順に文書データをソートする（Ｓ２０６−３）。

図９においては、まず、種別に対応する追加データを取得する（Ｓ２０７−１）。追加データは、追加データ登録部１１３（第２の登録部）によりワークフロー定義情報保持部１０７に登録されている。次に、取得したデータを条件情報の「追加処理」で設定される追加位置に追加する（Ｓ２０７−２）。追加するデータは、典型的には、例えば見積書の表紙ページなどが考えられ、表紙ページを登録していれば、先頭追加が条件として設定されることが考えられるが、この例に限定しなくてもよい。なお、本処理において、追加データを追加するか否かを、既に文書データの中に追加データが存在しているか否かによって判定してもよい。つまり、利用者が、表紙ページ等を入れ忘れて入力データが作成される場合もあれば、既に表紙ページが含まれている場合もあり、入力データに既に追加データに該当するページデータが含まれていた場合に追加データを追加すると重複してしまうため、このような判定によってチェックを行った後、追加データが含まれていない場合に追加することで、ユーザの利便性がより向上する。具体的には、文書データの各ページデータと追加データとを照合し（照合の方法は上述したような方法を採用すればよい）、追加データに該当するページデータの存在有無を判定する。判定の結果、存在する場合には、該当するページデータが、条件情報の「追加処理」で設定された位置にあるか否かを判定する。例えば、先頭追加で設定されていれば、該当するページデータが文書データの先頭ページかどうかを判定する。設定された位置にあれば、図９の追加処理フローは終了し、設定された位置になければ該当するページデータを設定された位置に移動することで追加処理フローは終了する。文書データの各ページデータの中に追加データに該当するページデータが存在しない場合には、取得した追加データを条件情報の「追加処理」で設定された位置に追加することで追加処理フローは終了する。

図１０においては、まず、ページ数が定型フォーマットと一致しているか否かを確認し、一致していない場合はエラーを返す（Ｓ２０８−２）。

＜具体例＞
図１１に、本実施形態による文書データの編集例（その１）を示す。図示の例は、図４のような条件情報が設定されている場合における条件「見積書」の場合の例である。Ｓ１０８受信時の文書データが５枚からなる文書データであったとする。このうち３枚目の「文３」が定型フォーマット外であるため、削除処理により取り除かれる（削除処理後文書データ）。

同様に、ソート処理により定型フォーマットと文書データの照合が行われてソートが行われる（ソート処理後文書データ）。ここでは、４枚目の文書データ「文４」が定型フォーマットの２ページ目のデータ「定２」と照合し、２枚目の文書データ「文２」が定型フォーマットの３ページ目のデータ「定３」と照合したことから、ページ順序が変更されている。また、追加処理により追加データの追加が行われる（追加処理後文書データ）。追加位置は、図４で指定されているとおり、文書の先頭であるため、図１１に示すような追加処理後文書データが得られる。

図１２に、本実施形態による文書データの編集例（その２）を示す。図示の例は、図４のような条件情報が設定されている場合における条件「請求書２」の場合の例である。ただし、本例では、削除処理が「ＯＦＦ」となっているため、定型フォーマット以外の文書データ（３枚目の文書データ「文３」）も削除はされず残っている。ただし、定型フォーマットとの照合によって該当するページデータを１まとまりの該当データとして扱い、追加データの追加処理については該当データに対する追加位置に追加されている。そして、定型フォーマット以外の文書データ（３枚目の文書データ「文３」）はその後に続くページデータとして扱われる。

文書データのすべてのページが定型フォーマットで作成されないような場合、そのようなページを残す処理を行うことで、例えば、定型フォーマットを利用して作成した原稿等の入力データの他に、任意のコメントを記述した入力データも残したいといったような利用法に適切に対応することができる。

＜第２の実施形態＞
本実施形態は、上記実施形態に加えて、文書データの種別の特定に関して、前処理を行い、前処理の結果から特定する。また、実行結果のは新についても説明する。

図１３に、本実施形態のワークフロー例を示す。本実施形態においては、図示のように、ＯＣＲ処理やバーコード処理や埋込データ抽出処理などの前処理を行い、上記実施形態で説明したような文書チェックプラグイン１１１によるチェックを行い、最後に配信処理を行うワークフローが行われる。前処理や配信処理は、各種の処理プラグイン１１０により行われる。このようなプラグインを前処理部、配信部と呼ぶ。

前処理として、他には、データ分割プラグインによるデータ分割処理がある。データ分割プラグインは、あらかじめ定められたページ分割の設定（例えば、「３ページごとに分割する」など）をする機能と、この設定に従って実際にデータを分割する機能を備える。

図１３に示すように、データ種別の特定のための前処理はいくつかあり、図示のものの他にも、指定するワークフローから特定する前処理であってもよい。例えば、ＭＦＰ１４のオペレーションパネルのワークフロー選択画面において（Ｓ１０５）、「見積書」「請求書１」「請求書２」などのワークフロー名で定義されたワークフローをリストアップしておく。この場合、ユーザが選択したワークフローから、種別が特定される。

図１４に、ワークフロー例と文書データの編集例を示す。図１４では、前処理として、前述のデータ分割プラグインを使ったデータ分割処理と、ＯＣＲプラグインを使ったＯＣＲ処理がワークフローに設定されている。配信サーバ１００が文書データを受信したときは６ページのデータだったものが、３ページごとの分割をする設定のデータ分割処理により、前３ページと後３ページに分割される。

次に、ＯＣＲ処理により、文書データの種別が、「請求書１」と「請求書２」であることが特定される。その後、前の文書データと後ろの文書データそれぞれに対して文書チェックプラグイン１１１による文書チェックが行われる。これらの処理の基づき作成された配信データは、それぞれ「見積書１」の文書データと「見積書２」の文書データとして扱われ、配信処理を実行する処理プラグイン１１０は、各見積書に応じた配信先へと配信データの送信（配信）を行う。図１４の例では、ファイルサーバ１２に設定されている「見積書１」用のデータフォルダと「見積書２」用のデータフォルダに、それぞれの文書データが配信される。

＜作用・効果＞
上記実施形態にて開示された技術的思想によれば、受信した文書データがビジネス文書として体裁が整っていなかったり不備があったりする場合であっても、文書データの種別を特定して、その種別に適した文書になるようにチェックを行うため、適切な形式のビジネス文書の自動的な配信が可能になると言うことができる。

とりわけ、上記実施形態によれば、利用者は、文書の並び順のチェックが不要である。ＭＦＰ１４に読み取らせる原稿の並び順を意識する必要がない。また、余計なページが原稿に挟まっていても取り除く必要がない。また、表紙が自動的に付加される。

１ 文書配信システム
１１ 文書配信サーバ
１２ ファイルサーバ
１３ メールサーバ
１４ ＭＦＰ
１５ 管理者端末
１６ 利用者端末
１００ 配信サーバ
１０１ ワークフロー制御部
１０２ ジョブ受信部
１０３ ジョブ取得部
１０４ ワークフロー設定部
１０５ ジョブキュー保持部
１０６ 画面定義情報保持部
１０７ ワークフロー定義情報保持部
１１０ 処理プラグイン
１１１ 文書チェックプラグイン
１１２ 条件設定部
１１３ 追加データ登録部
１１４ 定型データ登録部
１１５ データ種別特定部
１１６ データ処理判定部
１２０ データ処理部
１２１ データ追加部
１２２ データ削除部
１２３ データ確認部
１２４ データソート部

特開２００９−１７７２３１号公報

Claims (10)

1. 文書データに所定の処理を施す情報処理装置であって、
   前記文書データの種別を特定するデータ種別特定部と、
   前記文書データの種別に応じて設定される、定型フォーマット文書の構成に関する条件情報に基づいて、特定した前記文書データの種別に応じたデータ処理を前記文書データに対して実行するデータ処理部と、を備えることを特徴とする情報処理装置。
2. 前記データ処理部は、実行するデータ処理として、前記条件情報に定められた所定のページを追加する処理、前記条件情報に定められた定型フォーマットでないページを削除する処理、前記条件情報に定められた定型フォーマットの順番にページをソートする処理の少なくともいずれか１つを含むことを特徴とする請求項１に記載の情報処理装置。
3. 定型フォーマット文書を構成するページデータを登録する第１の登録部を備え、
   前記データ処理部は、定型フォーマット文書を構成するページデータに基づき、前記文書データから、定型フォーマットに基づく文書データ以外の文書データを削除することを特徴とする請求項１又は２に記載の情報処理装置。
4. 定型フォーマット文書を構成する追加のページデータを登録する第２の登録部を備え、
   前記データ処理部は、特定した種別に対応する定型フォーマットを構成する前記追加のページデータが前記文書データに含まれていない場合に、前記文書データに前記追加のページデータを追加することを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記データ処理部による前記追加のページデータの追加処理は、前記文書データに前記追加のページデータが含まれているか否かに応じて実行し、かつ、前記追加のページデータを追加する位置に関する前記条件情報に基づいて、前記文書データのうち前記定型フォーマット文書を構成する文書データに対して前記追加のページデータを追加又は移動することを特徴とする請求項４に記載の情報処理装置。
6. 前記文書データに前処理を行う前処理部を備え、
   前記データ種別特定部は、前記前処理の結果に基づいて種別の特定を行い、
   前記前処理が前記文書データの画像から情報を抽出する処理を含むことを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記前処理が前記文書データのページ分割を行う処理を含むことを特徴とする請求項６に記載の情報処理装置。
8. 前記データ処理部の実行結果を配信する配信部を備えることを特徴とする請求項１から７のいずれか１項に記載の情報処理装置。
9. 文書データに所定の処理を施す情報処理装置の制御方法であって、
   前記文書データの種別を特定するデータ種別特定工程と、
   前記文書データの種別に応じて設定される、定型フォーマット文書の構成に関する条件情報に基づいて、特定した前記文書データの種別に応じたデータ処理を前記文書データに対して実行するデータ処理工程と、を含むことを特徴とする情報処理装置の制御方法。
10. コンピュータが文書データに所定の処理を施すためのプログラムであって、
    前記コンピュータに、
    前記文書データの種別を特定するデータ種別特定処理と、
    前記文書データの種別に応じて設定される、定型フォーマット文書の構成に関する条件情報に基づいて、特定した前記文書データの種別に応じたデータ処理を前記文書データに対して実行するデータ処理処理と、
    を実行させることを特徴とするプログラム。

Images