JP2014149809A - 情報処理システム、情報処理装置、プログラム及び処理実行方法 - Google Patents

Abstract

【課題】処理の種類の増加に柔軟に対応可能な情報処理システム、情報処理装置、プログラム及び処理実行方法を提供することを課題とする。
【解決手段】情報処理装置を含むように構成される情報処理システムであって、処理実行要求を処理の種類により振り分ける管理手段と、振り分けられた処理実行要求を処理の種類ごとに保持する保持手段と、保持された処理実行要求に対応した処理を実行する複数の実行手段とを備え、複数の実行手段の少なくとも１つは、保持手段が保持する処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を他の実行手段に連携させて実行させる処理実行要求を保持手段に保持させることにより、上記課題を解決する。
【選択図】 図４

Description

本発明は、情報処理システム、情報処理装置、プログラム及び処理実行方法に関する。

従来、デバイスと、ウェブサービスと、分散環境を提供するプラットフォームとを連携させることを目的としたクラウドコンピューティングシステムは知られている（例えば特許文献１参照）。

従来のクラウドコンピューティングシステムは、画像形成装置からのジョブの処理依頼を受信する要求受信部と、ジョブに対応するメッセージに基づく処理を行うバックエンド処理部と、バックエンド処理部の数を管理する管理手段とを有している。

バックエンド処理部は、ジョブのタスク実行状況を特定する特定手段と、ジョブのタスク実行状況に応じたタスクサービスを、サービス提供装置が提供する複数のタスクサービスの中から選択し、サービス提供装置に実行を指示する指示手段とを有している。

例えば、あるデータ形式から他のデータ形式に変換する際、プログラムの独立性やメンテナンス性を高めるために、データ形式を変換するデータ変換エンジン（データ変換プログラム又はデータ変換ライブラリ）を用いる場合がある。

データ形式の変換に限らず、何らかの処理を実行する際、プログラムの独立性やメンテナンス性を高めるために、何らかの処理を実行する処理実行エンジン（処理実行プログラム又は処理実行ライブラリ）を用いる場合がある。

しかしながら、データ形式の種類が多数の場合には入力データ形式の種類と出力データ形式の種類のペア分のデータ変換エンジンが必要になる。例えば、変換前のデータ形式の候補が３種類あり、変換後のデータ形式の候補が３種類あると、それぞれのパターンに応じたデータ変換エンジンを９種類用意する必要がある。すなわち、変換前又は変換後のデータ形式の選択肢が多くなればなるほど、用意しなければならないデータ変換エンジンの数が増える。このように、実行する処理の種類が多数の場合には処理の種類分の処理実行エンジンが必要となる。

要約すると、データ変換処理など実行する処理の種類が多くなればなるほど、用意しなければならない処理実行エンジンの数が増えることが想定されるが、処理の種類の増加に柔軟に対応できないことが課題である。

本発明の実施の形態は、上記の点に鑑みなされたもので、処理の種類の増加に柔軟に対応可能な情報処理システム、情報処理装置、プログラム及び処理実行方法を提供することを目的とする。

上記目的を達成するために本願請求項１は、一以上の情報処理装置を含むように構成される情報処理システムであって、処理実行要求を処理の種類により振り分ける管理手段と、振り分けられた前記処理実行要求を処理の種類ごとに保持する保持手段と、保持された前記処理実行要求に対応した処理を実行する複数の実行手段とを備え、前記複数の実行手段の少なくとも１つは、前記保持手段が保持する前記処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させることを特徴とする。

本発明の実施の形態によれば、処理の種類の増加に柔軟に対応可能となる。

クラウドプリントの一例を表した模式図である。 クラウドプリントを実現する情報処理システムの構成例を示すブロック図である。 クラウドプリントの手順の一例を表したフローチャートである。 本実施形態のデータ変換システムの構成例を示すブロック図である。 変換手段の詳細な構成を示すブロック図である。 非同期変換サーバの動作を示すシーケンス図である。 ジョブの情報に含まれるタスクの分割例を表した説明図である。 分割前及び分割後のジョブフォーマットの一例を表した説明図である。 複数の変換エンジンの連携による処理の一例を表した説明図である。 画像ファイルをＯＣＲ処理してオンラインストレージに保存する処理の一例を表した模式図である。 画像ファイルをＯＣＲ処理してオンラインストレージに保存する処理を実現する情報処理システムの構成例を示すブロック図である。 本実施形態の処理実行システムの構成例を示すブロック図である。 実行手段の詳細な構成を示すブロック図である。 非同期処理サーバの動作を示すシーケンス図である。 ジョブの情報に含まれるタスクの分割例を表した説明図である。 第３の実施形態に係るシステムの一例の構成図である。 コンピュータシステムの一例のハードウェア構成図である。 第３の実施形態に係るサービス提供システムの一例の処理ブロック図である。 組織管理情報の一例の構成図である。 ユーザ管理情報の一例の構成図である。 機器管理情報の一例の構成図である。 第３の実施形態におけるデータ変換処理の一例について説明する説明図である。 キューとデータ形式変換部との対応付けの一例について説明する説明図である。 変換要求のリクエストを分割する処理の一例について説明する説明図である。 変換要求のリクエストを分割する処理の一例について説明する説明図である。 変換要求のリクエストを分割する処理の一例について説明する説明図である。 ステップＳ３０４の処理の一例について説明する説明図である。 ジョブａの実行結果を書き込まれたあとのジョブ管理情報の一例のデータ構造図である。 ステップＳ３０８の処理の一例について説明する説明図である。 ジョブｂの実行結果を書き込まれたあとのジョブ管理情報の一例のデータ構造図である。 ステップＳ３１２の処理の一例について説明する説明図である。 ジョブｃの実行結果を書き込まれたあとのジョブ管理情報の一例のデータ構造図である。 ジョブを処理する順序に優先度を付けないデータ変換システムの構成例を示すブロック図である。 ジョブを処理する順序に優先度を付けるデータ変換システムの構成例を示すブロック図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜クラウドプリント＞
図１はクラウドプリントの一例を表した模式図である。クラウドプリントとは、クラウドコンピューティング型のプリントサービスである。ステップＳ１において、インプット側機器の一例としてのＰＣ（パーソナルコンピュータ）１２は例えばワードプロセッサアプリケーションなどで作成した電子文書ファイルをクラウド１０上のサーバ１１にアップロードする。

ステップＳ２において、サーバ１１はアップロードされた電子文書ファイルを例えばＲＰＣＳ（株式会社リコーが開発したページ記述言語）のプリントデータに変換する。アウトプット側機器の一例としてのＭＦＰ（複合機）１３はステップＳ３において、クラウド１０上からプリントデータを受信し、出力する。

クラウド１０側から見ると、ＰＣ１２とＭＦＰ１３とはクライアントとなる。クライアントであるＰＣ１２とＭＦＰ１３とは、クラウド１０上のサーバ１１と通信を行い、所与の目的を達成する。

クラウドプリントではクラウド１０上でデータ変換処理を行うため、クライアントであるＰＣ１２にデータ変換エンジンを持つ必要がない。ところが、クラウド１０側で用意するデータ変換エンジンは多種多様な電子文書ファイルに対応する必要がある。また、電子文書ファイルの種類は今後も増えていく可能性がある。出力に関しても、データ変換エンジンはアウトプット側機器がＭＦＰ１３である場合の他、プロジェクタや、或いは全く未知の機器への出力に対応する可能性がある。さらに、データ変換エンジンは別のクラウドサービスで利用できるデータ形式に対応する可能性もあり得る。

このような事情は、データ変換処理と同様、何らかの処理を実行するクラウド１０側において共通の課題であると言える。例えばＭＦＰ１３でスキャンした画像をクラウド１０側でＯＣＲ（Optical Character Reader）処理して、別のクラウドサービスが提供するオンラインストレージに保存する場合も共通の課題を有する。

また、別のクラウドサービスが提供するオンラインストレージからファイルを読み出してプリントデータ（印刷ファイル）への変換やＯＣＲ処理などのデータ変換処理を行う場合も共通の課題を有する。

以下では、クラウドプリントを一例として説明するが、クラウドプリントに限定されるものではない。例えば上記したようなＭＦＰ１３でスキャンした画像をクラウド１０側でＯＣＲ処理して、別のクラウドサービスが提供するオンラインストレージに保存する処理にも適用可能である。また、上記したようなクラウドサービスが提供するオンラインストレージからファイルを読み出してプリントデータへの変換やＯＣＲ処理などを行う処理にも適用可能である。

図１に示すクラウドプリントは、図２に示すようなクラウドコンピューティング型の情報処理システムで構成される。図２はクラウドプリントを実現する情報処理システムの構成例を示すブロック図である。

ローカル側にはＰＣ１２、ＭＦＰ１３が存在する。ＰＣ１２及びＭＦＰ１３は、ＬＡＮなどのネットワーク上のゲートウェイ等に設置されているファイヤウォール１０３を介してインターネットなどのネットワークに接続する。なお、クラウドプリントではＰＣ１２とＭＦＰ１３とが同一のネットワーク上にあってもよいし、なくてもよい。以下ではＰＣ１２とＭＦＰ１３とが同一のネットワーク上にないと仮定して説明する。

図２において、クラウド側は、データ変換システム１００、印刷ジョブ管理サーバ１０２、リバースプロキシ１０４、認証サーバ１０５及び認証用データベース１０６を有する構成である。

データ変換システム１００は、非同期変換サーバ１０１、共有ファイルストレージ１０７及びジョブ情報管理データベース１０８を有する。なお、共有ファイルストレージ１０７はデータ変換システム１００の外側に置く設計としてもよい。さらに、図４に示すようにジョブ情報管理データベース１０８は非同期変換サーバ１０１の一部として含まれる構成としてもよい。

ローカル側の機器であるＰＣ１２、ＭＦＰ１３はリバースプロキシ１０４によって通信が仲介されることで、クラウド側のサーバ群やストレージの内部構造を意識した処理や通信をする必要がない。また、認証サーバ１０５と認証用データベース１０６とは、ユーザ及び／又はローカル側の機器であるＰＣ１２、ＭＦＰ１３の認証を行う。

データ変換システム１００と印刷ジョブ管理サーバ１０２とは、ローカル側の機器であるＰＣ１２がアップロードした印刷ジョブを管理／登録する。ローカル側の機器であるＭＦＰ１３から印刷要求があった場合、データ変換システム１００と印刷ジョブ管理サーバ１０２とはプリントデータをＭＦＰ１３に送信する。

印刷ジョブには、ワードプロセッサアプリケーションなどで作成した電子文書ファイルが含まれる。データ変換システム１００は、印刷ジョブに含まれる電子文書ファイルを例えばＭＦＰ１３で出力可能なデータ形式（ページ記述言語（ＰＤＬ））の電子データであるプリントデータに変換する。

図２に示した情報処理システムの利用例について図３を参照して説明する。図３はクラウドプリントの手順の一例を表したフローチャートである。

ステップＳ１０１において、ユーザはＰＣ１２からクラウドプリントサービスにログインする。認証処理は認証サーバ１０５が実行する。ステップＳ１０２において、ユーザは印刷したい電子文書ファイルを、ＰＣ１２からクラウドプリントサービスにアップロードする。ステップＳ１０２の処理が印刷ジョブの登録である。印刷ジョブの登録処理は印刷ジョブ管理サーバ１０２が実行する。ここまでがＰＣ１２から行われる手順である。

