JP7314273B2 - クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のシステムおよび方法 - Google Patents

Description

本開示は、クラウドサービスブローカ（ＣＳＢ）プラットフォームにおけるソフトウェア配信のシステムおよび方法に関する。詳細には、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のシステムおよび方法に関する。

再販売業者は、サービス所有者が外部の独立系ソフトウェアベンダー（ＩＳＶ）であるクラウドサービスの販売を開始する場合、再販売業者は、クラウドサービスの販売を円滑にするためにクラウドサービスブローカ（ＣＳＢ）プラットフォームを実行する必要があり得る。ＣＳＢは、異なるＩＳＶからの提供を統合した一意のユーザインタフェース（ＵＩ）、サービスに対して異なる制御アクションを実行する（プロビジョニング、削除、変更など）ためのオペレーティングシステム、消費／ライセンス料の計算を実行して、下請け再販売業者および顧客に対する請求書を生成するための請求システムを提供するように構成されることになる。ＣＳＢプラットフォームはまた、複数の異なるサービスベンダー（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｄｒｏｐｂｏｘ（登録商標）、Ｋａｓｐｅｒｓｋｙ Ｌａｂ（登録商標））インタフェースまたは専用コネクタと統合され得る。

いくつかの場合においては、再販売業者は、クラウドサービスとは無関係の他のサービスを既に提供し得る。例として、ハードウェア配布業務の再販売業者は、下請け再販売業者および顧客に請求するためのソリューションを既に埋め込み済みであり得る、ならびに機能しているＣＲＭおよび多くの他のカスタムシステム、またはそのようなシステムの任意の一般的なベンダー（Ｏｒａｃｌｅ、ＱｕｉｃｋＢｏｏｋｓ、ＳａｌｅｓＦｏｒｃｅ、ＳＡＰなど）からのＩＴビジネスシステムを調整済みである。結果として、製品の販売を可能にする内蔵型ＩＴソリューション（クラウドサービスであり得るが、ＩＳＶによって処理される何かでもある）で新たなプラットフォームを開始することは、コストがかかりすぎて効果がない。

他方では、サービスベンダーはまた、ＣＳＢプラットフォームとの複雑な統合プロセスも被り得る。複雑さが、アプリケーションプログラミングインタフェース（ＡＰＩ）の変更を招き、新たなＡＰＩの開発を必要とし、請求ルールの調整などを生じ得る。結果として、統合コストは、多くの期間にわたるプラットフォームチャネルを通じた販売利益を超え得るが、ベンダーが他の類似のＣＳＢプラットフォームとの契約を既に有する場合は、統合プロセスが不可能にさえなり得る。

したがって、クラウドサービスブローカインフラストラクチャ、および詳細には、ベンダーのシステムとの、および再販売業者によって使用されるサードパーティＩＴビジネスシステムとの統合を用いたデジタル製品の搭載および配布の新たな改善されたシステムおよび方法に対する必要性が存在し、これによりベンダーは、１つのＣＳＢシステムと統合して、そのようなベンダーの電子商取引およびＩＴビジネスシステム上に新たなサービス提供を表示することができる。

本開示の少なくとも１つの実施形態においては、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のためのシステムの概略図が示される。システムは、ＩＳＶデバイス、注文システム、ベンダーポータルコンピューティングデバイス、マーケットプレイスコンピューティングデバイス、およびサードパーティコンピューティングデバイスを含む。

本開示の少なくとも１つの実施形態においては、（自身のサービスをＣＳＢプラットフォームと統合したいＩＳＶの）デベロッパは、ベンダーポータルコンピューティングデバイス内でベンダーＵＩポータルを使用し得る。本開示の少なくとも１つの実施形態においては、ＩＳＶのデベロッパは、販売用製品の一般属性を記入するために、ベンダーポータルコンピューティングデバイスを使用し得るが、そのような属性は、例えば、製品名、ロゴ、ＡＰＩコールでさらに使用されることになる製品ＩＤ、ＩＳＶ側からこの製品を所有するアカウント名、プロビジョニング／変更／削除がいかに行われているかを定義する製品フルフィルメントモード、ＣＳＢの簡潔な製品概要およびＣＳＢの製品の詳細概要を含み得る。

