図面 (/)

技術 サービスとしてのウェアラブルデバイス

出願人 コーニンクレッカフィリップスエヌヴェ
発明者 クロニンジョンアメスジョントラウトカイル
出願日 2016年2月8日 (4年10ヶ月経過) 出願番号 2017-541622
公開日 2018年8月2日 (2年4ヶ月経過) 公開番号 2018-521369
状態 特許登録済
技術分野 診断用測定記録装置
主要キーワード 入力前処理 ウェアラブルデバイス 訓練済み アルゴリズム適用 データ収集者 ノードグラフ エネルギー消費情報 処理アクション
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年8月2日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (18)

課題・解決手段

本明細書に記載される様々な実施形態は、サービスブローカーフレームワーク又はデバイス、並びにそれに関連する方法及び非一時的な機械可読記憶媒体に関し、通信インターフェースと;ユーザに関連付けられ、ユーザのセンサデバイスから入手することが可能な入力タイプを指定するユーザプロフィールであって、入力タイプはユーザの生理学的パラメータである、ユーザプロフィール、並びに、それぞれのサービスに関連付けられ、それらのサービスを提供するそれぞれの入力タイプとサーバとを識別するサービスレコードを記憶したメモリと;プロセッサであって、通信インターフェースを介してユーザから、サービスレコードによって識別されるサービスを追加する要求を受け取ることであって、サービスレコードは、ユーザプロフィールによって指定される入力タイプがそのサービスによって入力として受理されることを示す、ことと、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行することとを行うように構成されたプロセッサと、を備える。

概要

背景

[0003]ウェアラブル技術には、身体に着用したり、個人衣類アクセサリーに取り付ける又は埋め込むことが可能で、現在消費者及び医療市場に存在する、任意タイプのモバイル電子デバイスが含まれ得る。ウェアラブル技術に関連するプロセッサ及びセンサは、情報を表示、処理、収集する、又は導き出すことができる。そのようなウェアラブル技術は、ユーザの健康データや他のタイプのデータ及び統計を監視することを含む幅広い領域で使用されることがある。これらのタイプのデバイスは、一般大衆が容易に入手することができ、消費者によって容易に購入することができる。健康関連の領域におけるいくつかのウェアラブル技術の例として、FIT BIT、NIKE+ FUEL BAND、及びAPPLE WATCHデバイスが挙げられる。

概要

本明細書に記載される様々な実施形態は、サービスブローカーフレームワーク又はデバイス、並びにそれに関連する方法及び非一時的な機械可読記憶媒体に関し、通信インターフェースと;ユーザに関連付けられ、ユーザのセンサデバイスから入手することが可能な入力タイプを指定するユーザプロフィールであって、入力タイプはユーザの生理学的パラメータである、ユーザプロフィール、並びに、それぞれのサービスに関連付けられ、それらのサービスを提供するそれぞれの入力タイプとサーバとを識別するサービスレコードを記憶したメモリと;プロセッサであって、通信インターフェースを介してユーザから、サービスレコードによって識別されるサービスを追加する要求を受け取ることであって、サービスレコードは、ユーザプロフィールによって指定される入力タイプがそのサービスによって入力として受理されることを示す、ことと、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行することとを行うように構成されたプロセッサと、を備える。

目的

[0004] 本明細書に記載される様々な実施形態は、サービスブローカーデバイスに関し、このサービスブローカーデバイスは、通信インターフェースと;ユーザに関連付けられ、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプを指定する、ユーザプロフィールであって、入力タイプはユーザの生理学的パラメータである、ユーザプロフィール、並びに、複数のサービスレコードであって、複数のサービスレコードのうち第1のサービスレコードは、サービス、入力タイプ、及びサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

通信インターフェースと、ユーザに関連付けられ、前記ユーザのセンサデバイスから入手可能である利用可能な入力タイプを指定する、ユーザプロフィールであって、前記利用可能な入力タイプは前記ユーザの生理学的パラメータである、ユーザプロフィール、並びに複数のサービスレコードであって、前記複数のサービスレコードのうち第1のサービスレコードは、サービス、入力タイプ、及び前記サービスを提供するサーバに関連付けられている、複数のサービスレコードを記憶したメモリと、前記通信インターフェース及び前記メモリと通信状態にあるプロセッサであって、前記通信インターフェースを介して前記ユーザから、前記複数のサービスレコードのうち前記第1のサービスレコードに関連付けられた前記サービスを前記ユーザに対して追加する要求を受け取ることであって、前記サービスレコードは、前記ユーザプロフィールによって指定される前記利用可能な入力タイプが、前記サービスを提供するための入力として前記サーバによって受理されることを示す、ことと、前記サービスレコードに関連付けられた前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行することとを行うプロセッサとを備える、サービスブローカーデバイス

請求項2

前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する際に、前記プロセッサは、入力装置構成情報を送信し、前記入力装置は、前記ユーザの前記センサデバイスと、前記センサデバイスから前記データを受け取る報告フレームワークデバイスとのうち少なくとも1つであり、前記構成情報は、前記サービスレコードによって識別される前記サーバに直接前記データを送信するように前記入力装置を構成する、請求項1に記載のサービスブローカーデバイス。

請求項3

前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する際に、前記プロセッサは、前記サービスレコードによって識別される前記サーバに資格証明情報を送信し、前記資格証明情報は、前記サーバが、前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも1つに前記データを要求することを可能にする、請求項1に記載のサービスブローカーデバイス。

請求項4

前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する際に、前記プロセッサは、前記サービスレコードによって識別される前記サーバに前記データを転送すべき旨の指示を前記ユーザと関連付けて記録し、前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも1つから前記データを受け取り、記録された前記指示に基づいて、受け取った前記データを前記サーバに送信する、請求項1に記載のサービスブローカーデバイス。

請求項5

前記サービスレコードは、送信の前に行われるべき入力処理アクションに関連付けられており、前記プロセッサはさらに、受け取った前記データを前記サーバに送信する前に、前記入力処理アクションに従って前記データを修正する、請求項4に記載のサービスブローカーデバイス。

請求項6

前記サービスレコードは、前記サービスの出力タイプに関連付けられており、前記出力タイプは別の生理学的パラメータであり、前記プロセッサはさらに、追加的な入力タイプの提供元となる追加的なセンサデバイスとして前記サービスを前記ユーザプロフィールに追加し、前記追加的な入力タイプは、前記サービスレコードによって識別される前記出力タイプである、請求項1に記載のサービスブローカーデバイス。

請求項7

前記プロセッサはさらに、前記サービスを追加する前記要求に応答して、前記ユーザと前記サービスの提供者とのうち少なくとも1つに対する課金を遂行する、請求項1に記載のサービスブローカーデバイス。

請求項8

前記プロセッサはさらに、前記ユーザに利用可能なサービスのセットを、ユーザから入手可能であるとユーザプロフィールで示される、前記利用可能なサービスのそれぞれの入力タイプに基づいて識別し、前記利用可能なサービスのセットを、前記ユーザに対して追加する個々のサービスの選択のために前記ユーザに提示する、請求項1に記載のサービスブローカーデバイス。

請求項9

前記プロセッサはさらに、前記ユーザから第1の追加的なサービスの選択を受け取ることであって、前記第1の追加的なサービスは、前記複数のサービスレコードのうち追加的なサービスレコードに関連付けられている、ことと、前記追加的なサービスレコードによって識別される追加的な入力タイプが前記ユーザから入手可能であると識別されないことを、前記ユーザプロフィールに基づいて判定することと、前記追加的な入力タイプを提供するであろう少なくとも1つの提案品を前記ユーザに提示することとを行う、請求項1に記載のサービスブローカーデバイス。

請求項10

前記提案品は、前記追加的な入力タイプを出力として提供する第2の追加的なサービスを含んでいる、請求項1に記載のサービスブローカーデバイス。

請求項11

ウェアラブルデバイスを介して提供されるサービスを拡張するためにサービスブローカーデバイスのプロセッサによって行われる方法であって、前記方法は、ユーザのセンサデバイスから入手可能である利用可能な入力タイプの識別を前記ユーザから受け取るステップであって、前記利用可能な入力タイプは前記ユーザの生理学的パラメータである、ステップと、サービスを追加する要求を前記ユーザから受け取るステップであって、前記サービスは前記利用可能な入力タイプを入力として受理することが知られている、ステップと、前記サービスを提供するサーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記利用可能な入力タイプとの送信を遂行するステップとを含む、方法。

請求項12

前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する前記ステップは、入力装置に構成情報を送信するステップであって、前記入力装置は、前記ユーザの前記センサデバイスと、前記センサデバイスから前記データを受け取る報告フレームワークデバイスとのうち少なくとも1つである、ステップを含み、前記構成情報は、前記サービスレコードによって識別される前記サーバに直接前記データを送信するように前記入力装置を構成する、請求項11に記載の方法。

請求項13

前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する前記ステップは、前記サービスレコードによって識別される前記サーバに資格証明情報を送信するステップを含み、前記資格証明情報は、前記サーバが、前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも1つに前記データを要求することを可能にする、請求項11に記載の方法。

請求項14

前記サービスレコードによって識別される前記サーバへの、前記ユーザの前記センサデバイスによって集められたデータと、前記サービスレコードによって識別される前記入力タイプとの送信を遂行する前記ステップは、前記サービスレコードによって識別される前記サーバに前記データを転送すべき旨の指示を前記ユーザと関連付けて記録するステップと、前記ユーザの前記センサデバイスと、前記センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも1つから前記データを受け取るステップと、記録された前記指示に基づいて、受け取った前記データを前記サーバに送信するステップとを含む、請求項11に記載の方法。

請求項15

前記サービスは、出力タイプを有する出力を提供し、前記出力タイプは別の生理学的パラメータであり、前記プロセッサはさらに、追加的な入力タイプの提供元となる追加的なセンサデバイスとして前記サービスを前記ユーザプロフィールに追加し、前記追加的な入力タイプは前記出力タイプである、請求項11に記載の方法。

技術分野

0001

関連出願の相互参照
[0001] 本出願は、2015年2月9日に出願された「Wearables as a service」という名称の米国仮出願第62/113,999号の優先権の利益を主張し、同仮出願の全開示内容は、あらゆる目的のために参照により本明細書に組み込まれる。

0002

[0002] 本明細書に記載される様々な実施形態はウェアラブルデバイスに関し、より詳細には、ただしこれに限らないが、追加されたサービスを通じてウェアラブルデバイスの機能を拡張するためのフレームワークに関する。

背景技術

0003

[0003]ウェアラブル技術には、身体に着用したり、個人衣類アクセサリーに取り付ける又は埋め込むことが可能で、現在消費者及び医療市場に存在する、任意タイプのモバイル電子デバイスが含まれ得る。ウェアラブル技術に関連するプロセッサ及びセンサは、情報を表示、処理、収集する、又は導き出すことができる。そのようなウェアラブル技術は、ユーザの健康データや他のタイプのデータ及び統計を監視することを含む幅広い領域で使用されることがある。これらのタイプのデバイスは、一般大衆が容易に入手することができ、消費者によって容易に購入することができる。健康関連の領域におけるいくつかのウェアラブル技術の例として、FIT BIT、NIKE+ FUEL BAND、及びAPPLE WATCHデバイスが挙げられる。

0004

[0004] 本明細書に記載される様々な実施形態は、サービスブローカーデバイスに関し、このサービスブローカーデバイスは、通信インターフェースと;ユーザに関連付けられ、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプを指定する、ユーザプロフィールであって、入力タイプはユーザの生理学的パラメータである、ユーザプロフィール、並びに、複数のサービスレコードであって、複数のサービスレコードのうち第1のサービスレコードは、サービス、入力タイプ、及びサービスを提供するサーバに関連付けられている、複数のサービスレコードを記憶したメモリと;通信インターフェース及びメモリと通信状態にあるプロセッサであって、通信インターフェースを介してユーザから、複数のサービスレコードのうち第1のサービスレコードに関連付けられたサービスをユーザに対して追加する要求を受け取ることであって、サービスレコードは、ユーザプロフィールによって指定される利用可能な入力タイプが、サービスを提供するための入力としてサーバによって受理されることを示すことと、サービスレコードに関連付けられたサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行することとを行うように構成されたプロセッサと、を備える。

0005

[0005] 本明細書に記載される様々な実施形態は、ウェアラブルデバイスを介して提供されるサービスを拡張するためにサービスブローカーデバイスのプロセッサによって行われる方法に関し、この方法は、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプの識別をユーザから受け取るステップであって、入力タイプはユーザの生理学的パラメータである、ステップと、サービスを追加する要求をユーザから受け取るステップであって、サービスは上記利用可能な入力タイプを入力として受理することが知られている、ステップと、そのサービスを提供するサーバへの、ユーザのセンサデバイスによって集められたデータと、利用可能な入力タイプとの送信を遂行するステップと、を含む。

0006

[0006] 本明細書に記載される様々な実施形態は、ウェアラブルデバイスを介して提供されるサービスを拡張するためにサービスブローカーデバイスのプロセッサによって実行するための命令が符号化された非一時的な機械可読記憶媒体に関し、この非一時的な機械可読記憶媒体は、ユーザのセンサデバイスから入手することが可能な利用可能な入力タイプの識別をユーザから受け取るための命令であって、入力タイプはユーザの生理学的パラメータである、命令と、サービスを追加する要求をユーザから受け取るための命令であって、サービスは利用可能な入力タイプを入力として受理することが知られている、命令と、そのサービスを提供するサーバへの、ユーザのセンサデバイスによって集められたデータと、利用可能な入力タイプとの送信を遂行するための命令と、を含む。

0007

[0007] 様々な実施形態が記載され、それらの実施形態では、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行する際に、プロセッサは、入力装置構成情報を送信するように構成され、入力装置は、ユーザのセンサデバイスと、センサデバイスからデータを受け取る報告フレームワークデバイスとのうち少なくとも1つであり、構成情報は、サービスレコードによって識別されるサーバに直接データを送信するように入力装置を構成する。

0008

[0008] 様々な実施形態が記載され、それらの実施形態では、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行する際に、プロセッサは、サービスレコードによって識別されるサーバに資格証明情報を送信するように構成され、資格証明情報は、サーバが、ユーザのセンサデバイスと、センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも1つにデータを要求することを可能にする。

0009

[0009] 様々な実施形態が記載され、それらの実施形態では、サービスレコードによって識別されるサーバへの、ユーザのセンサデバイスによって集められたデータと、サービスレコードによって識別される入力タイプとの送信を遂行する際に、プロセッサは、サービスレコードによって識別されるサーバにデータを転送すべき旨の指示をユーザと関連付けて記録し、ユーザのセンサデバイスと、センサデバイスに関連付けられた報告フレームワークデバイスとのうち少なくとも1つからデータを受け取り、記録された指示に基づいて、受け取ったデータをサーバに送信するように構成される。

0010

[0010] 様々な実施形態が記載され、それらの実施形態では、サービスレコードは、送信の前に行われるべき入力処理アクションを識別し、プロセッサは、受け取ったデータをサーバに送信する前に、入力処理アクションに従ってデータを修正するようにさらに構成される。

0011

