JP5482363B2 - 画像処理システム、画像処理装置及び画像処理方法 - Google Patents

Description

本発明は、画像データを処理する画像処理システム、画像処理装置及び画像処理方法に関する。

近年、多くの企業において、多機能複合機などの画像入出力機器のネットワーク上への配置・接続が進んでいる。画像入出力機器は、業務の効率化を図る手段として大きな役割を担っている。特に、紙文書の電子化と配布を効率的に行う配信管理システムが重要になっている。配信管理システムを構成する大きな要素は、画像入力機器（例えばスキャナなど）と配信管理サーバである。配信管理サーバには、あらかじめさまざまな業務・用途にあわせた複数の配信処理メニューが登録されている。利用者は、スキャナのオペレーションパネル（操作部）から、業務に適した処理メニューを選択してスキャンを行う。

例えば、特開２００６−０１８６４０号公報には、配信処理や画像変換処理をプラグイン化し、ユーザや管理者がそれらプラグインを任意に組み合わせて入力、画像変換、出力のワークフローを作成し、作成されたワークフローを利用して画像データの配信処理を行う技術が開示されている。また、前述した配信管理を行う配信管理サーバの機能を組み込んだ画像形成装置は、ＣＰＵの処理負荷やメモリ量の制限により、処理ができないアプリケーションがある。

一方、オフィス複合機をインタフェースとしたＡＳＰ（アプリケーション・サービス・プロバイダ）のサービスを提供する技術がある。例えば、特開２００２−２５２７３２号公報には、画像形成装置において、処理できない機能については、サービス提供側に電子情報を送信することで、サービス提供側で所望のサービスを実施し、サービス結果を取得することで、処理可能とする技術が開示されている。

しかしながら、サービス提供側では無制限に処理を可能とするのは一般的ではなく、所定の機器に処理権限を与える仕組みが考えられる。ここで、サービス提供側でログインに成功した機器に認証チケットを与えることが考えられるが、これは、サービス利用側とサービス提供側との通信に有効であり、サービス提供側での内部通信において毎回ユーザ認証を行なう場合は処理負荷が大きい。また、内部通信において何のチェックもなしにデータ通信を行う場合は、セキュリティ上問題がある。

そこで、本発明は、上記問題点に鑑みてなされたものであり、サービス提供側において処理負荷を軽減して通信を行なう画像処理システム、画像処理装置及び画像処理方法を提供することを第１の目的とする。また、サービス提供側において、セキュリティを考慮しつつ処理負荷を軽減して通信を行なう画像処理システム、画像処理装置及び画像処理方法を提供することを第２の目的とする。

本発明における一局面の画像処理システムは、ネットワークを介して画像形成装置と１又は複数の画像処理装置とを接続し、画像処理を行う画像処理システムであって、画像形成装置からのログインを管理し、ログインした画像形成装置に認証チケットを発行するユーザ管理手段と、前記認証チケットを付加して画像データを含む画像処理要求を前記画像処理装置に行うタスク要求手段と、前記画像処理要求の不正を検出する検出手段と、正当な前記画像処理要求を受信した後、前記ユーザ管理手段にユーザ情報を問い合わせて取得したユーザ情報に、当該画像処理システム内部からの通信であることを示す識別情報を付加して、前記画像処理要求を行うタスク処理手段と、前記識別情報により内部通信であることを確認した後、前記タスク処理手段から取得した画像処理要求をタスクキューに保存し、前記１又は複数の画像処理手段から前記画像処理要求に対する問合せを受けるタスク管理手段と、前記タスクキューに保存された画像処理要求に対し、処理可能な画像処理要求を取得して画像処理を行う１又は複数の画像処理手段と、前記画像処理手段により処理された画像データを格納する格納手段と、前記画像データの格納場所を指定して前記画像データを取得する取得手段と、を備える。

また、本発明における他の局面の画像処理装置は、ネットワークを介して接続される画像形成装置からの画像処理要求を管理する画像処理装置であって、画像形成装置からのログインを管理し、ログインした画像形成装置に認証チケットを発行するユーザ管理手段と、正当な認証チケットを含む前記画像処理要求を受信した後、前記ユーザ管理手段にユーザ情報を問い合わせて取得し、該ユーザ情報を含めて前記画像処理要求を行うタスク処理手段と、前記タスク処理手段から取得した画像処理要求をタスクキューに保存し、１又は複数の画像処理手段から前記画像処理要求に対する問合せを受けるタスク管理手段と、を備える。

また、本発明における他の局面の画像処理方法は、ネットワークを介して画像形成装置と１又は複数の画像処理装置とを接続し、画像処理を行う画像処理システムにおける画像処理方法であって、画像形成装置からのログインを管理し、ログインした画像形成装置に認証チケットをユーザ管理手段により発行する発行ステップと、前記認証チケットを付加して画像データを含む画像処理要求を前記画像処理装置に行うタスク要求ステップと、前記画像処理要求の不正を検出する検出ステップと、正当な前記画像処理要求を受信した後、前記ユーザ管理手段にユーザ情報を問い合わせて取得したユーザ情報に、当該画像処理システム内部からの通信であることを示す識別情報を付加して、前記画像処理要求を行うタスク処理ステップと、前記識別情報により内部通信であることを確認した後、前記タスク処理ステップにより要求された画像処理要求をタスクキューに保存し、前記１又は複数の画像処理手段から前記画像処理要求に対する問合せを受けるタスク管理ステップと、前記タスクキューに保存された画像処理要求に対し、処理可能な画像処理要求を取得して画像処理を行う１又は複数の画像処理ステップと、前記画像処理手段により処理された画像データを格納手段に格納する格納ステップと、前記処理された画像データの格納場所を指定して前記画像データを取得する取得ステップと、を有する。

本発明によれば、サービス提供側において処理負荷を軽減して通信を行なうことができる画像処理システム、画像処理装置及び画像処理方法を提供することができる。

実施例１に係る画像処理システムの一例を示す図。 実施例１に係るＭＦＰのハードウェア構成の一例を示すブロック図。 実施例１に係る画像処理サーバのハードウェア構成の一例を示すブロック図。 実施例１における画像処理システムの機能構成の一例を示すブロック図。 実施例１における画像処理システムの他の機能構成の一例を示すブロック図。 実施例１における画像処理サービスが提供するサービスの一例の概要を示す図。 実施例１におけるユーザ管理、認証処理の一例の概要を示す図。 ユーザマネジメントで管理する各種テーブルの一例を示す図。 画像処理サービスを構成する機器の一例を示す図。 実施例１における画像処理サービスを利用した画像処理の一例を示すシーケンス図。 認証チケット取得に係るリクエストとレスポンスの一例を示す図。 ファイルアップロードに係るリクエストとレスポンスの一例を示す図。 タスク登録に係るリクエストとレスポンスの一例を示す図。 タスクのステータス取得に係るリクエストとレスポンスの一例を示す図。 出力ファイル取得に係るリクエストの一例を示す図。 引き取り終了通知に係るリクエストとレスポンスの一例を示す図。 実施例２における画像処理システムの機能構成の一例を示すブロック図。 ＭＦＰにおける表示画面の一例を示す図。 実施例２におけるサービスの一例の概要を説明する図。 変形例における画像処理システムの機能構成の一例を示すブロック図。 発注に関する管理データの一例を示す図。