印刷ジョブが登録されると、本実施形態のクラウドプリントサービスはバックグラウンドでデータ変換処理を行う。つまり、クラウドプリントサービスは非同期処理の一例としてデータ変換処理を実現している。

ステップＳ１０３において、印刷ジョブ管理サーバ１０２は登録された電子文書ファイルのデータ変換をデータ変換システム１００に依頼する。ここで行われるデータ変換処理の詳細については後述する。

ユーザは印刷する場合、ＭＦＰ１３にて以下の一連の手順を行う。ステップＳ１０４において、クラウド側はＭＦＰ１３がクラウドプリントサービスに対応の機器であるかを確かめる。機器としての認証である。次に、ステップＳ１０５において、ユーザはＭＦＰ１３を操作してクラウドプリントサービスにログインする。ユーザとしての認証である。

認証後、ＭＦＰ１３はステップＳ１０６においてジョブ一覧をクラウドプリントサービスから取得し、操作パネルなどの表示手段に表示する。次にユーザはステップＳ１０７において、表示されているジョブ一覧の中から印刷を所望する印刷ジョブを選択する。

ユーザにより印刷ジョブを選択されると、ＭＦＰ１３はステップＳ１０８においてクラウドプリントサービスから印刷ジョブを取得し、出力する。クラウドプリントサービスはＰＣ１２にＭＦＰ１３のプリンタドライバ（データ変換エンジン）を用意する必要がないので、例えば、会議資料を作成／アップロードしておき、海外出張時に現地で印刷するような用途に有効である。

《データ変換システム》
本実施形態に係るデータ変換システム１００は、多種多様なデータ変換要求に応えるため、また、データ変換要求の種類の増加に柔軟に対応するため、以下に説明する構成を備える。図４に、データ変換システム１００の機能構成を示す。図４は本実施形態のデータ変換システムの構成例を示すブロック図である。

図４に示すように、データ変換システム１００は、フロントエンドアプリケーション１０２ａと、共有ファイルストレージ１０７と、非同期変換サーバ１０１とを含む。フロントエンドアプリケーション１０２ａは印刷ジョブ管理サーバ１０２の一機能である。非同期変換サーバ１０１は非同期変換サービスを提供する。また、非同期変換サーバ１０１はデータ変換要求管理手段１１１と、メッセージキュー１１２と、ジョブ情報管理データベース１０８と、複数の変換手段１２０を含む構成である。

印刷ジョブ管理サーバ１０２は、インプット側機器の一例としてのＰＣ１２から送信された印刷ジョブを受信して、印刷ジョブに含まれる電子文書ファイル等を共有ファイルストレージ１０７に登録する機能を備える。また、印刷ジョブ管理サーバ１０２は、必要なファイル変換を判断して、データ変換システム１００に変換を実行させる制御を行う。

データ変換システム１００は処理の単位であるタスクを定義し、複数のタスクをジョブとして取り扱う。データ変換システム１００は、メッセージキュー１１２にジョブを登録しておき、変換手段１２０がジョブを一つずつ処理していく。変換手段１２０は例えばＷｏｒｋｅｒにより実現される。

変換後のファイルは共有ファイルストレージ１０７に登録される。例えばアウトプット側機器の一例としてのＭＦＰ１３から印刷ジョブの出力指示を受信すると、印刷ジョブ管理サーバ１０２は共有ファイルストレージ１０７に登録された変換後のファイルをＭＦＰ１３に送信する。

フロントエンドアプリケーション１０２ａは、出力指示の実行に必要なファイル変換を判断する機能を備える。フロントエンドアプリケーション１０２ａは例えば電子ファイルがドキュメントファイルであり、出力指示を送信するＭＦＰ１３がＲＰＣＳ対応の機種である場合、ドキュメントファイルのデータ形式からＲＰＣＳのデータ形式へのデータ変換が必要と判断する。

フロントエンドアプリケーション１０２ａは判断したデータ変換の種類を例えば「ｔｙｐｅ＝ｄｏｃ２ｒｐｃｓ」のようなパラメータにして、非同期変換サーバ１０１に送信するリクエスト（ジョブ）に埋め込む。

同様に、変換元のデータのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）もパラメータとしてリクエストに埋め込む。ＵＲＩは共有ファイルストレージ１０７におけるデータの存在する場所の情報である。

データ変換の種類とデータのＵＲＩを少なくとも含むリクエストを受け取った非同期変換サーバ１０１では、データ変換要求管理手段１１１がリクエストを受け取る。データ変換要求管理手段１１１は、データ変換に係るリクエストを解析して、データ変換の種類に合致するメッセージキュー１１２に、ジョブ（メッセージ）を入れる。

データ変換要求管理手段１１１は、メッセージキュー１１２へメッセージを入れることと同時に並行して、ジョブ情報管理データベース１０８に、当該リクエストの情報を登録又は更新する。

ジョブ情報管理データベース１０８に登録される情報は、ファイルの場所（共有ファイルストレージ１０７上のＵＲＩ）、リクエストに含まれるデータ変換の種類、当該リクエストの状態などである。リクエストの状態としては「データ変換実行中」「データ変換中継中」「データ変換完了」などがある。リクエストの状態は、データ変換の処理状況を示すステータスを表す。

メッセージキュー１１２は複数の変換手段１２０に対応するキューを有する。図４では変換手段１２０とメッセージキュー１１２が有するキューとが一対一に対応する例を示しているが、多対多に対応していてもよい。

各変換手段１２０は、その変換手段１２０に対応するキューを監視しており、キューにメッセージが入ると、ジョブ情報管理データベース１０８に登録された、そのメッセージに対応するリクエストの情報を取りに行く。各変換手段１２０は、ジョブ情報管理データベース１０８から取得したリクエストの情報に含まれるＵＲＩに基づいて、共有ファイルストレージ１０７上のデータを取得する。

そして、各変換手段１２０は取得したデータの変換を行う。各変換手段１２０は、変換後のデータを共有ファイルストレージ１０７上に登録し、ジョブ情報管理データベース１０８上に登録されたリクエストの情報を書き換えて更新する。また、後述するように連携してデータ変換する場合、各変換手段１２０はデータ変換した後、新たなメッセージを次にデータ変換を行う変換手段１２０のキューに入れる。

複数の変換手段１２０は、図５に示すように、変換処理ライブラリ１２０ａと変換エンジン１２０ｂを備える構成である。変換処理ライブラリ１２０ａは、その変換手段１２０に対応するキューを監視する処理や、変換後のデータを共有ファイルストレージ１０７上に登録する処理などを実行する。

また、変換処理ライブラリ１２０ａはジョブ情報管理データベース１０８上に登録されたリクエストの情報を書き換えて更新する処理などを行う。また、変換処理ライブラリ１２０ａは連携してデータ変換する場合にデータ変換後の新たなメッセージを次にデータ変換を行う変換手段１２０のキューに入れる処理などを実行する。

変換エンジン１２０ｂとしては、例えば、以下のようなものがある。
・ｄｏｃ２ｒｐｃｓ：ドキュメントファイルなどの電子文書ファイルをＲＰＣＳに変換するエンジン
・ｐｄｆ２ｒｐｃｓ：ＰＤＦ（Portable Document Format）ファイルをＲＰＣＳに変換するエンジン
・ｉｍｇ２ｐｄｆ：画像ファイルをＰＤＦに変換するエンジン
・ｈｔｍｌ２ｐｄｆ：ＨＴＭＬ（Hyper Text Markup Language）ファイルをＰＤＦに変換するエンジン
・ｔｘｔ２ｐｄｆ：テキストファイルをＰＤＦに変換するエンジン
（非同期変換サービス）
図４に示す非同期変換サーバ１０１による非同期変換サービスの流れについて、図６のシーケンス図を参照して説明する。図６は非同期変換サーバの動作を示すシーケンス図である。

ステップＳ１１において、フロントエンドアプリケーション１０２ａは共有ファイルストレージ１０７に登録しておいたデータに対するデータ変換の要求（ジョブ登録依頼）を非同期変換サーバ１０１のデータ変換要求管理手段１１１に対して行う。つまり、非同期変換サービスは、フロントエンドアプリケーション１０２ａが共有ファイルストレージ１０７に登録しておいたデータに対するデータ変換の要求（リクエスト）をデータ変換要求管理手段１１１に送信すると始まる。

ステップＳ１１で送信されるリクエストはデータ変換の種類が例えば「ｔｙｐｅ＝ｄｏｃ２ｒｐｃｓ」のようなパラメータにより埋め込まれている。また、リクエストには変換しようとしているデータのＵＲＩ（Uniform Resource Indicator）もパラメータで埋め込まれている。

ステップＳ１２において、ジョブを受信したデータ変換要求管理手段１１１はジョブを解析して、データ変換の種類に合致する変換手段１２０があるか否かを判定する。データ変換の種類に合致する変換手段１２０がある場合、データ変換要求管理手段１１１は、その変換手段１２０に対応するメッセージキュー１１２のキューに、ジョブを登録する。

ステップＳ１３において、データ変換要求管理手段１１１はジョブ登録結果をフロントエンドアプリケーション１０２ａに返す。ここでは、第１の変換手段１２１に対応するメッセージキュー１１２のキューにジョブが登録されたものとして説明を続ける。

ステップＳ１４において、自身が処理できるジョブに対応するキューを監視している第１の変換手段１２１はキューにジョブが登録されたことを検知する。ステップＳ１５において、第１の変換手段１２１はキューに登録されたジョブの情報をジョブ情報管理データベース１０８から取得する。

第１の変換手段１２１は取得したジョブの情報に含まれるタスクの内容を解析し、そのタスクを変換手段１２０でデータ変換できる種類のタスクに分割する。ステップＳ１５におけるタスクの分割は、例えば図７のように行われる。

図７はジョブの情報に含まれるタスクの分割例を表した説明図である。図７ではデータ変換の種類が「ｈｔｍｌ２ｒｐｃｓ」である例を表している。データ変換の種類「ｈｔｍｌ２ｒｐｃｓ」はＨＴＭＬファイルをＲＰＣＳに変換するものである。なお、本実施形態では一つの変換手段１２０でＨＴＭＬファイルをＲＰＣＳファイル（プリントデータ）にできないものとする。

そこで、フロントエンドアプリケーション１０２ａは複数の変換手段１２０を連携させて「ｈｔｍｌ２ｒｐｃｓ」をデータ変換させる。フロントエンドアプリケーション１０２ａは例えば「ｈｔｍｌ２ｒｐｃｓ」のタスクを「ｈｔｍｌ２ｐｄｆ」及び「ｐｄｆ２ｒｐｃｓ」の二つのタスクに分割する第１の変換手段１２１に対応するメッセージキュー１１２のキューにジョブを登録する。第１の変換手段１２１は「ｈｔｍｌ２ｒｐｃｓ」のタスクを「ｈｔｍｌ２ｐｄｆ」及び「ｐｄｆ２ｒｐｃｓ」の二つのタスクに分割する。第１の変換手段１２１は、次に行うタスクに対応するキューに、それぞれのタスクを含むジョブを再登録することで、複数の変換手段１２０を連携させたデータ変換が可能となる。

図８は分割前及び分割後のジョブフォーマットの一例を表した説明図である。図８に示すジョブフォーマットはＪＳＯＮ形式の例である。