本開示の少なくとも１つの実施形態においては、ベンダーポータルコンピューティングデバイスおよび製品カタログは、特定の製品の製品モデルを生成するように構成される。本開示の少なくとも１つの実施形態においては、製品定義は、ＡＰＩコールを通じて機能し得る。

本開示の少なくとも１つの実施形態においては、標準フルフィルメントＡＰＩワークフローが示される。本開示の少なくとも１つの実施形態においては、ＡＰＩコールは、購入注文要求に関連し、購入注文は、ＩＳＶからの複数の製品アイテムを有する単一アセットに関連する。本開示の少なくとも１つの実施形態においては、システムは、反復のまたは１回限りのサービスまたは製品として定義されたアセット、およびこれらのアセットを要求するワークフローを可能にするように構成される。本開示の少なくとも１つの実施形態においては、すべてのそのような要求は、キューに入り、その後、フルフィルメントＵＩを用いてオペレータによって、またはフルフィルメントＡＰＩを通じた統合を介して自動的に、のいずれかで処理される。

実施形態ならびに本明細書に含まれる他の特徴、利点および開示、ならびに、それらを達成する方法は、本開示の様々な例示的実施形態の以下の説明および添付図面を参照することにより明らかになるとともに、本開示は、よりよく理解されるであろう。

本開示の少なくとも１つの実施形態による、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のためのシステムの概略図である。

本開示の少なくとも１つの実施形態による、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のためのシステムおよび方法の例示的なカタログを示す。

本開示の少なくとも１つの実施形態による、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のための方法のワークフローを示す図である。

本開示の少なくとも１つの実施形態による、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のための方法のワークフローを示す図である。

本開示の原理の理解を促進するために、図面に示される実施形態を参照しつつ、特定の言語を用いて記述する。それにもかかわらず、これにより本開示の範囲を限定する意図ではないことが理解されるであろう。

本詳細説明は、コンピュータまたはコンピュータのネットワーク上で実行されるプログラム、データ構造またはプロシージャに関して提示される。システムによって実装されるソフトウェアプログラムは、任意のプログラミング言語、すなわち、インタープリタ型、コンパイル型、またはその他で記述され得る。これらの言語は、Ｘｃｏｄｅ、ｉＯＳ、ｃｏｃｏａ、ｃｏｃｏａ ｔｏｕｃｈ、ＭａｃＲｕｂｙ、ＰＨＰ、ＡＳＰ．ｎｅｔ、ＨＴＭＬ、ＨＴＭＬ５、Ｒｕｂｙ、Ｐｅｒｌ、Ｊａｖａ、Ｐｙｔｈｏｎ、Ｃ＋＋、Ｃ＃、ＪａｖａＳｃｒｉｐｔ、および／またはＧｏプログラミング言語を含み得るが、これらに限定されない。当業者であれば、代わりにまたは上記と組み合わせて他の言語が使用され得ること、および例えば、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、Ｓｙｓｔｅｍ．ｊｓ、Ｚｅｎｄ、Ｓｙ ｍｆｏｎｙ、Ｒｅｖｅｌ、Ｄｊａｎｇｏ、Ｓｔｒｕｔｓ、Ｓｐｒｉｎｇ、Ｐｌａｙ、Ｊｏ、Ｔｗｉｔｔｅｒ Ｂｏｏｔｓｔｒａｐおよびその他などの、ウェブおよび／またはモバイルアプリケーションフレームワークも使用され得ることが理解されるであろうことを、当然ながら理解すべきである。本明細書に開示するシステムおよび方法は、例えばインターネットなどのコンピュータネットワーク上で利用可能なソフトウェアアズアサービスにおいて具現化され得ることをさらに理解すべきである。さらに、本開示は、ウェブサービス、アプリケーションプログラミングインタフェースおよび／または１つ以上のアプリケーションプログラミングインタフェースまたはそれ以外を通じたサービス指向のアーキテクチャを可能にし得る。

ここで図１を参照すると、クラウドサービスブローカインフラストラクチャを用いたデジタル製品の搭載および配布のためのシステムの概略図が示され、概して１００に示す。システム１００は、ＩＳＶデバイス１０２、注文システム１０４、ベンダーポータルコンピューティングデバイス１０６、マーケットプレイスコンピューティングデバイス１１０、およびサードパーティコンピューティングデバイス１３０を含む。

