JP4306454B2 - 接続管理装置及びサービス処理システム - Google Patents

Description

本発明は、接続管理装置及びサービス処理システムにかかり、特に、紙文書を電子化して共有化を図ったワークフローを構築するサービス処理システムに好適な接続管理装置及びサービス処理システムに関する。

スキャナ、ファクシミリ装置、複写機、又はこれらを複合した複合機、パーソナルコンピュータ、メールサーバ等をネットワークで相互に接続して、紙文書と電子情報の共有化を図ったワークフローシステムが提案されている。

このようなワークフローシステムは、原稿を読み取るスキャナ、ペーパーレスＦＡＸ等の入力系からの文書ファイルを取り込み、イメージ加工、文字認識等の処理系を経て、プリンタやメールサーバ等の出力系を介して文書ファイルを外部に配信する。

通常、文書ファイルの取り込み、加工、配信等の各サービスはそれぞれ独立して行われる。このため、オペレータは、文書ファイルの取り込み、加工、配信を連続して実行したい場合は、取り込み、加工、配信のそれぞれについて所定の設定を行わなければならない。つまり、オペレータは、取り込み、加工、配信等のサービスに関するウィンドウを１つずつ開いて、所定の入力操作を行わなければならず、非常に不便であった。

このため、従来より、取り込みから配信までの一連の処理をネットワーク上でサービス連携して予め定義した順番で実行するワークフローシステムが導入されている。ワークフローシステムは、承認や回覧などオフィスで汎用的に使用されるワークフローを想定して、既存の紙ベースの業務システムをそのまま電子化することによって開発されることが多い（例えば、特許文献１、特許文献２、特許文献３を参照）。
特開２００２−９９６８６号公報 特開２００１−３２５３８９号公報 特開２００１−１９５２９５号公報

ところで、上述のようなネットワークシステムでは、サーバ型のワークフローシステムが適用され、サービスが能動的にサービスを要求する入力端末等にアクセスしてサービス対象の文書を検知して取得することをサービスの起点とする、所謂プル型配信が適用される。

このような既存のプル型配信のサーバ型のワークフローシステムをプッシュ型配信（処理対象文書と共に処理要求を行うことを起点とする）に適用し、複数のワークフローシステムを接続しようとすると、処理要求に対応したサービスを行う際に発行する各ジョブを特定するためのジョブＩＤが各システム毎に発行され、それぞれのジョブＩＤが全世界で一意ではないため、処理要求を行う入力端末側からワークフローシステムを特定することができない、という問題が発生する。

本発明は、上記問題を解決すべく成されたもので、処理の監視や中止などの操作を容易に行うことができるプッシュ型配信のサービス処理システムの接続管理装置及び当該サービス処理システムを提供することを目的とする。

上記目的を達成するために本発明は、文書データに関して所定の処理を行うサービスの処理要求に対して処理要求毎に一意な識別子を発行する発行手段によって発行された識別子と、入力端末から行われた処理要求を表す識別情報と、処理要求に応じたサービスを実行するサービス処理サーバにおける個々のサービスを特定するサービス特定情報と、を関連付けて記憶し、これら識別子、識別情報、及びサービス特定情報に基づいて、入力端末とサービス処理サーバとの接続を管理すると共に、サービス処理サーバの負荷を監視して、負荷に応じて入力端末からの処理要求を振り分けることで、入力端末からの処理要求とサービス処理サーバにおける個々のサービスの対応を取ることができるので、プッシュ型配信を適用しても処理の監視や中止などの操作を容易に行うことができる。

以上説明したように本発明によれば、プッシュ型配信を適用して処理の監視や中止などの操作を容易に行うことができる、という効果がある。

図１は、本発明の実施の形態に係わるサービス処理システム１０の概略構成を示すブロック図である。

本発明の実施の形態に係わるサービス処理システム１０は、様々なサービスやアプリケーションがネットワークを介して接続されてものである。ここで、サービスとは、外部からの要求に応じて文書に関する利用可能な機能をいう。サービスは、例えば、コピー、プリント、スキャン、ファクシミリ送受信、メール配信、レポジトリへの格納やレポジトリからの読込、ＯＣＲ（Optical Character Recognition）処理、ノイズ除去処理等、が該当し、特に限定されるものではない。

