特許 7508618 クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-21

(45)【発行日】2024-07-01

(54)【発明の名称】クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムおよび方法

(51)【国際特許分類】

   G06Q 10/04 20230101AFI20240624BHJP

【ＦＩ】

G06Q10/04

【請求項の数】 4

(21)【出願番号】P 2023033266

(22)【出願日】2023-03-04

(62)【分割の表示】P 2020556281の分割

【原出願日】2019-04-16

(65)【公開番号】P2023065623

(43)【公開日】2023-05-12

【審査請求日】2023-03-07

(31)【優先権主張番号】15/954,238

(32)【優先日】2018-04-16

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】322000096

【氏名又は名称】クラウドブルー エルエルシー

(74)【代理人】

【識別番号】100138760

【弁理士】

【氏名又は名称】森 智香子

(72)【発明者】

【氏名】クスキン，マキシム

(72)【発明者】

【氏名】ザットセイン，ウラジーミル

(72)【発明者】

【氏名】ホドス，パベル

(72)【発明者】

【氏名】メルニコフ，オレグ

(72)【発明者】

【氏名】グレベンシュチコフ，ウラジーミル

(72)【発明者】

【氏名】ボロトフ，アンドレイ

(72)【発明者】

【氏名】ウリツキー，セルゲイ

(72)【発明者】

【氏名】アヴァーチク，グレブ

(72)【発明者】

【氏名】コレスニコフ，ヒョードル

(72)【発明者】

【氏名】リクタンスキー，エヴゲーニー

【審査官】星野 裕

(56)【参考文献】

【文献】特開２０１４－０２６５３７（ＪＰ，Ａ）

【文献】特開２００９－２２３７５５（ＪＰ，Ａ）

【文献】特表２００８－５３７８１８（ＪＰ，Ａ）

【文献】米国特許出願公開第２００３／０１８７７９４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／００１９６３６（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０２３６２１８（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

独立ソフトウェアベンダー（ＩＳＶ）格付けエンジンにおいて、売上コスト計算機から新しい見積もり要求を受信するステップと、
前記独立ソフトウェアベンダー格付けエンジンにおいて、前記新しい見積もり要求の終了日を識別するステップと、
前記独立ソフトウェアベンダー格付けエンジンにおいて、前記終了日および最も近い未来の請求日を比較するステップであって、前記最も近い未来の請求日は、サービスベンダーとクラウドサービスブローカプラットフォームとの間の契約に少なくとも部分的に基づくステップと、
前記独立ソフトウェアベンダー格付けエンジンにおいて、独立ソフトウェアベンダーカタログに複数の価格ルールを要求するステップであって、前記複数の価格ルールは、前記新しい見積もり要求の好ましい請求期間および請求日を含むステップと、
前記クラウドサービスブローカプラットフォームにおいて、前記新しい見積もり要求の終了日の後に続く前記請求日に関して少なくとも１つの料金を作成するステップと、
前記クラウドサービスブローカプラットフォームにおいて、前記新しい見積もり要求の前記終了日に続く請求日を含む次の請求日を割り当てるステップとを含む、
クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法。

【請求項2】

前記新しい見積もり要求のための料金を、前記クラウドサービスブローカプラットフォーム内のデータベースに送信する前記ステップをさらに含む、請求項１に記載の方法。

【請求項3】

前記少なくとも１つの料金は、条件付き価格形成および最新価格形成をさらに含む、請求項１に記載の方法。

【請求項4】

前記条件付き価格形成は、価格設定条件のための少なくとも１つの請求ルールを含む、請求項３に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本実用特許出願は、２０１８年４月１６日に出願された米国特許出願第１５／９５４，２３８号の優先権を主張し、その出願は参照として本明細書に組み込まれる。

【0002】

本開示は、請求のシステムおよび方法、より詳細には、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムおよび方法に関する。

【背景技術】

【0003】

現在、多くのソフトウェアベンダーが、オンラインサービスプラットフォームを介して自身のソフトウェアを提供する。このようなソフトウェアアズアサービス（ＳａａＳ）プラットフォームにより、ＳａａＳ登録者／エンドユーザは、ＳａａＳプロバイダによってホストされるソフトウェアサービスを取得して使用することができる。ＳａａＳは、「オンデマンドソフトウェア」とも呼ばれるが、通常は、ペイ・パー・ユースでまたはサブスクリプション料を用いて価格設定される。例えば、ＳａａＳ登録者は、一定期間（例えば、１ヶ月間）、ＳａａＳプラットフォームにアクセスするために、月次（または年次）のサブスクリプション料をＳａａＳベンダーに支払うことができる。逆に、ペイ・パー・ユースの料金体系では、ＳａａＳ登録者は、所与の期間内の登録者のＳａａＳプラットフォームの利用状況に基づいてＳａａＳプロバイダに支払いを行う。例えば、登録者は、利用状況当たりの料金に基づいて請求され得るが、利用状況は、ＳａａＳプラットフォーム内の１つ以上のリソースに基づいて測定される。これらの「登録者－ベンダー」体系では、登録者とＳａａＳベンダーとの間の請求は、１対１の関係であり、ＳａａＳベンダーのコストが登録者に直接移され、これにより、登録者はＳａａＳプラットフォームへの継続的なアクセスを保証するために支払うことになる。

【0004】

ソフトウェアサービス配信の代替システムでは、クラウドサービスブローカが使用される。クラウドサービスブローカは、登録者／エンドユーザとＳａａＳベンダーとの間の仲介として機能する機関である。クラウドサービスブローカは、（様々なＳａａＳベンダーから入手可能な）異なるソフトウェアサービスを統合して、統合サービスセット（すなわち、クラウドサービスパッケージ）を登録者に提示し得る。いくつかの場合において、クラウドサービスブローカはまた、ソフトウェアサービスをホストして従来のＳａａＳベンダーの代わりに動作することもある。付加的に、クラウドサービスブローカは、異なるレベルの様々なＳａａＳベンダーへのサブスクリプションのプロビジョニングおよび販売を可能にするので、その結果、下流の再販売業者の階層システムをもたらす。これらの再販売業者は以降、下位の再販売業者およびエンドユーザにサービスを再販することができる。いくつかの場合において、これらの再販売業者は、ＳａａＳベンダーおよび／またはクラウドブローカと比較して異なる価格設定体系でＳａａＳ提供物の価格を決め得る。

【0005】

クラウドサービスブローカは、このようなソフトウェア配信システムにおいて多くの関係を管理することができる唯一のエンティティなので、クラウドサービスブローカシステムにおける請求は、クラウドサービスブローカを通じて管理される。しかしながら、収益の整合および決済は、問題となり得る。例えば、クラウドブローカシステムにおける請求の複雑さは、ＳａａＳベンダーのタイプの混在、再販売業者の影響、およびこれらのエンティティの各々によって提供される様々な請求体系に起因して生じる。例えば、クラウドサービスパッケージは、複数のＳａａＳベンダーからの複数のソフトウェアサービスを含み得る。クラウドサービスパッケージ内のこれらの複数のソフトウェアサービスの各々は、様々な請求体系を含み得る（例えば、利用状況ベースのおよびサブスクリプションベースの体系の組み合わせ、および各々が変動するインセンティブおよび請求属性を有する）。さらに、下流の再販売業者は、クラウドサービスパッケージのために自身の一意の価格設定体系を提供し得る。

【0006】

登録者エンドユーザが、クラウドサービスブローカまたは下流の再販売業者からソフトウェアサービスを取得するとき、これらの登録者エンドユーザへの請求は、従来の「登録者－ベンダー」体系におけるような１対１の関係ではない。代わりに、クラウドサービスブローカ体系における登録者エンドユーザは、クラウドサービス仲介配信チャネルの階層内の異なる価格設定に基づいて請求され得る。したがって、このような請求体系の実施は、階層全体のエンティティ（すなわち、ＳａａＳベンダー、再販売業者、下位再販売業者など）からの請求ルールおよび請求体系におけるばらつきを考慮しなければならない。さらに、上流のエンティティ（例えば、ＳａａＳベンダー）および下流のエンティティ（例えば、再販売業者）からの請求ルール間には相違が存在し得るが、１つの特定のエンティティの請求体系に基づいて登録者エンドユーザに課される請求は、不適切である。例えば、固定の値上げおよび割引は、上流のエンティティ（例えば、ＳａａＳベンダー）によって適用され得るが、値上げおよび割引は、下流のエンティティ（例えば、再販売業者のエンドユーザ）にとっては適切でない場合がある。同様に、ソフトウェア配信システムの各レベルで同じ請求ルールが適用される場合、ソフトウェアサービス配信の柔軟性のない契約およびルールをもたらすことになる。付加的に、配信チャネル内の特定のタイプのエンティティに基づいて、価格設定（および対応する請求ルール）をカスタマイズすることはできない。例えば、直接的な登録者エンドユーザは、間接的な登録者エンドユーザとは異なる方法で請求され得る。これにより、ソフトウェア配信システムの異なる要素にわたって収益の損失が生じる。最後に、異なる請求ルールに従って配信されるサービスの大量購入を実行することもできず、より大規模なサービス配信業者の機会の喪失にもつながる。

【0007】

したがって、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための改善されたシステムおよび方法に対する必要性が存在する。

【発明の概要】

【課題を解決するための手段】

【0008】

本開示の少なくとも１つの実施形態においては、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムが提供される。システムは、サービスベンダー、クラウドブローカ、第１再販売業者、第２再販売業者および第３再販売業者などの異なる階層レベルの再販売業者を含む。システムは、最終顧客をさらに含み、最終顧客は、サービスベンダーから直接、または再販売業者を介して間接的にサービスを受け取り得る。

【0009】

本開示の少なくとも１つの実施形態においては、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムは、マーケットプレイス、サービスプロバイダデータベース（ベンダー契約カタログ）、パートナーデータベース、マーケットプレイスブローカ、任意の連携コネクタ、トランザクションメディエータ、利用状況データベース、プロビジョニングデータベース、コネクタ、スケジューラおよびネットワークを含む。

【0010】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカは、システム内の様々なエンティティ間で確立された契約を管理するように構成される。

【0011】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカは、利用可能なサービスのカタログを記憶するように構成され、コネクタの請求利用状況を監視するように構成され、連携コネクタを（任意で）含む。

【0012】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカは、マーケットプレイスを介してパートナーにサービスを販売するように構成される。

【0013】

本開示の少なくとも１つの実施形態においては、マーケットプレイスは、システムを経由するすべてのトランザクションについての請求情報を記憶するように構成されたトランザクションメディエータをさらに含む。マーケットプレイスは、システムを経由するすべてのトランザクションについての調整固有の詳細を記憶するようにさらに構成される。

【0014】

本開示の少なくとも１つの実施形態においては、クラウドブローカは、パートナーによって稼働され得るが、パートナーは、サービスベンダーのサービスを登録者に提供するように動作する。

【0015】

本開示の少なくとも１つの実施形態においては、クラウドブローカはまた、再販売業者および下位の再販売業者の階層を維持するようにも構成される。

