JP2017058834A - 情報処理システム及び課金方法 - Google Patents

Abstract

【課題】ユーザによる処理の使用量の増加に対応可能な課金体系を実現できる情報処理システムを提供することを課題とする。【解決手段】１台以上の情報処理装置を含む情報処理システムであって、端末装置からの要求に基づき処理を実行する１つ以上のアプリケーションに対し、共通サービスを提供する共通サービス提供手段と、共通サービス提供手段に対する処理の使用量の登録をアプリケーションから受け付ける使用量登録受付手段と、共通サービス提供手段に登録された処理の使用量と、該処理の使用量から料金を算出する方法を表す料金情報とに基づき、処理の使用量に対する料金を算出する課金手段と、を有することにより上記課題を解決する。【選択図】 図４

Description

本発明は情報処理システム及び課金方法に関する。

近年、ユーザが必要な時に必要な機能だけを利用するクラウドコンピューティングやＳａａＳ（Software as a Service）などの新しいサービス提供形態が増加している。このようなサービスを利用するユーザは利用料を支払う（課金を行う）場合があった。

例えばアグリゲーション型のＳａａＳサービスを行うサービス事業者がサービス管理基盤を運用し、アプリケーション提供者が別の場所で運用するアプリケーションを取りまとめてＳａａＳサービスとしてテナント企業に提供することは従来から行われている。このようなＳａａＳサービスではサービス事業者が課金情報を生成して利用料の請求を行っていた（例えば特許文献１参照）。

上記のようなサービスをユーザに提供する従来のサービス提供システムでは、課金処理の容易な定額料金でサービスを提供する場合がある。このような定額料金でサービスを提供するサービス提供システムは、ユーザによるサービス使用量が増えてもユーザに請求できる料金が増えないという問題があった。また、このような定額料金でサービスを提供するサービス提供システムは、ユーザによるサービス使用量が増え過ぎると、システムの増強が必要になるという問題もあった。

本発明の実施の形態は、上記の点に鑑みなされたものであり、ユーザによる処理の使用量の増加に対応可能な課金体系を実現できる情報処理システムを提供することを目的とする。

上記目的を達成するため本願請求項１は、１台以上の情報処理装置を含む情報処理システムであって、端末装置からの要求に基づき処理を実行する１つ以上のアプリケーションに対し、共通サービスを提供する共通サービス提供手段と、前記共通サービス提供手段に対する前記処理の使用量の登録を前記アプリケーションから受け付ける使用量登録受付手段と、前記共通サービス提供手段に登録された前記処理の使用量と、該処理の使用量から料金を算出する方法を表す料金情報とに基づき、前記処理の使用量に対する料金を算出する課金手段と、を有することを特徴とする。

本発明の実施の形態によれば、ユーザによる処理の使用量の増加に対応可能な課金体系を実現できる。

第１の実施形態に係る情報処理システムの一例の構成図である。 コンピュータの一例のハードウェア構成図である。 第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。 サービス提供システムのコンポーネント間の関係を示す一例の説明図である。 ライセンス情報の一例の構成図である。 ライセンス情報の具体例を示す図である。 サービス実行処理の一例のシーケンス図である。 実行可否を判断する処理の一例のフローチャートである。 使用を予約する処理の一例のフローチャートである。 使用履歴のレコードの一例の構成図である。 使用を確定する処理の一例のフローチャートである。 使用を開始する処理の一例のフローチャートである。 使用を終了する処理の一例のフローチャートである。 課金・請求処理の一例のシーケンス図である。 料金情報の一例の説明図である。 計算結果のテーブルの一例の構成図である。 ワーカーの処理に対する課金について説明するための図である。 ワーカー処理に対する課金の一例のシーケンス図である。 第１の実施形態に係る情報処理システムの一例の構成図である。 情報処理システムの連携処理について説明する図である。 契約情報の一例の構成図である。 第２の実施形態に係る情報処理システムの一例の構成図である。 第２の実施形態に係る情報処理システムの一例の処理ブロック図である。 ロジック処理部の一例の処理ブロック図である。 コンポーネント群のコンポーネントの処理に対する課金の一例のシーケンス図である。 コンポーネントの処理に対する課金の一例のイメージ図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は第１の実施形態に係る情報処理システムの一例の構成図である。図１の情報処理システム１０００は、例えばオフィス内ネットワーク等のネットワークＮ１と、サービス提供システム１０２１とが、インターネットなどのネットワークＮ２を介して接続されている。

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

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

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

なお、携帯端末１０１２はオフィス内ネットワーク等のネットワークＮ１以外に接続されてもよい。図１では携帯端末１０１２がネットワークＮ１とネットワークＮ２とに接続されている例を示している。

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

また、サービス提供システム１０２１は、例えばポータルサービス、プリントサービスやスキャンサービス等を後述のように提供する。サービス提供システム１０２１は一台以上の情報処理装置によって実現される。例えばサービス提供システム１０２１はＳａａＳ系のサービス提供装置、共通サービス（Network Service Platform）系のサービス提供装置、ストレージ（Storage）系の記憶装置、業務系の管理装置を情報処理装置により実現する。共通サービス系のサービス提供装置はＳａａＳ系のサービス提供装置が共通で使えるサービスを提供する。

＜ハードウェア構成＞
図１のクライアント端末１０１１、携帯端末１０１２は例えば図２に示すようなハードウェア構成のコンピュータにより実現される。また、サービス提供システム１０２１を実現する情報処理装置も例えば図２に示すようなハードウェア構成のコンピュータにより実現される。

図２はコンピュータの一例のハードウェア構成図である。図２のコンピュータ１５００は入力装置１５０１、表示装置１５０２、外部Ｉ／Ｆ１５０３、ＲＡＭ１５０４、ＲＯＭ１５０５、ＣＰＵ１５０６、通信Ｉ／Ｆ１５０７、及びＨＤＤ１５０８などを備え、それぞれがバスＢで相互に接続されている。なお、入力装置１５０１及び表示装置１５０２は必要なときに接続して利用する形態であってもよい。

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

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

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

なお、コンピュータ１５００はＨＤＤ１５０８に替え、記憶媒体としてフラッシュメモリを用いるドライブ装置（例えばソリッドステートドライブ：ＳＳＤ）を利用するものであってもよい。

外部Ｉ／Ｆ１５０３は、外部装置とのインタフェースである。外部装置には、記録媒体１５０３ａなどがある。これにより、コンピュータ１５００は外部Ｉ／Ｆ１５０３を介して記録媒体１５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１５０３ａにはフレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリなどがある。

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

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

クライアント端末１０１１、携帯端末１０１２、サービス提供システム１０２１を実現する情報処理装置は、例えば上記ハードウェア構成のコンピュータ１５００上でプログラムを実行することにより、後述するような各種処理を実現できる。なお、図１に示した画像形成装置１０１３、ファイヤウォールＦＷのハードウェア構成については、説明を省略する。

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

図３のサービス提供システム１０２１はアプリケーション１１０１、固有サービス１１０２、共通サービス１１０３、データベース１１０４、業務サービス１１０５、プラットフォームＡＰＩ１１０６及び１１０７を実現している。

アプリケーション１１０１は、ポータルサービスアプリ１１１１、スキャンサービスアプリのＵＩ部１１１２ａ、プリントサービスアプリのＵＩ部１１１３ａを一例として有している。

ポータルサービスアプリ１１１１は、ポータルサービスを提供するアプリケーションである。ポータルサービスは、サービス提供システム１０２１を利用するための入り口となるサービスを提供する。

スキャンサービスアプリのＵＩ部１１１２ａは携帯端末１０１２や画像形成装置１０１３などのＷｅｂブラウザからのアクセスを受け付ける。プリントサービスアプリのＵＩ部１１１３ａは携帯端末１０１２や画像形成装置１０１３などのＷｅｂブラウザからのアクセスを受け付ける。

固有サービス１１０２であるスキャンサービスアプリのロジック部１１１２ｂとプリントサービスアプリのロジック部１１１３ｂと後述のＩ／Ｏサービス部１１１４とは、携帯端末１０１２や画像形成装置１０１３などのＷｅｂブラウザ以外のクライアントからのアクセスを受ける。プラットフォームＡＰＩ１１０６及び１１０７は、アプリケーション１１０１や固有サービス１１０２が共通サービス１１０３を利用するためのインタフェースである。プラットフォームＡＰＩ１１０６及び１１０７はアプリケーション１１０１や固有サービス１１０２からの要求を共通サービス１１０３が受信するために設けられた予め定義されたインタフェースであり、例えば関数やクラス等により構成される。

プラットフォームＡＰＩ１１０６及び１１０７は、サービス提供システム１０２１が複数の情報処理装置で構成される場合、ネットワーク経由で利用可能な例えばＷｅｂ ＡＰＩにより実現できる。

共通サービス１１０３は、認証・認可部１１２１、テナント管理部１１２２、ユーザ管理部１１２３、ライセンス管理（Ｗｒａｐｐｅｒ）部１１２４、機器管理部１１２５、一時画像保存部１１２６、データ保管部１１２７、ログ収集部１１２８、課金（Ｗｒａｐｐｅｒ）部１１２９、画像処理ワークフロー制御部１１３０を有する。