本開示の少なくとも１つの実施形態においては、（自身のサービスをＣＳＢプラットフォームと統合したいＩＳＶの）デベロッパは、ベンダーポータルコンピューティングデバイス１０６内でベンダーＵＩポータルを使用し得る。ＩＳＶがＣＳＢプラットフォームと統合するためには、ＩＳＶは、本明細書でさらに開示するように、ベンダーポータルコンピューティングデバイス１０６を介して製品モデルを作成する必要があり得ることが理解されるであろう。製品モデルのフォーマットには、アプリケーションパッケージング規格（ＡＰＳ）特有の要件がないので、製品モデルを作成する手法は、製品に依存しないことがさらに理解されるであろう。本開示の少なくとも１つの実施形態においては、ＩＳＶのデベロッパは、販売用製品の一般属性を記入するために、ベンダーポータルコンピューティングデバイス１０６を使用し得るが、そのような属性は、例えば、製品名、ロゴ、ＡＰＩコールでさらに使用されることになる製品ＩＤ、ＩＳＶ側からこの製品を所有するアカウント名、プロビジョニング／変更／削除がいかに行われているかを定義する製品フルフィルメントモード、ＣＳＢの簡潔な製品概要およびＣＳＢの製品の詳細概要を含み得る。

本開示の少なくとも１つの実施形態においては、ＩＳＶのデベロッパはまた、製品カタログ１１４内で製品定義および関連するビジネスモデルも設定し得る。本開示の少なくとも１つの実施形態においては、製品カタログ１１４は、ユーザインタフェースを含み得る。製品カタログ１１４は、複数の考えられる製品定義およびビジネスモデルに対応することで、様々な製品を製品カタログ１１４内で調整できるように構成されるので、マーケットプレイスコンピューティングデバイス１１０を製品に依存しないようにすることが理解されるであろう。

ＩＳＶは、製品モデルに関して非常に複雑な構造を有し得ることがさらに理解されるであろう。例として、ＩＳＶは、製品が販売され得る方法についての非常に複雑なルールを有し得る。例えば、製品は、依存性を有し得る、すなわち、第２製品アイテムがユーザによって以前に使用された場合にのみ、第１製品アイテムが存在し得る、あるいは第１再販売業者は、１つの製品アイテムグループのみを販売でき、別の製品アイテムグループを販売できない。別の例として、第１製品アイテムの第１数量は、特定の機能的依存性を介して第２製品アイテムの第１数量の数に依存し得る。

ＩＳＶは、このビジネスロジックを非構造化データ記憶の内部に維持することが理解されるであろう。しかしながら、ＣＳＢマーケットプレイス１１２との統合は、そのような製品が、可能であれば統一され自動で販売されるように、適切にカタログに入れられることを必要とするであろう。したがって、ＩＳＶは、特に自身の製品モデルおよびビジネスルールの統合および自動化を高速且つ効率的にする必要がある場合は、ＩＳＶはそれを行うための課題に直面し得る。

本開示の少なくとも１つの実施形態においては、ＩＳＶは、製品カタログ１１４内に記憶されて処理されるであろう製品モデルを定義する。明確にするためであり定義を限定することなく、製品は、販売可能な（単体でまたはそれ以外）ものとして構成される。本開示の少なくとも１つの実施形態においては、製品は、最小の販売可能な（および逆に購入可能な）商品／アイテムである。本開示の少なくとも１つの実施形態においては、製品アイテムは、財務書類で品目として反映されて計算される製品の一部分である。本開示の少なくとも１つの実施形態においては、製品が購入される場合、少なくとも１つの製品アイテムが購入されなければならず、他のすべては任意となり得る。製品アイテムは、価格を有し得ることが理解されるであろう。本開示の少なくとも１つの実施形態においては、製品提供は、製品に関連する特定の業務提供である。例として、顧客（または再販売業者）が製品を購入する場合、特定の提供は、いくつかの非限定的な例を挙げると、固定の製品価格、通貨、値引き、および他の詳細と共に選択され得る。