図８（Ａ）は分割前のジョブフォーマットの一例を表している。図８（Ａ）はデータ変換の種類が「ｈｔｍｌ２ｒｐｃｓ」のタスクが含まれる。例えばデータ変換の種類「ｈｔｍｌ２ｐｄｆ」のデータ変換が可能な第２の変換手段１２２と、データ変換の種類「ｐｄｆ２ＲＰＣＳ」のデータ変換が可能な第３の変換手段１２３とが存在するものとして説明する。また、データ変換の種類「ｈｔｍｌ２ｒｐｃｓ」のデータ変換が可能な変換手段１２０が存在しないものとして説明する。

本実施形態では「ｈｔｍｌ２ｒｐｃｓ」のタスクを「ｈｔｍｌ２ｐｄｆ」及び「ｐｄｆ２ｒｐｃｓ」の二つのタスクに分割する第１の変換手段１２１を用意して、図８（Ａ）のジョブフォーマットを図８（Ｂ）のジョブフォーマットに変更する。図８（Ｂ）は「ｈｔｍｌ２ｒｐｃｓ」のタスクを分割した「ｈｔｍｌ２ｐｄｆ」及び「ｐｄｆ２ｒｐｃｓ」の二つのタスクが含まれている。

第１の変換手段１２１は変換手段１２０で変換できないデータ変換の種類のタスクを含むジョブから第２の変換手段１２２及び第３の変換手段１２３で変換できるデータ変換の種類のタスクを含むジョブを生成する。第１の変換手段１２１は第２の変換手段１２２及び第３の変換手段１２３で変換できるデータ変換の種類のタスクを含むジョブを生成することにより、第２の変換手段１２２と第３の変換手段１２３とを連携させたデータ変換を実現している。

図６に戻り説明を続ける。ステップＳ１６において、第１の変換手段１２１は分割したタスクを含むジョブを、次に行うタスク（例えばｈｔｍｌ２ｐｄｆ）のデータ変換の種類に対応するキューに登録する。ステップＳ１７において、自身が処理できるジョブに対応するキューを監視している第２の変換手段１２２はキューにジョブが登録されたことを検知する。

ステップＳ１８において、第２の変換手段１２２はキューに登録されたジョブの情報をジョブ情報管理データベース１０８から取得する。第２の変換手段１２２はジョブの情報を解析し、先頭のタスクの情報に含まれるＵＲＩに基づいて共有ファイルストレージ１０７上のデータを取得し、先頭のタスクの情報に含まれるデータ変換の種類に応じたデータの変換を行う。

第２の変換手段１２２は、変換後のデータを共有ファイルストレージ１０７上に登録又は更新する。また、第２の変換手段１２２は変換したことを表すために、ジョブ情報管理データベース１０８に登録されているジョブの情報を更新する。このとき、リクエストの状態が例えば「データ変換中継中」に更新される。

そして、ステップＳ１９において、第２の変換手段１２２はジョブの情報から先頭のタスク（処理済み）の情報を削除し、次に行うタスク（例えばｐｄｆ２ＲＰＣＳ）のデータ変換の種類に対応するキューに、残りのタスクを含むジョブを登録する。

ステップＳ２０において、自身が処理できるジョブに対応するキューを監視している第３の変換手段１２３はキューにジョブが登録されたことを検知する。ステップＳ２１において、第３の変換手段１２３はキューに登録されたジョブの情報をジョブ情報管理データベース１０８から取得する。

第３の変換手段１２３はジョブの情報を解析し、先頭のタスクの情報に含まれるＵＲＩに基づいて共有ファイルストレージ１０７上のデータを取得し、先頭のタスクの情報に含まれるデータ変換の種類に応じたデータの変換を行う。

第３の変換手段１２３は、変換後のデータを共有ファイルストレージ１０７上に登録又は更新する。また、第３の変換手段１２３は変換したことを表すために、ジョブ情報管理データベース１０８に登録されているジョブの情報を更新する。このとき、リクエストの状態が例えば「データ変換完了」に更新される。そして、ステップＳ２２において、第３の変換手段１２３はジョブの情報から先頭のタスク（処理済み）の情報を削除し、次に行うタスクがジョブの情報に含まれていないため、他のキューにジョブを登録することなく処理を終了する。

上述した動作により、本実施形態では直接変換する変換手段１２０が存在しない変換要求のリクエストを満足する変換手段１２０を用意するのではなく、複数の既存の変換エンジン１２０を組み合わせ連携させることで、変換要求を処理できるようになる。

データ変換のリクエストの種類は、上述したように、データ変換システム１００を立ち上げたあとに増加する可能性がある。これに対して、本実施形態によれば図９に示すように柔軟に対応することができるようになる。

また、本実施例によれば、フロントエンドアプリケーション１０２ａは変換手段１２０のタスクを一つ含むジョブを登録することで、複数の変換手段１２０が処理することを意識することなく、複数のタスクを実行できる。

なお、変換手段１２０の種類としては、上記実施形態のものに限定されない。データ変換を行う変換手段１２０以外にも、例えば、バーコード画像のデータを文字列のデータに変換する変換手段１２０や、画像ファイルのデータからＯＣＲ処理して、文字列のデータに変換する変換手段１２０など、種々のものが考えられる。また、上記実施形態は、矛盾しない範囲で適宜組み合わせて適用することも可能である。
［第２の実施形態］
第２の実施形態は、前述した第１の実施形態と一部を除いて同様であるため、同一部分について適宜説明を省略する。

＜画像ファイルをＯＣＲ処理してオンラインストレージに保存＞
図１０は画像ファイルをＯＣＲ処理してオンラインストレージに保存する処理の一例を表した模式図である。

ステップＳ３１において、インプット側機器の一例としてのＭＦＰ１３は例えば原稿をスキャンして画像データ（画像ファイル）を作成する。ステップＳ３２において、ＭＦＰ１３は作成した画像ファイルをクラウド１０上のサーバ１１にアップロードする。

ステップＳ３３において、サーバ１１はアップロードされた画像ファイルをＯＣＲ処理して、テキストファイルに変換する。ステップＳ３４において、サーバ１１は変換したテキストファイルを例えばクラウド１０上のオンラインストレージ１４に保存する。例えばクラウド１０上のオンラインストレージ１４の種類は今後も増加が予想される。

したがって、ＭＦＰ１３でスキャンした画像をクラウド１０側でＯＣＲ処理して、別のクラウドサービスが提供するオンラインストレージ１４に保存する場合も、データ変換処理と同様の課題を有する。

図１０に示す画像ファイルをＯＣＲ処理してオンラインストレージに保存する処理は図１１に示すようなクラウドコンピューティング型の情報処理システムで構成される。図１１は画像ファイルをＯＣＲ処理してオンラインストレージに保存する処理を実現する情報処理システムの構成例を示すブロック図である。

ローカル側にはＭＦＰ１３が存在する。ＭＦＰ１３はファイヤウォール１０３を介してインターネットなどのネットワークに接続する。図１１において、クラウド側は、処理実行システム２００、ジョブ管理サーバ２０２、リバースプロキシ１０４、認証サーバ１０５及び認証用データベース１０６を有する構成である。

図１０のブロック図はローカル側からＰＣ１２が削除されている点と、データ変換システム１００が処理実行システム２００に変更されている点と、印刷ジョブ管理サーバ１０２がジョブ管理サーバ２０２に変更されている点と、が図２のブロック図と異なる。図１１の処理実行システム２００が実行する処理は画像ファイルのＯＣＲ処理やオンラインストレージへテキストファイルを保存する処理の他、第１の実施形態で説明したデータ変換処理も含ませることができる。

処理実行システム２００は、非同期処理サーバ２０１、共有ファイルストレージ２０７及びジョブ情報管理データベース２０８を有する。なお、共有ファイルストレージ２０７は第１の実施形態の共有ファイルストレージ１０７と同様である。ジョブ情報管理データベース２０８も第１の実施形態のジョブ情報管理データベース１０８と同様である。

処理実行システム２００とジョブ管理サーバ２０２とは、ローカル側の機器であるＭＦＰ１３がアップロードしたジョブを管理／登録する。処理実行システム２００はジョブに含まれる画像ファイルをＯＣＲ処理してテキストファイルに変換する。処理実行システム２００はＯＣＲ処理により画像ファイルから変換したテキストファイルをオンラインストレージ１４に保存する。ジョブにはＭＦＰ１３でスキャンして作成した画像ファイルが含まれる。

《処理実行システム》
本実施形態に係る処理実行システム２００は、多種多様な処理実行要求や処理実行要求の種類の増加に柔軟に対応するため、以下に説明する構成を備える。図１２に、処理実行システム２００の機能構成を示す。図１２は本実施形態の処理実行システムの構成例を示すブロック図である。

図１２に示すように、処理実行システム２００は、フロントエンドアプリケーション２０２ａと、共有ファイルストレージ２０７と、非同期処理サーバ２０１とを含む。フロントエンドアプリケーション２０２ａはジョブ管理サーバ２０２の一機能である。非同期処理サーバ２０１は非同期処理サービスを提供する。また、非同期処理サーバ２０１は処理実行要求管理手段２１１と、メッセージキュー２１２と、ジョブ情報管理データベース２０８と、複数の実行手段２２０を含む構成である。

ジョブ管理サーバ２０２は、インプット側機器の一例としてのＭＦＰ１３から送信されたジョブを受信して、ジョブに含まれる画像ファイル等を共有ファイルストレージ２０７に登録する機能を備える。また、ジョブ管理サーバ２０２は、実行が必要な処理を判断して処理実行システム２００に処理を実行させる制御を行う。

処理実行システム２００は処理の単位であるタスクを定義し、複数のタスクをジョブとして取り扱う。処理実行システム２００は、メッセージキュー２１２にジョブを登録しておき、実行手段２２０がジョブを一つずつ処理していく。実行手段２２０は例えばＷｏｒｋｅｒにより実現される。実行手段２２０は、例えばインプット側機器の一例としてのＭＦＰ１３から送信された画像ファイルをＯＣＲ処理してオンラインストレージ１４に保存する。

フロントエンドアプリケーション２０２ａは必要な処理を判断する機能を備える。フロントエンドアプリケーション２０２ａは判断した処理の種類をパラメータにして、非同期処理サーバ２０１に送信するリクエスト（ジョブ）に埋め込む。同様に、処理を実行する画像ファイルのＵＲＩもパラメータとしてリクエストに埋め込む。

処理の種類と画像ファイルのＵＲＩを少なくとも含むリクエストを受け取った非同期処理サーバ２０１では、処理実行要求管理手段２１１がリクエストを受け取る。処理実行要求管理手段２１１は処理に係るリクエストを解析して、処理の種類に合致するメッセージキュー２１２に、ジョブ（メッセージ）を入れる。

処理実行要求管理手段２１１は、メッセージキュー２１２へメッセージを入れることと同時に並行して、ジョブ情報管理データベース２０８に、当該リクエストの情報を登録又は更新する。ジョブ情報管理データベース２０８に登録される情報は、画像ファイルなどのファイルの場所（共有ファイルストレージ２０７上のＵＲＩ）、リクエストに含まれる処理の種類、当該リクエストの状態などである。

メッセージキュー２１２は複数の実行手段２２０に対応するキューを有する。図１２では実行手段２２０とメッセージキュー２１２が有するキューとが一対一に対応する例を示しているが、多対多に対応していてもよい。