【0016】

本開示の少なくとも１つの実施形態においては、クラウドブローカおよびマーケットプレイスブローカは、単一のエンティティとして動作し得る。

【0017】

本開示の少なくとも１つの実施形態においては、クラウドサービスブローカプラットフォームにおいて収益およびコストの流れを整合させるための方法が提供される。方法は、請求期間にわたって適用されるようなトランザクションの判断と、トランザクションの開始と、登録者の請求サイクルのトランザクション属性に基づく更新または開始と、請求期間のコストの計算と、サービスベンダーとクラウドブローカとの間の契約の判断と、各期間のブローカの売上コストの計算とを含む。

【0018】

本開示の少なくとも１つの実施形態においては、方法は、各サービスベンダーの契約およびサブスクリプションの記録の保持と、特定の請求期間中の個別のサービスコストの各々の計算とを含む。

【0019】

本開示の少なくとも１つの実施形態においては、方法は、サービスベンダーの各々におけるコストの計算と、クラウドブローカにおけるサービスコストの計算と、再販売業者におけるコストの計算と、最終顧客のための統合請求書の作成とを含む。

【0020】

本開示の少なくとも１つの実施形態においては、コストは、サービスベンダー、クラウドブローカ、再販売業者の各々に関して計算され、統合請求書は、最終顧客に関して作成される。

【0021】

本開示の少なくとも１つの実施形態においては、方法は、トランザクションメディエータへのプロビジョニング動作の属性の報告と、サービス利用状況データベースへのデータの記憶と、サービスベンダーとの調整のためのサービス利用状況レポートの要求と、サービスベンダーの請求ルールの受信と、サービスの総利用状況の計算と、連携コネクタへのレポートの送信と、マーケットプレイスブローカへのレポートの送信と、サービスベンダーとの調整のための利用状況レポートを作成するためのサービスベンダーの価格設定モデルの適用と、パートナー請求のためのサービス利用状況レポートの要求と、パートナーのサブスクリプションからの請求ルールの受信と、サービスの総利用状況の計算と、連携コネクタへのレポートの送信と、マーケットプレイスブローカへのレポートの送信と、パートナーからの価格設定モデルの適用と、パートナーへの請求とを含む。

【0022】

本開示の少なくとも１つの実施形態においては、方法は、トランザクションメディエータへのプロビジョニング動作の属性の報告と、サービス利用状況データベースへのデータの記憶と、サービスＳＫＵ当たりの売上コストの見積もりの開始と、サービスベンダーの請求ルールの実行と、サービスＳＫＵ当たりの売上コストの計算と、ＥＲＰシステムへのサービスＳＫＵ当たりの売上コストの報告とをさらに含む。

【図面の簡単な説明】

【0023】

【図1】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの概略図である。

【0024】

【図1A】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの概略図である。

【0025】

【図1B】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの概略図である。

【0026】

【図2】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの概略図である。

【0027】

【図2A】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素である。

【0028】

【図2B】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素である。

【0029】

【図2C】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素である。

【0030】

【図3】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素である。

【0031】

【図4】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素である。

【0032】

【図5】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素である。

【0033】

【図6】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0034】

【図7A】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの概略図である。

【0035】

【図7B】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの概略図である。

【0036】

【図8】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの構成要素を示す図である。

【0037】

【図9】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムの構成要素を示す図である。

【0038】

【図10】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0039】

【図10A】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0040】

【図10B】クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0041】

【図10C】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0042】

【図11】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0043】

【図12】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【0044】

【図13】一実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法を示す図である。

【発明を実施するための形態】

【0045】

開示する実施形態の詳細な説明
ここで本開示の好ましい実施形態を詳細に参照して、これらの実施例が添付図面に図示される。本開示の付加的な特徴および利点は、以下の説明に記載されており、説明から明らかにされ得るかまたは本開示の実践によって学ばれ得る。上記の一般的な説明および以下の詳細な説明は例示および解説であり、本開示のさらなる説明を請求通りに提供することを意図する。

【0046】

ここで図１を参照すると、クラウドサービスブローカを介したクラウドサービス配信のためのシステムが示され、概して１００に示す。システム１００は、サービスベンダー１０２、クラウドブローカ１０４、第１再販売業者１０６、第２再販売業者１０８、第３再販売業者１１０および最終顧客１１２を含む。

【0047】

本開示の少なくとも１つの実施形態においては、サービスベンダー１０２は、サービスのサブスクリプションを自身のクライアント（例えば、異なるサイズの企業または顧客）に提供するエンティティである。明確にするために、サービスベンダー１０２は、「サービスプロバイダ」とも呼ばれ得るが、両方の語は同義的に使用され得ることは理解されたい。付加的に、サービスベンダー１０２は、独立したソフトウェアベンダーのホスティングサーバ（図示せず）上に位置付けられたアプリケーションおよびサービスへのサブスクリプションを提供することができる。サービスベンダー１０２は、顧客によって加入されたサービスをさらにホストすることができる。サービスベンダー１０２は、サービスを（通常は自身のクラウドインフラ上で）開発、サポート、および実行するソフトウェア開発会社であり得る。サービスベンダー１０２はまた、自身のサービスへのサブスクリプションを販売して提供する。サービスベンダー１０２は、自身のサービスの各々のためのアプリケーションプログラミングインタフェース（ＡＰＩ）を提供することが理解されるであろう。ＡＰＩは、外部アプリケーションで使用するためにサービスベンダー１０２によって提供されるクラス、プロシージャ、関数、構造および定数のセットを含み得る。サービスベンダー１０２は、例えば、Ｄｒｏｐｂｏｘ（登録商標）、Ａｍａｚｏｎ（登録商標）ウェブサービスおよびＯｆｆｉｃｅ３６５（登録商標）などの複数のサービスベンダー（例えば、サービスベンダー１０２ａ、１０２ｂおよび１０２ｃ）を含み得る。複数のサービスベンダー１０２の各々は、いくつかの非限定的な例を挙げると、電子メール、ウェブホスティング、ファイル共有および記憶、ネットワーク、電話、メッセージング、テレビ会議、一般通信、企業資源計画（ＥＲＰ）、顧客関係管理（ＣＲＭ）、サプライチェーン管理などの様々なソフトウェアサービスを提供する。サービスベンダー１０２は、自身のサービスを再販売業者にまたは最終顧客に直接、提供し得ることが理解されるであろう。

【0048】

本開示の少なくとも１つの実施形態においては、サービスベンダー１０２は、再販売業者および最終顧客による自身のサービスの利用状況を監視するように構成される。例えば、サービスベンダー１０２ａ（Ｏｆｆｉｃｅ３６５（登録商標））は、登録者のサービスベンダー１０２ａのサービスの使用によって生じる計算リソース利用状況を監視するように構成され得る。計算リソースは、いくつかの非限定的な例を挙げると、時間ごとベースで使用される１つ以上の計算リソース、１回以上の読出しおよび書込みＩ／Ｏ動作、ならびにネットワーク帯域幅利用状況からなるグループから選択された少なくとも１つの測定されたメトリックを含むことができる。利用状況の測定は、アプリケーションプログラミングインタフェース（ＡＰＩ）の１つ以上で実行することができることがさらに理解されるであろう。このような監視から取得されたメトリックは、サービスベンダー１０２の環境内に記憶され得るか、またはシステム１００内の他のエンティティに、例えばインターネット経由などで送信可能であることも理解されるであろう。

【0049】

サービスベンダー１０２は、自身の請求ルールを適用するように構成され得ることが理解されるであろう。例えば、サービスベンダー１０２ｂ（例えば、Ａｍａｚｏｎ（登録商標）ウェブサービス）は、定額の月次価格設定構造を適用し得るが、サービスベンダー１０２ｃ（例えば、Ｄｒｏｐｂｏｘ（登録商標））は、計算リソースの利用状況に比例した料金を適用し得る。サービスベンダー１０２は、システム１００内の他のエンティティに請求ルールを送信し得ることがさらに理解されるであろう。

【0050】

本開示の少なくとも１つの実施形態においては、システム１００は、クラウドブローカ１０４をさらに含む。クラウドブローカ１０４は、（例えば、サービスベンダー１０２からの）異なるソフトウェアサービスをＡＰＩを介して統合して、サービスベンダー１０２のサービスへのサブスクリプションを様々な他のエンティティ（例えば、再販売業者および最終顧客）にプロビジョニング、および販売する機能を提供するエンティティである。クラウドブローカ１０４は、異なるタイプのサービスベンダー１０２のためのユーザインタフェースを提供することが理解されるであろう。例えば、通信サービス（例えば、電子メール）を提供するサービスベンダーは、ホスティングまたは記憶サービスベンダー（例えば、Ｄｒｏｐｂｏｘ）とは異なるインタフェースを有することになる。異なるインタフェースのプロビジョニングは、本明細書にさらに開示するように再販売業者の階層システムをサポートすることがさらに理解されるであろう。

【0051】

本開示の少なくとも１つの実施形態においては、システム１００は、異なる階層レベルの再販売業者をさらに含む。例えば、第１再販売業者１０６は、地理的ベースの再販売業者（例えば、第１再販売業者１０６ａは米国でサービス提供し、第１再販売業者１０６ｂはフランスでサービス提供し、および第１再販売業者１０６ｃはブラジルでサービス提供する）。システム１００は、第２再販売業者１０８および第３再販売業者１１０などの下流の再販売業者をさらに含み得る。再販売業者は、いくつかの非限定的な例を挙げると、地理的分布、産業業界、消費者業界、または技術業界などのいずれかの因子に基づいて編成され得る。いくつかの選ばれた数の再販売業者および下流再販売業者しか示されていないが、システム１００は、当該技術で周知のタイプのソフトウェアおよびハードウェアシステム（例えば、インターネット）によって接続されたあらゆる数の再販売業者および下流再販売業者を含み得るが、これらのシステムは、本開示により再販売業者に委任される機能を実行するように共に動作可能であることが理解されるであろう。

【0052】

本開示の少なくとも1つの実施形態においては、システム１００は、最終顧客１１２をさらに含む。最終顧客１１２は、サービスベンダー１０２によって提供されるサービス（またはサービスベンダー１０２に少なくとも由来し得るサービス）に加入する個人または企業組織を含み得る。最終顧客は、サービスベンダー１０２から直接、または再販売業者を介して間接的にサービスを受け取り得ることが理解されるであろう。例えば、図１を参照すると、最終顧客１１２ａは、第２再販売業者１０８ａからサービスを受け取り得るが、第２再販売業者１０８ａは、第１再販売業者１０６ａの下流再販売業者である。同様に、最終顧客１１２ｂは、第３再販売業者１１０ｂからサービスを受け取り得るが、第３再販売業者１１０ｂは、第２再販売業者１０８ｂの下流再販売業者であり、さらに第２再販売業者１０８ｂは、第１再販売業者１０６ａの下流再販売業者である。再販売業者の各々は、自身の請求および価格設定体系を使用するように構成されるので、最終顧客１１２の各々は、サービスベンダー１０２からの同じサービスに加入していても、異なる価格および請求条件を受け取り得ることが理解されるであろう。