また、画像処理ワークフロー制御部１１３０はメッセージキュー１１３１、１つ以上のワーカー（Ｗｏｒｋｅｒ）１１３２を有する。ワーカー１１３２は画像変換や画像送信などの機能を実現する。

認証・認可部１１２１は、クライアント端末１０１１や画像形成装置１０１３などのオフィス機器からのログイン要求に基づいて認証・認可を実行する。オフィス機器はクライアント端末１０１１、携帯端末１０１２、画像形成装置１０１３などの総称である。

認証・認可部１１２１は、例えば後述するユーザ情報記憶部１１４３、ライセンス情報記憶部１１４４などにアクセスしてユーザを認証・認可する。また、認証・認可部１１２１は例えば後述するテナント情報記憶部１１４２、ライセンス情報記憶部１１４４、機器情報記憶部１１４５などにアクセスして画像形成装置１０１３などを認証する。

テナント管理部１１２２は後述するテナント情報記憶部１１４２に記憶されているテナント情報を管理する。ユーザ管理部１１２３は、後述するユーザ情報記憶部１１４３に記憶されているユーザ情報を管理する。

ライセンス管理（Ｗｒａｐｐｅｒ）部１１２４は後述するライセンス情報記憶部１１４４に記憶されているライセンス情報を管理する。機器管理部１１２５は後述する機器情報記憶部１１４５に記憶されている機器情報を管理する。一時画像保存部１１２６は後述する一時画像記憶部１１４６への一時画像の保存、一時画像記憶部１１４６からの一時画像の取得を行う。データ保管部１１２７は後述のジョブ情報記憶部１１４７などにデータを保管する。

ログ収集部１１２８は、収集したログ情報を例えば後述するようなログ情報記憶部１１４１に記憶させる。課金（Ｗｒａｐｐｅｒ）部１１２９は課金情報を作成して例えば後述する課金情報記憶部１１４８に記憶させる。

画像処理ワークフロー制御部１１３０はアプリケーション１１０１又は固有サービス１１０２からの要求に基づいて画像処理に関するワークフローを制御する。メッセージキュー１１３１は処理の種類に対応するキューを有する。画像処理ワークフロー制御部１１３０は処理（ジョブ）に係るリクエストのメッセージを、そのジョブの種類に対応するキューに投入する。

ワーカー１１３２は対応するキューを監視している。キューにメッセージが投入されるとワーカー１１３２は、対応するジョブの種類に応じた画像変換や画像送信などの処理を行う。なお、キューに投入されたメッセージはワーカー１１３２が主体的に読み出す（Ｐｕｌｌ）ようにしてもよいし、キューからワーカー１１３２に提供する（Ｐｕｓｈ）ようにしてもよい。

また、データベース１１０４は、ログ情報記憶部１１４１、テナント情報記憶部１１４２、ユーザ情報記憶部１１４３、ライセンス情報記憶部１１４４、機器情報記憶部１１４５、一時画像記憶部１１４６、ジョブ情報記憶部１１４７、課金情報記憶部１１４８及びアプリケーション固有の設定情報記憶部１１４９を有する。

ログ情報記憶部１１４１はログ情報を記憶する。テナント情報記憶部１１４２は組織情報を記憶する。ユーザ情報記憶部１１４３はユーザ情報を記憶する。ライセンス情報記憶部１１４４は、後述のライセンス情報を記憶する。機器情報記憶部１１４５は機器情報を記憶する。

一時画像記憶部１１４６は一時画像を記憶する。一時画像は、例えばワーカー１１３２が処理するスキャン画像などのファイルやデータである。ジョブ情報記憶部１１４７は処理（ジョブ）に係るリクエストの情報（ジョブ情報）を記憶する。課金情報記憶部１１４８は後述の課金情報を記憶する。アプリケーション固有の設定情報記憶部１１４９はアプリケーション１１０１に固有の設定情報を記憶する。

業務サービス１１０５は、ライセンス管理部１１５１、課金部１１５２、契約管理部１１５３、及び、請求部１１５４を有する。ライセンス管理部１１５１は後述のライセンス情報を管理する。課金部１１５２は後述の課金に関する処理を行う。契約管理部１１５３は契約情報を管理する。請求部１１５４は後述の請求に関する処理を行う。

サービス提供システム１０２１は認証・認可や画像処理に関するワークフロー等の共通サービスを提供する統合基盤と、統合基盤の機能を利用してスキャンサービス、プリントサービス等のアプリサービスを提供するサービス群として機能する。図３のサービス提供システム１０２１はサービス群と統合基盤とを分離した構成により、アプリケーション１１０１を容易に開発できる。

なお、図３に示したサービス提供システム１０２１の処理ブロックの分類形態は一例であり、図３に示される階層で分類されていることが必須ではない。第１の実施形態に係るサービス提供システム１０２１の処理を実施できるのであれば、図３に示される階層関係などは特定のものに限定されない。

図３のサービス提供システム１０２１は例えば図４に示すようなコンポーネント間の関係を有している。図４はサービス提供システムのコンポーネント間の関係を示す一例の説明図である。

図４において業務サービス１１０５はプラットフォームとしてグローバルに共通なコンポーネントであるライセンス管理部１１５１及び課金部１１５２と、販売地域や販売会社によって異なる契約管理部１１５３及び請求部１１５４と、を含む構成である。図４においてライセンス管理部１１５１及び課金部１１５２はビジネスサービス１２０１を構成している。また、契約管理部１１５３及び請求部１１５４は販売地域や販売会社によって異なる基幹システム１２０２に置かれている。さらに、図４では共通サービス１１０３とビジネスサービス１２０１とがサービスプラットフォームに置かれている。

図４の構成では、ライセンス情報や課金情報をグローバルに管理できるというメリットがある。なお、販売地域や販売会社でライセンス情報や課金情報を管理できればよいのであれば、販売地域や販売会社の基幹システム１２０２にビジネスサービス１２０１を置くようにしてもよい。基幹システム１２０２にビジネスサービス１２０１を置くことで販売会社はライセンス情報や課金情報を販売地域外に出さなくても済む。

図４において、アプリケーション１１０１は共通サービス１１０３を利用する。ライセンス管理（Ｗｒａｐｐｅｒ）部１１２４は業務サービス１１０５のライセンス管理部１１５１を利用する。課金（Ｗｒａｐｐｅｒ）部１１２９は業務サービス１１０５の課金部１１５２を利用する。また、業務サービス１１０５の契約管理部１１５３はライセンス管理部１１５１及び課金部１１５２を利用する。業務サービス１１０５の請求部１１５４は課金部１１５２を利用する。

図３に示したサービス提供システム１０２１は前述したライセンス情報記憶部１１４４にライセンス情報を記憶している。図５はライセンス情報の一例の構成図である。図５のライセンス情報はデータ項目として、サービス種別、ライセンスＩＤ、販売地域、国、タイムゾーン、商品コード、数量（台数）、利用開始日、課金開始日、利用終了日、解約予定日、状態などを有する。また、図５のライセンス情報はデータ項目として、親サービス種別、親ライセンスＩＤ、登録用コード、機種機番、次ライセンス種別、次ライセンスＩＤ、ライセンス種別、ライセンス形態、数量（ユーザ数）などを有する。さらに、図５のライセンス情報はデータ項目として、使用中の台数、使用中のユーザ数、契約形態、課金形態、使用上限、使用上限基準日時、使用可能残度数、使用度数などを有する。

サービス種別はポータル、スキャン、プリントなどのサービスの種別を特定する情報である。ライセンスＩＤは、ライセンスを識別する識別情報である。ライセンスＩＤは例えばテナントライセンスの場合にテナントＩＤとなり、サービスライセンスの場合にサービスＩＤとなる。販売地域は、ライセンスを販売する地域等を表す情報である。

国はライセンスを使用する国名を表している。タイムゾーンはライセンスを使用する国の標準時を表している。商品コードは、ライセンスに対応する商品を識別する識別情報である。また、数量（台数）はボリュームライセンスの場合などに機器の数などを表す情報である。

利用開始日はライセンスが有効になった日を表す情報である。課金開始日は課金の開始される日を表す情報であり、利用開始日と同日か後日（例えば翌月１日など）である。利用終了日は表示上のライセンス期限を表す情報であり、例えば課金開始日の一年後などである。解約予定日はライセンスが無効化される日を表す情報である。状態はライセンスの状態を表す情報である。ライセンスの状態には、例えば利用開始前を表す仮登録、利用中を表す登録、利用終了を表す解約などがある。

親サービス種別は、サービスライセンスの場合にテナントが設定される。親ライセンスＩＤはサービスライセンスの場合にテナントＩＤが設定される。登録用コードは、テナントライセンスの場合に設定される。登録用コードはテナントの開設時に入力するコードである。機種機番はサービスライセンスの場合に設定される。機種機番はライセンスの対象となる機器を特定する情報である。

次ライセンス種別は更新済みのサービスライセンスの場合に設定される。次ライセンス種別はサービス種別と同じ値となる。次ライセンスＩＤは更新済みのサービスライセンスの場合に設定される。次ライセンスＩＤは更新済みのサービスライセンスのサービスＩＤとなる。

ライセンス種別は機器ライセンスやユーザライセンスなどのサービスライセンスの種別を特定する情報である。ライセンス種別はサービスライセンスにより利用の制限の対象である機器やユーザなどを設定する情報である。ライセンス形態は、他の種別のサービスライセンスと組み合わせて利用を許可するか、自身のサービスライセンスのみで利用を許可するか、を表す情報である。