各実行手段２２０は、その実行手段２２０に対応するキューを監視しており、キューにメッセージが入ると、ジョブ情報管理データベース２０８に登録された、そのメッセージに対応するリクエストの情報を取りに行く。各実行手段２２０は、ジョブ情報管理データベース２０８から取得したリクエストの情報に含まれるＵＲＩに基づいて、共有ファイルストレージ２０７上のデータを取得する。

そして、各実行手段２２０は取得したデータの処理を行う。各実行手段２２０は、処理後のデータを共有ファイルストレージ２０７上に登録し、ジョブ情報管理データベース２０８上に登録されたリクエストの情報を書き換えて更新する。また、連携してデータを処理する場合、各実行手段２２０はデータを処理した後、新たなメッセージを次にデータを処理する実行手段２２０のキューに入れる。

複数の実行手段２２０は、図１３に示すように、処理ライブラリ２２０ａと処理エンジン２２０ｂを備える構成である。処理ライブラリ２２０ａは、その実行手段２２０に対応するキューを監視する処理や、処理後のデータを共有ファイルストレージ２０７上に登録する処理などを実行する。

また、処理ライブラリ２２０ａは、ジョブ情報管理データベース２０８上に登録されたリクエストの情報を書き換えて更新する処理などを実行する。また、処理ライブラリ２２０ａは連携して処理する場合にデータの処理後の新たなメッセージを、次に処理を行う実行手段２２０のキューに入れる処理などを実行する。

処理エンジン２２０ｂとしては、例えば、以下のようなものがある。
・画像ファイルをＯＣＲ処理するエンジン
・ファイルをオンラインストレージ１４に保存するエンジン
・画像／テキスト／ＨＴＭＬファイルをＰＤＦに変換するエンジン
・ドキュメント／ＰＤＦファイルをＲＰＣＳに変換するエンジン
・ドキュメント／ＰＤＦファイルを画像ファイル（ｊｐｅｇ／ｔｉｆｆなど）に変換するエンジン
・ドキュメント／ＰＤＦファイルをプレビュー画像ファイルに変換するエンジン
（非同期処理サービス）
図１２に示す非同期処理サーバ２０１による非同期処理サービスの流れについて、図１４のシーケンス図を参照して説明する。図１４は非同期処理サーバの動作を示すシーケンス図である。

ステップＳ４１において、フロントエンドアプリケーション２０２ａは共有ファイルストレージ２０７に登録しておいたデータに対する処理の要求（ジョブ登録依頼）を非同期処理サーバ２０１の処理実行要求管理手段２１１に対して行う。非同期処理サービスはフロントエンドアプリケーション２０２ａが共有ファイルストレージ２０７に登録しておいたデータに対する処理の要求（リクエスト）を処理実行要求管理手段２１１に送信すると始まる。

ステップＳ４１で送信されるリクエストは処理の種類が例えば「ｔｙｐｅ＝ｉｍｇ２ｏｃｒ」のようなパラメータにより埋め込まれている。また、リクエストには処理しようとしているデータのＵＲＩもパラメータで埋め込まれている。

ステップＳ４２において、ジョブを受信した処理実行要求管理手段２１１はジョブを解析して、処理の種類に合致する実行手段２２０があるか否かを判定する。処理の種類に合致する実行手段２２０がある場合、処理実行要求管理手段２１１は、その実行手段２２０に対応するメッセージキュー２１２のキューに、ジョブを登録する。

ステップＳ４３において、処理実行要求管理手段２１１はジョブ登録結果をフロントエンドアプリケーション２０２ａに返す。ここでは、第１の実行手段２２１（例えば画像ファイルをＯＣＲ処理してオンラインストレージに保存する処理）に対応するメッセージキュー２１２のキューにジョブが登録されたものとして説明を続ける。

ステップＳ４４において、自身が処理できるジョブに対応するキューを監視している第１の実行手段２２１はキューにジョブが登録されたことを検知する。ステップＳ４５において、第１の実行手段２２１はキューに登録されたジョブの情報をジョブ情報管理データベース２０８から取得する。

第１の実行手段２２１は取得したジョブの情報に含まれるタスクの内容を解析し、そのタスクを実行手段２２０で処理できる種類のタスクに分割する。ステップＳ４５におけるタスクの分割は、例えば図１５のように行われる。

図１５はジョブの情報に含まれるタスクの分割例を表した説明図である。なお、図１５では処理の種類が「ｉｍｇ２ｓｔｏｒａｇｅＡ」である例を表している。処理の種類「ｉｍｇ２ｓｔｏｒａｇｅＡ」は画像ファイルをＯＣＲ処理し、テキストファイルをオンラインストレージＡに保存するものである。なお、本実施形態では一つの実行手段２２０で画像ファイルをＯＣＲ処理し、テキストファイルをオンラインストレージＡに保存することができないものとする。

そこで、フロントエンドアプリケーション２０２ａは、複数の実行手段２２０を連携させて「ｉｍｇ２ｓｔｏｒａｇｅＡ」を処理させるため、次のように処理する。例えば「ｉｍｇ２ｓｔｏｒａｇｅＡ」のタスクを「ｉｍｇ２ｏｃｒ」及び「ｔｘｔ２ｓｔｏｒａｇｅＡ」の二つのタスクに分割する第１の実行手段２２１に対応するメッセージキュー２１２のキューにジョブを登録する。

処理の種類「ｉｍｇ２ｏｃｒ」は画像ファイルをＯＣＲ処理し、テキストファイルを出力するものである。処理の種類「ｔｘｔ２ｓｔｏｒａｇｅＡ」はテキストファイルをオンラインストレージＡに保存するものである。第１の実行手段２２１は「ｉｍｇ２ｓｔｏｒａｇｅＡ」のタスクを「ｉｍｇ２ｏｃｒ」及び「ｔｘｔ２ｓｔｏｒａｇｅＡ」の二つのタスクに分割する。

そして、第１の実行手段２２１は、次に行うタスクに対応するキューに、それぞれのタスクを含むジョブを再登録することで、複数の実行手段２２０を連携させた処理が可能となる。

このように、第１の実行手段２２１は実行手段２２０で処理できない種類のタスクを含むジョブから第２の実行手段２２２及び第３の実行手段２２３で処理できる種類のタスクを含むジョブを生成する。このため、第１の実行手段２２１は第２の実行手段２２２と第３の実行手段２２３とを連携させた処理を実現できる。

図１４に戻り説明を続ける。ステップＳ４６において、第１の実行手段２２１は分割したタスクを含むジョブを、次に行うタスク（例えばｉｍｇ２ｏｃｒ）の処理の種類に対応するキューに登録する。ステップＳ４７において、自身が処理できるジョブに対応するキューを監視している第２の実行手段２２２はキューにジョブが登録されたことを検知する。

ステップＳ４８において、第２の実行手段２２２はキューに登録されたジョブの情報をジョブ情報管理データベース２０８から取得する。第２の実行手段２２２はジョブの情報を解析し、先頭のタスクの情報に含まれるＵＲＩに基づいて共有ファイルストレージ２０７上のデータを取得し、先頭のタスクの情報に含まれる処理の種類に応じた処理を行う。

第２の実行手段２２２は、処理後のデータを共有ファイルストレージ２０７上に登録又は更新する。また、第２の実行手段２２２は変換したことを表すために、ジョブ情報管理データベース２０８に登録されているジョブの情報を更新する。このとき、リクエストの状態が例えば「処理中継中」に更新される。

ステップＳ４９において、第２の実行手段２２２はジョブの情報から先頭のタスク（処理済み）の情報を削除し、次に行うタスク（例えばｔｘｔ２ｓｔｏｒａｇｅＡ）の処理の種類に対応するキューに、残りのタスクを含むジョブを登録する。

ステップＳ５０において、自身が処理できるジョブに対応するキューを監視している第３の実行手段２２３はキューにジョブが登録されたことを検知する。ステップＳ５１において、第３の実行手段２２３はキューに登録されたジョブの情報をジョブ情報管理データベース２０８から取得する。

第３の実行手段２２３はジョブの情報を解析し、先頭のタスクの情報に含まれるＵＲＩに基づいて共有ファイルストレージ２０７上のデータを取得し、先頭のタスクの情報に含まれる処理の種類に応じた処理を行う。例えば第３の実行手段２２３は処理後のデータをオンラインストレージＡに保存する処理を実行する。また、第３の実行手段２２３は処理したことを表すために、ジョブ情報管理データベース２０８に登録されているジョブの情報を更新する。このとき、リクエストの状態が例えば「処理完了」に更新される。

ステップＳ５２において、第３の実行手段２２３はジョブの情報から先頭のタスク（処理済み）の情報を削除し、次に行うタスクがジョブの情報に含まれていないため、他のキューにジョブを登録することなく処理を終了する。

上述した動作によって、本実施形態では、直接処理する実行手段２２０が存在しない処理要求のリクエストを満足する実行手段２２０を用意するのではなく、複数の既存の処理エンジン２２０ｂを組み合わせ、連携させることによって処理要求を処理できる。

処理のリクエストの種類は、上述したように、処理実行システム２００を立ち上げたあとに増加する可能性がある。これに対して、本実施形態によれば柔軟に対応することができるようになる。また、本実施例によれば、フロントエンドアプリケーション２０２ａは実行手段２２０のタスクを一つ含むジョブを登録することで、複数の実行手段２２０が処理することを意識することなく、複数のタスクを実行できる。

なお、実行手段２２０の種類は、上記実施形態のものに限定されない。また、上記実施形態は、矛盾しない範囲で適宜組み合わせて適用することも可能である。
［第３の実施形態］
データ変換処理などの処理の種類の増加に柔軟に対応することは、以下の第３の実施形態によっても実現できる。なお、第３の実施形態ではデータ変換処理の種類の増加に柔軟に対応する例について説明する。

＜システム構成＞
図１６は第３の実施形態に係るシステムの一例の構成図である。図１６のシステム１０００は例えばオフィス内ネットワーク等のネットワークＮ１と、クラウドサービスに代表されるようなサービス提供システムのネットワークＮ２と、インターネットなどのネットワークＮ３とを有する。

ネットワークＮ１は、ファイヤウォールＦＷの内側にあるプライベートなネットワークである。ファイヤウォールＦＷはネットワークＮ１とネットワークＮ３との接点に設置され、不正なアクセスを検出及び遮断する。ネットワークＮ１にはクライアント端末１０１１、携帯端末１０１２、複合機などの画像形成装置１０１３が接続されている。

クライアント端末１０１１は端末装置の一例である。クライアント端末１０１１は一般的なＯＳなどが搭載された情報処理装置によって実現できる。クライアント端末１０１１は無線による通信の手段または有線による通信の手段を有する。クライアント端末１０１１は、タブレットＰＣ、ノートＰＣなど、ユーザが操作可能な端末である。

携帯端末１０１２は端末装置の一例である。携帯端末１０１２は、無線による通信の手段または有線による通信の手段を有している。携帯端末１０１２は、スマートフォンや携帯電話、タブレットＰＣ、ノートＰＣなど、ユーザが携帯可能な端末である。

画像形成装置１０１３は複合機などの画像形成機能を有する装置である。画像形成装置１０１３は無線による通信の手段または有線による通信の手段を有する。画像形成装置１０１３は複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板など、画像形成に係る処理を行う装置である。図１６では、一例としてクライアント端末１０１１、携帯端末１０１２、画像形成装置１０１３がそれぞれ一台である例を示しているが複数台であってもよい。