以下、添付図面を参照して、本発明にかかる画像処理システム、画像形成装置、画像処理装置（又は画像処理サーバ）、画像処理方法、プログラム及び記録媒体の実施例を詳細に説明する。

また、以下に示す実施例では、画像データを入力する画像入力装置として、プリンタ機能、スキャナ機能、コピー機能、ファクシミリ機能を一つの筐体に搭載した複合機を例にあげて説明しているが、これに限定されるものではなく、画像データを入力可能であれば、スキャナ装置、ファクシミリ装置、コピー装置などいずれにも適用することができる。

［実施例１］
＜システム構成とハードウェア構成＞
図１は、実施例１に係る画像処理システムの一例を示す図である。図１に示すように、画像処理システムは、ネットワークを介してＭＦＰ（Multifunction Peripheral）１０、ＭＦＰ２０、画像処理装置（画像処理サーバ）３０、画像管理サーバ４０、データベース（ＤＢ）５０が接続されている。以下、画像形成装置はＭＦＰを例にして説明する。

ＭＦＰ１０、２０は、スキャン機能、コピー機能、プリンタ機能、ファクシミリ機能などを一つの筐体に搭載したものである。ＭＦＰ１０、２０は、スキャナ機能により紙媒体等をスキャン処理して画像データを生成し、生成された画像データを画像処理サーバ３０に送信する。ＭＦＰの詳細については後述する。また、画像データは、文書の画像データを含む。

また、ＭＦＰ１０、２０は、スキャンされた画像データを受信して、指定されたワークフローに従って種々の処理や配信処理を実行するワークステーション等のコンピュータである。ワークフローは、１又は複数の処理が規定された一連の処理フローをいい、メール送信、ＦＡＸ送信、フォルダ配信などがある。

また、ＭＦＰ１０、２０は、入力された画像データに基づいてワークフローを実行し、ユーザによって構築されたワークフローに従って文書の蓄積又は配信処理を実行する。

画像処理サーバ３０は、各ＭＦＰにはない機能を管理し、また、各ＭＦＰからの画像処理要求を管理する。なお、画像処理サーバは機能毎に備えてもよく、詳細は後述する。

画像管理サーバ４０は、ＭＦＰから配信された画像データを蓄積、管理するサーバである。また、画像管理サーバ４０は、蓄積した画像データに対して画像タイプを登録したり、検索を行ったりすることもできる。

ＤＢ５０は、各ＭＦＰから送信されてきた画像データを保存し、また、画像処理装置により画像処理された画像データを保存する。なお、画像処理装置は、画像処理システムに複数接続されていてもよい。

実施例１に係るＭＦＰ１０と画像処理サーバ３０とのハードウェア構成について説明する。図２は、実施例１に係るＭＦＰ１０のハードウェア構成の一例を示すブロック図である。

図２に示すように、ＭＦＰ１０は、制御部１１、主記憶部１２、補助記憶部１３、外部記憶装置Ｉ／Ｆ部１４、ネットワークＩ／Ｆ部１６、操作部１７、表示部１８、エンジン部１９を含む。

制御部１１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部１１は、主記憶部１２に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。

主記憶部１２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部１１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。

補助記憶部１３は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。

外部記憶装置I／F部１４は、ＵＳＢ（Universal Serial Bus）などのデータ伝送路を介して接続された記憶媒体１５（例えば、フラッシュメモリなど）と当該ＭＦＰとのインタフェースである。

また、記憶媒体１５に、所定のプログラムを格納し、この記憶媒体１５に格納されたプログラムは外部記憶装置Ｉ／Ｆ部１４を介してＭＦＰ１０にインストールされ、インストールされた所定のプログラムはＭＦＰ１０により実行可能となる。

ネットワークＩ／Ｆ部１６は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器と当該ＭＦＰ１０とのインタフェースである。

操作部１７や表示部１８は、キースイッチ（ハードキー）とタッチパネル機能（ＧＵＩのソフトウェアキーを含む：Graphical User Interface）を備えたＬＣＤ（Liquid Crystal Display）とから構成され、ＭＦＰ１０が有する機能を利用する際のＵＩ（User Interface）として機能する表示及び／又は入力装置である。

エンジン部１９は、実際に画像形成に係る処理を行うプロッタ、スキャナ等の機構部分である。

図３は、実施例１に係る画像処理サーバ３０のハードウェア構成の一例を示すブロック図である。図３に示すように、画像処理サーバ３０は、制御部３１、主記憶部３２、補助記憶部３３、外部記憶装置Ｉ／Ｆ部３４、ネットワークＩ／Ｆ部３６を含む。

制御部３１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部３１は、主記憶部３２に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。

主記憶部３２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部３１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。

補助記憶部３３は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。

外部記憶装置I／F部３４は、ＵＳＢ（Universal Serial Bus）などのデータ伝送路を介して接続された記憶媒体１５（例えば、フラッシュメモリなど）と画像処理サーバ３０とのインタフェースである。

また、記憶媒体１５に、所定のプログラムを格納し、この記憶媒体１５に格納されたプログラムは外部記憶装置Ｉ／Ｆ部３４を介して画像処理サーバ３０にインストールされ、インストールされた所定のプログラムは画像処理サーバ３０により実行可能となる。

ネットワークＩ／Ｆ部３６は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器と画像処理サーバ３０とのインタフェースである。

＜機能構成＞
図４は、実施例１における画像処理システムの機能構成の一例を示すブロック図である。図４に示す例では、ＭＦＰ１０は、取得した画像（例えば、スキャン画像）に対し、ワークフロー１０１に従って配信を行う。このとき、ＭＦＰ１０は、ワークフローに含まれる画像変換機能を有していないとする。よって、画像変換プラグイン（タスク要求手段、取得手段）１０２は、サービス提供システム（以下、画像処理サービスともいう）に画像処理（たとえば、ＯＣＲ）を依頼する。画像変換プラグイン１０２は、以下、単にプラグイン１０２ともいう。

また、ＭＦＰ１０のプラグイン１０２は、画像処理サービスにアクセスする前に、ユーザマネジメント４０２から認証用のチケットを取得する。プラグイン１０２は、取得した認証チケットを付加して画像処理サービスに画像処理を要求する。

図４に示すように画像処理サービス側では、ファイアウォール４０１、ユーザマネジメント４０２、ストレージ４０３、タスクフロント４０４、タスクマスタ４０５、タスクキュー４０６、ＯＣＲワーカー４０７、バーコードワーカー４０８、サービスログ４０９、Ｗｅｂサービス４１０、サービスモニタリング４１１の機能を有する。

ファイアウォール（検出手段）４０１は、不正アクセスを検出するためのファイアウォールでもあり、さらに、負荷分散を行うためのロードバランサーでもある。ロードバランサーは、外部ネットワークからの要求を一元的に管理し、同等の機能を持つ複数のサーバに要求を転送する機能を有する。

ユーザマネジメント（ユーザ管理手段）４０２は、タスクフロント４０４、ストレージ４０３、サービスログ４０９にシングルサインオンできる機能を提供するアプリケーションである。

ストレージ４０３は、各種アプリケーションが共通で使用できる格納手段である。ストレージ４０３は、画像処理サービスにおいて、処理前ファイル、処理済ファイルを一時的に格納するウェブアプリケーションの役割を担う。また、ＭＦＰ１０のプラグイン１０２は、処理前のファイルをストレージ４０３にアップロードしたり、処理済のファイルをダウンロードしたりする。また、ファイルは例えば画像データのことをいう。