サービス処理システム１０は、具体的には、後述するドキュメントフローサービス１６が提供するサービスに対して処理要求を行う入力端末１２と、入力端末１２から送信されるドキュメントを取り込んで所定の加工を施したり、加工後のドキュメントを所定の配信先に配信したりする複数のドキュメントフローサービス１６と、入力端末１２からの処理要求を対応するドキュメントフローサービス１６へ送信するドキュメントフローサービスゲートウエイ１４と、で構成されている。また、入力端末１２、ドキュメントフローサービスゲートウエイ１４及びドキュメントフローサービス１６はそれぞれ、例えば、ＬＡＮ（Local Area Network）等のネットワークを介して接続することができる。

なお、ここでいうドキュメントとは、主に文書に関するイメージデータであるが、加工処理の状態に応じてテキストデータを含むものであってもよく、特に限定されるものではない。

また、本発明の実施の形態に係わるサービス処理システム１０は、既存のドキュメントフローサービス１６を用いてプッシュ型配信（ドキュメントフローサービス１６が受動的にドキュメントとその処理要求を受け取ることをサービスの起点とするもの）を可能としたものである。

入力端末１２は、プリント機能、スキャナ機能、及びファクシミリ機能を兼ね備えた複合機からなり、それぞれの機能を連携して処理を行うことも可能とされている。なお、入力端末１２は、複数台をドキュメントフローサービスゲートウエイ１４に接続するようにしてもよい。

入力端末１２は、ドキュメントフローサービス１６に対して処理要求を行う。詳細には、入力端末１２は、自装置で処理不可能な処理をドキュメントフローサービス１６に対して処理要求するようになっている。

具体的には、入力端末で実行可能な機能を組み合わせたサービスの内容と、ドキュメントフローサービス１６が実行可能な内容とが記述された指示書をネットワークに接続されたクライアントコンピュータ（図示省略）等によって作成し、入力端末１２に登録して実行指示をクライアントコンピュータや入力端末１２で行うことによって、入力端末１２とドキュメントフローサービス１６によるサービス連携が行われるようになっており、入力端末１２は、指示書に記述された内容に基づいて、自装置で処理可能なサービスを実行すると共に、入力端末１２で処理不能なサービスについてドキュメントフローサービス１６に処理要求を行うようになっている。

なお、処理要求は、ドキュメントフローサービス１６によるサービスを実行するための予め定められたルールに従った処理要求がなされるようになっており、処理対象のドキュメントあるいはドキュメントに対するリンク情報と共に処理要求が行われる。

ドキュメントフローサービス１６は、図２に示すようなサーバコンピュータからなり、プル型配信（ドキュメントフローサービスが能動的に入力端末などにアクセスし文書検知することをサービスの起点としたもの）が可能な既存のシステムである。

具体的には、全体を制御するＣＰＵ（Central Processing Unit）１８、ワークエリアとしてデータを一時格納するＲＡＭ（Random Access Memory）２０、ＣＰＵ１８の制御プログラム等を記憶するＲＯＭ（Read Only Memory）２２、種々の画面を表示するディスプレイ２４、ＣＤ−ＲＯＭドライブ２６を備えている。

また、ドキュメントフローサービス１６は、さらに、ドキュメントの取り込み、加工及び配信までの一連の処理を自動化／定型化するためのプログラムや種々のアプリケーション等を記憶したり読み出すハードディスク２８、文章や記号等を入力するキーボード３０、ポインティングデバイスであるマウス３２、これらが接続されたインタフェース３４、入出力ポート３６及び通信制御ユニット３８を備えている。

なお、キーボード３０は、ディスプレイ２４に様々な設定画面が表示されたときなどに、オペレータの指示する情報を直接入力するときに用いられる。また、マウス３２は、ディスプレイ２４に様々な設定画面等が表示されたときに、表示されたものを選択したり、設定指示の内容を入力するときに使用される。