なお、クライアント端末１０１１、携帯端末１０１２は、第１の実施形態のＰＣ１２に対応する。画像形成装置１０１３は第１の実施形態のＭＦＰ１３に対応する。

ネットワークＮ２はアクセス制御装置１０２１によってネットワークＮ３に接続されている。ネットワークＮ２はアクセス制御装置１０２１によってセキュリティが保護されている。ネットワークＮ２にはプリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４が接続されている。

図１６のシステム１０００は、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４がサービス提供システムを実現している。サービス提供システムは第１の実施形態のクラウド側のデータ変換システム１００、印刷ジョブ管理サーバ１０２、リバースプロキシ１０４、認証サーバ１０５、認証用データベース１０６に対応する。

アクセス制御装置１０２１はプリントサービス提供装置１０２２が提供するプリントサービスやスキャンサービス提供装置１０２３が提供するスキャンサービスなどへのログインを制御する。

アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、一台以上の情報処理装置によって実現される。

アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は一台の情報処理装置に統合して実現してもよいし、複数の情報処理装置に分散して実現してもよい。

ネットワークＮ２側のサービスの一部はネットワークＮ２以外にあってもよい。携帯端末１０１２は、オフィス内ネットワーク等のネットワークＮ１以外にあってもよい。図１６のシステム１０００では携帯端末１０１２がネットワークＮ１と、ネットワークＮ３とにある例を示している。

＜ハードウェア構成＞
クライアント端末１０１１、携帯端末１０１２、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、例えば図１７に示すようなハードウェア構成のコンピュータシステムにより実現される。

図１７はコンピュータシステムの一例のハードウェア構成図である。コンピュータシステム１５００は、入力装置１５０１、表示装置１５０２、外部Ｉ／Ｆ１５０３、ＲＡＭ（Random Access Memory）１５０４、ＲＯＭ（Read Only Memory）１５０５、ＣＰＵ（Central Processing Unit）１５０６、通信Ｉ／Ｆ１５０７、及びＨＤＤ（Hard Disk Drive）１５０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置１５０１はキーボードやマウス、タッチパネルなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置１５０２はディスプレイ等を含み、コンピュータシステム１５００による処理結果を表示する。

通信Ｉ／Ｆ１５０７はコンピュータシステム１５００をネットワークＮ１〜Ｎ３に接続するインタフェースである。これにより、コンピュータシステム１５００は通信Ｉ／Ｆ１５０７を介してデータ通信を行うことができる。

ＨＤＤ１５０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、例えばコンピュータシステム１５００全体を制御する基本ソフトウェアであるＯＳ（Operating System）や、ＯＳ上において各種機能を提供するアプリケーションソフトウェアなどがある。

ＨＤＤ１５０８は格納しているプログラムやデータを所定のファイルシステム及び／又はＤＢ（データベース）により管理している。外部Ｉ／Ｆ１５０３は、外部装置とのインタフェースである。外部装置には、記録媒体１５０３ａなどがある。これにより、コンピュータシステム１５００は外部Ｉ／Ｆ１５０３を介して記録媒体１５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１５０３ａにはフレキシブルディスク、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（SD Memory card）、ＵＳＢメモリ（Universal Serial Bus memory）などがある。

ＲＯＭ１５０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１５０５には、コンピュータシステム１５００の起動時に実行されるＢＩＯＳ（Basic Input/Output System）、ＯＳ設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１５０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。

ＣＰＵ１５０６は、ＲＯＭ１５０５やＨＤＤ１５０８などの記憶装置からプログラムやデータをＲＡＭ１５０４上に読み出し、処理を実行することで、コンピュータシステム１５００全体の制御や機能を実現する演算装置である。

クライアント端末１０１１、携帯端末１０１２、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、コンピュータシステム１５００のハードウェア構成により、後述するような各種処理を実現できる。

＜ソフトウェア構成＞
《サービス提供システム》
第３の実施形態に係るサービス提供システムは例えば図１８に示す処理ブロックにより実現される。図１８は第３の実施形態に係るサービス提供システムの一例の処理ブロック図である。

図１８のサービス提供システム１１００は、プログラムを実行することにより、サービスアプリ１１０１、プラットフォーム１１０２、管理データ記憶部１１０３及びプラットフォームＡＰＩ（Application Programming Interface）１１０４を実現している。

サービスアプリ１１０１は、プリントサービスアプリ１１１１、スキャンサービスアプリ１１１２、１つ以上のその他のサービスアプリ１１１３を一例として有する。

プリントサービスアプリ１１１１はプリントサービスを提供するアプリケーションである。スキャンサービスアプリ１１１２はスキャンサービスを提供するアプリケーションである。その他のサービスアプリ１１１３は何らかのサービスを提供するアプリケーションである。

プラットフォームＡＰＩ１１０４はプリントサービスアプリ１１１１、スキャンサービスアプリ１１１２、その他のサービスアプリ１１１３などのサービスアプリ１１０１が、プラットフォーム１１０２を利用するためのインタフェースである。プラットフォームＡＰＩ１１０４はサービスアプリ１１０１からの要求をプラットフォーム１１０２が受信するために設けられた予め定義されたインタフェースであり、例えば関数やクラス等により構成される。なお、サービス提供システム１１００を複数の情報処理装置に分散して構成する場合、プラットフォームＡＰＩ１１０４にはネットワーク経由で利用可能な例えばＷｅｂ ＡＰＩを利用できる。

プラットフォーム１１０２は、認証処理部１１２１、機器通信部１１２２、セッション管理部１１２３、処理制御部１１２４、データ処理部１１２５を有する。データ処理部１１２５はメッセージキュー１１３１、１つ以上のデータ形式変換部１１３２を有する。

認証処理部１１２１は第１の実施形態の認証サーバ１０５に対応する。認証処理部１１２１はクライアント端末１０１１や画像形成装置１０１３などのオフィス機器からのログイン要求に基づいて認証を実行する。オフィス機器はクライアント端末１０１１、携帯端末１０１２、画像形成装置１０１３などの総称である。認証処理部１１２１は例えば後述するユーザ管理情報記憶部１１４２にアクセスしてユーザを認証する。また、認証処理部１１２１は組織管理情報記憶部１１４１、機器管理情報記憶部１１４３にアクセスして画像形成装置１０１３などを認証する。

機器通信部１１２２はオフィス機器との通信を実行する。セッション管理部１１２３はオフィス機器とのセッションを管理する。処理制御部１１２４はサービスアプリ１１０１からの要求に基づいてデータ処理部１１２５が実行するデータ処理を制御する。データ処理部１１２５は処理制御部１１２４の制御によりデータ処理を実行する。なお、処理制御部１１２４は第１の実施形態のデータ変換要求管理手段１１１に対応する。データ処理部１１２５のメッセージキュー１１３１は第１の実施形態のメッセージキュー１１２に対応する。データ形式変換部１１３２は第１の実施形態の変換手段１２０に対応する。

メッセージキュー１１３１は後述するデータ変換の種類に対応するキューを有し、処理制御部１１２４からデータ変換に係るリクエストのメッセージを入れられる。データ形式変換部１１３２は対応するキューを監視している。データ形式変換部１１３２はキューにメッセージが入ると、データ変換や、変換要求のリクエストの分割などを行う。第３の実施形態における非同期変換サービスの処理の詳細は後述する。

管理データ記憶部１１０３は組織管理情報記憶部１１４１、ユーザ管理情報記憶部１１４２、機器管理情報記憶部１１４３、ジョブ管理情報記憶部１１４４、データストレージ１１４５を有する。

組織管理情報記憶部１１４１は、後述の組織管理情報を記憶する。ユーザ管理情報記憶部１１４２は、後述のユーザ管理情報を記憶する。機器管理情報記憶部１１４３は後述の機器管理情報を記憶する。組織管理情報記憶部１１４１、ユーザ管理情報記憶部１１４２及び機器管理情報記憶部１１４３は、第１の実施形態の認証用データベース１０６に対応する。

ジョブ管理情報記憶部１１４４は第１の実施形態のジョブ情報管理データベース１０８に対応し、データ変換に係るリクエストの情報を記憶する。データストレージ１１４５は第１の実施形態の共有ファイルストレージ１０７に対応し、印刷ジョブに含まれる電子文書ファイル等のデータを記憶する。

サービス提供システム１１００は、例えば認証やデータ形式変換といった機能を有するクラウド基盤と、クラウド基盤の機能を利用してプリントサービス等のサービス提供を行うサービス群として機能する。クラウド基盤は、例えばプラットフォーム１１０２、管理データ記憶部１１０３、プラットフォームＡＰＩ１１０４によって構成される。サービス群は例えばサービスアプリ１１０１によって構成される。

サービス提供システム１１００のクラウド基盤が有する認証の機能は、例えば認証処理部１１２１と、認証用データベースにより構成される。認証用データベースは組織管理情報記憶部１１４１、ユーザ管理情報記憶部１１４２、機器管理情報記憶部１１４３などにより構成される。

また、サービス提供システム１１００のクラウド基盤が有するデータ形式変換の機能は処理制御部１１２４、データ処理部１１２５、ジョブ管理情報記憶部１１４４、データストレージ１１４５などにより構成される。サービス群は、サービス提供システム１１００のクラウド基盤が有する認証やデータ形式変換といった機能を利用し、サービスの提供を行う。

また、図１８のサービス提供システム１１００は、複数のサービスアプリ１１０１が共通に利用する組織管理情報、ユーザ管理情報、機器管理情報を管理データとして管理することで、認証機能を集約している。

《管理データ》
図１９は組織管理情報の一例の構成図である。図１９の組織管理情報はデータ項目として組織コード、組織名、国、言語、アドレス情報などを有する。組織コードは企業、組織などのグループを特定する情報である。

組織名は企業、組織などのグループの名称である。国は企業、組織などのグループの属する国名を表している。言語は企業、組織などのグループの使用言語を表している。アドレス情報は企業、組織などのグループのメールアドレスを表している。

図２０はユーザ管理情報の一例の構成図である。図２０のユーザ管理情報はデータ項目として組織コード、ユーザ名、パスワード、アドレス情報などを有する。ユーザ名、パスワードはユーザを特定する情報である。したがって、ユーザ名はユーザＩＤ等であってもよい。また、パスワードは必須でない。また、同じ組織コードで管理されるユーザ名、パスワードは一意であるが、組織コードが異なれば重複していてもよい。アドレス情報は例えばユーザのメールアドレスを表している。

さらに、ユーザＩＤはユーザが所持する電子媒体（例えばＩＣカード）を識別する情報を用いてもよい。ユーザが所持する電子媒体としてはＩＣカード、携帯電話、タブレット端末、電子書籍端末等を利用できる。電子媒体を識別する情報としては、カードＩＤ、シリアルＩＤ、携帯電話の電話番号、端末のプロフィール情報などを利用できる。電子媒体を識別する情報は組み合わせて利用してもよい。

図２１は機器管理情報の一例の構成図である。図２１の機器管理情報はデータ項目として組織コード、デバイス認証情報、事業所情報、ケーパビリティなどを有する。デバイス認証情報はオフィス機器が特定の条件を備えたものであることを判別するデバイス認証のための情報である。デバイス認証情報はオフィス機器に特定のアプリケーションが搭載されていることを示すＩＤや、特定のオフィス機器であることを示す機器番号などであってもよい。事業所情報は例えばオフィス機器が設置されている事業所を表している。ケーパビリティは例えばオフィス機器の能力を表している。

