(57)【要約】      （修正有）【課題】システムの利用者側に起因するエラーを除外したエラーを検出した場合の利用料を決定できる利用料決定プログラムを提供する。【解決手段】利用料決定プログラムは、システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、解析した結果、レスポンスからシステムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と特定のエラーの組み合わせを管理し、組み合わせに基づいて、特定のエラーにより利用者が影響を受ける負担の度合を表す影響度を特定し、特定のエラーのエラー数と影響度とに応じてシステムの利用料を決定する処理をコンピュータに実行させる。【選択図】図７
2019160130.tif 000002
【特許請求の範囲】
【請求項１】
システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、
前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、
前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、
前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、
処理をコンピュータに実行させる利用料決定プログラム。
【請求項２】
前記処理は、前記影響度の合計値を前記エラー数に基づいて算出し、予め定めた対応表に基づいて、算出した前記合計値に応じた割引率を決定し、決定した前記割引率と前記システムの割引前の利用料とに基づいて、前記システムの利用料を決定する、
ことを特徴とする請求項１に記載の利用料決定プログラム。
【請求項３】
前記処理は、前記エラー数を日毎に計数し、計数した値が閾値以上になるエラー頻発日を検出した場合、前記エラー頻発日と前記システムが提供するサービスの品質を保証する対象日とを比較し、前記エラー頻発日が前記対象日に対応する場合、前記割引率の前記システムの割引前の利用料への適用を除外する、
ことを特徴とする請求項２に記載の利用料決定プログラム。
【請求項４】
前記リクエスト内容は、前記システムが提供するサービスの名称とＡＰＩで利用されるメソッドの名称及びリソースの名称との組み合わせである、
ことを特徴とする請求項１から３のいずれか１項に記載の利用料決定プログラム。
【請求項５】
システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、
前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、
前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、
前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、
処理をコンピュータが実行する利用料決定方法。
【請求項６】
システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、
前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、
前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、
前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、
処理を実行する処理部を有することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、利用料決定プログラム、利用料決定方法、及び情報処理装置に関する。
【背景技術】
【０００２】
共有ストレージ（例えば、データベースシステム）及び／またはコンピューティングリソースへのアクセスといったサービスをクライアントに提供するシステムが知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２０１６−５２９５９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、上述したシステムを利用する利用者がシステムの提供者に支払う利用料は、多くの場合、サービスの品質を保証するService Level Agreement（ＳＬＡ）に基づいて定められている。例えば、システム全体の稼働が停止した場合には、ＳＬＡに基づいて、利用料が減額されることがある。
【０００５】
一方で、システム全体の稼働停止ではなく、利用者が行った個別の操作に対して一時的な失敗（以下、エラーという）が発生した場合には、ＳＬＡの保証対象外に該当する。このため、利用料が減額されるか否かは、ＳＬＡとは別にエラーの発生要因に起因して個別に判断される。例えば、このような一時的なエラーがシステムの利用者側に起因する場合には、利用料が減額されることはない。
【０００６】
そこで、１つの側面では、システムの利用者側に起因するエラーを除外した利用料を決定できる利用料決定プログラム、利用料決定方法、及び情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
１つの実施態様では、利用料決定プログラムは、システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、処理をコンピュータに実行させる。
【発明の効果】
【０００８】
システムの利用者側に起因するエラーを除外した利用料を決定することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は利用料決定システムの一例を説明するための図である。
【図２】図２はＡＰＩ管理サーバのハードウェア構成の一例である。
【図３】図３は利用料決定システムのブロック図の一例である。
【図４】図４（ａ）は契約管理テーブルの一例である。図４（ｂ）はベース契約管理テーブルの一例である。図４（ｃ）は割引率管理テーブルの一例である。図４（ｄ）は利用料管理テーブルの一例である。
【図５】図５はエラー情報管理テーブルの一例である。
【図６】図６は影響度管理テーブルの一例である。
【図７】図７はＡＰＩ管理サーバの動作の一例を示すフローチャートである。
【図８】図８（ａ）はリクエストメッセージの一例である。図８（ｂ）はレスポンスメッセージの一例である。
【図９】図９は第３サービス提供サーバの動作の一例を示すフローチャートである。
【図１０】図１０はＡＰＩ管理サーバの動作の他の一例を示すフローチャートである。
【図１１】図１１は課金管理画面の一例である。
【発明を実施するための形態】
【００１０】
以下、本件を実施するための形態について図面を参照して説明する。
【００１１】
図１は利用料決定システムＳＹＳの一例を説明するための図である。利用料決定システムＳＹＳは利用者端末１００と情報処理装置としてのApplication Programming Interface（ＡＰＩ）管理サーバ２００と管理者端末３００とを備えている。図１では、利用者端末１００及び管理者端末３００の一例としてPersonal Computer（ＰＣ）が示されている。ＰＣに代えて、スマートフォンやタブレット端末といったスマートデバイスが利用者端末１００や管理者端末３００として利用されてもよい。
【００１２】
ＡＰＩ管理サーバ２００はクラウドＣＬ上に配備される。より詳しくは、ＡＰＩ管理サーバ２００は第１サービス提供サーバ２１０や第３サービス提供サーバ２３０などと共にデータセンターに配備される。ＡＰＩ管理サーバ２００、第１サービス提供サーバ２１０、及び第３サービス提供サーバ２３０などがデータセンターなどに配備され、互いに接続されることにより、クラウドサービス提供システムＳＴを実現することができる。尚、ＡＰＩ管理サーバ２００はＡＰＩエンドポイントなどと呼ばれることがある。一方、第１サービス提供サーバ２１０や第３サービス提供サーバ２３０などはバックエンドセキュアやバックエンドシステムなどと呼ばれることがある。
【００１３】
利用者端末１００とＡＰＩ管理サーバ２００と管理者端末３００は、通信ネットワークＮＷを介して互いに接続されている。通信ネットワークＮＷとしては例えばインターネットなどがある。したがって、利用者端末１００及び管理者端末３００はいずれも通信ネットワークＮＷを利用してＡＰＩ管理サーバ２００に接続することができる。
【００１４】
利用者端末１００は入力装置１１０、表示装置１２０、及び制御装置１３０を含んでいる。入力装置１１０と表示装置１２０はいずれも制御装置１３０と接続されている。制御装置１３０は入力装置１１０から入力された情報に基づいて、表示装置１２０の表示内容を制御する。また、制御装置１３０は入力装置１１０から入力された情報をＡＰＩ管理サーバ２００に向けて送信したり、ＡＰＩ管理サーバ２００から送信された情報を受信したりする。制御装置１３０は、情報を受信した場合、受信した情報に基づいて、表示装置１２０の表示内容を制御する。尚、管理者端末３００については、基本的に、利用者端末１００と同様の構成及び機能を有するため、説明は省略する。
【００１５】
ここで、上述した制御装置１３０が送信する情報としては、REpresentational State Transfer（ＲＥＳＴ）形式のＡＰＩ（ＲＥＳＴ−ＡＰＩ）におけるリクエストメッセージがある。リクエストメッセージはクラウドサービス提供システムＳＴが管理する種々のＡＰＩの呼び出し（コール）を要求する情報である。一方、制御装置１３０が受信する情報としては、ＲＥＳＴ−ＡＰＩにおけるレスポンスメッセージがある。レスポンスメッセージはリクエストメッセージに対する応答を表す情報である。
【００１６】
したがって、制御装置１３０は、レスポンスメッセージに基づいて、表示装置１２０の表示内容を制御する。これにより、表示装置１２０はレスポンスメッセージに応じた種々の内容を表示する。利用者は表示装置１２０に表示された内容に基づいて、クラウドサービス提供システムＳＴに依頼したサービスの成否を判断する。例えば、利用者自身の設定誤りといった不適切な操作によりエラーが発生していた場合には、利用者は改めてクラウドサービス提供システムＳＴにサービスを依頼する。一方、利用者自身の不適切な操作ではない適切な操作によりエラーが発生していた場合には、利用者は必要に応じてリカバリ処理を行う。具体的には、クラウドサービス提供システムＳＴが提供するサービスの過程で生成されてシステム内に残存した不要な情報を利用者はリカバリ処理として削除する処理を行う。
【００１７】
以下、上述した利用者端末１００、ＡＰＩ管理サーバ２００、第１サービス提供サーバ２１０などの詳細を説明する。
【００１８】
図２はＡＰＩ管理サーバ２００のハードウェア構成の一例である。尚、上述した利用者端末１００及び管理者端末３００については基本的にＡＰＩ管理サーバ２００と同様のハードウェア構成であるため、説明を省略する。また、上述した第１サービス提供サーバ２１０や第３サービス提供サーバ２３０なども基本的にＡＰＩ管理サーバ２００と同様のハードウェア構成であるため、説明を省略する。図２に示すように、ＡＰＩ管理サーバ２００は、少なくともCentral Processing Unit（ＣＰＵ）２００Ａ、Random Access Memory（ＲＡＭ）２００Ｂ、Read Only Memory（ＲＯＭ）２００Ｃ及びネットワークＩ／Ｆ（インタフェース）２００Ｄを含んでいる。ＡＰＩ管理サーバ２００は、必要に応じて、Hard Disk Drive（ＨＤＤ）２００Ｅ、入力Ｉ／Ｆ２００Ｆ、出力Ｉ／Ｆ２００Ｇ、入出力Ｉ／Ｆ２００Ｈ、ドライブ装置２００Ｉの少なくとも１つを含んでいてもよい。ＣＰＵ２００Ａからドライブ装置２００Ｉまでは、内部バス２００Ｊによって互いに接続されている。すなわち、ＡＰＩ管理サーバ２００はコンピュータによって実現することができる。
【００１９】
入力Ｉ／Ｆ２００Ｆには、入力装置７１０が接続される。入力装置７１０としては、例えばキーボードやマウスなどがある。尚、上述した入力装置１１０についても入力装置７１０と基本的に同様である。出力Ｉ／Ｆ２００Ｇには、表示装置７２０が接続される。表示装置７２０としては、例えば液晶ディスプレイがある。尚、上述した表示装置１２０についても表示装置７２０と基本的に同様である。入出力Ｉ／Ｆ２００Ｈには、半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばUniversal Serial Bus（ＵＳＢ）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ２００Ｈは、半導体メモリ７３０に記憶されたプログラムやデータを読み取る。入力Ｉ／Ｆ２００Ｆ及び入出力Ｉ／Ｆ２００Ｈは、例えばＵＳＢポートを備えている。出力Ｉ／Ｆ２００Ｇは、例えばディスプレイポートを備えている。
【００２０】
ドライブ装置２００Ｉには、可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばCompact Disc（ＣＤ）−ＲＯＭ、Digital Versatile Disc（ＤＶＤ）といったリムーバブルディスクがある。ドライブ装置２００Ｉは、可搬型記録媒体７４０に記録されたプログラムやデータを読み込む。ネットワークＩ／Ｆ２００Ｄは、例えばＬＡＮポートを備えている。ネットワークＩ／Ｆ２００Ｄは上述した通信ネットワークＮＷと接続される。
【００２１】
上述したＲＡＭ２００Ｂには、ＲＯＭ２００ＣやＨＤＤ２００Ｅに記憶されたプログラムがＣＰＵ２００Ａによって一時的に格納される。ＲＡＭ２００Ｂには、可搬型記録媒体７４０に記録されたプログラムがＣＰＵ２００Ａによって一時的に格納される。格納されたプログラムをＣＰＵ２００Ａが実行することにより、ＣＰＵ２００Ａは後述する各種の機能を実現し、また、後述する各種の処理を実行する。尚、プログラムは後述するフローチャートに応じたものとすればよい。
【００２２】
次に、図３から図６までを参照して、利用料決定システムＳＹＳの機能について説明する。
【００２３】
図３は利用料決定システムＳＹＳのブロック図の一例である。特に、図３では、利用者端末１００が備える制御装置１３０、並びにクラウドサービス提供システムＳＴに含まれるＡＰＩ管理サーバ２００、第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０の機能構成を表している。図４（ａ）は契約管理テーブルＴ１の一例である。図４（ｂ）はベース契約管理テーブルＴ２の一例である。図４（ｃ）は割引率管理テーブルＴ５の一例である。図４（ｄ）は利用料管理テーブルＴ６の一例である。図５はエラー情報管理テーブルＴ３の一例である。図６は影響度管理テーブルＴ４の一例である。尚、管理者端末３００については、基本的に、利用者端末１００と同様の機能構成であるため、説明を省略する。
【００２４】
まず、制御装置１３０について説明する。制御装置１３０は、図３に示すように、入力部１３１、表示部１３２、通信部１３３、及び制御部１３４を備えている。尚、入力部１３１、表示部１３２、通信部１３３は上述した入力Ｉ／Ｆ２００Ｆ、出力Ｉ／Ｆ２００Ｇ、ネットワークＩ／Ｆ２００Ｄによってそれぞれ実現することができる。制御部１３４は例えば上述したＣＰＵ２００Ａ及びＲＡＭ２００Ｂによって実現することができる。
【００２５】
入力部１３１は入力装置１１０から出力された情報を受け付ける。例えば、利用者が後述するメソッド、Uniform Resource Locator（ＵＲＬ、統一資源位置指定子）及びリクエストボディを指定して、クラウドサービス提供システムＳＴにＡＰＩを実行させる操作を入力装置１１０に対して行うと、入力部１３１は当該操作に応じた情報を入力装置１１０から受け付ける。表示部１３２は制御部１３４による制御に基づいて種々の内容を表示装置１２０に表示する。これにより、表示装置１２０は種々の内容を表示する。
【００２６】
制御部１３４は利用者端末１００の動作全体を制御する。例えば、制御部１３４は入力部１３１が受け付けた情報に基づいて、上述したリクエストメッセージを生成する。制御部１３４はリクエストメッセージを生成すると、生成したリクエストメッセージを通信部１３３に出力する。また、制御部１３４は通信部１３３から出力されたレスポンスメッセージに基づいて表示部１３２を制御する。通信部１３３は制御装置１３０とＡＰＩ管理サーバ２００との通信を制御する。例えば、通信部１３３は制御部１３４から出力されたリクエストメッセージをＡＰＩ管理サーバ２００に送信する。例えば、通信部１３３はＡＰＩ管理サーバ２００から送信されたレスポンスメッセージを受信して制御部１３４に出力する。
【００２７】
次に、ＡＰＩ管理サーバ２００について説明する。ＡＰＩ管理サーバ２００は、図３に示すように、通信部２０１と処理部２０２を備えている。尚、通信部２０１は上述したネットワークＩ／Ｆ２００Ｄによって実現することができる。処理部２０２は上述したＣＰＵ２００Ａ及びＲＡＭ２００Ｂによって実現することができる。
【００２８】
通信部２０１はＡＰＩ管理サーバ２００と利用者端末１００及び管理者端末３００との通信を制御する。また、通信部２０１はＡＰＩ管理サーバ２００と第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０との通信を制御する。具体的には、通信部２０１は利用者端末１００から送信されたリクエストメッセージを受信する。通信部２０１は受信したリクエストメッセージを第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０のいずれかに送信する。
【００２９】
通信部２０１は第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０から送信されたレスポンスメッセージを受信する。通信部２０１はレスポンスメッセージを利用者端末１００又は管理者端末３００に送信する。より詳しくは、通信部２０１はレスポンスメッセージに対応するリクエストメッセージが利用者端末１００から送信されている場合には、レスポンスメッセージを利用者端末１００に送信する。一方、通信部２０１はレスポンスメッセージに対応するリクエストメッセージが管理者端末３００から送信されている場合には、レスポンスメッセージを管理者端末３００に送信する。その他、通信部２０１は後述するエラー情報を第１サービス提供サーバ２１０に送信する。
【００３０】
処理部２０２は通信部２０１が受信したリクエストメッセージ及びレスポンスメッセージを解析する。処理部２０２は解析結果に応じて種々の処理を実行する。リクエストメッセージを解析した場合、処理部２０２はサービス依頼処理を実行する。詳細は後述するが、サービス依頼処理は解析結果に応じて第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０のいずれかを特定し、通信部２０１に対し、特定したいずれかにリクエストメッセージを送信させる処理である。一方、レスポンスメッセージを解析した場合、処理部２０２はレスポンスメッセージに含まれるステータスコードを特定する。
【００３１】
処理部２０２は特定したステータスコードが、クラウドサービス提供システムＳＴの利用者側に起因するエラーを表すエラーコード（具体的には４００番台）を除いた特定のエラーを表す特定のエラーコード（具体的には５００番台）を検出した場合、エラー情報を生成する。このエラー情報は特定のエラーコードを含むレスポンスメッセージに対応するリクエストメッセージに含まれるＡＰＩ名とその特定のエラーコードの組み合わせを含んでいる。すなわち、処理部２０２はクラウドサービス提供システムＳＴの提供者側に起因するエラーを表す特定のエラーコードを検出した場合、ＡＰＩ名とその特定のコードの組み合わせを含むエラー情報を生成する。処理部２０２はエラー情報を生成すると、生成したエラー情報を通信部２０１に出力する。上述したように、通信部２０１はエラー情報を受信した場合、受信したエラー情報を第１サービス提供サーバ２１０に送信する。したがって、処理部２０２はエラー情報を第１サービス提供サーバ２１０より管理する。
【００３２】
次に、第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０について説明する。図３に示すように、第１サービス提供サーバ２１０は、通信部２１１と課金サービス提供部２１２と第１記憶部２１３を備えている。第２サービス提供サーバ２２０は、通信部２２１とネットワークサービス提供部２２２と第２記憶部２２３を備えている。第３サービス提供サーバ２３０は、通信部２３１とコンピュートサービス提供部２３２と第３記憶部２３３を備えている。
【００３３】
尚、各通信部２１１，２２１，２３１はいずれも上述したネットワークＩ／Ｆ２００Ｄによって実現することができる。課金サービス提供部２１２、ネットワークサービス提供部２２２、及びコンピュートサービス提供部２３２は上述したＣＰＵ２００Ａ及びＲＡＭ２００Ｂによって実現することができる。第１記憶部２１３、第２記憶部２２３、第３記憶部２３３は上述したＨＤＤ２００Ｅによって実現することができる。
【００３４】
通信部２１１は第１サービス提供サーバ２１０とＡＰＩ管理サーバ２００との通信を制御する。同様に、通信部２２１は第２サービス提供サーバ２２０とＡＰＩ管理サーバ２００との通信を制御する。通信部２３１は第３サービス提供サーバ２３０とＡＰＩ管理サーバ２００との通信を制御する。例えば、通信部２１１，２２１，２３１は、いずれもＡＰＩ管理サーバ２００から送信されたリクエストメッセージを受信したり、レスポンスメッセージを送信したりする。例えば、通信部２１１は、ＡＰＩ管理サーバ２００から送信されたエラー情報を受信する。
【００３５】
課金サービス提供部２１２は課金や契約に関するＡＰＩをサービスとして提供する。より詳しくは、課金サービス提供部２１２はクラウドサービス提供システムＳＴが提供する各種ＡＰＩの呼び出しに課する利用料に関する情報を第１記憶部２１３により管理する。また、課金サービス提供部２１２はクラウドサービス提供システムＳＴの提供者と利用者との契約に関する契約情報を第１記憶部２１３により管理する。その他、課金サービス提供部２１２は通信部２１１がエラー情報を受信した場合、受信したエラー情報を第１記憶部２１３に格納する。課金サービス提供部２１２は通信部２１１がリクエストメッセージを受信した場合、受信したリクエストメッセージに含まれるリクエスト内容に応じた処理を実行する。
【００３６】
ここで、第１記憶部２１３は上述したエラー情報を含む各種の情報を記憶する。具体的には、図４（ａ）に示すように、第１記憶部２１３はクラウドサービス提供システムＳＴの提供者と利用者との契約に関する契約情報を記憶する。契約情報は契約管理テーブルＴ１によって管理される。また、図４（ｂ）に示すように、第１記憶部２１３は契約種別と固定月額料金との関係を定義したベース契約情報を記憶する。ベース契約情報はベース契約管理テーブルＴ２によって管理される。
【００３７】
また、図５に示すように、第１記憶部２１３はエラー情報を記憶する。エラー情報はエラー情報管理テーブルＴ３によって管理される。特に、エラー情報は、５００番台によって表される特定のエラーコード、そのエラーコードに応じたエラーメッセージ、リクエストメッセージに含まれるリクエスト内容によって定められるＡＰＩ名、エラー発生日時、契約ＩＤなどを構成要素として含んでいる。エラー情報の各々はエラーＩＤによって識別される。
【００３８】
さらに、図６に示すように、第１記憶部２１３は影響度情報を記憶する。影響度情報は影響度管理テーブルＴ４によって管理される。影響度情報は、ＡＰＩ名と、特定のエラーコードと、ＡＰＩ名と特定のエラーコードの組み合わせによって定義される影響度と、エラーメッセージを構成要素として含んでいる。尚、エラーメッセージについては構成要素から除外してもよい。影響度は特定のエラーコードに応じたエラーによって利用者が影響を受ける負担の度合を表している。
【００３９】
例えば、ＡＰＩ名に属するメソッド名「ｇｅｔ」はリソースを参照するメソッドであるため、エラーが発生しても利用者は上述した削除処理を行わなくても済むため、相対的に小さな度合が影響度に登録される。一方、メソッド名「ｃｒｅａｔｅ」はリソースを生成するメソッドであるため、エラーが発生した場合、利用者は上述した削除処理を行うことが求められるため、相対的に大きな度合が影響度として登録される。このような、影響度情報の各々は割引ＩＤによって識別される。
【００４０】
その他、図４（ｃ）に示すように、第１記憶部２１３は割引情報を記憶する。割引情報は割引前の利用料を割り引く際に適用する割引率に関する情報である。割引情報は割引率管理テーブルＴ５によって管理される。割引情報は影響度の合計値と割引率を構成要素として含んでいる。影響度の合計値と割引率との対応関係は予め定められている。例えば、影響度の合計値が相対的に大きい場合には、相対的に大きな割引率が登録される。逆に、影響度の合計値が相対的に小さい場合には、相対的に小さな割引率が登録される。
【００４１】
また、図４（ｄ）に示すように、第１記憶部２１３は利用料情報を記憶する。利用料情報は利用者に請求する利用料に関する情報である。利用料情報は利用料管理テーブルＴ６によって管理される。利用料情報の各々は月額ＩＤによって識別される。特に、割引前の利用料を表す割引前料金に割引率が適用された割引後料金が利用者に請求される。このように、エラー情報の数とエラー情報により利用者に生じる負担の影響度とに基づいて、利用者に請求する利用料が減額される。
【００４２】
尚、本実施形態では、第１記憶部２１３が種々の情報を記憶したが、契約情報については第１記憶部２１３と異なる別の記憶部（不図示）が記憶してもよい。また、契約情報やベース契約情報、影響度情報、割引情報は事前に第１記憶部２１３に記憶させておけばよい。一方、エラー情報や利用料情報は課金サービス提供部２１２によって動的に第１記憶部２１３に格納される。
【００４３】
図３に戻り、ネットワークサービス提供部２２２はネットワークに関する各種のＡＰＩをサービスとして提供する。より詳しくは、利用者がクラウドＣＬ内のネットワーク接続性やアドレス割り当てを定義できるＡＰＩをサービスとして提供する。例えば、ネットワークサービス提供部２２２は、通信部２２１が受信したリクエストメッセージに基づいて、ネットワーク、スイッチ、サブネット、ルータといった仮想ネットワーク基盤を生成して第２記憶部２２３により管理する。そして、ネットワークサービス提供部２２２は仮想ネットワーク基盤を、コンピュートサービス提供部２３２が管理するデバイス（例えばＣＰＵやメモリなど）に対して提供する。一方、コンピュートサービス提供部２３２は仮想マシンに関する各種のＡＰＩをサービスとして提供するとともに、第３記憶部２３３によりデバイスを管理する。例えば、コンピュートサービス提供部２３２はハイパーバイザーＡＰＩを使用して仮想マシンインスタンスを生成して終了する。
【００４４】
続いて、利用料決定システムＳＹＳの動作について説明する。
【００４５】
図７はＡＰＩ管理サーバ２００の動作の一例を示すフローチャートである。図８（ａ）はリクエストメッセージＲＱの一例である。図８（ｂ）はレスポンスメッセージＲＰの一例である。図９は第３サービス提供サーバ２３０の動作の一例を示すフローチャートである。ＡＰＩ管理サーバ２００はリクエストメッセージを受信する度に図７に示すフローチャートに従った処理を実行する。同様に、第３サービス提供サーバ２３０はリクエストメッセージを受信する度に図９に示すフローチャートに従った処理を実行する。尚、第１サービス提供サーバ２１０及び第２サービス提供サーバ２２０がリクエストメッセージを受信した場合も、リクエストメッセージを受信する度に、図９に示すフローチャートに従った処理を実行する。
【００４６】
まず、図７に示すように、ＡＰＩ管理サーバ２００の通信部２０１がリクエストメッセージＲＱを受信すると（ステップＳ１０１）、処理部２０２は通信部２０１が受信したリクエストメッセージＲＱを解析する（ステップＳ１０２）。具体的には、図８（ａ）に示すように、処理部２０２はリクエストメッセージＲＱの１行目であるリクエストラインを解析する。処理部２０２はリクエストメッセージＲＱの２行目から開始するリクエストヘッダやリクエストヘッダの後に続くリクエストボディを解析してもよい。
【００４７】
ステップＳ１０２の処理が完了すると、次いで、処理部２０２はサービス依頼処理を実行する（ステップＳ１０３）。ここで、上述したリクエストラインにはメソッド名（図８（ａ）においてcreate）とＵＲＬがリクエスト内容として含まれている。特に、ＵＲＬはサービス名（図８（ａ）においてcompute）とリソース名（図８（ａ）においてserver）を含んでいる。したがって、本実施形態では、処理部２０２はＵＲＬのサービス名に基づいて第３サービス提供サーバ２３０を特定し、通信部２０１に対し、第３サービス提供サーバ２３０にリクエストメッセージＲＱを送信させる。これにより、通信部２０１はリクエストメッセージＲＱを第３サービス提供サーバ２３０に送信する。尚、ＵＲＬのサービス名にnetworkが含まれている場合には、処理部２０２は第２サービス提供サーバ２２０を特定する。
【００４８】
図９に移り、通信部２３１がリクエストメッセージＲＱを受信すると、コンピュートサービス提供部２３２はリクエストメッセージＲＱのリクエストラインに記載されたメソッド名とＵＲＬのリソース名に応じた処理を実行する（ステップＳ２０１）。本実施形態では、メソッド名にcreateが記載され、ＵＲＬのリソース名にserverが記載されているため、コンピュートサービス提供部２３２は仮想サーバをリソースとして生成する。
【００４９】
ステップＳ２０１の処理が完了すると、コンピュートサービス提供部２３２は第３記憶部２３３を更新し（ステップＳ２０２）、レスポンスメッセージＲＰを生成する（ステップＳ２０３）。ステップＳ２０３の処理が完了すると、通信部２３１はレスポンスメッセージＲＰをＡＰＩ管理サーバ２００に送信する（ステップＳ２０４）。
【００５０】
図７に戻り、ＡＰＩ管理サーバ２００の通信部２０１はレスポンスメッセージＲＰを受信すると（ステップＳ１０４）、処理部２０２はレスポンスメッセージＲＰを解析する（ステップＳ１０５）。具体的には、図８（ｂ）に示すように、処理部２０２はレスポンスメッセージＲＰの１行目であるステータスラインを解析する。処理部２０２はレスポンスメッセージＲＰの２行目から開始するレスポンスヘッダやレスポンスヘッダの後に続くレスポンスボディを解析してもよい。
【００５１】
ここで、処理部２０２はステータスラインに含まれるステータスコードが２００番台であるか否かを判断する（ステップＳ１０６）。処理部２０２はステータスコードが２００番台であると判断した場合（ステップＳ１０６：ＹＥＳ）、後続のステップＳ１０７，Ｓ１０８の処理を実行せずに、通信部２０１はレスポンスメッセージＲＰを送信する（ステップＳ１０９）。すなわち、ステータスコードが２００番台である場合、コンピュートサービス提供部２４２が実行したステップＳ２０１の処理が成功したと処理部２０２は判断し、通信部２０１はレスポンスメッセージＲＰを利用者端末１００に送信する。
【００５２】
一方、処理部２０２はステータスコードが２００番台でないと判断した場合（ステップＳ１０６：ＮＯ）、次いで、ステータスコードが４００番台であるか否かを判断する（ステップＳ１０７）。処理部２０２はステータスコードが４００番台であると判断した場合（ステップＳ１０７：ＹＥＳ）、後続のステップＳ１０８の処理を実行せずに、通信部２０１はステップＳ１０９の処理を実行する。すなわち、ステータスコードが４００番台である場合、コンピュートサービス提供部２３２が実行したステップＳ２０１の処理にエラーが発生したが、そのエラーが利用者に起因すると処理部２０２は判断し、通信部２０１はレスポンスメッセージＲＰを利用者端末１００に送信する。
【００５３】
一方、処理部２０２はステータスコードが４００番台でないと判断した場合（ステップＳ１０７：ＮＯ）、エラー情報を管理する（ステップＳ１０８）。すなわち、処理部２０２はステータスコードが５００番台であると判断し、エラー情報を管理する。具体的には、処理部２０２はリクエストメッセージＲＱのリクエストラインに記載されたメソッド名とＵＲＬにそれぞれ含まれるサービス名とリソース名を取得してＡＰＩ名を生成する。また、処理部２０２はレスポンスメッセージＲＰのステータスラインに含まれるステータスコードと、レスポンスヘッダにエラー発生日時として含まれる日時と、レスポンスボディに含まれるエラーメッセージ及び契約ＩＤをレスポンス情報として取得する。そして、処理部２０２はＡＰＩ名とレスポンス情報とを含むエラー情報を生成し、エラー情報にエラーＩＤを付与して、通信部２０１に出力する。通信部２０１は処理部２０２から出力されたエラー情報を第１サービス提供サーバ２１０に送信する。すなわち、処理部２０２は第１サービス提供サーバ２１０によりエラー情報を管理する。
【００５４】
ステップＳ１０８の処理が完了すると、通信部２０１はステップＳ１０９の処理を実行する。すなわち、通信部２０１はレスポンスメッセージＲＰを利用者端末１００に送信する。これにより、利用者端末１００の制御装置１３０はレスポンスメッセージＲＰを受信する。
【００５５】
図１０はＡＰＩ管理サーバ２００の動作の他の一例を示すフローチャートである。ＡＰＩ管理サーバ２００は月末や利用料の請求期間の締日といった特定日に図１０に示すフローチャートに従った処理を実行する。尚、ＡＰＩ管理サーバ２００は第１サービス提供サーバ２１０に図１０に示すフローチャートに従った処理を実行させてもよい。
【００５６】
処理部２０２は、例えば上述した特定日をカレンダー機能により検出すると、図１０に示すように、ループ処理を開始する（ステップＳ３０１）。処理部２０２がループ処理を開始すると、後続の処理を契約数分に渡って実行する。ループ処理を開始すると、まず、処理部２０２はいずれかの契約ＩＤを特定し、ＳＬＡ保証対象日とエラー発生日を比較する（ステップＳ３０２）。より詳しくは、処理部２０２は第１記憶部２１３が記憶するエラーコードの中から、特定した契約ＩＤに対応する複数種類のエラーコードを抽出し、抽出したエラーコードを種類に関係なく日毎に計数する。この結果、日々のエラー情報の発生数がエラーコードの種類に関係なく特定される。そして、処理部２０２は計数した値が閾値以上になるエラー発生頻発日を検出した場合、エラー発生頻発日とＳＬＡ保証対象日とを比較する。
【００５７】
ステップＳ３０２の処理が完了すると、処理部２０２は割引適用対象外のエラー情報を特定する（ステップＳ３０３）。例えば、処理部２０２はエラー発生頻発日とＳＬＡ保証対象日とを比較した結果、エラー発生頻発日がＳＬＡ保証対象日に対応する場合には、エラー発生頻発日のエラー情報を割引適用対象外のエラー情報として特定する。これにより、割引の二重適用が回避される。割引適用対象外のエラー情報については、処理部２０２は後続の処理対象から除外する。
【００５８】
ステップＳ３０３の処理が完了すると、次いで、処理部２０２は影響度を特定する（ステップＳ３０４）。より詳しくは、処理部２０２は割引適用対象外のエラー情報を除いた残りのエラー情報のそれぞれについてＡＰＩ名とエラーコードの組み合わせに応じた影響度を特定する。尚、処理部２０２は影響度を特定する際、第１記憶部２１３が記憶する影響度情報（図６参照）を参照すればよい。
【００５９】
ステップＳ３０４の処理が完了すると、次いで、処理部２０２は特定した影響度の合計値を算出し（ステップＳ３０５）、算出した合計値に応じた割引率を決定する（ステップＳ３０６）。処理部２０２は合計値を算出する際、エラー情報のエラー数を利用する。例えば、エラーコードとＡＰＩ名の組み合わせが共通するエラー情報が３つある場合、その組み合わせに対応付けられた影響度を３倍すればよい。そして、処理部２０２は３倍した影響度を他の組み合わせに対応付けられた影響度と足し合わせて合計値を算出してもよい。また、処理部２０２は割引率を決定する際、第１記憶部２１３が記憶する割引情報（図４（ｃ）参照）を参照すればよい。
【００６０】
ステップＳ３０６の処理が完了すると、処理部２０２は割引前料金を算出する（ステップＳ３０７）。より詳しくは、処理部２０２は、まず、第１記憶部２１３が記憶する契約情報（図４（ａ）参照）とベース契約情報（図４（ｂ）参照）を参照して、特定した契約ＩＤに応じた固定月額料金を特定する。次に、処理部２０２は、ＡＰＩの呼び出し回数やクラウドサービス提供システムＳＴの利用時間に応じた従量課金を特定する。尚、ＡＰＩの呼び出し回数や利用時間については処理部２０２が第１記憶部２１３により管理しておけばよい。そして、処理部２０２は特定した固定月額料金と従量課金を合計した割引前料金を算出する。
【００６１】
ステップＳ３０７の処理が完了すると、処理部２０２は割引後料金を算出する（ステップＳ３０８）。より詳しくは、処理部２０２はステップＳ３０７の処理で算出した割引前料金にステップＳ３０６の処理で決定した割引率を適用して割引後料金を算出する。処理部２０２は割引後料金を算出すると、割引後料金などを含む利用料情報（図４（ｄ）参照）を第１記憶部２１３に格納する。処理部２０２は利用料情報を格納すると、特定した契約ＩＤと異なる別の契約ＩＤを特定して、ステップＳ３０２からＳ３０８の処理を繰り返す。処理部２０２は全ての契約ＩＤについて利用料情報を格納すると、ループ処理を終了し（ステップＳ３０９）、利用料の課金処理を終了する。
【００６２】
図１１は課金管理画面の一例である。管理者端末３００はクラウドサービス提供システムＳＴを管理する管理者による操作に基づいて、課金管理画面を表示する。例えば、管理者が課金管理画面を表示させる操作を管理者端末３００に対し行うと、管理者端末３００は当該操作に応じたリクエストメッセージＲＱをＡＰＩ管理サーバ２００に送信する。ＡＰＩ管理サーバ２００の通信部２０１は管理者端末３００から送信されたリクエストメッセージＲＱを受信すると、処理部２０２はリクエストラインを解析する。本実施形態では、解析の結果、通信部２０１はリクエストメッセージＲＱを第１サービス提供サーバ２１０に送信する。
【００６３】
第１サービス提供サーバ２１０の通信部２１１がリクエストメッセージＲＱを受信すると、課金サービス提供部２１２はリクエストメッセージＲＱのリクエストラインに記載されたリクエスト内容に応じた処理を実行する。例えば、リクエストラインのメソッド名としてgetが記載されていれば、課金サービス提供部２１２は利用料情報などを第１記憶部２１３から取得し、通信部２１１は課金サービス提供部２１２が取得した利用料情報などを含むレスポンスメッセージＲＰをＡＰＩ管理サーバ２００に送信する。
【００６４】
ＡＰＩ管理サーバ２００の通信部２０１は第１サービス提供サーバ２１０から送信されたレスポンスメッセージＲＰを受信する。通信部２０１がレスポンスメッセージＲＰを受信すると、処理部２０２はステータスラインを解析する。解析の結果、ステータスラインに２００番台のステータスコードが含まれていれば、通信部２０１はレスポンスメッセージＲＰを管理者端末３００に送信する。これにより、管理者端末３００は利用料情報などを含む課金管理画面を表示する。尚、図１１に示すように、管理者が請求対象年月を入力して、ポインタＰＴにより実行ボタンＢＴを押下する操作を行うと、以上説明した処理と同様の処理が行われ、管理者端末３００は請求対象年月に応じた利用料情報などを含む課金管理画面を表示する。
【００６５】
以上、本実施形態によれば、ＡＰＩ管理サーバ２００は処理部２０２を備えている。処理部２０２はクラウドサービス提供システムＳＴを利用する利用者の利用者端末１００から送信されたリクエストメッセージＲＱに対するレスポンスメッセージＲＰを解析する。処理部２０２はレスポンスメッセージＲＰを解析した結果、レスポンスメッセージＲＰからクラウドサービス提供システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、特定のエラーを含むレスポンスメッセージＲＰに応じたリクエストメッセージＲＱに含まれるリクエスト内容と特定のエラーの組み合わせを管理する。処理部２０２はこの組み合わせに基づいて、特定のエラーにより利用者が影響を受ける負担の度合を表す影響度を特定し、特定のエラーのエラー数と影響度とに応じて、クラウドサービス提供システムＳＴの利用料を決定する。これにより、システムの利用者側に起因するエラーを除外した利用料を決定することができる。結果的に、一時的なエラーがクラウドサービス提供システムＳＴの利用者側に起因しない場合であっても、クラウドサービス提供システムＳＴの提供者は利用者からＳＬＡとは別に利用料の減額を求められずに済む。
【００６６】
以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。例えば、上述した実施形態では、一例としてエラーコードを利用したが、エラーコードとエラーメッセージは対応しているため、エラーコードに代えてエラーメッセージを利用してもよい。
【００６７】
また、上述した実施形態では、第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０をクラウドサービス提供システムＳＴの構成要素としたが、第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０の少なくとも１つをクラウドサービス提供システムＳＴの構成要素から除外してもよい。この場合、第１サービス提供サーバ２１０、第２サービス提供サーバ２２０、及び第３サービス提供サーバ２３０の少なくとも１つを通信ネットワークＮＷに接続してもよい。
【００６８】
さらに、上述した実施形態では、ＡＰＩの形式の一例としてＲＥＳＴ形式を説明したが、ＲＥＳＴ形式とは異なる別の形式を利用してもよい。例えば、利用者端末１００とＡＰＩ管理サーバ２００との間では別の形式のＡＰＩを利用し、ＡＰＩ管理サーバ２００と第１サービス提供サーバ２１０との間ではＲＥＳＴ形式のＡＰＩを利用してもよい。この場合、ＡＰＩ管理サーバ２００はＡＰＩの形式変換を実行する。
【００６９】
さらに、上述した実施形態では、リクエストラインやリクエストヘッダなどとの混同を避けるために、リクエストメッセージという記載を利用したが、リクエストメッセージについては単にリクエストと言い換えてもよい。レスポンスメッセージについてもリクエストメッセージと同様である。
【００７０】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１）システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、処理をコンピュータに実行させる利用料決定プログラム。
（付記２）前記処理は、前記影響度の合計値を前記エラー数に基づいて算出し、予め定めた対応表に基づいて、算出した前記合計値に応じた割引率を決定し、決定した前記割引率と前記システムの割引前の利用料とに基づいて、前記システムの利用料を決定する、ことを特徴とする付記１に記載の利用料決定プログラム。
（付記３）前記処理は、前記エラー数を日毎に計数し、計数した値が閾値以上になるエラー頻発日を検出した場合、前記エラー頻発日と前記システムが提供するサービスの品質を保証する対象日とを比較し、前記エラー頻発日が前記対象日に対応する場合、前記割引率の前記システムの割引前の利用料への適用を除外する、ことを特徴とする付記２に記載の利用料決定プログラム。
（付記４）前記リクエスト内容は、前記システムが提供するサービスの名称とＡＰＩで利用されるメソッドの名称及びリソースの名称との組み合わせである、ことを特徴とする付記１から３のいずれか１項に記載の利用料決定プログラム。
（付記５）システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、処理をコンピュータが実行する利用料決定方法。
（付記６）システムを利用する利用者の端末から送信されたリクエストに対するレスポンスを解析し、前記レスポンスを解析した結果、前記レスポンスから前記システムの利用者側に起因するエラーを除いた特定のエラーを検出した場合、前記特定のエラーを含むレスポンスに応じたリクエストに含まれるリクエスト内容と前記特定のエラーの組み合わせを管理し、前記組み合わせに基づいて、前記特定のエラーにより前記利用者が影響を受ける負担の度合を表す影響度を特定し、前記特定のエラーのエラー数と前記影響度とに応じて、前記システムの利用料を決定する、処理を実行する処理部を有することを特徴とする情報処理装置。
（付記７）前記処理部は、前記影響度の合計値を前記エラー数に基づいて算出し、予め定めた対応表に基づいて、算出した前記合計値に応じた割引率を決定し、決定した前記割引率と前記システムの割引前の利用料とに基づいて、前記システムの利用料を決定する、ことを特徴とする付記６に記載の情報処理装置。
（付記８）前記処理部は、前記エラー数を日毎に計数し、計数した値が閾値以上になるエラー頻発日を検出した場合、前記エラー頻発日と前記システムが提供するサービスの品質を保証する対象日とを比較し、前記エラー頻発日が前記対象日に対応する場合、前記割引率の前記システムの割引前の利用料への適用を除外する、ことを特徴とする付記７に記載の情報処理装置。
（付記９）前記リクエスト内容は、前記システムが提供するサービスの名称とＡＰＩで利用されるメソッドの名称及びリソースの名称との組み合わせである、ことを特徴とする付記６から８のいずれか１項に記載の情報処理装置。
【符号の説明】
【００７１】
ＳＹＳ  利用料決定システム
ＳＴ  クラウドサービス提供システム
１００  利用者端末
２００  ＡＰＩ管理サーバ
２０１  通信部
２０２  処理部
３００  管理者端末
【図１】
2019160130.tif 000003
【図２】
2019160130.tif 000004
【図３】
2019160130.tif 000005
【図４】
2019160130.tif 000006
【図５】
2019160130.tif 000007
【図６】
2019160130.tif 000008
【図７】
2019160130.tif 000009
【図８】
2019160130.tif 000010
【図９】
2019160130.tif 000011
【図１０】
2019160130.tif 000012
【図１１】
2019160130.tif 000013