ドキュメントフローサービスゲートウエイ１４は、図３に示すように、入力端末１２と複数のドキュメントフローサービス１６との間に設けられ、入力端末１２とドキュメントフローサービス１６との接続を管理する。

ドキュメントフローサービスゲートウエイ１４は、図３に示すように、入力端末１２からの処理要求を受け付ける処理要求受付部４０、ドキュメントフローサービス１６における処理状況を取得する処理状況取得部４２、処理状況取得部４２で取得した処理状況を入力端末１２に通知する処理状況通知部４４、ドキュメントフローサービス１６で行われる処理の中止や停止等の操作要求を受け付ける操作要求受付部４６、入力端末１２からの処理要求によって実行されたドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報、該ドキュメントフロー識別情報に対応するドキュメントフローサービスの各処理を特定するサービス特定情報、及びこれらを外部から一意に特定するためのチケットを関連付けて記憶管理するチケット管理部４８、及び複数のドキュメントフローサービス１６の実行を制御するドキュメントフローサービス管理部５０で構成されている。

処理要求受付部４０は、入力端末１２から要求される所望のドキュメントフローサービスを特定するドキュメントフロー識別情報を含むサービス開始要求を受け付け、ドキュメントフローサービス管理部５０を介してドキュメントフローサービス１６に対してサービスの処理指示を行う。

処理要求受付部４０によって処理要求がなされると、チケット管理部４８は、ドキュメントフローサービス１６からドキュメントフローサービス１６内のジョブＩＤを取得し、これに対応付けて全世界で一意な識別子であるＧＵＩＤ（Global Unique Identifier）等からなるチケット（要求識別子）を発行して管理する。すなわち、チケット管理部４８は、処理要求を行ったドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報、チケット（ＧＵＩＤ）及びドキュメントフローサービス特有の識別子であるジョブＩＤとを対応付けて記憶する。そして、処理状況通知部４４を介して入力端末１２が行った処理要求に対応するチケットを入力端末１２に通知する。なお、入力端末１２が複数接続されている場合には、入力端末１２を特定する情報もチケットに関連付けて記憶される。

また、入力端末１２から処理状況通知部４４を介してチケットを含む処理状況確認要求がなされた場合には、処理状況取得部４２はチケットに対応するドキュメントフローサービス識別情報及びジョブＩＤをチケット管理部４８から取得し、ドキュメントフローサービス識別情報及びジョブＩＤに基づいてドキュメントフローサービス管理部５０を介して処理状況確認を行った後、処理状況通知部４４を介して処理状況確認結果を入力端末１２に通知する。

さらに、入力端末１２から処理要求したドキュメントフローサービス１６に対して、当該処理の中止、一時停止、再開、優先順位変更等の操作要求がチケットを用いて入力端末１２から行われた場合には、操作要求受付部４６は、これを受け付けてチケット管理部４８からチケットに対応するドキュメントフローサービス識別情報及びジョブＩＤを取得し、ドキュメントフローサービス管理部５０を介して、チケットに対応するドキュメントフローサービス１６に対して、操作要求に応じた操作を行う。そして、ドキュメントフローサービス１６から操作結果を取得して入力端末１２に返信する。

一方、ドキュメントフローサービス管理部５０は、入力端末１２から処理要求がなされた場合には、入力端末１２から要求される処理要求に対応するドキュメントフローサービス１６に対して処理指示を行うと共に、ドキュメントフローサービス１６から処理指示に対応するジョブＩＤ及びドキュメントフローサービス識別情報を取得してチケット管理部４８に返信する。また、操作要求がなされた場合には、操作要求に対応するドキュメントフローサービス１６に対して操作指示を行うと共に、操作結果を取得して返信する。

また、ドキュメントフローサービス管理部５０は、複数のドキュメントフローサービス１６の負荷を監視して、負荷に応じて、入力端末１２からの処理要求の振り分けを行うようになっている。

続いて、上述のように構成されたサービス処理システム１０の処理の流れについて説明する。

