JP2017084129A - 情報処理システム、情報処理装置、情報処理方法およびプログラム - Google Patents

Abstract

【課題】処理の遅延を抑制可能な情報処理システム、情報処理装置、情報処理方法およびプログラムを提供する。【解決手段】データ変換システム１００では、印刷ジョブ管理サーバのフロントエンドアプリケーション１０２ａからの要求に従い、印刷関連のジョブを非同期変換サーバ１０１で実行する。データ変換要求管理部１１１は、ジョブ処理の要求を受付け、メッセージキュー１１２にジョブを登録する。この時、ジョブの開始日時を予約されたジョブは、メッセージキュー１１４に入れられる。起動部１２２は、予約されたジョブの開始日時に専用実行部（第１の実行部）１２１を起動し、予約ジョブが実行される。なお、予約ジョブ以外のジョブは、メッセージキュー１１３−１〜ｎに入れられ、それぞれの実行部（第２の実行部）１２０−１〜ｎで実行される。【選択図】図５

Description

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

近年、様々なクラウドサービスが市場に出始めている。例えば、クラウドコンピューティング型のプリントサービスやスキャンサービスが提供されている。これらのサービスは、認証機能、ドキュメント処理機能、ライセンス管理機能、および、ロギング機能などの共通機能を利用して実現される場合がある。このような共通機能を含むプラットフォームを商品開発者へ提供することで、開発効率の向上や、機能開発の二重投資を回避できる。

ドキュメント処理機能は、例えば、ユーザからドキュメントを処理するジョブの投入を受け付け、処理エンジンに対応したキューへキューイングし、非同期に処理を実行していく機能である。処理エンジンとしては、ファイルフォーマット変換、ＯＣＲ（Optical Character Recognition）、画像加工、外部ストレージへのアップロード、および、メール配信などが存在する。

しかしながら、従来の技術では、ドキュメント処理などの対象となるジョブの処理が遅延する場合があった。例えば、あるユーザが大量のドキュメントを処理する場合、他のユーザのジョブの処理が遅くなる場合があった。

本発明は、上記に鑑みてなされたものであって、処理の遅延を抑制可能な情報処理システム、情報処理装置、情報処理方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、処理の予約を要求する第１の要求、および、前記処理の実行を要求する第２の要求を受付ける受付部と、前記第１の要求および前記第２の要求を記憶部に記憶させる記憶制御部と、記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約された前記処理を実行する第１の実行部と、記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約されていない前記処理を実行する第２の実行部と、記憶された前記第１の要求に基づき、前記第１の実行部を起動する起動部と、を備える。

本発明によれば、処理の遅延を抑制可能になるという効果を奏する。

クラウドプリントサービスの一例を表した模式図である。 クラウドプリントサービスを実現する情報処理システムの構成例を示すブロック図である。 コンピュータシステムの一例のハードウェア構成図である。 クラウドプリントサービスの手順の一例を表したフローチャートである。 本実施形態のデータ変換システムの構成例を示すブロック図である。 データ変換要求管理部の機能構成の一例を示すブロック図である。 ジョブ情報テーブルのデータ構造の一例を示す図である。 本実施形態におけるジョブ登録処理の一例を示すフローチャートである。 予約ジョブ情報のデータ構造の一例を示す図である。 予約キューの例を示す図である。 ジョブ情報の振り分け手順の一例を説明する図である。 本実施形態における予約実行処理の一例を示すフローチャートである。 予約画面の一例を示す図である。

以下に添付図面を参照して、この発明にかかる情報処理システム、情報処理装置、情報処理方法およびプログラムの一実施形態を詳細に説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜ハードウェア構成＞
非同期変換サーバ１０１、印刷ジョブ管理サーバ１０２、認証サーバ１０５、および、ＰＣ１２は、例えば図３に示すようなハードウェア構成のコンピュータシステムにより実現される。