ＩＳＶが販売する予定の製品の製品モデルを定義することによって、限定ではないが、製品アイテムＩＤ、製品アイテムの数量、ベンダーシステムからの内部ＩＤおよび同様のものを含む製品属性も定義されることが理解されるであろう。すべての製品アイテムは、ＣＳＢプラットフォーム内の製品アイテムの識別子である最小在庫管理単位（ＳＫＵ）に割り当てられることがさらに理解されるであろう。

本開示の少なくとも１つの実施形態においては、製品アイテムは、複雑な階層構造を有し得る。構造は、本明細書にさらに開示するような複数のルールの少なくとも１つによって定義され得る。本開示の少なくとも１つの実施形態においては、各製品アイテムは、各レベルにおいて一意である。例示的実施形態として、そのような製品は、割り当てられた階層レベルでのみ注文され得る。非限定的な例として、モバイルサービス調達において、購入者は、要望通りにできるだけ多くの電話番号を購入し得るが、さらにすべての関連電話番号によって共有されるであろうデータ／分パッケージも購入することができる。同様に、別の製品においては、電話番号をまず購入して、次にデータ／分パッケージをその後に購入することもあり得る。

上記の例示的実施形態を続けると、構造は、（数量を指定して）１回のみ注文することができ、あるいは最初の注文の後に、数量変更のみを要求できるようなものであり得る。

本開示の少なくとも１つの実施形態においては、各製品アイテムはまた、任意の子製品アイテムがあるか、およびそれらの子製品アイテムが一意であるかまたは集合として構成されるかも定義し得る。別の例示的実施形態として、子製品アイテムは、同じレベルの他の製品アイテムとの非互換性ルールを定義し、子製品アイテムは、親製品アイテムとの互換性ルールを定義し、任意のレベルの各製品アイテムは、同じレベルの別の製品アイテムに遷移するための互換性を定義し得る。

本開示の少なくとも１つの実施形態においては、製品アイテムのキャンセルに対するサポートがあり、リニューアルは任意である（１回限りの料金アイテムおよび同様のもの）。

本開示の少なくとも１つの実施形態においては、契約日の各々（契約応当日、期間、請求、ルールなど）は、特定の階層レベルで設定することができ、それよりも下位レベルにあるアイテムによって継承される。例として、契約日がレベル０で設定されれば、その下にあるすべてのレベルは、それに従う。同様に、契約日がレベル１で設定されれば、レベル１にある製品アイテムの異なる日付は、異なり得るが、それよりも下位のレベルは親に従う。

本開示の少なくとも１つの実施形態においては、各レベルの製品アイテムは、自身に割り当てられた（それらの子によっても可視の）さらなる属性を有し得るが、これらの属性は、製品所有者によって定義することができ、その後、プロビジョニングレベルに渡される。

図２を参照すると、製品モデルコンストラクションツールインタフェースの例示的実施形態が示され、概して２００に示す。インタフェース２００は、レベル１に８製品アイテムを含み（すなわち、２０２、２０４、２０６、２１２、２１８、２２０～２２４）、２つのレベル１製品アイテム（すなわち、２０６および２１２）が、自身の子製品アイテムを有し、２０６は、子製品アイテム２０８および２１０を有し、２１２は、子製品アイテム２１４および２１６を有する。

製品カタログ１１４の一部分であり得るこの製品モデルコンストラクションツールにより、ＩＳＶは、ＩＳＶのビジネスモデルに従って任意の製品構造を構築できることが理解されるであろう。製品モデルコンストラクションツールは、ＡＰＩを介して提供され得ることも理解されるであろう。本開示の少なくとも１つの実施形態においては、製品モデルコンストラクションツールは、例えばＪａｖａＳｃｒｉｐｔオブジェクト表記（ＪＳＯＮ）で、製品モデルのこの表現に基づいてコンピュータ可読ファイルを生成する。コンピュータ可読ファイル（すなわち、ＪＳＯＮフォーマットの）は、ＡＰＩコールを処理するため、および注文情報を含む着信要求を、製品カタログ１１４内に記憶された製品定義に対して妥当性を確認できるようにするために使用され得ることが理解されるであろう。