まず、入力端末１２で行われる処理の流れについて説明する。図４は、入力端末１２で行われる処理の流れの一例を示すフローチャートである。

ステップ１００では、処理要求か否か判定される。すなわち、入力端末１２に登録された指示書が実行され、該指示書に記述されたサービスを行うドキュメントフローサービス１６への処理要求がなされたか否か判定される。該判定が肯定された場合には、ステップ１０２へ移行して、指示書に記述されたドキュメントフローサービス１６の処理要求がなされる。すなわち、ドキュメントフローサービスゲートウエイ１４に対して処理要求が行われる。なお、処理要求は、処理要求元（端点）の情報（例えば、ネットワーク上のアドレス等の情報など）、処理状況確認時の通知手段、及び処理要求時に使用する認証方法（例えば、暗証番号など）等を含めて出力する。

続いて、ステップ１０４では、チケットを取得したか否か判定される。該判定は、ドキュメントフローサービスゲートウエイ１４のチケット管理部４８によって発行されるチケットを受信したか否か判定することによってなされ、該判定が肯定される間で待機してステップ１０６へ移行する。

ステップ１０６では、チケットが指示書に対応して記憶され、ステップ１０８へ移行する。すなわち、チケットを用いることによって、指示書に記述されたサービスを行うドキュメントフローサービス１６の処理状況確認や操作を行うことが可能となる。

一方、ステップ１００の判定が否定された場合には、そのままステップ１０８へ移行する。

ステップ１０８では、入力端末１２から処理要求したドキュメントフローサービス１６による処理状況確認か否か判定される。該判定は、処理要求したドキュメントフローサービス１６の処理状況確認要求が入力端末１２の操作手段等を介して行われたか否かを判定することによってなされ、該判定が肯定された場合には、ステップ１１０へ移行する。

ステップ１１０では、処理要求時に取得したチケットと共に、処理状況確認が行われる。すなわち、入力端末１２から処理状況確認要求がチケットと共にドキュメントフローサービスゲートウエイ１４に出力される。なお、処理状況確認は、処理要求元（端点）の情報（例えば、ネットワーク上のアドレス等の情報など）、処理状況確認時の通知手段、及び処理要求時に使用する認証方法（例えば、暗証番号など）等を含めて出力する。

そして、ステップ１１２では、ドキュメントフローサービスゲートウエイ１４から処理状況確認結果を取得したか否か判定される。該判定はドキュメントフローサービスゲートウエイ１４の処理状況通知部４４から処理状況確認結果が通知されたか否かを判定することによってなされ、該判定が肯定されるまで待機してステップ１１４へ移行する。

一方、ステップ１０８の判定が否定された場合には、そのままステップ１１４へ移行する。

ステップ１１４では、入力端末１２から処理要求したドキュメントフローサービス１６による処理に対する操作要求が行われたか否か判定される。該判定は、入力端末１２から処理要求したドキュメントフローサービス１６の処理に対する操作要求が入力端末１２の操作手段等を介して行われたか否かを判定することによってなされ、該判定が肯定された場合には、ステップ１１６へ移行する。なお、操作要求は、操作要求元（端点）の情報（例えば、ネットワーク上のアドレス等の情報など）、操作要求時の通知手段、及び操作要求時に使用する認証方法（例えば、暗証番号など）等を含めて出力する。

ステップ１１６では、処理要求時に取得したチケットと共に、操作要求が行われる。すなわち、入力端末１２から処理要求したドキュメントフローサービス１６に対して、中止、一時停止、再開、優先順位変更等の操作要求がチケットと共にドキュメントフローサービスゲートウエイ１４に出力される。

そして、ステップ１１８では、ドキュメントフローサービスゲートウエイ１４から操作結果を取得したか否か判定され、該判定が肯定されるまで待機して一連の処理を終了し、はじめから上述の処理が繰り返される。

一方、ステップ１１４の判定が否定された場合には、ステップ１２０へ移行して、その他の処理が行われて一連の処理を終了し、はじめから上述の処理が繰り返される。なお、その他の処理がない場合には、ステップ１２０は省略するようにしてもよい。