例えばライセンス形態には「機器ライセンスのみ」や「機器ライセンス＋ユーザライセンス」のような情報が設定される。ライセンス形態が「機器ライセンスのみ」である場合はライセンス種別が「機器ライセンス」であるサービスライセンスが登録されることによりサービスの利用が許可される。また、ライセンス形態が「機器ライセンス＋ユーザライセンス」である場合はライセンス種別が「機器ライセンス」であるサービスライセンスとライセンス種別が「ユーザライセンス」であるサービスライセンスが登録されることによりサービスの利用が許可される。

数量（ユーザ数）はライセンスによりサービスを利用可能とすることができるユーザ数を表す情報である。使用中の台数はライセンスによりサービスが利用可能となっている機器の台数を表す情報である。使用中のユーザ数はライセンスによりサービスが利用可能となっているユーザ数を表す情報である。契約形態は本契約のライセンスか、トライアル契約のライセンス（トライアルライセンス）か、を表す情報である。

課金形態は、定額課金か、プリペイド課金か、従量課金か、を表す情報である。上限付きの定額課金の場合は、基準日時（例えば各月１日の００：００）までに使用上限に達すると、基準日時までサービスを使用できなくなるか、あるいはＱｏＳが劣化する。使用上限はプリペイドライセンスで一時的に上げることができるようにしてもよい。

また、上限付きのプリペイド課金の場合は、プリペイドライセンスによる使用上限に達すると、新たなプリペイドライセンスを購入しない限りサービスを使用できないか、あるいはＱｏＳが劣化する。

また、従量課金の場合は、同じサービス種別において、例えば「従量課金１」「従量課金２」というように複数の異なるパラメータで従量課金するライセンスを選べるようにすることもできる。

使用上限は使用できる度数（ページ数、回数、時間など）の上限である。使用上限基準日時はバッチ処理により使用可能残度数、使用度数をリセットする日時である。使用上限基準日時は基幹システム１２０２側（契約管理部１１５３）側からの要求でリセットするようにしてもよいが、ネットワーク障害などでリセットできないリスクが高まるため、サービスプラットフォーム側でバッチ処理によりリセットすることが望ましい。

使用可能残度数は、確定した使用度数と予約済みの度数とを使用上限から引いた度数である。使用度数は確定した使用度数である。なお、どのパラメータに対して従量課金や上限の制限を行うかは、サービス種別によって異なる。したがって、どのパラメータに対して従量課金や上限の制限を行うかの情報は、ライセンス情報として保持しない。

図６はライセンス情報の具体例を示す図である。なお、図６のライセンス情報は第１の実施形態の説明に不要なデータ項目について適宜省略している。ライセンスＩＤ「１００００００００」のライセンスは機器に関連付けられる機器ライセンスの一例である。ライセンスＩＤ「１００００００００」のライセンスはユーザ認証無し、機器認証有りの機器ライセンスの例を示しているため、テナントと関連付けられていない。なお、ライセンスＩＤ「１００００００００」のライセンスは上限付きの定額課金の例を示している。

また、ライセンスＩＤ「１０００００００１」のライセンスはテナントに関連付けられるユーザライセンスの一例である。ライセンスＩＤ「１０００００００１」のライセンスは従量課金の例を示している。なお、ライセンスＩＤ「１０００００００１」のライセンスは機器によらず、テナント内での使用度数に課金するため、ユーザ数の上限を設定していない。

＜処理の詳細＞
《サービス実行》
第１の実施形態に係るサービス提供システム１０２１では例えば図７に示す手順によりサービスが実行される。図７はサービス実行処理の一例のシーケンス図である。ステップＳ１１において、アプリケーション１１０１はテナントに紐付くライセンスのユーザ認証又は機器に紐付くライセンスの機器認証を、認証・認可部１１２１に要求する。認証に成功すると、アプリケーション１１０１は認証・認可部１１２１から認証要求の応答として認証チケットを受け取る。

ステップＳ１２に進み、アプリケーション１１０１は認証チケットとサービス種別とを付加した実行可否の判断を認証・認可部１１２１に要求する。なお、実行可否を判断する処理の詳細は後述する。

認証・認可部１１２１は実行可否の判断を要求されたサービス種別のライセンスが存在すれば、実行可をアプリケーション１１０１に返す。なお、認証・認可部１１２１は実行可否の判断を要求されたサービス種別のライセンスに使用上限があれば、使用可能残度数もアプリケーション１１０１に返す。

実行可を認証・認可部１１２１から返されたアプリケーション１１０１は、課金（Ｗｒａｐｐｅｒ）部１１２９に対し、度数を登録するパターンの処理か、又は、開始及び終了で指定するパターンの処理を行う。なお、ステップＳ１３〜Ｓ１５の処理は使用量を度数で登録するパターンの処理である。ステップＳ１６〜Ｓ１９の処理は、使用量を開始及び終了で指定（通知）するパターンの処理である。

まず、度数を登録するパターンの処理について説明する。アプリケーション１１０１はステップＳ１３において、認証チケットとサービス種別と度数とを付加した使用の予約を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。なお、使用を予約する処理の詳細は後述する。

課金（Ｗｒａｐｐｅｒ）部１１２９は後述する使用履歴のレコードの使用履歴ＩＤと使用可能残度数とをアプリケーション１１０１に返す。なお、課金（Ｗｒａｐｐｅｒ）部１１２９は使用の予約を要求されたサービス種別のライセンスに使用上限があり、付加した度数が使用可能残度数より大きい場合、エラーと使用可能残度数を返す。

ステップＳ１４において、アプリケーション１１０１はサービス種別に対応する処理を実行する。ステップＳ１５に進み、アプリケーション１１０１は使用履歴ＩＤと度数とを付加した使用の確定を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。なお、使用を確定する処理の詳細は後述する。課金（Ｗｒａｐｐｅｒ）部１１２９は使用可能残度数をアプリケーション１１０１に返す。

なお、ステップＳ１３〜Ｓ１５に示した度数を登録するパターンの処理では、サービス種別に対応する処理の実行前に度数が分からない場合、適切な単位で使用の予約を行うようにしてもよい。この場合、アプリケーション１１０１は使用を予約した度数を使い切る度に課金ＡＰＩを呼び、ステップＳ１３〜Ｓ１５の処理を繰り返す。なお、使用上限が無い場合はステップＳ１３の処理を省略してもよい。

また、ステップＳ１５の使用を確定する処理ではステップＳ１３で使用を予約した度数よりも少ない度数で行うようにしてもよい。また、ステップＳ１５の使用を確定する処理はステップＳ１４の処理の実行中に複数回に分けて行ってもよい。そして、課金（Ｗｒａｐｐｅｒ）部１１２９は使用を予約した度数を超えて、使用を確定する処理が要求された場合、使用上限を超えていれば使用可能残度数を０とし、エラーをアプリケーション１１０１に返す。なお、ステップＳ１３の処理を省略した場合、ステップＳ１５の使用を確定する処理では、使用履歴ＩＤではなく認証チケットが付加される。

次に、開始及び終了で指定するパターンの処理について説明する。アプリケーション１１０１はステップＳ１６において、認証チケットとサービス種別とコールバックＵＲＬとを付加した使用の開始を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。なお、使用を開始する処理の詳細は後述する。

課金（Ｗｒａｐｐｅｒ）部１１２９は後述する使用履歴のレコードの使用履歴ＩＤと使用可能残度数とをアプリケーション１１０１に返す。そして、ステップＳ１７においてアプリケーション１１０１はサービス種別に対応する処理を実行する。なお、課金（Ｗｒａｐｐｅｒ）部１１２９は使用の予約を要求されたサービス種別のライセンスに使用上限があり、使用可能残度数が「０」になると、ステップＳ１８に進み、コールバックＵＲＬにコールバックを行う。つまり、課金（Ｗｒａｐｐｅｒ）部１１２９は使用上限を超えた場合にアプリケーション１１０１にコールバックする。

サービス種別に対応する処理が終了すると、アプリケーション１１０１はステップＳ１９において、使用履歴ＩＤを付加した使用の終了を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。なお、使用を終了する処理の詳細は後述する。課金（Ｗｒａｐｐｅｒ）部１１２９は使用可能残度数をアプリケーション１１０１に返す。

このように図７に示すシーケンス図の処理によれば、アプリケーション１１０１の使用量を課金（Ｗｒａｐｐｅｒ）部１１２９に登録させることで、アプリケーション１１０１の処理に対する課金を行うことができる。したがって、図７に示すシーケンス図の処理によれば、翻訳サービスのアプリケーション１１０１でのワード単位の課金も可能となる。

図８は実行可否を判断する処理の一例のフローチャートである。ステップＳ３１において認証・認可部１１２１はアプリケーション１１０１からの実行可否の判断の要求に付加されていた認証チケットが、ユーザ認証により発行された認証チケット（以下、ユーザ認証チケットという）か否かを判定する。

