(57)【特許請求の範囲】
【請求項１】
通信インターフェースと、
ユーザに関連付けられ、前記ユーザのセンサデバイスから入手可能である利用可能な入力タイプ及びサービスを指定する、ユーザプロフィールであって、前記利用可能な入力タイプは前記ユーザの生理学的パラメータである、ユーザプロフィール、並びに
複数のサービスレコードは、当該サービスレコードに関連付けられる、前記サービス、入力タイプ、前記サービスの出力タイプ、及び前記サービスを提供するサーバを識別するための情報であり、前記出力タイプは別の生理学的パラメータである、当該複数のサービスレコード
を記憶したメモリと、
前記通信インターフェース及び前記メモリと通信状態にあるプロセッサであって、
前記通信インターフェースを介して前記ユーザから、前記複数のサービスレコードのうちの第１のサービスレコードに関連付けられた前記サービスを前記ユーザに対して追加する要求を受け取ることであって、前記サービスレコードは、前記ユーザプロフィールによって指定される前記利用可能な入力タイプが、前記サービスを提供するための入力として前記サーバによって受理されることを示す、ことと、
前記サービスレコードに関連付けられた前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行することと、
追加的な入力タイプの提供元となる追加的なセンサデバイスにより提供される前記サービスを前記ユーザプロフィールに追加することであって、前記追加的な入力タイプは前記サービスレコードによって識別される前記出力タイプである、当該追加することと、
を行うプロセッサとを備える、サービスブローカーデバイス。
【請求項２】
前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する際に、前記プロセッサは、
入力装置に構成情報を送信し、前記入力装置は、前記ユーザの前記センサデバイスと、前記センサデバイスから前記データを受け取る報告フレームワークデバイスとのうち少なくとも１つであり、
前記構成情報は、前記サービスレコードによって識別される前記サーバに前記入力装置が直接前記データを送信するための当該サーバを示す情報である、請求項１に記載のサービスブローカーデバイス。
【請求項３】
前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する際に、前記プロセッサは、
前記サービスレコードによって識別される前記サーバに資格証明情報を送信し、前記資格証明情報は、許可トークンであり、前記サーバが、前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも１つに前記データを要求することを可能にする、請求項１に記載のサービスブローカーデバイス。
【請求項４】
前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する際に、前記プロセッサは、
前記サービスレコードによって識別される前記サーバに前記データを転送すべき旨の指示を前記ユーザと関連付けて記録し、
前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも１つから前記データを受け取り、
記録された前記指示に基づいて、受け取った前記データを前記サーバに送信する、請求項１に記載のサービスブローカーデバイス。
【請求項５】
前記サービスレコードは、送信の前に行われるべき入力処理アクションに関連付けられており、
前記プロセッサはさらに、受け取った前記データを前記サーバに送信する前に、前記入力処理アクションに従って前記データを修正する、請求項４に記載のサービスブローカーデバイス。
【請求項６】
前記プロセッサはさらに、前記サービスを追加する前記要求に応答して、前記ユーザと前記サービスの提供者とのうち少なくとも１つに対する課金を遂行する、請求項１に記載のサービスブローカーデバイス。
【請求項７】
前記プロセッサはさらに、
前記ユーザに利用可能なサービスのセットを、ユーザから入手可能であるとユーザプロフィールで示される、前記利用可能なサービスのそれぞれの入力タイプに基づいて識別し、
前記利用可能なサービスのセットを、前記ユーザに対して追加する個々のサービスの選択のために前記ユーザに提示する、請求項１に記載のサービスブローカーデバイス。
【請求項８】
前記プロセッサはさらに、
前記ユーザから第１の追加的なサービスの選択を受け取ることであって、前記第１の追加的なサービスは、前記複数のサービスレコードのうち追加的なサービスレコードに関連付けられている、ことと、
前記追加的なサービスレコードによって識別される追加的な入力タイプが前記ユーザから入手可能であると識別されないことを、前記ユーザプロフィールに基づいて判定することと、
前記追加的な入力タイプを提供するであろう少なくとも１つの提案品を前記ユーザに提示することと
を行う、請求項１に記載のサービスブローカーデバイス。
【請求項９】
前記提案品は、前記追加的な入力タイプを出力として提供する第２の追加的なサービスを含んでいる、請求項８に記載のサービスブローカーデバイス。
【請求項１０】
ウェアラブルデバイスを介して提供されるサービスを拡張するためにサービスブローカーデバイスのプロセッサによって行われる方法であって、前記方法は、前記プロセッサが、
ユーザのセンサデバイスから入手可能である利用可能な入力タイプの識別を前記ユーザから受け取るステップであって、前記利用可能な入力タイプは前記ユーザの生理学的パラメータである、ステップと、
サービスを追加する要求を前記ユーザから受け取るステップであって、前記サービスは、前記利用可能な入力タイプを入力として受理することが知られており、出力タイプを有する出力を提供し、前記出力タイプは別の生理学的パラメータである、ステップと、
前記サービスを提供するサーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記利用可能な入力タイプとの送信を遂行するステップと、
追加的な入力タイプの提供元となる追加的なセンサデバイスにより提供される前記サービスをユーザプロフィールに追加するステップであって、前記追加的な入力タイプは前記出力タイプである、ステップと、
を含む、方法。
【請求項１１】
サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する前記ステップは、
入力装置に構成情報を送信するステップであって、前記入力装置は、前記ユーザの前記センサデバイスと、前記センサデバイスから前記データを受け取る報告フレームワークデバイスとのうち少なくとも１つである、ステップを含み、
前記構成情報は、前記サービスレコードによって識別される前記サーバに前記入力装置が直接前記データを送信するための当該サーバを示す情報である、請求項１０に記載の方法。
【請求項１２】
サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する前記ステップは、
前記サービスレコードによって識別される前記サーバに資格証明情報を送信するステップを含み、前記資格証明情報は、許可トークンであり、前記サーバが、前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも１つに前記データを要求することを可能にする、請求項１０に記載の方法。
【請求項１３】
サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する前記ステップは、
前記サービスレコードによって識別される前記サーバに前記データを転送すべき旨の指示を前記ユーザと関連付けて記録するステップと、
前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも１つから前記データを受け取るステップと、
記録された前記指示に基づいて、受け取った前記データを前記サーバに送信するステップとを含む、請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
[0001]  本出願は、２０１５年２月９日に出願された「Ｗｅａｒａｂｌｅｓ  ａｓ  ａ  ｓｅｒｖｉｃｅ」という名称の米国仮出願第６２／１１３，９９９号の優先権の利益を主張し、同仮出願の全開示内容は、あらゆる目的のために参照により本明細書に組み込まれる。
【０００２】
[0002]  本明細書に記載される様々な実施形態はウェアラブルデバイスに関し、より詳細には、ただしこれに限らないが、追加されたサービスを通じてウェアラブルデバイスの機能を拡張するためのフレームワークに関する。
【背景技術】
【０００３】
[0003]  ウェアラブル技術には、身体に着用したり、個人の衣類やアクセサリーに取り付ける又は埋め込むことが可能で、現在消費者及び医療市場に存在する、任意タイプのモバイル電子デバイスが含まれ得る。ウェアラブル技術に関連するプロセッサ及びセンサは、情報を表示、処理、収集する、又は導き出すことができる。そのようなウェアラブル技術は、ユーザの健康データや他のタイプのデータ及び統計を監視することを含む幅広い領域で使用されることがある。これらのタイプのデバイスは、一般大衆が容易に入手することができ、消費者によって容易に購入することができる。健康関連の領域におけるいくつかのウェアラブル技術の例として、ＦＩＴ  ＢＩＴ、ＮＩＫＥ＋  ＦＵＥＬ  ＢＡＮＤ、及びＡＰＰＬＥ  ＷＡＴＣＨデバイスが挙げられる。
【発明の概要】
【０００４】
[0004]  本明細書に記載される様々な実施形態は、サービスブローカーデバイスに関し、このサービスブローカーデバイスは、通信インターフェースと；ユーザに関連付けられ、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプを指定する、ユーザプロフィールであって、入力タイプはユーザの生理学的パラメータである、ユーザプロフィール、並びに、複数のサービスレコードであって、複数のサービスレコードのうち第１のサービスレコードは、サービス、入力タイプ、及びサービスを提供するサーバに関連付けられている、複数のサービスレコードを記憶したメモリと；通信インターフェース及びメモリと通信状態にあるプロセッサであって、通信インターフェースを介してユーザから、複数のサービスレコードのうち第１のサービスレコードに関連付けられたサービスをユーザに対して追加する要求を受け取ることであって、サービスレコードは、ユーザプロフィールによって指定される利用可能な入力タイプが、サービスを提供するための入力としてサーバによって受理されることを示すことと、サービスレコードに関連付けられたサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行することとを行うように構成されたプロセッサと、を備える。
【０００５】
[0005]  本明細書に記載される様々な実施形態は、ウェアラブルデバイスを介して提供されるサービスを拡張するためにサービスブローカーデバイスのプロセッサによって行われる方法に関し、この方法は、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプの識別をユーザから受け取るステップであって、入力タイプはユーザの生理学的パラメータである、ステップと、サービスを追加する要求をユーザから受け取るステップであって、サービスは上記利用可能な入力タイプを入力として受理することが知られている、ステップと、そのサービスを提供するサーバへの、ユーザのセンサデバイスによって集められたデータと、利用可能な入力タイプとの送信を遂行するステップと、を含む。
【０００６】
[0006]  本明細書に記載される様々な実施形態は、ウェアラブルデバイスを介して提供されるサービスを拡張するためにサービスブローカーデバイスのプロセッサによって実行するための命令が符号化された非一時的な機械可読記憶媒体に関し、この非一時的な機械可読記憶媒体は、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプの識別をユーザから受け取るための命令であって、入力タイプはユーザの生理学的パラメータである、命令と、サービスを追加する要求をユーザから受け取るための命令であって、サービスは利用可能な入力タイプを入力として受理することが知られている、命令と、そのサービスを提供するサーバへの、ユーザのセンサデバイスによって集められたデータと、利用可能な入力タイプとの送信を遂行するための命令と、を含む。
【０００７】
[0007]  様々な実施形態が記載され、それらの実施形態では、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行する際に、プロセッサは、入力装置に構成情報を送信するように構成され、入力装置は、ユーザのセンサデバイスと、センサデバイスからデータを受け取る報告フレームワークデバイスとのうち少なくとも１つであり、構成情報は、サービスレコードによって識別されるサーバに直接データを送信するように入力装置を構成する。
【０００８】
[0008]  様々な実施形態が記載され、それらの実施形態では、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行する際に、プロセッサは、サービスレコードによって識別されるサーバに資格証明情報を送信するように構成され、資格証明情報は、サーバが、ユーザのセンサデバイスと、センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも１つにデータを要求することを可能にする。
【０００９】
[0009]  様々な実施形態が記載され、それらの実施形態では、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行する際に、プロセッサは、サービスレコードによって識別されるサーバにデータを転送すべき旨の指示をユーザと関連付けて記録し、ユーザのセンサデバイスと、センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも１つからデータを受け取り、記録された指示に基づいて、受け取ったデータをサーバに送信するように構成される。
【００１０】
[0010]  様々な実施形態が記載され、それらの実施形態では、サービスレコードは、送信の前に行われるべき入力処理アクションを識別し、プロセッサは、受け取ったデータをサーバに送信する前に、入力処理アクションに従ってデータを修正するようにさらに構成される。
【００１１】
[0011]  様々な実施形態が記載され、それらの実施形態では、サービスレコードは、上記サービスの出力タイプに関連付けられており、出力タイプは別の生理学的パラメータであり、プロセッサは、追加的な入力タイプの提供元となる追加的なセンサデバイスとしてサービスをユーザプロフィールに追加するようにさらに構成され、追加的な入力タイプは、そのサービスレコードによって識別される出力タイプである。
【００１２】
[0012]  様々な実施形態が記載され、それらの実施形態では、プロセッサは、サービスを追加する要求に応答して、ユーザとサービスの提供者とのうち少なくとも１つに対する課金を遂行するようにさらに構成される。
【００１３】
[0013]  様々な実施形態が記載され、それらの実施形態では、プロセッサは、ユーザに利用可能なサービスのセットを、ユーザから入手可能であるとユーザプロフィールで示される、利用可能なサービスのそれぞれの入力タイプに基づいて識別し、その利用可能なサービスのセットを、ユーザに対して追加する個々のサービスの選択のためにユーザに提示するようにさらに構成される。
【００１４】
[0014]  様々な実施形態が記載され、それらの実施形態では、プロセッサは、ユーザから第１の追加的なサービスの選択を受け取ることであって、第１の追加的なサービスは、複数のサービスレコードのうち追加的なサービスレコードに関連付けられていることと、追加的なサービスレコードによって識別される追加的な入力タイプがユーザから入手可能であると識別されないことを、ユーザプロフィールに基づいて判定することと、追加的な入力タイプを提供するであろう少なくとも１つの提案品をユーザに提示することとを行うようにさらに構成される。
【００１５】
[0015]  様々な実施形態が記載され、それらの実施形態では、提案品は、上記追加的な入力タイプを出力として提供する第２の追加的なサービスを含んでいる。
【００１６】
[0016]  様々な例示的実施形態をよりよく理解するために、添付図面が参照される。
【図面の簡単な説明】
【００１７】
【図１】[0017]  サービスとしてのウェアラブルを提供するシステムの例を示す図である。
【図２】[0018]  本明細書に記載される様々なシステムに参加する様々なデバイスを実施するためのハードウェアの例を示す図である。
【図３】[0019]  例示的なサービスブローカーフレームワークを示す図である。
【図４】[0020]  サービスとしてのウェアラブルを提供するための環境の例を示す図である。
【図５】[0021]  新しいサービスを定義するためのインターフェースの例を示す図である。
【図６】[0022]  新しい提案品を定義するためのインターフェースの例を示す図である。
【図７】[0023]  ユーザプロフィールを定義するためのデータ配置の例を示す図である。
【図８】[0024]  ユーザについてセンサデバイスを登録する方法の例を示す図である。
【図９】[0025]  提案品を閲覧するための例示的インターフェースを示す図である。
【図１０】[0026]  提案品の推薦を生成する方法の例を示す図である。
【図１１】[0027]  予測モデルを訓練する方法の例を示す図である。
【図１２】[0028]  サービスの詳細を表示する方法の例を示す図である。
【図１３】[0029]  ユーザに対する新しいサービスを追加するためのインターフェースの例を示す図である。
【図１４】[0030]  提案品の購入を遂行する方法の例を示す図である。
【図１５】[0031]  入力の共有を容易にする方法の例を示す図である。
【図１６】[0032]  出力の提示を容易にする方法の例を示す図である。
【発明を実施するための形態】
【００１８】
[0033]  本明細書に提示される説明及び図面は、様々な原理を例示する。当業者は、本明細書に明示的には記載又は示されないもののそれらの原理を具現化し本開示の範囲に含まれる様々な構成を考案できることが認識されよう。本明細書で使用される場合、用語「又は」は、別途指示されない限り（例えば、「さもなければ（ｏｒ  ｅｌｓｅ）」又は「又は代替では（ｏｒ  ｉｎ  ｔｈｅ  ａｌｔｅｒｎａｔｉｖｅ）」）、非排他的な又は（すなわち、及び／又は）を意味する。また、本明細書に記載される様々な実施形態は、必ずしも相互に排他的ではなく、組み合わせて、本明細書に記載される原理を組み込んだ追加的な実施形態を作り出すことが可能である。
【００１９】
[0034]  多様なセンサのセットを有する多くの異なるウェアラブルデバイスが入手可能になっているが、それらのセンサの使用は、通例はデバイス製造者に結び付けられている。例えば、デバイスは、センサデータを解釈する（例えば生の加速度計データを歩数に変換する）アルゴリズムがあらかじめ組み込まれて出荷されることがあるが、そのアルゴリズムは、後に改良、拡張、又はその他の更新を行うことはできない。別の例として、ウェアラブルデバイスは、パラメータ（センサからの生のパラメータと内蔵アルゴリズムによって生成されるコンピュータパラメータの両方）を製造者のサーバに報告することがあり、製造者はその後、追加的な処理、編成、提示、及び他のサービスを提供する。しかし、これらのリモートサービスは、製造者が開発し、ホストし、その他のやり方で提供できる事柄に依然として結び付けられている。
【００２０】
[0035]  ウェアラブルデバイスのこれら及び他の態様に対処するために、本明細書に記載される様々な実施形態は、様々なウェアラブルデバイス製造者によって設定された堅固なフレームワークの外側でウェアラブルデバイスユーザに新しいサービスを提供するためのフレームワークに関する。いくつかの実施形態によれば、サービスブローカーフレームワークにより、ユーザは、ウェアラブルデバイス（及び他のデバイス）によって提供される、そのユーザが利用可能なセンサを登録し、第３者によって供されるサービスを購入し、追加されたサービスとそのサービスの動作が依存するセンサとの間の通信を容易にすることができる。
【００２１】
[0036]  図１は、サービスとしてのウェアラブルを提供するシステム１００の例を示す。図示されるシステム１００は、様々な機能構成要素とそれらの間の対話の一部を示している。そのような機能構成要素は、物理ハードウェア、及びいくつかの実施形態ではそのハードウェアによって実行されるソフトウェアを使用して実施されることが認識されよう。したがって、各機能デバイス又はエンジンは、専用ハードウェアデバイスとして具現化され得る。加えて、いくつかの実施形態では、システム１００の機能デバイスの２つ以上が単一のハードウェアデバイスとして具現化され得る。例えば、いくつかの実施形態では、いくつかのセンサデバイス１１０、消費者出力装置１３０、及び消費者構成デバイス１４０が、例えば、十分なユーザインターフェース能力を備えた、モバイルデバイス、タブレット、又はウェアラブルデバイス等の単一のデバイスとして具現化される。
【００２２】
[0037]  システム１００は、いくつかの機能デバイスを単一のデバイスとして示し、他の機能デバイスを複数の同様のデバイスを含むものとして示しているが、代替の機構が可能であることが理解されよう。例えば、代替のシステムは、１つのみのセンサデバイス１１０を使用するが、複数の冗長なサービスブローカーフレームワーク１２０を含むことも可能である（例えば、図示されない負荷分散メカニズムを備えることにより、要求、ユーザデータ、又は他の利用性のある情報をそれらのサービスブローカーフレームワーク１２０間に均等に分配して、サービスブローカーフレームワーク１２０が多数の着用者及びセンサデバイス１１０に対応できるようにする）。
【００２３】
[0038]  センサデバイス１１０は、ユーザに関するデータ、ユーザの環境、ユーザの状況、ユーザに関連する様々な電子機器の状態等を感知することが可能な、実質的に任意のセンサであってよい。いくつかの実施形態では、センサデバイス１１０は、ユーザに関する生理学的パラメータを感知する。例えば、センサデバイス１１０は、加速度計、コンダクタンスセンサ、光学センサ、温度センサ、マイクロフォン、カメラ等を含み得る。これら又は他のセンサは、着用者を記述する生理学的パラメータを感知、算出、推定、又はその他のやり方で獲得するのに有用である可能性があり、そのようなパラメータには、例えば、歩数、歩行／走行距離、立っている時間数、心拍数、呼吸数、血圧、ストレスレベル、体温、消費カロリー、安静時のエネルギー消費、活動時のエネルギー消費、身長、体重、睡眠の測定値等がある。
【００２４】
[0039]  多くの有用なパラメータをセンサデバイス１１０から直接取得することができるのに対し、他の有用なパラメータは、他の利用可能データ（センサデータを含む）から「抽出する」ことによって取得される。例えば、生の加速度計データを処理して、歩数、消費カロリーの推定値、又はユーザによって行われている活動（例えば、走る、テニスをする、自転車に乗る等）の推定を抽出することができる。したがって、システム内の様々なデバイスが、利用可能なパラメータ（例えば、感知されたパラメータ及び他の抽出されるパラメータ）を処理して新しいパラメータを生成するパラメータ抽出アルゴリズムを実施することができる。いくつかの実施形態では、センサデバイス１１０は、アルゴリズムが依存するパラメータを取得するセンサの少なくとも一部と同じデバイスの中でパラメータ抽出を行うために、又は、ユーザにとってローカルであるが、必ずしもプレディケートセンサと同じデバイス内ではないパラメータ抽出を行うために、そのようなアルゴリズムを実施することができる。例えば、いくつかの実施形態では、ウェアラブルブレスレットが加速度計データをユーザのモバイルデバイスに報告し、モバイルデバイスは次いでアルゴリズムを適用し、加速度計データを使用して歩数を推定する。それに加えて、又はそれに代えて、実質的にあらゆるデバイスが、そのようなパラメータ抽出アルゴリズムを適用してもよい（それらのアルゴリズムは、場合によっては、本明細書に記載されるシステム及び方法に従ってサービスとして提供される）。例えば、報告フレームワーク１１５、サービスブローカーフレームワーク１２０、サービスアプリケーションデバイス１２５、消費者出力装置１３０、又は何らかの他のデバイス（図示されている、又は図示されていないもの）が、デバイスに入手可能な入力パラメータからのパラメータ抽出を行うことができる。そのような他のデバイスが、他のサービスへの入力として使用され得るパラメータを抽出できる限りにおいて、そのような他のデバイスは、それら自体をセンサデバイス１１０とみなすことができる。例えば、加速度計データを処理して消費カロリーを推定するサービスアプリケーションデバイス１２５は、他のサービスにカロリーの推定値を提供するセンサデバイス１１０ともみなすことができる。
【００２５】
[0040]  本明細書に記載される様々な実施形態によれば、センサデバイス１１０は、直接報告センサデバイス１１２及び間接報告センサデバイス１１４の２つのグループに分けることができる。直接報告センサデバイス１１２は、他のデバイス（例えば、サービスブローカーフレームワーク１２０又はサービスアプリケーションデバイス１２５）にパラメータを送信するように（例えばサービスブローカーフレームワークによって）構成されることが可能な任意のセンサデバイス１１０を含み得る。そのような構成は、パラメータが送信されるべきネットワーク上の場所を示すために、直接報告センサデバイス１１２の構成ファイルにドメイン名又はＩＰアドレスを追加することを含むことができる。代替法として、別のデバイス（例えばサービスブローカーフレームワーク１２０）が、そのようなパラメータが報告されることを周期的に要求してもよい。様々な認証及び許可も行われてよく、例えば、パラメータの送信先となるデバイスの識別を確認するための情報（例えばパスワード又は公開鍵）と共に、直接報告センサデバイス１１２を構成する。いくつかの実施形態では、そのような構成は、ユーザによる手動の承認を必要とする場合もある。
【００２６】
[0041]  一方、間接報告センサデバイス１１４は、そのように構成可能でないことがあり、代わりに、例えば、センサデバイス１１０の製造者の独自仕様のサーバやＡＷＳモノのインターネット（ＩｏＴ）クラウドプラットフォームなどのフレームワークなど、事前定義されたエンティティにのみパラメータを報告することができる。まとめて、これらの他のエンティティは、報告フレームワーク１１５を構成するとみなすことができる。報告フレームワーク１１５は、間接報告センサデバイス１１４によって報告されたパラメータ（及びいくつかの実施形態では、報告フレームワーク１１５自体によって抽出されたパラメータ）へのアクセスを可能にするアプリケーションプログラマインターフェース（ＡＰＩ）を提供することができる。上記で直接報告センサデバイスに関して説明したように、同様の認証及び許可処置が、報告フレームワーク１１５及び間接報告センサデバイス１１４に関して取られてもよい。例えば、サービスブローカーフレームワーク１２０は、（ＡＰＩを介して）報告フレームワーク１１５に、サービスブローカーフレームワーク１２０に提供すべきパラメータの識別を、そのような共有に対するユーザの承認を示す（又はそのような承認を得る際に有用な）トークンと共に、指示することができる。その後、報告フレームワーク１１５は、周期的に、又は要求の際に、そのようなパラメータをサービスブローカーフレームワーク１２０（又はサービスアプリケーションデバイス１２５などの他のデバイス）に送信することができる。
【００２７】
[0042]  サービスブローカーフレームワーク１２０は、サービスとしてのウェアラブルを容易にするための様々な機能を行う１つ又は複数のデバイスであってよい。様々な実施形態によれば、サービスブローカーフレームワークは、サービスブローカーフレームワークを介して供されるサービスをユーザが閲覧し、契約するための「市場」を提供する。そのため、サービス提供者構成デバイス１５０（例えば、パーソナルコンピュータ、サーバ、ＶＭ等）が、サービスブローカーフレームワーク１２０と（例えばウェブページ又はＡＰＩを介して）通信して、サービスブローカーフレームワーク１２０の市場によって容易にされるサービスを定義し、提案者構成デバイス１４５（例えば、パーソナルコンピュータ、サーバ、ＶＭ等）が、サービスブローカーフレームワーク１２０と（例えばウェブページ又はＡＰＩを介して）通信して、サービスブローカーフレームワーク１２０を通じて消費者に供される１つ又は複数の提案品（例えば、サービス、ハードウェア、サービス又はハードウェアのパッケージ等の）を定義し、そして、消費者構成デバイス１４０（例えば、携帯電話、タブレット、パーソナルコンピュータ、ウェアラブルデバイス等）が、サービスブローカーフレームワーク１２０と（例えばウェブページ又はＡＰＩを介して）通信して、ユーザのセンサデバイス１１０を登録し、サービスを契約し、ハードウェアを購入する等できる。いくつかの実施形態では、サービス提供者は、サービスを定義又は構成する際に、可能性としては単一のインターフェース又はインターフェースのグループを使用して、そのサービスを販売又は契約のために供することもできる。そのような実施形態では、サービス提供者構成デバイス１５０は、提案者構成デバイス１４５とみなすこともできる。
【００２８】
[0043]  いくつかの実施形態では、サービスブローカーフレームワーク１２０は、システム１００の様々なデバイス間のパラメータの送信も容易にすることができる。例えば、いくつかの実施形態では、サービスブローカーフレームワーク１２０は、サービスのための入力パラメータを集めるか又はその他のやり方で受け取り、それらを当該ユーザが契約しているサービスに従って処理するためにサービスアプリケーションデバイス１２５に転送することにより、仲介として機能することができる。いくつかのそのような実施形態では、サービスブローカーフレームワーク１２０は、パラメータをサービスアプリケーションデバイス１２５に転送する前に、何らかの前処理（例えば、追加的なパラメータ抽出、フォーマッティング、変換、パラメータのパッケージング等）を行うことができる。同様にして、サービスブローカーフレームワーク１２０は追加的に、サービスアプリケーションデバイス１２５によって出力された情報を（ここでも可能性としては前処理を施して）、消費者出力装置１３０に返すことを容易にすることができる。
【００２９】
[0044]  別の例として、サービスブローカーフレームワーク１２０は、サービスブローカーフレームワーク１２０が仲介として機能することなくデバイス間に通信を確立するように１つ又は複数のデバイスを構成することにより、それらデバイス間のパラメータの送信を容易にすることができる。例えば、サービスブローカーフレームワーク１２０は、サービスアプリケーションデバイス１２５のアドレスを関連するセンサデバイス１１０又は報告フレームワーク１１５に提供して、それらのデバイスが後にサービスアプリケーションデバイス１２５にパラメータを送信できるようにする。それに加えて、又はそれに代えて、サービスブローカーフレームワーク１２０は、ポーリングのために、関連するセンサ１１０又は報告フレームワーク１１５のアドレスをサービスアプリケーションデバイス１２５に提供してもよい。いくつかの実施形態では、これらのデバイスのうちいずれかの構成は、許可情報を提供することも含んでよく、許可情報は、例えば、パラメータの送信時又はそのような送信の要求の際に提示するためにサービスブローカーフレームワーク１２０又は他のデバイスによって生成される許可トークン（例えばＡＰＩトークン）である。
【００３０】
[0045]  サービスブローカーフレームワーク１２０は、１つ又は複数の課金システム１５５に支払いの要求を提出することにより、購入及び契約に関連する課金も容易にすることができる。例えば、消費者がサービスへの契約の支払いを月ごとに行う場合、サービスブローカーフレームワーク１２０は、消費者の支払い機器に対する支払いの要求を毎月提出することができる。例えば、購入時の１回払い、すべて若しくは一部が消費者以外の当事者による支払い（例えば、保険会社や、インセンティブプログラムの一部である医師による）、又は消費者自身に対する支払い（例えば、別のサービスとして、若しくは別のサービスとの関係でデータを共有する、若しくは広告を受け取る承認に対する報酬）などの追加的な機構及び修正が明らかであろう。
【００３１】
[0046]  様々な実施形態において、サービスブローカーフレームワーク１２０によって容易にされるサービスは、例えばサービス提供者によって運営される外部のサービスアプリケーションデバイス１２５にホストされることが可能である。サービスアプリケーションデバイス１２５は、例えば、入力を処理し、消費者に供されるサービスに従って何らかの出力（例えば、追加的な抽出されたパラメータ、コーチング等）を提供するように構成されたサーバ又はＶＭであってよい。いくつかの実施形態では、サービスは、１つ又は複数のアルゴリズム（例えばパラメータ抽出アルゴリズム）を直接消費者のデバイス（例えばセンサデバイス１１０又は他のデバイス）にインストールすることによって提供することができ、そのような実施形態では、消費者のデバイスはサービスアプリケーションデバイス１２５とみなすことができ、消費者出力装置１３０と同一のデバイスであり得る。したがって、いくつかの実施形態では、サービスブローカーフレームワーク１２０は、同じ消費者によって所有される複数のデバイス間のパラメータの送信を容易にするように働くことができる。
【００３２】
[0047]  消費者出力装置１３０は、サービスアプリケーションデバイス１２５から直接、又はサービスブローカーフレームワーク１２０を介してのいずれかにより、１つ又は複数のサービスからの出力を受け取るために消費者がアクセスできる実質的に任意のデバイスであってよい。例えば、消費者出力装置１３０は、パーソナルコンピュータ、携帯電話、タブレット、又はウェアラブルデバイスである。いくつかの実施形態では、消費者出力装置１３０は、ウェブブラウザを介してサービスアプリケーションデバイスから（例えば、サービスアプリケーションデバイスによってホストされるウェブサイトから）、又はサービス提供者によって提供される、消費者出力装置にインストールされたアプリ若しくは他のプログラム（例えば、サービスアプリケーションデバイス１２５若しくはサービスブローカーフレームワーク１２０によってプッシュされた出力を受け取るサービスフロントエンドプログラム）から出力を受け取るか、又は、サービスアプリケーションデバイスによって供されるＡＰＩを介して出力にアクセスすることができる。例えば、電子メール、電話、テキストメッセージなど、サービスアプリケーションデバイス１２５と消費者出力装置１３０との間の通信のための様々な追加的チャネルが明らかであろう。消費者出力装置１３０がサービスの出力にアクセスするためにアプリを利用する実施形態では、サービスブローカーフレームワーク１２０は、サービスを契約すると、消費者出力装置を、アプリ又はそのアプリをダウンロードできる場所（例えば、サービスブローカーフレームワーク１２０によって運営されるサーバ、又はサービスブローカーとは独立した別のアプリ市場）にリンクする（又は、その他のやり方でアプリ若しくは場所の識別を提供する）ことができる。
【００３３】
[0048]  様々な実施形態によれば、消費者及びサービス提供者に加えて、様々な提案者及び他の第３者が本システムに参加し得る。そのため、提案者及び第３者デバイス１３５は追加的に、パラメータ、人口統計学的データ、使用状況データ、及び他の情報などの情報を、サービスブローカーフレームワーク１２０、サービスアプリケーションデバイス１２５、又は他のデバイスから受け取る可能性がある。例えば、いくつかの実施形態では、医師サーバ１３５が、消費者としてシステムに参加している患者についての情報を受け取り、広告サーバ１３５が、消費者に表示するための広告を提供し、そのような表示及びクリックスルーについての情報を受け取り、第３者のデータ収集者が、ユーザがそのような収集に同意している場合はパラメータ及び他の情報を受け取り（例えば、そのようなデータ収集と引き換えにユーザに支払いをする、又は１つ若しくは複数のサービスの割り引きを提供する提案品の一部として）、クラウドサービス提供者（例えばクラウドストレージ）がデータを受け取り、そのデータを記憶し、後にサービスブローカーフレームワーク１２０又はサービスアプリケーションデバイス１２５が検索（又は処理などの他のサービス）することができる（例えば、サービスがそのような追加的なサービスを必要とするが、その場ではそれらのサービスを提供しない場合、又はサービスブローカーフレームワーク１２０を介した、若しくはその他のやり方による消費者による別個の調達を伴わない場合）。
【００３４】
[0049]  図２は、図１のシステム１００の様々な機能デバイスなど、本明細書に記載される様々なシステムに参加する様々なデバイスを実施するためのハードウェア２００の例を示す。例えば、ハードウェア２００は、センサデバイス１１０、サービスブローカーフレームワーク１２０、消費者構成デバイス１４０、消費者出力装置１３０、サービスアプリケーションデバイス１２５、又は本明細書に記載されるその他のデバイスのいずれをも実施することができる。図示されるように、デバイス２００は、プロセッサ２２０、キャッシュ／システムメモリ２３０、ユーザインターフェース２４０、ネットワークインターフェース２５０、及びストレージ２６０、並びに一部のデバイスに関してはセンサ２４５を含み、これらは１つ又は複数のシステムバス２１０を介して相互に接続されている。図１１は、いくつかの点で抽象化を構成しており、デバイス２００の構成要素の実際の編成は図よりも複雑であり得ることが理解されよう。
【００３５】
[0050]  プロセッサ２２０は、メモリ２３０又はストレージ２６０に記憶された命令を実行する、又は他のやり方でデータを処理することが可能な任意のハードウェアデバイスであってよい。そのため、プロセッサは、マイクロプロセッサ、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）、特定用途集積回路（ＡＳＩＣ）、又は他の同様のデバイスを含み得る。１つ又は複数のＡＳＩＣに依拠する実施形態などのいくつかの実施形態では、部分的にソフトウェアを介して提供されると説明される機能は、代わりに、ＡＳＩＣの動作にハードワイヤードされることが可能であり、そのため、関連するソフトウェアが省略されてもよい。
【００３６】
[0051]  キャッシュ／システムメモリ２３０は、例えば、Ｌ１、Ｌ２、若しくはＬ３キャッシュ又はシステムメモリなど、各種メモリを含み得る。そのため、メモリ２３０は、静的ランダムアクセスメモリ（ＳＲＡＭ）、動的ＲＡＭ（ＤＲＡＭ）、フラッシュメモリ、読出し専用メモリ（ＲＯＭ）、又は他の同様のメモリデバイスを含み得る。
【００３７】
[0052]  ユーザインターフェース２４０は、管理者などのユーザとの通信を可能にする１つ又は複数のデバイスを含むことができる。例えば、ユーザインターフェース２４０は、ディスプレイ、マウス、キーボード、タッチ画面、ボタン、カメラ、マイクロフォン、振動器、触覚エンジン等を含み得る。いくつかの実施形態では、ユーザインターフェース２４０は、通信インターフェース２５０を介してリモート端末に提示されることが可能な、コマンドラインインターフェース又はグラフィックユーザインターフェースを含む。
【００３８】
[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]  ユーザプロフィール７００は、サービスブローカーがユーザの１つ又は複数のサービスのための仲介としてどのように振る舞うかを定義する共有レコードのセット７６０も含む。そのため、共有レコードのセット７６０は、共有構成が適用されるサービスを識別するサービスＩＤフィールド７６２と、共有される１つ又は複数の入力を識別する入力フィールド７６４と、入力が共有される先となる１つ又は複数のデバイスを識別する「共有先」フィールド７６６とを含む。図示されるように、入力フィールド７６４は、切り離された分類法のみに依拠することによるのではなく、入力データがそこから送信されるべき個々のデバイスを指定することができる。このような機構は、同様の入力パラメータタイプが複数のデバイスから入手可能であり、ユーザ（又は他のデバイス若しくはエンティティ）がサービスに情報を提供するためにそのような供給元を１つだけ選択する際に有益である可能性がある。それに代えて、いくつかの実施形態では、入力フィールド７６４は特定のデバイスからも切り離されてよく、どのデバイスがその特定の入力を提供するかを決める決定は、他の場所で行われてもよい（例えば、すべてのデバイスからの入力を転送する、新しい入力パラメータを最も頻繁に提供するセンサデバイスから転送する、利用可能なデバイスの中でそのサービスの最良の性能を提供することが知られているセンサデバイスから転送する等）。
【００８５】
[00100]  第１の例として、レコード７７２は、「ＥＥＳｅｒｖｉｃｅ」として知られるサービスについては、Ｗｒｉｓｔｗａｔｃｈ−５Ｄ３デバイスによって取得される３つのパラメータが、それぞれｖｍ１．ｓｅｒｖｉｃｅ．ｃｏｍ、ｐｈｙｓｉｃｉａｎ．ｃｏｍ、及びｉｎｓｃｏ１．ｃｏｍに位置する３つのデバイスに転送されるべきことを示している。いくつかの実施形態では、レコード７７２は、図４のエネルギー消費推定サービスＶＭ４６０によって供されるサービスに対応することができる。
【００８６】
[00101]  「ＥＥＳｅｒｖｉｃｅ」に対して入力前処理スクリプトが定義される（例えばそのサービスのサービスレコードの中で）などのいくつかの実施形態及び事例では、前処理は、転送する前に入力データに行うことができる。さらに、サービス「ＥＥＳｅｒｖｉｃｅ」が、情報が共有されることになる当事者のパラメータ化された定義を含む実施形態などのいくつかの実施形態では、共有先フィールド７６６の値は、ユーザプロフィール内の別の場所にある情報に従って埋めることができる。例えば、「ｐｈｙｓｉｃｉａｎ．ｃｏｍ」は、ユーザの医師のサーバを具体的に指し示すのに対し、ＥＥＳｅｒｖｉｃｅは、単に、入力が％ＰｈｙｓｉｃｉａｎＳｅｒｖｅｒ％と共有されるべきことを定義することができる。したがって、これ（及び他の値）は、同じサービスに対してユーザごとに異なり得る。
【００８７】
[00102]  第２の例示的レコード７７４は、「フィットネスコーチングサービス」として知られるサービスに関して、ＭｏｂｉｌｅＰｈｏｎｅ１２３デバイスによって取得される２つのパラメータと、ＥＥＳｅｒｖｉｃｅ＿Ｕｓｅｒ４３２「デバイス」によって取得されるパラメータとの両方が、ｖｍ２．ｃｏａｃｈｉｎｇ．ｃｏｍに位置するデバイスに転送されるべきことを示している。様々な実施形態において、レコード７７４は、図４のフィットネスコーチングサービスＶＭ４７０によって供されるサービスに対応することができる。いくつかの代替実施形態では、共有レコードのセット７６０は、サービスブローカーフレームワークが仲介として機能するレコードのみを含んでもよい。そのため、モバイルデバイス４２０及びエネルギー消費推定サービスＶＭ４６０が入力パラメータをフィットネスコーチングサービスＶＭ４７０に直接送信する図４の例では、このレコード７７４はいくつかの実施形態では省略されてもよい。代わりに、いくつかのそのような実施形態では、サービスブローカーフレームワークは、単にセンサのバインドを行い、その後は、そのサービスが中断されるまで容易化に関してはそれ以上のアクションを行わず、サービスが中断された時点で、サービスブローカーフレームワークはセンサのバインド解除を容易にすることができる。
【００８８】
[00103]  図８は、ユーザについてセンサデバイスを登録する方法８００の例を示す。様々な実施形態において、方法８００は、サービスブローカーフレームワークによって行われることが可能であり、いくつかの実施形態では、図３のセンサ登録命令３１２に対応し得る。サービスブローカーフレームワーク内でセンサを登録するための様々な代替の機構及び方法が明らかであろう。
【００８９】
[00104]  方法はステップ８１０で開始し、サービスブローカーフレームワークがユーザから登録メッセージを受け取る。登録メッセージは、登録が行われているセンサデバイスによって、又はユーザによって操作される別のデバイス（例えば、携帯電話、タブレット、ＰＣ、報告フレームワーク等）によって送信される。登録メッセージは、例えば、ユーザがフォームを記入して提出する結果としてか、センサデバイスについての情報を取得及び報告するソフトウェアの動作を通じてか、又はセンサデバイスの動作を通じて（例えば、初回の電源投入後の「家への電話（ｐｈｏｎｉｎｇ  ｈｏｍｅ）」により）送られる。次に、ステップ８２０で、サービスブローカーフレームワークが、登録メッセージから、広告された入力パラメータタイプと共にデバイスの識別子を読み出す。それに代えて、いくつかの実施形態では、登録メッセージは入力パラメータの広告を含まない場合もあり、代わりに、サービスブローカーフレームワークは、識別されたセンサデバイスのタイプによって提供され知られている入力パラメータタイプをリストしたデータベースを参照することができる。
【００９０】
[00105]  ステップ８３０で、サービスブローカーフレームワークは登録メッセージによって識別されるユーザのユーザプロフィールを取り出し、ステップ８４０で、サービスブローカーフレームワークは、その新しいデバイスを表す新しいレコードをユーザプロフィールに追加する。この新しいレコードは、識別子及び利用可能な入力タイプなどの情報を含むことができる。そのため、ステップ８４０で作成されるレコードは、図７のセンサデバイスレコードのセット７４０のうちのレコードに対応することができる。次に、ステップ８５０で、サービスブローカーフレームワークが、識別されたセンサデバイスが間接報告デバイスであるかどうかを判定する。ここでも、この情報は、登録メッセージによって伝えられるか、又は登録が行われている特定のデバイスについて知られている情報に基づいてサービスブローカーフレームワークによって相互参照される。間接報告デバイスである場合、サービスブローカーフレームワークは、登録しようとするデバイスの報告フレームワークと通信して８６０、サービスブローカーフレームワーク又は他のデバイスに入力パラメータを公開する許可を取得する。例えば、サービスブローカーフレームワークは、そのような共有を許すユーザの承認を示すトークン、又はサービスブローカーフレームワークがそのような承認を取得するためにユーザとの別個の通信を開始するのに使用できる識別子を送信する。その後、承認の取得に成功した場合、又はすでに成功している場合、報告フレームワークは、ステップ８７０で、報告フレームワークの識別子（例えばネットワークアドレス又は他のＩＤ）と共に、レコードに記憶されたＡＰＩ許可トークンを返す。その後、ＡＰＩトークンは、報告フレームワークに入力パラメータを要求するために使用することができる。最後に、方法はステップ８８０で終了する。
【００９１】
[00106]  図９は、提案品を閲覧するための例示的インターフェース９００を示す。このインターフェース９００は、例えば、図３の提案品市場命令３１４に従って生成され、消費者のデバイスで実行されるウェブブラウザ、アプリ、又は他のクライアントソフトウェアを介して提示され得る。
【００９２】
[00107]  図示されるように、インターフェース９０２は、閲覧する提案品を見つけるためにユーザが名前や他のキーワードを入力することを可能にする検索バー９０２及び検索ボタン９０４を含む。データベース化された提案品の検索を行うための様々なアルゴリズムが明らかであろう。例えば、いくつかの実施形態では、検索ボタン９０４を押すと実行される検索アルゴリズムは、検索バー９０２に入力された１つ又は複数の単語が、提案品の名前若しくは説明の中にある、又は提案品に関連付けられたサービスの名前若しくは説明の中にある提案品をいずれも識別することができる。推薦ボタン９０６は、サービスブローカーフレームワークがユーザの閲覧のために１つ又は複数の提案品を推薦することを要求する。ここでも、そのような推薦を行うための様々なアルゴリズムが明らかであろう。その一例を、図１０との関連で下記でより詳細に説明する。例えば、推薦アルゴリズムは、登録されたサービスの動作のために必要とされるセンサデバイスのすべて若しくは大半をユーザがすでに持っている提案品を見つけるか、又は遺伝的アルゴリズム、回帰、ニューラルネットワーク、ベイジアンネットワーク等の機械学習手法を用いて、ユーザに関する情報に基づいて推薦を行うことができる。
【００９３】
[00108]  インターフェース９００は、単一のサービスを含む提案品を記述する２つの提案品エントリ９１０、９３０を示している。提案品が２つ以上のサービス又は他の品目を含む事例では、提案品の各要素をリストするための様々な代替の機構が明らかであろう。第１の提案品９１０は、「エネルギー推定サービス」に関連付けられており、星の数による評価付けとして示された２つの評価付け９１２、９１４に関連付けられているが、様々な代替の評価付けメカニズムが明らかであろう。具体的には、２つの評価付け９１２、９１４は、特定のユーザに合わせてより調節された評価付けから、総合的な評価付けを区別するように示すことができる。理解されるように、様々な要因がサービスの性能に影響する可能性があり、それらには、任意選択の入力パラメータが利用可能であるかどうか、又はユーザのデバイスによって取られた測定値に対する他の同様のデバイスによって取られた測定値の品質などがある。評価付けは、他のユーザによるそのサービスのレビューに基づいて生成されてもよい。例えば、図示されるように、一般的な評価付け９１４は、そのサービスのユーザが概ねそのサービスを３つ星と評価付けしていることを示し、一方、個別化された評価付け９１２は、見ているユーザとより類似したユーザはそのサービスを４つ星と評価付けしていることを示す。例えば、４つ星の評価付け９１２は、すべての任意選択の入力パラメータがそのユーザから入手可能である時の平均の評価付けであり、一方、３つ星の評価付け９１４は、必須の入力パラメータだけが利用可能である時の平均の評価付けであるか、又は利用可能な入力パラメータに関係なくすべてのユーザ評価付けの平均である可能性がある。
【００９４】
[00109]  要件欄９１６は、エネルギー推定サービスは、加速度計データ及び歩数計データの２つの入力パラメータを必要とすることを示し、それらは両方とも、ユーザのモバイルデバイス又は腕時計ウェアラブルのどちらからでも入手可能であることを示している（又は、それに代えて、インターフェース９００は、これらの値がデバイス「ＭｏｂｉｌｅＰｈｏｎｅ１２３」及び「Ｗｒｉｓｔｗａｔｃｈ−５Ｄ３」から入手可能であることを示してもよい）。いくつかの実施形態では、市場は、提案品９１０との関係で利用可能な１つ又は複数のハードウェアアップグレード提案品を識別することができる。例えば、星の数による評価付け９１２、９１４が前提とするユーザ評価付けは、異なるタイプの加速度計デバイスを持っているユーザはさらに高い満足度を報告することを示す傾向があり得る。それに応じて、そのタイプの加速度計デバイスが、サービスブローカーフレームワークを介した購入のために利用できる場合は、ハードウェアアップグレードボタン９１８がその特定の入力の隣に表示されてもよい。ボタン９１８を押すと、例えば、新しいウィンドウの中に、又はインターフェース９００に重なるポップアップの中に、追加的なハードウェア提案品が受理のために表示される。
【００９５】
[00110]  オプション入力欄９２２は、必須ではないものの２つのタイプの入力パラメータがサービスによって使用され得ることを示しており、それらの入力パラメータは、手首着用型の加速度計データ及び活動データであり、これらは両方ともユーザの腕時計ウェアラブルから入手可能である（又は、より正確には、図４の例では報告フレームワークからであるが、ユーザからは隠される可能性がある）。ハードウェアアップグレードボタン９１８と同様にして、サービスアップグレードボタン９２４は、入力の１つ又は複数の隣に設けられて、一般にはよりよいサービス性能又はユーザの満足度を伴う、入力パラメータを提供するサービスに関する提案品が利用可能であることを示すことができる。図の例では、サービスブローカーフレームワークは、エネルギー推定サービスの動作（又はユーザの満足度若しくは何らかの他の指標）を向上させる傾向のある「活動」入力パラメータを推定するための別のサービスを見つけている。ボタン９１８を押すと、追加的なサービス提案品が、例えば、新しいウィンドウの中に、又はインターフェース９００に重なったポップアップの中に、受理のために表示される。
【００９６】
[00111]  価格欄９２６は、その提案品を受理すると（及び関連付けられたエネルギー推定サービスをそのユーザに対して追加する）と、ユーザに対して２．９９ドルの毎月発生する料金が生じることを示している。追加ボタン９２８を選択すると、提案品が直ちに受理され、提案品をショッピングカートに追加するか、又はユーザをその新しいサービスのための精算若しくは構成画面に導くことができる。
【００９７】
[00112]  第２の提案品９３０は、単一の評価付け９３２のみに関連付けられている。この理由は、個別化された評価付けがそのユーザには利用することができず、代わりに一般的な評価付けだけが示されているためである可能性がある。そのような個別化された評価付けは、例えば、現在のユーザに類似するユーザからの十分なユーザ入力が入手できない場合、利用可能なセンサデバイスが必要最小限の入力パラメータしか提供しない場合、又は利用可能なセンサ若しくはユーザについての他の情報が平均的なレビューユーザと大きく異ならない場合に、利用できない場合がある。
【００９８】
[00113]  図示されるように、要件欄９３６は、必須パラメータの１つであるエネルギー消費が、ユーザのデバイスのどれからも入手できないことを示している。そのため、ハードウェアアップグレードボタン９１８と同様の提案品を指すことが可能なハードウェアアップグレードボタン９３８に加えて、サービス追加ボタン９４４が、欠落している入力パラメータを提供することが可能なサービスに関する１つ又は複数の提案品を指すことができる。例えば、サービス追加ボタン９４４は、欠落している入力パラメータの提供元となる第１の提案品９１０を指す。別の代替法として、サービスブローカーフレームワークが欠落している入力パラメータを識別しているときには、これら２つのサービスが単一の提案品として動的に共にパッケージされてもよい。欠落している入力パラメータが、そのユーザの利用可能なセンサデバイスに基づいて新しいサービスによって提供されることが可能でない場合、サービス追加ボタン９４４は、ユーザを新しいハードウェアデバイスを購入するための提案品（及び、可能性としては、新しいハードウェアデバイスと共に使用する追加的なサービス）にリンクする新しいハードウェア注文ボタン（図示せず）に置き換えられてよい。価格フィールド９４６は、追加ボタン９４８を介して提案品を受理すると、そのサービスが中止されるまでユーザに毎月９．９９ドルが課金され得ることを示している。いくつかの実施形態では、すべての必須の入力が利用可能になるまでユーザが追加ボタン９４８を選択できないように、又はその他のやり方で提案品９３０を受理できないようにすることができる。
【００９９】
[00114]  図１０は、提案品の推薦を生成する方法１０００の例を示す。方法１０００は、サービスブローカーフレームワークによって行われることが可能であり、提案品市場命令３１４によって定義することができる。この方法１０００は、インターフェース９００の推薦ボタン９０６をユーザが選択するのに応答して提案品のリストを作成するために実行することができる。
【０１００】
[00115]  方法はステップ１００５で開始し、ステップ１０１０に進んで、サービスブローカーフレームワークが現在のユーザのユーザプロフィールを取り出し、次いでステップ１０１５に進んで、サービスブローカーフレームワークが、ユーザプロフィールの中で識別されるセンサデバイスから入手可能な現在の（又は最近若しくは過去の）パラメータ値を取り出す。
【０１０１】
[00116]  サービスブローカーフレームワークは次いで、ユーザが特定のサービス、提案品、又はサービス若しくは提案品のクラス（例えば、フィットネス関係の提案品、心臓の健康に関する提案品、ソーシャルサービス等）に関心を持つかどうかを予測するために前もって訓練された、予測モデルのグループを反復し始める。例えば、いくつかの実施形態によれば、これらの予測モデルは、取得される訓練セットに基づいてロジスティック回帰手法に従って訓練されたモデル（その例が図１１との関連で下記でより詳細に説明される）を含み、いくつかの実施形態では、提案品を見ること、受理すること、又は評価付けすることなどのユーザアクションに基づいて継続的に更新される。ステップ１０２０で、サービスブローカーフレームワークは、特定の提案品又は提案品のクラス（又はサービス若しくはサービスのクラス）に関連付けられた予測モデル（例えば、学習済み係数、特徴リスト等）を評価のために取り出す。次に、ステップ１０２５で、サービスブローカーフレームワークは、予測モデルによって使用される特徴であるステップ１０１０、１０１５で集められた情報に予測モデルを適用し、モデルから関連性スコアを受け取る。例えば、予測モデルがシグモイド関数として実施される実施形態などのいくつかの実施形態では、関連性スコアは０と１との間の値とすることができ、高い値ほど高い関連度に対応する。ステップ１０３０で、サービスブローカーフレームワークは、現在のモデルに関連付けられた提案品又はクラスを、順序付けられたリストの関連性スコアに対応する位置に追加する。
【０１０２】
[00117]  次にステップ１０３５で、サービスブローカーフレームワークは、現在の予測モデルが分析すべき最後のモデルであるかどうかを判定する。そうでない場合、方法１０００はステップ１０２０にループバックして、次の予測モデルを評価する。現在の予測モデルが分析すべき最後のモデルであるかどうかを判定する様々な方法が使用されてよい。例えば、サービスブローカーフレームワークは、すべての知られているモデルを反復する、所定数のモデルを評価する（例えば、ステップ１０２０で各モデルを無作為に選択する）、モデルのサブセットを評価する（例えば、ユーザがすでに特定カテゴリの提案品を現在閲覧中である場合）、又は、閾値を上回る関連性を持つ所定数の提案品若しくはクラスが見つかるまでモデルの評価を継続することができる。したがって、ステップ１０２０〜１０３５の連続した反復を通じて、より高い関連性の提案品若しくは提案品のクラス（又はサービス若しくはサービスのクラス）がリストの上位に共にグループ化された、順序付けられたリストが構築されることが見て取れよう。様々な代替実施形態では、本明細書に記載されるリスト構築方法以外の手法が用いられ得ることが認識されよう。
【０１０３】
[00118]  ステップ１０４０で、サービスブローカーフレームワークは、順序付けられたリストから最高位の提案品又はクラスを評価のために取り出す。ステップ１０４５で、サービスブローカーフレームワークは、この提案品又はクラスをそのユーザに対して無視すべきことを示す、以前の指示又は他の構成があるかどうかを判定する。例えば、そのような無視の指示は、ユーザによって手動で設定されて、ユーザがその提案品又はクラスに関心がないことを示すか、その提案品又はクラスが以前にユーザに何回か提示されたことがある場合、ユーザの利用可能なセンサデバイスがその提案品の中のサービスに必要な入力を提供することができない（若しくは、所定数の入力より多い欠落がある）場合、又はユーザがその提案品若しくはクラスの中ですでにそのサービス（若しくはそれと同様のサービス）を有する場合に、システムによって自動的に設定され得る。その提案品又はクラスが無視されるべきでない場合、サービスブローカーフレームワークは、ステップ１０５０で提示リストにその提案品又はクラスを追加する。提案品クラスを提示リストに追加すべき場合、サービスブローカーフレームワークは、そのクラス内の個々の提案品を提示リストに追加することができる（例えば、そのクラス内のすべての提案品を追加することにより、又は、無作為の選択によるか、関連性を測るために個々の提案品に関連付けられた予測モデルを適用することによるか、若しくは最も評価付けが高い提案品を選択することにより、そのクラス内の個々の提案品のサブセットを選択することによる）。サービスを提示リストに追加すべき場合、サービスブローカーフレームワークは、提示リストに追加するために、そのサービスに関連付けられた１つ又は複数の提案品を検索することができる。サービスクラスを追加すべき場合、サービスブローカーフレームワークは、まずそのサービスクラスの中で１つ又は複数のサービスを選択し（例えば、上記で提案品クラスに関連して説明したものと同様の方法に従って）、その後、選択されたサービスに関連付けられた提案品を見つけることができる。
【０１０４】
[00119]  ステップ１０５５で、サービスブローカーフレームワークは、提示リストが現在一杯であるかどうかを判定する。例えば、様々な実施形態において、提示リストは、提案品の数が所定の閾値（例えば、単一の画面に表示できる提案品の数）を満たすか、又は超えるときに一杯であるとみなすことができる。提示リストが一杯でない場合、サービスブローカーフレームワークは、ステップ１０６０で、順序付けられたリストが空であるかどうかを判定する。空でない場合、方法１０００はステップ１０４０にループバックし、次の品目が評価のために順序付けられたリストから取り出される。提示リストが一杯になるか、又は順序付けられたリストが空になるかのいずれかになると、提示リストにある提案品が、ステップ１０６５で、例えばインターフェース９００と同様のインターフェース上でユーザに提示される。方法１０００は次いでステップ１０７０で終了に進む。
【０１０５】
[00120]  図１１は、予測モデルを訓練する方法１１００の例を示す。方法１１００は、その後適用のためにサービスブローカーフレームワークに伝達される予測モデルを訓練するために、サービスブローカーフレームワーク又は別のデバイスによって記憶され実行される命令に対応し得る。例えば、プログラマによって定義されたアルゴリズム、ニューラルネットワーク、ベイジアンネットワーク等、モデル訓練の様々な代替の手法が明らかであろう。
【０１０６】
[00121]  方法はステップ１１０２で開始し、ステップ１１０４に進んで、デバイスが、モデルを作成しようとする所与のパラメータについてのラベル付けされたデータセットを取得する。ラベル付けされていない訓練セットからモデルを訓練するための様々な手法が明らかであろう。様々な実施形態において、訓練セットは、１つ又は複数の特徴（例えば、ユーザの人口統計学的データ、利用可能なセンサデバイス、取り出されたパラメータ等）と、その特徴セットから導かれるべき適切な結論とを指定する訓練事例のレコードをいくつか含むことができる。様々な実施形態において、訓練セットは、サービスブローカーフレームワークとの様々なユーザの対話中に集められるデータなど、現実世界のデータ収集活動から作成され得る。例えば、ユーザが提案品（又はそれに関連付けられたサービス）を見る、受理する、又は肯定的に評価付けするたびに、そのユーザの現在の特徴セットが、その提案品がユーザに関連することを示すラベル（例えば、１、又はユーザによって提供された正規化された評価付け）と関連付けて、訓練事例として捕捉される。逆に、ユーザに提案が表示されたもののユーザがその提案を受理しないか、その提案品に対して無視の指示を手動で設定するか、又は提案品を否定的に評価付けするたびに、そのユーザの現在の特徴セットが、その提案品がユーザに関連しないことを示すラベル（例えば、０、又はユーザによって提供された正規化された評価付け）と関連付けて、訓練事例として捕捉される。提案品（又は提案品のクラス）の関連性を予測するための様々な予測モデルに対して訓練セットを構築するための様々な追加的方法が明らかであろう。
【０１０７】
[00122]  ステップ１１０６で、デバイスは、データセット中で識別される特徴の数を識別し、ステップ１１０８で、最終的に得られるモデルで使用される係数のセットを初期化する。様々な実施形態によれば、係数は、定数として機能する１の追加的な係数と共に、特徴ごとに作成される。モデルが数値を出力するように訓練される場合は、線形回帰手法を利用することができ、その場合、最終的なモデル関数は、
ｈ（Ｘ）＝θ０＋θ１ｘ１＋θ２ｘ２．．．
の形態を取ることができ、ここで、Ｘは、特徴のセット｛ｘ１，ｘ２，．．．｝であり、係数｛θ０，θ１，θ２，．．．｝は、出力として関連性の推定値を提供するように、訓練データセットから学習された傾向に沿って方法１１００によって調整されることになる。いくつかの実施形態では、最終的なモデル関数は、次のようにシグモイド関数を組み込むことができ、
【数１】
0006745807.tif 000002
ここで、係数を調整する結果、関数ｈ（Ｘ）が０と１との間の値を出力するようになり、この値は、提案品の関連性の推定値として機能する。様々な実施形態によれは、係数はすべてゼロの値に初期化される。いくつかの実施形態では、ｈ（Ｘ）（及びそれに関連する係数）に含めるための追加的な特徴が、例えばｘ１２又はｘ１ｘ２など、訓練セット中の特徴から構築され得ることが明らかであろう。
【０１０８】
[00123]  方法は、それぞれステップ１１１０、１１１２で２つのループ変数ｉ及びｐを０に初期化することにより、係数の訓練を開始する。次いで、ステップ１１１４で、デバイスは、現在の係数θｐにおけるコスト関数の偏導関数Ｊ（θ）を得、ここで、コスト関数は、いくつかの実施形態では、
【数２】
0006745807.tif 000003
と定義することができ、ここで、ｍは、訓練データセット中の訓練事例の数であり、ｈθ（ｘ）は、現在の係数のセットθを使用する訓練された関数であり、ｘ（ｊ）は、ｊ番目の訓練事例の特徴のセットであり、ｙ（ｊ）は、ｊ番目の訓練事例に要求される出力（すなわちラベル）である。したがって、バッチ勾配降下手法に従うと、係数ｐ（θｐ）での偏導関数は、
【数３】
0006745807.tif 000004
となり得、ここで、ｘｐ（ｊ）は、ｊ番目の訓練事例にあるｐ番目の特徴である（又は、ｐ＝０の時、ｘｐ（ｊ）＝１）。
【０１０９】
[00124]  ステップ１１１６で、デバイスはｐを増分し、ステップ１１１８で、デバイスは、ｐが、ｈ（Ｘ）に含まれるべき特徴の総数を現在超えているかどうかを判定することにより、すべての係数が現在のループで検討されたかどうかを判定する。そうでない場合、方法は、ループバックしてステップ１１１４に戻り、次の偏導関数項を見つける。
【０１１０】
[00125]  現在の反復についてすべての偏導関数が見つけられると、方法１１００は、続いてステップ１１２０でループ変数ｐをゼロにリセットする。次いで、ステップ１１２２で、デバイスは、ステップ１１１４で見つかった対応する偏導関数に基づいて、且つあらかじめ設定された学習率に基づいて、ｐ番目の係数θｐを更新する。例えば、デバイスは、次の更新規則、
【数４】
0006745807.tif 000005
を適用することができ、ここで、αは学習率であり、これは例えば、０．１、０．３、１、又は各反復における所望の変更率に合わせて適宜選択された任意の他の値である。
【０１１１】
[00126]  ステップ１１２４で、デバイスはｐを増分し、ステップ１１２６で、デバイスは、ｐが、ｈ（Ｘ）に含まれるべき特徴の総数を現在超えているかどうかを判定することにより、すべての係数が現在のループで検討されたかどうかを判定する。そうでない場合、方法はループバックしてステップ１１２２に戻り、次の係数を更新する。方法１１００によれば、すべての偏導関数は、第２のループで係数を実際に修正する前に第１のループ中で見つかり、よって、偏導関数は、部分的に更新された値に基づいて取られることはないことに留意されたい。他の実施形態は、そのような係数の「同時の」更新を実施しない場合もある。
【０１１２】
[00127]  すべての係数が更新された後、方法はステップ１１２８に進んで、変数ｉが増分される。ステップ１１３０で、デバイスは、方法１１００が無期限にループしないことを保証するための事前定義された反復の最大回数を、ｉが超えているかどうかを判定する。１０００、５０００、１０００００回など、十分に大きい反復の最大回数が選択されてよい。最大の反復に達していない場合、方法１１００はステップ１１３２に進んで、デバイスが、訓練セットに基づいて、コスト関数Ｊ（θ）を使用して現在のコストを算出する。ステップ１１３４で、デバイスは、前回の反復から現在の反復までのコストの変化が最小の閾値を満たさないかどうかを判定することにより、関数ｈ（Ｘ）が許容可能な解に収束したかどうかを判定する。変化が閾値を上回った場合、方法はステップ１１１２にループバックして、別の係数更新ループを行う。一方、最大の反復に達しているか、又はコストの変化が最小の閾値を下回る場合、方法１１００はステップ１１３６に進んで、デバイスが、パラメータを抽出するための新しいモデルの一部として係数を記憶し、方法１１００はステップ１１３８で終了に進む。
【０１１３】
[00128]  回帰以外の手法を採ることに加えて、他の実施形態は、バッチ勾配降下以外の回帰手法で係数を調整するために異なる方法を利用し得ることが明らかであろう。例えば、いくつかの実施形態は、確率的勾配降下を使用することができ、その場合、それぞれの係数更新は、単一の訓練事例に基づいて行われ（それにより偏導関数からの加算をなくし）、方法は、追加的にそのような各例を反復する。他の実施形態では、行列に基づく非反復的手法を使用して、回帰の正規方程式を使用して適切な係数を見つけることができ、係数のセットは、
θ＝（ＸＴＸ）−１ＸＴｙ
と算出され、ここで、Ｘは、すべての訓練事例にある特徴の行列であり、ｙはそれに関連付けられたラベルのベクトルである。
【０１１４】
[00129]  図１２は、サービスの詳細を表示する方法１２００の例を示す。方法１２００は、サービスブローカーフレームワークによって行われることが可能であり、例えば、提案品市場命令３１４に対応し得る。方法１２００は、表示するサービス（又はサービスを含む提案品）をユーザが選択するのに応答して実行され得る。後に説明されるように、方法１２００は、表示されるサービス又は提案品と一緒に提案するための追加的な提案品を見つける。提案がリストの一部として表示される時、例えば、インターフェース９００の様々な追加提案品ボタン９１８、９２４、９３８、９４４を生成するために、同様のステップが取られ得る。
【０１１５】
[00130]  方法１２００はステップ１２０５で開始し、サービスブローカーフレームワークが、表示するサービス又は提案品の選択を受け取り、ステップ１２１０に進んで、サービスブローカーフレームワークが、そのサービスによって（又は選択された提案品に属するサービスによって）使用される入力パラメータを読み出す。ステップ１２１５で、サービスブローカーフレームワークは、そのユーザのユーザプロフィールを取り出して、そのユーザにどの入力パラメータタイプが利用可能であるかを判定する。ステップ１２２０で、サービスブローカーフレームワークは、例えば、ステップ１２１０で得た入力の中にユーザプロフィールにリストされていないものがあるかどうかを判定することにより、そのサービスのための入力がすべてそのユーザに利用可能であることをユーザプロフィールが示すかどうかを判定する。少なくとも１つの入力が欠落している場合、方法１２００はステップ１２４０に進んで、サービスブローカーフレームワークが、現在利用可能な入力パラメータに基づいて、その欠落している入力を提供するであろうサービス（又はサービスの組み合わせ）の検索を試みる。
【０１１６】
[00131]  追加的なサービスのそのような組み合わせを１つ又は複数識別するための様々な方法が明らかであろう。例えば、いくつかの実施形態によれば、サービスブローカーフレームワークは、リンクされたノードデータ構造（例えばノードグラフ）を構築することができ、その場合、各ノードは入力パラメータのセットであり、根ノードは、現在利用可能な入力パラメータであり、終端ノードは、現在利用可能な入力パラメータに欠落している入力パラメータを足したものであり、すべての他のノードは、それら２つのノードの間の中間の組み合わせとなる。ノード間のツリー上のエッジはそれぞれ、提案品又はサービスの１つに関連付けられ、関連付けられた提案品又はサービスに関して十分な入力を持つ各ノードを始端とし、そのサービスが採用された場合に結果的に生じる入力パラメータセットを記述する各ノードで終端する。そのような各エッジに様々な重みが割り当てられてよく、重みは、例えば、採用される新しいサービスの数を最小化するための定数１、ユーザに対するコストを最小化するための各サービスの価格、サービスの選択を促すための各サービスのレビュー評価付けなどである。データ構造を構築した後（利用可能な提案品から連結グラフを実際に作成できる場合）、ダイクストラのアルゴリズム又はＢｅｌｌｍａｎ−Ｆｏｒｄアルゴリズムなどの最短経路アルゴリズムを適用して、表示されているサービスに必要な入力を提供することになる最もコストが低いエッジのセット（すなわちサービス又は提案品のセット）を見つけることができる。
【０１１７】
[00132]  ステップ１２４５で、そのようなサービス又は提案品のセットが存在すると判定された場合、方法１２００はステップ１２５０に進んで、サービスブローカーフレームワークが、見つけられたサービスのセット（又は、そこから選択するためのサービスの複数のセット）と共に、サービスをユーザに表示する。一方、欠落している入力すべてを提供するために利用可能なサービスのセットが見つからない場合、方法１２００はステップ１２５５に進んで、サービスブローカーフレームワークが、欠落している入力パラメータを提供することになる新しいハードウェア提案品のセットを、可能性としては新しいサービス提案品と共に見つける。例えば、いくつかの実施形態では、エッジがハードウェア提案品とサービス提案品との両方によって定義され得る点を除いて、ステップ１２５５は、上記でステップ１２４０に関連して説明したものと同様の手法に従うことができる。いくつかの実施形態では、ステップ１２４０及び１２５５が単一の検索ステップにまとめられてもよい。例えば、ハードウェア提案品とサービス提案品との両方を持つグラフが１回検索され、いくつかの実施形態ではハードウェア提案品のエッジにコストペナルティを与えて、サービスブローカーフレームワークが、利用可能な場合には、欠落している入力を提供するためのサービスだけのセットを返すことを優先するようにする。欠落している入力を提供するための１つ又は複数のハードウェア提案品（及び可能性としては１つ又は複数のサービス提案品）を識別した後、ステップ１２６０で、要求されるサービスが、それらの見つかった付加オプションと共に表示される。
【０１１８】
[00133]  一方、ステップ１２２０で、表示されるサービスに関する要件を満たすのに十分なハードウェア及びサービスをユーザがすでに持っていると判定される場合、サービスブローカーフレームワークは、次いでステップ１２２５で、そのサービスが任意選択の入力パラメータに関連付けられているかどうかを判定し、関連付けられている場合は、ステップ１２３０で、その任意選択の入力パラメータが、そのサービスの性能又は満足度を向上させるかを判定する（例えば、その任意選択のパラメータを提供するユーザからのユーザ評価付け、レビュー、使用統計等を、その任意選択のパラメータを欠くユーザと比較することによる）。性能を向上させる任意選択のパラメータが実際に存在する場合、方法１２００はステップ１２３５に進んで、その任意選択の入力が、以後のステップために「欠落」とマークされ、方法１２００はステップ１２４０に進む。一方、任意選択のパラメータが存在しないか、任意選択のパラメータがサービスを大幅には向上させない場合、サービスブローカーフレームワークは、ステップ１２２５で、サービスの推薦は一切せずに、単にサービスを表示する。方法１２００は次いでステップ１２６５で終了に進む。
【０１１９】
[00134]  方法１２００は一例に過ぎず、選択されたサービスをどのように表示するか、又は補完的な提案品を推薦するオプションをどのように識別するかを決定するための様々な他の方法が用いられ得ることが認識されよう。例えば、いくつかの実施形態では、この方法は、それらが必要ではなく、性能を向上させると予想されない場合でも、少なくとも１つの付加提案品のセットを常に推薦してもよい。別の代替法として、一部の提案品は特徴として分類されてもよく、そのため常に提示されるか、又は表示されるサービス若しくは提案品に十分な関連性がある時はいつでも提示されてもよい。
【０１２０】
[00135]  図１３は、ユーザに対する新しいサービスを追加するためのインターフェース１３００の例を示す。インターフェース１３００は、消費者のデバイス（例えば、携帯電話、タブレット、ＰＣ、又はウェアラブルデバイス）に表示され、市場命令３１４により生成され得る。様々な実施形態において、インターフェース１３００は、サービスに関連付けられた提案品が選択又は購入された後に表示されることが可能であり、サービスの以後の動作を構成するために使用することができる。
【０１２１】
[00136]  図示されるように、インターフェース１３００もやはり、提案品を閲覧するためにインターフェース９００に表示されるもの９１２、９１４と同様の個別化された評価付け１３０５及び一般評価付け１３１０を含む。図示されるように、ユーザには、どのセンサデバイスが新しいサービスに入力パラメータを提供するかを決定するための複数のオプション１３１５、１３２０、１３２５が提示される。例えば、加速度計の選択１３１５で、ユーザは、加速度計データを提供するために、自分のモバイルデバイス又は腕時計ウェアラブルのどちらかを選択することができる（又はそれに代えて「ＭｏｂｉｌｅＰｈｏｎｅ１２３」及び「Ｗｒｉｓｔｗａｔｃｈ−５Ｄ３」）。サービスブローカーフレームワークは、腕時計ウェアラブルの選択が推薦されることを示す（例えば、それらのデバイスの両方が選択された時のサービスの性能又はユーザからの評価付けを比較することに基づく）。同様に、歩数計の選択１３２０で、ユーザは、サービスに歩数計データを提供するために、自分のモバイルデバイス、腕時計ウェアラブル、又はその両方を選択することができる。この選択１３２０は、両方のデバイスの選択を可能にするために、ラジオボタンに代えてチェックボックスの形態であってもよい。これは、例えば、サービスが複数の歩数計の供給元を利用するように適合されているが、一度に１つの供給元からしか加速度計データを受理しないときに望ましい可能性がある。歩数計入力パラメータが必要とされる場合、インターフェース１３００は、選択１３２０においてチェックボックスを両方とも非選択にすることを許さないようにしてもよい。活動の選択１３２５で、ユーザは、活動パラメータ（当該サービスには任意選択の入力パラメータ）が腕時計ウェアラブルデバイスから共有されるべきかどうかを指示することができる。
【０１２２】
[00137]  サービスアップグレードボタン１３３０は、一旦構成されるとサービスの性能を向上させるであろう活動パラメータを推定するサービスを提示し得る点で、インターフェース９００のアップグレードボタン９１８、９２４、９３８、９４４と同様であり得る。様々な実施形態において、そのような他のサービスの追加と選択要素１３１５、１３２０、１３２５の修正とにより、見込まれる入力が変更されるため、個別化された評価付け１３０５をアップグレードすることができる（例えば、個別化された評価付け１３０５に関してそれらのレビューを考慮するように、異なる「類似ユーザ」グループを選択することによる）。データ共有ボックス１３３５は、１つ又は複数の任意選択の第３者とデータを共有すべきことを指示するために選択可能とすることができる。場合によっては、ボックス１３３５を選択する結果、消費者がデータを共有することに同意する見返りに、消費者に対して割り引き又は支払いが行われることがある。確定ボタン１３４０は選択を送付し、適宜、且つサービスブローカーフレームワークがそのサービスに関して仲介として動作することになるかどうかに基づいて、サービスへのセンサのバインド又は共有構成の保存を行わせることができる。
【０１２３】
[00138]  図１４は、提案品の購入を遂行する方法１４００の例を示す。方法１３００は、サービスブローカーフレームワークによって行われることが可能であり、例えば提案品市場命令３１４に対応し得る。方法１３００は、購入のためにサービス（又はサービスを含む提案品）をユーザが選択するのに応答して実行され得る。例えば、いくつかの実施形態では、方法１４００は、インターフェース１３００の確定ボタン１３４０をユーザが選択するのに応答して実行される。
【０１２４】
[00139]  方法１４００は、ステップ１４０５で開始し、ステップ１４１０に進んで、サービスブローカーフレームワークが、その提案品が繰り返し発生する課金を必要とするか、それとも１回限りの購入を必要とするかを判定する。繰り返し発生する課金が生じることになる場合、方法１４００はステップ１４１０に進んで、サービスブローカーフレームワークが、ユーザ、課金額、及び課金期間を識別する契約レコードを作成し、初回の支払いを処理すべきことを課金エンジンに通知する。そうでない場合、サービスブローカーフレームワークは、ステップ１４２０で、単に課金エンジンによる処理のために請求書を提出する。
【０１２５】
[00140]  ステップ１４２５で、サービスブローカーフレームワークは、新しいサービスへの入力が、仲介としてのサービスブローカーフレームワークを通じて処理されるべきかどうかを判定する。例えば、サービスブローカーフレームワークは、選択されたデバイス（又はそれらの報告フレームワーク）のいずれかが、サービスアプリケーションデバイスに直接入力を提供するように構成可能であるかどうか、又は当該サービスがそのような仲介機能に対応して構成されているかどうかを判定する。そうである場合、サービスブローカーフレームワークは、ステップ１４３０でユーザプロフィールの中に新しい共有レコードを作成する。そのような共有レコードは、例えば、共有レコードのセット７６０に対応し得る。一方、サービスブローカーフレームワークが仲介として機能しない場合、サービスブローカーフレームワークは、続いて１４３５で、入力パラメータの必要とされる転送を遂行するようにセンサデバイス又はサービスアプリケーションデバイスを構成することによってセンサのバインドを容易にする。
【０１２６】
[00141]  ステップ１４４０で、サービスブローカーフレームワークは、新しいサービスが、他のサービスへの入力パラメータの役割を果たし得る出力パラメータを提供するかどうかを判定する。例えば、この情報は、インターフェース５００を介してサービス提供者によって指定されているか、又はサービスブローカーフレームワークのＡＰＩを介してサービスアプリケーションデバイスによって広告される可能性がある。提供する場合、サービスブローカーフレームワークは、そのサービスを、新しい入力パラメータの提供元となる新しいセンサデバイスとしてユーザプロフィールに追加する。例えば、サービスブローカーフレームワークは、センサデバイスレコード７４０に新しいレコードを追加する。方法１４００は次いでステップ１４００で終了に進む。
【０１２７】
[00142]  図１５は、入力の共有を容易にする方法１５００の例を示す。方法１５００は、センサデータ転送命令３９４によって行われ得る。方法１５００はステップ１５０５で開始し、サービスブローカーフレームワークが、ユーザの１つ又は複数のセンサデバイスから入力パラメータを受け取る。ステップ１５１０で、サービスブローカーフレームワークが、受け取られた入力パラメータに適用される、ユーザの共有許諾のセット（例えば、ユーザプロフィール７００にある共有構成７６０の１つ）を取り出す。次いで、ステップ１５１５で、サービスブローカーフレームワークは、現在の共有許諾レコードについてのサービス定義を取り出す。ステップ１５２０で、サービスブローカーフレームワークは、そのサービスレコードが、入力前処理スクリプトを識別するかどうかを判定し、識別する場合は、ステップ１５２５でそのスクリプトを実行する。次いで、サービスブローカーフレームワークは、ステップ１５３０で、共有許諾レコード中で識別されたサーバに入力を送信する。ステップ１５３５で、サービスブローカーフレームワークは、その入力に対して評価すべき追加的なサービス許諾レコードが残っているかどうかを判定する。残っている場合、方法１５００はステップ１５１５にループバックする。すべての共有許諾レコードが処理されると、方法はステップ１５４０で終了に進む。
【０１２８】
[00143]  図１６は、出力の提示を容易にする方法１６００の例を示す。方法１６００は、サービス提示命令３９６によって行われ得る。方法１６００は、ステップ１６０５で開始し、サービスブローカーフレームワークがサービスアプリケーションデバイスからデータを受け取る。サービスブローカーフレームワークは次いで、ステップ１６１０で、そのサービスのサービスレコードを取り出し、ステップ１６１５で、そのサービスが出力処理スクリプトを定義しているかどうかを判定する。定義している場合、サービスブローカーフレームワークは、ステップ１６２０でそのスクリプトを実行する。サービスブローカーフレームワークは次いで、ステップ１６２５で、消費者出力装置に出力を送り、ステップ１６３０で、パラメータを処理し、新しい入力パラメータとして出力する。例えば、サービスブローカーフレームワークは、入力処理方法１５００を呼び出して、これらの新しく受け取ったパラメータを処理することができる。方法１６００は次いでステップ１６３５で終了に進むことができる。
【０１２９】
[00144]  前述の説明から、本発明の様々な例示的実施形態は、ハードウェア又はファームウェアとして実施可能であることが明らかになるはずである。さらに、様々な例示的実施形態が、機械可読記憶媒体に記憶された命令として実施されることが可能であり、その命令が少なくとも１つのプロセッサによって読み出され、実行されて、本明細書に詳細に記載される動作を行う。機械可読記憶媒体は、パーソナルコンピュータ若しくはラップトップコンピュータ、サーバ、又は他のコンピューティングデバイスなどの機械によって可読の形態で情報を記憶するための任意の機構を含み得る。したがって、機械可読記憶媒体は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、及び同様の記憶媒体を含み得る。
【０１３０】
[00145]  当業者には、本明細書中のブロック図は、本発明の原理を具現化する例示的回路の概念図を表していることが認識されるはずである。同様に、フローチャート、流れ図、状態遷移図、疑似コード等は、実質的に機械可読媒体として表され、したがってそのコンピュータ又はプロセッサが明示的に図示されているか否かに関わらずコンピュータ又はプロセッサによって実行され得る、様々なプロセスを表していることが認識されよう。
【０１３１】
[00146]  様々な例示的実施形態についてその特定の例示的態様を特に参照して詳細に説明したが、本発明には他の実施形態が可能であり、その詳細には様々な明白な点で修正が可能であることを理解すべきである。当業者には容易に明らかであるように、変形例及び修正は、本発明の主旨及び範囲内に留まりながら遂行することができる。したがって、前述の開示、説明、及び図は、例示のみを目的とし、特許請求の範囲のみによって定められる本発明を何ら制限するものではない。
【図１】
0006745807.tif 000006
【図２】
0006745807.tif 000007
【図３】
0006745807.tif 000008
【図４】
0006745807.tif 000009
【図５】
0006745807.tif 000010
【図６】
0006745807.tif 000011
【図７】
0006745807.tif 000012
【図８】
0006745807.tif 000013
【図９】
0006745807.tif 000014
【図１０】
0006745807.tif 000015
【図１１−１】
0006745807.tif 000016
【図１１−２】
0006745807.tif 000017
【図１２】
0006745807.tif 000018
【図１３】
0006745807.tif 000019
【図１４】
0006745807.tif 000020
【図１５】
0006745807.tif 000021
【図１６】
0006745807.tif 000022