JP6171346B2 - 情報処理装置、処理実行方法、プログラム - Google Patents

Description

順番に実行される一連の処理の設定を受け付ける機器とネットワークを介して通信可能な情報処理装置等に関する。

データの入力、変換、出力が組み合わされた一連の処理を、サーバやＭＦＰ（Multi Function Peripheral）等の装置が実行する処理実行システムが知られている。入力、変換、出力はそれぞれ独立したモジュールで実行される。したがって、ＭＦＰ等のユーザはモジュールを追加することで、入力、変換又は出力のバリエーションを増やすことが可能になる。

ＭＦＰでは、印刷ページ数などの従量制で課金する課金形態が採用されているが、サービスの提供者としてはモジュールに対しても同様に従量課金することが考えられる。しかし、モジュール単体では従量課金になじまない場合もあり（例えば、出力を伴わない処理だけには課金しづらい）、追加時に一括して又は定期的にモジュールに対し課金する場合が多い。ユーザから見ると、モジュールの利用量が多い場合には割安に感じるが、利用しなかったモジュールについても固定的な料金を支払う必要があるため、利用状況に即した課金を要望するユーザも存在する。

利用状況に即した課金として、入力、変換、出力の組み合わせに応じた課金プランを複数種類記憶しておき、ジョブログの情報に基づいて課金プランを選択して、入力、変換、出力の組み合わせに課金する技術が考えられている（例えば、特許文献１参照。）。この課金方法では、実行した一連の処理（入力、変換、出力の組み合わせ）毎に課金できるので、利用状況に即した課金が可能になる。

しかしながら、特許文献１に記載された課金方法では、課金方法が固定化されているため、入力、変換、出力の同じ組み合わせに対しては同じ課金方法でしか課金できないという問題がある。

例えば、ＭＦＰが処理ａ、処理ｂ、処理ｃを実行する場合、企業などでは、利用者やデータの入力先によって処理ａ〜ｃの課金方法を個別に変えたいという要請がある。また、サービス提供者としても、処理ａ〜ｃのそれぞれでどのように従量課金をするか（例えば、処理ａは完全な従量制だが、処理ｂは一定量以下は定額）を変更したい場合がある。このように、従来の課金方法では、入力、変換、出力の組み合わせに対し柔軟に課金することができなかった。

本発明は、上記課題に鑑み、複数の処理を組み合わせて行われる一連の処理に対し、柔軟に課金する情報処理装置を提供することをと目的とする。

本発明は、順番に実行される一連の処理の設定を受け付ける機器とネットワークを介して通信可能な情報処理装置であって、各処理の処理内容と処理の順番が定義された処理定義情報、処理対象データ、及び、前記一連の処理の料金を算出するための算出パラメータを受信する受信手段と、当該処理に特有の課金規則を保持し、固有の処理を実行する複数の処理実行手段と、前記処理定義情報を解析して次に実行する処理を決定する処理決定手段と、前記処理実行手段が処理した処理結果に基づき前記算出パラメータを更新すると共に、前記課金規則に必要な情報を前記算出パラメータに基づいて取得して前記算出パラメータを更新するパラメータ更新手段と、処理ごとに更新された前記算出パラメータを前記課金規則に適用して、前記処理実行手段が実行した処理毎に課金情報を算出する算出手段と、を有することを特徴とする。

複数の処理を組み合わせて行われる一連の処理に対し、柔軟に課金する情報処理装置を提供することができる。

課金方法の概略的な特徴を説明する図の一例である。 処理実行システムのシステム構成図の一例である。 ＭＦＰとしてのワークフロー実行要求装置のハードウェア構成図の一例である。 ＰＣやサーバとして構成された処理サーバのハードウェア構成図の一例である。 フロー定義情報を模式的に説明する図の一例である。 ワークフロー実行要求装置、及び、処理サーバの機能ブロック図の一例である。 プラグインの機能ブロック図、算出パラメータの一例を示す図である。 処理実行システムの全体的な動作手順の一例を示す図である。 処理実行システムのシステム構成図の一例である（実施例２）。 ワークフロー実行要求装置、及び、処理サーバの機能ブロック図の一例である（実施例２）。 処理実行システムの全体的な動作手順の一例を示す図である。

以下、図面を参照して本発明の実施形態について説明する。しかしながら、本発明の技術的範囲が、本実施の形態に限定されるものではない。

図１は、本実施形態の課金方法の概略的な特徴を説明する図の一例である。図１（ａ）に示すように、処理サーバ１００には入力、変換及び出力のそれぞれに１つ以上のモジュールがインストールされている。各モジュールはプラットホームが呼び出すことで動作する単体で追加可能なプログラムである。以下、モジュールをプラグインと称し、プラットホームをフロー制御部と称する。

フロー制御部２２は、適宜、プラグインを呼び出して（ジョブを投入して）、入力、変換、出力の一連の処理を実行する。プラグインを組み合わせてデータを処理することをワークフローと称する。フロー定義ＤＢには管理者が設定したいくつかのワークフローのフロー定義情報が記憶されている。フロー定義ＤＢのフロー定義情報は、処理と処理の順番を定義したものである。

図１（ｂ）に示すように各プラグインは、課金制御部５３を有している。課金制御部５３はプラグインに専用の課金ルールを有している。課金ルールには、算出パラメータに応じてプラグインの使用に対する料金を算出するための規則が記述されている。

フロー制御部２２の課金処理部３６は、課金制御部５３から課金ルールを取得し、また、ワークフローと共に送信される算出パラメータを課金ルールに適用することでプラグイン毎に料金を算出する。したがって、本実施形態の処理サーバ１００は、使用した分だけ課金されるという従量制の課金が可能になる。また、プラグインの組み合わせが同じでも、プラグイン毎に従量課金されるので、各プラグインの課金ルールに従ってワークフローの全体に柔軟に課金することができる。

また、フロー制御部２２はプラグインが処理を実行する毎に算出パラメータを更新することができる。変換などによりデータ量が変わることに対応するためである。これにより、処理により処理対象のデータ量などが変わっても、最初のデータ量や最終的なデータ量ではなく、各処理に対し施された実際の処理量を用いて処理毎に料金を算出できる。