タスクフロント（タスク処理手段）４０４は、ＭＦＰ１０のプラグイン１０２から、ファイルやタスク情報を受け付けたり、プラグイン１０２にタスクの処理結果情報を返したりするウェブアプリケーションである。

タスクマスタ（タスク管理手段）４０５は、タスクフロント４０４や他のアプリケーションから例えばＯＣＲなどの処理タスクを受け付けるウェブアプリケーションである。たま、タスクマスタ４０５は、タスクキュー４０６、タスクワーカー（ＯＣＲワーカー４０７、バーコードワーカー４０８など）を管理する。

タスクキュー４０６は、プラグイン１０２から依頼された処理タスクを先入れ先出し（ＦＩＦＯ）により保存する。

ＯＣＲワーカー４０７は、タスクマスタ４０５から仕事を受け取り、ＯＣＲのタスクを処理するサービスプログラムである。

バーコードワーカー４０８は、タスクマスタ４０５から仕事を受け取り、バーコード読取のタスクを処理するサービスプログラムである。なお、タスクマスタ４０５からの仕事は、例えば、ＯＣＲ４０７の処理後にバーコードワーカー４０８の処理を行うなど、複数の処理を行ってもよい。

また、ＯＣＲワーカー４０７やバーコードワーカー４０８の上位であるタスクワーカー（画像処理手段）は、タスクマスタ４０５から仕事を受け取り、各種画像処理を行うサービスプログラムである。タスクマスタ４０５が管理するタスクキュー４０６によって、タスクワーカーが動くサーバインスタンスは増減する。

サービスログ４０９は、各種アプリケーションのログを一括して保存するウェブアプリケーションである。画像処理サービスでは、例えばＯＣＲタスクのログを閲覧することができる。

Ｗｅｂサービス４１０は、インターネット上で提供されていて、ＸＭＬベースのプロトコルでアクセスできる機能を有する。Ｗｅｂサービス４１０の例として翻訳処理などがある。なお、実施例１では、ＯＣＲワーカー４０７によるＯＣＲ処理後にＷｅｂサービス４１０による翻訳処理を行ってもよい。サービスモニタリング４１１は、各サーバのサービス、リソースを監視する。

また、ＭＦＰ１０のプラグイン１０２は、ＨＴＴＰＳによる通信で画像処理サービスにファイル（例えば画像データ）をアップロードし、処理結果を受け取る。なお、画像処理サービス内の通信を内部通信といい、画像処理サービス内の機器又はアプリケーションとＭＦＰ１０との通信を外部通信という。

図５は、実施例１における画像処理システムの他の機能構成の一例を示すブロック図である。図５に示す例では、ＭＦＰ１０で処理することができないＯＣＲプラグイン５０１、バーコードプラグイン５０２から、画像処理サービスは画像処理依頼を受ける。

図５に示す例では、共通のコンポーネント群として、タスクフロント４０４、タスクマスタ４０５、ストレージ４０３、サービスログ４０９、タスクワーカー４１２を含む。共通コンポーネント群は、ドキュメントソリューションで共通に利用できるコンポーネント群である。画像配信機能を有さないＭＦＰや画像処理の種類に対応できるよう、柔軟なウェブＡＰＩにより構成される。また、ストレージ４０３やサービスログ４０９は、画像処理以外のアプリケーションでも利用することができる。また、共通コンポーネント群は、処理量に応じて、容易にスケールアウトできる仕組みになっている。

また、図５に示す例では、インフラストラクチャ群として、ファイアウォール４０１、ユーザマネジメント４０２、サービスモニタリング４１１、アクセスマネジメント４１３を含む。インフラストラクチャ群は、画像処理サービスの機能実現、セキュリティの保護、管理を行う。

アクセスマネジメント４１３は、契約アカウントがどのアプリケーションをどれぐらい利用できるかを管理する。ユーザマネジメント４０２と連携して、利用制限をファイアウォール内のウェブアプリケーションが容易に確認できる仕組みを提供する。

また、図５に示す例では、プラットフォームとして、Ｗｅｂサービス４１０を含む。プロットフォームは、Ｗｅｂサービス４１０のプラットフォームを提供する。

なお、前述した構成では、タスクフロント４０４と、タスクマスタ４０５とを別構成とすることで、ＭＦＰ１０からのアクセスと、タスクワーカー４１２からのアクセスとを分散させることができる。また、タスクフロント４０４を拡張可能とする構成にすることで、ＭＦＰの増加や、アクセスするアプリケーションの増加にも対応することができる。

＜画像処理サービスの概要＞
図６は、実施例１における画像処理サービスが提供するサービスの一例の概要を示す図である。まず、ＭＦＰ１０のＯＣＲプラグイン５０１は、ユーザマネジメント４０２に対し、認証チケットの取得を試みる（１）。

ＯＣＲプラグイン５０１は、認証チケットを取得した場合は、ＨＴＴＰＳリクエストのヘッダに認証チケットを含ませて、ＯＣＲ処理前のファイル（画像データ）をストレージ４０３にアップロードする（２）。なお、ファイルのアップロードは、タスクフロント４０４を介して行ってもよい。

また、ＯＣＲプラグイン５０１は、ファイルを保存したストレージ４０３の場所を示す位置情報を含むＯＣＲ処理要求（タスク）をタスクフロント４０４に行う（３）。次に、画像処理サービス側では、タスクフロント４０４は、ＯＣＲ処理要求のタスクをタスクマスタ４０５に通知し、タスクキュー４０６にタスクを登録する（３．１）。

ＯＣＲワーカー４０７が、自身が処理できるタスクがないかをタスクマスタ４０５に問い合わせて（ポーリングして）、処理可能なタスクがあればタスクを取得する（３．２）。ＯＣＲワーカー４０７は、タスクからファイルの位置情報を取得し、ストレージ４０３から処理前のファイルを取得する（３．３）。

ＯＣＲワーカー４０７は、取得したファイルに対し、ＯＣＲ処理を施し、処理済のファイルをストレージ４０３に保存する（３．４）。このとき、ＯＣＲワーカー４０７は、処理済のファイルを保存したストレージ４０３の場所を示す位置情報を記憶する。ＯＣＲワーカー４０７は、処理済のファイルの位置情報を含めてタスク終了通知をタスクマスタ４０５に行う（３．５）。

タスクマスタ４０５は、ＯＣＲワーカー４０７からタスク終了通知を受けると、サービスログ４０９に正常にタスクが終了したことをログとして残す（３．６）。

タスクマスタ４０５は、タスクログの保存が終了すると、タスク終了通知をタスクフロント４０４に行う（３．７）。

ＯＣＲプラグイン５０１は、タスクフロント４０４に対し、ＯＣＲ処理が終了したかを問い合わせて（ポーリングして）、処理済ファイルのＵＲＬ（位置情報）を取得する（４）。

ＯＣＲプラグイン５０１は、ＨＴＴＰＳリクエストに認証チケットを含めてストレージ４０３にアクセスし、位置情報が示す場所に保存される処理済ファイルを取得する（５）。

ＯＣＲプラグイン５０１は、ファイル取得の確認を行なった後、ＨＴＴＰＳリクエストに認証チケットを含めてタスクフロント４０４にアクセスし、タスクの削除申請を行う（６）。