[0011] 様々な実施形態が記載され、それらの実施形態では、サービスレコードは、上記サービスの出力タイプに関連付けられており、出力タイプは別の生理学的パラメータであり、プロセッサは、追加的な入力タイプの提供元となる追加的なセンサデバイスとしてサービスをユーザプロフィールに追加するようにさらに構成され、追加的な入力タイプは、そのサービスレコードによって識別される出力タイプである。

0012

[0012] 様々な実施形態が記載され、それらの実施形態では、プロセッサは、サービスを追加する要求に応答して、ユーザとサービスの提供者とのうち少なくとも1つに対する課金を遂行するようにさらに構成される。

0013

[0013] 様々な実施形態が記載され、それらの実施形態では、プロセッサは、ユーザに利用可能なサービスのセットを、ユーザから入手可能であるとユーザプロフィールで示される、利用可能なサービスのそれぞれの入力タイプに基づいて識別し、その利用可能なサービスのセットを、ユーザに対して追加する個々のサービスの選択のためにユーザに提示するようにさらに構成される。

0014

[0014] 様々な実施形態が記載され、それらの実施形態では、プロセッサは、ユーザから第1の追加的なサービスの選択を受け取ることであって、第1の追加的なサービスは、複数のサービスレコードのうち追加的なサービスレコードに関連付けられていることと、追加的なサービスレコードによって識別される追加的な入力タイプがユーザから入手可能であると識別されないことを、ユーザプロフィールに基づいて判定することと、追加的な入力タイプを提供するであろう少なくとも1つの提案品をユーザに提示することとを行うようにさらに構成される。

0015

[0015] 様々な実施形態が記載され、それらの実施形態では、提案品は、上記追加的な入力タイプを出力として提供する第2の追加的なサービスを含んでいる。

0016

[0016] 様々な例示的実施形態をよりよく理解するために、添付図面が参照される。

図面の簡単な説明

0017

[0017]サービスとしてのウェアラブルを提供するシステムの例を示す図である。
[0018] 本明細書に記載される様々なシステムに参加する様々なデバイスを実施するためのハードウェアの例を示す図である。
[0019] 例示的なサービスブローカーフレームワークを示す図である。
[0020] サービスとしてのウェアラブルを提供するための環境の例を示す図である。
[0021] 新しいサービスを定義するためのインターフェースの例を示す図である。
[0022] 新しい提案品を定義するためのインターフェースの例を示す図である。
[0023]ユーザプロフィールを定義するためのデータ配置の例を示す図である。
[0024] ユーザについてセンサデバイスを登録する方法の例を示す図である。
[0025] 提案品を閲覧するための例示的インターフェースを示す図である。
[0026] 提案品の推薦を生成する方法の例を示す図である。
[0027]予測モデル訓練する方法の例を示す図である。
[0028] サービスの詳細を表示する方法の例を示す図である。
[0029] ユーザに対する新しいサービスを追加するためのインターフェースの例を示す図である。
[0030] 提案品の購入を遂行する方法の例を示す図である。
[0031] 入力の共有を容易にする方法の例を示す図である。
[0032] 出力の提示を容易にする方法の例を示す図である。

実施例

0018

[0033] 本明細書に提示される説明及び図面は、様々な原理を例示する。当業者は、本明細書に明示的には記載又は示されないもののそれらの原理を具現化し本開示の範囲に含まれる様々な構成を考案できることが認識されよう。本明細書で使用される場合、用語「又は」は、別途指示されない限り(例えば、「さもなければ(or else)」又は「又は代替では(or in the alternative)」)、非排他的な又は(すなわち、及び/又は)を意味する。また、本明細書に記載される様々な実施形態は、必ずしも相互に排他的ではなく、組み合わせて、本明細書に記載される原理を組み込んだ追加的な実施形態を作り出すことが可能である。

0019

[0034] 多様なセンサのセットを有する多くの異なるウェアラブルデバイスが入手可能になっているが、それらのセンサの使用は、通例はデバイス製造者に結び付けられている。例えば、デバイスは、センサデータ解釈する(例えば生の加速度計データを歩数に変換する)アルゴリズムがあらかじめ組み込まれて出荷されることがあるが、そのアルゴリズムは、後に改良、拡張、又はその他の更新を行うことはできない。別の例として、ウェアラブルデバイスは、パラメータ(センサからの生のパラメータと内蔵アルゴリズムによって生成されるコンピュータパラメータの両方)を製造者のサーバに報告することがあり、製造者はその後、追加的な処理、編成、提示、及び他のサービスを提供する。しかし、これらのリモートサービスは、製造者が開発し、ホストし、その他のやり方で提供できる事柄に依然として結び付けられている。

0020

[0035]ウェアラブルデバイスのこれら及び他の態様に対処するために、本明細書に記載される様々な実施形態は、様々なウェアラブルデバイス製造者によって設定された堅固なフレームワークの外側でウェアラブルデバイスユーザに新しいサービスを提供するためのフレームワークに関する。いくつかの実施形態によれば、サービスブローカーフレームワークにより、ユーザは、ウェアラブルデバイス(及び他のデバイス)によって提供される、そのユーザが利用可能なセンサを登録し、第3者によって供されるサービスを購入し、追加されたサービスとそのサービスの動作が依存するセンサとの間の通信を容易にすることができる。

0021

[0036]図1は、サービスとしてのウェアラブルを提供するシステム100の例を示す。図示されるシステム100は、様々な機能構成要素とそれらの間の対話の一部を示している。そのような機能構成要素は、物理ハードウェア、及びいくつかの実施形態ではそのハードウェアによって実行されるソフトウェアを使用して実施されることが認識されよう。したがって、各機能デバイス又はエンジンは、専用ハードウェアデバイスとして具現化され得る。加えて、いくつかの実施形態では、システム100の機能デバイスの2つ以上が単一のハードウェアデバイスとして具現化され得る。例えば、いくつかの実施形態では、いくつかのセンサデバイス110、消費者出力装置130、及び消費者構成デバイス140が、例えば、十分なユーザインターフェース能力を備えた、モバイルデバイスタブレット、又はウェアラブルデバイス等の単一のデバイスとして具現化される。

0022

[0037] システム100は、いくつかの機能デバイスを単一のデバイスとして示し、他の機能デバイスを複数の同様のデバイスを含むものとして示しているが、代替の機構が可能であることが理解されよう。例えば、代替のシステムは、1つのみのセンサデバイス110を使用するが、複数の冗長なサービスブローカーフレームワーク120を含むことも可能である(例えば、図示されない負荷分散メカニズムを備えることにより、要求、ユーザデータ、又は他の利用性のある情報をそれらのサービスブローカーフレームワーク120間に均等に分配して、サービスブローカーフレームワーク120が多数の着用者及びセンサデバイス110に対応できるようにする)。

0023

[0038]センサデバイス110は、ユーザに関するデータ、ユーザの環境、ユーザの状況、ユーザに関連する様々な電子機器の状態等を感知することが可能な、実質的に任意のセンサであってよい。いくつかの実施形態では、センサデバイス110は、ユーザに関する生理学的パラメータを感知する。例えば、センサデバイス110は、加速度計、コンダクタンスセンサ、光学センサ温度センサマイクロフォンカメラ等を含み得る。これら又は他のセンサは、着用者を記述する生理学的パラメータを感知、算出、推定、又はその他のやり方で獲得するのに有用である可能性があり、そのようなパラメータには、例えば、歩数、歩行走行距離、立っている時間数、心拍数呼吸数血圧ストレスレベル体温消費カロリー安静時のエネルギー消費、活動時のエネルギー消費、身長、体重、睡眠測定値等がある。

0024

[0039] 多くの有用なパラメータをセンサデバイス110から直接取得することができるのに対し、他の有用なパラメータは、他の利用可能データ(センサデータを含む)から「抽出する」ことによって取得される。例えば、生の加速度計データを処理して、歩数、消費カロリーの推定値、又はユーザによって行われている活動(例えば、走る、テニスをする、自転車に乗る等)の推定を抽出することができる。したがって、システム内の様々なデバイスが、利用可能なパラメータ(例えば、感知されたパラメータ及び他の抽出されるパラメータ)を処理して新しいパラメータを生成するパラメータ抽出アルゴリズムを実施することができる。いくつかの実施形態では、センサデバイス110は、アルゴリズムが依存するパラメータを取得するセンサの少なくとも一部と同じデバイスの中でパラメータ抽出を行うために、又は、ユーザにとってローカルであるが、必ずしもプレディケートセンサと同じデバイス内ではないパラメータ抽出を行うために、そのようなアルゴリズムを実施することができる。例えば、いくつかの実施形態では、ウェアラブルブレスレットが加速度計データをユーザのモバイルデバイスに報告し、モバイルデバイスは次いでアルゴリズムを適用し、加速度計データを使用して歩数を推定する。それに加えて、又はそれに代えて、実質的にあらゆるデバイスが、そのようなパラメータ抽出アルゴリズムを適用してもよい(それらのアルゴリズムは、場合によっては、本明細書に記載されるシステム及び方法に従ってサービスとして提供される)。例えば、報告フレームワーク115、サービスブローカーフレームワーク120、サービスアプリケーションデバイス125、消費者出力装置130、又は何らかの他のデバイス(図示されている、又は図示されていないもの)が、デバイスに入手可能な入力パラメータからのパラメータ抽出を行うことができる。そのような他のデバイスが、他のサービスへの入力として使用され得るパラメータを抽出できる限りにおいて、そのような他のデバイスは、それら自体をセンサデバイス110とみなすことができる。例えば、加速度計データを処理して消費カロリーを推定するサービスアプリケーションデバイス125は、他のサービスにカロリーの推定値を提供するセンサデバイス110ともみなすことができる。

0025

[0040] 本明細書に記載される様々な実施形態によれば、センサデバイス110は、直接報告センサデバイス112及び間接報告センサデバイス114の2つのグループに分けることができる。直接報告センサデバイス112は、他のデバイス(例えば、サービスブローカーフレームワーク120又はサービスアプリケーションデバイス125)にパラメータを送信するように(例えばサービスブローカーフレームワークによって)構成されることが可能な任意のセンサデバイス110を含み得る。そのような構成は、パラメータが送信されるべきネットワーク上の場所を示すために、直接報告センサデバイス112の構成ファイルドメイン名又はIPアドレスを追加することを含むことができる。代替法として、別のデバイス(例えばサービスブローカーフレームワーク120)が、そのようなパラメータが報告されることを周期的に要求してもよい。様々な認証及び許可も行われてよく、例えば、パラメータの送信先となるデバイスの識別を確認するための情報(例えばパスワード又は公開鍵)と共に、直接報告センサデバイス112を構成する。いくつかの実施形態では、そのような構成は、ユーザによる手動承認を必要とする場合もある。

0026

[0041] 一方、間接報告センサデバイス114は、そのように構成可能でないことがあり、代わりに、例えば、センサデバイス110の製造者の独自仕様のサーバやAWSモノインターネットIoTクラウドプラットフォームなどのフレームワークなど、事前定義されたエンティティにのみパラメータを報告することができる。まとめて、これらの他のエンティティは、報告フレームワーク115を構成するとみなすことができる。報告フレームワーク115は、間接報告センサデバイス114によって報告されたパラメータ(及びいくつかの実施形態では、報告フレームワーク115自体によって抽出されたパラメータ)へのアクセスを可能にするアプリケーションプログラマインターフェース(API)を提供することができる。上記で直接報告センサデバイスに関して説明したように、同様の認証及び許可処置が、報告フレームワーク115及び間接報告センサデバイス114に関して取られてもよい。例えば、サービスブローカーフレームワーク120は、(APIを介して)報告フレームワーク115に、サービスブローカーフレームワーク120に提供すべきパラメータの識別を、そのような共有に対するユーザの承認を示す(又はそのような承認を得る際に有用な)トークンと共に、指示することができる。その後、報告フレームワーク115は、周期的に、又は要求の際に、そのようなパラメータをサービスブローカーフレームワーク120(又はサービスアプリケーションデバイス125などの他のデバイス)に送信することができる。

0027

[0042]サービスブローカーフレームワーク120は、サービスとしてのウェアラブルを容易にするための様々な機能を行う1つ又は複数のデバイスであってよい。様々な実施形態によれば、サービスブローカーフレームワークは、サービスブローカーフレームワークを介して供されるサービスをユーザが閲覧し、契約するための「市場」を提供する。そのため、サービス提供者構成デバイス150(例えば、パーソナルコンピュータ、サーバ、VM等)が、サービスブローカーフレームワーク120と(例えばウェブページ又はAPIを介して)通信して、サービスブローカーフレームワーク120の市場によって容易にされるサービスを定義し、提案者構成デバイス145(例えば、パーソナルコンピュータ、サーバ、VM等)が、サービスブローカーフレームワーク120と(例えばウェブページ又はAPIを介して)通信して、サービスブローカーフレームワーク120を通じて消費者に供される1つ又は複数の提案品(例えば、サービス、ハードウェア、サービス又はハードウェアのパッケージ等の)を定義し、そして、消費者構成デバイス140(例えば、携帯電話、タブレット、パーソナルコンピュータ、ウェアラブルデバイス等)が、サービスブローカーフレームワーク120と(例えばウェブページ又はAPIを介して)通信して、ユーザのセンサデバイス110を登録し、サービスを契約し、ハードウェアを購入する等できる。いくつかの実施形態では、サービス提供者は、サービスを定義又は構成する際に、可能性としては単一のインターフェース又はインターフェースのグループを使用して、そのサービスを販売又は契約のために供することもできる。そのような実施形態では、サービス提供者構成デバイス150は、提案者構成デバイス145とみなすこともできる。

0028

[0043] いくつかの実施形態では、サービスブローカーフレームワーク120は、システム100の様々なデバイス間のパラメータの送信も容易にすることができる。例えば、いくつかの実施形態では、サービスブローカーフレームワーク120は、サービスのための入力パラメータを集めるか又はその他のやり方で受け取り、それらを当該ユーザが契約しているサービスに従って処理するためにサービスアプリケーションデバイス125に転送することにより、仲介として機能することができる。いくつかのそのような実施形態では、サービスブローカーフレームワーク120は、パラメータをサービスアプリケーションデバイス125に転送する前に、何らかの前処理(例えば、追加的なパラメータ抽出、フォーマッティング、変換、パラメータのパッケージング等)を行うことができる。同様にして、サービスブローカーフレームワーク120は追加的に、サービスアプリケーションデバイス125によって出力された情報を(ここでも可能性としては前処理を施して)、消費者出力装置130に返すことを容易にすることができる。

0029

[0044] 別の例として、サービスブローカーフレームワーク120は、サービスブローカーフレームワーク120が仲介として機能することなくデバイス間に通信を確立するように1つ又は複数のデバイスを構成することにより、それらデバイス間のパラメータの送信を容易にすることができる。例えば、サービスブローカーフレームワーク120は、サービスアプリケーションデバイス125のアドレスを関連するセンサデバイス110又は報告フレームワーク115に提供して、それらのデバイスが後にサービスアプリケーションデバイス125にパラメータを送信できるようにする。それに加えて、又はそれに代えて、サービスブローカーフレームワーク120は、ポーリングのために、関連するセンサ110又は報告フレームワーク115のアドレスをサービスアプリケーションデバイス125に提供してもよい。いくつかの実施形態では、これらのデバイスのうちいずれかの構成は、許可情報を提供することも含んでよく、許可情報は、例えば、パラメータの送信時又はそのような送信の要求の際に提示するためにサービスブローカーフレームワーク120又は他のデバイスによって生成される許可トークン(例えばAPIトークン)である。