〔構成例〕
図２は、処理実行システム５００のシステム構成図の一例を示す。処理サーバ１００を中心に、ネットワーク４００を介してワークフロー実行要求装置２００と管理者ＰＣ（Personal Computer）１５０が接続されている。処理サーバ１００が中心にあるのは処理上の位置を示すにすぎず、ワークフロー実行要求装置２００と管理者ＰＣ１５０も互いにネットワーク４００を介して接続されている。また、処理サーバ１００が２台以上ある場合もあり、処理サーバ同士が１つのワークフローを分担して実行することも可能である。

ネットワーク４００は、ＬＡＮ、又は、複数のＬＡＮがルータなどを介して接続されたＷＡＮである。また、インターネットを含んでいてよい。ネットワーク４００は有線で構築されていてもよいし、一部又は全てを無線ＬＡＮ（IEEE802.11b/a/g/n等）で構築されていてもよい。さらに、ネットワーク４００は携帯電話網、WiMAX網、ＰＨＳ網などの移動体向けに構築された通信網を含む。なお、処理実行システム５００の機器が例えば無線ＬＡＮのアドホックモードなどで１対１で通信しても、ネットワーク４００に含めることとする。

ワークフロー実行要求装置２００はワークフローの実行を処理サーバ１００に要求する装置である。例えば、ＭＦＰ（Multi Function Peripheral）２０１、携帯端末２０２、クライアント端末２０３が図示されているが、通信機能を備えた情報処理装置はワークフロー実行要求装置２００になりうる。ワークフロー実行要求装置２００は処理実行システム５００に１台以上存在する。ＭＦＰ２０１は、コピー機、スキャナー、プリンタ、ファックス装置など画像を形成する機能を備えた装置である。ＭＦＰ２０１はこのうち１つ以上の機能を有していればよい。ＭＦＰ２０１は、例えば原稿をスキャンして作成した画像データ（後述するジョブデータに対応する）に対し、処理サーバ１００にワークフローの実行を要求する。

携帯端末２０２は、携帯電話、スマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistant）、デジタルカメラなど、ユーザが携帯又は所持する端末である。例えば、携帯電話のカメラやデジタルカメラで撮影した画像データに対し、処理サーバ１００にワークフローの実行を要求する。

クライアント端末２０３はノートＰＣ、デスクトップＰＣ、ワークステーション、ＴＶ会議端末などユーザが使用する情報処理装置である。例えば、アプリケーションが作成したアプリケーションデータ、Ｗｅｂから取得したＷｅｂデータに対し、処理サーバ１００にワークフローの実行を要求する。

なお、ワークフロー実行要求装置２００は、ユーザが直接、操作する装置であるとするが、ジョブデータはユーザが直接、操作する装置が作成したり記憶している必要はない。例えば、クライアント端末が、ＮＡＳ（Network Attached Storage）や他の装置に記憶されているジョブデータを指定して、ＮＡＳ等から処理サーバ１００に送信する（処理サーバ１００が読みに行く）ことも可能である。

処理サーバ１００は、ＰＣ、サーバ装置、シンクライアント等の情報処理装置である。また、ＭＦＰを処理サーバ１００として用いることもできる。処理サーバ１００は、ワークフロー実行要求装置２００からワークフローの実行要求を受け付け、ジョブデータに対し入力、変換、出力の各処理を実行する。入力、変換、出力の処理内容はフロー定義情報に定義されている。

管理者ＰＣ１５０は、ＰＣ、サーバ装置、シンクライアント等の情報処理装置である。管理者ＰＣ１５０は、管理者権限で処理サーバ１００にログインし、プラグイン毎に課金ルールを確認したり、設定したり、変更したりすることができる。

図３は、ＭＦＰ２０１としてのワークフロー実行要求装置２００のハードウェア構成図の一例を示す。また、処理サーバ１００をＭＦＰとして実装した場合のハードウェア構成図でもある。

ＭＦＰ２０１は、コントローラ１３０と、オペレーションパネル１２５と、ファクシミリコントロールユニット（ＦＣＵ）１２６と、撮像部１２７及び印刷部１２８を有する。

コントローラ１３０は、ＣＰＵ１１４と、ＡＳＩＣ１１６と、ＮＢ（ノースブリッジ）１１５と、ＳＢ（サウスブリッジ）１１７と、ＭＥＭ−Ｐ（システムメモリ）１１１と、ＭＥＭ−Ｃ（ローカルメモリ）１１２と、ＨＤＤ（ハードディスクドライブ）１１３と、メモリカードスロット１２３と、ＮＩＣ（ネットワークインタフェースコントローラ）１１８と、ＵＳＢデバイス１１９と、ＩＥＥＥ１３９４デバイス１２１と、セントロニクスデバイス１２２とを有する。

ＣＰＵ１１４は、種々の情報処理を実行するためのＩＣであり、ＯＳやプラットホーム上で、アプリケーションをプロセス単位で並列的に実行する。ＡＳＩＣ１１６は、画像処理用のＩＣである。ＮＢ１１５は、ＣＰＵ１１４とＡＳＩＣ１１６を接続するためのブリッジである。ＳＢ１１７は、ＮＢ１１５と周辺機器等を接続するためのブリッジである。ＡＳＩＣ１１６とＮＢ１１５は、例えばＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介して接続されている。

ＭＥＭ−Ｐ１１１は、ＮＢ１１５に接続されたメモリである。ＭＥＭ−Ｃ１１２は、ＡＳＩＣ１１６に接続されたメモリである。ＨＤＤ１１３は、ＡＳＩＣ１１６に接続されたストレージであり、画像データ蓄積・文書データ蓄積・プログラム蓄積・フォントデータ蓄積・フォームデータ蓄積等を行うために使用される。ＨＤＤ１１３には種々のアプリケーション（コピーアプリ、スキャナアプリ、プリンタアプリ、ファックスアプリ等）及びプログラム１３１が記憶されている。プログラム１３１はユーザによるワークフローの設定を受け付け、フロー定義情報等を作成するためのものである。