図３は、コンピュータシステムの一例のハードウェア構成図である。コンピュータシステム３００は、入力装置３０１、表示装置３０２、外部Ｉ／Ｆ（インタフェース）３０３、ＲＡＭ（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）、ＯＳ設定、およびネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ３０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。

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

非同期変換サーバ１０１、印刷ジョブ管理サーバ１０２、認証サーバ１０５、および、ＰＣ１２は、コンピュータシステム３００のハードウェア構成により、後述するような各種処理を実現できる。

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

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

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

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

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

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

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

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

図５に示すように、データ変換システム１００は、フロントエンドアプリケーション１０２ａと、共有ファイルストレージ１０７と、非同期変換サーバ１０１とを含む。フロントエンドアプリケーション１０２ａは、印刷ジョブ管理サーバ１０２の一機能である。非同期変換サーバ１０１は、非同期変換サービスを提供する。また、非同期変換サーバ１０１は、データ変換要求管理部１１１と、メッセージキュー１１２と、ジョブ情報管理データベース１０８と、複数の実行部１２０−１〜１２０−ｎ（第２の実行部）と、専用実行部１２１（第１の実行部）と、起動部１２２と、を含む。実行部１２０−１〜１２０−ｎを区別する必要がない場合は単に実行部１２０という場合がある。

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

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

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

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

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

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

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

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

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

メッセージキュー１１２は、複数の実行部１２０、専用実行部１２１、および、起動部１２２に対応するキューを有する。例えば、メッセージキュー１１３−１〜１１３−ｎは、実行部１２０−１〜１２０−ｎにそれぞれ対応する。メッセージキュー１１４および１１５は、専用実行部１２１および起動部１２２にそれぞれ対応する。図５では実行部１２０、専用実行部１２１、および、起動部１２２と、メッセージキュー１１２が有するキューと、が一対一に対応する例を示しているが、多対多に対応していてもよい。

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

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

専用実行部１２１は、予約されたジョブ（以下、予約ジョブと呼ぶ）を実行するための実行部である。例えば大量のジョブを実行する必要がある場合、ユーザは、開始日時などを指定して当該ジョブの実行を事前に予約する。専用実行部１２１は、このようにして予約されたジョブを実行するように制御される。専用実行部１２１が実行するジョブの情報は、メッセージキュー１１４に記憶される。メッセージキュー１１４は、以下では専用キューという場合がある。

起動部１２２は、ジョブの予約の要求（リクエスト）に従い、専用実行部１２１を起動する。例えば起動部１２２は、ジョブの予約のリクエストを記憶するメッセージキュー１１５を監視し、少なくともジョブの予約時に指定された予約期間（開始日時から終了日時までの期間）、専用実行部１２１を起動する。起動部１２２は、要求されたジョブの種類に応じて、当該種類の処理を実行する専用実行部１２１を起動してもよい。起動部１２２は、例えばジョブの種類に応じた複数の専用実行部１２１を起動してもよい。メッセージキュー１１５は、ジョブの予約のリクエストを記憶するキューであるため、以下では予約キューという場合がある。

専用実行部１２１および起動部１２２は、実行部１２０と同様にＷｏｒｋｅｒにより実現されてもよい。

なお、認証用データベース１０６、共有ファイルストレージ１０７、ジョブ情報管理データベース１０８、および、メッセージキュー１１２は、ＨＤＤ（図３ではＨＤＤ３０８）、ＲＡＭ（図３ではＲＡＭ３０４）、メモリカードなどの一般的に利用されているあらゆる記憶媒体により構成することができる。

図６は、データ変換要求管理部１１１の詳細な機能構成の一例を示すブロック図である。図６に示すように、データ変換要求管理部１１１は、受付部６０１と、記憶制御部６０２と、判定部６０３と、通信制御部６０４と、を備えている。

受付部６０１は、フロントエンドアプリケーション１０２ａなどの外部の機能から、各種情報を受付ける。例えば受付部６０１は、上記のようなデータ変換の種類とデータのＵＲＩを少なくとも含むリクエスト（第２の要求）を受付ける。また受付部６０１は、ジョブの予約のリクエスト（第１の要求）を受け付ける。