【0053】

ここで図１Ａを参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムが示され、概して１２０に示す。システム１２０は、マーケットプレイス１２２、サービスプロバイダデータベース１２４、パートナーデータベース１２６、マーケットプレイスブローカ１２８、連携コネクタ１３０、トランザクションメディエータ１３２、利用状況データベース１３４、プロビジョニングデータベース１３６、コネクタ１３８、スケジューラ１４０およびネットワーク１４２を含む。

【0054】

本開示の少なくとも１つの実施形態においては、サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６は、システム１２０によって生成されたおよび／または１つ以上の情報源から読み出された情報を記憶する。本開示の少なくとも１つの実施形態においては、図１Ａの実施形態に示すように、サービスプロバイダデータベース１２４およびパートナーデータベース１２６は、マーケットプレイスブローカ１２８と「関連付ける」ことができ、利用状況データベース１３４およびプロビジョニングデータベース１３６は、トランザクションメディエータ１３２と「関連付ける」ことができる。サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々はまた、マーケットプレイス１２２から遠隔のサーバまたはコンピューティングデバイスと「関連付ける」こともでき、これは、リモートサーバまたはコンピューティングデバイスが、例えば、Ａｍａｚｏｎ ＡＷＳ、Ｒａｃｋｓｐａｃｅまたは他の仮想インフラ、またはいずれかのビジネスネットワークにおいてなど、マーケットプレイス１２２との双方向データ転送を行う能力がある場合である。本開示の少なくとも１つの実施形態においては、サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々が常駐するマーケットプレイス１２２は、サービスプロバイダコンピューティングデバイスおよびパートナーコンピューティングデバイス１０４（例えば、ネットワーク１４２を介して）、およびその中の構成要素に電子的に接続されており、それらが互いに継続的な双方向でのデータ転送が可能であるようになっている。

【0055】

明確にするために、サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々は、図１Ａに単一のデータベースとして示されている。サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々は、当該技術で周知のタイプのソフトウェアおよびハードウェアシステム（例えば、インターネット）によって接続された複数のデータベースを含み得るが、これらは、本開示によりサービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々に委任される機能を実行するように共に動作可能であることが、当業者であれば理解されるであろう。サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々はまた、例えば、ビッグデータサービス用の、Ｈａｄｏｏｐアーキテクチャなどの分散データアーキテクチャの一部分であり得る。サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々は、リレーショナルデータベースアーキテクチャ、ｎｏＳＱＬ、ＯＬＡＰ、またはデータベース技術で周知のタイプの他のデータベースアーキテクチャを含み得る。サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々は、例えば、ＭＩＣＲＯＳＯＦＴのＳＱＬサーバ、ＭＩＣＲＯＳＯＦＴのＡＣＣＥＳＳ、ＭｏｎｇｏＤＢ、Ｒｅｄｉｓ、Ｈａｄｏｏｐ、またはＩＢＭのＤＢ２データベース管理システム、またはＯＲＡＣＬＥまたはＳＹＢＡＳＥから入手可能なデータベース管理システムなどの多くの周知のデータベース管理システムのうちの１つを含み得る。サービスプロバイダデータベース１２４、パートナーデータベース１２６、利用状況データベース１３４およびプロビジョニングデータベース１３６の各々は、本明細書にさらに開示するように、自身に伝達される情報を検索可能に記憶する。

【0056】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカ１２８は、システム１００内の様々なエンティティ（例えば、サービスベンダー１０２、クラウドブローカ１０４、第１再販売業者１０６、最終顧客１１２など）間で確立された契約を管理するように構成される。例えば、複数のサービスベンダー１０２のいずれかによって提供されるサービスへのすべてのサブスクリプションが契約によって管理されて、この契約が、いくつかの非限定的な例を挙げると、価格設定、ライセンスコストおよびサービスレベル合意などのサービス条件を記録する。同様に、再販売業者（例えば、第１再販売業者１０６）は、追加の（または異なる）契約条件を有し得るが、最終顧客１１２のサービスの受領は、サービスベンダーの契約条件ではなく、再販売業者の契約条件によって管理される。このような例示の実施形態においては、特定のサービスのプロビジョニング、販売および修正を行う可能性は、サービスベンダー１０２の適用可能な契約条件によって管理される。

【0057】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカ１２８は、利用可能なサービス（すなわち、サービスベンダーまたは再販売業者によって提供されるサービス）のカタログを記憶するように構成される。サービスベンダー１０２によって提供されるサービスが「利用可能」とみなされるのは、サービスベンダー１０２がマーケットプレイス１２２との契約を有するときである。契約を割り当てるプロセスにおいて、サービスプロバイダ１０２は、各サービス（例えば、本明細書にさらに開示するようなＳＫＵ）のサービスプラン、請求ルール、およびコネクタ（例えば、コネクタ１３８）をマーケットプレイス１２２に提供し得る。サービスベンダー１０２のプランおよび請求ルールは、サービスプロバイダデータベース１２４に記憶される。

【0058】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカ１２８は、コネクタ１３８の請求利用状況を監視するようにさらに構成される。例えば、パートナー１０４ａは、サービスベンダー１０２に基づいてサービスを提供することを望むエンティティであり得る。パートナー１０４ａがサービスベンダー１０２に基づいて新しいサービス提供を作成するとき、パートナー１０４ａは、コネクタ１３８を用いてマーケットプレイス１２２に動作可能に接続することで、サービスベンダー１０２のサービスを契約できるようにする。これが「プロビジョニング」とみなされ得る。例えば、図１Ａを参照すると、クラウドブローカ１０４は、パートナー１０４ａによって稼働され得るが、パートナー１０４ａは、サービスベンダー１０２のサービスの提供を望む。このような例示の実施形態においては、パートナー１０４ａは、コネクタ１３８の使用を通じて、マーケットプレイス１２２を介して「利用可能」にされる（すなわち、サービスベンダー１０２は、コネクタ１３８の使用を介してパートナー１０４ａに利用可能にされる）。この実施例を続けると、パートナー１０４ａは、プロビジョニングされた後、再販売業者１０６にまたは最終顧客１１２にさえもサービスを提供し得る。

【0059】

本開示の少なくとも１つの実施形態においては、マーケットプレイス１２２は、連携コネクタ１３０をさらに含み、連携コネクタ１３０は、パートナーのサブスクリプションに基づく利用状況レポートをトランザクションメディエータ１３２から受信するように構成される（本明細書にさらに開示するように）。例えば、マーケットプレイスブローカとパートナーとの間の契約では、請求書が毎月１日に送信される必要があり得るが、連携コネクタ１３０は、必要なデータを受信するために、毎月１日にトランザクションメディエータ１３２に要求を送信する。連携コネクタ１３０は、特定のサービスの（サービスＳＫＵ当たりの）サービス利用状況を要求して、サービスユニット内のＳＫＵ当たりの総利用状況を受信する。図１Ａに示した実施形態のクラウドサービスブローカマーケットプレイスは、サービス顧客のアクティビティおよび実行されたトランザクションについて、サービス顧客からの直接的な情報では動作しないので、クラウドサービスブローカマーケットプレイスは、コネクタを経由するトランザクションを、トランザクションメディエータおよび連携コネクタを用いて監視することで、この情報を抽出する必要がある。

【0060】

本開示の少なくとも１つの実施形態においては、マーケットプレイス１２２は、コネクタ１３８をさらに含む。コネクタ１３８は、すべてのサービス（例えば、サービスベンダー１０２のいずれかによって提供されるサービス）用に構成される。（例えば、図１に示すような）複数のサービスベンダー１０２の各々に関して、コネクタ１３８は、本明細書にさらに開示するように、１つのサブスクリプションを他のサブスクリプションと区別するように構成される。コネクタ１３８は、サービスの供給元（すなわち、サービスベンダー１０２の識別情報）およびサービスの提供先（すなわち、最終顧客１１２の識別情報）を識別するように構成される。コネクタ１３８はまた、サービスのプロビジョニング中にサービスについての情報も受信し得ることが理解されるであろう。本開示の少なくとも１つの実施形態においては、コネクタ１３８は、パートナーのサブスクリプションベースごとで展開されるので、コネクタ１３８は、パートナー１０４ａおよびそのサブスクリプションを定義するように構成される。あらゆるテナント（例えば、最終顧客１１２）およびエンドユーザＩＤは、クラウドブローカ１０４によって生成され、サブスクリプションＩＤは、複数のサービスベンダー１０２の各々がコネクタ１３８に対してプロビジョニングが成功裏に完了したことを確認するときに、サービスベンダー１０２によって生成されることが理解されるであろう。単一のコネクタ１３８が示されているが、システム１２０は、複数のサービスベンダー１０２の各々をサポートするために必要に応じて多くのコネクタ１３８を含み得ることがさらに理解されるであろう。例えば、マーケットプレイスブローカ１２８がＮ個の異なるサービスのＮ個のサブスクリプションを購入したら、マーケットプレイス１２２は、Ｎ個の異なるサービスの各々のためのＮ個のコネクタ１３８インスタンスを提供し得る。

【0061】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカ１２８は、マーケットプレイス１２２を介してパートナー（例えば、パートナー１０４ａ）に、この特定のパートナーのためのサービスプランに従ってサービスを販売するように構成される。パートナーのサービスの各販売に関して、マーケットプレイスブローカ１２８は、マーケットプレイス１２２と動作可能に接続するために、およびプロビジョニングチャネルを調整するために、パートナー（例えば、パートナー１０４ａ）のためのコネクタインスタンス（例えば、コネクタ１３８）を展開するよう、コネクタハブ（図示していないが、コネクタハブサービスを用いてアプリケーションをプロビジョニングする（ＰＲＯＶＩＳＩＯＮＩＮＧ ＡＰＰＬＩＣＡＴＩＯＮＳ ＵＳＩＮＧ Ａ ＣＯＮＮＥＣＴＯＲＳ ＨＵＢ ＳＥＲＶＩＣＥ）ための、その全体が参照として本明細書に組み込まれた米国出願番号第１５／００５，１５１号に開示するような）に要求を送信する。同時に、マーケットプレイスブローカ１２８は、連携コネクタ１３０およびトランザクションメディエータ１３２を介してパートナーに請求サービスを提供する。マーケットプレイスブローカ１２８は、クラウドブローカ１０４と同じように動作すること、ただし、クラウドブローカ１０４はソフトウェアアズアサービスを販売するためのチャネルを提供するのに対し、マーケットプレイスブローカ１２８は、最終的にサービスとして販売されることになるサービスをプロビジョニングするための機構を提供することが理解されるであろう。

【0062】