これにより、ＭＦＰ１０は、自身ではＣＰＵやメモリの制約上処理できない処理（例えばＯＣＲ）を、ＯＣＲプラグイン５０１を用いて画像処理サービスにＯＣＲ処理を依頼し、ＯＣＲ処理済のファイル（画像データ）を取得することができる。このとき、画像処理サービス側ではユーザの処理は介在しない。

＜ユーザ管理、認証処理の概要＞
図７は、実施例１におけるユーザ管理、認証処理の一例の概要を示す図である。まず、ＭＦＰ１０は、ユーザマネジメント４０２にログインする（１）。ログイン情報としては組織情報「ＢＢ」、ユーザ名情報「ＣＣＣ」、パスワードを含む。

図８は、ユーザマネジメント４０２で管理する各種テーブルの一例を示す図である。図８に示すように、ユーザマネジメント４０２は、組織テーブル、ユーザテーブル、ライセンステーブル、サービステーブル、セッションテーブルを管理する。

組織テーブルは、組織ＩＤ、組織名、住所を関連付けて記憶する。ユーザテーブルは、ユーザＩＤ、組織ＩＤ、ログイン名、パスワードを関連付けて記憶する。ライセンステーブルは、ライセンスＩＤ、ユーザＩＤ、サービスＩＤ、状態を関連付けて記憶する。

また、サービステーブルは、サービスＩＤとサービス名を関連付けて記憶する。セッションテーブルは、セッションＩＤとユーザＩＤとを関連付けて記憶する。

ユーザマネジメント４０２は、ログインしたＭＦＰ１０に対し、認証トークン（セッションＩＤ）、組織ＩＤ（ＯｒｇＩＤ）、ユーザＩＤ（ＵｓｅｒＩＤ）を含む認証チケットを送信する（２）。

このとき、ユーザマネジメント４０２は、ユーザＩＤと組織ＩＤとを付加してハッシュを計算し、計算したハッシュをセッションＩＤとする。また、ハッシュ生成には、秘密鍵を利用することで改ざんを防ぐことができる。ここでは、ユーザＩＤ「１５」と組織ＩＤ「３」とからハッシュを計算し、「ａｂｃｄｅｆｇｈ」を認証トークンとする。ここで、ユーザマネジメント４０２は、図８に示すように、計算されたセッションＩＤとユーザＩＤとをセッションテーブルに記憶する。

ＭＦＰ１０のプラグイン１０２は、画像処理を画像処理サービスに依頼する場合、ＨＴＴＰＳリクエストに認証チケットを含めて、タスクフロント４０４にアクセスする（３）。

このとき、ＭＦＰ１０から画像処理サービスへの通信（外の通信）は、認証トークンを用いる。また、一意性だけが必要なアプリケーションは、ＩＤを使い、ユーザマネジメント４０２への問合せを減らす（例えば、閲覧権限が作成者のみ）。

また、認証チケットは、ＨＴＴＰＳで暗号化されている上、ハッシュを計算してファイアウォール４０１により不正か否かチェックされる。よって、組織ＩＤなどを変えた場合には改ざんを検知することができる。つまり、ファイアウォール４０１は、不正な認証チケットを含むアクセスを検出することができる。

次に、タスクフロント４０４は、認証チケットを用いて、ユーザ情報をユーザマネジメント４０２に問い合わせる（４）。このとき、タスクフロント４０４は、図８に示すライセンステーブルに対して、サービス利用の状態を問合せてもよい。

また、認証チケットには組織ＩＤとユーザＩＤとが含まれているので、他の情報が必要なければ、タスクフロント４０４は、ユーザマネジメント４０２に問い合わせる必要はない。

ユーザマネジメント４０２は、タスクフロント４０４からユーザ情報の問合せがあった場合、組織名、ユーザ名を含むユーザ情報をタスクフロント４０４に出力する（５）。

タスクフロント４０４は、ユーザマネジメント４０２からユーザ情報を取得した場合、組織名、ユーザ名のユーザ情報そのものを画像処理サービス内の通信（内部通信）におけるＨＴＴＰリクエストのヘッダに付加する。さらに、内部通信であることを明確にするため、自身のアプリケーション名を付加する。タスクフロント４０４は、ユーザ情報そのものと、自身の識別情報（例えば、アプリケーション名、又はアプリケーションを実行する装置の識別情報など）をヘッダに追加してタスクの登録要求（リクエスト）をタスクマスタ４０５に行う（６）。

これにより、ユーザ情報そのものをやりとりするため、内部通信の度にユーザマネジメント４０２に問い合わせる必要がない。また、セキュリティを考慮して自身の識別情報を付加するため、リクエストを受信したアプリケーションは、ヘッダに含まれる識別情報をチェックすることで、内部からの通信であるかを判断することができる。このとき、画像処理サービス内部のアプリケーションは、内部の各アプリケーションの識別情報を保持しておく。

次に、ＯＣＲワーカー４０７は、タスクマスタ４０５から、（６）と同様の通信を行なって、タスクを取得し、ユーザ情報を取得する（７）。

ＯＣＲワーカー４０７は、取得した組織名「ＢＢ」、ユーザ名「ＣＣＣ」の権限で、ストレージ４０３からファイルを取得し、処理後のファイルをストレージ４０３に書き込む（８）。なお、ＯＣＲワーカー４０７とストレージ４０３との通信においても（６）と同様の通信を行なう。

これにより、ＭＦＰ１０と画像処理サービスとの通信（外部通信）については、認証チケットを用いて安全に通信を行なうことができる。また、画像処理サービス内部の通信（内部通信）については、生のユーザ情報をＨＴＴＰ拡張ヘッダに含めることで、ユーザマネジメント４０２への問合せを軽減でき、さらに、アプリケーションの識別情報をＨＴＴＰ拡張ヘッダに含めることで、内部からの通信であるかをチェックでき、セキュリティを守ることができる。

＜画像処理サービスの構成例＞
図９は、画像処理サービスを構成する機器の一例を示す図である。図９に示す例では、ロードバランサー４０１とＳＳＬ暗号通信機能を有する情報処理装置６１、サービスモニタリング４１１機能を有する情報処理装置６２、ユーザマネジメント４０２、ストレージ４０３、タスクフロント４０４、タスクマスタ４０５、サービスログ４０９機能を有する情報処理装置６３、６４、ＤＢ６５１を備えるＤＢサーバ６５、タスクワーカー４１２を備える情報処理装置６６、６７により、画像処理サービスを構成する。

ＤＢ６５１は、ユーザマネジメント４０２、ストレージ４０３、タスクフロント４０４、タスクマスタ４０５、サービスログ４０９の各テーブルを管理する。また、ＤＢ６５１は、各Ｗｅｂアプリケーションのバックエンドで機能するＤＢである。

なお、図９に示す例に限られることはなく、例えば、情報処理装置６３、６４はいずれか１つでもよく、また、３つ以上であってもよい。また、ＤＢサーバ６５は、２つ以上あってもよい。

＜動作＞
次に、実施例１における画像処理システムの動作について説明する。図１０は、実施例１における画像処理サービスを利用した画像処理の一例を示すシーケンス図である。図１０に示すステップＳ１０１において、プラグイン１０２が、認証チケットの取得を要求する。