記憶制御部６０２は、受け付けられたリクエストなどの情報を、ＨＤＤ３０８、および、ＲＡＭ３０４などの記憶部に記憶させる処理を制御する。例えば記憶制御部６０２は、ジョブの予約のリクエスト、および、ジョブの実行のリクエストなどを、記憶部の一例であるメッセージキュー１１２に記憶させる。

また、記憶制御部６０２は、ジョブについてのリクエスト（以下、ジョブ情報と呼ぶ）をジョブ情報テーブルに記憶する。ジョブ情報テーブルは、例えばジョブ情報管理データベース１０８に含まれる。

図７は、ジョブ情報テーブルのデータ構造の一例を示す図である。図７に示すように、ジョブ情報テーブルは、ジョブＩＤと、種類と、テナント／ユーザと、タスクパラメータと、ステータスと、を含む。ジョブＩＤは、ジョブを識別する情報である。

種類は、ジョブの種類を表す。予約ジョブを表す場合は、種類として「reservation」が設定される。予約されていない通常のジョブ（以下、通常ジョブと呼ぶ）の場合、種類は、データ変換の種類を示す値（「doc2rpcs」、「pdf2rpcs」、「ocr」など）が設定される。

テナント／ユーザは、ジョブの送信元である組織やユーザを示す。テナント／ユーザは、例えば、ユーザのテナントを識別する情報であるテナントＩＤ、および、ユーザを識別する情報であるユーザＩＤなどである。

タスクパラメータは、ジョブの処理で用いられるパラメータである。予約ジョブの場合、予約した開始日時や終了日時などをタスクパラメータに設定してもよい。ステータスは、上記のようにジョブの処理状態を示す。例えば、ジョブ受付（accepted）、ジョブ処理中（doing）、ジョブ完了（done）、および、エラー（error）などがステータスとして設定される。

図７に示すジョブ情報テーブルのデータ構造は一例であり、この他の情報をジョブ情報テーブルに記憶してもよい。例えば、ジョブを受け付けた日時をさらに記憶してもよい。

判定部６０３は、受け付けられたリクエストが、ジョブの予約のリクエストであるか、または、ジョブの実行のリクエストであるかを判定する。また判定部６０３は、ジョブの実行のリクエストの場合、さらに、事前に予約されたジョブの実行のリクエストであるかを判定する。

通信制御部６０４は、フロントエンドアプリケーション１０２ａなどの外部の機能との間の通信を制御する。例えば通信制御部６０４は、ジョブを受け付けたことを示す通知、および、重複する予約があったことを示す通知などを、フロントエンドアプリケーション１０２ａを介して、ＰＣ１２に送信する。

次に、このように構成された本実施形態にかかる情報処理システムによるジョブ登録処理について図８を用いて説明する。図８は、本実施形態におけるジョブ登録処理の一例を示すフローチャートである。

最初に受付部６０１は、ユーザによりＰＣ１２などを介して指定されたジョブについてのリクエスト（ジョブ情報）を受け付ける（ステップＳ２０１）。判定部６０３は、受付けられたジョブ情報が、ジョブを予約するリクエスト（以下、予約ジョブ情報と呼ぶ）であるか否かを判定する（ステップＳ２０２）。

図９は、予約ジョブ情報のデータ構造の一例を示す図である。図９に示すように、予約ジョブ情報では、ジョブの種類（type）を示す値として「reservation」が設定される。また、ジョブのパラメータ（params）として、開始日時（start_at）、終了日時（end_at）、および、実行する処理（jobType）が設定される。