メモリカードスロット１２３は、ＳＢ１１７に接続され、メモリカード１２４をセット（挿入）するために使用される。メモリカード１２４は、ＵＳＢメモリ、ＳＤメモリ等のフラッシュメモリであり、プログラム１３１を配布するために使用される。また、プログラム１３１は所定のサーバからＭＦＰ２０１にダウンロードすることで配布することもできる。

ＮＩＣ１１８は、ネットワーク４００等を介してＭＡＣアドレス等を使用したデータ通信を行うためのコントローラである。ＵＳＢデバイス１１９は、ＵＳＢ規格に準拠したシリアルポートを提供するためのデバイスである。ＩＥＥＥ１３９４デバイス１２１は、ＩＥＥＥ１３９４規格に準拠したシリアルポートを提供するためのデバイスである。セントロニクスデバイス１２２は、セントロニクス仕様に準拠したパラレルポートを提供するためのデバイスである。ＮＩＣ１１８と、ＵＳＢデバイス１１９と、ＩＥＥＥ１３９４デバイス１２１と、セントロニクスデバイス１２２と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＮＢ１１５とＳＢ１１７に接続されている。

オペレーションパネル１２５は、ユーザがＭＦＰ２０１に入力を行うためのハードウェア（操作部）であると共に、ＭＦＰ２０１がメニュー画面を表示するハードウェア（表示部）である。オペレーションパネル１２５は、ＡＳＩＣ１１６に接続されている。ＦＣＵ１２６と、撮像部１２７と、印刷部１２８は、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＡＳＩＣ１１６に接続されている。

撮像部１２７は、コンタクトガラスに載置された原稿を光学的に走査して、その反射光をＡ／Ｄ変換して画像処理を施し、カラー又はモノクロのデジタルデータ（以下、画像データという）を生成する。

印刷部１２８は、例えばタンデム型の感光ドラムを有し、上記の画像データやユーザＰＣから受信したＰＤＬデータに基づきレーザビームを変調し（又はＬＥＤを発光させ）感光ドラムを走査して潜像を形成する。潜像にトナーを付着して現像した１ページ毎の画像を用紙に熱と圧力で転写する。このような電子写真方式のプロッタに限られず、液滴を吐出して画像を形成するインクジェット型のプロッタエンジンでもよい。

ＦＣＵ１２６は、ＮＩＣ１１８を介してネットワーク４００に接続し例えばＴ.３７，Ｔ.３８の規格に対応した通信手順、又は、公衆通信網に接続し例えばＧ３、Ｇ４規格に対応した通信手順、に従い画像データの送受信を行う。また、ＭＦＰ２０１の電源がＯＦＦのときに画像データを受信しても、印刷部１２８を起動して画像データを用紙に印刷することができる。

図４は、ＰＣやサーバとして構成された処理サーバ１００のハードウェア構成図の一例を示す。管理者ＰＣ１５０又は携帯端末などの構成も同様としてよい。処理サーバ１００は、バスに接続された、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＨＤＤ３０４、ディスプレイ３２０が接続されたグラフィックボード３０５、キーボード・マウス３０６、メディアドライブ３０７、及び、ネットワーク通信部３０８を有する。ＣＰＵ３０１はＨＤＤ３０４に記憶されたプログラム３１０をＲＡＭ３０３に展開して実行し、各部品を制御して入出力を行ったり、データの加工を行ったりする。ＲＯＭ３０２にはＢＩＯＳや、ブートストラップローダをＨＤＤ３０４からＲＡＭ３０３に読み出すスタートプログラムが記憶されている。ブートストラップローダは、ＯＳをＨＤＤ３０４からＲＡＭ３０３に読み出す。

ＨＤＤ３０４は、不揮発性のメモリであればよくＳＳＤ（Solid State Drive）などでもよい。ＨＤＤ３０４は、ＯＳ、デバイスドライバ、プラグイン、及び、後述する機能を提供するプログラム３１０を記憶している。ディスプレイ３２０にはプログラムが指示し、グラフィックボード３０５が作成したＧＵＩ画面が表示される。

キーボード・マウス３０６はユーザの操作を受け付ける入力装置である。メディアドライブ３０７はコンパクトディスク、ＤＶＤ及びブルーレイディスクなどの光学メディアにデータを読み書きする。また、フラッシュメモリなどのメモリカードにデータを読み書きしてもよい。ネットワーク通信部３０８は、例えばＬＡＮに接続するためのイーサネット（登録商標）カードである。ＴＣＰ／ＩＰ（ＵＤＰ／ＩＰ）やアプリケーション層のプロトコルの処理はＯＳやプログラム３１０が行う。アプリケーション層のプロトコルは各種あるが、例えばＳＮＭＰ（Simple Network Management Protocol）、ＨＴＴＰ、ＦＴＰ、ＳＭＢ（Server Message Block）等がある。

プログラム３１０は、インストール可能な形式又は実行可能な形式のファイルで、コンピュータで読み取り可能な記録メディアに記録して配布される。また、プログラム３１０は、不図示のサーバからインストール可能な形式又は実行可能な形式のファイルで配布される。

〔フロー定義情報〕
図５はフロー定義情報を模式的に説明する図の一例である。フロー定義情報は、入力、変換、出力の内容が登録されており、その組み合わせで種々のバリエーションが存在する。管理者はユーザの業務内容に従ってプラグイン２１を組み合わせてワークフローを定義しておく。ユーザは業務に応じたワークフローを選択する。

図５の各ワークフローは処理サーバ１００からアクセス可能なフロー定義ＤＢ４４（図６参照）に記憶されている。ワークフローの各処理で必要な設定条件（例えば、変換が圧縮の場合の圧縮率、出力がドキュメントボックスの場合のフォルダ、出力が印刷の場合の用紙サイズなど）の初期値は予め設定されている。