＜処理の詳細＞
以下では第３の実施形態に係るサービス提供システム１１００の処理の詳細について説明するが、第１の実施形態と同様な部分について適宜説明を省略する。

《データ変換処理》
第３の本実施形態に係るサービス提供システム１１００は、多種多様なデータ変換要求に応えるため、また、データ変換要求の種類の増加に柔軟に対応するため、以下に説明する構成を備える。図２２に、サービス提供システム１１００におけるデータ変換処理の機能構成を示す。図２２は第３の実施形態におけるデータ変換処理の一例について説明する説明図である。なお、図２２は一部を除いて図４と同一であるため、同一部分について適宜説明を省略する。

図２２に示すように、サービス提供システム１１００は、プリントサービスアプリ１１１１の一機能であるフロントエンドアプリケーション１１１１ａと、データストレージ１１４５と、処理制御部１１２４と、メッセージキュー１１３１と、ジョブ管理情報記憶部１１４４と、複数のデータ形式変換部１１３２とを含む構成である。

処理制御部１１２４と、メッセージキュー１１３１と、ジョブ管理情報記憶部１１４４と、複数のデータ形式変換部１１３２とは、非同期データ変換サービスを提供する。クラウドプリントのソリューションにおいて、フロントエンドアプリケーション１１１１ａはクライアント端末１０１１などインプット側機器から印刷ジョブを受信し、印刷ジョブに含まれる電子文書ファイル等をデータストレージ１１４５に登録する機能を備える。フロントエンドアプリケーション１１１１ａは必要なファイル変換を判断して、非同期データ変換サービスにデータ変換を実行させる制御を行う。

変換後のファイルはデータストレージ１１４５に登録される。画像形成装置１０１３などアウトプット側機器から印刷ジョブの出力指示を受信すると、プリントサービスアプリ１１１１は登録された変換後のファイルを、出力指示を送信した画像形成装置１０１３に送信する。

フロントエンドアプリケーション１１１１ａは、出力指示の実行に必要なファイル変換を判断する機能を備える。フロントエンドアプリケーション１１１１ａは判断したデータ変換の種類を、例えば「ｄｏｃ２ｒｐｃｓ」のようなパラメータにして、処理制御部１１２４へのリクエストに埋め込む。同様に、フロントエンドアプリケーション１１１１ａは変換元のデータが存在する場所の情報であるＵＲＩもパラメータとしてリクエストに埋め込む。

処理制御部１１２４はデータ変換の種類とデータのＵＲＩとを少なくとも含むリクエストを受け取る。処理制御部１１２４はデータ変換に係るリクエストを解析して、データ変換の種類に合致するメッセージキュー１１３１のキューに、メッセージを入れる。

処理制御部１１２４は、メッセージキュー１１３１へメッセージを入れることと同時に並行して、ジョブ管理情報記憶部１１４４にリクエストの情報を登録する。ジョブ管理情報記憶部１１４４に登録されるリクエストの情報は、ファイルの場所（データストレージ１１４５上のＵＲＩ）、リクエストに含まれるデータ変換の種類、リクエストの状態などである。リクエストの状態としては「受付」「実行中」「完了」などがある。リクエストの状態は、データ変換の処理状況を示すステータスを表す。

メッセージキュー１１３１は複数のデータ形式変換部１１３２に対応するキューを有している。なお、図２２ではデータ形式変換部１１３２とメッセージキュー１１３１が有するキューとが一対一に対応する例を示しているが、多対多に対応していてもよい。

各データ形式変換部１１３２は、そのデータ形式変換部１１３２に対応するキューを監視しており、キューにメッセージが入ると、そのメッセージに対応するデータ変換や変換要求のリクエストの分割などの処理を行う。

例えばデータ変換の処理を行う場合、データ形式変換部１１３２はメッセージに含まれるデータのＵＲＩに基づいて、データストレージ１１４５上のデータを取得する。データ形式変換部１１３２は取得したデータの変換を行う。データ形式変換部１１３２は、変換後のデータをデータストレージ１１４５上に登録し、ジョブ管理情報記憶部１１４４上に登録されたリクエストの情報を更新する。

また、変換要求のリクエストを分割する処理を行う場合、データ形式変換部１１３２は変換要求のリクエストを分割して、複数段階のデータ変換のプロセスに分け、各プロセスに対応する複数のジョブとする。このように、本実施形態のデータ形式変換部１１３２にはデータ変換の処理を行わずに、変換要求のリクエストを分解する処理を行うものが含まれる。変換要求のリクエストを分解する処理の具体例は後述する。

なお、データ変換のプロセスの単位は、非同期データ変換サービスに含まれる変換エンジン１２０ｂの単位となる。変換要求のリクエストから分割された複数のジョブは、そのジョブのデータ変換の種類に対応するキューにメッセージとして入れられる。その後の処理は、上記したデータ変換の処理を行う場合と同様である。

メッセージキュー１１３１のキューとデータ形式変換部１１３２とは例えば図２３のように対応付けてもよい。図２３はキューとデータ形式変換部との対応付けの一例について説明する説明図である。

メッセージキュー１１３１は、複数のキューを有する。キューは例えば「ｄｏｃ２ｒｐｃｓ」などのデータ変換の種類ごとに分離されている。また、データ形式変換部１１３２はＷｏｒｋｅｒノード上で動作する。Ｗｏｒｋｅｒノードは例えばＷｉｎｄｏｗｓ（登録商標）サーバやＬｉｎｕｘ（登録商標）サーバにより実現される。

例えばデータ形式変換部１１３２は１つのＷｉｎｄｏｗｓ（登録商標）サーバ上で２つを動作させ、１つのＬｉｎｕｘ（登録商標）サーバ上で３つを動作させるような構成とすることができる。

図２３では、Ｗｉｎｄｏｗｓ（登録商標）サーバ上で動作するデータ形式変換部１１３２が「ｄｏｃ２ｒｐｃｓ」「ｄｏｃ２ｐｃｌ」「ｐｄｆ２ｒｐｃｓ」「ｐｄｆ２ｐｃｌ」のデータ変換処理を行うことができる。また、図２３ではＬｉｎｕｘ（登録商標）サーバ上で動作するデータ形式変換部１１３２が「ｈｔｍｌ２ｐｄｆ」「ｉｍａｇｅ２ｐｄｆ」のデータ変換処理を行うことができる。

図２３に示すように、データ形式変換部１１３２は１つの接続で複数のキューのジョブをポーリングすることができる。ただし、１つの接続でポーリングすることができる複数のキューの範囲は、例えば同一のＯＳサーバ上で動作するデータ形式変換部１１３２の範囲とする。

以下では変換要求のリクエストを分割する処理の一例として「ｉｍｇ２ｒｐｃｓ」を例に説明する。図２４〜図２６は変換要求のリクエストを分割する処理の一例について説明する説明図である。

図２４のステップＳ３０１以降の処理は処理制御部１１２４がデータ変換の種類「ｉｍｇ２ｒｐｃｓ」とデータのＵＲＩとを少なくとも含むリクエストをフロントエンドアプリケーション１１１１ａから受け取ったあとの処理である。

ステップＳ３０１において、処理制御部１１２４はフロントエンドアプリケーション１１１１ａから受け取ったリクエストをジョブとしてジョブ管理情報記憶部１１４４に登録する。

ステップＳ３０２において、処理制御部１１２４はフロントエンドアプリケーション１１１１ａから受け取ったリクエストをジョブａとして、データ変換の種類「ｉｍｇ２ｒｐｃｓ」に対応するキューに投入する（Ｅｎｑｕｅｕｅ）。

データ変換の種類「ｉｍｇ２ｒｐｃｓ」に対応するデータ形式変換部１１３２は、対応するキューを監視しており、ステップＳ３０３において、キューに投入されたジョブａを取得する。ステップＳ３０４において、データ形式変換部１１３２はジョブａに対応する処理を行う。

ここで、ステップＳ３０４におけるデータ形式変換部１１３２の処理について図２７を参照しつつ説明する。図２７はステップＳ３０４の処理の一例について説明する説明図である。図２７ではデータ形式変換部１１３２をＷｏｒｋｅｒと記載している。また、図２７では仮想的なタスクキュー（ＴａｓｋｓＱｕｅｕｅ）の状態を表している。なお、仮想的なタスクキューはＷｏｒｋｅｒ内部で持っている配列のことである。

図２７（１）において、タスクキューにはデータ形式変換部１１３２が取得したジョブａに対応するタスク「ｉｍｇ２ｒｐｃｓ」が存在する。図２７（２）において、データ変換の種類「ｉｍｇ２ｒｐｃｓ」に対応するデータ形式変換部１１３２は、画像ファイルからＲＰＣＳへのデータ変換に必要なタスク「ｉｍｇ２ｐｄｆ」「ｐｄｆ２ｒｐｃｓ」をタスクキューに追加する。

図２７（３）において、データ形式変換部１１３２は、タスクキューの先頭にあるタスク「ｉｍｇ２ｒｐｃｓ」を見て、ジョブａをデータ変換の種類「ｉｍｇ２ｒｐｃｓ」に対応するキューから削除する（Ｄｅｑｕｅｕｅ）。

図２７（４）において、データ形式変換部１１３２は、タスクキューの先頭にあるタスク「ｉｍｇ２ｒｐｃｓ」を削除する。そして、図２７（５）において、データ形式変換部１１３２はタスクキューの先頭にあるタスク「ｉｍｇ２ｐｄｆ」を見て、データ変換の種類「ｉｍｇ２ｐｄｆ」に対応するキューにジョブｂを投入する。

図２７（３）におけるジョブａの削除と図２７（５）におけるジョブｂの投入は図２４のステップＳ３０５の処理となる。図２４に戻り説明を続ける。

ステップＳ３０５においてジョブａの削除とジョブｂの投入を行ったあと、データ変換の種類「ｉｍｇ２ｒｐｃｓ」に対応するデータ形式変換部１１３２はステップＳ３０６においてジョブａの実行結果をジョブ管理情報記憶部１１４４に書き込む。ステップＳ３０６においてジョブａの実行結果を書き込まれたあとのジョブ管理情報は例えば図２８に示すようになる。

図２８はジョブａの実行結果を書き込まれたあとのジョブ管理情報の一例のデータ構造図である。図２８に示すように、ジョブ管理情報には実行結果として「分割されたことを示す文字列」が書き込まれる。なお、ステータスは「ｉｍｇ２ｒｐｃｓ」のデータ変換処理が実行中であることを表す「ｄｏｉｎｇ」となっている。

図２５のステップＳ３０７において、データ変換の種類「ｉｍｇ２ｐｄｆ」に対応するデータ形式変換部１１３２は、監視しているキューに投入されたジョブｂを取得する。ステップＳ３０８において、データ形式変換部１１３２はジョブｂに対応する処理を行う。

ここで、ステップＳ３０８におけるデータ形式変換部１１３２の処理について図２９を参照しつつ説明する。図２９はステップＳ３０８の処理の一例について説明する説明図である。

図２９（１）において、タスクキューにはタスク「ｉｍｇ２ｐｄｆ」「ｐｄｆ２ｒｐｃｓ」が存在する。図２９（２）において、データ変換の種類「ｉｍｇ２ｐｄｆ」に対応するデータ形式変換部１１３２は、タスクキューの先頭にあるタスク「ｉｍｇ２ｐｄｆ」を見る。データ変換の種類「ｉｍｇ２ｐｄｆ」に対応するデータ形式変換部１１３２はデータストレージ１１４５からのファイルの取得、ファイルのオープン、ファイルのデータ変換、ファイルのアップロード、ジョブｂの削除を行う。