例えば、「今日中に月末の伝票ＯＣＲスキャンを確実に終わらせたいので、２時から４時までは誰にも邪魔されずに集中的に作業したい」というユーザニーズが想定される。他のユーザのＯＣＲジョブも投入されるため、専用実行部１２１が存在しない構成では、当日中に処理することが困難になる場合がある。従って、２時から４時の間だけＯＣＲジョブを実行する専用の実行部を用意して、他のユーザのＯＣＲジョブが投入されない状態を保証し、集中的に処理をする機能を提供することが望ましい。本実施形態では、このような機能を実現するために、ジョブの予約を実行可能とし、予約されたジョブを実行する専用実行部１２１を備えるように構成している。そして、予約のためのジョブ情報は、図９のように開始日時（start_at）、終了日時（end_at）および実行する処理（jobType）を指定できるデータ構造となっている。

なお、通常ジョブの実行のためのリクエスト（ジョブ情報）は、例えば、図９と同様のデータ構造としてもよいし、他のデータ構造としてもよい。図９と同様のデータ構造とする場合は、例えば、ジョブの種類（type）に「reservation」以外の値を設定し、パラメータ（params）内の各項目（開始日時（start_at）、終了日時（end_at）、実行する処理（jobType））に「null」などの固定値を設定してもよい。

図８に戻り、ジョブ情報が予約ジョブ情報であった場合（ステップＳ２０２：Ｙｅｓ）、予約処理（ステップＳ２０３〜ステップＳ２０６）が実行される。予約処理は、予約ジョブ情報で予約が要求されたジョブを予約する処理である。まず記憶制御部６０２は、予約キューから、以前に予約されたジョブの一覧（以下、予約ジョブ一覧と呼ぶ）を取得する（ステップＳ２０３）。後述するようにジョブ情報テーブルにも同じ情報が格納されているが、ジョブ情報テーブルには「type」が「reservation」以外のジョブも格納されているので、予約キューを参照した方が効率よく処理できる。

判定部６０３は、予約ジョブ一覧に含まれる予約の中に、受け付けた予約ジョブ情報と予約期間が重複する予約があるか否かを判定する（ステップＳ２０４）。例えば判定部６０３は、取得した予約ジョブ一覧に、受け付けた予約ジョブ情報に対して、開始日時と終了日時で表される予約期間が重複し、かつ、実行する処理（jobType）が同じ予約ジョブが含まれるか判定する。

重複する予約がある場合（ステップＳ２０４：Ｙｅｓ）、通信制御部６０４は、重複する予約があることを、例えばフロントエンドアプリケーション１０２ａを介して、ジョブ情報の送信元（ＰＣ１２など）に送信する（ステップＳ２０５）。重複する予約がない場合（ステップＳ２０４：Ｎｏ）、判定部６０３は、予約ジョブの予約キューへの挿入位置を決定する（ステップＳ２０６）。

図７のジョブ情報テーブルで示される例のように、ジョブＩＤ＝「０００２」、「０００５」、「０００６」の３つの予約ジョブが既に予約キューに格納されているとする。図１０の左に示すキューは、この場合の予約キューの例を示す図である。この例に示すように、記憶制御部６０２は、開始日時の順に予約ジョブの情報を予約キューに記憶してもよい。なお、図１０はジョブＩＤのみを記載しているが、ジョブＩＤ以外の情報を記憶してもよい。例えば図７のジョブ情報テーブルと同じ情報を予約キューが記憶してもよい。

キューが図１０の左に示す状況で、新たにジョブＩＤ＝「０００７」の予約ジョブが投入されたとする。開始日時と終了日時を考慮すると、この予約ジョブは、ジョブＩＤ＝「０００２」の予約ジョブと、ジョブＩＤ＝「０００５」の予約ジョブとの間に実行する必要がある。従って、判定部６０３は、図１０の右のキューのように、新たな予約ジョブの挿入位置を２番目に決定する。

以上で予約処理は完了する。既に予約ジョブであることがわかっており、後段の予約確認を実施する必要がないので、ジョブ情報の蓄積（ステップＳ２１０）へ進む。