0030

[0045]サービスブローカーフレームワーク120は、1つ又は複数の課金システム155に支払いの要求を提出することにより、購入及び契約に関連する課金も容易にすることができる。例えば、消費者がサービスへの契約の支払いを月ごとに行う場合、サービスブローカーフレームワーク120は、消費者の支払い機器に対する支払いの要求を毎月提出することができる。例えば、購入時の1回払い、すべて若しくは一部が消費者以外の当事者による支払い(例えば、保険会社や、インセンティブプログラムの一部である医師による)、又は消費者自身に対する支払い(例えば、別のサービスとして、若しくは別のサービスとの関係でデータを共有する、若しくは広告を受け取る承認に対する報酬)などの追加的な機構及び修正が明らかであろう。

0031

[0046] 様々な実施形態において、サービスブローカーフレームワーク120によって容易にされるサービスは、例えばサービス提供者によって運営される外部のサービスアプリケーションデバイス125にホストされることが可能である。サービスアプリケーションデバイス125は、例えば、入力を処理し、消費者に供されるサービスに従って何らかの出力(例えば、追加的な抽出されたパラメータ、コーチング等)を提供するように構成されたサーバ又はVMであってよい。いくつかの実施形態では、サービスは、1つ又は複数のアルゴリズム(例えばパラメータ抽出アルゴリズム)を直接消費者のデバイス(例えばセンサデバイス110又は他のデバイス)にインストールすることによって提供することができ、そのような実施形態では、消費者のデバイスはサービスアプリケーションデバイス125とみなすことができ、消費者出力装置130と同一のデバイスであり得る。したがって、いくつかの実施形態では、サービスブローカーフレームワーク120は、同じ消費者によって所有される複数のデバイス間のパラメータの送信を容易にするように働くことができる。

0032

[0047]消費者出力装置130は、サービスアプリケーションデバイス125から直接、又はサービスブローカーフレームワーク120を介してのいずれかにより、1つ又は複数のサービスからの出力を受け取るために消費者がアクセスできる実質的に任意のデバイスであってよい。例えば、消費者出力装置130は、パーソナルコンピュータ、携帯電話、タブレット、又はウェアラブルデバイスである。いくつかの実施形態では、消費者出力装置130は、ウェブブラウザを介してサービスアプリケーションデバイスから(例えば、サービスアプリケーションデバイスによってホストされるウェブサイトから)、又はサービス提供者によって提供される、消費者出力装置にインストールされたアプリ若しくは他のプログラム(例えば、サービスアプリケーションデバイス125若しくはサービスブローカーフレームワーク120によってプッシュされた出力を受け取るサービスフロントエンドプログラム)から出力を受け取るか、又は、サービスアプリケーションデバイスによって供されるAPIを介して出力にアクセスすることができる。例えば、電子メール、電話テキストメッセージなど、サービスアプリケーションデバイス125と消費者出力装置130との間の通信のための様々な追加的チャネルが明らかであろう。消費者出力装置130がサービスの出力にアクセスするためにアプリを利用する実施形態では、サービスブローカーフレームワーク120は、サービスを契約すると、消費者出力装置を、アプリ又はそのアプリをダウンロードできる場所(例えば、サービスブローカーフレームワーク120によって運営されるサーバ、又はサービスブローカーとは独立した別のアプリ市場)にリンクする(又は、その他のやり方でアプリ若しくは場所の識別を提供する)ことができる。

0033

[0048] 様々な実施形態によれば、消費者及びサービス提供者に加えて、様々な提案者及び他の第3者が本システムに参加し得る。そのため、提案者及び第3者デバイス135は追加的に、パラメータ、人口統計学的データ、使用状況データ、及び他の情報などの情報を、サービスブローカーフレームワーク120、サービスアプリケーションデバイス125、又は他のデバイスから受け取る可能性がある。例えば、いくつかの実施形態では、医師サーバ135が、消費者としてシステムに参加している患者についての情報を受け取り、広告サーバ135が、消費者に表示するための広告を提供し、そのような表示及びクリックスルーについての情報を受け取り、第3者のデータ収集者が、ユーザがそのような収集に同意している場合はパラメータ及び他の情報を受け取り(例えば、そのようなデータ収集引き換えにユーザに支払いをする、又は1つ若しくは複数のサービスの割り引きを提供する提案品の一部として)、クラウドサービス提供者(例えばクラウドストレージ)がデータを受け取り、そのデータを記憶し、後にサービスブローカーフレームワーク120又はサービスアプリケーションデバイス125が検索(又は処理などの他のサービス)することができる(例えば、サービスがそのような追加的なサービスを必要とするが、その場ではそれらのサービスを提供しない場合、又はサービスブローカーフレームワーク120を介した、若しくはその他のやり方による消費者による別個調達を伴わない場合)。

0034

[0049]図2は、図1のシステム100の様々な機能デバイスなど、本明細書に記載される様々なシステムに参加する様々なデバイスを実施するためのハードウェア200の例を示す。例えば、ハードウェア200は、センサデバイス110、サービスブローカーフレームワーク120、消費者構成デバイス140、消費者出力装置130、サービスアプリケーションデバイス125、又は本明細書に記載されるその他のデバイスのいずれをも実施することができる。図示されるように、デバイス200は、プロセッサ220、キャッシュシステムメモリ230、ユーザインターフェース240、ネットワークインターフェース250、及びストレージ260、並びに一部のデバイスに関してはセンサ245を含み、これらは1つ又は複数のシステムバス210を介して相互に接続されている。図11は、いくつかの点で抽象化を構成しており、デバイス200の構成要素の実際の編成は図よりも複雑であり得ることが理解されよう。

0035

[0050]プロセッサ220は、メモリ230又はストレージ260に記憶された命令を実行する、又は他のやり方でデータを処理することが可能な任意のハードウェアデバイスであってよい。そのため、プロセッサは、マイクロプロセッサフィールドプログラム可能ゲートアレイFPGA)、特定用途集積回路ASIC)、又は他の同様のデバイスを含み得る。1つ又は複数のASICに依拠する実施形態などのいくつかの実施形態では、部分的にソフトウェアを介して提供されると説明される機能は、代わりに、ASICの動作にハードワイヤードされることが可能であり、そのため、関連するソフトウェアが省略されてもよい。

0036

[0051]キャッシュ/システムメモリ230は、例えば、L1、L2、若しくはL3キャッシュ又はシステムメモリなど、各種メモリを含み得る。そのため、メモリ230は、静的ランダムアクセスメモリ(SRAM)、動的RAM(DRAM)、フラッシュメモリ読出し専用メモリ(ROM)、又は他の同様のメモリデバイスを含み得る。

0037

[0052]ユーザインターフェース240は、管理者などのユーザとの通信を可能にする1つ又は複数のデバイスを含むことができる。例えば、ユーザインターフェース240は、ディスプレイマウスキーボードタッチ画面、ボタン、カメラ、マイクロフォン、振動器触覚エンジン等を含み得る。いくつかの実施形態では、ユーザインターフェース240は、通信インターフェース250を介してリモート端末に提示されることが可能な、コマンドラインインターフェース又はグラフィックユーザインターフェースを含む。

0038

[0053]センサ245は、本明細書に記載されるように、例えば、加速度計、ジャイロスコープ、コンダクタンスセンサ、光学センサ、温度センサ、マイクロフォン、カメラ等、ユーザ、環境等からパラメータを感知することが可能な実質的に任意のデバイスであってよい。いくつかの実施形態では、センサ145は、ユーザインターフェース240と共通のハードウェアを共有することができる。

0039

[0054]通信インターフェース250は、他のハードウェアデバイスとの通信を可能にする1つ又は複数のデバイスを含み得る。例えば、ネットワークインターフェース250は、Ethernetプロトコルに従って通信するように構成されたネットワークインターフェースカード(NIC)を含む。加えて、通信インターフェース250は、TCP/IPプロトコルに従った通信のためにTCP/IPスタックを実施することができる。通信インターフェース250についての様々な代替又は追加のハードウェア又は構成が明らかであろう。いくつかの実施形態では、通信インターフェース250は、NFC、Bluetooth(登録商標)、又は他の短距離ワイヤレスインターフェースを含む。通信インターフェース250についての様々な代替又は追加のハードウェア又は構成が明らかであろう。

0040

[0055]ストレージ260は、読出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶媒体、光学記憶媒体フラッシュメモリデバイス、又は同様の記憶媒体などの1つ又は複数の機械可読記憶媒体を含み得る。様々な実施形態において、ストレージ260は、プロセッサ220により実行するための命令、又はプロセッサ220が作用し得るデータを記憶することができる。例えば、ストレージ260は、ハードウェア200の様々な基本的動作を制御するオペレーティングシステム261を記憶する。

0041

[0056]デバイス200がセンサデバイス110を実施する場合、ストレージ260は、新しいデータを獲得する際に新しい生データを求めて周期的にセンサ245をポーリングするためのセンサポーリング命令262も含むことができる。ストレージ260は、センサポーリング命令によって取得されたパラメータ、他のパラメータ抽出アルゴリズム254から、又は他のデバイスから追加的なパラメータを抽出するために、1つ又は複数のパラメータ抽出アルゴリズム264を実行するためのパラメータ抽出アルゴリズム適用命令263も含むことができる。いくつかの実施形態では、パラメータ抽出アルゴリズムのセット264は、新しいアルゴリズム264の追加によって補充されることが可能である(例えば新しいサービスを契約した結果)。そのような機能の拡張を可能にするために、パラメータ抽出アルゴリズム適用命令263は、実行時中にパラメータ抽出アルゴリズム264の各々を呼び出すように適合される。例えば、いくつかの実施形態では、パラメータ抽出アルゴリズム264は、解釈されるコード(例えば、Java(登録商標)又は独自仕様のデバイスコード)を使用して書かれ得るのに対し、パラメータ抽出アルゴリズム適用命令263は、適切な解釈エンジン(例えば、Java(登録商標)実行時環境又は他のインタープリタ)を含むか、又はそれを呼び出す。別の例として、パラメータ抽出アルゴリズムは、代わりにコンパイルコードであってもよく、一方、パラメータ抽出アルゴリズム適用命令263は、各パラメータ抽出アルゴリズムを順に呼び出すコードを含んでもよい。いくつかの実施形態では、抽出アルゴリズム適用命令263は、各パラメータ抽出アルゴリズム264を順番に呼び出すコードと同じ位単純であってもよい。アルゴリズムに基づく機能を拡張するための様々な追加的な編成が明らかであろう。

0042

[0057]ストレージ260は、センサポーリング命令262によって感知された、又はパラメータ抽出アルゴリズム264によって抽出されたパラメータを送信するためのパラメータ報告命令265も含むことができる。例えば、センサデバイス110が間接報告センサデバイス114である場合、パラメータ報告命令265により、プロセッサは、パラメータを報告フレームワーク115に送信する。センサデバイス110が直接報告センサデバイス112である場合、パラメータ報告命令265により、プロセッサ220は、パラメータ報告構成266の中で識別される、又は許可されている1つ又は複数のデバイスにパラメータを送信することができる。パラメータ報告命令265は、周期的に、新しいパラメータの獲得の際に、又は別のデバイスからプル要求を受け取った際に、動作することができる。

0043

[0058]センサデバイス110が少なくともローカルに集められた、又は抽出されたパラメータの何らかの出力を提供する実施形態などのいくつかの実施形態では、ストレージ260は、例えばユーザによって要求された際に、パラメータの表示又は他の出力を行わせるパラメータ出力命令267も含む。センサデバイス110が消費者出力装置130でもある実施形態では、パラメータ出力命令267は追加的に、リモートパラメータ受信命令268を介して他のデバイスから受け取られたパラメータ又は他の情報の出力を遂行することができる。そのようなリモートパラメータ受信命令268は、周期的に、ユーザによって要求された時(例えば、サービス提供者と同期するため、若しくは遠隔で取得されるパラメータを表示するために)、又は、そのようなパラメータが、要求、受信、解釈、記憶、若しくは他のやり方でリモートパラメータを処理するために利用可能であることを示すリモートデバイスからの指示があった際に、動作することができる。

0044

[0059]デバイス200が消費者構成デバイス140又は消費者出力装置130である場合、ストレージ260は、ウェブブラウザ271及び1つ又は複数のアプリ272を含むことができる。本明細書に記載される様々な機能は、それに代えて、リモートウェブサーバと対話するウェブブラウザ271、又はAPIを介してサーバと対話するアプリ272を介して実現することも可能であることが認識されよう。例えば、サービスブローカーフレームワーク120を介して供される市場へのアクセスを消費者に提供するために、ウェブブラウザが、その市場のために設定されたURLを指し示すようにすることができ、又は市場アプリがダウンロードされ、市場サーバと通信するために開かれてもよい。同様に、消費者がサービスからの出力(例えば、パラメータ、履歴グラフチャートコーチングプログラム)を受け取ることを可能にするために、ウェブブラウザ271は、サービスアプリケーションデバイスのために設定されたURLを指し示すようにすることができ、又はアプリ272がダウンロードされ、そのサービスへの入り口を提示するために実行されてもよい。

0045

[0060]デバイスがサービスアプリケーションデバイス125である場合、ストレージ260は、1つ又は複数のデバイスからの入力パラメータを要求、受信、解釈、又はその他のやり方で処理するための入力パラメータ受信命令281を含むことができる。例えば、入力パラメータ受信命令281は、センサデバイス110、報告フレームワーク115、サービスブローカーフレームワーク120、又は他のサービスアプリケーションデバイス125と通信して、そのような入力パラメータを受け取ることができる。パラメータを受け取った後、サービスアルゴリズム282が、そのパラメータを処理して(可能性としては、そのユーザについて以前に受け取られたパラメータ及び情報と共に)、ユーザに提示される新しいパラメータ及び他の情報等の出力を生成する。サービスアルゴリズム282の具体的な機能は、サービス提供者によって供される特定のサービスに応じて大きく異なる。理解されるように、本明細書に記載される様々な方法は、ウェアラブルデバイス及び他のセンサデバイス110との関係で、実質的に任意のサービスの提供を容易にする。ウェブサーバ283又は出力提示命令284は、消費者、サービスブローカーフレームワーク120、他のサービスアプリケーションデバイス125、及び他の第3者などの関係者に出力を通信することを可能にする。例えば、出力提示命令284は、消費者にサービスへのウェブベースのインターフェースを提供するためにウェブサーバと併せて使用されるスクリプト及びマークアップを含むことができる。それに代えて、出力提示命令284は、消費者のアプリを通じて提示するために、アプリにデータをプッシュしてもよい。出力パラメータ報告命令285は、具体的には、そのような出力パラメータが使用されるか、又は他のサービスへの入力として他の形で有用であるときに、個々のパラメータを、サービスブローカーフレームワーク120又は他のサービスアプリケーションデバイス125に報告して戻すことができる。

0046