なお、図５では変換及び出力にそれぞれ１つの処理しか登録されていないが、管理者は変換及び出力に複数の処理を登録することも可能である。例えば変換では、ＯＣＲの後、ＰＤＦに変換するワークフローを定義できる。また、出力では、ＤＢ（ドキュメントボックス）に格納した後、印刷するワークフローを定義できる。

〔機能ブロック例〕
図６はワークフロー実行要求装置２００、及び、処理サーバ１００の機能ブロック図の一例である。

ワークフロー実行要求装置２００は、フローデータ送信部１１、フロー定義受付部１２、フロー定義画面受信部１３、及び、ログイン受付部１４を有する。ログイン受付部１４はユーザのログインを受け付ける。ログイン時に、ユーザは、ワークフロー実行要求装置２００がユーザをログインするためのユーザ名とパスワードを入力する。または、ログイン受付部１４が、ユーザ名とパスワードを処理サーバ１００に送信して、処理サーバ１００にログインしてもよい。

フロー定義画面受信部１３は、処理サーバ１００にアクセスしてワークフローを設定するための画面データを受信する。なお、処理サーバ１００のＩＰアドレス又はＵＲＬなどはワークフロー実行要求装置２００に予め設定されている。画面データは例えばＸＭＬで記述されている。フロー定義画面受信部１３はＸＭＬとＸＳＬＴスタイルシートを受信してＨＴＭＬに変換してオペレーションパネル１２５等に表示する。

本実施形態では、予めいつくかのワークフローが定義されているため、ユーザはオペレーションパネルに表示されたワークフローから使用するワークフローを選択する。なお、ユーザは任意のプラグインを組み合わせてワークフローを実行することも可能である。フロー定義受付部１２は、ユーザによるワークフローの選択を受け付ける。フロー定義受付部１２はユーザが選択したワークフローの入力、変換、出力のそれぞれで、必要な設定条件を要求する。例えば、入力では処理対象となるジョブデータ（文書データ、画像データ、映像データなど）の設定を要求し、変換では例えば圧縮率を要求し、出力（印刷）では用紙サイズ、拡大／縮小、集約、カラー／モノクロ、印刷部数、仕上げなどの設定を受け付ける。フロー定義受付部１２は、各処理の設定条件を含むフロー定義情報を作成する。

フローデータ送信部１１はフロー定義情報、入力で指定されたジョブデータ、算出パラメータ、及び、ユーザ情報を処理サーバ１００に送信する。本実施例ではユーザ情報が主に課金に使用されるので、以下、ユーザ情報を算出パラメータに含めて説明する。算出パラメータについては図7にて説明するが、算出パラメータには、ユーザ情報以外に、図７にて説明するようにジョブデータのうちデータ容量やページ数などが含まれる。

なお、これらのデータは同時に処理サーバ１００に送信される必要はない。例えば、ジョブデータがワークフローの入力処理で生成される場合は、ジョブデータは入力処理で送信される。

処理サーバ１００は、１つ以上のプラグイン２１、フロー制御部２２、ジョブ制御部２３、及び、配信機能部２４を有している。配信機能部２４は、処理サーバ１００がワークフローを準備・支援するための機能であり、ログ記録部４１、及び、画面データ送信部４３を有している。画面データ送信部４３は、ワークフロー実行要求装置２００からの要求に応じて、フロー定義ＤＢ４４から読み出したワークフローを、画面データＤＢ４５から読み出した画面データに設定して、ワークフロー実行要求装置２００に送信する。

ログ記録部４１は、ワークフローのログを記録する。ログ記録部４１はワークフロー単位で、ユーザ名、各処理の料金、ワークフロー全体の合計料金、実行した処理の開始時刻、終了時刻及び処理が完了したが失敗したか等を記録する。

ジョブ制御部２３は、ワークフローの各処理の実行を制御する。まず、ジョブ受信部３３は、ワークフロー実行要求装置２００からフロー定義情報、ジョブデータ及び算出パラメータを受信しジョブキュー３５に蓄積する。

ジョブ実行部３１は、フロー定義情報、ジョブデータ及び算出パラメータをジョブキュー３５から読み出してフロー制御部２２に送出する。フロー制御部２２は、課金処理部３６、パラメータ更新部３７、入力プラグインマネージャ３８、変換プラグインマネージャ３９、及び、出力プラグインマネージャ４０を有する。入力プラグインマネージャは入力の処理を行うプラグイン２１にどのようなものインストールされているか、ライセンス期限などを管理している。また、各プラグインに対し統一した手順で処理の依頼（ジョブの投入）、実行結果の取得などを行う。変換プラグインマネージャ等についても同様である。

フロー制御部２２はフロー定義情報に沿ってプラグイン２１を選択して処理を実行する。プラグイン２１は、入力、変換、出力に区分されているが、必ずしも区分されていなくてもよく、また、これら以外の区分を有していてもよい。入力は、例えば、ＭＦＰ２０１から受け取る処理、携帯端末２０２からジョブデータを受け取る処理など、入力装置に応じて用意されている。変換には、例えば、ジョブデータをＰＤＦに変換する処理、ＯＣＲ処理を行う処理、圧縮する処理、翻訳する処理などがある。出力には、例えば、ジョブデータをドキュメントボックスに蓄積する処理、印刷する出力、電子メールで送信する処理、などがある。

プラグイン２１は共通のプラットホーム上で動作可能になっており、処理サーバ１００は１つのプラグイン２１を独立に追加したり、削除することができる。プラグイン同士は互いの処理には関与しない。なお、このようなプラグイン２１に限られずアプリケーションプログラムにより処理してもよい。

フロー制御部２２は、フロー定義情報を解析して次に実行すべき処理を確認して、その処理を行うプラグイン２１を呼び出すと共に処理を実行させる。処理が正常に完了すればフロー制御部２２は、次の処理を実行する。全ての処理が終わるまで繰り返し、処理が終わるとジョブ実行部３１に通知する。