図２９（３）において、データ形式変換部１１３２は、タスクキューの先頭にあるタスク「ｉｍｇ２ｐｄｆ」を削除する。そして、図２９（４）において、データ形式変換部１１３２はタスクキューの先頭にあるタスク「ｐｄｆ２ｒｐｃｓ」を見て、データ変換の種類「ｐｄｆ２ｒｐｃｓ」に対応するキューにジョブｃを投入する。

図２９（２）におけるジョブｂの削除と図２９（４）におけるジョブｃの投入は図２５のステップＳ３０９の処理となる。図２５に戻り説明を続ける。

ステップＳ３０９においてジョブｂの削除とジョブｃの投入を行ったあと、データ変換の種類「ｉｍｇ２ｐｄｆ」に対応するデータ形式変換部１１３２はステップＳ３１０においてジョブｂの実行結果をジョブ管理情報記憶部１１４４に書き込む。ステップＳ３１０においてジョブｂの実行結果を書き込まれたあとのジョブ管理情報は例えば図３０に示すようになる。

図３０はジョブｂの実行結果を書き込まれたあとのジョブ管理情報の一例のデータ構造図である。図３０に示すように、ジョブ管理情報には実行結果として、データストレージ１１４５における変換後のファイルが存在する場所の情報「データストレージのＡ．ｐｄｆ」が書き込まれる。なお、ステータスは「ｉｍｇ２ｒｐｃｓ」のデータ変換処理が実行中であることを表す「ｄｏｉｎｇ」となっている。

また、図２６のステップＳ３１１において、データ変換の種類「ｐｄｆ２ｒｐｃｓ」に対応するデータ形式変換部１１３２は、監視しているキューに投入されたジョブｃを取得する。ステップＳ３１２において、データ形式変換部１１３２はジョブｃに対応する処理を行う。

ここで、ステップＳ３１２におけるデータ形式変換部１１３２の処理について図３１を参照しつつ説明する。図３１はステップＳ３１２の処理の一例について説明する説明図である。

図３１（１）において、タスクキューにはタスク「ｐｄｆ２ｒｐｃｓ」が存在する。図３１（２）において、データ変換の種類「ｐｄｆ２ｒｐｃｓ」に対応するデータ形式変換部１１３２は、タスクキューの先頭にあるタスク「ｐｄｆ２ｒｐｃｓ」を見る。データ変換の種類「ｐｄｆ２ｒｐｃｓ」に対応するデータ形式変換部１１３２は、データストレージ１１４５からのファイルの取得、ファイルのオープン、ファイルのデータ変換、ファイルのアップロード、ジョブｃの削除を行う。

図３１（３）において、データ形式変換部１１３２は、タスクキューの先頭にあるタスク「ｐｄｆ２ｒｐｃｓ」を削除する。タスク「ｐｄｆ２ｒｐｃｓ」が削除されると、タスクキューは空になる。なお、図３１（２）におけるジョブｂの削除は図２６のステップＳ３１３の処理となる。図２６に戻り説明を続ける。

ステップＳ３１３においてジョブｃの削除を行ったあと、データ変換の種類「ｐｄｆ２ｒｐｃｓ」に対応するデータ形式変換部１１３２はステップＳ３１４においてジョブｃの実行結果をジョブ管理情報記憶部１１４４に書き込む。ステップＳ３１４においてジョブｃの実行結果を書き込まれたあとのジョブ管理情報は例えば図３２に示すようになる。

図３２はジョブｃの実行結果を書き込まれたあとのジョブ管理情報の一例のデータ構造図である。図３２に示すように、ジョブ管理情報には実行結果として、データストレージ１１４５における変換後のファイルが存在する場所の情報「データストレージのＡ．ｒｐｃｓ」が書き込まれる。なお、ステータスは「ｉｍｇ２ｒｐｃｓ」のデータ変換処理が完了したことを表す「ｄｏｎｅ」となっている。

このように、本実施形態によれば、複数のデータ形式変換部１１３２を連携したデータ変換処理が可能である。このため、本実施形態によれば、変換前又は変換後のデータ形式の選択肢が多くなっても用意しなければならないデータ変換エンジンの数の増加を従来よりも抑えることができるので変換前又は変換後のデータ形式の種類の増加に柔軟に対応できる。

なお、第３の実施形態ではデータ変換処理を例として説明したが、第２の実施形態において示したように、画像ファイルのＯＣＲ処理やオンラインストレージへファイルを保存する処理など、多種多様な処理に対応可能である。この場合、データ形式変換部１１３２は処理を実行する実行手段２２０に置き換えられる。

実行手段２２０は、処理実行要求により要求された処理の他、まだ処理実行要求されていないが、要求された処理実行要求の次に要求されることが予想される処理（例えばプレビュー処理など）を、裏で処理するものであってもよい。本実施形態では、第１の実施形態の変換手段１２０、第２の実施形態の実行手段２２０又は第３の実施形態のデータ形式変換部１１３２を連携させて処理を行わせることにより、以下のような処理を行うことが可能となる。

・画像／テキスト／ＨＴＭＬ／ドキュメント／ＰＤＦファイルを印刷ファイルに変換
・画像形成装置１０１３でスキャンした画像ファイルをＯＣＲ処理して、オンラインストレージ１４に保存
・オンラインストレージ１４にあるファイルを取得し、印刷ファイルに変換
・オンラインストレージ１４にある画像ファイルを取得し、ＯＣＲ処理
［第４の実施形態］
上記した第１〜第３の実施形態では、受付順にジョブを処理していたが、以下の第４の実施形態のように、ジョブを処理する順序に優先度を付けることもできる。例えばユーザの種類を一般ユーザとプレミアムユーザとに分けた場合は、一般ユーザのジョブよりもプレミアムユーザのジョブを優先させたいケースが考えられる。処理時間が長いジョブと処理時間が短いジョブとがある場合は、処理時間が長いジョブよりも処理時間が短いジョブを優先させたいケースも考えられる。

ここでは、第１の実施形態において、ジョブを処理する順序に優先度を付ける例について説明するが、第２及び第３の実施形態においても同様に、ジョブを処理する順序に優先度を付けることが可能である。なお、第４の実施形態は前述した第１の実施形態と一部を除いて同様であるため、同一部分について適宜説明を省略する。

まず、ジョブを処理する順序に優先度を付けないデータ変換システム１００について図３３を参照しつつ説明する。図３３はジョブを処理する順序に優先度を付けないデータ変換システムの構成例を示すブロック図である。

なお、図３３は図４のデータ変換システム１００に示した共有ファイルストレージ１０７、ジョブ情報管理データベース１０８の構成を省略している。また、図３３は変換手段１２０をＷｏｒｋｅｒ１２０と記載している。

図３３に示すように、データ変換システム１００は、メッセージキュー１１２にジョブを登録しておき、Ｗｏｒｋｅｒ１２０がジョブを一つずつ処理していく。なお、図３３ではメッセージキュー１１２がデータ変換の種類「ｄｏｃ２ｒｐｃｓ」及び「ｐｄｆ２ｒｐｃｓ」に対応するキューを有している。また、図３３ではＷｏｒｋｅｒ１２０が「ｄｏｃ２ｒｐｃｓ」及び「ｐｄｆ２ｒｐｃｓ」のデータ変換処理を行うことができる。

フロントエンドアプリケーション１０２ａは、必要なデータ変換の種類を例えば「ｔｙｐｅ＝ｄｏｃ２ｒｐｃｓ」のようなパラメータにして、非同期変換サーバ１０１に送信するリクエスト（ジョブ）に埋め込む。

リクエストを受け取った非同期変換サーバ１０１のデータ変換要求管理手段１１１はリクエストを解析して、データ変換の種類に合致するメッセージキュー１１２のデータ変換の種類「ｄｏｃ２ｒｐｃｓ」のキューに、ジョブ（メッセージ）を入れる。

ここでは「ジョブ１」及び「ジョブ２」が一般ユーザのジョブであり、「ジョブ２」及び「ジョブ４」がプレミアムユーザであるものとして説明する。ジョブを処理する順番に優先度を付けないデータ変換システム１００では、図３３のように一般のユーザのジョブもプレミアムユーザのジョブも同じキューに入れられるため、キューに入れられた順番に処理される。処理時間が長いジョブと処理時間が短いジョブとがある場合も同様に処理される。

即ち、各Ｗｏｒｋｅｒ１２０は、データ変換の種類「ｄｏｃ２ｒｐｃｓ」及び「ｐｄｆ２ｒｐｃｓ」に対応するキューを監視しており、キューに入れられた順番にジョブを処理する。

次に、ジョブを処理する順序に優先度を付けるデータ変換システム１００について図３４を参照しつつ説明する。図３４はジョブを処理する順序に優先度を付けるデータ変換システムの構成例を示すブロック図である。

なお、図３４は図４のデータ変換システム１００に示した共有ファイルストレージ１０７、ジョブ情報管理データベース１０８の構成を省略している。また、図３４は変換手段１２０をＷｏｒｋｅｒ１２０と記載している。

図３４のデータ変換システム１００は、一般ユーザ用のキューとプレミアムユーザ用のキューと、をメッセージキュー１１２に用意している。例えば図３４のデータ変換システム１００はデータ変換の種類「ｄｏｃ２ｒｐｃｓ」及び「ｐｄｆ２ｒｐｃｓ」に対応する一般ユーザ用のキューとプレミアムユーザ用のキューとを用意している。

図３４ではデータ変換の種類「ｄｏｃ２ｒｐｃｓ」の一般ユーザ用のキューを「ｄｏｃ２ｒｐｃｓ」と記載する。また、データ変換の種類「ｐｄｆ２ｒｐｃｓ」の一般ユーザ用のキューを「ｐｄｆ２ｒｐｃｓ」と記載する。

また、データ変換の種類「ｄｏｃ２ｒｐｃｓ」のプレミアムユーザ用のキューを「ｄｏｃ２ｒｐｃｓ＿ｐｒｅｍ」と記載する。また、データ変換の種類「ｐｄｆ２ｒｐｃｓ」のプレミアムユーザ用のキューを「ｐｄｆ２ｒｐｃｓ＿ｐｒｅｍ」と記載する。

また、図３４のデータ変換システム１００は、プレミアムユーザ優先のＷｏｒｋｅｒ１２０と、一般ユーザ優先のＷｏｒｋｅｒ１２０とを用意している。なお、図３４ではプレミアムユーザ優先のＷｏｒｋｅｒ１２０も一般ユーザ優先のＷｏｒｋｅｒ１２０も処理できるデータ変換の種類が同一であるが、優先して処理を行うキューが異なっている。

例えば図３４の一般ユーザ優先のＷｏｒｋｅｒ１２０は一般ユーザ用のキューのジョブを優先して処理する。プレミアムユーザ優先のＷｏｒｋｅｒ１２０はプレミアムユーザ用のキューのジョブを優先して処理する。なお、図３４の各Ｗｏｒｋｅｒ１２０上には優先して処理を行う順番に、キューが記載されている。