ユーザ認証チケットであれば認証・認可部１１２１はステップＳ３２に進む。認証・認可部１１２１は実行可否の判断の要求に付加されていたサービス種別と一致し、親ライセンスＩＤがユーザ認証チケットに含まれるテナントＩＤと等しいライセンス情報をライセンス情報記憶部１１４４から検索する。ユーザ認証チケットでなければ認証・認可部１１２１はステップＳ３３に進む。認証・認可部１１２１は実行可否の判断の要求に付加されていたサービス種別と一致し、機種機番が機器認証チケットに含まれる機種機番と等しいライセンス情報をライセンス情報記憶部１１４４から検索する。機器認証チケットは機器認証により発行された認証チケットである。

ステップＳ３４において、認証・認可部１１２１はステップＳ３２又はＳ３３においてライセンス情報記憶部１１４４から検索されたライセンス情報があるか判定する。検索されたライセンス情報があれば、認証・認可部１１２１はステップＳ３５に進み、検索されたライセンス情報に使用上限が無いか（設定されていないか）を判定する。

検索されたライセンス情報に使用上限が無ければ、認証・認可部１１２１はステップＳ３６に進み、実行可否「可」と、使用可否残度数「上限なし」とをアプリケーション１１０１に返す。

また、検索されたライセンス情報に使用上限があれば認証・認可部１１２１はステップＳ３７に進み、検索されたライセンス情報に設定されている使用可能残度数が「０」よりも大きいか判定する。使用可能残度数が「０」より大きければ、認証・認可部１１２１はステップＳ３８に進み、実行可否「可」と、ライセンス情報に設定されている使用可否残度数の値とをアプリケーション１１０１に返す。

なお、ステップＳ３４においてライセンス情報がないと判定した場合、ステップＳ３７においてライセンス情報に設定されている使用可能残度数が「０」よりも大きくないと判定した場合は、ステップＳ３９に進む。ステップＳ３９において、認証・認可部１１２１は実行可否「否」と、使用可否残度数「０」とをアプリケーション１１０１に返す。

図９は使用を予約する処理の一例のフローチャートである。ステップＳ５１において課金（Ｗｒａｐｐｅｒ）部１１２９はアプリケーション１１０１からの使用の予約の要求に付加されていた認証チケットが、ユーザ認証チケットか否かを判定する。

ユーザ認証チケットであれば課金（Ｗｒａｐｐｅｒ）部１１２９は、ステップＳ５２に進む。課金（Ｗｒａｐｐｅｒ）部１１２９は使用の予約の要求に付加されていたサービス種別と一致し、親ライセンスＩＤがユーザ認証チケットに含まれるテナントＩＤと等しいライセンス情報をライセンス情報記憶部１１４４から検索する。ユーザ認証チケットでなければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ５３に進む。課金（Ｗｒａｐｐｅｒ）部１１２９は使用の予約の要求に付加されていたサービス種別と一致し、機種機番が機器認証チケットに含まれる機種機番と等しいライセンス情報をライセンス情報記憶部１１４４から検索する。

ステップＳ５４において、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ５２又はＳ５３においてライセンス情報記憶部１１４４から検索されたライセンス情報があるか判定する。検索されたライセンス情報があれば課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ５５に進み、検索されたライセンス情報に使用上限が無いか判定する。

検索されたライセンス情報に使用上限が無ければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ５６に進み、使用履歴のレコードを生成する。図１０は使用履歴のレコードの一例の構成図である。なお、図１０の使用履歴のレコードはデータ項目として使用履歴ＩＤ、状態、ライセンスＩＤ、予約度数、開始／予約日時、終了日時、確定度数、コールバックＵＲＬを有する。

課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴ＩＤを発行し、その使用履歴ＩＤの使用履歴のレコードを生成する。課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードの状態に「予約中」を保存する。また、課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードのライセンスＩＤに、検索されたライセンス情報のライセンスＩＤを保存する。また、課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードの予約度数に、使用の予約の要求に付加されていた度数を保存する。さらに、課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードの開始／予約日時に、使用の予約の要求があった日時を保存する。

そして、ステップＳ５７に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの使用履歴ＩＤと、使用可否残度数「上限なし」とをアプリケーション１１０１に返す。

また、検索されたライセンス情報に使用上限があれば課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ５８に進み、検索されたライセンス情報に設定されている使用可能残度数が使用の予約の要求に付加されていた度数（指定した度数）よりも大きいか判定する。

検索されたライセンス情報に設定されている使用可能残度数が指定した度数よりも大きければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ５９に進み、ステップＳ５６と同様に使用履歴のレコードを生成する。

ステップＳ６０に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は、検索されたライセンス情報の使用可能残度数から、指定した度数を減算する。ステップＳ６１に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は、使用履歴のレコードの使用履歴ＩＤと、減算後の使用可否残度数の値とをアプリケーション１１０１に返す。

検索されたライセンス情報に設定されている使用可能残度数が指定した度数よりも大きくなければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ６２に進み、エラー（使用可能残度数不足）と付加情報（使用可能残度数）とをアプリケーション１１０１に返す。

なお、ステップＳ５４においてライセンス情報がないと判定した場合、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ６３に進み、アプリケーション１１０１にエラー（ライセンスなし）を返す。

図１１は使用を確定する処理の一例のフローチャートである。ステップＳ７１において課金（Ｗｒａｐｐｅｒ）部１１２９はアプリケーション１１０１からの使用の確定の要求に使用履歴ＩＤの指定がないか判定する。

使用履歴ＩＤの指定がなければ課金（Ｗｒａｐｐｅｒ）部１１２９は、ステップＳ７２に進み、ステップＳ５２と同様な手順によりライセンス情報を検索する。課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ７３に進み、使用履歴のレコードを生成する。

使用履歴ＩＤの指定があれば、課金（Ｗｒａｐｐｅｒ）部１１２９は使用の確定の要求に付加されていた使用履歴ＩＤで使用履歴のレコードを検索する。また、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ７５に進み、ライセンスＩＤが使用履歴のレコードに含まれるライセンスＩＤと一致するライセンス情報をライセンス情報記憶部１１４４から検索する。

ステップＳ７３又はＳ７５に続いてステップＳ７６に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードに、使用の確定の要求のあった日時を保存する。また、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの確定度数に、使用の確定の要求に付加されていた度数を保存する。さらに、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの状態に「終了」を保存する。

ステップＳ７７に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は、検索されたライセンス情報の使用度数に、確定度数を加算する。また、ステップＳ７８に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は検索されたライセンス情報に使用上限が無いか判定する。検索されたライセンス情報に使用上限が無ければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ７９に進み、使用可否残度数「上限なし」をアプリケーション１１０１に返す。

また、検索されたライセンス情報に使用上限があれば課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８０に進み、使用履歴のレコードの確定度数と予約度数とが等しいかを判定する。

使用履歴のレコードの確定度数と予約度数とが等しければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８５に進み、検索されたライセンス情報の使用可能残度数をアプリケーション１１０１に返す。使用履歴のレコードの確定度数と予約度数とが等しくなければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８１に進み、使用履歴のレコードの確定度数が予約度数より小さいかを判定する。

使用履歴のレコードの確定度数が予約度数より小さければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８２に進み、検索されたライセンス情報の使用可能残度数に、予約度数から確定度数を減算した値を加算する。そして、ステップＳ８５に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は、加算後の使用可能残度数の値をアプリケーション１１０１に返す。

また、使用履歴のレコードの確定度数が予約度数より小さくなければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８３に進み、検索されたライセンス情報の使用可能残度数から、確定度数から予約度数を減算した値を減算する。

ステップＳ８３に続いてステップＳ８４に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は減算後の使用可能残度数の値が「０」以上であるかを判定する。減算後の使用可能残度数の値が「０」以上であれば、ステップＳ８５に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は減算後の使用可能残度数の値をアプリケーション１１０１に返す。減算後の使用可能残度数の値が「０」以上でなければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８６に進み、ライセンス情報の使用可能残度数の値を「０」に更新する。そして、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ８６に続いてステップＳ８７に進み、上限オーバのエラーをアプリケーション１１０１に返す。

図１２は使用を開始する処理の一例のフローチャートである。ステップＳ１０１において課金（Ｗｒａｐｐｅｒ）部１１２９はアプリケーション１１０１からの使用の開始の要求に付加されていた認証チケットが、ユーザ認証チケットか否かを判定する。

ユーザ認証チケットであれば課金（Ｗｒａｐｐｅｒ）部１１２９は、ステップＳ１０２に進む。課金（Ｗｒａｐｐｅｒ）部１１２９は使用の開始の要求に付加されていたサービス種別と一致し、親ライセンスＩＤがユーザ認証チケットに含まれるテナントＩＤと等しいライセンス情報をライセンス情報記憶部１１４４から検索する。ユーザ認証チケットでなければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１０３に進む。課金（Ｗｒａｐｐｅｒ）部１１２９は使用の開始の要求に付加されていたサービス種別と一致し、機種機番が機器認証チケットに含まれる機種機番と等しいライセンス情報をライセンス情報記憶部１１４４から検索する。

ステップＳ１０４において、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１０２又はＳ１０３においてライセンス情報記憶部１１４４から検索されたライセンス情報があるか判定する。検索されたライセンス情報があれば課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１０５に進み、検索されたライセンス情報に使用上限が無いか判定する。