続いて、ドキュメントフローサービスゲートウエイ１４で行われる処理の流れについて説明する。図５は、ドキュメントフローサービスゲートウエイ１４で行われる処理の流れの一例を示すフローチャートである。

ステップ２００では、処理要求受付部４０によって入力端末１２からの処理要求を受け付けたか否か判定される。該判定が肯定、すなわち、上述のステップ１０２で処理要求がなされた場合には、ステップ２００の判定が肯定されステップ２０２へ移行する。この時、処理要求受付部４０は、入力端末１２からの処理対象のドキュメントを同時に受け取りドキュメントフローサービス管理部５０に出力する。

ステップ２０２では、ドキュメントフローサービス管理部５０によって、処理要求に対応するドキュメントフローサービス１６に対して入力端末１２から受け付けたドキュメントを出力すると共に、処理要求に応じた処理指示が行われる。これによって、ドキュメントフローサービス１６では処理要求に応じた処理が行われる。

次に、ステップ２０４では、チケット管理部４８によってドキュメントフローサービス１６からジョブＩＤを取得したか否か判定される。該判定は、ドキュメントフローサービス１６による処理要求に応じた処理が行われることによって発行されるドキュメントフローサービス固有のジョブＩＤをチケット管理部４８が取得したか否かを判定することによってなされ、該判定が肯定されるまで待機してステップ２０６へ移行する。なお、ジョブＩＤを取得する際に、ドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報も同時に取得する。

ステップ２０６では、チケット管理部４８によってＧＵＩＤからなるチケットが発行され、入力端末１２からの処理要求、ドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報、及びジョブＩＤがチケットに関連付けられて記憶され、ステップ２０８へ移行する。すなわち、チケットを指定することで、処理を行っているドキュメントフローサービス１６と、そのドキュメントフローサービス１６のジョブをジョブＩＤから特定することができる。

一方、ステップ２００の判定が否定された場合には、そのままステップ２０８へ移行する。

ステップ２０８では、処理状況通知部４４によって入力端末１２から出力される処理状況確認要求を受け取ったか否か判定される。該判定が肯定された場合には、ステップ２１０へ移行して、チケット管理部４８によって処理状況確認要求に含まれるチケットに対応するドキュメントフローサービス識別情報とジョブＩＤが検索されてステップ２１２へ移行する。

ステップ２１２では、処理状況取得部４２によって入力端末１２から送られてきたチケットに対応するドキュメントフローサービス１６に対してジョブＩＤのジョブについての処理状況確認が行われる。すなわち、処理状況取得部４２は、チケット管理部４８からチケットに対応するドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報とジョブＩＤを取得して、これらに基づいて処理状況確認をドキュメントフローサービス管理部５０を介して行う。

ステップ２１４では、処理状況取得部４２によって処理状況確認結果が取得されたか否か判定され、該判定が肯定されるまで待機してステップ２１６へ移行して、処理状況取得部４２によって取得された処理状況確認結果が処理状況通知部４４を介して入力端末１２に通知され、ステップ２１８へ移行する。この時、処理状況通知部４４では、チケットに対応する入力端末１２から出力される端点の情報、処理状況確認時の通知手段、及び認証方法に基づいて、入力端末１２への通知が行われる。

一方、ステップ２０８の判定が否定された場合には、そのままステップ２１８へ移行する。

ステップ２１８では、操作要求受付部４６によって操作要求を受け付けたか否か判定される。該判定が肯定された場合には、ステップ２２０へ移行して、操作要求受付部４６によって操作要求に含まれるチケットに対応するドキュメントフローサービス識別情報とジョブＩＤが検索されてステップ２２２へ移行する。

ステップ２２２では、操作要求受付部４６によって入力端末１２から送られてきたチケットに対応するドキュメントフローサービス１６に対してジョブＩＤのジョブについての操作指示が行われる。すなわち、操作要求受付部４６は、チケット管理部４８からチケットに対応するドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報とジョブＩＤを取得して、これらに基づいて、入力端末１２から指示される操作をドキュメントフローサービス管理部５０を介して行う。これによって、ドキュメントフローサービス１６における処理の中止、一時停止、再開、優先順位変更等の操作がなされる。