本開示の少なくとも１つの実施形態においては、コネクタ１３８は、例えば、サービスのプロビジョニングが完了したときに、トランザクションメディエータ１３２に動作可能に接続される。コネクタ１３８は、トランザクションメディエータ１３２に報告するようにさらに構成され、レポートは、いくつかの非限定的な例を挙げると、起動日、プロビジョニング、キャンセル、変更、サービスＩＤ（本明細書にさらに開示するような）、クラウドサービスブローカの識別、サービスの数、起動、変更およびキャンセルなどのアクションのマーカーを含む。コネクタ１３８は、階層請求システム内のエンティティのＩＤを報告し得ることがさらに理解されるであろう。例えば、エンティティは、第１再販売業者１０６、第２再販売業者１０８、第３再販売業者１１０および最終顧客１１２を含み得る。コネクタ１３８は、トランザクションメディエータ１３２によるアクティビティの分析を実行するようにさらに動作する。

【0063】

本開示の少なくとも１つの実施形態においては、システム１２０は、コネクタ１３８に動作可能に接続されたスケジューラ１４０をさらに含む。例示の実施形態においては、販売するサービスは、ディスクスペース、ＣＰＵ時間（従量課金サービス）を含むことが理解されるであろう。スケジューラ１４０は、適用可能なサービスベンダー１０２に定期的な要求を送信することで、そのような情報を読み出して、リソース利用状況（例えば、ディスクスペース利用状況、ＣＰＵ時間）の追跡を提供するように構成される。スケジューラ１４０は、必要に応じてまたは定期的にトランザクションメディエータ１３２にリソース利用状況情報を送信するようにさらに構成される。

【0064】

本開示の少なくとも１つの実施形態においては、マーケットプレイス１２２は、トランザクションメディエータ１３２をさらに含む。トランザクションメディエータ１３２は、システム１２０を経由するすべてのトランザクションについての請求情報を記憶するように構成される。例えば、最終顧客１１２とサービスベンダー１０２ａとの間のトランザクションは、サービスベンダー１０２ａからのソフトウェアの購入、サービスベンダー１０２ａからのソフトウェアおよび／またはサービスのアップグレード、サービスベンダー１０２ａからのソフトウェアおよび／またはサービスのダウングレード、サービスベンダー１０２ａからのサービスのキャンセルまたは同様のものなどのタイプであり得る。本開示の少なくとも１つの実施形態においては、トランザクションメディエータ１３２は、サービス識別子を追跡するようにさらに構成され、サービス識別子は、トランザクションに関連するリソースタイプの英数字識別子である。トランザクションメディエータ１３２は、例えば、サービスベンダー１０２の登録者によって使用されるユニットまたはライセンスの数などの測定単位（ＵＯＭ）を追跡するようにさらに構成される。トランザクションメディエータ１３２はまた、サービス利用状況の量、ならびに開始日および終了日も追跡し得るが、同様に、いくつかの非限定的な例を挙げると、計算リソース利用状況のいずれかの計量または監視、およびサービスベンダー１０２からの請求ルールも受信し得る。

【0065】

開示の少なくとも１つの実施形態においては、マーケットプレイス１２２は、システム１２０を経由するすべてのトランザクションについての調整固有の詳細を、トランザクションメディエータ１３２を介して記憶するようにさらに構成される。例えば、複数のサービスベンダー１０２の各々は、自身に関連付けられたベンダー識別子（ＩＤ）を有し得る。トランザクションメディエータ１３２は、例えば、サービスベンダー側データ（例えば、サブスクリプションＩＤ）、いずれかの他の一意の識別子、いずれかの再販売業者または最終顧客のためのパートナー識別子またはサブスクリプションＩＤ、パートナー側データ（例えば、最終顧客のサブスクリプションＩＤ）および注文識別子などの他の識別子を収集するようにさらに構成される。

【0066】

すべてのトランザクションに関して、トランザクションメディエータ１３２は、報告する必要がある（適用可能な場合）最小データ量、ベンダーの識別情報、再販売業者の識別情報、最終顧客の識別情報、サービスベンダー１０２および再販売業者（例えば、第１再販売業者１０６、第２再販売業者１０８、第３再販売業者１１０）からの請求ルール、およびシステム１００内の各エンティティの利用状況および価格設定を記憶しなければならない。

【0067】

本開示の少なくとも１つの実施形態においては、クラウドブローカ１０４は、パートナー１０４ａによって稼働され得るが、パートナー１０４ａは、サービスベンダー１０２のサービスを登録者に提供するように動作する。クラウドブローカ１０４は、要求によって追跡されるすべてのリソースタイプの、およびリソースタイプごとに集約されて、サービスベンダー１０２（または再販売業者）によって示された条件に従って日割り計算された利用状況情報を受信するようにさらに構成される。前の例を続けると、サービスベンダー１０２ａ（Ｏｆｆｉｃｅ３６５（登録商標））が、登録者によって生じる計算リソース利用状況に基づいて請求するように構成される場合、ベンダー１０２ａがこの情報を追跡して、トランザクションメディエータ１３２は、この情報を受信するように構成される。

【0068】

本開示の少なくとも１つの実施形態においては、クラウドブローカ１０４はまた、再販売業者および下位再販売業者の階層を維持するようにも構成される。例えば、クラウドブローカ１０４は、第１再販売業者１０６、第２再販売業者１０８、第３再販売業者１１０および最終顧客１１２に（図１に示すように）サービス提供し得る。このような例示の実施形態においては、クラウドブローカ１０４は、加入エンティティによるクラウドサービスの消費量を捕捉して保持するように構成される。クラウドブローカ１０４は、パートナーが登録者（例えば、最終顧客１１２）の利用状況を捕捉して請求できるように構成されるのに対し、マーケットプレイスブローカ１２８は、コネクタ１３８の利用状況に対してパートナーに請求するように動作し得ることが理解されるであろう。

【0069】

トランザクションメディエータ１３２は、最終顧客１１２とサービスベンダー１０２との間で交わされるクラウドサービスの個々の請求可能なプロビジョニング動作を示すトランザクションをソフトウェアエージェントで記録するように、さらに構成される。本開示の少なくとも１つの実施形態においては、トランザクションに関連する情報は、次に処理されて、中央システム（例えば、マーケットプレイス１２２）に転送されて、そこで請求目的のためにこの情報を抽出することができる。プロビジョニングフローを監視することによって、クラウドブローカ１０４は、サービスベンダー１０２のデータによって課される同じ請求ルールに頼る必要なく、リアルタイムの請求情報を提供できることがさらに理解されるであろう。

【0070】

収益の整合および決済は、マーケットプレイスとベンダーとの間のコストおよび収益のバランスを取るように機能することが理解されるであろう。例えば、マーケットプレイスブローカは、ベンダーによって請求されて、コストを発生させる。少なくとも１つの実施形態においては、パートナーは、マーケットプレイスブローカによってコネクタを介してトランザクションごとに請求される。少なくとも１つの実施形態においては、マーケットプレイスブローカが収益の流れを生成し、トランザクションメディエータが、コネクタを通過するトランザクションについてのすべてのデータを収集して、マーケットプレイスブローカが、各サービス（ＳＫＵ）当たりの売上コストを見積もることができる。マーケットプレイスブローカは、このために必要なすべてのデータを有することがさらに理解されるであろう。マーケットプレイスは、パートナーのトランザクションに対して価格条件およびベンダーの請求ルールを実施して、経理上の目的でこれを内部または外部ＥＲＰシステムに報告する。より詳細で更新されたシステムを図７Ａに示し、詳細な方法を図１０―１３に示す。

【0071】

本開示の少なくとも１つの実施形態においては、クラウドブローカ１０４およびマーケットプレイスブローカ１２８は、図１Ｂのシステム１５０に示すように、単一のエンティティとして動作し得る。マーケットプレイスブローカ１２８は、本明細書にさらに開示するように、クラウドブローカ１０４と同じ機能を実行できることが理解されるであろう。

【0072】

本開示の少なくとも１つの実施形態においては、システム１５０は、第１再販売業者１０６、第２再販売業者１０８、第３再販売業者１１０および最終顧客１１２を含む。第２再販売業者１０８は、下位再販売業者を含み得るが、下位再販売業者は、上記で開示するように、第１再販売業者１０６からのサービスをさらに再販するように動作することが理解されるであろう。第３再販売業者１１０は、マーケットプレイスブローカ１２８からのサービスに加入するテナントを含み得るが、テナントはサービスを使用するように動作することが理解されるであろう。最終顧客１１２は、テナントのエンドユーザ（例えば、サービスに加入した会社テナントの従業員エンドユーザ）、または再販売業者タイプのエンティティのエンドユーザ（例えば、再販売業者１１０によって提供される統合ソフトウェアサービスの直接の消費者）であり得ることがさらに理解されるであろう。

【0073】

本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカ１２８は、本明細書にさらに開示するように、各者が自身の請求および価格設定ルールを実行するために、必要に応じて第１再販売業者１０６、第２再販売業者１０８、第３再販売業者１１０および最終顧客１１２にプロビジョニングするように動作可能に構成される。

【0074】

図２を参照すると、クラウドサービスブローカプラットフォームにおけるトランザクション処理のための方法のフロー図および構成要素が示され、概して２００に示す。フロー図２００は、請求期間２０４にわたって適用されるようなトランザクション２０２を含む。本開示の少なくとも１つの実施形態においては、トランザクション２０２は、購入２１０と、アドオン２１２と、アップグレード２１４と、ダウングレード２１６と、キャンセル２１８とを含む。いくつかの選ばれたトランザクションしか示されていないが、それにもかかわらず、トランザクション２０２は、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させる上で当業者によって周知であり実践されるような、あらゆるタイプのトランザクションを含み得ることが理解されるであろう。

【0075】

本開示の少なくとも１つの実施形態においては、トランザクション２０２の各々は、いくつかの非限定的な例を挙げると、サービス開始日、請求期間およびいずれかのインセンティブなどのトランザクション属性を含み得る。例えば、購入２１０は、月次請求期間（すなわち、請求期間は１ヶ月）であり、インセンティブは、初月無料サービスを含む。（請求ルールとしても知られる）トランザクション属性は、システム１００内の様々なエンティティ（例えば、クラウドブローカ１０４、第１再販売業者１０６など）の間の契約から生じることが理解されるであろう。他の請求ルール、例えば、無料期間、全額払い、購入および／またはキャンセルの日割り計算、アドオン、アップグレード、ダウングレード、整列（例えば、親のサブスクリプションと子のサブスクリプションとの間の請求期間の整列）、および契約応当日などを、トランザクション２０２の各々に関して含み得ることがさらに理解されるであろう。

【0076】