検索されたライセンス情報に使用上限が無ければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１０６に進み、使用履歴ＩＤを発行し、発行した使用履歴ＩＤの使用履歴のレコードを生成する。課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードの状態に「実行中」を保存する。また、課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードのライセンスＩＤに、検索されたライセンス情報のライセンスＩＤを保存する。さらに、課金（Ｗｒａｐｐｅｒ）部１１２９は生成した使用履歴のレコードの開始／予約日時に、使用の開始の要求があった日時を保存する。

そして、ステップＳ１０７に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの使用履歴ＩＤと、使用可否残度数「上限なし」とをアプリケーション１１０１に返す。

また、検索されたライセンス情報に使用上限があれば課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１０８に進み、検索されたライセンス情報に設定されている使用可能残度数が「０」よりも大きいか判定する。

検索されたライセンス情報に設定されている使用可能残度数が「０」よりも大きければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１０９に進み、ステップＳ１０６と同様に使用履歴のレコードを生成する。そして、ステップＳ１１０に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は、使用履歴のレコードの使用履歴ＩＤと、使用可否残度数の値とをアプリケーション１１０１に返す。

検索されたライセンス情報に設定されている使用可能残度数が「０」よりも大きくなければ課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１１１に進み、エラー（使用可能残度数０）をアプリケーション１１０１に返す。なお、ステップＳ１０４においてライセンス情報がないと判定した場合、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１１２に進み、アプリケーション１１０１にエラー（ライセンスなし）を返す。

図１３は使用を終了する処理の一例のフローチャートである。ステップＳ１２１において課金（Ｗｒａｐｐｅｒ）部１１２９は使用の終了の要求に付加されていた使用履歴ＩＤで使用履歴のレコードを検索する。また、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１２２に進み、ライセンスＩＤが使用履歴のレコードに含まれるライセンスＩＤと一致するライセンス情報をライセンス情報記憶部１１４４から検索する。

ステップＳ１２３に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は検索した使用履歴のレコードに、使用の終了の要求のあった日時を保存する。また、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの確定度数を保存する。また、課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの状態に「終了」を保存する。

ステップＳ１２４に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は、検索されたライセンス情報の使用度数に、確定度数を加算する。また、ステップＳ１２５に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は検索されたライセンス情報に使用上限が無いか判定する。

検索されたライセンス情報に使用上限が無ければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１２６に進み、使用可否残度数「上限なし」をアプリケーション１１０１に返す。

また、検索されたライセンス情報に使用上限があれば、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１２７に進み、使用上限から使用度数を減算して使用可能残度数を算出する。課金（Ｗｒａｐｐｅｒ）部１１２９は算出した使用可能残度数をライセンス情報に保存する。

ステップＳ１２８に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は算出した使用可能残度数の値が「０」以上であるかを判定する。算出した使用可能残度数の値が「０」以上であれば、ステップＳ１２９に進み、課金（Ｗｒａｐｐｅｒ）部１１２９は算出した使用可能残度数の値をアプリケーション１１０１に返す。

算出した使用可能残度数の値が「０」以上でなければ、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１３０に進み、ライセンス情報の使用可能残度数の値を「０」に更新する。そして、課金（Ｗｒａｐｐｅｒ）部１１２９はステップＳ１３０に続いてステップＳ１３１に進み、上限オーバのエラーをアプリケーション１１０１に返す。

なお、図７のステップＳ１６で入力パラメータとしてコールバックＵＲＬを課金（Ｗｒａｐｐｅｒ）部１１２９に渡すことで、課金（Ｗｒａｐｐｅｒ）部１１２９は使用可能残度数が「０」になったときに、アプリケーション１１０１にコールバックできる。アプリケーション１１０１はステップＳ１７の実行を停止できる。

また、図７のステップＳ１６はステップＳ１３と同様に、度数を付加した使用の開始の要求を行うことにより、その度数（予約度数）を消費するとコールバックを行うようにしてもよい。

さらに、使用可能残度数が「０」になったあと、課金（Ｗｒａｐｐｅｒ）部１１２９はアプリケーション１１０１の実行を停止させてもよいし、サービス品質（ＱｏＳ）を下げて実行を継続させてもよい。

《課金・請求》
第１の実施形態に係るサービス提供システム１０２１では例えば図１４に示す手順により課金・請求が実行される。図１４は課金・請求処理の一例のシーケンス図である。図１４では、図７のステップＳ１５又はＳ１９の処理と非同期に、使用履歴のテーブルをビジネスサービス１２０１側に登録（同期）する。

ステップＳ１５１において、課金（Ｗｒａｐｐｅｒ）部１１２９はビジネスサービス１２０１の課金部１１５２に使用履歴のテーブルを登録する。基幹システム１２０２の契約管理部１１５３は例えば料金計算の〆日（締め日）にバッチ処理で起動する。

ステップＳ１５２において、契約管理部１１５３はビジネスサービス１２０１の課金部１１５２に顧客ＩＤとライセンスＩＤと料金情報と計算期間とを付加した料金計算を要求する。ステップＳ１５３において課金部１１５２は使用履歴のテーブルを利用して料金を計算する。

ステップＳ１５３における料金の計算は、例えば次のように行われる。課金部１１５２は料金計算の要求に付加されていたライセンスＩＤと等しく、料金計算の要求に付加されていた計算期間に終了日時が含まれるレコードを使用履歴のテーブルから検索する。課金部１１５２は検索されたレコード（検索結果のレコード）の確定度数を合計する。

そして、課金部１１５２は料金計算の要求に付加されていた料金情報に従って料金を計算する。図１５は料金情報の一例の説明図である。料金情報には課金方式、単価などが含まれており、課金方式、単価及び度数に応じて料金計算が行われる。図５では料金情報の一例として「一律単価方式」「通過変動方式」「２段階定額方式」及び「階段方式」を表している。

ステップＳ１５４に進み、課金部１１５２は料金の計算結果を図１６に示すような計算結果のテーブルに保存する。図１６は計算結果のテーブルの一例の構成図である。図１６の計算結果のテーブルはライセンスＩＤごとに料金を計算している。ステップＳ１５５において課金部１１５２は計算した料金を契約管理部１１５３に返す。

基幹システム１２０２の請求部１１５４は例えば顧客ごとの請求日にバッチ処理で起動する。ステップＳ１５６において、請求部１１５４はビジネスサービス１２０１の課金部１１５２に顧客ＩＤと期間とを付加した計算結果の取得を要求する。

ステップＳ１５７において課金部１１５２は計算結果の取得の要求に付加されていた顧客ＩＤと等しく、計算結果の取得の要求に付加されていた期間に計算期間（終わり）が含まれるレコードを計算結果のテーブルから検索する。そして、課金部１１５２は検索されたレコード（計算結果のリスト）を請求部１１５４に返す。

ステップＳ１５９において、請求部１１５４は課金部１１５２から受信した計算結果のリストに基づき、請求処理を実行する。このように図１４に示すシーケンス図によればアプリケーション１１０１の処理に対する請求を行うことができる。

《ワーカーの処理に対する課金》
第１の実施形態に係るサービス提供システム１０２１では例えば図１７のワーカー１１３２の処理に対して課金を行うこともできる。図１７はワーカーの処理に対する課金について説明するための図である。

アプリケーション１１０１は、画像処理ワークフロー制御部１１３０にジョブ情報の登録を要求する。画像処理ワークフロー制御部１１３０はジョブ情報をジョブ情報記憶部１１４７に登録する。画像処理ワークフロー制御部１１３０は、ジョブ情報に含まれるタイプ（ｔｙｐｅ）から処理の種類（機能）を解析する。画像処理ワークフロー制御部１１３０は処理の種類に合致するメッセージキュー１１３１のキューに、ジョブに係るリクエストのメッセージを投入（キューイング）する。

メッセージキュー１１３１は複数の処理の種類に対応するキューを有している。図１７のワーカー１１３２は１又は複数のキューを担当することができる。また、図１７に示すように、キューは１又は複数のワーカー１１３２に担当されることができる。

例えば図１７は、１つのワーカー１１３２が担当する処理の種類として「ｄｏｃ２ＸＸＸ」「ｓｔｏｒａｇｅ２ＸＸＸ」「ｏｃｒ」「ｐｄｆ２ＸＸＸ、ｏｃｒ」を表している。処理の種類「ｐｄｆ２ＸＸＸ、ｏｃｒ」を担当するワーカー１１３２は複数の処理の種類を担当するワーカー１１３２の例である。

メッセージキュー１１３１のキューを監視しているワーカーフレームワーク１１３３はキューに投入されたジョブに係るリクエストのメッセージを検知する。ワーカーフレームワーク１１３３はキューに登録されたメッセージを取得する。

ワーカーフレームワーク１１３３は取得したメッセージに含まれるジョブＩＤのジョブ情報をジョブ情報記憶部１１４７から取得する。ワーカーフレームワーク１１３３は取得したジョブ情報から処理の種類に合致するワーカー１１３２にジョブ実行を指示する。指示されたジョブを実行したワーカー１１３２はワーカーフレームワーク１１３３にジョブの実行結果を返す。

図１７に示したように、メッセージキュー１１３１は例えば１つのサーバ１０上で動作する。また、ワーカー１１３２及びワーカーフレームワーク１１３３はワーカーサーバ１１Ａ及び１１Ｂ上で動作する。ワーカーサーバ１１Ａ及び１１Ｂは、例えばＷｉｎｄｏｗｓ（登録商標）サーバやＬｉｎｕｘ（登録商標）サーバにより実現される。