次に、ステップ２２４では、操作要求受付部４６によってドキュメントフローサービス１６から操作結果を取得したか否か判定される。該判定が肯定されるまで待機してステップ２２６へ移行して、操作要求受付部４６によって操作結果が入力端末１２に通知され、一連の処理を終了し、はじめから上述の処理が繰り返される。なお、操作結果の通知は、チケットに対応する入力端末１２から出力される端点の情報、操作要求時の通知手段、及び認証方法に基づいて、入力端末１２への通知が行われる。

一方、ステップ２１８の判定が否定された場合には、ステップ２２８へ移行して、その他の処理が行われて、一連の処理を終了し、はじめから上述の処理が繰り返される。なお、その他の処理がない場合には、ステップ２２８は省略するようにしてもよい。

続いて、ドキュメントフローサービス１６で行われる処理の流れについて説明する。図６は、ドキュメントフローサービス１６で行われる処理の流れの一例を示すフローチャートである。

ステップ３００では、ドキュメントフローサービスゲートウエイ１４の処理要求受付部４０からドキュメントフローサービス管理部５０を介して処理指示がなされたか否か判定される。すなわち、入力端末１２からドキュメントあるいはドキュメントに対するリンク情報と共に処理要求が出力されて処理指示がなされたか否か判定される。該判定が肯定された場合には、ステップ３０２へ移行して処理要求に応じた処理が、処理指示と共に送られてきたドキュメントに対して行われ、ステップ３０４へ移行する。

ステップ３０４では、処理実行時に発行する自装置のジョブＩＤがドキュメントフローサービス管理部５０に返信され、ステップ３０６へ移行する。これによって、ドキュメントフローサービスゲートウエイ１４のチケット管理部４８では、処理要求、ドキュメントフローサービス１６を特定するドキュメントフローサービス識別情報及びジョブＩＤがチケットに関連付けられて記憶される。

一方、ステップ３００の判定が否定された場合には、そのままステップ３０６へ移行する。

ステップ３０６では、ドキュメントフローサービスゲートウエイ１４の処理状況取得部４２からドキュメントフローサービス管理部５０を介して処理状況確認がなされたか否か判定される。すなわち、入力端末１２から処理要求された処理について処理状況の確認が行われたか否か判定される。該判定が肯定された場合には、ステップ３０８へ移行して、チケットに対応するジョブＩＤの処理状況の確認結果がドキュメントフローサービス管理部５０に返信され、ステップ３１０へ移行する。これによって、ドキュメントフローサービスゲートウエイ１４から入力端末１２に処理状況の確認結果が返信される。

一方、ステップ３０６の判定が否定された場合には、そのままステップ３１０へ移行する。

ステップ３１０では、ドキュメントフローサービスゲートウエイ１４の操作要求受付部４６からドキュメントフローサービス管理部５０を介して操作指示がなされたか否か判定される。すなわち、入力端末１２から処理要求された処理について操作指示が行われたか否か判定される。該判定が肯定された場合には、ステップ３１２へ移行して、操作要求に応じた操作（例えば、処理の中止、一時停止、再開、優先順位変更等の操作）が行われ、ステップ３１４へ移行する。

ステップ３１４では、操作結果がドキュメントフローサービス管理部５０に返信され、一連の処理を終了し、はじめから上述の処理が繰り返される。これによって、ドキュメントフローサービスゲートウエイ１４から入力端末１２に操作結果が返信される。

一方、ステップ３１０の判定が否定された場合には、ステップ３１６へ移行して、その他の処理が行われて、一連の処理を終了し、はじめから上述の処理が繰り返される。なお、その他の処理がない場合には、ステップ３１６は省略するようにしてもよい。