図３４のように、一般ユーザ優先のＷｏｒｋｅｒ１２０の数よりもプレミアムユーザ優先のＷｏｒｋｅｒ１２０の数を多くすることで、一般ユーザ用のキューにジョブが先に入れられても、プレミアムユーザ用のキューに入れられたジョブが優先的に処理される。

なお、プレミアムユーザ用のキューにジョブが無い場合、プレミアムユーザ優先のＷｏｒｋｅｒ１２０は、一般ユーザ用のキューのジョブを処理することで、ジョブが存在するのにＷｏｒｋｅｒ１２０が処理しない状況を回避し、稼働率を向上させる。

一般ユーザ用のキューにジョブが無い場合も、一般ユーザ優先のＷｏｒｋｅｒ１２０はプレミアムユーザ用のキューのジョブを処理することで、ジョブが存在するのにＷｏｒｋｅｒ１２０が処理しない状況を回避し、稼働率を向上させる。

フロントエンドアプリケーション１０２ａは、必要なデータ変換の種類を例えば「ｔｙｐｅ＝ｄｏｃ２ｒｐｃｓ」のようなパラメータにして、非同期変換サーバ１０１に送信するリクエスト（ジョブ）に埋め込む。

リクエストを受け取った非同期変換サーバ１０１のデータ変換要求管理手段１１１はリクエストを解析して、一般ユーザからのリクエストかプレミアムユーザからのリクエストかを判定する。一般ユーザかプレミアムユーザかの判定はリクエストの中に識別子を含ませて判定してもよいし、ユーザＩＤなどのユーザ特定情報から判定してもよい。例えば一般ユーザかプレミアムユーザかの情報をユーザＩＤなどのユーザ特定情報と対応付けて認証用データベース１０６に登録しておけば、一般ユーザによるプレミアムユーザのなりすまし等を防ぐこともできる。

そして、データ変換要求管理手段１１１は一般ユーザからのリクエストであると判定すると、データ変換の種類に合致する一般ユーザ用のキューに、ジョブ（メッセージ）を振り分ける。データ変換要求管理手段１１１はプレミアムユーザからのリクエストであると判定すると、データ変換の種類に合致するプレミアムユーザ用のキューにジョブを振り分ける。

図３４では一般ユーザ用のキューに一般ユーザからの「ジョブ１」〜「ジョブ３」が振り分けられた様子を表している。また、プレミアムユーザ用のキューにプレミアムユーザからの「ジョブ１」〜「ジョブ５」が振り分けられた様子を表している。一般ユーザ用のキューに振り分けられた一般ユーザからの「ジョブ１」は一般ユーザ優先のＷｏｒｋｅｒ１２０によって処理されている。また、プレミアムユーザ用のキューに振り分けられたプレミアムユーザからの「ジョブ１」〜「ジョブ３」はプレミアムユーザ優先のＷｏｒｋｅｒ１２０によって処理されている。

ジョブを処理する順番に優先度を付けるデータ変換システム１００では、一般のユーザのジョブとプレミアムユーザのジョブとを異なるキューに入れることでプレミアムユーザのジョブを優先的に処理できる。

なお、データ変換要求管理手段１１１によるジョブの振り分けは、一般ユーザ及びプレミアムユーザなどのユーザの種類の他、一般企業及びプレミアム企業などの企業の種類によっても行うことができる。

このように、本実施形態によれば、ジョブの優先度によりジョブを処理する順番を変更できる。例えば一般ユーザのジョブよりプレミアムユーザのジョブの方を優先的に処理することにより、プレミアムユーザの利用価値を向上させることができる。また、処理時間が長いジョブより処理時間が短いジョブの方を優先的に処理することにより、処理時間が長いジョブによって処理時間が短いジョブが待たされることを防ぐことができ、ユーザの利便性を向上させることができる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。なお、特許請求の範囲に記載した実行手段は変換手段１２０、実行手段２２０、データ形式変換部１１３２に相当する。管理手段はデータ変換要求管理手段１１１、処理実行要求管理手段２１１、処理制御部１１２４に相当する。保持手段はメッセージキュー１１２、２１２、１１３１に相当する。データ記憶装置はオンラインストレージ１４に相当する。

１０ クラウド
１１ サーバ
１２ ＰＣ（パーソナルコンピュータ）
１３ ＭＦＰ（複合機）
１４ オンラインストレージ
１００ データ変換システム
１０１ 非同期変換サーバ
１０２ 印刷ジョブ管理サーバ
１０２ａ、２０２ａ、１１１１ａ フロントエンドアプリケーション
１０３ ファイヤウォール
１０４ リバースプロキシ
１０５ 認証サーバ
１０６ 認証用データベース
１０７ 共有ファイルストレージ
１０８ ジョブ情報管理データベース
１１１ データ変換要求管理手段
１１２、２１２ メッセージキュー
１２０ 変換手段
１２０ａ 変換処理ライブラリ
１２０ｂ 変換エンジン
２００ 処理実行システム
２０１ 非同期処理サーバ
２０２ ジョブ管理サーバ
２０７ 共有ファイルストレージ
２０８ ジョブ情報管理データベース
２１１ 処理実行要求管理手段
２２０ 実行手段
２２０ａ 処理ライブラリ
２２０ｂ 処理エンジン
１０００ システム
１０１１ クライアント端末
１０１２ 携帯端末
１０１３ 画像形成装置
１０２１ アクセス制御装置
１０２２ プリントサービス提供装置
１０２３ スキャンサービス提供装置
１０２４ 他サービス提供装置
１１００ サービス提供システム
１１０１ サービスアプリ
１１０２ プラットフォーム
１１０３ 管理データ記憶部
１１０４ プラットフォームＡＰＩ（Application Programming Interface）
１１１１ プリントサービスアプリ
１１１２ スキャンサービスアプリ
１１１３ その他のサービスアプリ
１１２１ 認証処理部
１１２２ 機器通信部
１１２３ セッション管理部
１１２４ 処理制御部
１１２５ データ処理部
１１３１ メッセージキュー
１１３２ データ形式変換部
１１４１ 組織管理情報記憶部
１１４２ ユーザ管理情報記憶部
１１４３ 機器管理情報記憶部
１１４４ ジョブ管理情報記憶部
１１４５ データストレージ
１５００ コンピュータシステム
１５０１ 入力装置
１５０２ 表示装置
１５０３ 外部Ｉ／Ｆ
１５０３ａ 記録媒体
１５０４ ＲＡＭ
１５０５ ＲＯＭ
１５０６ ＣＰＵ
１５０７ 通信Ｉ／Ｆ
１５０８ ＨＤＤ
Ｂ バス
ＦＷ ファイヤウォール
Ｎ１〜Ｎ３ ネットワーク

特開２０１１−１９２２５０号公報

Claims (11)

1. 一以上の情報処理装置を含むように構成される情報処理システムであって、
   処理実行要求を処理の種類により振り分ける管理手段と、
   振り分けられた前記処理実行要求を処理の種類ごとに保持する保持手段と、
   保持された前記処理実行要求に対応した処理を実行する複数の実行手段と
   を備え、
   前記複数の実行手段の少なくとも１つは、前記保持手段が保持する前記処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させること
   を特徴とする情報処理システム。
2. 前記他の実行手段は、
   前記複数の実行手段の少なくとも１つが前記保持手段に保持させた前記処理実行要求に対応した処理を実行し、前記分割した処理のうち実行されていない処理の前記処理実行要求を前記保持手段に保持させること
   を特徴とする請求項１記載の情報処理システム。
3. 前記複数の実行手段は、あるデータ形式から別のデータ形式へ所定のデータ変換を実行する変換手段と、
   第１のデータ形式の電子データを第２のデータ形式の電子データへ変換する前記処理実行要求に対応したデータ変換処理を、前記変換手段により実行されるデータ変換処理に分割し、分割したデータ変換処理を前記変換手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させる分割手段と、
   を備えることを特徴とする請求項１又は２記載の情報処理システム。
4. 前記複数の実行手段は、電子データに対して処理を行い、又は、電子データを所定のデータ記憶装置に保存する複数の処理手段と、
   電子データに対して処理を行ったあと所定のデータ記憶装置に電子データを保存する処理実行要求を、前記処理手段により実行される電子データに対する処理と所定のデータ記憶装置に電子データを保存する処理とに分割し、分割した処理を前記処理手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させる分割手段と、
   を備えることを特徴とする請求項１又は２記載の情報処理システム。
5. 前記複数の実行手段は、電子データに対して処理を行い、又は、所定のデータ記憶装置から電子データを取得する複数の処理手段と、
   所定のデータ記憶装置から電子データを取得し、電子データに対して処理を行う処理実行要求を、前記処理手段により実行される所定のデータ記憶装置から電子データを取得する処理と電子データに対する処理とに分割し、分割した処理を前記処理手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させる分割手段と、
   を備えることを特徴とする請求項１又は２記載の情報処理システム。
6. 前記保持手段はキューであり、前記他の実行手段により実行される処理に分割される前記処理実行要求を保持するキューと、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を保持するキューと、
   を含むことを特徴とする請求項１乃至５何れか一項記載の情報処理システム。
7. 一以上の情報処理装置を含むように構成される情報処理システムであって、
   処理実行要求を処理の種類及び優先度により振り分ける管理手段と、
   振り分けられた前記処理実行要求を処理の種類及び優先度ごとに保持する保持手段と、
   保持された前記処理実行要求に対応した処理を前記処理の種類及び優先度に従って実行する複数の実行手段と
   を備え、
   前記複数の実行手段の少なくとも１つは、前記保持手段が保持する前記処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させること
   を特徴とする情報処理システム。
8. 前記保持手段は、振り分けられた前記処理実行要求を処理の種類及び優先度ごとに分けて保持し、優先度の高い前記処理実行要求に対応した処理を優先して実行する前記実行手段又は優先度の低い前記処理実行要求に対応した処理を優先して実行する前記実行手段により、保持している前記処理実行要求に対応した処理を実行されること
   を特徴とする請求項７記載の情報処理システム。
9. 処理実行要求を処理の種類により振り分ける管理手段と、
   振り分けられた前記処理実行要求を処理の種類ごとに保持する保持手段と、
   保持された前記処理実行要求に対応した処理を実行する複数の実行手段と
   を備え、
   前記複数の実行手段の少なくとも１つは、前記保持手段が保持する前記処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させること
   を特徴とする情報処理装置。
10. コンピュータを、
    処理実行要求を処理の種類により振り分ける管理手段と、
    振り分けられた前記処理実行要求を処理の種類ごとに保持する保持手段と、
    保持された前記処理実行要求に対応した処理を実行する複数の実行手段と
    として機能させ、
    前記複数の実行手段の少なくとも１つは、前記保持手段が保持する前記処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させること
    を特徴とするプログラム。
11. 一以上の情報処理装置を含むように構成される情報処理システムが実行する処理実行方法であって、
    前記情報処理システムが、
    処理実行要求を処理の種類により振り分ける管理ステップと、
    振り分けられた前記処理実行要求を処理の種類ごとに保持手段に保持する保持ステップと、
    保持された前記処理実行要求に対応した処理を複数の実行手段が実行する実行ステップと
    を実行し、
    前記複数の実行手段の少なくとも１つは、前記保持手段が保持する前記処理実行要求に対応した処理を、他の実行手段により実行される処理に分割し、分割した処理を前記他の実行手段に連携させて実行させる前記処理実行要求を前記保持手段に保持させること
    を特徴とする処理実行方法。

Images