ステップＳ２０２で、ジョブ情報が予約ジョブ情報でないと判定された場合（ステップＳ２０２：Ｎｏ）、予約確認処理（ステップＳ２０７〜ステップＳ２０９）が実行される。予約確認処理は、実行が要求されたジョブが、予約済みのジョブであるかを確認する処理である。受け付けられたジョブ情報が予約ジョブ情報でない場合、当該ジョブ情報は、予約済みのジョブを予約期間中に実行するために投入されたジョブ（以下、専用ジョブと呼ぶ）、または、通常ジョブのいずれかである。予約確認処理では、ジョブ情報をこれらのいずれかに振り分ける。

記憶制御部６０２は、予約キューから予約ジョブ一覧を取得する（ステップＳ２０７）。判定部６０３は、受け付けたジョブ情報が予約済みのジョブであるか否かを判定する（ステップＳ２０８）。例えば判定部６０３は、予約ジョブ一覧に含まれる予約ジョブから、現在時刻が予約期間に含まれ、かつ、ユーザと実行する処理（jobType）が一致する予約ジョブを探し出す。ユーザが一致するかは、例えば、ユーザのテナントを識別する情報であるテナントＩＤ（図９の例では「organization_id」）、および、ユーザを識別する情報であるユーザＩＤ（図９の例では「user_id」）などを用いて判定できる。

予約ジョブでない場合（ステップＳ２０８：Ｎｏ）、通常ジョブなので、ステップＳ２１０へ進む。予約ジョブである場合（ステップＳ２０８：Ｙｅｓ）、記憶制御部６０２は、専用キューに振り分けるためにジョブの種類（type）を書き換える（ステップＳ２０９）。例えば記憶制御部６０２は、元の「type」の後に予約者（予約したユーザ）のテナントＩＤとユーザＩＤを「_」で繋いだ文字列に書き換える。例えば「type」が「ocr」であった場合、「ocr」が「ocr_（tenantID）_（userID）」の形式に書き換えられる。

予約処理および予約確認処理の後、記憶制御部６０２は、受け取ったジョブ情報を、ジョブ情報管理データベース１０８内のジョブ情報テーブルに蓄積する（ステップＳ２１０）。例えば記憶制御部６０２は、ジョブＩＤ（_id）を発行してジョブ情報をジョブ情報テーブルに蓄積する。

図７に示すように、ジョブ情報テーブルには、予約ジョブおよび通常ジョブの両方が記憶される。図７の例では、ジョブＩＤ＝「０００２」、「０００５」、「０００６」、および、「０００７」が予約ジョブであり、ジョブＩＤ＝「０００１」、「０００３」、および、「０００４」が通常ジョブである。

記憶制御部６０２は、ジョブ情報を対応するキューに追加する（ステップＳ２１１）。例えば記憶制御部６０２は、ジョブの種類などを参照して、ジョブ情報をメッセージキュー１１２内の対応するキューに振り分ける。

図１１は、ジョブ情報の振り分け手順の一例を説明する図である。データ変換要求管理部１１１（記憶制御部６０２）は、例えばジョブ情報の「type」が「（type）_（tenantID）_（userID）」の形式であった場合、このジョブ情報を専用キューであるメッセージキュー１１４に振り分ける。記憶制御部６０２は、「type」が「reservation」である予約ジョブのジョブ情報を、メッセージキュー１１５に振り分ける。予約処理で予約キューへの挿入位置が決まっていれば、記憶制御部６０２は、その位置に予約ジョブを格納する。記憶制御部６０２は、それ以外の種類（type）のジョブ情報を、種類に対応するメッセージキュー１１３−１〜１１３−ｎのいずれかに振り分ける。

通信制御部６０４は、ジョブを受け付けたことを示す通知を、ジョブの送信元に送信し（ステップＳ２１２）、ジョブ登録処理を終了する。

以上の処理で、予約ジョブの受付、専用ジョブの受付、および、通常ジョブの受付が可能となった。次に、予約に応じた専用実行部１２１の機能について説明する。図１２は、本実施形態における予約実行処理の一例を示すフローチャートである。