このように、入力端末１２とドキュメントフローサービス１６の間に、ドキュメントフローサービスゲートウエイ１４を設けて、上述のように処理を行うことによって、ドキュメントフローサービス１６におけるジョブＩＤがドキュメントフローサービス固有の場合でも、ドキュメントフローサービスゲートウエイ１４内部でＧＵＩＤ等の一意のものに変換されるので、既存のサーバ型の処理装置（上述のドキュメントフローサービス１６やプル型配信のサーバ装置等）に大きな変更を加えることなく、入力端末１２からドキュメントあるいはドキュメントに対するリンク情報と共にサービスを依頼して処理する、所謂プッシュ型配信のサービス処理システムを提供することができる。さらには、既存のドキュメントフローサービス１６を用いるので、ドキュメントフローサービス１６はプル型配信もでき、柔軟で即時性の優れたサービス処理システムを提供することができる。

また、認証など共通に求められる機能が必要なときには、個々のドキュメントフローサービス１６にこれらの機能を持たせなくても、本実施の形態に係わるサービス処理システム１０では、ドキュメントフローサービスゲートウエイ１４に持たせること可能であるので、ドキュメントフローサービスゲートウエイ１４によって複数のドキュメントフローサービス１６を一元的処理することができる。

さらには、本実施の形態に係わるサービス処理システム１０では、複数のドキュメントフローサービス１６をドキュメントフローサービスゲートウエイ１４のドキュメントフローサービス管理部５０で管理するので、各ドキュメントフローサービス１６の負荷に応じて、入力端末１２から処理要求による処理を分散して行うことが可能となり、効率的なサービス処理システム１０を構築することができると共に、同一機能を保持するドキュメントフローサービス１６を複数接続することによって、少なくとも１つのドキュメントフローサービス１６が動作していれば、サービス処理システム１０はシステム全体として稼働することが可能となる。

続いて、ドキュメントフローサービスゲートウエイ１４で行われる能動的な処理状況通知の流れについて説明する。図７は、ドキュメントフローサービスゲートウエイ１４で行われる能動的な処理状況通知処理の流れの一例を示すフローチャートである。

ステップ４００では、ドキュメントフローサービス１６からのドキュメントフローサービスゲートウエイ１４のドキュメントフローサービス管理部５０に対する処理状況変更通知によって、ジョブに対する処理状況変更を検知する。これは、ドキュメントフローサービスゲートウエイ１４のドキュメントフローサービス管理部５０からドキュメントフローサービス１６に対する処理状況問い合わせによって処理状況変更を検知してもよい。

ステップ４０２では、ドキュメントフローサービス管理部５０はチケット管理部４８へドキュメントフローサービス識別情報およびジョブＩＤを送信し、チケット管理部４８は送信されたドキュメントフローサービス識別情報およびジョブＩＤからチケット情報を検索する。

続いて、ステップ４０４では、該チケット情報に処理状況通知時の通知手段が登録されているか否か判定される。該判定が肯定された場合には、ステップ４０６へ移行して、処理状況取得部４２にて最新の処理状況を取得され、ステップ４０８にて、処理状況通知部４４を介して入力端末１２に対して処理状況通知が実施される。

このように、ドキュメントフローサービスゲートウエイ１４が能動的に処理状況を入力端末１２に通知するので、入力端末１２とドキュメントフローサービス１６間の処理状態の相違（タイムラグ）を最小限にすることができると共に、通信負荷を軽減することが可能となる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。発明の要旨を逸脱しない範囲で上記実施の形態に態様な変更かたは改良を加えることができ、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれる。

また、上記の実施の形態は、クレーム（請求項）にかかる発明を限定するものではなく、また実施の形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。上述した実施の形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜の組み合わせにより種々の発明を抽出できる。実施の形態に示される全構成要件から幾つかの構成要件が削除されても、効果が得られる限りにおいて、この幾つかの構成要件が削除された構成が発明として抽出され得る。

なお、上記の実施の形態では、複数のドキュメントフローサービス１６をドキュメントフローサービスゲートウエイ１４に接続する構成としたが、これに限るものではなく、１つのドキュメントフローサービス１６をドキュメントフローサービスゲートウエイ１４に接続するようにしてもよい。