課金処理部３６は、各プラグイン２１が有する課金ルールに従って、プラグイン毎に、処理に対する料金を算出する。パラメータ更新部３７は算出パラメータを更新する。これらについて詳しくは後述する。なお、課金処理部３６が各プラグインの料金を算出するのでなく、プラグイン２１の課金制御部５３が自己の料金を算出して、課金処理部３６はワークフロー全体の料金の合計を算出してもよい。

図７（ａ）は、プラグイン２１の機能ブロック図の一例である。各プラグインはＵＩ処理部５１、データ処理部５２、及び、課金制御部５３を有している。ＵＩ処理部５１はプラグイン２１に必要なユーザインタフェースを提供する。例えば、プラグイン２１の処理に使用されるジョブデータの入力欄などを表示するユーザインタフェースをオペレーションパネル等に表示させる。データ処理部５２は、プラグイン２１に固有の処理を行う。例えば、ＰＤＦ変換やＯＣＲ処理を行う。

課金制御部５３は、管理者ＰＣ１５０からプラグイン２１に対し課金ルール５４の設定が行われた場合に、それを受け付け課金ルール５４として記憶する。また、課金処理部３６がプラグイン２１の処理に対し課金する場合（料金を算出する場合）は、課金ルール５４を課金処理部３６に出力する。プラグイン２１が課金ルール５４を有していることでプラグインと課金ルールを一体に管理できる。また、プラグイン２１と課金ルール５４は紐づけされていれば、プラグイン２１が課金ルールを有していなくてもよい。

〔課金ルール〕
課金ルール５４について説明する。課金ルールはプラグイン毎にどのように料金を算出するかのプラグイン２１に特有の規則を定めている。

課金ルール１
例えば、携帯電話を入力とするワークフローについて、ユーザが所属する部署に応じて課金する課金ルールが考えられる。
・営業部のユーザがワークフローで入力のプラグイン２１を使用する場合、無料
・それ以外の部署のユーザが利用する場合は課金を行う
・１入力につき１０円
課金ルール２
変換においてページ数に応じて課金する課金ルールが考えられる。
・ＰＤＦ変換するページ枚数が５枚以下では０円。
・ＰＤＦ変換するページ枚数が５枚より多い場合は、（ページ数−５)を課金対象のページ枚数とする。
・単価は、１ページあたり１０円。

課金ルール３
ストレージ（主に不揮発の記憶装置でありネットワーク上に存在すればよい）を使用する出力の場合、ユーザの総データ使用量に応じて課金する課金ルールが考えられる。
・ドキュメントボックスに記憶する出力のプラグイン２１について、ユーザの総データ使用量が５０ＭＢより少ない場合は０円。
・総データ使用量が５０ＭＢ以上の場合は、送信データサイズ（1M毎）×10円
課金ルール４
印刷する出力の場合、印刷したページ枚数に応じて課金する課金ルールが考えられる。
・対象ページ数が5ページより大きい場合、(ページ数−５)を課金対象とする。
・対象ページ数が5ページ以下の場合、課金しない。
・単価は１０円とする
以上のような課金ルールが各プラグイン２１の課金制御部５３にプログラムコードとして記述されている。例えば課金ルール２，４では次のようになる。
「Cost= if ({page_number} > 5) ({page_number}-5) ×10
Cost= if ({page_number} ＜＝ 5) ０」
〔算出パラメータと更新〕
図７（ｂ）は課金ルール５４に使用され得る算出パラメータの一例を示す図である。各処理で全ての算出パラメータを使用する必要はない。入力の算出パラメータは、例えばユーザ情報、ジョブデータのデータ量やページ数などである。上記の課金ルールでは例がないが、入力においてもジョブデータのデータ量を算出パラメータとすることができる。

少なくとも入力の算出パラメータはワークフロー実行要求装置２００から処理サーバ１００に送信される。しかし、ワークフロー実行要求装置２００から送信されるユーザ情報は、ユーザ名とパスワードなど限られているので、パラメータ更新部３７は課金ルール５４に適した内容にユーザ情報を更新する。すなわち、パラメータ更新部３７は不図示のデータベースからユーザ名に紐付いた所属、勤務地、及び、階級等を読み出し算出パラメータに追加する。これにより算出パラメータが更新される。

変換の算出パラメータは、例えば、ユーザ情報、ジョブデータのデータ量やページ数、及び、変換の設定パラメータなどである。上記の課金ルールに示したように、ユーザ情報とジョブデータのデータ量やページ数は入力と同様に課金に使用できる。上記の課金ルールには例がないが、変換の設定パラメータは、例えば圧縮率に応じて（圧縮率が高いと時間がかかるため）課金したい場合や、文字と画像の圧縮率を変えるような高度な変換に課金するためのものである。

また、変換によりデータ量やページ数が変更される場合がある。例えば、変換前にはページ数がない１枚のワークシートや画像データだったものが、ＰＤＦ変換することで複数のページになったり、ＯＣＲ処理によりテキストのデータが生じるのでページ数が増える場合がある。この場合、パラメータ更新部３７は課金ルール５４が必要とするページ数等を更新する。また、例えば圧縮の変換によりデータ量が低減された場合、データ量を更新する。

出力の算出パラメータは、例えば、ユーザ情報、ジョブデータのデータ量やページ数、出力先の装置情報などである。ユーザ情報とジョブデータのデータ量やページ数は入力と同様に課金に使用できる。また、出力先の装置情報は、ストレージが出力先の場合、例えば、共有領域とプライベート領域の違いで課金したり、暗号化領域と平文領域の違いで課金したり、バックアップの有無で課金するためのものである。また、課金ルール３のように、個人が使用する領域に応じて課金する場合は、出力先の装置から各ユーザの使用量が必要になる。この場合、パラメータ更新部３７はユーザ情報に基づき出力先の装置からユーザの使用量を取得して、算出パラメータに追加する。

また、出力によりページ数が変更される場合がある。例えば、集約印刷した場合、変換時のページ数よりも出力したページ数が少なくなる。この場合、パラメータ更新部３７は課金ルール５４が必要とするページ数等を更新する。