本開示の少なくとも１つの実施形態においては、ベンダーポータルコンピューティングデバイス１０６および製品カタログ１１４は、特定の製品の製品モデル（インタフェース２００を介して例示的に図示）を生成するように構成される。製品モデルはまた、サードパーティＣＳＢ１３０の電子商取引プラットフォームにも送信され得るが、サードパーティＣＳＢの電子商取引プラットフォームは、電子商取引システム内にこの製品の提供を表示するために、製品モデルからのデータを使用し得ることが理解されるであろう。注文システム１００もまた、製品モデルを記憶して、これにより、製品カタログ１１４は、フルフィルメントマネージャ１２２と動作可能に通信して、システム１００が、この特定の製品を参照する任意のサードパーティＣＳＢ１３０からの要求を、ＩＳＶによって設定された製品定義に従って処理できるようにすることがさらに理解されるであろう。本開示の少なくとも１つの実施形態においては、製品定義は、ＡＰＩコールを通じて機能し得る。

本開示の少なくとも１つの実施形態においては、サードパーティＣＳＢ１３０は、ＣＳＢマーケットプレイス１１２との契約を作成することを望み得る。本開示の少なくとも１つの実施形態においては、ＣＳＢマーケットプレイス１１２は、接続データベース１１６Ａ内に新たな接続を追加して、サードパーティＣＳＢ１３０のために、注文システムにアクセスするためのクレデンシャルのセットを作成するように構成される。システム１００は、サードパーティＣＳＢ１３０からのポスティングＡＰＩコールを受信するように構成される。本開示の少なくとも１つの実施形態においては、サードパーティＣＳＢ１３０は、製品提供を表示するために、製品モデルからのデータを任意で表示し得る。いくつかの実施形態においては、サードパーティＣＳＢ１３０は、内部システム（例えば、ＱｕｉｃｋＢｏｏｋｓ、ＳａｌｅｓＦｏｒｃｅ、Ｏｒａｃｌｅおよびその他）における製品とのアクションの自動トラッキングのために、内部電子商取引システムと製品モデルをさらに統合するために製品モデルを組み込み得る。

本開示の少なくとも１つの実施形態においては、統合レイヤは、任意であり、サードパーティＣＳＢ１３０のＡＰＩを注文システム１００の標準ポスティングＡＰＩに変換することを目的とする。ここで図３を参照すると、標準フルフィルメントＡＰＩのワークフローが示され、概して３００に示す。

本開示の少なくとも１つの実施形態においては、ＡＰＩコールは、購入注文要求に関し、購入注文は、ＩＳＶからの複数の製品アイテムを有する単一アセットに関する。システム１００は、反復のまたは１回限りのサービスまたは製品として定義されたアセット、およびこれらのアセットを要求するワークフローを可能にするように構成される。本開示の少なくとも１つの実施形態においては、すべてのそのような要求は、キューに入り、その後、フルフィルメントＵＩ１２６を用いてオペレータによって、またはフルフィルメントＡＰＩ１２４を通じた統合を介して自動的に、のいずれかで処理される。

本開示の少なくとも１つの実施形態においては、アセットは、以下を特徴とする：（ｉ）すべてのアセットは、何らかの購入を反映する（誰かがサービスまたは商品のいずれかを購入する）。（ｉｉ）購入要求は、購入期間が過ぎた場合に、取り消し（キャンセル）または終了することができる。（ｉｉｉ）アセットは、サブスクリプションベース（顧客が、何らかの期間における使用量に対して支払う場合）または１回限りベースとすることができる。（ｉｖ）アセットの内容は、購入数量（アセットアイテム）を伴う購入済みＳＫＵのリストとして定義される。（ｖ）アセット内のアイテムは、いくつのＳＫＵのアイテムを購入するかを顧客が決定する場合には予約ベースで、あるいはＳＫＵの実際の使用がアセットアイテムの数量を定義する場合には「ユーザあたりの支払い（ｐａｙ－ｐｅｒ－ｕｓｅｒ）」ベースのいずれかとなり得る。（ｖｉ）アセットは、変更要求を用いて修正され得る。アイテムセットが変更され得るか、または予約ベースのアイテムの数量が変更され得るかのいずれか。（ｖｉｉ）サービスが実際には提供されておらず、料金が発生しなかった場合、いくつかのアセットが一時停止状態に入れられる。（ｖｉｉｉ）アセットはまた、１つのアセットを別のものと区別する１つ以上のパラメータによってもパラメータ化され得る。