本発明の実施の形態に係わるサービス処理システムの概略構成を示すブロック図である。 ドキュメントフローサービスの構成を示すブロック図である。 ドキュメントフローサービスゲートウエイの構成を示すブロック図である。 入力端末で行われる処理の流れの一例を示すフローチャートである。 ドキュメントフローサービスゲートウエイで行われる処理の流れの一例を示すフローチャートである。 ドキュメントフローサービスで行われる処理の流れの一例を示すフローチャートである。 ドキュメントフローサービスゲートウエイで行われる能動的な処理状況通知処理の流れの一例を示すフローチャートである。

符号の説明

１０ サービス処理システム
１２ 入力端末
１４ ドキュメントフローサービスゲートウエイ
１６ ドキュメントフローサービス
４０ 処理要求受付部
４２ 処理状況取得部
４４ 処理状況通知部
４６ 操作要求受付部
４８ チケット管理部
５０ ドキュメントフローサービス管理部

Claims (5)

1. 文書データに関して所定の処理を行うサービスの処理要求を行う入力端末と、前記入力端末からの前記処理要求に応じた前記サービスを実行するサービス処理サーバと、を接続管理し、前記入力端末からの前記処理要求に対応する前記サービス処理サーバへ前記処理要求を行う接続管理装置であって、
   前記処理要求に対して前記処理要求毎に一意な識別子を発行して前記入力端末に送信する発行手段と、前記発行手段によって発行された前記識別子、前記入力端末から行われた前記処理要求を表す識別情報、及び前記サービス処理サーバにおける前記処理要求に対応する個々の前記サービスを特定するサービス特定情報を関連付けて記憶する記憶手段と、を含み、前記記憶手段に記憶された前記識別子、前記識別情報、及び前記サービス特定情報に基づいて、前記入力端末と前記サービス処理サーバとを接続管理する接続管理手段を備え、
   前記接続管理手段が、前記サービス処理サーバの負荷を監視して、負荷に応じて前記入力端末からの前記処理要求を振り分けることを特徴とする接続管理装置。
2. 文書データに関して所定の処理を行うサービスの処理要求を行う入力端末と、
   前記入力端末からの前記処理要求に応じた前記サービスを実行するサービス処理サーバと、
   前記処理要求に対して前記処理要求毎に一意な識別子を発行して前記入力端末に送信する発行手段と、前記発光手段によって発行された前記識別子、前記入力端末から行われた前記処理要求を表す識別情報、及び前記サービス処理サーバにおける前記処理要求に対応する個々の前記サービスを特定するサービス特定情報を関連付けて記憶する記憶手段と、を含み、前記記憶手段に記憶された前記識別子、前記識別情報、及び前記サービス特定情報に基づいて、前記入力端末と前記サービス処理サーバとを接続管理し、前記入力端末からの前記処理要求に対応する前記サービス処理サーバへ前記処理要求を行う接続管理装置と、
   を備え、
   前記接続管理手段が、前記サービス処理サーバの負荷を監視して、負荷に応じて前記入力端末からの前記処理要求を振り分けることを特徴とするサービス処理システム。
3. 前記入力端末は、前記処理要求に処理状況の通知を要求する情報を含めて、サービス処理要求を行い、前記接続管理装置は、サービス処理サーバでの処理状況変化の検知に伴い、前記入力端末に対して処理状況を通知することを特徴とする請求項２に記載のサービス処理システム。
4. 前記入力端末は、前記処理要求を行った前記サービスに対する確認要求及び操作要求の少なくとも一方の要求を行う際に前記識別子を用いて行い、前記接続管理装置は、前記入力手段が要求時に用いる前記識別子に基づいて、対応する処理要求及び前記サービス特定情報を特定して、前記入力端末からの要求に応じた処理を前記サービス処理サーバに対して行うことを特徴とする請求項２に記載サービス処理システム。
5. 前記入力端末は、複数種類の前記サービスが実行可能な複合機からなり、自装置で処理不能な前記サービスについて前記サービス処理サーバに前記処理要求を行うことを特徴とする請求項２〜４の何れか１項に記載のサービス処理システム。

Images