なお、プラグイン１０２と画像処理サービスとの通信はＨＴＴＰＳで行なわれる。よって、他のＨＴＴＰＳリクエストを行う前に、認証チケット取得要求を行う。以降のリクエストを行なう場合は、リクエストに含まれるＣｏｏｋｉｅヘッダに必ず認証チケットを含める。Ｃｏｏｋｉｅとは、ＨＴＴＰにおけるＷｅｂサーバとウェブブラウザ間で状態を管理するプロトコルであり、また、そこで用いられるＷｅｂブラウザに保存された情報のことをいう。なお、前述した通り、画像処理サービス内部での通信には認証チケットは使わず、ユーザ情報そのものと例えばアプリケーション名とを用いる。

ステップＳ１０２において、プラグイン１０２は、ユーザマネジメント４０２から認証チケットを取得する。

ここで、図１１は、認証チケット取得に係るリクエストとレスポンスの一例を示す図である。図１１（Ａ）は認証チケットの取得リクエストの一例を示す。図１１（Ａ）に示すように、リクエストのパラメータとして、組織名、ログイン名、パスワードが含まれる。図１１（Ｂ）は、認証チケットの取得レスポンスの一例を示す。図１１（Ｂ）に示すように、成功時には、Ｃｏｏｋｉｅに「ｓｅｒｖｉｃｅ＿ｔｋｔ」が設定される。

図１０に戻り、ステップＳ１０３において、タスクワーカー４１２は、タスクマスタ４０５に対し、自身の処理中以外は定期的にタスクの取得を試みる。ステップＳ１０４において、タスクマスタ４０５にタスクがなければ、タスクマスタ４０５は、タスクなしの通知をタスクワーカー４１２に行う。

ステップＳ１０５において、プラグイン１０２は、処理対象のファイルをタスクフロント４０４に出力し、ファイルのアップロードを要求する。ステップＳ１０６において、タスクフロント４０４は、ファイルをストレージ４０３にアップロードする。

ステップＳ１０７において、タスクフロント４０４は、アップロードしたファイルの情報を取得する。ファイルの情報には、ファイルの位置情報（ロケーション）が含まれる。ステップＳ１０８においてタスクフロント４０４は、プラグイン１０２に対し、ファイルのロケーションを通知する。

ここで、図１２は、ファイルのアップロードに係るリクエストとレスポンスの一例を示す図である。図１２（Ａ）は、ファイルのアップロードに係るリクエストの一例を示す。図１２（Ａ）に示すように、リクエストのパラメータとして、ファイルコンテンツ、送信するファイル数、クライアントのジョブを特定する情報が含まれる。

図１２（Ｂ）は、ファイルのアップロードに係るレスポンスの一例を示す。図１２（Ｂ）に示すように、アップしたファイルのロケーションがレスポンスに含まれる。

なお、ファイルをアップロードする際、レスポンスで得られたファイルのロケーションは後述するタスク登録時に指定する。ファイル数が多い場合は、一回のタスク登録のために何回もファイルをアップロードすることが可能とする。

ファイルアップロードのアクセス制限として、タスクフロント４０４は、
・ 契約していない会社のアカウントではアップロード不可
・ アップロードされたファイルは、アップロードしたアカウントのみアクセス可
・ 有効期限の切れたファイルはアクセス不可
を設定することもできる。

図１０に戻り、Ｓ１０９において、プラグイン１０２は、画像処理のタスクの登録要求をタスクフロント４０４に行う。

ステップＳ１１０において、タスクフロント４０４は、ユーザマネジメント４０２に対し、ユーザ情報、認可情報の取得要求を行う。ステップＳ１１１において、ユーザマネジメント４０２は、取得要求に対するユーザ情報、認可情報をタスクフロント４０４に出力する。

ステップＳ１１２−１において、タスクフロント４０４は、ユーザ情報とタスクが認可されているとの情報を取得した場合、タスクマスタ４０５にタスクを登録する。ステップＳ１１２−２において、タスクフロント４０４は、認可されないとの情報を取得した場合、プラグイン１０２にエラー通知を行う。

ステップＳ１１３において、タスクマスタ４０５は、登録したタスクの情報（タスク情報）をタスクフロント４０４に出力する。

ステップＳ１１４において、タスクフロント４０４は、プラグイン１０２に対し、タスク情報に含まれるタスクのロケーションを通知する。

ここで、図１３は、タスク登録に係るリクエストとレスポンスの一例を示す図である。図１３（Ａ）は、タスク登録に係るリクエストの一例を示す。図１３（Ａ）に示すように、パラメータとして、アップロードしたファイルのロケーション、処理を行う画像処理のサービス名、画像処理の設定値を含む。また、ログ用として、ログインしているユーザ名やジョブＩＤ、クライアントの画像処理におけるアプリケーション名やバージョンなどをパラメータに含めてもよい。

図１３（Ｂ）は、タスク登録に係るレスポンスの一例を示す。図１３（Ｂ）に示すように、レスポンスは、登録タスクのロケーション、タスクの処理状況、タスク処理サービス名、タスク登録時間を含む。また、エラーの種類、エラーメッセージはタスク登録のエラー時にはレスポンスに含まれる。

なお、タスクを登録する際、タスクフロント４０４は、ファイルのロケーション、画像処理を行うためのオプション（例えば設定値など）、ログに必要な情報をタスクマスタ４０５に送信する。

タスク登録のアクセス制限として、タスクフロント４０４は、
・ 契約していない会社のアカウントではタスク登録不可
・ 契約アカウントが利用可能なサービスのみ登録可（ただし、利用制限枚数内）
・ 入力ファイルのＵＲＬがその会社のストレージをさしてない場合は登録不可
を設定することもできる。

図１０に戻り、ステップＳ１１５において、プラグイン１０２は、タスクフロント４０４に対し、タスク終了まで定期的に状況をポーリングする。ステップＳ１１６において、プラグイン１０２は、タスクフロント４０４から、タスクの状況を取得する。

ここで、図１４は、タスクのステータス取得に係るリクエストとレスポンスの一例を示す図である。図１４（Ａ）は、タスクのステータス取得に係るリクエストの一例を示す。図１４（Ａ）に示すように、タスクフロント４０４からタスクの処理状況を取得するリクエストが発行される。

図１４（Ｂ）は、タスクのステータス取得に係るレスポンスの一例を示す。図１４（Ｂ）に示すように、レスポンスは、登録タスクのロケーション、タスクの処理状況（処理中、成功して終了、処理エラーのいずれか）、出力ファイルのロケーション、タスク処理サービス名、タスク登録時間、タスク情報更新時間を含む。図１４（Ｂ）に示す例では、処理中、成功して終了、処理エラーそれぞれの場合のレスポンスを示す。

プラグイン１０２は、登録したタスクの状況を定期的にポーリングし、タスク処理が終了するのを待つ。タスク処理が終了した場合には、出力ファイルのロケーションがレスポンスに含まれる。

タスクのステータス取得に係るアクセス制限として、タスクフロント４０４は、
・ 登録したアカウントではないアカウントではアクセス不可
・ 有効期限が切れたタスクへはアクセス不可
を設定することもできる。

図１０に戻り、ステップＳ１１７において、タスクワーカー４１２は、タスクマスタ４０５に対してタスクの取得要求を行う。ステップＳ１１８において、タスクマスタ４０５は、タスク情報をタスクワーカー４１２に出力する。