本開示の少なくとも１つの実施形態においては、フルフィルメントマネージャ１２２は、アセットを追跡して、要求の妥当性をチェックして、要求からの情報によって、製品カタログ１１４内で設定された製品モデルに対してこれをチェックする。

各ＩＳＶは、サードパーティＣＳＢ１３０のプラットフォームロジックとは独立して、製品に依存しないＡＰＩ（すなわち、フルフィルメントＡＰＩ１２４）を用いて注文システムと相互作用することができることが理解されるであろう。このフルフィルメントＡＰＩ１２４は、動作（例えば、購入、変更、削除）またはＩＳＶによって所有される製品とは独立した一貫した方法で、サードパーティＣＳＢ１３０プラットフォームによって生成された異なる要求で動作するためのベーシックエンドポイントを送達する。

本開示の少なくとも１つの実施形態においては、ＡＰＩに利用可能な動作は以下の通り：（ｉ）要求リスト取得（Ｇｅｔ Ｒｅｑｕｅｓｔｓ Ｌｉｓｔ）－ＧＥＴ／ｒｅｑｕｅｓｔｓ、（ｉｉ）要求詳細取得（Ｇｅｔ Ｒｅｑｕｅｓｔ Ｄｅｔａｉｌｓ）－ＧＥＴ／ｒｅｑｕｅｓｔｓ／｛ｉｄ｝、（ｉｉｉ）データの修正要求（Ｍｏｄｉｆｙ Ｒｅｑｕｅｓｔ Ｄａｔａ）－ＰＵＴ／ｒｅｑｕｅｓｔｓ／｛ｉｄ｝およびＰＡＴＣＨ／ｒｅｑｕｅｓｔｓ／｛ｉｄ｝、ならびに（ｉｖ）要求ステータス変更（Ｃｈａｎｇｅ Ｒｅｑｕｅｓｔ Ｓｔａｔｕｓ）－ＰＯＳＴ／ｒｅｑｕｅｓｔｓ／｛ｉｄ｝／｛ｓｔａｔｕｓ｝

本開示の少なくとも１つの実施形態においては、ＧＥＴ要求方法が、ベンダーに利用可能な要求オブジェクトの集合を提供する場合は、さらなるフィルタリングが、フルフィルメントシステムによって返された要求を制限することが可能である。利用可能なフィルタは、以下を含む：（ｉ）要求ステータスは、ペンディング中、問い合わせ中、承認または失敗である、（ｉｉ）特定の日付後に作成、（ｉｉｉ）具象アセットの場合は、具象アセットに関連するすべての注文を取得、（ｉｖ）具象製品に関しては、ＩＳＶが同時に複数の製品を提供。

本開示の少なくとも１つの実施形態においては、返されるオブジェクトの各々は、一意の要求を表し、これらの各々は、以下を提供する：（ｉ）要求の一意の識別子（ＩＤ）、（ｉｉ）要求のタイプであり、可能な値は以下の通り：（ａ）購入：新たなアセットの初期要求。（ｂ）変更：購入済みアイテムに関連する既存アセットへの修正であり、１つのアセットが、そのライフサイクルにおいて複数の変更要求を有し得る。（ｃ）キャンセル：具象アセットを終了させる要求に関連する。一時停止：一時停止されたアセットをＩＳＶプラットフォーム上に一時的に配置するため。（ｄ）再開：以前に一時停止されたアセットを正常状態に戻すための要求。（ｉｉｉ）ステータス：要求のワークフロー／ライフサイクルに基づいて可能なステータスのうちの任意。（ｉｖ）アセット構造は、以下についての情報を含む：（ａ）注文システムからのアセットの一意の識別子。（ｂ）具象製品要求が何のためであるかを識別するための一意の製品情報。（ｃ）アセットが結び付けられたＩＳＶとＣＳＢマーケットプレイス１１２との間の正確な契約を識別するための接続情報。（ｄ）要求に関与する異なる企業に関連する具象情報で、顧客情報または中間再販売業者のうちの任意である（ＣＳＢマーケットプレイス１１２情報は、製品セクタ別にまたは地理別に送達されることが理解されるであろう）。（ｅ）ＩＳＶシステム上のアセットに関連するか、または要求を完了できるように注文パラメータに関連するかのいずれかの具象パラメータ情報。または（ｆ）ＩＳＶ ＭＰＮ識別子に基づいて（もしくはＣＳＢマーケットプレイス用語で言えば、ＳＫＵ別に）購入されたアイテムであり、提供される情報は、新たな購入の数量または変更注文の場合は前の数量さえも含む。