[0061]ストレージ260に記憶されるものと説明される様々な情報は、それに加えて、又はそれに代えてメモリ230に記憶されることも可能であることが明らかであろう。この点で、メモリ230は「記憶装置」を構成するとみなすこともでき、ストレージ260は「メモリ」とみなすことができる。様々な他の機構が明らかであろう。さらに、メモリ230及びストレージ260はどちらも「非一時的な機械可読媒体」とみなすことができる。本明細書で使用される場合、用語「非一時的」は、一時的な信号を除外するが、揮発性メモリ及び不揮発性メモリの両方を含む、あらゆる形態のストレージを含むものと理解されるものとする。

0047

[0062]デバイス200は、説明される各構成要素を1つ含むものとして図示されているが、様々な構成要素は、様々な実施形態において重複する場合もある。例えば、プロセッサ220は、本明細書に記載される方法を独立して実行されるように構成された、又は、複数のプロセッサが協働して本明細書に記載される機能を実現するように本明細書に記載される方法のステップ若しくはサブルーチンを行うように構成された、複数のマイクロプロセッサを含み得る。さらに、デバイス200がクラウドコンピューティングシステム内に実施される場合、様々なハードウェア構成要素は、別々の物理的システムに属し得る。例えば、プロセッサ220は、第1のサーバ内の第1のプロセッサ及び第2のサーバ内の第2のプロセッサを含み得る。

0048

[0063]図3は、図1のサービスブローカーフレームワーク120を実施するための例示的サービスブローカーフレームワーク300を示す。サービスブローカーフレームワーク300は、図2のハードウェアデバイス200が図1のサービスブローカーフレームワーク120を実施するときに、ストレージ260の内容を記述することができる。いくつかの代替実施形態では、サービスブローカーフレームワーク300の様々な機能は、代わりに複数のデバイスに分散されてもよく、例えば、第1のVMがインターフェース310、330、340を実施し、第2のVMがサービス容易化エンジン390を実施する。様々な追加的な機構が明らかであろう。

0049

[0064] 図示されるように、サービスブローカーフレームワーク300は3つのインターフェースを備え、それらは、消費者構成インターフェース310、提案者インターフェース330、及びサービス提供者構成インターフェース340であり、それぞれは、各自の別個の機能を定義する機能の様々なセットによって実施され得る。これらに限定されないが、アカウント作成命令課金構成命令、使用状況統計命令等、これらのインターフェース310、330、340に含める命令の様々な追加的なセットが明らかであろう。

0050

[0065] 図示されるように、消費者構成インターフェース310は、ユーザが、サービスブローカーフレームワーク300を介して供されるサービスと併せて使用するために自身のセンサデバイスを登録することを可能にするセンサ登録命令312を含む。新しいセンサデバイスを認識するか、又はそれを許可すると、そのデバイスの識別が(可能性としては、デバイスアドレス、報告フレームワークアドレス等の他の情報、又はそのセンサデバイスから入手可能な入力パラメータのタイプと共に)、そのユーザのユーザプロフィール350に記録される。そこから、そのユーザに利用可能な入力のタイプを判定するため(例えば、ユーザに提示する提案品を推薦若しくはフィルタリングするため)、又はセンサデバイスと通信するため(例えばセンサデバイスを他のサービスにバインドするため)に、ユーザプロフィールを他の構成要素が調べることができる。本明細書で使用される場合、用語「ユーザプロフィール」は、ユーザと、そのユーザのサービスブローカーフレームワーク300の使用とに関係する情報をまとめて保持するレコード又はレコードの集まりを指すと理解されるものとする。

0051

[0066] 新しいセンサデバイスを登録するための様々な手法が、センサ登録命令によって利用され得る。例えば、いくつかの実施形態では、センサ登録命令は、センサデバイスの識別子を、消費者構成デバイスから受け取る(例えば、ユーザによって手動でタイプ入力される、バーコードQRコード(登録商標)を介してカメラにより、若しくは光学文字認識を使用して取り込まれる、又はNFC若しくはBluetooth(登録商標)などの近距離通信を介して消費者構成デバイスによって受け取られる)か、或いは、センサデバイス自体から直接受け取る(例えば、製造時、又は報告ネットワークへの登録の際にメモリに記憶されたもの)。いくつかの実施形態では、識別子は、MACアドレスやIPアドレスなどのネットワークアドレスであるか、又は他のやり方でそれを含んでもよい。識別子が少なくとも部分的に動的である(例えばIPアドレス)いくつかの実施形態では、センサ登録命令は、識別子の動的部分を更新するために周期的に再実行することができる。識別子を受け取ると、センサ登録命令312は、例えば報告フレームワークとの通信を通じて、デバイスを検証することができる。加えて、センサ登録命令は、この場合も報告フレームワークなどの別のデバイス又はセンサデバイス自体と通信することにより、デバイスとの関連で許可を受け取ってもよい。

0052

[0067] 提案品市場命令314は、選択、購入、又は契約のために提案品データベースにある利用可能な提案品を消費者に提示することに関係して、様々な機能を行うことができる。例えば、様々な実施形態において、提案品市場命令は、消費者構成デバイス上のウェブブラウザ又はアプリを介して店舗を提示する。この店舗を介して、消費者は、サービス及び製品についての様々な提案品を閲覧、検索、選択することができる。いくつかの実施形態では、提案品市場命令314は追加的に、消費者に提案品を推薦するための推薦エンジンを含む。例えば、提案品市場命令314は、ユーザが十分な入力、高度な入力、又は最適な入力を提供できることをユーザプロフィール350が示しているサービスに関して、提案品を識別する。別の例として、提案品市場命令314は、ユーザに合わせて個別に調節された提案品を推薦するために、規則セット又は学習済みモデルと併せて、消費者についての情報を使用することができる(例えば、利用可能な入力、パラメータ値、人口統計学的データ、健康記録、アプリの使用状況等)。例えば、心臓発作既往がある50男性には、心臓に関する健康コーチングサービスを推薦することができるのに対し、特定のソーシャルネットワーキングアプリを使用して比較的多量の時間をログしている18才の者には、フィットネスに関する達成を公開のためにソーシャルネットワーキングアプリにプッシュするサービスを供することができる。

0053

[0068]提案者インターフェース330は提案品作成命令334を含み、一方、サービス提供者インターフェース340はサービス作成命令344を含む。いくつかの実施形態では、提案者の役割とサービス提供者の役割とが単一の当事者によって保有され得ることが明らかであろう。例えば、アルゴリズム開発者自身が、契約のために自作のアルゴリズムを供することができる。そのような実施形態では、提案品作成命令334は、サービス提供者インターフェース340の一部を形成することができ、いくつかのそのような実施形態では、サービス作成命令344の一部を形成することができる。例えば、サービス提供者は、新しいサービスを定義し、それと同時か、並行してか、又はその他の形で同じ時に、その新しいサービスを契約のために供したい場合がある(可能性としては、他のサービス、ハードウェア等を含むパッケージ提案品の一部として)。いくつかの実施形態では、提案者は、例えば、医師、広告主、保険会社、データ収集者等、サービス提供者以外の当事者である場合もある。そのため、提案品作成命令334は、他のサービス提供者によって供される1つ又は複数のサービスを選択するため、並びに支払いの詳細事項を識別するため(例えば、提案者が消費者へのサービスの費用助成する、又はまかなう場合)のインターフェースを提供することができる。

0054

[0069]消費者が契約サービスを含む提案品を選択すると、提案品市場命令314は、契約データベース360に契約レコードを書き込み、それが次いで課金エンジン370によって読み出されて、該当する当事者への支払いを遂行する。同様に、提案品が即時購入品(例えば、新しいハードウェアや、1回払いのサービス)を含んでいる場合、提案品市場命令は、その支払いを直ちに処理するように課金エンジン370に命令する。さらに、消費者に対して新しいサービスを追加すると、提案品市場命令314は、その新しいサービスを識別するため、又はその新しいサービスを受けるために消費者のアカウントを他のやり方で構成するために、ユーザプロフィール350を更新する。例えば、提案品市場命令314は、ユーザプロフィールに、特定の入力のセットが特定のサーバのセットと共有されるべき旨の指示を記憶する。

0055

[0070]サービス容易化エンジン390も、サービスの分散された実行を可能にする様々な通信を誘導するのを助けるために配備され得る。いくつかの実施形態では、サービスブローカーフレームワーク300が仲介として機能することなく、入力パラメータを直接受け取るサービスなどの場合がある。センサデバイスは、そのような直接の通信を確立することによって(例えば、サービスアプリケーションサーバと、センサデバイス又は報告フレームワークとの間)、サービスに「バインド」することができる。そのようなサービスに対して、センサバインド命令392は、例えば、サービスアプリケーションサーバに入力パラメータの供給元(例えばネットワークアドレス)を知らせることによって、又は入力装置若しくは報告フレームワークに各自の入力パラメータの行先(例えばネットワークアドレス)を知らせることによって、バインドを容易にすることができる。センサバインド命令は、通信を安全にすべきこれらデバイスの1つ又は複数に、許可トークン、パスワード、鍵等を提供してもよい。

0056

[0071] いくつかの実施形態では、サービスブローカーフレームワーク300を介して入力パラメータを受け取るサービスなどの場合、センサデータ転送命令394は、様々なセンサデバイスから入力を受け取り、ユーザプロフィール350中の構成に従って、それらの入力を各自の該当する行先(例えば、サービスアプリケーションサーバ又は第3者サーバ)に転送することができる。いくつかの実施形態では、センサデータ転送命令394は、そのような転送の前に何らかの前処理を行ってもよい(例えば、サービスデータベース中の当該サービスの構成に従って)。同様にして、いくつかの実施形態では、サービス容易化エンジン390は、消費者出力装置への出力通信を容易にすることができ、そのため、サービス提示命令は、出力を受け取り、サービスデータベース380に定義されたように前処理(例えばHTMLページの作成)を行い、その消費者に関して知られている出力装置に出力を送ることができる。

0057

[0072]図4は、サービスとしてのウェアラブルを提供するための環境400の例を示す。環境400は、上記で説明した例示的システム100の例示的実施を含み得る。例えば、モバイルデバイス420は、直接報告センサデバイス112、消費者出力装置130、及び消費者構成デバイス140を実施し、腕時計ウェアラブル430は、間接報告センサデバイス110を実施し、独自仕様の腕時計サーバ440は、報告フレームワーク115及びセンサデバイス110を実施し(サーバ440が追加的なパラメータを抽出することによる)、サービスブローカーフレームワーク450は、サービスブローカーフレームワーク120を実施し、エネルギー消費推定サービスVM460は、サービスアプリケーションデバイス125及びセンサデバイス110を実施し(サーバ440が追加的なパラメータを抽出することによる)、フィットネスコーチングサービスVMは、サービスアプリケーションデバイス125を実施することができる。これらのデバイスは、例えば、LAN、キャリアネットワークデータセンターネットワーク、又はインターネットなどのデータネットワークを介して通信することができる。いくつかの実施形態ではデバイスは、有線接続又は無線接続を介して互いと直接通信することができる(例えば、モバイルデバイス420と腕時計ウェアラブルデバイスはNFC又はBluetooth(登録商標)を介して通信し得る)。

0058

[0073] 本明細書に記載される様々な実施形態は、コンピュータ命令が様々な機能を行うものと説明するが、そのような機能は、実際には、命令を実行し得るマイクロプロセッサ、又は命令なしに機能を行うようにハードワイヤードされたASICなど、ハードウェアによって行われることが明らかであろう。環境400内の様々なデバイスは、図2に関して説明したようなハードウェアにより実施され得る。さらに、以下の実施形態は、カロリー消費推定及びフィットネスコーチングのためのサービスの特定の例を説明するが、本明細書で設計されるシステムは、ウェアラブルデバイスとの関係で実質的にあらゆるタイプのサービスを提供するために使用され得る。

0059

[0074] 図示されるように、モバイルデバイスは、ユーザと他のデバイスとの間の様々なインターフェースを提供するためのウェブブラウザ422又はアプリケーション424を含む。例えば、アプリケーション424は、新しいサービスを契約するために市場VM452へのアクセスを提供し、一方、ウェブブラウザは、フィットネスコーチングサービスVM470のウェブベースのコーチングポータルへのアクセスを提供する。モバイルデバイスはまた、モバイルデバイス426の運動を記録するための加速度計426と、生の加速度計データを使用してユーザの歩数を推定するための内蔵歩数計命令428(サービスブローカーフレームワーク450により、又はそれとの関係で、モバイルデバイスにインストールされている可能性がある)とを含む。生の加速度計データ及び歩数計データは、モバイルデバイスのユーザによって適切に許可された任意のデバイスがオープン方式で入手することができる。そのため、モバイルデバイスは直接報告センサデバイスである。

0060

[0075] ユーザは、ユーザ腕時計ウェアラブルデバイスも所有し、着用しており、これは、追加的な加速度計432、並びに色の変化を検出するためにユーザの皮膚の方に向けられた光学センサ436を含む。歩数計命令434(サービスブローカーフレームワーク450により、又はそれとの関係で、モバイルデバイスにインストールされている可能性がある)は、生の加速度計432データを解釈して、歩数の推定値を出力する。それに代えて、モバイルデバイス420の歩数計命令428は、歩数の改良された推定値を与えるために、両方の加速度計426、432から生のデータを受け取ってもよい(例えばサービスブローカーフレームワーク450によって容易にされる)。心拍数命令438(サービスブローカーフレームワーク450により、又はそれとの関係で、モバイルデバイスにインストールされている可能性がある)は、生の光学データを解釈して心拍数パラメータを抽出する。歩数及び心拍数パラメータ、並びに生の加速度計データは、記憶及びさらなる処理のために独自仕様の腕時計サーバ440に提供される。腕時計ウェアラブル430は、他のデバイスとデータを共有するように構成可能でない場合もあり、そのため、間接報告センサデバイスとみなされ得る。

0061

[0076] 独自仕様の腕時計サーバは、例えば腕時計ウェアラブル430の製造者によって運営される、サーバ、ブレード、又はVMであり得る。腕時計ウェアラブル430からパラメータを受け取ると、それらのパラメータは、時計パラメータストレージ442に記憶され、ユーザが従事する特定の活動を識別するために後に活動識別命令444によって使用され得る。例えば、腕時計加速度計データは、カヤックをしていることからテニスをしていることを区別するための訓練済みモデルと併せて使用される。いくつかの実施形態では、サービスブローカーフレームワーク450は、追加的な入力パラメータ(例えばモバイルデバイス420からの加速度計データ)を独自仕様の腕時計サーバ440に提供することを容易にして、パラメータ抽出アルゴリズム又はデバイス製造者によって供される他のサービスの動作を向上させる、又は活性化することができる。独自仕様の腕時計サーバ440は追加的に、これらのパラメータの一部又はすべてをサービスブローカーフレームワーク450又は他のデバイスに提供するための外部アクセスAPIを備える。

0062

[0077]サービスブローカーフレームワーク450は市場VM452を含み、これは、ウェブブラウザ422又はアプリケーション424が、モバイルデバイス420及び腕時計ウェアラブル430のユーザのためにデータベース454にあるサービス及び提案品を選択、購入、契約、追加するか、又はその他のやり方で構成するためのインターフェースを提供する。その後、サービス容易化VM456は、適切な入力が適切なサーバに提供されるように、様々なアクションを行うことができる。いくつかの実施形態では、フレームワーク450は、1つのみのVMを含む場合も、追加的なVMを含む場合もあることが明らかであろう。