本開示の少なくとも１つの実施形態においては、登録者（例えば、最終顧客１１２）は、トランザクションを開始し得るが、登録者の請求サイクルは、トランザクション属性に基づいて更新または開始される。例えば、購入２１０は、サービスを購入するためのトランザクションである。購入２１０の属性は、初月無料サービスをインセンティブとした月次頻度（すなわち、月次請求サイクル）を含む。したがって、第１請求サイクル（すなわち、初月）では、登録者は、いずれの料金も請求されない。同様に、同じ登録者が、数ヶ月後にアドオン２１２を開始し得る。このような実施例においては、アドオン２１２のコストが登録者のサービスの総コストに追加される。図２に示すように、３ヶ月目には、登録者コスト２１０ａに登録者コスト２１２ａが加えられる。アドオン２１２の属性は、請求サイクルが親の請求サイクル（すなわち、購入２１０）と整列していることを示す。したがって、アドオン２１２は、購入２１０と同じ請求サイクル中に請求されることになる。図２に示すように、アドオン２１２は、インセンティブとして無料の初月を含む。アドオン２１２は、自身の請求サイクルが親の請求サイクル（すなわち、購入２１０）と整列しないように、独自の整列属性を有し得ることが理解されるであろう。

【0077】

本開示の少なくとも１つの実施形態においては、登録者はまた、サービスのアップグレードを望み得る。例えば、アップグレード２１４トランザクションは（例えば、マーケットプレイス１２２において）開始され得るが、登録者コスト２１４ａが、（図２に示すような）アップグレードされた登録者コスト２１４ｂに修正される。アップグレード２１４は、「旧」期間中の日割り計算、および「新」期間中の日割り計算の属性を含む。アップグレード２１４が開始される請求サイクル中に、登録者コスト２１４ａから登録者コスト２１４ｂへの移行では、移行のどちら側でも登録者のコストは月次請求サイクルで日割り計算される（すなわち、登録者は、請求サイクルの開始からアップグレード前までは登録者コスト２１４ａに基づいて日割り計算され、アップグレード時点から請求サイクルの最後までは登録者コスト２１４ｂに基づいて日割り計算される）。

【0078】

本開示の少なくとも１つの実施形態においては、請求期間コスト２２０が、各請求期間の最後に、登録者によって負担される複数のコストの合計に基づいて計算される。例えば、請求期間２２０ａの間、および１人の登録者がすべてのトランザクション２０２を開始したと仮定すると、登録者のコストは、登録者コスト２１０ａ、登録者コスト２１２ａ、登録者コスト２１４ａ、登録者コスト２１６ａ（ダウングレードへの移行を含む）を含み得る。請求期間２２０ａのコストは、登録者によって負担されるすべての個別サービスコストの合計であることが理解されるであろう。このようなコストは、いくつかの非限定的な例を挙げると、再販売業者当たりのコスト、最終顧客当たりのコスト、またはサービスベンダー当たりのコストを含み得ることがさらに理解されるであろう。

【0079】

図２Ａを参照すると、本開示の少なくとも１つの実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための例示の方法の実施例２４０が示される。実施例２４０においては、サービスベンダーとクラウドブローカとの間の契約が定義され、サービスベンダーに対する複数のサブスクリプションが作成される（すなわち、プランＰ１へのサブスクリプション、プランＰ２へのサブスクリプションおよびプランＰ３へのサブスクリプションであり、各請求期間に対して、プランＰ１は＄１００かかり、プランＰ２は＄２００かかり、プランＰ３は＄３００かかる）。複数のサブスクリプションの各々は、自身に関連付けられた複数の請求属性を含むことが理解されるであろう。実施例２４０においては、複数のサブスクリプションの各々がサブスクリプションの整列を有し、契約応当日は、各月の１０日に当たる（複数のサブスクリプションの各々の各請求期間の開始／終了）。さらに、複数のサブスクリプションの各々は、サービスベンダーが最初の契約応当日までの無料期間を提供する販促期間を含む。複数のサブスクリプションの各々はまた、各請求期間の終了後に日割り計算して請求するためのプロビジョニングも含む。各サブスクリプションの請求属性は、サービスベンダー１０２次第で決まり得ることが理解されるであろう。

【0080】

実施例２４０を続けると、第１登録者（例えば、最終顧客１１２）は、２５０ａに示すように、最初にサービスプランＰ１に加入し、第２登録者は、２５２ａに示すように、最初にサービスプランＰ３に加入し、第３登録者は、２５４ａに示すように、最初にサービスプランＰ３に加入し得る。請求サイクルの最後に、登録者の各々に関して、サービスベンダー１０２は、２６０ｂ、２６２ｂ、２６４ｂ、２６６ｂおよび２６８ｂに示すように、適切なクラウドブローカ（例えば、クラウドブローカ１０４）に請求書を送信することになる。例えば、２６０ｂは、請求期間２６０ａ中にプランＰ１、Ｐ２およびＰ３に加入するための総コストを示す。本実施例においては、２６０ｂのコストは、プランの各々が、上述のように、第１契約応当日に終了する販促の無料サービス期間を含むので、＄０である。同様に、２６２ｂにおいては（請求期間２６２ａのコスト）、プランＰ１のコストが＄１００で、プランＰ２のコストが＄０で、プランＰ３のコストが＄６００である。サービスベンダーがマーケットプレイスブローカ１２８に請求書を送信するときには、コスト（すなわち、ベンダーに支払う金額）と収益（すなわち、再販売業者またはパートナーから受け取る金額）を整合させる必要があることが理解されるであろう。トランザクションメディエータ１３２を用いてすべてのトランザクションを監視することによって、マーケットプレイスのコンピューティングデバイス１２２は、ベンダーの請求ルール（以下でさらに開示するように、サービスプロバイダデータベース１２４内に記憶され得る）を適用することによって、ベンダーの請求プロセスをシミュレートするように構成される。マーケットプレイスブローカ１２８は、ベンダーの請求書との調整を可能にして、正確なコスト収益整合を生み出すことがさらに理解されるであろう。

【0081】

上記の実施例を続けると、図２Ｂに、クラウドブローカ１０４とその登録者（例えば、最終顧客１１２ａ、１１２ｂ、１１２ｃ、１１２ｄ）との間の契約が示され、登録者は月次サブスクリプションに加入する。図２Ｂに示すように、この登録者にとって、プランＰ１は＄１２０かかり、プランＰ２は＄２４０かかり、プランＰ３は＄３６０かかる。プランの各々に適用される属性は、契約応当日が購入日に当たるサブスクリプションの整列、無料期間なし、プラン変更の返金なし、キャンセルの日割り計算、料金の前払いを含むことがさらに理解されるであろう。

【0082】

図２Ｂに示す請求モデルに従えば、各期間のブローカの売上２７０は、請求期間の売上総額に従う。例えば、期間２７０ｂ中のプランＰ１の総コストは＄１２０であり、プランＰ２の総コストは＄０であり、プランＰ３の総コストは＄７２０である。同様に、期間２７２ｂのプランＰ１の総コストは＄１２０であり、プランＰ２の総コストは＄０であり、プランＰ３の総コストは＄７２０である。この実施例を続けると、期間２７４ｂのプランＰ１の総コストは＄１２０であり、プランＰ２の総コストは＄２４０であり、プランＰ３の総コストは＄７２０である。

【0083】

本開示の少なくとも１つの実施形態においては、システム１００は、各サービスベンダー（例えば、サービスベンダー１０２）、再販売業者（例えば、再販売業者１０６）および最終顧客（例えば、最終顧客１１２）の契約およびサブスクリプションの記録を保持するようにさらに構成される。これにより、階層内の各エンティティが調整および損益分析を実行できるようにすることが理解されるであろう。例えば、図２Ｃを参照すると、クラウドブローカ１０４のブローカ売上２７０とクラウドブローカ１０４のブローカ支払い２７２との間の決済および調整が示されている。この実施例においては、２６０ｂに示すように、プランＰ１の期間２７０ｂ中のブローカ売上は＄１２０であるが、プランＰ１の同じ期間中のブローカ支払いは＄０である。図２Ｃに示すように、あらゆる請求期間に関して、ブローカ売上２７０とブローカ支払い２７２との間にはコスト収益整合が存在することが理解されるであろう。

【0084】

ここで図３を参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素が示され、概して３００に示す。フロー図３００は、サービス３０２、サービス請求ルール属性３０２ａ、請求期間３１０およびサービスユニット内の月次サービス量３１２を示す。本開示の少なくとも１つの実施形態においては、サービス３０２の各々は、登録者（例えば、最終顧客１１２）によって加入されたサービスを表す。サービス３０２は、プロビジョニングチャネルアーキテクチャに応じて、言い換えれば、クラウドブローカ１０４およびマーケットプレイスブローカ１２８が、システム１５０に示されるがシステム１２０には示されていないように、単一のエンティティとして動作するかどうかに応じて、クラウドブローカ１０４からまたはマーケットプレイスブローカ１２８から受信され得ることが理解されるであろう。本開示の少なくとも１つの実施形態においては、サービス３０２の各々は、自身に関連付けられたサービス請求ルール属性３０２ａを有する。例えば、サービス識別子「ＳＫＵ－Ｃ３」は、属性「ａ」、「ｆ」および「ｐ」を含むが、「ａ」は、ＳＫＵ－Ｃ３が整列されていることを示し、「ｆ」は、最初の無料期間を有することを示し、および「ｐ」は、例えば、キャンセル中に日割り計算されることを示す。

【0085】

本開示の少なくとも１つの実施形態においては、サービスユニット内の月次消費サービス量３１２の各々は、特定の請求期間３１０中のサービスの個々の量の各々を加算することによって計算される。例えば、請求期間３１０ｂ（２月）中は、月次サービス総量３１２ｂは、ＳＫＵ－Ａ１、ＳＫＵ－Ｂ２、ＳＫＵ－Ｃ３（ａｆｐ）、ＳＫＵ－Ｄ４（ａｐｆ）およびＳＫＵ－Ｄ４（ｕｆｆ）に関連する消費サービス量を含む。月次サービス総量３１２の各々は、サービス属性３０２ａの各々に基づいて、サービス３０２に関連する各個々の量を加算することによって計算される。次いで、月次消費サービス量は、ＳＫＵごとに、例えば、請求期間３１０ｂ（２月）中に計算され、ＳＫＵ－Ｃ３－１．６３、ＳＫＵ－Ａ１－０．１６、ＳＫＵ－Ｂ２－０．１３、ＳＫＵ－Ｄ４－１．３５である。月次コスト（または契約側、すなわちベンダーかまたはパートナーかに応じて収益）の各々は、請求ルールに従って、サービスユニット内の月次サービス量をサービスの価格で乗算することによって計算され得ることが理解されるであろう。

【0086】

ここで図４を参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法のフロー図および構成要素が示され、概して４００に示す。本開示の少なくとも１つの実施形態においては、販売注文４０２が生成される。販売注文４０２は、サブスクリプション期間４０４を示し、サブスクリプション期間は、複数の請求期間（４０６ａ、４０６ｂおよび４０６ｃ）に分割される。請求期間の各々に対して、請求コストが計算される。例えば、請求期間４０６ａにおいて、注文前請求４０８ａが計算される。請求期間４０６ａの最後に、利用状況が収集される。請求期間４０６ａの最後に、注文後請求４１０ａが計算される。サブスクリプション期間４０４は、販売注文４０２、または登録者とサービスプロバイダ（例えば、サービスベンダー１０２または再販売業者）、または最終顧客さえとの間で合意されたなんらかの他の契約条件に基づいて、複数の請求期間に分割され得ることが理解されるであろう。