ステップＳ１１９において、タスクワーカー４１２は、タスク情報に含まれるファイルのロケーションに基づいて、ストレージ４０３に対し、ファイルの取得要求を行う。ステップＳ１２０において、タスクワーカー４１２は、ロケーションが示すストレージ４０３の位置にある処理対象のファイルを取得する。ステップＳ１２１において、タスクワーカー４１２は、画像処理中に、タスク処理中の通知を定期的にタスクマスタ４０５に行う。

ステップＳ１２２において、プラグイン１０２は、タスクフロント４０４に対し、タスクの状況をポーリングする。ステップＳ１２３において、プラグイン１０２は、タスクフロント４０４から、タスクの状況を取得する。

ステップＳ１２４において、タスクワーカー４１２は、ファイルの画像処理が終了すると、処理済ファイルをストレージ４０３にアップロードする。ステップＳ１２５において、タスクワーカー４１２は、処理済ファイルのロケーションを取得する。

ステップＳ１２６において、タスクワーカー４１２は、タスク処理結果をタスクマスタ４０５に通知する。ステップＳ１２７において、タスクマスタ４０５は、タスクの処理結果をタスクフロント４０４に通知する。ステップＳ１２８において、タスクフロント４０４は、タスクマスタ４０５に対し、結果の登録が完了したことを通知する。

ステップＳ１２９において、タスクマスタ４０５は、タスクの終了をサービスログ４０９に記憶する。ステップＳ１３０、Ｓ１３１において、サービスログ４０９は、もし月初めであれば、ユーザマネジメント４０２から利用制限枚数を取得する。

ステップＳ１３２において、サービスログ４０９は、もし制限枚数を超えた場合は、認可ステータスを不可に変更する通知をユーザマネジメント４０２に行う。ステップＳ１３３において、サービスログ４０９は、ログを登録した場合、タスクマスタ４０５にログ登録が完了したことを通知する。

ステップＳ１３４において、タスクマスタ４０５は、ログ登録のＯＫ／ＮＧ、又は次のタスク情報をタスクワーカー４１２に出力する。

ステップＳ１３５において、プラグイン１０２は、タスクフロント４０４に対し、タスクの状況をポーリングする。ステップＳ１３６において、プラグイン１０２は、タスクフロント４０４から、タスクの状況を取得する。ここでは、プラグイン１０２は、「成功して終了」のタスク結果を取得する。

ステップＳ１３７、Ｓ１３８において、プラグイン１０２は、タスク結果に含まれる出力ファイルのロケーションにある処理済ファイルをストレージ４０３から取得する。

ここで、図１５は、出力ファイル取得に係るリクエストの一例を示す図である。図１５に示すように、プラグイン１０２からタスク情報で指定されたＵＲＬにある処理済ファイルを取得するリクエストが発行される。この場合のレスポンスは処理済ファイルになる。

なお、出力ファイルの取得に係るアクセス制限として、ストレージ４０３は、
・ タスクを登録したアカウントでないアカウントでのアクセス不可
・ 有効期限が切れたファイルへのアクセス不可
を設定することもできる。

図１０に戻り、ステップＳ１３９において、プラグイン１０２は、処理済ファイルの引き取り終了通知をタスクフロント４０４に行う。ステップＳ１４０において、タスクフロント４０４は、タスクマスタ４０５に対し、引き取り終了通知を行う。

ステップＳ１４１において、タスクマスタ４０５は、サービスログ４０９に対し、引き取りログを記録する。ステップＳ１４２において、サービスログ４０９は、ログ登録ＯＫの通知をタスクマスタ４０５に行う。

ステップＳ１４３において、タスクフロント４０４は、ストレージ４０３に保存されている処理済ファイルに対し、有効期限の再登録を行う。

ステップＳ１４４において、タスクマスタ４０５は、タスクフロント４０４に対し、引き取り処理が完了したことを通知する。ステップＳ１４５において、タスクフロント４０４は、プラグイン１０２に対し、引き取り処理が完了したことを通知する。

ここで、図１６は、引き取り終了通知に係るリクエストとレスポンスの一例を示す図である。図１６（Ａ）は、引き取り終了通知に係るリクエストの一例を示す図である。図１６（Ａ）に示すように、リクエストのパラメータとして、ステータスとファイル削除の期間を含む。

図１６（Ｂ）は、引き取り終了通知に係るレスポンスの一例を示す図である。図１６（Ｂ）に示すように、レスポンスは、登録タスクのロケーション、タスクの処理状況（ｒｅｃｅｉｖｅｄ）、出力ファイルのロケーション、タスク処理サービス名、タスク登録時間、タスク情報更新時間を含む。

また、プラグイン１０２は、処理済ファイルを確実に取得できた場合、引き取り終了通知を行う。この処理を行うことで、すぐにタスク情報及びファイルを削除することができる。この引き取り通知がない場合は、予め決められた期間後にタスク情報及びファイルを削除するようにすればよい。

なお、引き取り終了通知に係るアクセス制限として、タスクフロント４０４は、
・ 登録したアカウントでないアカウントではアクセス不可
・ 処理終了前のタスクへのアクセス不可
・ 有効期限が切れたタスクへのアクセス不可
を設定することもできる。

以上、実施例１によれば、サービス提供側においてセキュリティと処理負荷とを考慮した通信を行なうことができる。また、実施例１によれば、ＭＦＰ側で処理Ａを実行する際、処理ＡにＭＦＰ側で処理できない処理Ｂを含んでいても、サービス提供側ではユーザは介在せずに処理Ｂを行う。ＭＦＰは、処理Ｂが実行されたデータを取得することで、処理Ａを完了することができる。つまり、ＭＦＰ側で実行した処理がサービス提供側でも処理が切れずに（ユーザが介在せずに）処理を完了させることができる。

［実施例２］
次に、実施例２における画像処理サービスについて説明する。実施例２では、サービス提供システムは、ストレージを含む蓄積管理装置を備える構成となっている。

＜機能構成＞
図１７は、実施例２における画像処理システムの機能構成の一例を示すブロック図である。図１７に示すように、実施例２では、サービス提供システム内に、蓄積管理装置７０１を備える。蓄積管理装置７０１は、ユーザマネジメント４０２、ストレージ４０３、タスクフロント４０４、タスクマスタ４０５を含む。蓄積管理装置７０１は、ＯＣＲワーカー４０７を含んだりしてもよい。ＭＦＰ１０は、スキャナ７２１、プリントユニット７２２を含む。

図１７に示す例では、ＭＦＰ１０は、取得した画像（例えば、スキャン画像）に対し、ワークフロー７１０に従って配信を行う。ワークフロー７１０は、例えば、画像処理を行って、印刷をするワークフローとする。画像処理は、例えば、スキャン画像に対してＯＣＲ処理を行って文書データに変換し、変換後の文書データに文書処理（例えば言語変換処理）を行う処理とする。このとき、ＭＦＰ１０は、ワークフローに含まれる画像処理機能を有していないとする。

まず、ＭＦＰ１０では、オペレーションパネル（例えば操作部１７及び表示部１８）でスキャン画像の送信先と、スキャン画像の処理内容とを選択させる画面を表示させる。図１８は、ＭＦＰにおける表示画面の一例を示す図である。図１８に示す画面領域８０１では、スキャン画像の送信先を選択させる選択ボックスが表示される。画面領域８０３では、スキャン画像に対する処理内容（例えば、ワークフロー）を選択させる選択ボックスが表示される。ユーザは、これらの画面領域から所望の選択先と処理内容とを選択する。図１８に示す画面は、例えばワークフロー７１０がユーザに選択された後に表示される。このとき、変換後の言語は、画面領域８０３又は他の画面領域で選択されるようにしてもよい。また、選択された送信先は、蓄積管理装置７０１とする。