0063

[0078]エネルギー消費推定サービスVM460は、様々な入力から消費カロリー数を推定するパラメータ抽出アルゴリズムを実行するためのエネルギー消費推定命令462を含む。同様に、フィットネスコーチングサービスVM470は、様々な入力データを処理してユーザにコーチングメッセージを提供するためのフィットネスコーチング命令472を含む。

0064

[0079] 図示される例では、エネルギー消費推定サービスVMは、心拍数、歩数計、及び活動のパラメータを使用してエネルギー消費パラメータを推定することができる。これら3つの入力パラメータは、独自仕様の腕時計サーバの外部アクセスAPI446から入手できる可能性があるが、エネルギー消費推定サービスVM460は、API446自体にはアクセスできない可能性がある(例えば、この情報に直接アクセスすることを製造者から許可されない場合があり、又はそのようなアクセスを行うように構成されていない場合がある)。代わりに、サービス容易化VM456は、3つの入力パラメータを受け取り(例えば、API446を介した更新を契約しているため、又は周期的にAPI446をポーリングすることにより)、それらをメッセージにパッケージし、供されるサービスに従った処理のためにそのメッセージをエネルギー消費推定サービスVM460に送る。

0065

[0080] 図の例に従うと、フィットネスコーチングサービスVM470は、モバイルデバイス420からの歩数計データ及び加速度計データと共にエネルギー消費情報を利用して、コーチングサービスを提供することができる。この例では、サービス容易化VM456は、仲介として機能するのではなく、適切な入力の分配を容易にし、これは、フィットネスコーチングサービスVM470にパラメータを送るようにモバイルデバイス420を構成することによってセンサデバイスをフィットネスコーチングサービスVM470にバインドすることによるか、フィットネスコーチングサービスVM470にパラメータを送るようにエネルギー消費推定サービスVM460を構成することによるか、モバイルデバイス420にパラメータを要求するようにフィットネスコーチングサービスVM470を構成することによるか、エネルギー消費推定サービスVM460にパラメータを要求するようにフィットネスコーチングサービスVM470を構成することによるか、又はそれらの何らかの組み合わせによって行われる。その後、フィットネスコーチング命令472は、入力パラメータを処理して、ウェブブラウザ422、アプリケーション424、又は何らかの他のチャネルを介してユーザに伝達される出力(例えばコーチングメッセージ及び進捗チャート)を生成することができる。

0066

[0081] 説明される特定の例の様々な修正が可能であることが明らかであろう。例えば、いくつかの実施形態では、サービス容易化VM456は、サービスデバイスを、当該サービスデバイスと別のセンサデバイスとの間の仲介として機能する1つのセンサデバイスにバインドすることにより、入力パラメータの分配を容易にする。それに代えて、サービス容易化VM456がサービスに関する少なくとも1つの入力タイプのために仲介として機能しなければならないいくつかの実施形態では、サービス容易化VM456は、他の入力タイプについて直接のバインドが可能であり得る場合でも、そのサービスのすべての入力タイプのための仲介として機能することができる。

0067

[0082]図5は、新しいサービスを定義するためのインターフェース500の例を示す。このインターフェース500は、例えばサービス作成命令344によって提供される。インターフェース500は、例えば、サービスの場所と、そのサービスによって必要とされるか又は受理され得る入力のタイプとをサービスブローカーフレームワークに知らせるサービスを提供するためのアプリケーションを、サービス提供者が外部にホストしている場合に有用である可能性がある。サービスが完全にサービスブローカーフレームワークの内部でホストされる実施形態など、様々な他の実施形態では、サービスは、作成されると内部的に一意名前によって識別することができ、入力、出力、及び他のメタデータについての情報は、ホストされているアプリケーションから直接(例えば、ホストされているサービスアプリケーションから送られるコード若しくはAPIメッセージの分析により)、又は何らかの他の方式で集めることができる。いくつかの実施形態では、インターフェース500は、「マッシュアップ」アプリを作成するのに有用である可能性があり、そのアプリの中で、サービス提供者は、2つ以上の既存のサービスを選択し、それらのサービスの結果を単一のビューとして出力するためのフォーマット(例えばHTML又は他のマークアップ)を提供する。そのため、インターフェース500は、再パッケージするために既存のサービスから選択するように修正され得る。そのような実施形態、及び依存サービスが新しいサービス又は新しい提案品としてパッケージされる他の実施形態では、サービスブローカーフレームワークは、依存サービスの価格を含むように提案品の価格を自動的に算出して、各提案品の購入の支払いを、それらの依存サービスごとに該当する当事者に自動的に委ねることができる。

0068

[0083]インターフェース500は、サービスの名前を識別する名前フィールド505と、サービスがどこにホストされるかを識別するサーバアドレスフィールド510と、消費者に提示するサービスの説明文を入力する説明フィールド515とを備える。サービスによって必要とされる、又はその他の形で使用できる入力を定義するために、利用可能入力リスト520では、選択済み入力リスト525に追加する入力のタイプを(例えば、サービスブローカーフレームワークに知られているすべての入力タイプのリストから)選択することができる。図示されるように、リスト525中の選択された各入力は、必須の入力として示され得る。入力タイプを識別するための様々な代替のコントロールが明らかであろう。

0069

[0084] したがって、図示されるように、これらのサービスブローカーフレームワークは、サービス提供者に入力パラメータを提供する特定のセンサデバイスから入力タイプを切り離す。サービス提供者は、入力パラメータの潜在的な供給元を考慮し、列挙するのではなく、入力のタイプを識別するだけでよく、一方で、サービスブローカーフレームワークが、適切なタイプの入力データをサービスに誘導することを容易にする。いくつかの実施形態では、入力タイプが階層に並べられる場合もある。例えば、図示されるように、加速度計の入力タイプはさらに、ポケット収容型の加速度計又は手首用型の加速度計として分類することができる。いくつかのそのような実施形態では、親の入力タイプについての要件が子(又は孫等)の入力タイプによって満足され得る。例えば、図示されるように、定義が行われているサービスは加速度計入力データを必要とし、ポケット収容型の加速度計データ(「加速度計(ポケット)」)が利用可能である場合、この入力データは、その要件を満足することになる。同様に、手首着用型の加速度計データもこの要件を満足し、加えて、手首着用型の加速度計データのための任意選択の入力も満足する(例えば、そのサービスにより適した入力を提供することによってサービスの性能を向上させる)。

0070

[0085]チェックボックス530は、選択済みリスト525にリストされる入力パラメータが、仲介としてのサービスブローカーフレームワークを通じて処理されるべきかどうかを指示する。いくつかの実施形態では、サービスブローカーフレームワークは、チェックボックス530が選択されていない時でも、場合によって仲介として機能することができる。例えば、場合によっては、特定の入力タイプを提供するための特定のユーザのセンサデバイスは、他のデバイスには入力データを提供せず、そのような場合でも、サービスブローカーフレームワークはなお仲介として機能して入力データを取得し、それを該当するサーバに提供することができる。入力前処理スクリプトフィールド535は、収集された入力パラメータを転送する前にアップロードされ実行される1つ又は複数のスクリプトを識別するために使用することができる。入力受信者フィールド540は、収集された入力を転送すべき1つ又は複数のサーバを識別する。例えば、図示されるように、入力は、サービスアプリケーションサーバに転送されるだけでなく、医師サーバにも転送される。いくつかの実施形態では、このフィールド540は、消費者単位で評価を行うためにパラメータ化することができる。例えば、「physician.com」を定義するのではなく、%PhysicianServer%の値が、そのユーザに対して構成された特定の医師(例えばユーザのプロフィールの中で)に対応するサーバに入力パラメータが送信されることを指示するものと解釈され得る。

0071

[0086] 入力と同じようにして、利用可能出力リスト545は、選択して選択済み出力パラメータリスト550に含めるために、出力データタイプのリストを提供する。したがって、サービス提供者が入力パラメータに使用されるのと同じ分類法を介して各自の出力パラメータを定義できるようにすることにより、特定のセンサデバイスからのパラメータの切り離しがさらに容易にされ、それにより、追加的なサービスへの入力として本サービスを使用することを容易にする。チェックボックス555は、サービスの出力がフレームワークを介して消費者出力装置に伝達されるべきかどうかを指示し、伝達すべき場合は、出力前処理スクリプトフィールド560を使用して、出力(例えば出力パラメータ及び他の出力)を消費者出力装置に転送する前にアップロードされ実行される1つ又は複数のスクリプトを識別することができる。例えば、消費者出力装置(例えば、特定のモデル、デバイスタイプ出力能力等による)、又は通信チャネル(例えば、ウェブサイト、APIを介したアプリ、電子メール、テキストメッセージ等)を定義するための入力フィールドなど、様々な追加的な入力項目が明らかであろう。最後に、提出ボタン565で、サービス提供者は、新しいサービスをデータベースに送付することができる(又は、利用可能サービスのデータベースに追加される前の有効性検証を行うため)。

0072

[0087]サービス提供者が新しいサービスの定義と同時に提案品を定義することができる実施形態では、インターフェース500は、例示的な新しい提案品インターフェースとの関連で説明されるフィールドの1つ又は複数など、追加的な入力フィールドを含むことができる。それに代えて、インターフェース500に定義されたフォームの提出に続いて、定義が行われているサービスについての情報があらかじめ格納されている場合もある提案品インターフェース600が提示されてもよい。

0073

[0088]図6は、新しい提案品を定義するためのインターフェース600の例を示す。このインターフェース600は、例えば提案品作成命令334によって提供され、サービス市場で販売するためのサービスを供するためにサービス提供者又は他の提案者によって使用され得る。

0074

[0089] 提案品名フィールド605で、提案者は、提案品の名前を入力することができ、利用可能サービスフィールドが、選択済みサービスリスト615の中に含めると共に提案品の一部として含めるために選択する、1つ又は複数のサービスをリストすることができる。例えば、利用可能サービスフィールド610は、サービスブローカーフレームワークに登録されたすべてのサービス、提案に含めるために「公開」としてリストされたすべてのサービス、又はサービスブローカーフレームワークの中で提案者によって「所有」されているすべてのサービスをリストする。いくつかの実施形態では、他の提案品も「サービス」として含まれることが可能であり、それにより、それら他の提案品に対して以前に定義されたサービス又は支払い情報を現在の提案品に取り込むことができる。選択のために1つ又は複数のサービスを識別するための様々な代替のコントロールが明らかであろう。図示されるように、単一のサービスが選択されており、それは、獲得したデータを保険会社などの別の当事者と共有する、あるバージョンの「エネルギー推定サービス」である。

0075

[0090]支払い先フィールド620、支払い人フィールド625、及び支払いフィールド630は、定義が行われている提案品を受理した際に支払われるべき支払いを定義するために使用することができる。例えば、図示されるように、消費者がその提案品を選択すると、サービスブローカーフレームワーク内で「Insco1」と識別される当事者が、選択されたサービスのサービス提供者に毎月2.99ドルを支払うことになる。理解され得るように、例えば、消費者によるサービス提供者への支払い、又は別の当事者による消費者への支払いなど、図のコントロールを使用して様々な代替の機構が可能である。加えて、1回、週払い、年払い等の他の支払い期間も可能である。

0076

[0091] 同様の又はより複雑な支払い方式を定義するための様々な代替のコントロールのセットが明らかであろう。例えば、代替のコントロールは、複数の支払い先に対して異なる額を定義できるようにしてもよい。いくつかのそのような実施形態では、それらの支払い値又は支払い先の一部は、いくつかのサービスを選択すると自動的に埋められ得る。例えば、異なるサービス提供者によって「所有」されているサービス(又は他の提案品)が含めるために選択されると、そのサービスに対してそのサービス提供者によって以前に識別された望まれる支払いと共に、そのサービス提供者が支払い先として自動的に追加される。同様に、様々な代替実施形態は、複数の支払い人(例えば、第3者がサービス費用の一部のみを支払うことを希望する場合)と、提案品を選択した際に支払われるべきそれぞれの額とを定義できるようにしてもよい。

0077

[0092] 様々な追加的な修正が明らかであろう。例えば、いくつかの実施形態では、いつ消費者に所与の提案品が示されるか、又はその他のやり方で提案品を受理できるかを指示するために、インターフェース600を介して適格性の基準を定義することができる。そのような基準は、特定の保険会社や医師との関連付け、別のサービスへの参加又は契約、特定のデバイスを所有していること等の情報を含み得る。別の代替法として、いくつかの実施形態では、インターフェース600は、ハードウェア又は他の実際の商品購入者に提供することを可能にしてもよい。そのため、ハードウェア、そのハードウェアの能力、履行者、注文が提出されるサーバ等を定義するための入力フィールドも含めることができる。

0078

[0093]図7は、ユーザプロフィール700を定義するためのデータ配置の例を示す。例えば、ユーザプロフィール700は、図3のユーザプロフィール350の一部として記憶され得る。ユーザプロフィール700は単一のレコードとして図示されているが、他の実施形態では、「ユーザプロフィールレコード」は複数のタイプのレコード間に分散されてもよいことが明らかであろう。例えば、第1のレコードがユーザの人口統計学的情報を指定し、第2のレコードのセットがユーザの登録されたセンサを識別し、第3のレコードのセットがユーザの共有構成を記憶する。さらに、ユーザプロフィール700は、抽象化であってもよく、例えば、表、配列、リンクされたリスト、ツリーフラットテキスト等の様々なデータ配置(又はそれらの組み合わせ)として実施されてもよい。

0079

[0094] 図示されるように、ユーザレコードは、ユーザの名前を記憶する名前フィールド710と、提案品の支払いをする際に使用するユーザの支払い機器(例えば、クレジットカードデビットカード銀行口座支払いプロセッサアカウント等)に関する情報を記憶する課金情報フィールド720と、ユーザに対して行われる支払いが行われる先のアカウント(例えば、銀行口座、支払いプロセッサアカウント等)に関する情報を記憶する支払いアカウントフィールド730とを含む。いくつかの実施形態では、ユーザが同じアカウントを使用して支払いと支払いの受理とを行える場合は、課金情報フィールド720と支払いアカウントフィールド730とは組み合わせられてもよい。それに代えて、いくつかの実施形態では、支払いはユーザに対して全く行われないこともあり、そのため、支払いアカウントフィールド730は省略されることもある。

0080

[0095]ユーザプロフィール700は、ユーザに関して登録されているセンサを説明するセンサデバイスレコードセット740も含む。センサデバイスレコードセット740は、登録されたセンサデバイス(例えば、ユーザによって提供された名前、サービスブローカーフレームワークによって生成された識別子、報告フレームワークなどの別のデバイスによって使用される識別子、又は世界的に一意の識別子)を識別する入力IDフィールド742と、センサデバイスから入手可能な入力パラメータを識別する(例えば、サービス提供者がサービスへの入力及び出力を指定するために使用するものと同じパラメータタイプ分類法を使用する)入力タイプフィールド744と、センサデバイスが直接報告センサデバイスであるかそれとも間接報告センサデバイスであるかを識別する間接フィールド746と、センサデバイスからのデータにアクセスするために必要とされる1つ又は複数のトークン(例えば、暗号鍵、パスワード、APIトークン等)を記憶する許可トークンフィールド748とを含む。各センサデバイスに関する追加又は代替の情報がセンサデバイスレコードセット740によって提供されてもよいことが明らかであろう。例えば、そのような情報には、センサデバイスの1つ又は複数のネットワークアドレス、報告フレームワークの1つ又は複数のネットワークアドレス、サービスブローカーフレームワークが他のサービスに対しての仲介(例えば、サービスアプリケーションデバイスと直接報告センサ又は報告フレームワークとの間)として機能しなければならないかどうかの指示、などがある。