〔料金の算出例〕
課金ルール５４に基づくワークフローの料金の算出例について説明する。
・パターンＡ ： 営業部のユーザが外出先から見積もり書（6ページ）をＰＤＦに変換して携帯電話でドキュメントボックスへ登録する場合
（このユーザの総データ使用量：５５MB、送信データサイズ：１MB）
パターンＡの場合、合計料金＝入力[０円] + 変換[１０円] + 出力[１０円]
・パターンＢ ： 一般社員が外出先からメモ（５ページ）をＰＤＦに変換して携帯電話でドキュメントボックスへ登録する場合
（このユーザの総データ使用量：１０MB、送信データサイズ：５MB）
パターンＢの場合、合計料金＝入力[１０円] + 変換[０円] + 出力[０円]
・パターンＣ ： 庶務のユーザが社内のＭＦＰ２０１からスキャンデータ（１ページ）をＰＤＦに変換してドキュメントボックスへ登録する場合
（このユーザの総データ使用量：７０MB、送信データサイズ：１MB）
パターンＣの場合、合計料金＝入力[0円] + 変換[0円] + 出力[10円]
パターンＡについては、入力では課金ルール１により営業のユーザの入力は０円、変換では課金ルール２によりページ枚数が６ページの場合、「６−５＝１」が課金対象のページ枚数なので１０円、出力では課金ルール３により総データ使用量が５５ＭＢなので１０円、となる。

パターンＢについては、入力では課金ルール１により一般社員の入力は一律に１０円、変換では課金ルール２によりページ枚数が５ページの場合、０円、出力では課金ルール３により総データ使用量が「１０＋５」ＭＢなので０円、となる。

パターンＣについては、入力では課金ルール１により庶務のユーザの入力は一律に１０円、変換では課金ルール２によりページ枚数が１ページの場合、０円、出力では課金ルール３により総データ使用量が７０ＭＢなので１０円、となる。

このようにパターンＡ〜Ｃはいずれもジョブデータを変換してドキュメントボックスに登録するワークフローだが、各プラグインの課金ルール５４に従って課金処理部３６がプラグイン毎に料金を算出する。このため、同様のワークフローでも一律の料金とするのでなく、各プラグインの課金ルール５４に基づき従量制の料金設定とすることができる。

なお、金額そのものでなく課金ルールに基づきポイントを算出し、後に金額に換算したりポイント数に応じてサービスに交換してもよい。

〔動作手順〕
図８は、処理実行システム５００の全体的な動作手順の一例を示す図である。
S1：ユーザはワークフロー実行要求装置２００にログインする。ユーザは手動操作やＩＣカード等でユーザ名とパスワードを入力する。
S2：ユーザの操作により、ワークフロー実行要求装置２００はワークフローの画面データを処理サーバ１００に要求する。この時、ユーザ情報を送信してもよい。
S3：処理サーバ１００の画面データ送信部４３はフロー定義ＤＢ４４から１つ以上のフロー定義情報を読み出して、画面データに設定してワークフロー実行要求装置２００に送信する。
S4：ユーザは画面からワークフローを選択する。フロー定義受付部１２はワークフローの各処理に必要な設定条件を受け付けフロー定義情報を作成する。
S5：ユーザが最終的なワークフローの実行開始操作を行うと、フローデータ送信部１１はワークフロー実行要求を処理サーバ１００に送信する。これにより、フロー定義情報及び算出パラメータ（ユーザ情報）が送信される。
S6：処理サーバ１００のジョブ受信部３３はジョブキュー３５にフロー定義情報、及び、算出パラメータ（ユーザ情報）を記憶する。ジョブ実行部３１はフロー定義情報を解析し、ワークフローの定義が整っていることなどを確認して、フロー定義情報及び算出パラメータ（ユーザ情報）をフロー制御部２２に出力する。フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理とその処理のプラグイン２１を決定する。例えば、入力にも複数のフラグインがあるため、フロー定義情報の入力に指示されている装置に対応したプラグイン２１を決定する。
S7：入力のプラグイン２１のデータ処理部５２はジョブデータをワークフロー実行要求装置２００に要求する。
S8：ワークフロー実行要求装置２００は、ジョブデータを処理サーバ１００に送信する。なお、必要であれば、ユーザが送信許可したり、カメラで撮影して画像データ（ジョブデータ）を作成するなどする。入力のプラグイン２１のデータ処理部５２はジョブデータを取得して、フロー制御部２２に出力する。パラメータ更新部３７は、データ量やページ数などを算出パラメータに追加する。
S9：フロー制御部２２は算出前に算出パラメータを更新し（ここでは、ユーザ情報に所属等を付加する）、課金処理部３６は入力のプラグイン２１の課金ルール５４に基づき、入力の料金を算出する。
S10：次に、フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理とその処理のプラグイン２１を決定する。フロー定義情報の変換に指示されている処理に対応したプラグイン２１を決定する。
S11：変換のプラグイン２１のデータ処理部５２はジョブデータに変換処理を施し、ジョブデータをフロー制御部２２に出力する。
S12：パラメータ更新部３７は必要であれば算出パラメータを更新し（例えば、変換パラメータを付加する。データ量やページ数は変換前の値で算出するのでここでは更新しない。）、課金処理部３６は変換のプラグイン２１の課金ルール５４に基づき、変換の料金を算出する。
S13：次に、フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理とその処理のプラグイン２１を決定する。フロー定義情報の出力に指示されている処理に対応したプラグイン２１を決定する。
S14：出力のプラグイン２１のデータ処理部５２はジョブデータを出力する。例えば、ドキュメントボックスに登録したり印刷するなどの処理を行う。処理結果をフロー制御部２２に出力する。
S15：パラメータ更新部３７は、算出前に算出パラメータを更新し（変換結果に基づきページ数等を更新する。ユーザのストレージの現在の使用量は、データ処理部５２が管理しているのでデータ処理部５２から取得する。）、課金処理部３６は出力のプラグイン２１の課金ルール５４に基づき、出力の料金を算出する。
S16：次に、フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理がないことを検出する。
S17：フロー制御部２２の課金処理部３６は各プラグイン２１の料金の合計を算出する。課金処理部３６は各プラグインの料金と合計の料金をログ記録部４１に出力するなどして、ログと共に保持する。これにより、所定のサーバなどが例えば月単位で課金情報を作成し、ユーザや部署に課金情報を送信し、料金を収納できる。