図１７に戻り、ＭＦＰ１０から送信されたスキャン画像を処理要求と共にサービス提供システムに送信する。送信されたスキャン画像と処理要求は、ファイアウォール４０１を通過して蓄積管理装置７０１のストレージ４０３に格納される。蓄積管理装置７０１では、格納したスキャン画像に対して、処理要求に含まれるＯＣＲ処理及び言語変換処理のタスクをタスクキュー４０６に登録する。

ＯＣＲワーカー４０７は、タスクマスタ４０５に処理を問合せ、ストレージ４０３に蓄積されたスキャン画像を取得し、ＯＣＲ処理を行ってスキャン画像を文書データに変換する。ＯＣＲワーカー４０７は、処理された文書データをストレージ４０３に格納する。なお、ＯＣＲワーカー４０７は、蓄積管理装置７０１に含まれる構成であってもよい。

トランスレーションワーカー７０２は、タスクマスタ４０５に処理を問合せ、ストレージ４０３から処理された文書データを取得し、言語変換処理を行って、言語変換された文書データをストレージ４０３に格納する。このとき、格納された位置情報は、タスクマスタ４０５を介してタスクフロント４０４に通知される。また、実施例２では、言語変換処理を、Ｗｅｂサービス４１０を用いて行ってよい。

タスクフロント４０４は、要求された画像処理の完了を保持する。このとき、タスクフロント４０４は、処理後のデータの位置情報を完了通知と共に関連付けて保持しておく。

次に、ＭＦＰ１０は、サービス提供システムに対し、処理が完了したかを問い合わせる（ポーリング）。具体的には、画像処理プラグイン７１１は、タスクフロント４０４に対して問合せを行い、処理されたデータが格納される位置情報（例えばＵＲＬ）を取得する。

画像処理プラグイン７１１は、処理されたデータを取得し、印刷プラグインに出力する。ＭＦＰ１０は、印刷プラグインを実行することで、処理されたデータをプリントユニット（印刷手段）７２２により印刷する。

＜サービスの概要＞
図１９は、実施例２におけるサービスの一例の概要を説明する図である。図１９に示す例では、まず、ＭＦＰ１０は、オペレーションパネル上に、スキャン画像の送信先と、処理内容を表示する（図１８参照）。

ここで、ユーザは、送信先としてサービス提供システム内の蓄積管理装置７０１、処理内容としてＯＣＲ後に言語変換を含むワークフローを選択したとする。次に、ユーザは文書をセットしてスキャンの実行ボタンを押下する。

スキャナ７２１は、スキャンの実行ボタンが押下されると、文書を読み取り、スキャン画像９０１を生成する。ＭＦＰ１０は、スキャン画像９０１が生成されると、ネットワークＩ／Ｆ部１６（通信手段）を用いて、スキャン画像９０１と処理内容とをサービス提供システムに送信する。

サービス提供システムは、取得したスキャン画像９０１を処理内容に応じて処理を実行する。ここでは、サービス提供システムは、スキャン画像９０１に対しＯＣＲ処理を実行し、文書データ９０３を生成する。さらに、サービス提供システムは、文書データ９０３に対し、文書処理（例えば、言語変換処理）を実行する。例えば、サービス提供システムは、言語変換処理を実行する場合、日本語の文書データを英語の文書データに変換する。言語変換処理は、言語変換ソフトを用いたり、Ｗｅｂサービスの言語変換アプリケーションを用いたりして実行できる。

変換された文書データ９０５は、ＭＦＰ１０によりネットワークＩ／Ｆ部１６を用いて取得される。ＭＦＰ１０は、取得した文書データ９０５に対しプリントユニット７２２を実行し、印刷データ９０７を出力する。

これにより、ＭＦＰ１０は、要求した処理に対して自装置で処理できない場合でもサービス提供システム側で処理を行わせることができ、このときユーザの介在を必要としない。また、ＭＦＰ１０は、要求した画像処理が行われたデータをサービス提供システムから自動で取得することができ、さらに取得したデータを自動で印刷することも可能になる。

＜他のサービスの概要＞
次に、実施例２におけるサービスの一つであるバックアップ処理について説明する。サービス提供システムに対し、記憶部の容量が少なく、ＣＰＵの処理能力が高くないなどのリソースが乏しいＭＦＰが接続されることが考えられる。そこで、他のサービスでは、このようなＭＦＰ１０の場合、ＭＦＰ１０内部では画像データを大量に保存できないため、他装置の格納部にバックアップをとるサービスを提供する。

ＭＦＰ１０は、例えばバックアップのワークフローが選択されると、バックアップ先のＤＢ（データベース）をユーザに選択させる。ＤＢはウェブサーバであってもよい。ＭＦＰ１０は、文書をスキャナ７２１によりスキャンし、スキャン画像を生成する。次に、ＭＦＰ１０は、サービス提供システムにスキャン画像と格納先の情報とを送信する。

サービス提供システムは、ＭＦＰ１０から取得したスキャン画像を、選択されたＤＢに送信する。ＤＢは、受信したスキャン画像を格納する。サービス提供システムは、ＤＢへの格納が完了しても、スキャン画像を保持しておく。

ＭＦＰ１０は、定期的に処理が完了したかをサービス提供システムに問合せ（ポーリング）、処理が完了していた場合、スキャン画像をサービス提供システムから取得する。ＭＦＰ１０は、取得されたスキャン画像に対しプリントユニット７２２を用いて、印刷データを出力する。

これにより、リソースが乏しいＭＦＰを使用する場合でも、実施例２におけるサービスを利用すればスキャン画像のバックアップをとることができる。なお、リソースが乏しいＭＦＰ以外でも上述したバックアップサービスは適用可能である。

［変形例］
次に、画像処理システムの変形例について説明する。変形例では、実施例１や実施例２のサービス提供システムを直接的にまたは間接的に基幹システムに接続する。以下、実施例２のサービス提供システムを例にして変形例を説明する。基幹システムとは、企業の情報システムのうち、業務内容と直接に関わる販売や在庫管理、財務などを扱うシステムである。基幹システムでは、大量のデータを扱うため、迅速にデータを処理する必要がある。

＜機能構成＞
図２０は、変形例における画像処理システムの機能構成の一例を示すブロック図である。図２０に示すように、画像処理システムは、基幹システム１００１、サーバ１００３、ＭＦＰ１０、サービス提供システムを含む。変形例では、基幹システム１００１で注文を受けて発注したデータの管理の仕方の例について説明する。

図２０に示す基幹システム１００１で、製品の注文を受けたとする。基幹システム１００１は、注文を受けた製品を関係部門へ発注する。このとき、基幹システム１００１は、発注データにＩＤ（例えば発注番号）を付与してサーバ１００３に送信する。発注データには、例えば注文日、発注日、顧客ＩＤ、製品番号などが含まれる。

サーバ１００３は、発注データを取得すると、サービス提供システムに送信する。このとき、サーバ１００３は、データの改ざんを防ぐため、ＱＲコードなどに発注データを変更して送信してもよい。