【0087】

ここで図５を参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法および構成要素が示され、概して５００に示す。方法５００は、サービスベンダー１０２の各々においてコストを計算するステップ５０２と、クラウドブローカ（マーケットプレイス）１２８においてサービスコストを計算するステップ５０４と、再販売業者１０６ａおよび１０８ａにおいてコストを計算するステップ５０８と、最終顧客１１２ａのための統合請求書を作成するステップ５１０とを含む。

【0088】

本開示の少なくとも１つの実施形態においては、ステップ５０２において、サービスベンダー１０２の各々に関してコストが計算される。例えば、クラウドブローカ（マーケットプレイス）１２８は、サービスベンダー１０２が最初にセットアップされた（すなわち、「利用可能」にされた）ときから、サービスベンダー１０２の各々の契約情報を有する。サービスベンダー１０２の各々に関して、契約ベースの価格体系が作成される。例えば、サービスベンダー１０２ａは、ライセンス構造に基づく月次請求サイクルで請求し得るが、請求書の締め日は毎月４日となり、支払いは期間の最後に行われる。同様に、例として、サービスベンダー１０２ｂは、「従量課金」体系に基づく四半期ごとの請求サイクルで請求し得るが、請求書の締め日は毎月５日にあたり、支払いは請求期間の最後に行われる。

【0089】

本開示の少なくとも１つの実施形態においては、ステップ５０４において、クラウドブローカ（マーケットプレイス）１２８でコストが計算される。例えば、クラウドブローカ（マーケットプレイス）１２８は、サービスベンダー１０２ｂが四半期ベースで請求する場合でも、月次請求期間ベースで請求書を作成する必要があり得る。このような例示の実施形態においては、クラウドブローカ（マーケットプレイス）１２８は、サービスベンダーの請求期間が未来の場合は、見積もりコストに基づいてコストを計算するように構成される。

【0090】

本開示の少なくとも１つの実施形態においては、ステップ５０８において、再販売業者１０６ａ、１０８ａに関して、コストが計算される。ここでもまた、再販売業者１０６ａおよび１０８ａの各々は、独立した契約条件を有し得るので、請求特性は、サービスベンダー１０２の特性とは異なることになる。例えば、再販売業者１０８ａにおいて、サービスベンダー１０２ａ（ｏｆｆｉｃｅ３６５（登録商標））は、毎月１５日にあたる契約応当日を有し得るが、上述のように、サービスベンダー１０２ａは、毎月４日に請求を行う。

【0091】

本開示の少なくとも１つの実施形態においては、ステップ５１０において、最終顧客１１２ａに関して、統合請求書が作成される。最終顧客１１２ａに関しては、最終顧客１１２ａのサブスクリプションから生じるすべてのコストが、最終顧客１１２ａの請求特性に基づく単一の請求書上に生成されるように、単一の請求書が作成されることが理解されるであろう。最終顧客１１２ａの請求特性は、上流のエンティティ（例えば、サービスベンダー１０２、ならびに再販売業者１０６ａおよび１０８ａ）の特性とは異なり得ることが理解されるであろう。

【0092】

ここで図６を参照すると、クラウドサービスブローカプラットフォームにおける請求および調整のための方法が示され、概して６００に示す。本開示の少なくとも１つの実施形態においては、方法は、コネクタ１３８がトランザクションメディエータ１３２にプロビジョニング動作の属性を報告するステップ６０２と、トランザクションメディエータ１３２がサービス利用状況データベース１３４にデータを記憶するステップ６０４と、連携コネクタ１３０がサービスベンダー１０２との調整のためにサービス利用状況レポートを要求するステップ６０６と、トランザクションメディエータ１３２が、サービス利用状況を判断するためにサービスベンダー１０２の請求ルールを受信するステップ６０８と、トランザクションメディエータ１３２がサービスの総利用状況を計算するステップ６１０と、トランザクションメディエータ１３２が連携コネクタ１３０にレポートを送信するステップ６１２と、連携コネクタ１３０がマーケットプレイスブローカ１２８にレポートを送信するステップ６１４と、マーケットプレイスブローカ１２８が、サービスベンダー１０２との調整のための利用状況レポートを作成するためにサービスベンダー１０２の価格設定モデルを適用するステップ６１６と、連携コネクタ１３０がパートナー１０４ａ請求のためにサービス利用状況レポートを要求するステップ６１８と、トランザクションメディエータ１３２がパートナー１０４ａのサブスクリプションから請求ルールを受信して、トランザクションメディエータ１３２がサービス利用状況データを判断するために請求ルールを適用するステップ６２０と、トランザクションメディエータ１３２がサービスの総利用状況を計算するステップ６２２と、トランザクションメディエータ１３２が連携コネクタ１３０にレポートを送信するステップ６２４と、連携コネクタ１３０がマーケットプレイスブローカ１２８にレポートを送信するステップ６２６と、マーケットプレイスブローカ１２８が、利用状況レポートのためにパートナー１０４ａのサブスクリプションからの価格設定モデルを適用して、パートナー１０４ａに請求するステップ６２８とを含む。

【0093】

ここで図７Ａおよび７Ｂを参照すると、本開示の少なくとも１つの実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるためのシステムが示され、概して７００に示す。システム７００は、独立したソフトウェアベンダー（ＩＳＶ）格付けエンジン７０２、売上コスト計算機（ｃｏｓ.計算機）７０４および企業資源計画（ＥＲＰ）システム７０６を含む。

【0094】

本開示の少なくとも１つの実施形態においては、ＩＳＶ格付けエンジン７０２は、トランザクションメディエータ１３２に動作可能に接続される。ＩＳＶ格付けエンジン７０２は、マーケットプレイスブローカ１２８のトランザクションメディエータ１３２からトランザクション情報を受信するようにさらに構成される。非限定的な例として、トランザクションタイプは、起動、キャンセル、変更、アップグレード、ダウングレード、アドオン、利用状況収集、および同様のものを含む。本開示の少なくとも１つの実施形態においては、トランザクションメディエータ１３２は、トランザクションをＩＳＶ格付けエンジン７０２に送信する。トランザクションメディエータ１３２からの各トランザクションは、例えば、リソース識別子、ＩＳＶ契約識別子、サブスクリプション識別子、リソース最小在庫管理単位（ＳＫＵ）値、トランザクションタイプ、数量、日付および同様のものを含むことが理解されるであろう。本開示の少なくとも１つの実施形態においては、トランザクションに付随する情報は、マーケットプレイスブローカ１２８内で宣言される。本開示の少なくとも１つの実施形態においては、ＩＳＶ格付けエンジン７０２は、料金を、ＩＳＶ格付けエンジン７０２に動作可能に接続されたデータベースに記憶する。ＩＳＶ格付けエンジン７０２は、大口割引、更新期間の長さ、他の最新価格計算ルールなどの、ユーザトランザクションの過去の履歴に基づいて、価格形成ルールを実施することができることがさらに理解されるであろう。

【0095】

本開示の少なくとも１つの実施形態においては、ｃｏｓ．計算機７０４は、マーケットプレイス１２８上で行われるトランザクションまたは契約の各々の実際の売上コストを計算するように構成される。本開示の少なくとも１つの実施形態においては、マーケットプレイスブローカ１２８とパートナー１０４または再販売業者１０６との間の契約における契約条件は、プロビジョニングチャネルアーキテクチャ、言い換えれば、システム７００ａに示されるがシステム７００ｂには示されないように、クラウドブローカ１０４およびマーケットプレイスブローカ１２８が単一のエンティティとして動作するかどうかに応じて、マーケットプレイスブローカ１２８とサービスベンダー１０２との間の契約条件とは異なり得る（すなわち、これらの２つの契約の間に依存関係は存在しない）。マーケットプレイスブローカ１２８は、再販売業者１０６のためにいかなる請求ルールおよび価格形成ルールをセットアップすることができることが理解されるであろう。即ち、マーケットプレイスブローカー１２８がサービスベンダー１０２に対して支払う契約条件と比べて、この請求ルール及び価格形成ルールはマーケットプレイスブローカ１２８にとって柔軟性があり、より大きい収益の流れを生み出す。例として、マーケットプレイスブローカ１２８は、様々なサービスベンダーによって開発された異なるアプリケーションを含むソフトウェアバンドルを再販売業者１０６に販売して、アプリケーションのバンドル全体に関して１つのサブスクリプション期間をセットアップし得る。マーケットプレイスブローカ１２８はまた、特別割引もセットアップし得る。しかしながら、マーケットプレイスブローカ１２８は、再販売業者（例えば、再販売業者１０６）からの収益の流れと、サービスベンダー（例えば、サービスベンダー１０２）に支払うべきコストとを整合させなければならないであろう。

【0096】

本開示の少なくとも１つの実施形態においては、ｃｏｓ．計算機７０４は、自動コスト計算を円滑にするように構成される。ｃｏｓ．計算機７０４は、マーケットプレイスブローカ１２８と再販売業者１０６との間の契約によって定義された期間の、各リソースＳＫＵのコストの見積もりをＩＳＶ格付けエンジン７０２に対して要求する。本明細書に開示するように、ｃｏｓ．計算機７０４は、さらなる収益整合および決済のために重要であるコストの流れと収益期間を整列することが、理解されるであろう。例えば、マーケットプレイスブローカ１２８と再販売業者１０６との間の契約のいくつかの請求期間は、マーケットプレイスブローカ１２８とサービスベンダー１０２との間の契約からの請求期間よりも長くなり得る。このような実施形態においては、ＩＳＶ格付けエンジン７０２は、トランザクションメディエータ１３２を介して受信するトランザクションメトリックに基づいて、未来の請求期間に関するコストの見積もりを提供する。

【0097】

本開示の少なくとも１つの実施形態においては、企業資源計画（ＥＲＰ）システム７０６は、ＩＳＶ格付けエンジン７０２またはマーケットプレイス１２２に動作可能に接続される。ＥＲＰシステム７０６は、例えば、ＳＡＰ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｄｙｎａｍｉｃｓ（登録商標）、または同様のものなどの、当業者に周知のタイプである。ＥＲＰシステム７０６は、クラウドベース、およびマーケットプレイス１２２から遠隔であり得るか、またはマーケットプレイス１２２の構成要素とされ得ることが理解されるであろう。少なくとも１つの実施形態においては、ＥＲＰシステム７０６は、金融および他のデータを受信して、本開示によりＥＲＰシステム７０６に委任される機能を実行するように共に動作可能であるように構成される。

【0098】

ここで図８を参照すると、ＩＳＶ契約カタログコンピューティングデバイスが示され、概して８００に示す。本開示の少なくとも１つの実施形態においては、ＩＳＶ契約カタログコンピューティングデバイス８００は、ＩＳＶカタログ８０２、アプリケーションカタログ８０４、価格形成カタログ８０６、価格コンストラクタツール８０８、ＩＳＶ請求ルールマネージャ８１０、契約マネージャ８１２、格付けエンジンインタフェース８１４、通知マネージャ８１６およびユーザ入力インタープリタ８１８を含む。