0081

[0096] 一例として、第1のレコード752は、「MobilePhone123」という名前のデバイスが、ポケット携行型の歩数計データ及びポケット携行型の加速度計データの2つの入力タイプを提供することが可能であることを示している。この情報は、センサデバイスによって直接報告され、どの許可トークンにも関連付けられない。様々な実施形態において、レコード752は、図4のモバイルデバイス420に対応することができる。

0082

[0097] 第2の例示的レコード754は、「Wristwatch−5D3」という名前のデバイスが、手首着用型の歩数計、手首着用型の加速度計、及び活動データという3つの入力パラメータタイプを提供することを示している。この情報は、定義された許可トークンを使用してこのデバイスに関連付けられた報告フレームワークからのみ、取得することができる。様々な実施形態において、第2のレコード754は、図4の腕時計ウェアラブル430又は独自仕様の腕時計サーバ440に対応することができる。図4の例の状況に関して気付かれるように、このレコード754は、2つの異なるセンサデバイスから入手可能な入力パラメータを識別し、すなわち、腕時計ウェアラブル430は加速度計及び歩数計データを作成し、一方、独自仕様の腕時計サーバ440は活動データを抽出する。しかし、共有の目的で、又はユーザへの提示の目的で、これら2つのセンサデバイスは、単一の「デバイス」レコードにまとめられてもよい。何故ならば、3つのパラメータはすべて報告フレームワークから取得される(間接報告による)か、又は、ユーザが、自身が購入して使用する単一のデバイスを構成するために、製造者によって供される完成したソリューション(デバイス430及び報告フレームワーク440)を検討する可能性があるためである。

0083

[0098] 第3の例示的レコード756は、一部の「センサデバイス」は、ユーザによって携行される追加的な物理的デバイスではなく、ユーザのために構成されたサービスに対応し得ることを示している。例えば、図示されるように、「EEService_User432」という名前の「デバイス」(例えば、「EEService」という名前のサービスによってユーザ「432」に関して報告されるデータを指定する)はユーザにエネルギー消費の推定値を提供し、また、リストされる許可トークンを使用して他のデバイスに直接報告するように構成されることが可能である。様々な実施形態において、このレコード756は、図4のエネルギー消費推定サービスVM460に対応することができる。

0084

[0099]ユーザプロフィール700は、サービスブローカーがユーザの1つ又は複数のサービスのための仲介としてどのように振る舞うかを定義する共有レコードのセット760も含む。そのため、共有レコードのセット760は、共有構成が適用されるサービスを識別するサービスIDフィールド762と、共有される1つ又は複数の入力を識別する入力フィールド764と、入力が共有される先となる1つ又は複数のデバイスを識別する「共有先」フィールド766とを含む。図示されるように、入力フィールド764は、切り離された分類法のみに依拠することによるのではなく、入力データがそこから送信されるべき個々のデバイスを指定することができる。このような機構は、同様の入力パラメータタイプが複数のデバイスから入手可能であり、ユーザ(又は他のデバイス若しくはエンティティ)がサービスに情報を提供するためにそのような供給元を1つだけ選択する際に有益である可能性がある。それに代えて、いくつかの実施形態では、入力フィールド764は特定のデバイスからも切り離されてよく、どのデバイスがその特定の入力を提供するかを決める決定は、他の場所で行われてもよい(例えば、すべてのデバイスからの入力を転送する、新しい入力パラメータを最も頻繁に提供するセンサデバイスから転送する、利用可能なデバイスの中でそのサービスの最良の性能を提供することが知られているセンサデバイスから転送する等)。

0085

[00100] 第1の例として、レコード772は、「EEService」として知られるサービスについては、Wristwatch−5D3デバイスによって取得される3つのパラメータが、それぞれvm1.service.com、physician.com、及びinsco1.comに位置する3つのデバイスに転送されるべきことを示している。いくつかの実施形態では、レコード772は、図4のエネルギー消費推定サービスVM460によって供されるサービスに対応することができる。

0086

[00101] 「EEService」に対して入力前処理スクリプトが定義される(例えばそのサービスのサービスレコードの中で)などのいくつかの実施形態及び事例では、前処理は、転送する前に入力データに行うことができる。さらに、サービス「EEService」が、情報が共有されることになる当事者のパラメータ化された定義を含む実施形態などのいくつかの実施形態では、共有先フィールド766の値は、ユーザプロフィール内の別の場所にある情報に従って埋めることができる。例えば、「physician.com」は、ユーザの医師のサーバを具体的に指し示すのに対し、EEServiceは、単に、入力が%PhysicianServer%と共有されるべきことを定義することができる。したがって、これ(及び他の値)は、同じサービスに対してユーザごとに異なり得る。

0087

[00102] 第2の例示的レコード774は、「フィットネスコーチングサービス」として知られるサービスに関して、MobilePhone123デバイスによって取得される2つのパラメータと、EEService_User432「デバイス」によって取得されるパラメータとの両方が、vm2.coaching.comに位置するデバイスに転送されるべきことを示している。様々な実施形態において、レコード774は、図4のフィットネスコーチングサービスVM470によって供されるサービスに対応することができる。いくつかの代替実施形態では、共有レコードのセット760は、サービスブローカーフレームワークが仲介として機能するレコードのみを含んでもよい。そのため、モバイルデバイス420及びエネルギー消費推定サービスVM460が入力パラメータをフィットネスコーチングサービスVM470に直接送信する図4の例では、このレコード774はいくつかの実施形態では省略されてもよい。代わりに、いくつかのそのような実施形態では、サービスブローカーフレームワークは、単にセンサのバインドを行い、その後は、そのサービスが中断されるまで容易化に関してはそれ以上のアクションを行わず、サービスが中断された時点で、サービスブローカーフレームワークはセンサのバインド解除を容易にすることができる。

0088

[00103]図8は、ユーザについてセンサデバイスを登録する方法800の例を示す。様々な実施形態において、方法800は、サービスブローカーフレームワークによって行われることが可能であり、いくつかの実施形態では、図3のセンサ登録命令312に対応し得る。サービスブローカーフレームワーク内でセンサを登録するための様々な代替の機構及び方法が明らかであろう。

0089

[00104] 方法はステップ810で開始し、サービスブローカーフレームワークがユーザから登録メッセージを受け取る。登録メッセージは、登録が行われているセンサデバイスによって、又はユーザによって操作される別のデバイス(例えば、携帯電話、タブレット、PC、報告フレームワーク等)によって送信される。登録メッセージは、例えば、ユーザがフォームを記入して提出する結果としてか、センサデバイスについての情報を取得及び報告するソフトウェアの動作を通じてか、又はセンサデバイスの動作を通じて(例えば、初回電源投入後の「家への電話(phoning home)」により)送られる。次に、ステップ820で、サービスブローカーフレームワークが、登録メッセージから、広告された入力パラメータタイプと共にデバイスの識別子を読み出す。それに代えて、いくつかの実施形態では、登録メッセージは入力パラメータの広告を含まない場合もあり、代わりに、サービスブローカーフレームワークは、識別されたセンサデバイスのタイプによって提供され知られている入力パラメータタイプをリストしたデータベースを参照することができる。

0090

[00105] ステップ830で、サービスブローカーフレームワークは登録メッセージによって識別されるユーザのユーザプロフィールを取り出し、ステップ840で、サービスブローカーフレームワークは、その新しいデバイスを表す新しいレコードをユーザプロフィールに追加する。この新しいレコードは、識別子及び利用可能な入力タイプなどの情報を含むことができる。そのため、ステップ840で作成されるレコードは、図7のセンサデバイスレコードのセット740のうちのレコードに対応することができる。次に、ステップ850で、サービスブローカーフレームワークが、識別されたセンサデバイスが間接報告デバイスであるかどうかを判定する。ここでも、この情報は、登録メッセージによって伝えられるか、又は登録が行われている特定のデバイスについて知られている情報に基づいてサービスブローカーフレームワークによって相互参照される。間接報告デバイスである場合、サービスブローカーフレームワークは、登録しようとするデバイスの報告フレームワークと通信して860、サービスブローカーフレームワーク又は他のデバイスに入力パラメータを公開する許可を取得する。例えば、サービスブローカーフレームワークは、そのような共有を許すユーザの承認を示すトークン、又はサービスブローカーフレームワークがそのような承認を取得するためにユーザとの別個の通信を開始するのに使用できる識別子を送信する。その後、承認の取得に成功した場合、又はすでに成功している場合、報告フレームワークは、ステップ870で、報告フレームワークの識別子(例えばネットワークアドレス又は他のID)と共に、レコードに記憶されたAPI許可トークンを返す。その後、APIトークンは、報告フレームワークに入力パラメータを要求するために使用することができる。最後に、方法はステップ880で終了する。

0091

[00106]図9は、提案品を閲覧するための例示的インターフェース900を示す。このインターフェース900は、例えば、図3の提案品市場命令314に従って生成され、消費者のデバイスで実行されるウェブブラウザ、アプリ、又は他のクライアントソフトウェアを介して提示され得る。

0092

[00107] 図示されるように、インターフェース902は、閲覧する提案品を見つけるためにユーザが名前や他のキーワードを入力することを可能にする検索バー902及び検索ボタン904を含む。データベース化された提案品の検索を行うための様々なアルゴリズムが明らかであろう。例えば、いくつかの実施形態では、検索ボタン904を押すと実行される検索アルゴリズムは、検索バー902に入力された1つ又は複数の単語が、提案品の名前若しくは説明の中にある、又は提案品に関連付けられたサービスの名前若しくは説明の中にある提案品をいずれも識別することができる。推薦ボタン906は、サービスブローカーフレームワークがユーザの閲覧のために1つ又は複数の提案品を推薦することを要求する。ここでも、そのような推薦を行うための様々なアルゴリズムが明らかであろう。その一例を、図10との関連で下記でより詳細に説明する。例えば、推薦アルゴリズムは、登録されたサービスの動作のために必要とされるセンサデバイスのすべて若しくは大半をユーザがすでに持っている提案品を見つけるか、又は遺伝的アルゴリズム回帰ニューラルネットワークベイジアンネットワーク等の機械学習手法を用いて、ユーザに関する情報に基づいて推薦を行うことができる。

0093

[00108]インターフェース900は、単一のサービスを含む提案品を記述する2つの提案品エントリ910、930を示している。提案品が2つ以上のサービス又は他の品目を含む事例では、提案品の各要素をリストするための様々な代替の機構が明らかであろう。第1の提案品910は、「エネルギー推定サービス」に関連付けられており、星の数による評価付けとして示された2つの評価付け912、914に関連付けられているが、様々な代替の評価付けメカニズムが明らかであろう。具体的には、2つの評価付け912、914は、特定のユーザに合わせてより調節された評価付けから、総合的な評価付けを区別するように示すことができる。理解されるように、様々な要因がサービスの性能に影響する可能性があり、それらには、任意選択の入力パラメータが利用可能であるかどうか、又はユーザのデバイスによって取られた測定値に対する他の同様のデバイスによって取られた測定値の品質などがある。評価付けは、他のユーザによるそのサービスのレビューに基づいて生成されてもよい。例えば、図示されるように、一般的な評価付け914は、そのサービスのユーザが概ねそのサービスを3つ星と評価付けしていることを示し、一方、個別化された評価付け912は、見ているユーザとより類似したユーザはそのサービスを4つ星と評価付けしていることを示す。例えば、4つ星の評価付け912は、すべての任意選択の入力パラメータがそのユーザから入手可能である時の平均の評価付けであり、一方、3つ星の評価付け914は、必須の入力パラメータだけが利用可能である時の平均の評価付けであるか、又は利用可能な入力パラメータに関係なくすべてのユーザ評価付けの平均である可能性がある。

0094

[00109]要件欄916は、エネルギー推定サービスは、加速度計データ及び歩数計データの2つの入力パラメータを必要とすることを示し、それらは両方とも、ユーザのモバイルデバイス又は腕時計ウェアラブルのどちらからでも入手可能であることを示している(又は、それに代えて、インターフェース900は、これらの値がデバイス「MobilePhone123」及び「Wristwatch−5D3」から入手可能であることを示してもよい)。いくつかの実施形態では、市場は、提案品910との関係で利用可能な1つ又は複数のハードウェアアップグレード提案品を識別することができる。例えば、星の数による評価付け912、914が前提とするユーザ評価付けは、異なるタイプの加速度計デバイスを持っているユーザはさらに高い満足度を報告することを示す傾向があり得る。それに応じて、そのタイプの加速度計デバイスが、サービスブローカーフレームワークを介した購入のために利用できる場合は、ハードウェアアップグレードボタン918がその特定の入力の隣に表示されてもよい。ボタン918を押すと、例えば、新しいウィンドウの中に、又はインターフェース900に重なるポップアップの中に、追加的なハードウェア提案品が受理のために表示される。

0095

[00110]オプション入力欄922は、必須ではないものの2つのタイプの入力パラメータがサービスによって使用され得ることを示しており、それらの入力パラメータは、手首着用型の加速度計データ及び活動データであり、これらは両方ともユーザの腕時計ウェアラブルから入手可能である(又は、より正確には、図4の例では報告フレームワークからであるが、ユーザからは隠される可能性がある)。ハードウェアアップグレードボタン918と同様にして、サービスアップグレードボタン924は、入力の1つ又は複数の隣に設けられて、一般にはよりよいサービス性能又はユーザの満足度を伴う、入力パラメータを提供するサービスに関する提案品が利用可能であることを示すことができる。図の例では、サービスブローカーフレームワークは、エネルギー推定サービスの動作(又はユーザの満足度若しくは何らかの他の指標)を向上させる傾向のある「活動」入力パラメータを推定するための別のサービスを見つけている。ボタン918を押すと、追加的なサービス提案品が、例えば、新しいウィンドウの中に、又はインターフェース900に重なったポップアップの中に、受理のために表示される。

0096

[00111] 価格欄926は、その提案品を受理すると(及び関連付けられたエネルギー推定サービスをそのユーザに対して追加する)と、ユーザに対して2.99ドルの毎月発生する料金が生じることを示している。追加ボタン928を選択すると、提案品が直ちに受理され、提案品をショッピングカートに追加するか、又はユーザをその新しいサービスのための精算若しくは構成画面に導くことができる。

0097

[00112] 第2の提案品930は、単一の評価付け932のみに関連付けられている。この理由は、個別化された評価付けがそのユーザには利用することができず、代わりに一般的な評価付けだけが示されているためである可能性がある。そのような個別化された評価付けは、例えば、現在のユーザに類似するユーザからの十分なユーザ入力が入手できない場合、利用可能なセンサデバイスが必要最小限の入力パラメータしか提供しない場合、又は利用可能なセンサ若しくはユーザについての他の情報が平均的なレビューユーザと大きく異ならない場合に、利用できない場合がある。