ペイロードの例示的実施形態を、ここに示す：

本開示の少なくとも１つの実施形態においては、ＩＳＶは、要求のパラメータのみを変更して、ワークフローにわたって要求を移動させることができる。例として、パラメータを更新するために、要求ＩＤに対するＰＵＴが必要であり、ボディ上のデータは、新たな値、または顧客によって提供された値がなぜ誤っているかの理由をｖａｌｕｅ＿ｅｒｒｏｒの修正を介して含み得る。ボディの／ｒｅｑｕｅｓｔｓ／｛ｉｄ｝へのｐｕｔの例が、本開示の少なくとも１つの実施形態に従って提供される：

本開示の少なくとも１つの実施形態においては、パラメータの更新により、ＩＳＶは、以下を行うことができる：（ｉ）さらなるデータを要求するかまたは提供されたデータを補正するために、購入者との相互作用。（ｉｉ）同じアセットに対する新たな要求に対して将来的に使用するために、注文システム上に情報を記憶。

ポスティングＡＰＩにより、要求オブジェクトの作成を可能にして、これにより、フルフィルメントＡＰＩをアドオンと一致させて、アドオンは、外部商取引が、ベンダーには開示されないであろうｅｘｔｅｒｅｎａｌ＿ａｔｔｒｉｂｕｔｅｓ（外部属性）も渡せるようにして、そのような属性は、商取引システム（例えば、ＣＳＢプラットフォーム）によってのみ使用されて、報告を使用するため、または、内部で自身が作成した要求と一致／照合するための要求の検索のときにさえ使用することが理解されるであろう。これは、このような配列で言及するように、要求オブジェクトを拡張する：

本開示の少なくとも１つの実施形態においては、１つまたは複数の要求によって定義されるアセットは、長期にわたって複数の要求を生成するサードパーティＣＳＢ１３０のプラットフォームによって制御される完全なライフスタイルを有する。完全なアセットライフサイクルは、図４に示すワークフローによって包含され得る。

本開示の少なくとも１つの実施形態においては、アセットは、顧客によって取得された、限られた数のアイテムを有する製品のインスタンスを表す。図４を参照すると、本開示の少なくとも１つの実施形態による、アセットを指し示す複数の要求によって修正されたライフサイクルが示される。要求の各タイプは、これに応じてアセットのステータスを修正することになる。例として、「ＮＥＷ（新規）」ステータスのアセットは、購入要求が発行されたが、責任者によってすべてのパラメータがまだ記入されていないことを意味し、ＩＳＶは、まだアセットを認識していない。この例を続けると、「ＰＲＯＣＥＳＳＩＮＧ（処理中）」ステータスのアセットは、ＩＳＶが購入要求または変更要求の処理をまだ実行中であり、アセットは、購入者にはまだ送達されていないが、購入者には作業が進行中であることが通知されることを意味する。ステータス「ＲＥＪＥＣＴＥＤ（拒否）」のアセットは、ＩＳＶが（様々な考えられる理由で）購入要求に失敗したこと、およびオブジェクトが最終的な回復不能ステータスを受信することを意味し、「ＡＣＴＩＶＥ（アクティブ）」ステータスのアセットは、ＩＳＶが変更／購入／再開要求を完了しており、アセットが作動していて、購入者によって使用可能であることを意味し、「ＳＵＳＰＥＮＤＥＤ（一時停止）」ステータスのアセットが発生するのは、管理保留通知が一時停止要求を介して送信される場合であり、「ＴＥＲＭＩＮＡＴＥＤ（終了）」ステータスのアセットは、キャンセル要求を完了する最終的な回復不能ステータス結果を意味し、アセットオブジェクトは破棄されずに、トラッキング／報告目的のためにシステム上に残る。