図１７に示す構成において、ジョブに含まれる各タスク種別に対して例えば図８の実行可否を判断する処理を行うことにより、ワーカー１１３２の処理に対する課金を行うことができる。例えば実行可否を判断する処理はライセンスなしで動作するタスク種別に対しては実行可否「可」を返す。また、実行可否を判断する処理はライセンスが必要なタスク種別に対してライセンスを検索して判断する。

また、ワーカーフレームワーク１１３３には図７に示したサービス実行処理の使用量を度数で登録するパターンを実装する。ワーカー１１３２には入力情報に対して度数を計算する処理や画像処理を実行する処理を実装する。

図１８はワーカー処理に対する課金の一例のシーケンス図である。ステップＳ１７１において、アプリケーション１１０１は認証チケットを付加してジョブの登録をメッセージキュー１１３１に要求する。

ステップＳ１７２に進み、メッセージキュー１１３１は認証チケットを付加し、ジョブで必要となる全てのワーカー１１３２の実行可否の判断をワーカーフレームワーク１１３３に要求する。

ステップＳ１７３に進み、ワーカーフレームワーク１１３３は実行に必要なサービス種別のライセンスを取得する。なお、ワーカーフレームワーク１１３３は実行にライセンスが必要ない場合、メッセージキュー１１３１に実行可否「可」を返す。

ワーカーフレームワーク１１３３は実行にライセンスが必要な場合、ステップＳ１７４に進み、認証チケットとサービス種別とを付加して実行可否の判断を認証・認可部１１２１に要求する。認証・認可部１１２１は、図８に示したように実行可否を判断する処理を行い、実行可否の判断結果として実行可否と使用可能残度数とをワーカーフレームワーク１１３３に返す。

また、ワーカーフレームワーク１１３３はステップＳ１７５において実行可否の判断結果として実行可否と使用可能残度数とをメッセージキュー１１３１に返す。ステップＳ１７６においてメッセージキュー１１３１は使用可能残度数をアプリケーション１１０１に返す。

なお、ステップＳ１７６における使用可能残度数は、ジョブで必要な全てのワーカー１１３２の使用可能残度数のうち、最も少ない使用可能残度数とする。したがって、一つでも実行可否「否」のワーカー１１３２があれば、メッセージキュー１１３１はステップＳ１７６においてジョブ登録エラーをアプリケーション１１０１に返す。

ステップＳ１７７において、ワーカーフレームワーク１１３３は、メッセージキュー１１３１からジョブに含まれるタスクを取得する。ステップＳ１７８において、ワーカーフレームワーク１１３３は入力情報を付加してタスクの度数の計算をワーカー１１３２に要求する。ワーカー１１３２はタスクの度数を計算し、ワーカーフレームワーク１１３３に返す。なお、実行前にタスクの度数が分からない場合、ワーカー１１３２は実行単位の度数をワーカーフレームワーク１１３３に返す。

ステップＳ１７９に進み、ワーカーフレームワーク１１３３は認証チケットとサービス種別と度数とを付加した使用の予約を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。課金（Ｗｒａｐｐｅｒ）部１１２９は図９に示した使用を予約する処理を行う。

課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの使用履歴ＩＤと使用可能残度数とをワーカーフレームワーク１１３３に返す。ワーカーフレームワーク１１３３はステップＳ１８０において、入力情報と使用可能残度数とを付加して例えば画像処理の実行をワーカー１１３２に要求する。ワーカー１１３２はワーカーフレームワーク１１３３から要求された例えば画像処理を実行する。ワーカー１１３２は例えば画像処理の実行に要した度数と終了フラグとをワーカーフレームワーク１１３３に返す。

ステップＳ１８１に進み、ワーカーフレームワーク１１３３は使用履歴ＩＤと度数とを付加した使用の確定を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。課金（Ｗｒａｐｐｅｒ）部１１２９は図１１に示したように、使用を確定する処理を行う。課金（Ｗｒａｐｐｅｒ）部１１２９は使用可能残度数をワーカーフレームワーク１１３３に返す。

図１８のワーカー処理に対する課金を実現するため、ワーカー１１３２は以下のような度数を計算する処理、画像処理を実行する処理を実装する。ワーカー１１３２に実装される度数を計算する処理は、各ワーカー１１３２が実行するタスクの入力パラメータを入力情報とする。例えばＯＣＲワーカーの場合、入力パラメータは入力ファイルのパス、言語や出力形式等である。また、ワーカー１１３２に実装される度数を計算する処理は、実行に必要となる度数又は適切な実行単位を出力とする。

したがって、度数を計算する処理が実装されたワーカー１１３２は入力情報に対して実行に必要となる度数を計算して返す。例えばワーカー１１３２は例えばＯＣＲがページ単位の課金を行うライセンスを必要としている場合、入力ファイルからページ数を取得して度数として返す。

また、度数を計算する処理が実装されたワーカー１１３２は処理を実行してみないと度数が計算できない場合や、度数を計算するのに長い時間を要する場合に、適切な実行単位を定めて返す。この場合は、最終的に使用可能残度数の範囲でタスクを終了できない可能性がある。

ワーカー１１３２に実装される画像処理を実行する処理は、ワーカー１１３２の処理の入力パラメータ、課金（Ｗｒａｐｐｅｒ）部１１２９から返された使用可能残度数を入力情報とする。

また、ワーカー１１３２に実装される画像処理を実行する処理は、ワーカー１１３２の処理に要した度数と、ワーカー１１３２のタスクが終了したか否かを示す終了フラグとを出力とする。なお、ワーカーフレームワーク１１３３は終了フラグが立つまで一連の処理を繰り返す。

したがって、画像処理を実行する処理が実装されたワーカー１１３２は入力情報に対してワーカー１１３２の処理を実行する。なお、ワーカー１１３２は使用可能残度数が設定されている場合、その使用可能残度数を上限として処理を実行する。ワーカー１１３２はタスクが完了した場合、処理に要した度数と終了フラグ「ｔｒｕｅ」とを返す。タスクが完了しなかった場合、ワーカー１１３２は処理に要した度数（入力情報の使用可能残度数と一致する）と終了フラグ「ｔｒｕｅ」とを返す。

＜システム構成のバリエーション＞
図１９は第１の実施形態に係る情報処理システムの一例の構成図である。図１９の情報処理システム１０００Ａは図１の情報処理システム１０００のサービス提供システム１０２１にネットワークＮ３経由で業務システム１０２２と購買システム１０２３とが接続された構成である。図１９の情報処理システム１０００Ａは例えば図２０に示すように連携して処理を行う。

図２０は情報処理システムの連携処理について説明する図である。業務システム１０２２は業務担当の認証機能と契約情報の入力を受け付ける契約情報入力画面とを有する。購買システム１０２３は顧客の認証機能とサービスの購入を受け付けるサービス購入画面を有する。基幹システム１２０２の契約管理部１１５３はビジネスサービス１２０１のライセンス管理部１１５１にライセンスの発行を要求できる。

例えば業務担当は業務担当のユーザデータベースを持つ業務システム１０２２から契約書（営業が書面で締結）に基づき契約情報を入力する。また、顧客は顧客のユーザデータベースを持つ購買システム１０２３からユーザの入力に基づき契約を締結する。

基幹システム１２０２の契約管理部１１５３は業務システム１０２２に入力された契約情報や購買システム１０２３へのユーザの入力の内容に従って、図２１に示すような契約情報を生成する。図２１は契約情報の一例の構成図である。図２１の契約情報はデータ項目として契約番号、顧客ＩＤ、商品コード、ライセンスＩＤ、課金方法、単価、基準日時などを有する。

基幹システム１２０２の契約管理部１１５３は業務システム１０２２に入力された契約情報や購買システム１０２３へのユーザの入力の内容に従い、ビジネスサービス１２０１のライセンス管理部１１５１にライセンス発行を要求する。基幹システム１２０２の契約管理部１１５３はライセンス管理部１１５１により発行されたライセンスのライセンスＩＤを図２１の契約情報のライセンスＩＤとして保存する。

このように、図１９の情報処理システム１０００Ａでは基幹システム１２０２の契約管理部１１５３からビジネスサービス１２０１のライセンス管理部１１５１にライセンス発行を要求できる。
［第２の実施形態］
＜システム構成＞
図２２は第２の実施形態に係る情報処理システムの一例の構成図である。図２２の情報処理システム１０００Ｂは図１の情報処理システム１０００のネットワークＮ２に外部ストレージシステム１０２４が接続された構成である。

外部ストレージシステム１０２４は、ネットワークＮ２を介してストレージサービスと呼ばれるクラウドサービスを提供する。ストレージサービスとは、外部ストレージシステム１０２４のストレージの記憶領域を貸し出すサービスである。

＜ソフトウェア構成＞
第２の実施形態に係る情報処理システム１０００Ｂは、例えば図２３に示されるような処理ブロックにより実現することができる。図２３は、第２の実施形態に係る情報処理システムの一例の処理ブロック図である。なお、図２３は本実施形態の説明に不要な部分について図示を省略している。

画像形成装置１０１３はブラウザ１３０１を有する。画像形成装置１０１３のユーザはブラウザ１３０１を介して、サービス提供システム１０２１により提供されるサービスを利用することができる。