以上説明したように、本実施例の処理実行システム５００は、プラグイン毎に課金ルール５４が設定されており、料金の算出をプラグイン毎に行うので、ワークフローの料金を使用量に応じて柔軟に算出することができる。

本実施例では２台以上の処理サーバ１００が連携してワークフローを実行する処理実行システム５００について説明する。

図９は、処理実行システム５００のシステム構成図の一例を示す。なお、本実施例において、実施例１において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。本実施例の処理実行システム５００は２つの処理サーバ１、２を有する。処理サーバ１、２は例えば保有しているプラグイン２１の種類が異なっている。したがって、処理サーバ１が自機では実行できない処理を含むワークフローの実行要求を取得した場合、処理サーバ１は処理単位で処理サーバ２に処理を要求できる。

図１０は、ワークフロー実行要求装置２００、及び、処理サーバ１００の機能ブロック図の一例を示す図である。本実施例では、ジョブ制御部２３がジョブ転送部３４を有している。ジョブ転送部３４は、フロー定義情報、ジョブデータ及び算出パラメータ（ユーザ情報）を処理サーバ２に転送する。フロー制御部２２が保有しているプラグイン２１で実行できない処理を検出した場合、ジョブ実行部３１が機器決定テーブル２９で転送先の処理サーバ２を決定する。例えば処理サーバ１が翻訳のプラグイン２１を有していない場合、翻訳のプラグイン２１を有する処理サーバ２を決定する。機器決定テーブル２９には処理と、その処理を有する処理サーバ１，２の識別情報又はＩＰアドレスなどが登録されている。なお、処理サーバ１が処理を保有していない場合だけでなく、処理負荷が大きい場合に他の処理サーバ２に一部の処理又はワークフロー全体を転送してもよい。

処理サーバ２は翻訳を実行すると共に料金を算出し、フロー定義情報、課金情報、ジョブデータ及び算出パラメータ（ユーザ情報）を処理サーバ１に送信する。課金情報のみ返送してもよい。したがって、処理サーバ１が保有しない処理を他の処理サーバ２で実行できると共に、プラグイン単位で課金することができる。

なお、処理サーバ２のジョブ制御部２３とフロー制御部２２の機能は処理サーバ１と同様である。これにより、処理サーバ２もワークフローを他の処理サーバ１００に転送することが可能になる。また、処理サーバ２は配信機能部２４を有していないが、有していてもよい。または、処理サーバ１から処理サーバ２、処理サーバ３から処理サーバ4のように、次々にワークフローを転送するのでなく、処理サーバ１を中心に処理単位で（１つのプラグイン単位で）、プラグイン２１を有する装置に処理を要求することを繰り返してワークフローの全体を実行してもよい。

〔動作手順〕
図１１は、処理実行システム５００の全体的な動作手順の一例を示す図である。図１１においてS1〜S9の処理は図８と同様になる。
S10：次に、フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理とその処理のプラグイン２１を決定する。フロー定義情報の変換に指示されている処理を有していない場合、フロー制御部２２はジョブ実行部３１にフロー定義情報を出力しジョブ実行部３１が機器決定テーブル２９を参照して、変換の処理が可能な処理サーバ２を決定する。
S11：処理サーバ１のジョブ転送部３４はワークフロー実行要求と共にフロー定義情報、ジョブデータ及び算出パラメータ（ユーザ情報）を処理サーバ２に送信する。
S12：処理サーバ２のジョブ実行部３１は処理サーバ１と同様の手順でワークフローを実行する。すなわち、フロー制御部２２はフロー定義情報を解析し、次に実行すべき処理とその処理のプラグイン２１を決定する。フロー定義情報の変換に指示されている処理に対応したプラグイン２１を決定する。
S13：変換のプラグイン２１のデータ処理部５２はジョブデータに変換処理を施し、ジョブデータをフロー制御部２２に出力する。
S14：パラメータ更新部３７は必要であれば算出パラメータを更新し（例えば、変換パラメータを付加する。データ量やページ数は変換前の値で算出するのでここでは更新しない。）、課金処理部３６は変換のプラグイン２１の課金ルール５４に基づき、変換の料金を算出する。
S15：次に、フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理とその処理のプラグイン２１を決定する。フロー定義情報の変換に指示されている処理を有していない場合、フロー制御部２２はジョブ実行部３１にフロー定義情報を出力しジョブ実行部３１が機器決定テーブル２９を参照して、変換の処理が可能な処理サーバ１を決定する。
S16：処理サーバ２のジョブ転送部３４はワークフロー実行要求と共にフロー定義情報、ジョブデータ、課金情報、及び、算出パラメータ（ユーザ情報）を処理サーバ１に送信する。
S17：処理サーバ１のフロー制御部２２はフロー定義情報を解析して、次に実行すべき処理とその処理のプラグイン２１を決定する。フロー定義情報の出力に指示されている処理に対応したプラグイン２１を決定する。
S18：出力のプラグイン２１のデータ処理部５２はジョブデータを出力する。例えば、ドキュメントボックスに登録したり印刷するなどの処理を行う。処理結果をフロー制御部２２に出力する。
S19：パラメータ更新部３７は、算出前に算出パラメータを更新し（変換結果に基づきページ数等を更新する。ユーザのストレージの現在の使用量は、データ処理部５２が管理しているのでデータ処理部５２から取得する。）、課金処理部３６は出力のプラグイン２１の課金ルール５４に基づき、出力の料金を算出する。
S20：次に、フロー制御部２２はフロー定義情報を解析して、次に実行すべき処理がないことを検出する。
S21：フロー制御部２２の課金処理部３６は各プラグインの料金の合計を算出する。課金料金処理部は各プラグインの料金と合計の料金をログ記録部４１に出力するなどして、ログと共に保持する。これにより、所定のサーバなどが例えば月単位で課金情報を作成し、ユーザや部署に課金情報を送信し、料金を収納できる。