本開示は、様々な実施形態を有するものとして説明してきたが、本開示によるこれらの実施形態は、本開示の範囲および精神内でさらに修正可能である。したがって、本願は、一般原則を用いて本開示の任意の変形、使用または適応を包含することが意図される。例えば、本明細書に開示される任意の方法は、これらのステップを実行する１つの考えられる順序を表す。実践者は、開示する方法のうちの１つ以上の複数のステップを結合可能であり得ること、または同じ結果を得るために、ステップの異なる順序が採用され得ることを、特定の実装で決定し得る。このような各実装は、本明細書および添付の特許請求の範囲に開示されるような本開示の範囲内に含まれる。さらに、本願は、本開示が関係する技術分野における既知の実践または慣行に含まれるような、本開示からのこのような逸脱を包含することが意図される。

Claims (7)

1. ＣＳＢインフラストラクチャを用いたデジタル製品の搭載および配布の方法であって、
   前記ＣＳＢインフラストラクチャは、独立系サービスベンダーのデバイスと、サードパーティクラウドサービスブローカ（ＣＳＢ）のデバイスと、ＣＳＢマーケットプレイスのデバイスと、注文システムとを備え、
   前記独立系サービスベンダーに係るベンダーポータルコンピューティングデバイスにおいて製品モデルを作成することであって、前記製品モデルは少なくとも部分的に第１製品に基づくことと、
   前記製品モデルを前記ＣＳＢマーケットプレイスに設けられた製品カタログにおいて記憶することと、
   前記製品モデルを前記サードパーティクラウドサービスブローカ（ＣＳＢ）のプラットフォームに前記ＣＳＢマーケットプレイスからエクスポートすることと、
   前記製品モデルを前記注文システムに前記ＣＳＢマーケットプレイスからエクスポートすることと、
   前記第１製品の統合要求（統合の要求）を受信可能なようにＡＰＩs（一つあるいは複数のアプリケーションプログラミングインタフェース）を構成することと、
   前記注文システムにおいて、前記第１製品の前記統合要求を受信することであって、前記統合要求は、製品モデルペイロードの要求を含むことと、
   前記注文システムにおいて、少なくとも部分的に製品属性に基づいて、前記第１製品の前記統合要求をフルフィリングすることとを含み、
   前記製品モデルは、製品階層を含み、
   前記製品階層は、少なくとも１つの親アイテムを含み、
   前記製品モデルは、製品モデルコンストラクションツールを使用して作成されるコンピュータ可読ファイルを備えており、
   前記製品モデルコンストラクションツールは、前記ＡＰＩs（一つあるいは複数のアプリケーションプログラミングインタフェース）を介して供給されるものであり、
   前記サードパーティクラウドサービスブローカ（ＣＳＢ）の前記プラットフォームは、前記第１製品の提供を表示するために、前記製品モデルからのデータを使用し、
   前記統合は、前記サードパーティクラウドサービスブローカ（ＣＳＢ）の前記ＡＰＩs（一つあるいは複数のアプリケーションプログラミングインタフェース）を前記注文システムの標準ポスティングＡＰＩに変換するように作用する、
   ＣＳＢインフラストラクチャを用いたデジタル製品の搭載および配布の方法。
2. 前記製品モデルは、ＪａｖａＳｃｒｉｐｔオブジェクト表記（ＪＳＯＮ）ファイルを含む、請求項１に記載の方法。
3. 前記統合要求は、前記サードパーティＣＳＢの前記プラットフォームから送信されて、前記注文システムによって受信される、請求項１に記載の方法。
4. 前記統合要求は、独立系サービスベンダー統合レイヤから送信されて、前記注文システムによって受信される、請求項１に記載の方法。
5. 前記統合要求は、フルフィルメントユーザインタフェースまたはフルフィルメントＡＰＩを介して前記注文システムによって受信される、請求項３に記載の方法。
6. 前記統合要求は、購入アクション、キャンセルアクション、一時停止アクション、および再開アクションからなるグループから選択される、請求項１に記載の方法。
7. 前記統合要求は、要求リスト、要求詳細、修正要求、および変更要求から選択された動作をさらに含む、請求項６に記載の方法。