サービス提供システム１０２１は、サービス処理部１３１０と、ストレージサービス連携部１３２０と、ドキュメントサービス部１３３０とを有する。また、サービス提供システム１０２１は、アプリ情報記憶部１３４０を有する。なお、アプリ情報記憶部１３４０はサービス提供システム１０２１とネットワークＮ２を介して接続される記憶装置等により実現されてもよい。

サービス処理部１３１０は、アプリ管理部１３１１とロジック処理部１３１２とデータＩ／Ｆ部１３１３とを有する。アプリ管理部１３１１は、アプリ情報記憶部１３４０に記憶されているアプリ情報１３４１を管理する。アプリ管理部１３１１は、ブラウザ１３０１からの要求に応じて、アプリ情報１３４１に含まれる画面定義に基づくアプリ画面を返信する。これにより、画像形成装置１０１３のブラウザ１３０１には、サービス提供システム１０２１により提供されるサービスを利用するためのアプリ画面が表示される。アプリ情報１３４１は、上述したアプリ画面を画像形成装置１０１３に表示させるための画面定義と、サービスの処理内容とが記述された情報である。

また、アプリ管理部１３１１は、ロジック処理部１３１２からの要求に応じて、アプリ情報１３４１に含まれる処理内容を返信する。処理内容は、スキャン配信サービスやクラウドプリントサービス等を実現するための一連の処理が記述されている。

ロジック処理部１３１２は、ブラウザ１３０１からの要求に応じて、アプリ管理部１３１１から処理内容を取得する。そして、ロジック処理部１３１２は、取得した処理内容に従ってドキュメントサービス部１３３０又は／及びストレージサービス連携部１３２０のファイル処理部１３２１に対して、処理の実行を要求する。これにより、サービス提供システム１０２１による各種サービスが、画像形成装置１０１３に提供される。

データＩ／Ｆ部１３１３は、ブラウザ１３０１からの要求に応じて、ストレージサービス連携部１３２０のデータ処理部１３２２に対して、例えばフォルダ一覧の取得等を要求する。

ドキュメントサービス部１３３０は、サービス提供システム１０２１により提供されるサービスを実現するためのプログラム（モジュール）群である。ドキュメントサービス部１３３０には、電子ファイルに対してＯＣＲ処理を実行するＯＣＲ処理や電子ファイルを画像形成装置１０１３が印刷可能なデータ形式（印刷データ）に変換する印刷変換処理等が含まれる。ドキュメントサービス部１３３０には例えば電子ファイルの圧縮又は解凍するためのプログラム、電子ファイルのデータ形式を変換（例えばＰＤＦ形式に変換）するためのプログラム等、各種の処理を実行するプログラムが含まれていてもよい。

ストレージサービス連携部１３２０は、ロジック処理部１３１２及びデータＩ／Ｆ部１３１３からの要求に応じて、外部ストレージシステム１０２４に対して、各種処理の実行を要求する。サービス提供システム１０２１は、外部ストレージシステム１０２４毎にストレージサービス連携部１３２０をそれぞれ有する。図２３では複数のストレージサービス連携部１３２０について、各々を区別するときは、上記のように「ストレージサービスＡ連携部」「ストレージサービスＢ連携部」等と記載する。

ストレージサービス連携部１３２０は、ロジック処理部１３１２からの要求を受け付けるファイル処理部１３２１と、データＩ／Ｆ部１３１３からの要求を受け付けるデータ処理部１３２２とを有する。ファイル処理部１３２１は、外部ストレージシステム１０２４に保存されている電子ファイルに対する操作（例えば、取得、保存、編集等）を行うためのＡＰＩが定義された共通Ｉ／Ｆ及び固有Ｉ／Ｆを有する。

共通Ｉ／Ｆは、複数の外部ストレージシステム１０２４において共通に利用できるＡＰＩである。一方、固有Ｉ／Ｆは、特定の外部ストレージシステム１０２４において利用できるＡＰＩである。

一方、データ処理部１３２２は、外部ストレージシステム１０２４に保存されている電子ファイルの書誌情報等のメタデータ（例えば、ファイル一覧、フォルダ一覧等）を取得等するためのＡＰＩが定義された共通Ｉ／Ｆ及び固有Ｉ／Ｆを有する。

以上のように、第２の実施形態に係るサービス提供システム１０２１は、連携して処理を行う外部ストレージシステム１０２４毎に、それぞれストレージサービス連携部１３２０を有する。

図２４はロジック処理部の一例の処理ブロック図である。図２４のロジック処理部１３１２はフロー実行部１３５０と、コンポーネント管理部１３６０と、コンポーネント群１３７０と、型変換管理部１３８０と、型変換群１３９０とを有する。また、ロジック処理部１３１２は、型変換テーブル３０００を利用する。

フロー実行部１３５０は、ブラウザ１３０１からスキャン配信サービス等の処理の実行要求を受け付けると、アプリ管理部１３１１を介して、アプリ情報１３４１から処理内容を取得する。そして、フロー実行部１３５０は、取得した処理内容に従ってコンポーネント群１３７０のコンポーネントに対して処理の実行を要求する。なお、コンポーネントとは各種処理を実行するためのモジュール等であり、クラスや関数等で定義される。

コンポーネント管理部１３６０は、フロー実行部１３５０からの要求に応じて、コンポーネントの生成を行う。なお、コンポーネントの生成とは、例えばクラスで定義されたコンポーネントを、メモリ上に展開することを意味する。

コンポーネント群１３７０は、コンポーネントの集合である。図２４のコンポーネント群１３７０には、課金準備コンポーネント１３７４、ＯＣＲコンポーネント１３７３、課金コンポーネント１３７１、メール配信コンポーネント１３７２が含まれる。図２４のコンポーネント群１３７０に含まれる各コンポーネントは、コンポーネント共通Ｉ／Ｆ１３７５を有する。コンポーネント共通Ｉ／Ｆ１３７５は、各コンポーネントに対して共通に定義されたＡＰＩであり、コンポーネントを生成するためのＡＰＩと、コンポーネントに対して処理の実行を要求するためのＡＰＩとが含まれる。

型変換管理部１３８０は、データ型の型変換を管理する。型変換管理部１３８０はコンポーネントからの要求に応じて、型変換テーブル３０００を参照し、型変換群１３９０に定義されている型変換１３９１を生成する。そして、型変換管理部１３８０は、生成された型変換１３９１に対して型変換処理の実行を要求する。型変換とは、データ型の型変換処理を実行するためのモジュール等であり、クラスや関数等で定義される。

これらの各型変換１３９１は、型変換共通Ｉ／Ｆ１３９２を有する。型変換共通Ｉ／Ｆ１３９２は、各型変換１３９１に対して共通に定義されたＡＰＩであり、型変換１３９１を生成するためのＡＰＩと、型変換１３９１に対して処理の実行を要求するためのＡＰＩとが含まれる。

図２４に示すコンポーネント群１３７０のコンポーネントの処理に対する課金は例えば図２５のシーケンス図に示す手順により行うことができる。図２５はコンポーネント群のコンポーネントの処理に対する課金の一例のシーケンス図である。

ステップＳ２０１において、ブラウザ１３０１はアプリＩＤ、ファイル、宛先を付加してロジック処理部１３１２のフロー実行部１３５０に処理実行を要求する。フロー実行部１３５０は認証チケット、データを付加して課金準備コンポーネント１３７４に処理実行を要求する。

ステップＳ２０３において、課金準備コンポーネント１３７４は認証チケットとサービス種別とを付加して実行可否の判断を認証・認可部１１２１に要求する。認証・認可部１１２１は、図８に示したように実行可否を判断する処理を行い、実行可否の判断結果として実行可否と使用可能残度数とを課金準備コンポーネント１３７４に返す。

ステップＳ２０４に進み、課金準備コンポーネント１３７４は認証チケットとサービス種別と度数とを付加した使用の予約を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。課金（Ｗｒａｐｐｅｒ）部１１２９は図９に示した使用を予約する処理を行う。

課金（Ｗｒａｐｐｅｒ）部１１２９は使用履歴のレコードの使用履歴ＩＤと使用可能残度数とを課金準備コンポーネント１３７４に返す。ステップＳ２０５に進み、課金準備コンポーネント１３７４はデータと使用履歴ＩＤとをフロー実行部１３５０に返す。

ステップＳ２０６においてフロー実行部１３５０はデータを付加して処理の実行をＯＣＲコンポーネント１３７３に要求する。ＯＣＲコンポーネント１３７３はフロー実行部１３５０から要求された処理を実行し、処理後のデータをフロー実行部１３５０に返す。

ステップＳ２０７においてフロー実行部１３５０は処理後のデータを付加して処理の実行を課金コンポーネント１３７１に要求する。課金コンポーネント１３７１は使用履歴ＩＤと度数とを付加した使用の確定を課金（Ｗｒａｐｐｅｒ）部１１２９に要求する。

課金（Ｗｒａｐｐｅｒ）部１１２９は図１１に示したように、使用を確定する処理を行う。課金（Ｗｒａｐｐｅｒ）部１１２９は使用可能残度数を課金コンポーネント１３７１に返す。ステップＳ２０９において課金コンポーネント１３７１は処理後のデータと使用履歴ＩＤとをフロー実行部１３５０に返す。