また、基幹システム１００１は、発注データに基づく発注書１００５を作成し、関係部門でプリントアウトする。プリントアウトされた発注書は、ＭＦＰ１０によりスキャンされてワークフロー１０１に基づきサービス提供システムに送信される。また、ＭＦＰ１０は、配信サーバを用いて、発注書のスキャン画像をサービス提供システムに送信するようにしてもよい。

サービス提供システムに含まれる蓄積管理装置７０１は、サーバ１００３から取得した発注データと、ＭＦＰ１０から取得した発注書のスキャン画像を関連付けて管理する。具体的には、蓄積管理装置７０１は、発注書のスキャン画像に対してＯＣＲ処理を行い、発注番号を取得する。蓄積管理装置７０１は、スキャン画像から取得した発注番号と、サーバ１００３から取得した発注データに付与される発注番号との照合を行う。

蓄積管理装置７０１は、照合の結果、発注番号が一致した発注データとスキャン画像とを関連付けて記憶、管理する。蓄積管理装置７０１は、発注データ、又はスキャン画像のいずれか一つしかないデータをエラーデータとして蓄積、管理する。蓄積管理装置７０１は、エラーデータを管理者にメール送信したりすることができる。

図２１は、発注に関する管理データの一例を示す図である。図２１に示すように、管理データは、発注番号をキーとして、注文日、発注日、製品ＩＤ、顧客ＩＤ、画像が関連付けられる。なお、注文日、発注日、製品ＩＤ、顧客ＩＤは発注データから取得され、画像は、スキャン画像を示す。スキャン画像のデータ形式は、ＴＩＦＦ、ＰＤＦなどの画像データや、ＯＣＲ処理後の文書データでもよい。

また、蓄積管理装置７０１は、発注データがＱＲコードなどにデータ変換されている場合、バーコードワーカー４０８などにデータを読み取らせて発注番号を取得すればよい。

以上、変形例では、基幹システムにサービス提供システムを接続し、基幹システムから出力されるデータの管理を容易にかつ確実に行うことができる。

なお、実施例の画像処理サーバは、ＣＰＵなどの制御装置と、ＲＯＭ（Read Only Memory）やＲＡＭなどの記憶装置と、ＨＤＤ、ＣＤドライブ装置などの外部記憶装置などの装置を備えており、ワークステーションや通常のコンピュータを利用したハードウェア構成となっている。

実施例の画像処理サーバやＭＦＰで実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、実施例の画像処理サーバやのＭＦＰで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、実施例の画像処理サーバやＭＦＰで実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、実施例の画像処理サーバやＭＦＰで実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

実施例の画像処理サーバやＭＦＰで実行されるプログラムは、前述した各手段を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からプログラムを読み出して実行することにより上記各手段が主記憶装置上にロードされ、上記各手段が主記憶装置上に生成されるようになっている。

なお、本発明は、上記実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施例に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施例に示される全構成要素からいくつかの構成要素を削除してもよい。

１０、２０ ＭＦＰ
３０ 画像処理サーバ
４０ 画像管理サーバ
５０ ＤＢ
１０１ ワークフロー
１０２ プラグイン
４０１ ファイアウォール
４０２ ユーザマネジメント
４０３ ストレージ
４０４ タスクフロント
４０５ タスクマスタ
４０６ タスクキュー
４０７ ＯＣＲワーカー
４０８ バーコードワーカー
４０９ サービスログ
４１０ Ｗｅｂサービス
４１１ サービスモニタリング

特開２００６−０１８６４０号公報 特開２００２−２５２７３２号公報

Claims (6)

1. ネットワークを介して画像形成装置とサービス提供システムとを接続し、画像処理を行う画像処理システムであって、
   画像形成装置からのログインを管理し、ログインした画像形成装置に認証チケットを発行するユーザ管理手段と、
   前記認証チケットを付加して画像データを含む画像処理要求を前記サービス提供システムに行うタスク要求手段と、
   前記画像処理要求の不正を検出する検出手段と、
   正当な前記画像処理要求を受信した後、前記ユーザ管理手段にユーザ情報を問い合わせて取得したユーザ情報に、前記サービス提供システムからの内部通信であることを示す識別情報を付加して、前記画像処理要求を行うタスク処理手段と、
   前記識別情報により内部通信であることを確認した後、前記タスク処理手段から取得した画像処理要求を示すタスクをタスクキューに保存し、１又は複数の画像処理手段から前記タスクに対する問合せを受けるタスク管理手段と、
   前記タスクキューに保存されたタスクが示す画像処理要求に対し、処理可能な画像処理要求を取得して画像処理を行う１又は複数の画像処理手段と、
   前記画像処理手段により処理された画像データを格納する格納手段と、
   前記処理された画像データの格納場所を指定して前記画像データを取得する取得手段と、
   を備える画像処理システム。
2. 前記ユーザ管理手段は、
   前記認証チケットに、ユーザＩＤ、セッションＩＤを含め、
   前記タスク処理手段からの問合せに対し、セッションＩＤが正しければ、ユーザＩＤに対応するユーザ名を前記ユーザ情報に含める請求項１に記載の画像処理システム。
3. 前記タスク処理手段は、
   前記ユーザ情報と前記識別情報を拡張ヘッダに含めたＨＴＴＰリクエストを用いて前記タスク管理手段に前記画像処理要求を行う請求項２記載の画像処理システム。
4. 前記画像処理手段は、
   前記タスク管理手段から前記ＨＴＴＰリクエストに含まれる前記ユーザ情報を取得し、取得したユーザ権限により、画像処理を行った画像データを前記格納手段に格納する請求項３記載の画像処理システム。
5. ネットワークを介して接続される画像形成装置からの画像処理要求を管理する画像処理装置であって、
   画像形成装置からのログインを管理し、ログインした画像形成装置に認証チケットを発行するユーザ管理手段と、
   正当な認証チケットを含む前記画像処理要求を受信した後、前記ユーザ管理手段にユーザ情報を問い合わせて取得し、該ユーザ情報を含めて前記画像処理要求を行うタスク処理手段と、
   前記タスク処理手段から取得した画像処理要求を示すタスクをタスクキューに保存し、１又は複数の画像処理手段から前記タスクに対する問合せを受けるタスク管理手段と、
   を備える画像処理装置。
6. ネットワークを介して画像形成装置とサービス提供システムとを接続し、画像処理を行う画像処理システムにおける画像処理方法であって、
   画像形成装置からのログインを管理し、ログインした画像形成装置に認証チケットをユーザ管理手段により発行する発行ステップと、
   前記認証チケットを付加して画像データを含む画像処理要求を前記サービス提供システムに行うタスク要求ステップと、
   前記画像処理要求の不正を検出する検出ステップと、
   正当な前記画像処理要求を受信した後、前記ユーザ管理手段にユーザ情報を問い合わせて取得したユーザ情報に、当該サービス提供システム内部からの通信であることを示す識別情報を付加して、前記画像処理要求を行うタスク処理ステップと、
   前記識別情報により内部通信であることを確認した後、前記タスク処理ステップにより要求された画像処理要求を示すタスクをタスクキューに保存する保存ステップと、
   前記タスクキューに保存されたタスクが示す画像処理要求に対し、処理可能な画像処理要求を取得して画像処理を行う画像処理ステップと、
   前記画像処理ステップにより処理された画像データを格納手段に格納する格納ステップと、
   前記処理された画像データの格納場所を指定して前記画像データを取得する取得ステップと、
   を有する画像処理方法。

Images