本実施例の処理実行システム５００は、実施例１の効果に加え、複数の処理サーバで１つのワークフローを実行することができるので、多種多様なサービスを提供できる。

２１ プラグイン
２２ フロー制御部
２３ ジョブ制御部
２４ 配信機能部
３１ ジョブ実行部
３３ ジョブ受信部
３４ ジョブ転送部
３５ ジョブキュー
１００ 処理サーバ
１５０ 管理者ＰＣ
２００ ワークフロー実行要求装置
５００ 処理実行システム

特開２０１１‐０３５７７９号公報

Claims (10)

1. 順番に実行される一連の処理の設定を受け付ける機器とネットワークを介して通信可能な情報処理装置であって、
   各処理の処理内容と処理の順番が定義された処理定義情報、処理対象データ、及び、前記一連の処理の料金を算出するための算出パラメータを受信する受信手段と、
   当該処理に特有の課金規則を保持し、固有の処理を実行する複数の処理実行手段と、
   前記処理定義情報を解析して次に実行する処理を決定する処理決定手段と、
   前記処理実行手段が処理した処理結果に基づき前記算出パラメータを更新すると共に、前記課金規則に必要な情報を前記算出パラメータに基づいて取得して前記算出パラメータを更新するパラメータ更新手段と、
   処理ごとに更新された前記算出パラメータを前記課金規則に適用して、前記処理実行手段が実行した処理毎に課金情報を算出する算出手段と、を有することを特徴とする情報処理装置。
2. 処理毎に前記課金規則の設定又は変更を受け付ける課金規則受け付け手段を有し、
   前記課金規則受け付け手段はネットワークを介して接続された機器から取得した前記課金規則を前記処理実行手段に設定するか、又は、前記機器から取得した変更要求に応じて前記処理実行手段がすでに保持している前記課金規則を変更することを特徴とする請求項１記載の情報処理装置。
3. 前記算出パラメータにはユーザ情報が含まれており、
   前記パラメータ更新手段は、前記ユーザ情報に基づき前記課金規則に必要な付随情報を取得して追加することで前記ユーザ情報を更新し、
   前記算出手段は、前記付随情報を前記課金規則に適用して課金情報を算出することを特徴とする請求項１又は２記載の情報処理装置。
4. 前記算出パラメータには前記処理対象データのデータ量が含まれており、
   前記パラメータ更新手段は、前記処理実行手段が処理を施した前記処理対象データに基づき前記データ量を更新し、
   前記算出手段は、更新後の前記データ量を前記課金規則に適用して課金情報を算出することを特徴とする請求項１又は２記載の情報処理装置。
5. 前記付随情報はユーザの所属部署であり、
   前記算出手段は、前記所属部署を前記課金規則に適用することで、前記所属部署に応じて異なる金額の前記課金情報を算出することを特徴とする請求項３記載の情報処理装置。
6. 前記データ量は前記処理対象データのページ数であり、
   前記算出手段は、更新後の前記ページ数が閾値以下の場合には一定の課金情報を算出し、閾値より多い場合には前記ページ数が多いほど大きい課金情報を算出することを特徴とする請求項４記載の情報処理装置。
7. 前記パラメータ更新手段は、記憶装置においてユーザが前記処理対象データの保存のためにすでに使用している使用領域サイズ情報を追加することで前記算出パラメータを更新し、
   前記算出手段は、前記使用領域サイズ情報が閾値以下の場合には一定の課金情報を算出し、閾値より多い場合には前記データ量が多いほど大きい課金情報を算出することを特徴とする請求項４記載の情報処理装置。
8. 前記一連の処理は、前記処理対象データの入力処理、前記処理対象データの変換処理、及び、前記処理対象データの出力処理を含み、
   前記算出手段は、前記入力処理、前記変換処理、及び、前記出力処理ごとに、前記算出パラメータを各処理の前記課金規則に適用して処理毎に課金情報を算出することを特徴とする請求項１〜７いずれか１項記載の情報処理装置。
9. 順番に実行される一連の処理の設定を受け付ける機器とネットワークを介して通信可能な情報処理装置の処理実行方法であって、
   受信手段が、各処理の処理内容と処理の順番が定義された処理定義情報、処理対象データ、及び、前記一連の処理の料金を算出するための算出パラメータを受信するステップと、
   処理決定手段が、前記処理定義情報を解析して次に実行する処理を決定するステップと、
   当該処理に特有の課金規則を保持し固有の処理を実行する複数の処理実行手段が、それぞれ前記処理決定手段により決定された処理を実行するステップと、
   パラメータ更新手段が、前記処理実行手段が処理した処理結果に基づき、前記算出パラメータを更新すると共に、前記課金規則に必要な情報を前記算出パラメータに基づいて取得して前記算出パラメータを更新するステップと、
   算出手段が、処理ごとに更新された前記算出パラメータを前記課金規則に適用して、前記処理実行手段が実行した処理毎に課金情報を算出するステップと、
   を有することを特徴とする処理実行方法。
10. 順番に実行される一連の処理の設定を受け付ける機器とネットワークを介して通信可能な情報処理装置に、
    各処理の処理内容と処理の順番が定義された処理定義情報、処理対象データ、及び、前記一連の処理の料金を算出するための算出パラメータを受信する受信ステップと、
    前記処理定義情報を解析して次に実行する処理を決定する処理決定ステップと、
    前記処理決定ステップにより決定され特有の課金規則を有する処理実行手段が固有の処理を実行する処理実行ステップと、
    前記処理実行ステップにより処理された処理結果に基づき、前記算出パラメータを更新すると共に、前記課金規則に必要な情報を前記算出パラメータに基づいて取得して前記算出パラメータを更新するパラメータ更新ステップと、
    処理ごとに更新された前記算出パラメータを前記処理実行手段に特有の前記課金規則に適用して、前記処理実行ステップにより実行された処理毎に課金情報を算出する算出ステップと、
    を実行させるプログラム。

Images