【0099】

ＩＳＶカタログ８０２は、ＩＳＶ契約カタログコンピューティングデバイス８００上で実行されるサービスである。ＩＳＶカタログは、いくつかの部分からなる。製品カタログ８０４は、コネクタを介してクラウドサービスブローカマーケットプレイスシステムと統合された利用可能なＩＳＶサービスについての情報を記憶する。製品カタログはまた、サービスに関連するリソースセットも含む。価格コンストラクタツール８０８を介して、ＩＳＶは、サービスおよびリソース利用状況の価格を調整することができる。価格コンストラクタツール８０８は、様々な価格形成設定、例えば、価格の公式が依存し得る大口からの依存性、使用期間、なんらかのタイプのクライアントに対する特別割引、様々な引数等を含み得る。ＩＳＶは、様々な価格設定を使用し得るが、これらを組み合わせて、数式の形態の価格条件を含む、自身の価格条件を設定する。価格形成カタログ８０６は、ＩＳＶによってツール８０８または手動で設定された価格条件を記憶する。ＩＳＶ請求ルールは、サービスおよび関連するリソースのための請求ルールを記憶する。様々な請求ルールが、図２の２０２に図示されている。契約マネージャは、ＩＳＶとクラウドサービスブローカマーケットプレイス１２８との間の契約条件を記憶する。格付けエンジンインタフェース８１４は、格付けエンジンとのインタフェース、要求および応答の処理を担う。通知マネージャ８１６は、格付けエンジンおよびクラウドサービスブローカマーケットプレイス１２８に、ＩＳＶ側からの製品リスト、価格、請求ルールまたは契約の変更について通知する。ユーザ入力インタープリタ８１８は、ＩＳＶ用のＵＩであり、ＩＳＶがＩＳＶカタログサービス８０２と相互作用するのを手助けする。

【0100】

本開示の少なくとも１つの実施形態においては、ＩＳＶ契約カタログデバイス８００は、サービスプロバイダ請求ルールおよびサービスプランデータベース１２４を引き継ぐ。本開示の少なくとも１つの実施形態においては、ＩＳＶ契約カタログデバイス８００および階層パートナー契約カタログ１２６は、製品カタログとして組み合わされ得る（図示せず）。本開示の少なくとも１つの実施形態においては、製品カタログは、（ベンダーによって設定された、パートナー、再販売業者のために設定された）価格付きのベンダーのサービスを含む製品を伴う少なくとも１つのデータベースを含み得る。

【0101】

ここで図９を参照すると、ＩＳＶ格付けエンジンコンピューティングデバイスの構成要素が示され、概して９００に示す。本開示の少なくとも１つの実施形態においては、ＩＳＶ格付けエンジンコンピューティングデバイスは、トランザクションメディエータインタフェース９０２、トランザクションマネージャ９０４、料金ジェネレータ９０６、料金見積もりマネージャ９０８、価格計算機９１０、格付けマネージャ９１２、リソース利用状況マネージャ９１４、ＩＳＶ契約カタログインタフェース９１６、ｃｏｓ．計算機インタフェース９１８、ＥＲＰインタフェース９２０および連携利用状況計算機９２２を含む。

【0102】

本開示の少なくとも１つの実施形態においては、リソース利用状況マネージャ９１４は、従量課金モデルをサポートするように構成され、トランザクションメディエータ１３２から利用状況を伴うトランザクションを受信する。本開示の少なくとも１つの実施形態においては、連携利用状況計算機９２２は、連携コネクタ１３０の機能を引き継いで、ＳＫＵ当たりの利用状況を計算するように構成され、これをマーケットプレイスコンピューティングデバイス１２２に報告する。

【0103】

ここで図１０を参照すると、本開示の少なくとも１つの実施形態による、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法１０００が示される。本開示の少なくとも１つの実施形態においては、ステップ１００２で、トランザクションメディエータ１３２は、あらゆるサービスリソースに関して「収集」要求を含むいずれかのトランザクションを送信する。方法１０００は、ステップ１００４に進み、そこでＩＳＶ格付けエンジン７０２は、サービスリソースの契約詳細（例えば、価格形成ルール等）についてＩＳＶカタログ８０２に要求して、利用状況レポートを待つ。トランザクションメディエータ１３２は、ステップ１００６において、この契約が存在するかどうかをチェックして、存在する場合は、ステップ１００８に進み、存在しない場合は、ステップ１０３６に進む。本開示の少なくとも１つの実施形態においては、ステップ１００８で、トランザクションメディエータ１３２は、利用状況レポートをＩＳＶ格付けエンジン７０２に送信する。ＩＳＶ格付けエンジン７０２は、利用状況レポートを収集して、価格形成ルールに従う価格で料金を作成する。例えば、ＩＳＶ格付けエンジン７０２は、サービスベンダー１０２でセットアップされたこのリソースに関連する請求期間ごとに１つの料金を作成し得る。別の場合には、契約が、異なるリソース量に対して異なる価格を定義する場合、ＩＳＶ格付けエンジン７０２は、閾値を超えるまで待って、第１価格で料金を作成して、その後、次の閾値に達するおよび／またはこれを超えるまで、利用状況を収集する。

【0104】

本開示の少なくとも１つの実施形態においては、ＩＳＶカタログ８０２は、マーケットプレイスブローカ１２８とサービスベンダー１０２との間の契約についての契約詳細を含む。特に、マーケットプレイスブローカ１２８とサービスベンダー１０２との間の各契約は、アプリケーション、これらの記述、リソースＳＫＵについてのデータ、およびこのアプリケーションに関連するリソース識別子（例えば、サービスベンダー番号）、サブスクリプション期間、価格形成ルール、通貨、測定単位、起動、キャンセル、変更（例えば、アドオン、アップグレード、ダウングレード）のための請求ルールおよび請求書作成の少なくとも１つのセットを含む。ＩＳＶカタログ８０２はまた、価格形成ルール設定のためのユーザインタフェース、およびすべての考えられる価格形成ルールを含むカタログ、およびサービスベンダーまたは他のエンティティが価格形成ルールをセットアップするためのユーザインタフェースを含む価格コンストラクタツールも有することが理解されるであろう。様々な価格条件は、広範であるが事前設定されることが理解されるであろう。最低でも、要件は、これらの価格形成ルールは、トランザクションメディエータ１３２からのトランザクションに含まれる情報に基づいて、ＩＳＶ格付けエンジン７０２によって決定されなければならない（すなわち、価格の公式は、トランザクションメディエータ１３２によって／に対して報告される変数に関して表現されるべきであるか、または別様にはそれらに基づいて直接計算することができることが理解されるであろう）。

【0105】

方法１０００を続けると、ステップ１００８において、受信するトランザクションに関連するリソースサブスクリプションが存在するかどうかをチェックする。存在する場合、方法１０００はステップ１０１０に進み、存在しない場合は、方法１０００はステップ１０３８に進み、ここでトランザクションが「起動」であるかをチェックする。

【0106】

ステップ１０１０において、トランザクションのタイプが定義される。本開示の少なくとも１つの実施形態においては、ステップ１０１２において「起動」トランザクションが判断されて、これらに関連する２つの属性：整列（ａ）および非整列（ｕ）、ならびにトランザクションの起動に関連付けられた３つの属性：無料、全額および日割り計算を含む契約応当日によって特徴付けられる。トランザクションが実際に「起動」である場合、方法１０００はステップ１０５８に進み、ステップ１００６で判断されたように契約が既に存在するので、トランザクションは、「誤り」として記憶され得る（同様に、ステップ１０４０において、トランザクションが「起動」であると判断されると、方法はステップ１０４２に進み、そうでなければステップ１０３６に進み、トランザクションは「非整合」として記憶される）。

【0107】

トランザクションが「起動」ではない場合、方法１０００はステップ１０１４に進む。ステップ１０１４において、トランザクションが「キャンセル」であるかどうかが判断される。本開示の少なくとも１つの実施形態においては、キャンセルは、関連付けられた３つの属性、すなわち、無料、全額、日割り計算を有する。トランザクションがキャンセルではない場合、方法１０００はステップ１０６０に進む。

【0108】

トランザクションがキャンセルの場合、方法１０００は、ステップ１０１６に進み、既存のアクティブリソースサブスクリプションが、トランザクションに関連付けられたリソース上で識別される。方法１０００は、次いでステップ１０１８に進み、関連するリソースＳＫＵに対してサービスベンダー１０２の請求期間が識別される。ステップ１０２０において、サービスベンダー１０２との適用可能な契約に関するキャンセルルールを読み出すために、ＩＳＶカタログ８０２がクエリされる。ステップ１０２４において、現在の請求期間のためのキャンセルルールを決定することによって、次いでステップ１０２６において、キャンセルルールを実施して、キャンセルのためのマイナス価格を計算することによって、ステップ１０２２においてマイナス価格の料金が作成される。

【0109】

本開示の少なくとも１つの実施形態においては、さらなる請求期間のための任意の見積もり料金が、ステップ１０２８において判断される。このような請求料金が存在しない場合は、前のステップから作成された料金が、ステップ９０２において記憶される。記憶すべき料金が存在する場合、ステップ１０３０において、すべての見積もり料金に関してマイナス価格で料金が作成されて、ステップ１０３２において、見積もり料金のための価格が識別される。ステップ１０３４において、作成されたすべての料金が、関連するトランザクションと共に記憶されて記載される。

【0110】

方法１０００のステップ１０４０を再び参照すると、トランザクションが「起動」である場合、方法１０００は、図１０Ａに示すようにステップ１０４２に進む。本開示の少なくとも１つの実施形態においては、ステップ１０４４において、リソースＳＫＵに関連する請求期間について、ＩＳＶカタログ８０２がクエリされる。ステップ１０４６において、ＩＳＶカタログ８０２は、リソースＳＫＵに関連する価格形成ルールセットについてさらにクエリされる。本開示の少なくとも１つの実施形態においては、ステップ１０４８において、サービスベンダー１０２の最も遠い請求日の終了日で料金が作成される。例えば、ステップ１０５０においてトランザクションデータが識別されて、ステップ１０５２において価格形成ルールが決定されて、ステップ１０５４において価格が実施される。ステップ１０５６において、作成された料金が記憶される。

【0111】

方法１０００のステップ１０５８を再び参照すると、トランザクションが「誤り」として記憶された後、方法１０００は、図１０Ｃに示すようにステップ１０６０に進む。ステップ１０６０において、トランザクションが「変更」であるかどうかが判断される。本開示の少なくとも１つの実施形態においては、変更のトランザクションは６つの属性、すなわち、旧サブスクリプションの無料、全額、日割り計算の３つ、および新サブスクリプションの無料、全額、日割り計算の３つを有する。

【0112】