0098

[00113] 図示されるように、要件欄936は、必須パラメータの1つであるエネルギー消費が、ユーザのデバイスのどれからも入手できないことを示している。そのため、ハードウェアアップグレードボタン918と同様の提案品を指すことが可能なハードウェアアップグレードボタン938に加えて、サービス追加ボタン944が、欠落している入力パラメータを提供することが可能なサービスに関する1つ又は複数の提案品を指すことができる。例えば、サービス追加ボタン944は、欠落している入力パラメータの提供元となる第1の提案品910を指す。別の代替法として、サービスブローカーフレームワークが欠落している入力パラメータを識別しているときには、これら2つのサービスが単一の提案品として動的に共にパッケージされてもよい。欠落している入力パラメータが、そのユーザの利用可能なセンサデバイスに基づいて新しいサービスによって提供されることが可能でない場合、サービス追加ボタン944は、ユーザを新しいハードウェアデバイスを購入するための提案品(及び、可能性としては、新しいハードウェアデバイスと共に使用する追加的なサービス)にリンクする新しいハードウェア注文ボタン(図示せず)に置き換えられてよい。価格フィールド946は、追加ボタン948を介して提案品を受理すると、そのサービスが中止されるまでユーザに毎月9.99ドルが課金され得ることを示している。いくつかの実施形態では、すべての必須の入力が利用可能になるまでユーザが追加ボタン948を選択できないように、又はその他のやり方で提案品930を受理できないようにすることができる。

0099

[00114]図10は、提案品の推薦を生成する方法1000の例を示す。方法1000は、サービスブローカーフレームワークによって行われることが可能であり、提案品市場命令314によって定義することができる。この方法1000は、インターフェース900の推薦ボタン906をユーザが選択するのに応答して提案品のリストを作成するために実行することができる。

0100

[00115] 方法はステップ1005で開始し、ステップ1010に進んで、サービスブローカーフレームワークが現在のユーザのユーザプロフィールを取り出し、次いでステップ1015に進んで、サービスブローカーフレームワークが、ユーザプロフィールの中で識別されるセンサデバイスから入手可能な現在の(又は最近若しくは過去の)パラメータ値を取り出す。

0101

[00116]サービスブローカーフレームワークは次いで、ユーザが特定のサービス、提案品、又はサービス若しくは提案品のクラス(例えば、フィットネス関係の提案品、心臓の健康に関する提案品、ソーシャルサービス等)に関心を持つかどうかを予測するために前もって訓練された、予測モデルのグループを反復し始める。例えば、いくつかの実施形態によれば、これらの予測モデルは、取得される訓練セットに基づいてロジスティック回帰手法に従って訓練されたモデル(その例が図11との関連で下記でより詳細に説明される)を含み、いくつかの実施形態では、提案品を見ること、受理すること、又は評価付けすることなどのユーザアクションに基づいて継続的に更新される。ステップ1020で、サービスブローカーフレームワークは、特定の提案品又は提案品のクラス(又はサービス若しくはサービスのクラス)に関連付けられた予測モデル(例えば、学習済み係数特徴リスト等)を評価のために取り出す。次に、ステップ1025で、サービスブローカーフレームワークは、予測モデルによって使用される特徴であるステップ1010、1015で集められた情報に予測モデルを適用し、モデルから関連性スコアを受け取る。例えば、予測モデルがシグモイド関数として実施される実施形態などのいくつかの実施形態では、関連性スコアは0と1との間の値とすることができ、高い値ほど高い関連度に対応する。ステップ1030で、サービスブローカーフレームワークは、現在のモデルに関連付けられた提案品又はクラスを、順序付けられたリストの関連性スコアに対応する位置に追加する。

0102

[00117] 次にステップ1035で、サービスブローカーフレームワークは、現在の予測モデルが分析すべき最後のモデルであるかどうかを判定する。そうでない場合、方法1000はステップ1020にループバックして、次の予測モデルを評価する。現在の予測モデルが分析すべき最後のモデルであるかどうかを判定する様々な方法が使用されてよい。例えば、サービスブローカーフレームワークは、すべての知られているモデルを反復する、所定数のモデルを評価する(例えば、ステップ1020で各モデルを無作為に選択する)、モデルのサブセットを評価する(例えば、ユーザがすでに特定カテゴリの提案品を現在閲覧中である場合)、又は、閾値を上回る関連性を持つ所定数の提案品若しくはクラスが見つかるまでモデルの評価を継続することができる。したがって、ステップ1020〜1035の連続した反復を通じて、より高い関連性の提案品若しくは提案品のクラス(又はサービス若しくはサービスのクラス)がリストの上位に共にグループ化された、順序付けられたリストが構築されることが見て取れよう。様々な代替実施形態では、本明細書に記載されるリスト構築方法以外の手法が用いられ得ることが認識されよう。

0103

[00118] ステップ1040で、サービスブローカーフレームワークは、順序付けられたリストから最高位の提案品又はクラスを評価のために取り出す。ステップ1045で、サービスブローカーフレームワークは、この提案品又はクラスをそのユーザに対して無視すべきことを示す、以前の指示又は他の構成があるかどうかを判定する。例えば、そのような無視の指示は、ユーザによって手動で設定されて、ユーザがその提案品又はクラスに関心がないことを示すか、その提案品又はクラスが以前にユーザに何回か提示されたことがある場合、ユーザの利用可能なセンサデバイスがその提案品の中のサービスに必要な入力を提供することができない(若しくは、所定数の入力より多い欠落がある)場合、又はユーザがその提案品若しくはクラスの中ですでにそのサービス(若しくはそれと同様のサービス)を有する場合に、システムによって自動的に設定され得る。その提案品又はクラスが無視されるべきでない場合、サービスブローカーフレームワークは、ステップ1050で提示リストにその提案品又はクラスを追加する。提案品クラスを提示リストに追加すべき場合、サービスブローカーフレームワークは、そのクラス内の個々の提案品を提示リストに追加することができる(例えば、そのクラス内のすべての提案品を追加することにより、又は、無作為の選択によるか、関連性を測るために個々の提案品に関連付けられた予測モデルを適用することによるか、若しくは最も評価付けが高い提案品を選択することにより、そのクラス内の個々の提案品のサブセットを選択することによる)。サービスを提示リストに追加すべき場合、サービスブローカーフレームワークは、提示リストに追加するために、そのサービスに関連付けられた1つ又は複数の提案品を検索することができる。サービスクラスを追加すべき場合、サービスブローカーフレームワークは、まずそのサービスクラスの中で1つ又は複数のサービスを選択し(例えば、上記で提案品クラスに関連して説明したものと同様の方法に従って)、その後、選択されたサービスに関連付けられた提案品を見つけることができる。

0104

[00119] ステップ1055で、サービスブローカーフレームワークは、提示リストが現在一杯であるかどうかを判定する。例えば、様々な実施形態において、提示リストは、提案品の数が所定の閾値(例えば、単一の画面に表示できる提案品の数)を満たすか、又は超えるときに一杯であるとみなすことができる。提示リストが一杯でない場合、サービスブローカーフレームワークは、ステップ1060で、順序付けられたリストが空であるかどうかを判定する。空でない場合、方法1000はステップ1040にループバックし、次の品目が評価のために順序付けられたリストから取り出される。提示リストが一杯になるか、又は順序付けられたリストが空になるかのいずれかになると、提示リストにある提案品が、ステップ1065で、例えばインターフェース900と同様のインターフェース上でユーザに提示される。方法1000は次いでステップ1070で終了に進む。

0105

[00120] 図11は、予測モデルを訓練する方法1100の例を示す。方法1100は、その後適用のためにサービスブローカーフレームワークに伝達される予測モデルを訓練するために、サービスブローカーフレームワーク又は別のデバイスによって記憶され実行される命令に対応し得る。例えば、プログラマによって定義されたアルゴリズム、ニューラルネットワーク、ベイジアンネットワーク等、モデル訓練の様々な代替の手法が明らかであろう。

0106

[00121] 方法はステップ1102で開始し、ステップ1104に進んで、デバイスが、モデルを作成しようとする所与のパラメータについてのラベル付けされたデータセットを取得する。ラベル付けされていない訓練セットからモデルを訓練するための様々な手法が明らかであろう。様々な実施形態において、訓練セットは、1つ又は複数の特徴(例えば、ユーザの人口統計学的データ、利用可能なセンサデバイス、取り出されたパラメータ等)と、その特徴セットから導かれるべき適切な結論とを指定する訓練事例のレコードをいくつか含むことができる。様々な実施形態において、訓練セットは、サービスブローカーフレームワークとの様々なユーザの対話中に集められるデータなど、現実世界データ収集活動から作成され得る。例えば、ユーザが提案品(又はそれに関連付けられたサービス)を見る、受理する、又は肯定的に評価付けするたびに、そのユーザの現在の特徴セットが、その提案品がユーザに関連することを示すラベル(例えば、1、又はユーザによって提供された正規化された評価付け)と関連付けて、訓練事例として捕捉される。逆に、ユーザに提案が表示されたもののユーザがその提案を受理しないか、その提案品に対して無視の指示を手動で設定するか、又は提案品を否定的に評価付けするたびに、そのユーザの現在の特徴セットが、その提案品がユーザに関連しないことを示すラベル(例えば、0、又はユーザによって提供された正規化された評価付け)と関連付けて、訓練事例として捕捉される。提案品(又は提案品のクラス)の関連性を予測するための様々な予測モデルに対して訓練セットを構築するための様々な追加的方法が明らかであろう。

0107

[00122] ステップ1106で、デバイスは、データセット中で識別される特徴の数を識別し、ステップ1108で、最終的に得られるモデルで使用される係数のセットを初期化する。様々な実施形態によれば、係数は、定数として機能する1の追加的な係数と共に、特徴ごとに作成される。モデルが数値を出力するように訓練される場合は、線形回帰手法を利用することができ、その場合、最終的なモデル関数は、
h(X)=θ0+θ1x1+θ2x2...
の形態を取ることができ、ここで、Xは、特徴のセット{x1,x2,...}であり、係数{θ0,θ1,θ2,...}は、出力として関連性の推定値を提供するように、訓練データセットから学習された傾向に沿って方法1100によって調整されることになる。いくつかの実施形態では、最終的なモデル関数は、次のようにシグモイド関数を組み込むことができ、



ここで、係数を調整する結果、関数h(X)が0と1との間の値を出力するようになり、この値は、提案品の関連性の推定値として機能する。様々な実施形態によれは、係数はすべてゼロの値に初期化される。いくつかの実施形態では、h(X)(及びそれに関連する係数)に含めるための追加的な特徴が、例えばx12又はx1x2など、訓練セット中の特徴から構築され得ることが明らかであろう。

0108

[00123] 方法は、それぞれステップ1110、1112で2つのループ変数i及びpを0に初期化することにより、係数の訓練を開始する。次いで、ステップ1114で、デバイスは、現在の係数θpにおけるコスト関数偏導関数J(θ)を得、ここで、コスト関数は、いくつかの実施形態では、



と定義することができ、ここで、mは、訓練データセット中の訓練事例の数であり、hθ(x)は、現在の係数のセットθを使用する訓練された関数であり、x(j)は、j番目の訓練事例の特徴のセットであり、y(j)は、j番目の訓練事例に要求される出力(すなわちラベル)である。したがって、バッチ勾配下手法に従うと、係数p(θp)での偏導関数は、



となり得、ここで、xp(j)は、j番目の訓練事例にあるp番目の特徴である(又は、p=0の時、xp(j)=1)。

0109

[00124] ステップ1116で、デバイスはpを増分し、ステップ1118で、デバイスは、pが、h(X)に含まれるべき特徴の総数を現在超えているかどうかを判定することにより、すべての係数が現在のループで検討されたかどうかを判定する。そうでない場合、方法は、ループバックしてステップ1114に戻り、次の偏導関数項を見つける。

0110

[00125] 現在の反復についてすべての偏導関数が見つけられると、方法1100は、続いてステップ1120でループ変数pをゼロにリセットする。次いで、ステップ1122で、デバイスは、ステップ1114で見つかった対応する偏導関数に基づいて、且つあらかじめ設定された学習率に基づいて、p番目の係数θpを更新する。例えば、デバイスは、次の更新規則



を適用することができ、ここで、αは学習率であり、これは例えば、0.1、0.3、1、又は各反復における所望の変更率に合わせて適宜選択された任意の他の値である。

0111

[00126] ステップ1124で、デバイスはpを増分し、ステップ1126で、デバイスは、pが、h(X)に含まれるべき特徴の総数を現在超えているかどうかを判定することにより、すべての係数が現在のループで検討されたかどうかを判定する。そうでない場合、方法はループバックしてステップ1122に戻り、次の係数を更新する。方法1100によれば、すべての偏導関数は、第2のループで係数を実際に修正する前に第1のループ中で見つかり、よって、偏導関数は、部分的に更新された値に基づいて取られることはないことに留意されたい。他の実施形態は、そのような係数の「同時の」更新を実施しない場合もある。

0112

[00127] すべての係数が更新された後、方法はステップ1128に進んで、変数iが増分される。ステップ1130で、デバイスは、方法1100が無期限にループしないことを保証するための事前定義された反復の最大回数を、iが超えているかどうかを判定する。1000、5000、100000回など、十分に大きい反復の最大回数が選択されてよい。最大の反復に達していない場合、方法1100はステップ1132に進んで、デバイスが、訓練セットに基づいて、コスト関数J(θ)を使用して現在のコストを算出する。ステップ1134で、デバイスは、前回の反復から現在の反復までのコストの変化が最小の閾値を満たさないかどうかを判定することにより、関数h(X)が許容可能な解に収束したかどうかを判定する。変化が閾値を上回った場合、方法はステップ1112にループバックして、別の係数更新ループを行う。一方、最大の反復に達しているか、又はコストの変化が最小の閾値を下回る場合、方法1100はステップ1136に進んで、デバイスが、パラメータを抽出するための新しいモデルの一部として係数を記憶し、方法1100はステップ1138で終了に進む。

0113

[00128]回帰以外の手法を採ることに加えて、他の実施形態は、バッチ勾配降下以外の回帰手法で係数を調整するために異なる方法を利用し得ることが明らかであろう。例えば、いくつかの実施形態は、確率的勾配降下を使用することができ、その場合、それぞれの係数更新は、単一の訓練事例に基づいて行われ(それにより偏導関数からの加算をなくし)、方法は、追加的にそのような各例を反復する。他の実施形態では、行列に基づく非反復的手法を使用して、回帰の正規方程式を使用して適切な係数を見つけることができ、係数のセットは、
θ=(XTX)−1XTy
と算出され、ここで、Xは、すべての訓練事例にある特徴の行列であり、yはそれに関連付けられたラベルのベクトルである。

0114

[00129]図12は、サービスの詳細を表示する方法1200の例を示す。方法1200は、サービスブローカーフレームワークによって行われることが可能であり、例えば、提案品市場命令314に対応し得る。方法1200は、表示するサービス(又はサービスを含む提案品)をユーザが選択するのに応答して実行され得る。後に説明されるように、方法1200は、表示されるサービス又は提案品と一緒に提案するための追加的な提案品を見つける。提案がリストの一部として表示される時、例えば、インターフェース900の様々な追加提案品ボタン918、924、938、944を生成するために、同様のステップが取られ得る。