起動部１２２は、一定の待機時間（例えば１分）が経過するごとに予約キューを監視し、予約キューからジョブを取得する（ステップＳ３０１）。予約キューに開始日時の順に予約ジョブが記憶されている場合であれば、起動部１２２は、開始日時が早い予約ジョブを予約キューから読み出してもよい。起動部１２２は、現在日時から、取得したジョブの開始日時までの時間が、所定の閾値（例えば１０分）より小さいか否かを判断する（ステップＳ３０２）。開始日時−現在日時の値が閾値より小さい場合（ステップＳ３０２：Ｙｅｓ）、すなわち、現在日時が開始日時に迫っている場合、起動部１２２は、専用実行部１２１を起動する（ステップＳ３０３）。起動部１２２は、例えば「jobType」を参照し、起動する専用実行部１２１の種類を決定してもよい。

起動部１２２による起動方法は、一般的な方法で構わない。例えば、Ｗｉｎｄｏｗｓ（登録商標）サーバ上でサービスとして起動する方法、Ｌｉｎｕｘ（登録商標）サーバ上でバックグラウンドプロセスとして起動する方法、および、サーバインスタンスをイメージ化してイメージをコピーすることでサーバを増やす方法などを適用できる。起動部１２２は、起動する際に、「jobType」の後に予約者のテナントＩＤとユーザＩＤを「_」で繋いだ文字列を引数に起動してもよい。この場合、専用実行部１２１は、指定された引数に対応するキューを監視するように動作する。

起動部１２２はさらに、起動した専用実行部１２１が終了日時に停止するように設定してもよい（ステップＳ３０４）。終了日時の設定方法は、一般的な方法で構わない。例えば、Ｗｉｎｄｏｗｓサーバではタスクスケジューラにサービスの停止日時をスケジュールする方法、および、Ｌｉｎｕｘサーバでは「ｃｒｏｎ」によって指定プロセスを終了日時に停止するように設定する方法などを適用できる。

専用実行部１２１は、処理実行中にサービスおよびプロセスを停止するように指示された場合に、実行中の処理が完了するまでは処理を続ける機能を搭載してもよい。これにより、上記のように終了処理を実施しても問題は生じない。

起動部１２２は、ジョブ情報テーブルに記憶される予約ジョブのステータスを「完了（done）」状態に更新する（ステップＳ３０５）。

ステータスを更新後、および、ステップＳ３０２で「開始日時−現在日時」の値が閾値以上であると判断された場合（ステップＳ３０２：Ｎｏ）、起動部１２２は、待機時間が経過したかを判定する（ステップＳ３０６）。経過していない場合（ステップＳ３０６：Ｎｏ）、起動部１２２は、経過するまで待機する。経過した場合（ステップＳ３０６：Ｙｅｓ）、ステップＳ３０１に戻り処理が繰り返される。

（変形例）
判定部６０３は、予約キューのどの位置に新たな予約ジョブを挿入するかを判断していたが、そのような判断を実施しなくてもよい。この場合、例えば起動部１２２が、予約キューに記憶された１以上の予約ジョブ（例えばすべての予約ジョブ）を取得し、それぞれの開始日時を参照して、いずれの予約ジョブから処理すべきかを判断しても構わない。すなわち起動部１２２は、読み出した予約ジョブの開始日時のうち、他の予約ジョブの開始日時より早い開始日時に、対応する専用実行部１２１を起動してもよい。

また、起動部１２２は、予約ジョブ（予約キュー）のみを監視しているが、通常ジョブの監視、および、通常ジョブに対応する実行部１２０の起動を合わせて実施してもよい。例えば起動部１２２は、予約キュー（メッセージキュー１１５）と、「pdf2rpcs」の処理に対応するキュー（メッセージキュー１１３−１〜１１３−ｎのいずれか）とを監視し、これらのキューのジョブを交互に処理しても構わない。