本開示の少なくとも１つの実施形態においては、トランザクションに関連するリソース上の既存のアクティブリソースサブスクリプションが、ステップ１０６２において識別される。１０６４において、変更トランザクションのタイプが識別され、リソースＳＫＵに関連する期間に関して、サービスベンダー１０２の請求期間が識別される。次いで方法１０００は、ステップ１０６８に進み、サービスベンダー１０２との契約からの変更ルールについて、ＩＳＶカタログ８０２がクエリされる。ＩＳＶカタログ８０２はまた、リソースＳＫＵおよび変更トランザクションのタイプに関連する価格ルールについてもクエリされることが理解されるであろう。本開示の少なくとも１つの実施形態においては、ステップ１０７２において変更料金が作成されて、１０８０において、現在の請求期間のための変更ルールが決定され、ステップ１０８２において変更ルールが実施される。

【0113】

次いで方法１０００は、ステップ１０９０に進み、さらなる請求期間に関していずれかの見積もり料金が存在するかどうかが判断される。記憶すべき料金が存在しない場合、方法１０００は、ステップ１０９２において終了する。存在する場合は、すべての見積もり料金に関して、リソースに関連付けられた見積もり料金に関連する価格を含む料金が、ステップ１０９４において作成される。ステップ１０９６において、見積もり料金の価格が識別され、ステップ１０９８において、トランザクションに関連する作成されたすべての料金が記憶されて記載されることがさらに理解されるであろう。

【0114】

ＣＳＢプラットフォームにおいて、リソースの基本価格が、サービスベンダー１０２とマーケットプレイスブローカ１２８との間の契約によって固定されて設定されることが理解されるであろう。いくつかのタイプの割引、すなわち、大口割引（いくつかの非限定的な例を挙げると、ユニットごとのサブスクリプションに関しては、数量がユニット数であり、従量課金サブスクリプションに関しては、数量は、メモリ、ネットワーク帯域幅および他のコンピュータリソースなどの購入済みリソースの数量として直接定義される）が存在することがさらに理解されるであろう。割引は、サブスクリプション更新期間に基づいて実施可能であることも理解されるであろう。例えば、初年度割引は２５％で、２年目割引は３５％等となり得る。割引の階層は、サービスベンダー１０２によって設定され得るが、割引は、パーセンテージとしておよび現金等価物ではデルタ修正として設定可能である。割引は、条件の組み合わせとして設定可能であることが理解されるであろう。

【0115】

本開示の少なくとも１つの実施形態においては、最新価格計算もセットアップすることができる。例えば、登録者が、１年間になんらかの閾値を超えるリソースサブスクリプション量を購入する場合、特別割引を実施することができる。最新価格計算を実施するために、トランザクションが記憶されて、割引のためのなんらかの閾値が達成される場合は、補正料金が発行される。ＩＳＶ格付けエンジン７０２は、トランザクションメディエータ１３２からトランザクションを受信して、ＩＳＶカタログ８０２に契約詳細を要求した後に、各リソースＳＫＵに関して価格形成ルールおよび請求ルールを実施する。

【0116】

ここで図１１を参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法が示され、概して１１００に示す。方法１１００は、本開示の少なくとも１つの実施形態による、ｃｏｓ．計算機７０４の要求に応えるＩＳＶ格付けエンジン７０２の動作を示す。方法１１００は、ステップ１１０２から始まり、新しい見積もり要求がｃｏｓ．計算機７０４から受信される。ステップ１１０４において、ＩＳＶ格付けエンジン７０２は、受信した要求に関連するリソースサブスクリプションが存在するかどうかをチェックする。要求が存在しない場合、方法１１００は、ステップ１１０６に進み、次いでステップ１１０２に再びループする。

【0117】

要求が存在する場合、方法１１００はステップ１１０８に進み、要求された見積もり期間の終了日が識別される。ステップ１１１０において、要求された見積もり期間の終了日が、適用可能なサービスベンダー１０２との関連する契約による最も近い未来の請求日と比較される。

【0118】

本開示の少なくとも１つの実施形態においては、ステップ１１１２において、要求された見積もり期間の終了日が、適用可能なサービスベンダー１０２との関連する契約による次の請求日を超えるかどうかを確認するためにチェックされる。超えない場合、方法１１００は、本明細書にさらに開示するようにステップ１１２０に進む。

【0119】

超える場合、方法１１００は、ステップ１１１４に進み、ＩＳＶカタログ８０２は、好ましい請求期間に関して、リソースＳＫＵに関連する価格ルールセット、および見積もり期間の終了日後に続く請求日についてクエリされる。ステップ１１１６において、見積もり期間の終了日に続く請求日に関して、料金が作成される。ステップ１１１８において、次の請求日が、見積もり期間の終了後の請求日に続く請求日として割り当てられる。次いで、方法１１００は、ステップ１１２０で終了して、要求された期間に関して新たな料金が送信および記憶される。

【0120】

ＩＳＶカタログ８０２は、見積もりのためのルールを含み得ることが理解されるであろう。例えば、サービスベンダー（Ｍｉｃｒｏｓｏｆｔのような）が前払いシステムを有する場合、このようなサービスベンダーは、平均消費リソース量を計算するために次の請求期間のためのルールをセットアップして、このようなルールに従って請求書を準備し得る。このような請求期間の最後に、サービスベンダーは、補正済みの請求書を送信し得るが、ＩＳＶ格付けエンジン７０２は、ｃｏｓ．計算機７０４からの見積もり要求に対してこのような補正を実施し得ることがさらに理解されるであろう。

【0121】

ここで図１２を参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法が示され、概して１２００に示す。方法１２００は、本開示の少なくとも１つの実施形態による、ＩＳＶ格付けエンジン７０２が反復レポートをＥＲＰシステム７０６に送信するための動作を示す。

【0122】

方法１２００は、ステップ１２０２から始まり、反復格付けのための非同期タスクを受信するどうかをチェックする。このタスクは、同期もあり得ることが理解されるであろう。このようなタスクを受信しない場合、方法１２００は、１２０２にループバックする。

【0123】

タスクを受信する場合、方法１２００はステップ１２０４に進み、すべてのアクティブなサブスクリプションが選択されて、このようなアクティブサブスクリプションの次の請求日は、現在の日付を超えない。次いで、方法１２００はステップ１２０６に進み、選択されたサブスクリプションが、リソースＳＫＵごとにグループ化されて、各グループに対してタスクが実行される。

【0124】

本開示の少なくとも１つの実施形態においては、ステップ１２０８において、ＩＳＶカタログ８０２が、各適用可能なリソースＳＫＵに関連する価格ルールセットについてクエリされる。ステップ１２１０において、現在の日付がその後に続く請求期間の料金が作成される。ステップ１２１２において、価格形成ルールが決定され、ステップ１２１４において、価格が実施される。

【0125】

本開示の少なくとも１つの実施形態においては、ステップ１２１６において、次の請求日が、現在の日付後に続く請求日として割り当てられる。方法１２００は、ステップ１２１８で終了し、要求された期間の料金が送信されて記憶される。

【0126】

ここで図１３を参照すると、クラウドサービスブローカプラットフォームにおいて収益の流れを整合させるための方法が示され、概して１３００に示す。方法１３００は、本開示の少なくとも１つの実施形態による、ＩＳＶ契約カタログ８０２内の変更を監視するためのＩＳＶ格付けエンジン７０２の動作を示す。

【0127】

方法１３００は、ステップ１３０２から始まり、ＩＳＶ格付けエンジン７０２は、自身がＩＳＶ契約カタログ８０２から価格変更通知を受信したかを確認するために（定期的にまたは継続的に）チェックする。通知を受信すると、方法１３００はステップ１３０４に進み、影響を受けるサブスクリプションが選択されて、料金が注文される。次いで、方法１３００はステップ１３０６に進み、選択されたサブスクリプションがリソースＳＫＵごとにグループ化されて、各グループに対してタスクが実行される。

【0128】

本開示の少なくとも１つの実施形態においては、ステップ１３０８において、ＩＳＶカタログ８０２が、各適用可能なリソースＳＫＵに関連する価格ルールセットについてクエリされる。ステップ１３１０において、影響を受けるサブスクリプションのためのあらゆるペンディング中の料金が取り消される。次いで、方法１３００はステップ１３１２に進み、請求期間の料金が作成される。ステップ１３１４において、価格形成ルールが決定され、ステップ１３１６において、価格が実施される。

【0129】

本開示の少なくとも１つの実施形態においては、ステップ１３１８において、過去に過剰請求された、これまで影響を受けた注文済みの料金に関して、払戻し料金が作成され得る。方法１３００は、ステップ１３２０で終了し、要求された期間の料金が送信されて記憶される。

【0130】

ＩＳＶ格付けエンジン７０２はまた、価格形成ルールについてＩＳＶカタログ８０２からアップデートも受信して、過去のトランザクションに関連するリソースに結び付けられることが理解されるであろう。ＩＳＶ格付けエンジン７０２は、最新価格設定の条件に関連するサービスベンダーの請求期間の最後に、最新価格計算および補正後料金を実施する。すべての補正料金が、方法１２００に開示するような反復コストレポートでＥＲＰシステム７０６に自動的に報告され得ることも理解されるであろう。

【0131】

本開示の少なくとも１つの実施形態においては、ｃｏｓ．計算機７０４が、マーケットプレイスブローカ１２８と再販売業者１０６との間の契約に関してセットアップされた請求期間についての情報を以下のいずれかまでに受け取る。マーケットプレイスブローカ１２８が、再販売業者チェーンを介して、クラウドアプリケーション自体を配信するときまでに受け取る場合があるのだが、この場合はＣＳＢプラットフォームが自身の請求ルール、およびコストの流れを整合させる必要があるすべての請求期間を含む。あるいは、マーケットプレイスブローカ１２８がサードパーティパートナーを有するときまでに受け取る場合があるのだが、この場合は、パートナープラットフォーム自身の請求を含む。このような実施形態においては、マーケットプレイスコンピューティングデバイスが、各パートナーの価格および請求条件を含む階層関係者の契約カタログを含むことになることが理解されるであろう。製品カタログは、マーケットプレイスコンピューティングデバイス内に記憶され得るが、価格設定情報を独立して（すなわち、階層関係者において）記憶する必要性を除外し得ることはさらに理解されるであろう。本開示の少なくとも１つの実施形態においては、このようなマーケットプレイスコンピューティングデバイスは、同じトランザクションメディエータ１３２から連携コネクタ１３０を通じて受信する情報に従って収益を計算するために、およびパートナーの契約カタログからの価格形成ルールおよび請求ルールを実施するために、同じＩＳＶ格付けエンジンを有する。

【0132】

本開示は、図面および上記の説明において例示され詳述されたが、それは、特性においても、例示的であり、限定的でないとみなされるべきである。特定の実施形態のみが示されて説明されたものであり、本開示の精神の範囲に入るすべての変更と修飾が保護されることが望ましいことが理解される。

【図1】

【図1A】

【図1B】

【図2】

【図2A】

【図2B】

【図2C】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図10A】

【図10B】

【図10C】

【図11】

【図12】

【図13】