0115

[00130] 方法1200はステップ1205で開始し、サービスブローカーフレームワークが、表示するサービス又は提案品の選択を受け取り、ステップ1210に進んで、サービスブローカーフレームワークが、そのサービスによって(又は選択された提案品に属するサービスによって)使用される入力パラメータを読み出す。ステップ1215で、サービスブローカーフレームワークは、そのユーザのユーザプロフィールを取り出して、そのユーザにどの入力パラメータタイプが利用可能であるかを判定する。ステップ1220で、サービスブローカーフレームワークは、例えば、ステップ1210で得た入力の中にユーザプロフィールにリストされていないものがあるかどうかを判定することにより、そのサービスのための入力がすべてそのユーザに利用可能であることをユーザプロフィールが示すかどうかを判定する。少なくとも1つの入力が欠落している場合、方法1200はステップ1240に進んで、サービスブローカーフレームワークが、現在利用可能な入力パラメータに基づいて、その欠落している入力を提供するであろうサービス(又はサービスの組み合わせ)の検索を試みる

0116

[00131] 追加的なサービスのそのような組み合わせを1つ又は複数識別するための様々な方法が明らかであろう。例えば、いくつかの実施形態によれば、サービスブローカーフレームワークは、リンクされたノードデータ構造(例えばノードグラフ)を構築することができ、その場合、各ノードは入力パラメータのセットであり、根ノードは、現在利用可能な入力パラメータであり、終端ノードは、現在利用可能な入力パラメータに欠落している入力パラメータを足したものであり、すべての他のノードは、それら2つのノードの間の中間の組み合わせとなる。ノード間のツリー上のエッジはそれぞれ、提案品又はサービスの1つに関連付けられ、関連付けられた提案品又はサービスに関して十分な入力を持つ各ノードを始端とし、そのサービスが採用された場合に結果的に生じる入力パラメータセットを記述する各ノードで終端する。そのような各エッジに様々な重みが割り当てられてよく、重みは、例えば、採用される新しいサービスの数を最小化するための定数1、ユーザに対するコストを最小化するための各サービスの価格、サービスの選択を促すための各サービスのレビュー評価付けなどである。データ構造を構築した後(利用可能な提案品から連結グラフを実際に作成できる場合)、ダイクストラのアルゴリズム又はBellman−Fordアルゴリズムなどの最短経路アルゴリズムを適用して、表示されているサービスに必要な入力を提供することになる最もコストが低いエッジのセット(すなわちサービス又は提案品のセット)を見つけることができる。

0117

[00132] ステップ1245で、そのようなサービス又は提案品のセットが存在すると判定された場合、方法1200はステップ1250に進んで、サービスブローカーフレームワークが、見つけられたサービスのセット(又は、そこから選択するためのサービスの複数のセット)と共に、サービスをユーザに表示する。一方、欠落している入力すべてを提供するために利用可能なサービスのセットが見つからない場合、方法1200はステップ1255に進んで、サービスブローカーフレームワークが、欠落している入力パラメータを提供することになる新しいハードウェア提案品のセットを、可能性としては新しいサービス提案品と共に見つける。例えば、いくつかの実施形態では、エッジがハードウェア提案品とサービス提案品との両方によって定義され得る点を除いて、ステップ1255は、上記でステップ1240に関連して説明したものと同様の手法に従うことができる。いくつかの実施形態では、ステップ1240及び1255が単一の検索ステップにまとめられてもよい。例えば、ハードウェア提案品とサービス提案品との両方を持つグラフが1回検索され、いくつかの実施形態ではハードウェア提案品のエッジにコストペナルティを与えて、サービスブローカーフレームワークが、利用可能な場合には、欠落している入力を提供するためのサービスだけのセットを返すことを優先するようにする。欠落している入力を提供するための1つ又は複数のハードウェア提案品(及び可能性としては1つ又は複数のサービス提案品)を識別した後、ステップ1260で、要求されるサービスが、それらの見つかった付加オプションと共に表示される。

0118

[00133] 一方、ステップ1220で、表示されるサービスに関する要件を満たすのに十分なハードウェア及びサービスをユーザがすでに持っていると判定される場合、サービスブローカーフレームワークは、次いでステップ1225で、そのサービスが任意選択の入力パラメータに関連付けられているかどうかを判定し、関連付けられている場合は、ステップ1230で、その任意選択の入力パラメータが、そのサービスの性能又は満足度を向上させるかを判定する(例えば、その任意選択のパラメータを提供するユーザからのユーザ評価付け、レビュー、使用統計等を、その任意選択のパラメータを欠くユーザと比較することによる)。性能を向上させる任意選択のパラメータが実際に存在する場合、方法1200はステップ1235に進んで、その任意選択の入力が、以後のステップために「欠落」とマークされ、方法1200はステップ1240に進む。一方、任意選択のパラメータが存在しないか、任意選択のパラメータがサービスを大幅には向上させない場合、サービスブローカーフレームワークは、ステップ1225で、サービスの推薦は一切せずに、単にサービスを表示する。方法1200は次いでステップ1265で終了に進む。

0119

[00134] 方法1200は一例に過ぎず、選択されたサービスをどのように表示するか、又は補完的な提案品を推薦するオプションをどのように識別するかを決定するための様々な他の方法が用いられ得ることが認識されよう。例えば、いくつかの実施形態では、この方法は、それらが必要ではなく、性能を向上させると予想されない場合でも、少なくとも1つの付加提案品のセットを常に推薦してもよい。別の代替法として、一部の提案品は特徴として分類されてもよく、そのため常に提示されるか、又は表示されるサービス若しくは提案品に十分な関連性がある時はいつでも提示されてもよい。

0120

[00135]図13は、ユーザに対する新しいサービスを追加するためのインターフェース1300の例を示す。インターフェース1300は、消費者のデバイス(例えば、携帯電話、タブレット、PC、又はウェアラブルデバイス)に表示され、市場命令314により生成され得る。様々な実施形態において、インターフェース1300は、サービスに関連付けられた提案品が選択又は購入された後に表示されることが可能であり、サービスの以後の動作を構成するために使用することができる。

0121

[00136] 図示されるように、インターフェース1300もやはり、提案品を閲覧するためにインターフェース900に表示されるもの912、914と同様の個別化された評価付け1305及び一般評価付け1310を含む。図示されるように、ユーザには、どのセンサデバイスが新しいサービスに入力パラメータを提供するかを決定するための複数のオプション1315、1320、1325が提示される。例えば、加速度計の選択1315で、ユーザは、加速度計データを提供するために、自分のモバイルデバイス又は腕時計ウェアラブルのどちらかを選択することができる(又はそれに代えて「MobilePhone123」及び「Wristwatch−5D3」)。サービスブローカーフレームワークは、腕時計ウェアラブルの選択が推薦されることを示す(例えば、それらのデバイスの両方が選択された時のサービスの性能又はユーザからの評価付けを比較することに基づく)。同様に、歩数計の選択1320で、ユーザは、サービスに歩数計データを提供するために、自分のモバイルデバイス、腕時計ウェアラブル、又はその両方を選択することができる。この選択1320は、両方のデバイスの選択を可能にするために、ラジオボタンに代えてチェックボックスの形態であってもよい。これは、例えば、サービスが複数の歩数計の供給元を利用するように適合されているが、一度に1つの供給元からしか加速度計データを受理しないときに望ましい可能性がある。歩数計入力パラメータが必要とされる場合、インターフェース1300は、選択1320においてチェックボックスを両方とも非選択にすることを許さないようにしてもよい。活動の選択1325で、ユーザは、活動パラメータ(当該サービスには任意選択の入力パラメータ)が腕時計ウェアラブルデバイスから共有されるべきかどうかを指示することができる。

0122

[00137]サービスアップグレードボタン1330は、一旦構成されるとサービスの性能を向上させるであろう活動パラメータを推定するサービスを提示し得る点で、インターフェース900のアップグレードボタン918、924、938、944と同様であり得る。様々な実施形態において、そのような他のサービスの追加と選択要素1315、1320、1325の修正とにより、見込まれる入力が変更されるため、個別化された評価付け1305をアップグレードすることができる(例えば、個別化された評価付け1305に関してそれらのレビューを考慮するように、異なる「類似ユーザ」グループを選択することによる)。データ共有ボックス1335は、1つ又は複数の任意選択の第3者とデータを共有すべきことを指示するために選択可能とすることができる。場合によっては、ボックス1335を選択する結果、消費者がデータを共有することに同意する見返りに、消費者に対して割り引き又は支払いが行われることがある。確定ボタン1340は選択を送付し、適宜、且つサービスブローカーフレームワークがそのサービスに関して仲介として動作することになるかどうかに基づいて、サービスへのセンサのバインド又は共有構成の保存を行わせることができる。

0123

[00138]図14は、提案品の購入を遂行する方法1400の例を示す。方法1300は、サービスブローカーフレームワークによって行われることが可能であり、例えば提案品市場命令314に対応し得る。方法1300は、購入のためにサービス(又はサービスを含む提案品)をユーザが選択するのに応答して実行され得る。例えば、いくつかの実施形態では、方法1400は、インターフェース1300の確定ボタン1340をユーザが選択するのに応答して実行される。

0124

[00139] 方法1400は、ステップ1405で開始し、ステップ1410に進んで、サービスブローカーフレームワークが、その提案品が繰り返し発生する課金を必要とするか、それとも1回限りの購入を必要とするかを判定する。繰り返し発生する課金が生じることになる場合、方法1400はステップ1410に進んで、サービスブローカーフレームワークが、ユーザ、課金額、及び課金期間を識別する契約レコードを作成し、初回の支払いを処理すべきことを課金エンジンに通知する。そうでない場合、サービスブローカーフレームワークは、ステップ1420で、単に課金エンジンによる処理のために請求書を提出する。

0125

[00140] ステップ1425で、サービスブローカーフレームワークは、新しいサービスへの入力が、仲介としてのサービスブローカーフレームワークを通じて処理されるべきかどうかを判定する。例えば、サービスブローカーフレームワークは、選択されたデバイス(又はそれらの報告フレームワーク)のいずれかが、サービスアプリケーションデバイスに直接入力を提供するように構成可能であるかどうか、又は当該サービスがそのような仲介機能に対応して構成されているかどうかを判定する。そうである場合、サービスブローカーフレームワークは、ステップ1430でユーザプロフィールの中に新しい共有レコードを作成する。そのような共有レコードは、例えば、共有レコードのセット760に対応し得る。一方、サービスブローカーフレームワークが仲介として機能しない場合、サービスブローカーフレームワークは、続いて1435で、入力パラメータの必要とされる転送を遂行するようにセンサデバイス又はサービスアプリケーションデバイスを構成することによってセンサのバインドを容易にする。

0126

[00141] ステップ1440で、サービスブローカーフレームワークは、新しいサービスが、他のサービスへの入力パラメータの役割を果たし得る出力パラメータを提供するかどうかを判定する。例えば、この情報は、インターフェース500を介してサービス提供者によって指定されているか、又はサービスブローカーフレームワークのAPIを介してサービスアプリケーションデバイスによって広告される可能性がある。提供する場合、サービスブローカーフレームワークは、そのサービスを、新しい入力パラメータの提供元となる新しいセンサデバイスとしてユーザプロフィールに追加する。例えば、サービスブローカーフレームワークは、センサデバイスレコード740に新しいレコードを追加する。方法1400は次いでステップ1400で終了に進む。

0127

[00142]図15は、入力の共有を容易にする方法1500の例を示す。方法1500は、センサデータ転送命令394によって行われ得る。方法1500はステップ1505で開始し、サービスブローカーフレームワークが、ユーザの1つ又は複数のセンサデバイスから入力パラメータを受け取る。ステップ1510で、サービスブローカーフレームワークが、受け取られた入力パラメータに適用される、ユーザの共有許諾のセット(例えば、ユーザプロフィール700にある共有構成760の1つ)を取り出す。次いで、ステップ1515で、サービスブローカーフレームワークは、現在の共有許諾レコードについてのサービス定義を取り出す。ステップ1520で、サービスブローカーフレームワークは、そのサービスレコードが、入力前処理スクリプトを識別するかどうかを判定し、識別する場合は、ステップ1525でそのスクリプトを実行する。次いで、サービスブローカーフレームワークは、ステップ1530で、共有許諾レコード中で識別されたサーバに入力を送信する。ステップ1535で、サービスブローカーフレームワークは、その入力に対して評価すべき追加的なサービス許諾レコードが残っているかどうかを判定する。残っている場合、方法1500はステップ1515にループバックする。すべての共有許諾レコードが処理されると、方法はステップ1540で終了に進む。

0128

[00143]図16は、出力の提示を容易にする方法1600の例を示す。方法1600は、サービス提示命令396によって行われ得る。方法1600は、ステップ1605で開始し、サービスブローカーフレームワークがサービスアプリケーションデバイスからデータを受け取る。サービスブローカーフレームワークは次いで、ステップ1610で、そのサービスのサービスレコードを取り出し、ステップ1615で、そのサービスが出力処理スクリプトを定義しているかどうかを判定する。定義している場合、サービスブローカーフレームワークは、ステップ1620でそのスクリプトを実行する。サービスブローカーフレームワークは次いで、ステップ1625で、消費者出力装置に出力を送り、ステップ1630で、パラメータを処理し、新しい入力パラメータとして出力する。例えば、サービスブローカーフレームワークは、入力処理方法1500を呼び出して、これらの新しく受け取ったパラメータを処理することができる。方法1600は次いでステップ1635で終了に進むことができる。

0129

[00144] 前述の説明から、本発明の様々な例示的実施形態は、ハードウェア又はファームウェアとして実施可能であることが明らかになるはずである。さらに、様々な例示的実施形態が、機械可読記憶媒体に記憶された命令として実施されることが可能であり、その命令が少なくとも1つのプロセッサによって読み出され、実行されて、本明細書に詳細に記載される動作を行う。機械可読記憶媒体は、パーソナルコンピュータ若しくはラップトップコンピュータ、サーバ、又は他のコンピューティングデバイスなどの機械によって可読の形態で情報を記憶するための任意の機構を含み得る。したがって、機械可読記憶媒体は、読出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、及び同様の記憶媒体を含み得る。

0130

[00145] 当業者には、本明細書中ブロック図は、本発明の原理を具現化する例示的回路概念図を表していることが認識されるはずである。同様に、フローチャート、流れ図、状態遷移図、疑似コード等は、実質的に機械可読媒体として表され、したがってそのコンピュータ又はプロセッサが明示的に図示されているか否かに関わらずコンピュータ又はプロセッサによって実行され得る、様々なプロセスを表していることが認識されよう。

0131

[00146] 様々な例示的実施形態についてその特定の例示的態様を特に参照して詳細に説明したが、本発明には他の実施形態が可能であり、その詳細には様々な明白な点で修正が可能であることを理解すべきである。当業者には容易に明らかであるように、変形例及び修正は、本発明の主旨及び範囲内に留まりながら遂行することができる。したがって、前述の開示、説明、及び図は、例示のみを目的とし、特許請求の範囲のみによって定められる本発明を何ら制限するものではない。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