また、予約ジョブを完了するとき、予約ジョブのステータスを完了（done）ではなく処理中（doing）にすることで、予約キューに該当ジョブを残すように構成してもよい。そして起動部１２２は、ステータスが「doing」である予約ジョブを取得した場合に、当該予約ジョブに対応する専用実行部１２１が稼働しているか否かを確認し、稼働していなければ再度起動処理を実行してもよい。また起動部１２２は、現在日時が、ステータスが「doing」である予約ジョブの終了日時を超えていた場合は、当該ジョブのステータスを「done」に変更し、予約ジョブを終わらせる。この際、予約キューからジョブを次々に取得し、ステータスが「doing」の場合は上記処理を実施し、ステータスが「accepted」の予約ジョブを取得したら起動処理を実施して１分待つようにすれば、次々に専用実行部１２１を起動および監視することができる。

予約の情報を課金処理に用いるように構成してもよい。上記のように、予約ジョブおよび専用ジョブは、ジョブ情報管理データベース１０８内のジョブ情報テーブルに格納されている。予約ジョブの情報のうち、例えば以下の情報を課金処理に用いることができる。
「organization_id」＋「user_id」：ジョブをリクエストしたユーザ（請求先）
「created_at」：ジョブを受け付けた日時
「start_at」：予約開始日時
「end_at」：予約終了日時
「jobType」：予約した処理内容
「status」：ジョブのステータス

課金料金は、例えば以下の手順で算出される。課金処理は、例えば印刷ジョブ管理サーバ１０２などの装置内でスクリプト等により実行するように構成できる。
（１）ジョブの種類（jobType）に応じた課金の単価を取得する（ＯＣＲなら１００円／ジョブ、ＰＤＬ変換なら２０円／ジョブなど）。
（２）終了日時（end_at）−開始日時（start_at）により利用期間を求める。
（３）利用期間中で種類が「（type）_（tenantID）_（userID）」の形式であるジョブをジョブ情報テーブルから取得する。
（４）状態（status）が「done」であるジョブをカウントし、利用数を求める。
（５）課金単価×利用数で課金料金を算出する。
（６）予約の早割を以下のようにディスカウントする。
・１か月以上前：ディスカウント５０％
・１５日以上前：ディスカウント２５％
・５日以上前：ディスカウント１０％
・それ以外：ディスカウント０％

本機能を利用し続けているユーザは、毎月月末の伝票処理が決まっている場合は、およそ毎月何時間の作業になるかを把握することができる。このため、何時から何時まで予約すればよいかを経験的に概算できる。また、上記のような課金体系の場合は、予約を利用することにより、料金のディスカウントを受けることが可能となる。

予約した場合の料金を、予約時に用いられる画面（予約画面）を介してユーザに提示するように構成してもよい。図１３は、予約画面の一例を示す図である。予約画面１３１０では、予約する期間、および、予約する処理（機能）が指定される。「予約する」ボタン１３０１が押下されると、指定されたジョブが実行された場合の料金等を提示するための確認画面１３２０が表示される。重複する予約がある場合、例えば図１３の確認画面１３３０のように、重複する予約があることを示すメッセージが表示されてもよい。

非同期変換サーバ１０１は、１つの装置（情報処理装置）により実現してもよいし、複数の装置を含む情報処理システムの各装置に、非同期変換サーバ１０１の各機能を分散して備えるように構成してもよい。

なお、本実施形態の装置で実行されるプログラムは、ＲＯＭ等に予め組み込まれて提供される。

本実施形態の装置で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータ・プログラム・プロダクトとして提供するように構成してもよい。

さらに、本実施形態の装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

本実施形態の装置で実行されるプログラムは、上述した各部を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記ＲＯＭからプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各部が主記憶装置上に生成されるようになっている。