ステップＳ２１０に進み、フロー実行部１３５０は宛先と処理後のデータとを付加して処理の実行をメール配信コンポーネント１３７２に要求する。ステップＳ２１１においてメール配信コンポーネント１３７２は処理度のデータを宛先にメール送信する。ステップＳ２１２において、メール配信コンポーネント１３７２はフロー実行部１３５０にデータを返す。ステップＳ２１３においてフロー実行部１３５０はブラウザ１３０１に処理結果を返す。

図２５のコンポーネントの処理に対する課金を実現するため、課金準備コンポーネント１３７４は前述した実行可否の判断を要求する処理と、使用の予約を要求する処理とを実装する。例えば課金準備コンポーネント１３７４はサービス種別と、課金度数を計算する入力データの属性（ページ数など）及び係数と、を入力パラメータとする。課金準備コンポーネント１３７４は属性の値×係数から度数を計算する。また、課金準備コンポーネント１３７４は使用履歴ＩＤを出力パラメータとする。

図２５のコンポーネントの処理に対する課金を実現するため、課金コンポーネント１３７１は前述した使用の確定を要求する処理を実装する。例えば課金コンポーネント１３７１は課金度数を計算する入力データの属性及び係数と、使用履歴ＩＤとを入力パラメータとする。

第２の実施形態に係る情報処理システム１０００Ｂは図２４に示すコンポーネント群１３７０のコンポーネントの処理に対する課金を、図２６に示すようにフローに追加できる課金準備コンポーネント１３７４と課金コンポーネント１３７１とにより実現する。

図２６は、コンポーネントの処理に対する課金の一例のイメージ図である。例えば図２６（Ａ）に示すＯＣＲコンポーネント１３７３とメール配信コンポーネント１３７２との処理フローに課金を行うものとする。

第２の実施形態に係る情報処理システム１０００Ｂは図２６（Ｂ）に示すように、図２６（Ａ）の処理フローに課金準備コンポーネント１３７４及び課金コンポーネント１３７１の処理を追加することで、コンポーネントの処理に対する課金を実現している。例えば図２６（Ｂ）の課金コンポーネント１３７１はＯＣＲコンポーネント１３７３から出力されるファイルサイズにより課金を行うことができる。

このように、第２の実施形態に係る情報処理システム１０００Ｂによれば、コンポーネント群１３７０のコンポーネントに入力されるデータや、コンポーネントから出力されるデータに対する課金を行うことができる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

例えば、サービス提供システム１０２１又は図４のサービスプラットフォームは、特許請求の範囲に記載した情報処理システムの一例である。画像形成装置１０１３は端末装置の一例である。共通サービス１１０３は共通サービス提供手段の一例である。プラットフォームＡＰＩ１１０６、１１０７は使用量登録受付手段の一例である。課金部１１５２は課金手段の一例である。請求部１１５４は請求手段の一例である。ワーカー１１３２、ＯＣＲコンポーネント１３７３は処理実行部の一例である。

１０００、１０００Ａ〜１０００Ｃ 情報処理システム
１０１１ クライアント端末
１０１２ 携帯端末
１０１３ 画像形成装置
１０２１ サービス提供システム
１０２２ 業務システム
１０２３ 購買システム
１０２４ 外部ストレージシステム
１１０１ アプリケーション
１１０２ 固有サービス
１１０３ 共通サービス
１１０４ データベース
１１０５ 業務サービス
１１０６、１１０７ プラットフォームＡＰＩ（Application Programming Interface）
１１１１ ポータルサービスアプリ
１１１２ａ スキャンサービスアプリのＵＩ部
１１１２ｂ スキャンサービスアプリのロジック部
１１１３ａ プリントサービスアプリのＵＩ部
１１１３ｂ プリントサービスアプリのロジック部
１１１４ Ｉ／Ｏサービス部
１１２１ 認証・認可部
１１２２ テナント管理部
１１２３ ユーザ管理部
１１２４ ライセンス管理（Ｗｒａｐｐｅｒ）部
１１２５ 機器管理部
１１２６ 一時画像保存部
１１２７ データ保管部
１１２８ ログ収集部
１１２９ 課金（Ｗｒａｐｐｅｒ）部
１１３０ 画像処理ワークフロー制御部
１１３１ メッセージキュー
１１３２ ワーカー
１１３３ ワーカーフレームワーク
１１４１ ログ情報記憶部
１１４２ テナント情報記憶部
１１４３ ユーザ情報記憶部
１１４４ ライセンス情報記憶部
１１４５ 機器情報記憶部
１１４６ 一時画像記憶部
１１４７ ジョブ情報記憶部
１１４８ 課金情報記憶部
１１４９ アプリケーション固有の設定情報記憶部
１１５１ ライセンス管理部
１１５２ 課金部
１１５３ 契約管理部
１１５４ 請求部
１２０１ ビジネスサービス
１２０２ 基幹システム
１３０１ ブラウザ
１３１０ サービス処理部
１３１２ ロジック処理部
１３５０ フロー実行部
１３７１ 課金コンポーネント
１３７２ メール配信コンポーネント
１３７３ ＯＣＲコンポーネント
１３７４ 課金準備コンポーネント
１５００ コンピュータ
１５０１ 入力装置
１５０２ 表示装置
１５０３ 外部Ｉ／Ｆ
１５０３ａ 記録媒体
１５０４ ＲＡＭ
１５０５ ＲＯＭ
１５０６ ＣＰＵ
１５０７ 通信Ｉ／Ｆ
１５０８ ＨＤＤ
Ｂ バス
ＦＷ ファイヤウォール
Ｎ１〜Ｎ３ ネットワーク

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

Claims (11)

1. １台以上の情報処理装置を含む情報処理システムであって、
   端末装置からの要求に基づき処理を実行する１つ以上のアプリケーションに対し、共通サービスを提供する共通サービス提供手段と、
   前記共通サービス提供手段に対する前記処理の使用量の登録を前記アプリケーションから受け付ける使用量登録受付手段と、
   前記共通サービス提供手段に登録された前記処理の使用量と、該処理の使用量から料金を算出する方法を表す料金情報とに基づき、前記処理の使用量に対する料金を算出する課金手段と、
   を有する情報処理システム。
2. 前記課金手段により算出した前記処理の使用量に対する料金の請求処理を実行する請求手段、を更に有する請求項１記載の情報処理システム。
3. 前記使用量登録受付手段は、前記アプリケーションからの要求に基づき処理を実行する処理実行部の処理の使用量の登録を受け付けること
   を特徴とする請求項１又は２記載の情報処理システム。
4. 前記使用量登録受付手段は、前記処理の使用量の登録を度数で受け付けること
   を特徴とする請求項１乃至３何れか一項に記載の情報処理システム。
5. 前記使用量登録受付手段は、前記処理の使用量の登録を、前記処理の開始時と終了時との通知により受け付けること
   を特徴とする請求項１乃至３何れか一項に記載の情報処理システム。
6. １台以上の情報処理装置を含む情報処理システムであって、
   端末装置からの要求に基づき処理を実行する１つ以上のアプリケーションに対し、共通サービスを提供する共通サービス提供手段と、
   前記共通サービス提供手段に対する前記処理の使用量の登録を前記アプリケーションから受け付ける使用量登録受付手段と、
   前記共通サービス提供手段に登録された前記処理の使用量と、前記処理の使用上限を含むライセンス情報とに基づき、前記アプリケーションが使用可能な残りの前記処理の使用量を前記アプリケーションに通知して前記アプリケーションによる前記処理の使用上限を制限する課金手段と、
   を有する情報処理システム。
7. 前記課金手段は、前記共通サービス提供手段に登録された前記処理の使用量と、該処理の使用量から料金を算出する方法を表す料金情報とに基づき、前記処理の使用量に対する料金を算出すること
   を特徴とする請求項６記載の情報処理システム。
8. 前記課金手段により算出した前記処理の使用量に対する料金の請求処理を実行する請求手段、を更に有する請求項６又は７記載の情報処理システム。
9. 前記使用量登録受付手段は、ＡＰＩ（Application Programming Interface）により実現されること
   を特徴とする請求項１乃至８何れか一項記載の情報処理システム。
10. １台以上の情報処理装置を含む情報処理システムにおいて実行される課金方法であって、
    端末装置からの要求に基づき処理を実行する１つ以上のアプリケーションに対し、共通サービスを提供する共通サービス提供手段に対する前記処理の使用量の登録を、前記アプリケーションから受け付ける使用量登録受付ステップと、
    前記共通サービス提供手段に登録された前記処理の使用量と、該処理の使用量から料金を算出する方法を表す料金情報とに基づき、前記処理の使用量に対する料金を算出する課金ステップと、
    を有する課金方法。
11. １台以上の情報処理装置を含む情報処理システムにおいて実行される課金方法であって、
    端末装置からの要求に基づき処理を実行する１つ以上のアプリケーションに対し、共通サービスを提供する共通サービス提供手段に対する前記処理の使用量の登録を、前記アプリケーションから受け付ける使用量登録受付ステップと、
    前記共通サービス提供手段に登録された前記処理の使用量と、前記処理の使用上限を含むライセンス情報とに基づき、前記アプリケーションが使用可能な残りの前記処理の使用量を前記アプリケーションに通知して前記アプリケーションによる前記処理の使用上限を制限する課金ステップと、
    を有する課金方法。

Images