１０ クラウド
１１ サーバ
１２ ＰＣ
１３ ＭＦＰ
１００ データ変換システム
１０１ 非同期変換サーバ
１０２ 印刷ジョブ管理サーバ
１０３ ファイヤウォール
１０４ リバースプロキシ
１０５ 認証サーバ
１０６ 認証用データベース
１０７ 共有ファイルストレージ
１０８ ジョブ情報管理データベース
１１１ データ変換要求管理部
１１２ メッセージキュー
１２０ 実行部
１２１ 専用実行部
１２２ 起動部
６０１ 受付部
６０２ 記憶制御部
６０３ 判定部
６０４ 通信制御部

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

Claims (10)

1. 処理の予約を要求する第１の要求、および、前記処理の実行を要求する第２の要求を受付ける受付部と、
   前記第１の要求および前記第２の要求を記憶部に記憶させる記憶制御部と、
   記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約された前記処理を実行する第１の実行部と、
   記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約されていない前記処理を実行する第２の実行部と、
   記憶された前記第１の要求に基づき、前記第１の実行部を起動する起動部と、
   を備える情報処理システム。
2. 前記第１の要求は、前記処理の開始日時を少なくとも含み、
   前記記憶制御部は、前記処理の開始日時の順に前記第１の要求を前記記憶部に記憶させ、
   前記起動部は、前記開始日時が早い前記第１の要求を前記記憶部から読み出し、読み出した前記第１の要求に含まれる前記開始日時に前記第１の実行部を起動する、
   請求項１に記載の情報処理システム。
3. 前記第１の要求は、前記処理の開始日時を少なくとも含み、
   前記起動部は、前記記憶部に記憶された１以上の前記第１の要求を読出し、読み出した前記第１の要求に含まれる前記開始日時のうち、他の前記第１の要求に含まれる前記開始日時より早い前記開始日時に前記第１の実行部を起動する、
   請求項１に記載の情報処理システム。
4. 前記第１の要求は、前記処理の開始日時、および、前記処理の終了日時を少なくとも含み、
   前記起動部は、前記開始日時に前記第１の実行部を起動し、起動した前記第１の実行部を前記終了日時に停止する、
   請求項１に記載の情報処理システム。
5. 前記起動部は、さらに、記憶された前記第２の要求に基づき、前記第２の実行部を起動する、
   請求項１に記載の情報処理システム。
6. 前記起動部は、起動した前記第１の実行部が稼働しているか否かを監視し、稼働していない場合は起動する、
   請求項１に記載の情報処理システム。
7. 前記第１の要求は、前記処理の開始日時、前記処理の終了日時、および、前記処理の種類を含む、
   請求項１に記載の情報処理システム。
8. 処理の予約を要求する第１の要求、および、前記処理の実行を要求する第２の要求を受付ける受付部と、
   前記第１の要求および前記第２の要求を記憶部に記憶させる記憶制御部と、
   記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約された前記処理を実行する第１の実行部と、
   記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約されていない前記処理を実行する第２の実行部と、
   記憶された前記第１の要求に基づき、前記第１の実行部を起動する起動部と、
   を備える情報処理装置。
9. 処理の予約を要求する第１の要求、および、前記処理の実行を要求する第２の要求を受付ける受付ステップと、
   前記第１の要求および前記第２の要求を記憶部に記憶させる記憶制御ステップと、
   第１の実行部が、記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約された前記処理を実行する第１の実行ステップと、
   第２の実行部が、記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約されていない前記処理を実行する第２の実行ステップと、
   記憶された前記第１の要求に基づき、前記第１の実行部を起動する起動ステップと、
   を含む情報処理方法。
10. コンピュータに、
    処理の予約を要求する第１の要求、および、前記処理の実行を要求する第２の要求を受付ける受付ステップと、
    前記第１の要求および前記第２の要求を記憶部に記憶させる記憶制御ステップと、
    第１の実行部が、記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約された前記処理を実行する第１の実行ステップと、
    第２の実行部が、記憶された前記第２の要求により要求される前記処理のうち、前記第１の要求により予約されていない前記処理を実行する第２の実行ステップと、
    記憶された前記第１の要求に基づき、前記第１の実行部を起動する起動ステップと、
    を実行させるためのプログラム。

Images