本発明の実施形態は、一般的に、システム内の複数のエンティティ間の分散状態を同期することに関係する。システム内のエンティティは、典型的には、リモートサーバーと通信する少なくとも1つの監視デバイスを備え、例示的な実施形態における監視デバイスは、スマートホーム環境内の、サーモスタット、ハザード検出ユニット、環境センサー、環境コントローラ、セキュリティ関係のセンサー、セキュリティ関係のコントローラ、照明センサー/コントローラ、スマートアプライアンス、アプライアンスセンサー/コントローラ、娯楽関係のデバイス、通信関係のデバイス、害虫検出器、侵入検出器、ドア破損センサーおよび窓破損センサーなどの、インテリジェント型マルチセンサーネットワーク接続デバイスである。説明を簡潔にし明確にするために、「監視デバイス」という用語は、本明細書における1つまたは複数の例においてリモートサーバーと通信するデバイスとして使用され得るが、そのような用語は、「制御(する)」機能が実質的にすべてのスマートホームデバイスに対する少なくとも1つの「監視」態様を必ず含むので、本明細書において識別されているものを含む、さまざまなスマートホーム関係の制御機能のうちのどれかを実行することができるさまざまな制御デバイスのうちのどれかを含むものとして理解されることは明らかであろう。したがって、本明細書で使用されているような「監視デバイス」という用語は、サーモスタット、例えば、監視機能(周囲温度、湿度、および/または制御すべき他の環境条件を感知する)が必須コンポーネントである制御機能(HVACシステムのオペレーションを制御する)を有するサーモスタットを包含するものとして理解されるべきである。リモートサーバーは監視デバイスから離れた場所にあり、情報状態を監視デバイスと同一の情報状態に維持する。多くの実施形態において、システムは、リモートサーバーと通信する少なくとも1つのアクセスデバイスも備え、アクセスデバイスは、ラップトップコンピュータ、携帯電話、タブレットコンピュータ、またはスマートフォンなどであってよく、これは監視デバイスの作動状態を見る、制御する、および/または他の何らかの形で影響を及ぼすために使用される。
システムのいくつかのエンティティにまたがる状態の同期化を円滑にするために、サブスクリプションベースの通知メカニズムが使用され得る。本明細書で説明されているサブスクリプションベースの通知メカニズムにおいて、いくつかのエンティティにまたがって同期される共通情報のインスタンス(本明細書では情報の「バケット」と称される)は、それらのエンティティのそれぞれに格納される。リモートサーバーは、システムのすべてのユーザーについて接続されているすべてのデバイスに対してバケットを維持し、デバイスは、それらおよび/または共通構造内の他のデバイス(例えば、単一のスマートホーム環境内のデバイス)または他の何らかの形で共通制御スキームの影響を受ける他のデバイス(例えば、同じコンシューマもしくはコンシューマアカウントに関連付けられているデバイス)に関連しているバケットのみを維持する。リモートサーバー側のバケットの状態との同期を維持するために、監視デバイスおよび/またはアクセスデバイス(より一般的にクライアントデバイスと称されることが多い)は、サブスクリプション要求をリモートサーバーにサブミットし、このサブスクリプション要求は、リモートサーバー側でバケットになされた変更をクライアントデバイスに通知するようにするリモートサーバーに対する要求である。監視デバイスを備え、関連付けられているアクセスデバイスを有する構造について、変更は、例えば、アクセスデバイスによって開始されるものとしてよく、これにより、リモートサーバーは、その保留中のサブスクリプション要求を使って変更を監視デバイスに通知する。これらの変更は、代替的に、例えば、監視デバイスによって開始されるものとしてよく、これにより、リモートサーバーは、その保留中のサブスクリプション要求を使って変更をアクセスデバイスに通知する。
本発明の実施形態は、一般的に、いくつかのデバイスおよびいくつかのリモートサーバーの間の通信を円滑にするための多層認証技術にも関係する。これらのエンティティは、典型的には、リモートサーバーと通信するクライアントデバイス(例えば、監視デバイス、アクセスデバイスなど)を含み、例示的な実施形態におけるクライアントデバイスは、スマートホーム環境内の、サーモスタット、ハザード検出ユニット、環境センサー、環境コントローラ、セキュリティ関係のセンサー、セキュリティ関係のコントローラ、照明センサー/コントローラ、スマートアプライアンス、アプライアンスセンサー/コントローラ、娯楽関係のデバイス、通信関係のデバイス、害虫検出器、侵入検出器、ドア破損センサーおよび窓破損センサーなどの、インテリジェント型マルチセンサーネットワーク接続デバイスである。リモートサーバーは、クライアントデバイスから離れた場所にあり、情報(例えば、セキュリティ対策が施されているリソース)を格納し、かつ/またはクライアントデバイスが取得またはインタラクティブな操作を望むことができるサービスを提供する。リモートサーバーは、クライアントデバイスの認証のレベルに基づきクライアントデバイスへのアクセスを提供するか、または拒絶することができる。
認証のレベルを参照するときに、クライアントデバイスは異なるデバイス資格証明書または他の特性/関係を使用してその同一性を認証することができる。提示されているデバイス資格証明書および/または他の特性/関係に基づき、リモートサーバーは、クライアントデバイスへのアクセスのレベルを増減することができる。いくつかのデバイス資格証明書(例えば、「既定の資格証明書」)では、クライアントデバイスがリモートサーバーからのデータおよび/または機能の限定されたセットへのアクセスを許され得る。他のデバイス資格証明書(例えば、「割り当てられた資格証明書」)では、クライアントデバイスがリモートサーバーからのデータおよび/または機能のより大きなセットへのアクセスを許され得る。それに加えて、何らかの関係が満たされている(例えば、クライアントデバイスが特定のユーザーアカウントとペアリングされている)場合、割り当てられている資格証明書の提示により、クライアントデバイスは、リモートサーバーからのデータおよび/または機能のなおいっそう大きなセットに対しても許容されるものとしてよく、それはユーザーアカウントに固有の情報(例えば、機密ユーザー情報)である。
本特許明細書の主題は、同一出願人による出願の主題に関係し、これらの出願のそれぞれは、参照により本明細書に組み込まれる、2011年10月17日に出願された米国特許第13/275,307号、2011年10月17日に出願された米国特許第13/275,311号、2012年3月22日に出願された国際出願第PCT/US12/30084号、および2012年5月8日に出願された米国特許第13/466,815号である。上記の特許出願は、本明細書では「同一出願人による組み込まれている出願」と総称される。
通信プロトコルを実施するためのシステム
1つまたは複数の実施形態によるサブスクリプションベースの同期のさまざまな態様および実施が、本明細書において開示される。図を参照すると、図1は一実施形態によるシステム上に分散されたデバイスの状態を同期するためのサブスクリプション通知メカニズムを実装するシステム100を示している。システム100は、ネットワーク106を介して1つまたは複数のクライアントデバイス104から離れた場所にあり、また通信可能に結合されているリモートサーバー102を備える。クライアントデバイス104は、さまざまな電子デバイスを含み得る。一実施形態において、クライアントデバイス104は、1つまたは複数の監視デバイス108を含み得るが、他の実施形態では、クライアントデバイス108は、1つまたは複数のアクセスデバイス110を含み得る。
監視デバイス108は、システム100上で共有されるべき基本データを生成するように動作可能な電子デバイスである。一実施形態において、監視デバイス108は、その環境の1つまたは複数の態様を監視し、監視データを基本データとして使用することによってそのような基本データを生成することができる。例えば、監視デバイス108が、インテリジェント型サーモスタットである場合、監視デバイスは、温度、湿度、占有などの環境特性を感知するセンサーを含むものとしてよい。したがって、そのようなデータは、監視デバイス108によって生成され、リモートサーバー102に伝達され得る。監視デバイス108で変化が生じた場合、例えば、環境変化が感知された場合、それらの変化も、同様に、リモートサーバー102に伝達され得る。
その環境の態様を監視することによってデータを生成することに加えて、データは、ユーザーが監視デバイス108をインタラクティブに操作することによっても生成され得る。例えば、監視デバイス108がインテリジェント型サーモスタットである場合、ユーザーは、監視デバイス108を介して所望の温度(すなわち、「設定点温度」またはより単純に「設定点」)を定義することができ、監視デバイス108は、その後、電気的に結合されたHVACシステムを制御して、所望の温度を達成し、かつ/または維持することができる。または、そこでプログラムされたアルゴリズムを介して、監視デバイス108自体が、設定点を生成することができる。設定点およびそれに対する変更は、設定点がどのように生成されるかまたは変更されるかに関係なく、同様に、リモートサーバー102に伝達され得る。
逆に、リモートサーバー102は、監視デバイス108に関連付けられているデータの1つまたは複数のフィールドを変更することができる。例えば、リモートサーバー102において、監視デバイス108側に格納されている設定点を変更したい場合がある。そのような場合、リモートサーバー102は、監視デバイス108の設定点の自バージョンを変更し、その変更を監視デバイス108に伝達することができる。こうして、監視デバイス108で行われたデータへの変更がリモートサーバー102側に反映されることに加えて、リモートサーバー102側で行われたデータへの変更は、監視デバイス108側に反映される。
いくつかの実施形態では、アクセスデバイス110も備えることができ、アクセスデバイス110は、監視デバイス108からのデータにアクセスし、監視デバイス108側のデータを変更するように動作可能である。監視デバイス108からのデータにアクセスするために、アクセスデバイス110は、リモートサーバー102からそのようなデータのコピーを取得することができる。監視デバイス108側の情報の状態およびリモートサーバー102側の情報の状態は、一般的に同一であるため、リモートサーバー102からデータを取得することによって、アクセスデバイス110側の情報の状態は、一般的に、監視デバイス108側の情報の状態と同一になる。さらに、監視デバイス108のデータ(例えば、設定点)を変更するために、ユーザーは、アクセスデバイス110側で変更を行うことができ、この変更は、リモートサーバー102を介して監視デバイス108に伝搬される。
理解されるように、リモートサーバー102は、情報の状態を監視デバイス108側で提供されるものと同一の情報の状態に維持するように動作し、いくつかの場合において、情報のその状態を監視デバイス108に関して変更し、そのような変更を監視デバイス108に伝え、リモートサーバー102の状態および監視デバイス108の状態を同期させることができる。アクセスデバイス110が備えられている実施形態では、リモートサーバー102も同様に、監視デバイス108およびアクセスデバイス110の両方において情報の同一の状態を維持して監視デバイス108およびアクセスデバイス110の状態を同期させるように動作する。
少なくとも1つの実施形態において、複数の監視デバイス108が備えられ得る。そのような場合において、それぞれの監視デバイス108は、それ独自の基本情報を生成し、リモートサーバー102および1つまたは複数のアクセスデバイス110と同期させ得るが、それぞれの監視デバイス108は、その情報のサブセットを選択された他の監視デバイス108と共有することもできる。例えば、監視デバイス108がインテリジェント型サーモスタットである場合、これらは、占有データを互いに共有することができるが、温度データを共有することはできない。したがって、複数の監視デバイス108における情報のサブセットの状態は、互いに同期させることができる。
ネットワーク106は、クライアントデバイス104とリモートサーバー102との間などの、さまざまなエンティティの間の通信を可能にするのに適しているネットワークである。このようなネットワークとして、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、ワイヤレスネットワーク、ワイヤレスデータネットワーク、セルラーネットワーク、もしくは任意の他のそのようなネットワーク、またはこれらの組み合わせが挙げられる。ネットワークは、さらに、好適なネットワークトポロジーを組み込むことができる。ネットワーク106は、好適なプロトコルを利用することができ、ネットワーク106上の通信は、有線接続またはワイヤレス接続、およびこれらの組み合わせによって使用可能になる。
図1を参照しつつ説明されている特定の例において、監視デバイス108およびアクセスデバイス110は、共通のユーザーに関連付けられ得ることは理解されるであろう(例えば、これらはそれぞれ、本明細書でさらに説明されているように、特定のユーザーアカウントに「ペアリング」することができる)。ペアリング(および続いて説明されているサブスクリプションプロセス)の結果として、監視デバイス108およびアクセスデバイス110の状態が同期され得る。すなわち、特定のユーザーアカウントにペアリングされている監視デバイス108およびアクセスデバイス110は、情報の1つまたは複数のバケットに、これらの情報のバケットに加えられた変更がいずれかのデバイスによって他のデバイスに伝搬されるようにサブスクライブすることができる。しかし、ペアリングされたデバイス(例えば、監視デバイス108およびアクセスデバイス110)は、システム100に含まれ得るすべてのクライアントデバイスのサブセットにすぎないことは理解されるであろう。すなわち、システム100は、異なるアカウントにペアリングされている多数の監視デバイス108、および同じまたは異なるアカウントにペアリングされている多数のアクセスデバイス110を含むことができる。したがって、同期は、互いに関連付けられている(例えば、共通のユーザーアカウントに「ペアリング」されている)クライアントデバイス間で典型的には実行されるが、互いに関連付けられていないクライアントデバイス間では実行されない。
いくつかの実施形態におけるシステム100は、1つまたは複数のコンピュータネットワークまたは直接接続を使用して、通信リンクを介して相互接続されている複数のコンピュータシステムおよびコンポーネントを利用する分散コンピューティング環境である。しかし、当業者であれば、そのようなシステムは、図1に示されているものよりも少ない、または多い数のコンポーネントを有するシステムであっても等しく適切に動作できることを理解するであろう。したがって、図1のシステム100の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を制限するものとしてみなされるべきでない。
図2は、一実施形態によるそのシステムのエンティティのそれぞれにおいて提供される情報のバケットを伴う図1のシステムを示す。システム100のエンティティは、データを「バケット」の形態で格納し、それぞれのバケットは、複数のフィールド-値ペアを含む。フィールドは、監視デバイス108および/またはその環境のさまざまな特性に合わせて定義され得る。値は、それぞれのフィールドに関連付けられる。インテリジェント型サーモスタットでは、例示的なフィールド-値ペアは以下のものとしてよい。
"hvac_heater_state" : 0
文字列「hvac_heater_state」は、HVACヒーターの状態を指すフィールドであり、数「0」は、HVACヒーターの状態(例えば、オフ)を指す値である。例示的なバケットは以下のとおりである。
Bucket Name: structure.<id>
{
"devices": [device.<id>, device <id>]
"name": "My Living Room Thermostat",
"away": false,
" display_location": "Palo Alto,CA/n"
}
この例のバケットは、「構造」と称され、監視デバイス108が配置されている構造(例えば、家)に関連付けられているフィールド-値ペアを含む。図2を参照すると、「構造」バケットは、監視デバイス108側で最初に定義された値を含むバケット「B1」108Aであるものとしてよい。それぞれのバケットは、バージョン識別子および/またはタイムスタンプを備えることができる。バージョン識別子は、バケットのバージョンを一意に識別するが、タイムスタンプは、バケット(またはその中の値)がサーバー102によって受信または生成された時間を識別する。したがって、図2をもう一度参照すると、バケット「B1」は、サーバー102から受信される一意的なバージョン「v1」およびタイムスタンプ「t1」に関連付けられ得る。
監視デバイス108は、複数のバケット「B1」108Aから「BN」108Nを有することができ、それぞれのバケットは、フィールド-値ペアの自セットを含む。リモートサーバーは、それぞれ監視デバイス108のバケットに対応する複数のバケット「B1」102Aから「BN」102Nも有する。定常状態にあるときに、リモートサーバー102側のバケットおよび監視デバイス108側の対応するバケットの内容は同一である。バージョン識別子および/またはタイムスタンプが使用される実施形態では、リモートサーバー102側のバケットおよび監視デバイス108側の対応するバケットのバージョン識別子および/またはタイムスタンプも同様に同一となる。
説明されているように、いくつかの実施形態では、システム100は、1つまたは複数のアクセスデバイス110を含む。アクセスデバイス110は、それぞれ監視デバイス108のバケットに対応するバケット「B1」110Aから「BN」110Nも同様に含む。定常状態にあるときに、アクセスデバイス110側のバケットならびにリモートサーバー102および監視デバイス108のそれぞれの側の対応するバケットの内容は同一となる。バージョン識別子および/またはタイムスタンプが使用される実施形態では、アクセスデバイス110側のバケットのバージョン識別子および/またはタイムスタンプも同様に、リモートサーバー102および監視デバイス108のものと同一となる。
少なくとも1つの実施形態において、同じ構造またはユーザーアカウントに関連付けられている複数の監視デバイス108がすべて実現され得る。それぞれの監視デバイス108は、リモートサーバー102と、またいくつかの場合において、アクセスデバイス110と同期するバケットB1からBN(Nは複数のデバイス108において同じであるかまたは異なっていてもよい)の一意的なセットを含む。さらに、監視デバイス108の一部または全部が、共有されるバケット「BS」108Sを含むこともできる。共有されるバケットBSは、他のバケットに似ているが、さらに、同じ構造またはユーザーアカウントに関連付けられている複数の監視デバイス108の間で共有されるか、または他の何らかの形で同期され得る。このような共有を円滑にするために、リモートサーバー102は、それぞれの監視デバイス108に対して共有されるバケット「BS」102Sも含み得る。1つの監視デバイス108が、その共有されているバケット「BS」に変更を加えた場合、リモートサーバー102は、それらの変更を他の監視デバイス108に伝搬し得る。この様式で、監視デバイス108は、事実上互いに通信することができる。
アクセスデバイス110は、共有されるバケット「BS」110Sも含むことができる。少なくとも1つの実施形態において、アクセスデバイス110は、すべての監視デバイス108の共有されるバケット「BS」を含む。この様式で、アクセスデバイス110は、複数の監視デバイス108にまたがって共有される情報のバケットにアクセスするように動作可能であるものとしてよい。共有されるバケットのさらなる詳細および例は、2011年10月21日に出願された米国仮出願第61/627,996号において説明されている。このような一例として、いわゆるアウェイ状態フラグ(away-state flags)があり、それぞれ家庭内の明確に区別できる占有感知デバイス(occupancy-sensing device)に対応し、それぞれ所定の時間間隔の間に占有を検出しなかった場合に対応するデバイスによって「アウェイレディ(away ready)」状態に設定され、これらのフラグのすべてが「アウェイレディ」に設定されるまで、どのデバイスも実際のアウェイ状態(低エネルギー使用状態)に入らない。占有感知サーモスタットの事例では、これは、デバイスのすべてが必要条件である非占有条件を「確認する」までどのサーモスタットも快適度の低い低エネルギー使用状態に入らないことを確実にし、それにより、家庭が真に無人状態にある高い確率を定める。
図3は、一実施形態によるリモートサーバー102のいくつかの簡素化されたコンポーネントを含む図1のシステムを示している。類似の番号が振られているエンティティは、すでに説明されているものと同一であり、したがって、さらなる説明は、省く。リモートサーバー102は、登録サーバー112、複数の同期化サーバー114Aから114M、ロギングサーバー116、およびストレージ要素118を含む。登録サーバー112、同期化サーバー114Aから114M、およびロギングサーバー116は、ネットワーク106を介してクライアントデバイス104に通信可能に結合される。同期化サーバー114Aから114Mも、登録サーバー112およびストレージ要素118に通信可能に結合される。
本明細書においてさらにより詳しく説明されているように、ストレージ要素118は、システム100のすべてのユーザーについてバケット102Aから102Nおよび102Sなどのさまざまな情報を格納することができる。例えば、図2を参照すると、システム100のそれぞれのユーザーについて、ストレージ要素118は、バケット102Aから102Nおよび共有されているバケット102Sのすべてを格納することができる。次いで、登録サーバー112および同期化サーバー114Aから114Mは、ストレージ要素118内のバケットの状態が、関連付けられているクライアントデバイス104内のバケットの状態と同一であることを確実にするように動作することができる。ストレージ要素118は、これに加えて、または代替的に、認証関係の情報を格納することができる。例えば、ストレージ要素118は、割り当てられた資格証明書、既定の資格証明書などを格納することができる。
いくつかの実施形態では、本明細書でさらに説明されているように、登録サーバー112は、クライアントデバイス104に対する第1のコンタクトポイントとして働く。例えば、監視デバイス108は、初期化または再接続後、監視デバイス108が登録サーバー112に常にコンタクトすることができるように中にハードコーディングされた登録サーバー112のロケーション識別子(例えば、URL)を有するものとしてよい。とりわけ、登録サーバー112は、クライアントデバイス104側のバケットをストレージ要素118側のバケットと同期させる役割を有する同期化サーバー114Aから114Mのうちの1つを識別し、選択された同期化サーバーの同一性をクライアントデバイス104に伝えることができる。次いで、クライアントデバイスは、クライアントデバイス104の状態を互いに(例えば、クライアントデバイス104が同じユーザーアカウントにペアリングされるなど互いに関連付けられている場合)、またストレージ要素118とその後同期する選択された同期化サーバーに接続することができる。
いくつかの実施形態におけるシステム100は、さまざまなコンポーネントを含むリモートサーバー102を含む分散コンピューティング環境である。しかし、当業者であれば、そのようなリモートサーバーは、図3に示されているものよりも少ない、または多い数のコンポーネントと共に等しく適切に動作できることを理解するであろう。したがって、図3のシステム100の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を制限するものとしてみなされるべきでない。
図4は、一実施形態によるクライアントデバイス104のコンポーネントを示す簡素化されたブロック図である。クライアントデバイス104は、セキュリティモジュール120、認証モジュール122、調整モジュール124、セッション識別生成器126、およびストレージ要素128を含む、多数の異なる機能モジュールを含む。ストレージ要素128は、登録サーバーロケーション128A、デバイス識別子128B、現在のソフトウェアバージョン128C、情報の1つまたは複数のバケット128D、既定の資格証明書128E、およびいくつかの時点における、割り当てられた資格証明書128Fなどの、さまざまな情報を含み得る。
セキュリティモジュール120は、クライアントデバイスと、登録サーバー112および/または同期化サーバー114などのシステム100の他の要素との間のセキュア(例えば、暗号法により暗号化されている)通信を行うように動作可能である。そのようなセキュア通信を円滑にするために、セキュリティモジュール120は、対称暗号化、非対称暗号化、キー合意および/または確立、ハッシュ化、および署名などの、1つまたは複数のセキュリティ関係の機能を実行するためのコードまたはハードウェア機能を含むことができる。したがって、セキュリティモジュール120は、トランスポートレイヤセキュリティ(TSL)、およびセキュアソケットレイヤ(SSL)などの、さまざまな暗号通信プロトコルのうちの1つまたは複数を実施するように動作可能であるものとしてよい。リモートサーバー102とのセキュア接続を確立した結果、リモートサーバー102の同一性(例えば、登録サーバー112および/または同期化サーバー114の同一性)は、クライアントデバイス104に対して認証され得る。
セキュア通信チャネルを提供し、リモートサーバー102の同一性をクライアントデバイス104に対して認証する際のセキュリティモジュール120の機能とは対照的に、認証モジュール122は、クライアントデバイス104の同一性をリモートサーバー102に対して認証するように動作可能である。セキュリティモジュール120と同様に、認証モジュール122は、対称暗号化、非対称暗号化、キー合意および/または確立、ハッシュ化、および署名などの、1つまたは複数のセキュリティ関係の機能を実行するためのコードまたはハードウェア機能を含むことができる。しかし、この場合、認証モジュール120は、拡張可能認証プロトコル(EAP)、チャレンジ-ハンドシェイク認証プロトコル(CHAP)、およびチャレンジ-レスポンス認証(CRAM)などのさまざまな認証プロトコルのうちの1つまたは複数を実施するように動作可能であるものとしてよい。本明細書では、使用され得る認証プロトコルのさまざまな例について、この後に説明する。
調整モジュール124は、クライアントデバイス104のバケット128Dの状態と同期化サーバー114において提供される対応するバケットとの調整を行うように動作可能である。バケット128Dの状態と同期化サーバー114における状態との調整を行うことによって、クライアントデバイス104側のバケット128Dおよび同期化サーバー114側の対応するバケットは、少なくとも最終的には、同一の内容を有することが保証される。さらに、システム100が、同じユーザーアカウントにペアリングされている監視デバイス108およびアクセスデバイス110など、互いに関連付けられている複数のクライアントデバイス104を含む場合、それぞれのクライアントデバイス104のバケット128Dの状態と同期化サーバー114において提供される対応するバケットとの調整を行うことによって、すべてのクライアントデバイス104側のバケット128Dは、同様に、少なくとも最終的には、同一の内容を有することが保証される。本明細書では、さまざまな調整技術が、さらに説明される。
セッションID生成器モジュール126は、クライアントデバイス104とリモートサーバー102との間に確立された一意的な通信セッションを識別するセッション識別子を生成するように動作可能である。セクション識別子は、さまざまな時刻のうちのどれかの時刻に生成され得、さまざまな持続時間のうちのどれかの持続時間の間持続し得る。例えば、一意的なセッション識別子は、クライアントデバイス104が電源を投入されたときに生成され、クライアントデバイス104の電源が切られるまで持続し得る。別の例として、セッション識別子は、クライアントデバイス104が登録サーバー112に再接続するたびに生成され、これにより、新しい割り当てられた資格証明書を取得し、クライアントデバイス104が再び登録サーバー112に再接続する必要が生じるまで持続し得る。さらに別の例では、セッション識別子が定期的に生成され得る。それぞれのセッションについて生成されるセッション識別子は、通信セッションを一意的に識別する識別子である。例えば、セッション識別子は、ランダムに生成される文字列、時間順の数値、または他の情報列であってよい。本明細書では、セッション識別子の使用についてさらに説明する。
すでに述べているように、ストレージ要素128は、登録サーバーロケーション128A、デバイス識別子128B、現在のソフトウェアバージョン128C、情報の1つまたは複数のバケット128D、既定の資格証明書128E、およびいくつかの時点における、割り当てられた資格証明書128Fなどの、さまざまな情報を含む。登録サーバーロケーション128Aは、クライアントデバイス104と登録サーバー112との間の通信が円滑になされるように登録サーバー112のターゲットロケーションを示す。例えば、登録サーバーロケーション128Aは、クライアントデバイス104がインターネットなどのネットワーク106経由で登録サーバー112に接続できるように登録サーバー112の名前を識別する統一資源識別子(URI)、または統一資源位置指定子(URL)などであってよい。いくつかの実施形態では、登録サーバーロケーション128Aは、クライアントデバイス104にハードコーディングされるか、またはクライアントデバイス104の不揮発性メモリ内に他の何らかの形で格納され得る。
デバイス識別子128Bは、クライアントデバイス104を一意的に識別するデータ文字列または他の情報列である。デバイス識別子128Bは、静的でも動的でもよい。例えば、静的デバイス識別子128Bは、クライアントデバイス104にハードコーディングされるか、またはクライアントデバイス104の不揮発性メモリ内に他の何らかの形で格納され得、例えば、シリアル番号、媒体アクセス制御(MAC)アドレス、または他の一意的な識別子とすることができる。動的デバイス識別子128Bは、クライアントデバイス104も一意的に識別する動的に生成された識別子であってもよい。動的デバイス識別子128Bは、クライアントデバイス104によって生成され得るか、またはいくつかの実施形態では、登録サーバー112などのシステムの他のエンティティによって生成され得る。特定の一実施形態において、クライアントデバイス104は、静的識別子および動的識別子などの、複数のデバイス識別子128Bを含むことができ、静的識別子は、クライアントデバイス104内にハードコーディングされ、動的識別子は、登録サーバー112によって生成され、クライアントデバイス104に提供される。特定の一実施形態において、デバイス識別子128Bは、本明細書でさらに説明されているように既定の資格証明書128Eおよび割り当てられた資格証明書128Fのうちの1つまたは複数の資格証明書で提供され得る。
現在のソフトウェアバージョン128Cは、クライアントデバイス104上で実行されているソフトウェアのバージョンを識別するデータ文字列または他の情報列である。例えば、いくつかの実施形態では、クライアントデバイス104のモジュール、および多くの場合における、クライアントデバイスの追加の機能のうちの1つまたは複数は、クライアントデバイス104上に格納されているソフトウェアコードで実装される。現在のソフトウェアバージョン128Cは、そのソフトウェアコードのバージョンを示し、ソフトウェアコードは時間が経つうちに更新されるか、または他の何らかの形で異なるバージョンと交換され得る。
バケット128Dは、図2を参照しつつすでに説明されているような情報のバケットである。したがって、それぞれのバケット128Dは、クライアントデバイス104が監視デバイス108である場合にクライアントデバイス104および/またはその環境の特性を定義するための複数のフィールド-値ペアを含む。フィールド-値ペアは、バケットの「内容」と称されることが多いが、バケットの内容は、フィールド-値ペア以外のさまざまな情報(例えば、ヘッダー、書式制御文字など)を含み得る。それぞれのバケット128Dは、これに関連付けられた、バケットを一意的に識別するバケット識別子またはバケット名(例えば、「バケットA」)を有し、これもまたすでに説明されているように、これに割り当てられ、また関連付けられた、タイムスタンプ(「t」)およびバージョン(「v」)を有するものとしてよい。
既定の資格証明書128Eは、製造時にデバイスに与えられ、その寿命が尽きるまでデバイスに付けられたままである、クライアントデバイス104およびリモートサーバー102に知られている、秘密パスワードなどの資格証明書である。したがって、既定の資格証明書は、クライアントデバイスが特定の企業体によって製造されたことを示し得る。既定の資格証明書は、資格証明書の種類(すなわち、既定の資格証明書)を識別するスキーム、デバイスを一意的に識別する識別子(例えば、シリアル番号、MACアドレスなど)、およびクライアントデバイス104およびリモートサーバー102に知られている秘密(例えば、識別子のハッシュ化されたバージョン)などの、さまざまな情報のうちの1つまたは複数を含み得る。
割り当てられた資格証明書128Fは、インタラクティブなやり取りの過程でリモートサーバーによってクライアントデバイス104に割り当てられ、いくつかの実施形態では、定期的に期限切れになり得る、クライアントデバイス104およびリモートサーバー102に知られている、秘密パスワードなどの資格証明書である。割り当てられた資格証明書は、既定の資格証明書と比較したときにセキュリティ対策が施されたリソースへのアクセス増大をクライアントデバイスにもたらすように動作することができ、デバイスがユーザーアカウントとペアリングされたときに、クライアントデバイスがそのアカウントに関連付けられていることを認証する。割り当てられた資格証明書は、資格証明書の種類(すなわち、割り当てられた資格証明書)を識別するスキーム、デバイスを一意的に識別する識別子(例えば、シリアル番号、MACアドレスなど)、およびクライアントデバイス104およびリモートサーバー102に知られている秘密(例えば、乱数)などの、さまざまな情報のうちの1つまたは複数を含み得る。
独立したモジュールとして説明されているが、クライアントデバイス104を参照しつつ説明されているさまざまなモジュールおよび要素は、1つまたは複数のモジュールに組み込まれ得るか、または1つまたは複数のモジュールにさらに分けることができることは理解されるであろう。さまざまなモジュールが、ソフトウェアまたはハードウェアで実装され、ストレージ要素128は、1つまたは複数のディスクドライブ、光学式記憶装置、ランダムアクセスメモリ(「RAM」)および/またはリードオンリーメモリ(「ROM」)などの固体記憶装置上などの1つまたは複数のデータベースなどの好適な様式で実装され得る。
本明細書では、クライアントデバイス104の要素のさまざまな他の特性、オペレーション、および使用について、さらに説明する。さらに、クライアントデバイス104は、さまざまなモジュールおよびコンポーネントを含むように図示されているが、本明細書で説明されているような電子デバイスのオペレーションを円滑にするための他の要素を含み得ることは理解されるであろう。当業者であれば、クライアントデバイスは、図4に示されているものよりも少ない、または多い数のコンポーネントと共に等しく適切に動作できることも理解するであろう。したがって、図4のクライアントデバイス104の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を制限するものとしてみなされるべきでない。
図5は、一実施形態による登録サーバー112のコンポーネントを示す簡素化されたブロック図である。登録サーバー112は、セキュリティモジュール140、認証モジュール142、層リダイレクションモジュール144、ソフトウェア更新モジュール146、同期化サーバー識別モジュール148、およびストレージ要素150を含む、多数の異なる機能モジュールを含む。ストレージ要素150は、同期化サーバー識別子150A、ソフトウェアバージョン/アップデータマップ150B、ソフトウェアバージョン/層マップ150C、およびデバイス識別子/層マップ150Dなどの、さまざまな情報を含み得る。
クライアントデバイス104を参照しつつ説明されているセキュリティモジュール120のような、セキュリティモジュール140は、登録サーバー112とクライアントデバイス104などのシステム100の他の要素との間のセキュア通信を提供するように動作可能である。したがって、セキュリティモジュール140は、クライアントデバイス104とのセキュア接続を確立し、その同一性を、クライアントデバイス104のセキュリティモジュール120との通信を介してクライアントデバイス104に対して認証するためにセキュリティモジュール120のコードまたはハードウェア機能と類似したコードまたはハードウェア機能を含むことができる。
認証モジュール142も、クライアントデバイス104を参照しつつ説明されている認証モジュール122に類似しており、したがって、クライアントデバイス104の認証モジュール122と通信してクライアントデバイス104の同一性を認証するように動作可能である。したがって、認証モジュール122は、クライアントデバイス104の認証モジュール122との通信を介してクライアントデバイス104の同一性を認証するためにクライアントデバイス104のコードまたはハードウェア機能と類似したコードまたはハードウェア機能を含むことができる。
層リダイレクションモジュール144は、クライアントデバイス104を、クライアントデバイス104が一部となり得る特定の層に基づきリモートサーバー102の異なるインスタンスにリダイレクトするように動作可能である。すなわち、登録サーバー112および同期化サーバー114Aから114Mを含む、リモートサーバー102の多数の異なるインスタンス(すなわち、作業コピー)が存在し得る。異なるインスタンスは、クライアントデバイス104が最初に接続する基本インスタンスと同じ機能を提供するか、または追加のもしくは代替的な機能を提供することができる。例えば、リモートサーバー102の異なるインスタンスは、生産目的、品質保証目的、ステージング目的などの、異なる目的のために生成され得る。生産インスタンスは、クライアントデバイス104が登録サーバーロケーション128Aを使って最初に接続する基本インスタンスであってよく、コンシューマの使用を対象とするオペラビリティの安定したバージョンを含み得る。対照的に、品質保証インスタンスは、システム100のテスターによって操作されるクライアントデバイス104がリダイレクションモジュール144を使ってリダイレクトされるリダイレクト先の試験インスタンスであってよく、試験インスタンスは、クライアントデバイス104、登録サーバー112などのシステム100のさまざまなエンティティの新しい、または異なるオペラビリティの試験を目的として使用され得る。
ソフトウェア更新モジュール146は、ソフトウェアバージョン情報を識別し、クライアントデバイス140にソフトウェアバージョン情報を提供するように動作可能である。ソフトウェアバージョン情報は、クライアントデバイス104が実行しているべきである一番最近の、または所望のソフトウェアバージョンを示し得、かつ/またはクライアントデバイス104がソフトウェア更新を取得するために訪れることができるソフトウェア更新デスティネーション(例えば、ターゲットURI)を示し得る。ソフトウェア更新モジュール146は、クライアントデバイス104が本明細書で説明されているような機能の一部または全部を実行するためのコンピュータソフトウェアを含む実装に特によく適している。
同期化サーバー識別モジュール148は、クライアントデバイス104および他の関係するクライアントデバイス104(例えば、複数のクライアントデバイス104が同じ構造またはユーザーアカウントに関連付けられている場合)に代わって同期化オペレーションを実行するためにクライアントデバイス104に割り当てられている複数の同期化サーバー114Aから114Mのうちの1つを識別するように動作可能である。すでに説明されているように、いくつかの実施形態では、リモートサーバー102は、複数の同期化サーバー114Aから114Mを含む。それぞれの同期化サーバーは、可能なすべてのクライアントデバイス104のサブセット(すなわち、登録サーバー112に登録されているすべてのクライアントデバイス104のサブセット)に代わって同期化オペレーションを実行するように割り当てられ得る。それぞれの同期化サーバーが可能なすべてのクライアントデバイス104のサブセットにのみ割り当てられるので、システム100全体の同期化作業負荷は、同期化サーバー114Aから114Mに分散される。本明細書では、同期化サーバー114Aから114Mをクライアントデバイス104に割り当てるためのさまざまな技術についてさらに説明しているが、図3に示されていないが、いくつかの実施形態では、システム100は、複数の同期化サーバーではなく単一の同期化サーバーのみを備え得ることは理解されるであろう。そのような場合、単一の同期化サーバーは、すべてのクライアントデバイス104に代わって同期化オペレーションを実行する。理解されるであろうが、同期化サーバー識別モジュール148は、複数の同期化サーバーを含む実装に特によく適している。
すでに述べているように、ストレージ要素150は、同期化サーバー識別子150A、ソフトウェアバージョン/アップデータマップ150B、ソフトウェアバージョン/層マップ150C、およびデバイス識別子/層マップ150Dなどの、さまざまな情報を含む。同期化サーバー識別子150Aは、それぞれ、複数の同期化サーバー114Aから114Mのうちの1つを一意的に識別する。例えば、同期化サーバー識別子150Aは、それぞれの同期化サーバーに対するURI、またはURLなどを含むものとしてよい。したがって、登録サーバー112は、異なる同期化サーバーを知っており、選択された同期化サーバーのターゲットロケーションをクライアントデバイス104に伝達することができる。
ソフトウェアバージョン/アップデータマップ150Bは、クライアントデバイス(例えば、デバイス識別子)を特定のソフトウェアバージョン、およびいくつかの実施形態では、ソフトウェア更新デスティネーションに相関させるか、または他の何らかの形でマッピングするマップである。少なくとも1つの実施形態において、異なるクライアントデバイス104は、異なるバージョンのコンピュータソフトウェアをローカルで実行するように制御され得る。例えば、コンシューマに分配されるクライアントデバイス104は、コンシューマに適したバージョンのソフトウェアを実行するように制御され得るが、システム100のテスターに分配されるクライアントデバイス104は、テスターに適したバージョンのソフトウェアを実行するように制御され得る。したがって、ソフトウェアバージョン/アップデータマップ150Bは、クライアントデバイス104とそれらのデバイスが実行しているべきであるソフトウェアバージョンとの間のマッピングを含む。デバイス識別子128Bは、それぞれのクライアントデバイス104を一意的に識別するので、ソフトウェアバージョン/アップデータマップ150Bは、登録サーバー112が、デバイス識別子128Bに基づきクライアントデバイス104が実行しているべきである適切なソフトウェアバージョンを決定することを可能にするようにデバイス識別子とソフトウェアバージョンとの間のマッピングを含み得る。さらに、いくつかの実施形態では、異なるソフトウェア更新エンティティまたはターゲットロケーションが使用され、したがって、異なるソフトウェアアップデータロケーションは、異なるソフトウェアバージョンに関連付けられ得る。いくつかの実施形態では、同じソフトウェアアップデータロケーションが、すべてのソフトウェア更新に使用され得、さらに他の実施形態では、同じソフトウェアバージョンが、すべてのクライアントデバイス104によって使用され得る。
ソフトウェアバージョン/層マップ150Cは、クライアントデバイス104が実行している現在のソフトウェアバージョンをクライアントデバイス104が一部となっている層と相関させるマップである。クライアントデバイス104が一部となっている層を識別することによって、登録サーバー112は、クライアントデバイス104をリモートサーバー102のインスタンス上に保持するか、または層リダイレクションモジュール144を介してクライアントデバイス104をリモートサーバー102の異なるインスタンス上に回送することができる。ソフトウェアバージョン/層マップ150Cは、クライアントデバイスの層を識別することによって、それに対応して、登録サーバー112の異なるインスタンスのターゲットロケーションを識別することができ、したがって、例えば、クライアントデバイス104が未認証のソフトウェアバージョンを現在実行している場合に、登録サーバー112は、クライアントデバイス104を登録サーバー112の異なるインスタンス(例えば、テストインスタンス)、したがってリモートサーバー102の異なるインスタンスにリダイレクトすることができる。
デバイス識別子/層マップ150Dは、ソフトウェアバージョン/層マップ150Cに似たマップであるが、クライアントデバイス104が実行している現在のソフトウェアバージョンを層と相関させる代わりに、マップ150Cは、クライアントデバイス104のデバイス識別子を層と相関させる。この様式で、登録サーバーは、クライアントデバイス104がどのソフトウェアバージョンを実行しているかに関係なくリモートサーバー102の異なるインスタンスにクライアントデバイス104をリダイレクトすることができる。
独立したモジュールとして説明されているが、登録サーバー112を参照しつつ説明されているさまざまなモジュールおよび要素は、1つまたは複数のモジュールに組み込まれ得るか、または1つまたは複数のモジュールにさらに分けることができることは理解されるであろう。さまざまなモジュールが、ソフトウェアまたはハードウェアで実装され、ストレージ要素150は、1つまたは複数のディスクドライブ、光学式記憶装置、ランダムアクセスメモリ(「RAM」)および/またはリードオンリーメモリ(「ROM」)などの固体記憶装置上などの1つまたは複数のデータベースなどの好適な様式で実装され得る。
本明細書では、登録サーバー112の要素のさまざまな他の特性、オペレーション、および使用について、さらに説明する。さらに、登録サーバー112は、さまざまなモジュールおよびコンポーネントを含むように図示されているが、本明細書で説明されているような電子デバイスのオペレーションを円滑にするための他の要素を含み得ることは理解されるであろう。当業者であれば、登録サーバー112は、図5に示されているものよりも少ない、または多い数のコンポーネントと共に等しく適切に動作できることも理解するであろう。したがって、図5の登録サーバー112の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を制限するものとしてみなされるべきでない。
図6は、一実施形態による同期化サーバー114のコンポーネントを示す簡素化されたブロック図である。同期化サーバー114は、セキュリティモジュール160、認証モジュール162、クライアントアロケータモジュール164、関連するバケット識別子166、バケット生成器168、バージョン生成器170、タイムスタンプ生成器172、調整モジュール174、およびストレージ要素178を含む、多数の異なる機能モジュールを含む。ストレージ要素178は、同期化サーバー識別子178A、デバイス識別子178B、デバイス識別子/バケットマップ178C、およびデバイス識別子/ユーザーアカウントマップ178Dなどの、さまざまな情報を含み得る。
クライアントデバイス104を参照しつつ説明されているセキュリティモジュール120のような、セキュリティモジュール160は、同期化サーバー114とクライアントデバイス104などのシステム100の他の要素との間のセキュア通信を提供するように動作可能である。したがって、セキュリティモジュール160は、クライアントデバイス104とのセキュア接続を確立し、その同一性を、クライアントデバイス104のセキュリティモジュール120との通信を介してクライアントデバイス104に対して認証するためにセキュリティモジュール120のコードまたはハードウェア機能と類似したコードまたはハードウェア機能を含むことができる。
認証モジュール162も、クライアントデバイス104を参照しつつ説明されている認証モジュール122に類似しており、したがって、クライアントデバイス104の認証モジュール122と通信してクライアントデバイス104の同一性を認証するように動作可能である。したがって、認証モジュール162は、クライアントデバイス104の認証モジュール122との通信を介してクライアントデバイス104の同一性を認証するためにクライアントデバイス104のコードまたはハードウェア機能と類似したコードまたはハードウェア機能を含むことができる。
クライアントアロケータモジュール164は、複数の同期化サーバー114Aから114Mのうちから1つの同期化サーバーを特定のクライアントデバイス104に割り当てるように動作可能である。すでに説明されているように、単一の同期化サーバー114は、クライアントデバイスのサブセットに代わって同期化オペレーションを実行することができる。したがって、クライアントアロケータモジュール164は、特定のクライアントデバイス104に割り当てる特定の同期化サーバーを識別するための1つまたは複数のアルゴリズムを含むことができる。特定の一実施形態において、クライアントアロケータモジュール164は、そのような割り当てを実行するコンシステントハッシュ化アルゴリズムを実施することができる。しかし、実施形態は、コンシステントハッシュ化アルゴリズムの使用に限定されないが、むしろ、自明なハッシュ関数、完全ハッシュ関数、最小完全ハッシュ関数、専用ハッシュ関数、ローリングハッシュ関数、ユニバーサルハッシュ関数などの、他の種類のハッシュ化アルゴリズムが使用され得る。特定の同期化サーバーを識別することを円滑にするために、それぞれの同期化サーバーは、システム100内のすべての同期化サーバー、さらには同期化サーバーを割り当てられることを望んでいるクライアントデバイス104に対するデバイス識別子を知っているものとしてよい。システム100内のすべての同期化サーバーの同一性は、例えば、同期化サーバー識別子178A内に格納され得るが、受信されたデバイス識別子は、デバイス識別子178Bとして格納され得る。このスキームのおかげで、登録サーバー112が特定のクライアントデバイス104を同期化サーバー114のうちの指定された同期化サーバーに送るときが来たときに、登録サーバー112は、最初に、同期化サーバー114のどれかに、それらのうちのどれが注目している特定のクライアントデバイス104に対する指定された同期化サーバーであるべきかについて問い合わせを行うことができる。他にも利点はあるがとりわけ、複数の同期化サーバー114間での負荷平衡は、登録サーバー112、または任意の他の外部負荷平衡システムがその負荷平衡プロセスを律する必要なく、それ専用の自律的割り当てアルゴリズムのおかげで達成され得るものがある。
関連するバケット識別子166は、特定のクライアントデバイス104に関連するバケットを識別するように動作可能である。関連することによって、クライアントデバイスと同期化サーバーとの間で同期されるのがこれらのバケットである。例えば、図8を簡単に参照すると、図8は、一実施形態によるストレージ要素118のいくつかの内容を示している。ストレージ要素118は、それぞれのデバイスについて、複数のバケットを含む。例えば、クライアントデバイス104「デバイスA」について、ストレージ要素116は、バケット190を含み、これは「バケットA」、「バケットB」、「バケットC」、「バケットZ」、および「バケットS」を含む。デバイスAは、「ユーザーA」に対するユーザーアカウントにペアリングされるか、または他の何らかの形で関連付けられる。ストレージ要素118は、デバイスAに対する少なくとも5個のバケットを含むが、バケットA、B、C、およびSを含む、これらのバケットのサブセット190Aのみが同期化サーバー114側の対応するバケットと同期される。少なくとも1つのバケット190B、バケットZは、同期化サーバー114側の対応するバケットと同期されない。したがって、所定のクライアントデバイス104について、関連するバケット識別子166は、バケットA、B、C、およびSを、クライアントデバイス104とリモートサーバー102との間で同期されるべきなのがこれらのバケット(この例における)なので、識別するように動作可能である。
バケット生成器168は、リモートサーバー102でバケットのインスタンスを生成するように動作可能である。いくつかの実施形態では、情報のバケット(例えば、バケット190)は、ストレージ要素118内に(例えば、リモートサーバー102に)事前には存在しない。むしろ、バケットは、クライアントデバイスへ初期接続し、またはクライアントデバイスを初期化後、作成され得る。例えば、最初に監視デバイス108を登録サーバー112に接続した後、登録サーバー112は、クライアントデバイス104に関連付けられているバケットがストレージ要素118で作成されるようにし得る。
バージョン生成器170は、それぞれのバケットに対するバージョン識別子を生成するように動作可能である。バージョン識別子は、ある特定の時刻において特定のクライアントに対する特定のバケットのバージョンを一意的に識別するように動作する文字列または他のデータ列とすることができる。例えば、図8を参照すると、所定の時点において、バケット190のバケットAは、バケットAが使用中である時間にわたってバケットAに対して一意的であるバージョンを関連付けられ得る。いくつかの実施形態では、特定のバケットのバージョンは、同じまたは異なるユーザーに関連付けられている他のバケットに関しても一意的であるが、他の実施形態では、特定のバケットのバージョンは、同じまたは異なるユーザーに関連付けられている他のバケットに関して一意的でない場合がある。バージョン生成器170は、バージョン識別子を、ランダムに、逐次的に、または一意的な識別子を生成するのに適した他の様式で生成することができる。
タイムスタンプ生成器172は、それぞれのバケットに対するタイムスタンプを生成するように動作可能である。タイムスタンプは、時刻の指示を与えるように動作する文字列または他のデータ列であってよい。例えば、タイムスタンプ生成器172は、バケットが生成される時刻を示すタイムスタンプを生成することができる。その後、バケットが変更された時点で、タイムスタンプ生成器172は、バケットが変更された時刻を示す新しいタイムスタンプを生成することができる。いくつかの実施形態では、タイムスタンプは、タイムスタンプが絶対時間を示さないとしても、タイムスタンプの順序が、あるタイムスタンプが別のタイムスタンプの前または後に生成されたかどうかを示すように時間順に生成され得る。
調整モジュール174は、クライアントデバイス104の調整モジュール124に類似しているが、この場合、ストレージ要素118側のバケットの状態とクライアントデバイス104側のバケット128Dの状態とを調整するように動作可能である。システム100が所定のユーザーに関連付けられている多数の異なるクライアントデバイス104を含む実施形態では、調整モジュール174は、ストレージ要素118側のバケットの状態とすべてのクライアントデバイス側のバケットの状態とを調整するように動作可能である。
すでに述べているように、ストレージ要素178は、同期化サーバー識別子178A、デバイス識別子178B、デバイス識別子/バケットマップ178C、およびデバイス識別子/ユーザーアカウントマップ178Dなどの、さまざまな情報を含み得る。同期化サーバー識別子178Aは、同期化サーバー識別子150Aと類似しており、デバイス識別子178Bは、デバイス識別子128Bと類似しているため、さらなる説明は省く。デバイス識別子/バケットマップ178Cは、デバイス識別子とバケットとの間のマッピングまたは相関関係である。すなわち、デバイス識別子/バケットマップ178Cは、それらのクライアントデバイス104に関連付けられているストレージ要素118側に格納されているバケットと共にクライアントデバイス104をマッピングする。例えば、図8を参照すると、デバイス識別子/バケットマップ178Cは、バケットA、B、C、Z、およびSを伴うデバイスAに対するデバイス識別子をバケット190においてマッピングすることができる。デバイス識別子/ユーザーアカウントマップ178は、クライアントデバイス104のユーザーによってリモートサーバー102により確立されたデバイス識別子とユーザーアカウントの間のマッピングまたは相関関係である
説明されている実施形態のうちの1つまたは複数は、特注の専用ハードウェア実装を構築することに付随する費用または遅れを必要とすることなく多数のクライアントデバイス104(例えば、いくつかのシナリオにおけるそのような数百台のクライアントデバイスから、他のシナリオにおけるそのような数十万台のクライアントデバイス、さらに別のシナリオにおけるそのような数百万台以上のクライアントデバイスまで)にサービスを提供するために、信頼性が高く、経済的で、拡張性が高い様式でリモートサーバー102の全部または一部を実装することを望むこともある企業が、より一般的に利用可能である仮想コンピューティングマシンおよびデータストレージ要素の性質に照らしてさらに明らかにされる1つまたは複数の利点を享受し得る。例示的な一シナリオにおいて、リモートサーバー102は、ワシントン州シアトル所在のAmazon, Inc.社などのクラウドサービス提供会社からコンピューティングおよびデータストレージ容量を購入することによって実装することができ、その場合、それぞれの登録サーバー112は、ローカルインスタンスストアボリューム、マウントされたEBS(Elastic Block Storage)ボリューム、およびデータストレージ要素150の少なくとも一部として使用される一意的なAmazon RDS(リレーショナルデータベースサービス)インスタンスへのアクセスのうちの1つまたは複数を有するEC2(Elastic Computing Cloud)インスタンスであってよく、それぞれの同期化サーバー114は、ローカルインスタンスストアボリューム、マウントされたEBS(Elastic Block Storage)ボリューム、およびデータストレージ要素178の少なくとも一部として使用される一意的なAmazon RDS(リレーショナルデータベースサービス)インスタンスへのアクセスのうちの1つまたは複数を有するEC2インスタンスであってよく、それぞれのロギングサーバー116は、データストレージ要素186の少なくとも一部として使用されるAmazon S3(Simple Storage Service)インスタンスへのアクセスを有するEC2インスタンスであってよく、ストレージ要素118は、Amazon RDS(Relational Database Service)インスタンスであってよい。一般的に言えば、そのような実装について、それぞれの登録サーバー112に対するデータストレージ要素150は、その特定の登録サーバー112に専用のものであり、その特定の登録サーバー112によってのみ容易にアクセスされ、それぞれの同期化サーバー114に対するデータストレージ要素178は、その特定の同期化サーバー114に専用のものであり、その特定の同期化サーバー114によってのみ容易にアクセスされる。データストレージ要素186は、もっぱら、ロギングサーバー116によってアクセスされ得るが、正しい認証資格証明書を提供するシステム100の他の要素へのアクセスも許すことができる。登録サーバー112および同期化サーバー114に対するストレージ要素とは対照的に、ストレージ要素118は、同期化サーバー114(さらには望ましい場合には登録サーバー112およびロギングサーバー116)のすべてにアクセス可能であるが、当技術分野で知られているように、データの書き込みおよび取り出し速度は、一般的に、それぞれの同期化サーバー114が自ローカルデータストレージ要素178に対して読み書きするときほどは速くならない。
独立したモジュールとして説明されているが、同期化サーバー114を参照しつつ説明されているさまざまなモジュールおよび要素は、1つまたは複数のモジュールに組み込まれ得るか、または1つまたは複数のモジュールにさらに分けることができることは理解されるであろう。さまざまなモジュールが、ソフトウェアまたはハードウェアで実装され、ストレージ要素178は、1つまたは複数のディスクドライブ、光学式記憶装置、ランダムアクセスメモリ(「RAM」)および/またはリードオンリーメモリ(「ROM」)などの固体記憶装置上などの1つまたは複数のデータベースなどの好適な様式で実装され得る。
本明細書では、同期化サーバー114の要素のさまざまな他の特性、オペレーション、および使用について、さらに説明する。さらに、同期化サーバー114は、さまざまなモジュールおよびコンポーネントを含むように図示されているが、本明細書で説明されているような電子デバイスのオペレーションを円滑にするための他の要素を含み得ることは理解されるであろう。当業者であれば、同期化サーバー114は、図6に示されているものよりも少ない、または多い数のコンポーネントと共に等しく適切に動作できることも理解するであろう。したがって、図6の同期化サーバー114の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を限定するものとしてみなされるべきでない。
図7は、一実施形態によるロギングサーバー116のコンポーネントを示す簡素化されたブロック図である。ロギングサーバー116は、セキュリティモジュール180、認証モジュール182、カテゴライザーモジュール184、およびストレージ要素186を含む、多数の異なる機能モジュールを含む。ストレージ要素186は、ロギング情報186Aなどの、さまざまな情報を含み得る。
クライアントデバイス104を参照しつつ説明されているセキュリティモジュール120のような、セキュリティモジュール180は、ロギングサーバー116とクライアントデバイス104などのシステム100の他の要素との間のセキュア通信を提供するように動作可能である。したがって、セキュリティモジュール180は、クライアントデバイス104とのセキュア接続を確立し、その同一性を、クライアントデバイス104のセキュリティモジュール120との通信を介してクライアントデバイス104に対して認証するためにセキュリティモジュール120のコードまたはハードウェア機能と類似したコードまたはハードウェア機能を含むことができる。
認証モジュール182も、クライアントデバイス104を参照しつつ説明されている認証モジュール122と類似しており、したがって、クライアントデバイス104の認証モジュール122と通信してクライアントデバイス104の同一性を認証するように動作可能である。したがって、認証モジュール182は、クライアントデバイス104の認証モジュール122との通信を介してクライアントデバイス104の同一性を認証するためにクライアントデバイス104のコードまたはハードウェア機能と類似したコードまたはハードウェア機能を含むことができる。
カテゴライザーモジュール186は、クライアントデバイスからロギングサーバー116に提供される情報(例えば、ロギング情報)を分類するように動作可能である。情報を分類する際に、カテゴライザーモジュール186は、クライアントデバイス104の認証のレベルに基づき情報を分類する。これは、クライアントデバイス104がロギングサーバー116とのセキュア接続、またはセキュアでない接続を確立したかどうか、クライアントデバイス104が、割り当てられた、または既定の資格証明書をサブミットしたかどうか、およびサブミットした資格証明書が有効であったかまたは無効であったかなどの、さまざまな要因のうちの1つまたは複数を考慮することができる。
すでに述べているように、ストレージ要素186は、ロギング情報186Aなどの、さまざまな情報を含み得る。ロギング情報186Aは、クライアントデバイス104がロギングサーバー116に送信することを望んでいるさまざまな情報を含み得る。これは、例えば、デバイスのステータス、デバイスの最近のオペレーション、デバイスの環境条件などに関する情報を含むものとしてよい。特定の一実施形態において、これは、クライアントイベントログ(クライアントデバイスが感知した内容に関する情報)、クライアントデビューログ(デバイスが最後に再起動したとき、デバイスが最後にワイヤレス接続を確立したときなどの、デバイスの体系的な態様に関する情報)、およびシステムログ(例えば、標準のLinux(登録商標)ログ)を含み得る。いくつかの実施形態では、ロギング情報186Aは、クライアントデバイスの認証のレベルに基づき格納され得る。すなわち、クライアントデバイスが少なくとも特定のレベルの認証を達成した場合にのみ格納され得る情報がある。
独立したモジュールとして説明されているが、ロギングサーバー116を参照しつつ説明されているさまざまなモジュールおよび要素は、1つまたは複数のモジュールに組み込まれ得るか、または1つまたは複数のモジュールにさらに分けることができることは理解されるであろう。さまざまなモジュールが、ソフトウェアまたはハードウェアで実装され、ストレージ要素186は、1つまたは複数のディスクドライブ、光学式記憶装置、ランダムアクセスメモリ(「RAM」)および/またはリードオンリーメモリ(「ROM」)などの固体記憶装置上などの1つまたは複数のデータベースなどの好適な様式で実装され得る。
本明細書では、ロギングサーバー116の要素のさまざまな他の特性、オペレーション、および使用について、さらに説明する。さらに、ロギングサーバー116は、さまざまなモジュールおよびコンポーネントを含むように図示されているが、本明細書で説明されているような電子デバイスのオペレーションを円滑にするための他の要素を含み得ることは理解されるであろう。当業者であれば、ロギングサーバー116は、図7に示されているものよりも少ない、または多い数のコンポーネントと共に等しく適切に動作できることも理解するであろう。したがって、図7のロギングサーバー116の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を限定するものとしてみなされるべきでない。
すでに述べているように、図8は、一実施形態によるストレージ要素118の内容を示す。ストレージ要素118は、1つまたは複数のディスクドライブ、光学式記憶装置、ランダムアクセスメモリ(「RAM」)および/またはリードオンリーメモリ(「ROM」)などの固体記憶装置上などの1つまたは複数のデータベースなどの好適な様式で実装され得る。この特定の例では、ユーザーAは、2つのデバイスデバイスAおよびデバイスBに関連付けられている。ストレージ要素118は、デバイスAに関連付けられているバケット190を含み、デバイスBに関連付けられているバケット192を含む。ユーザーBおよびユーザーCなどの他のユーザーは、他のバケット194および196に関連付けられている。すでに説明されているように、バケット190Aは、デバイスAに関連しているが、バケット190Bは、デバイスAに関連していない。さらに、この例のバケットSは、デバイスAとデバイスBとの間で共有されているバケットである。ストレージ要素118は、リモートサーバー102に知られているすべてのデバイスの既定の資格証明書198を含み得る。ストレージ要素118は、割り当てられた資格証明書がリモートサーバー102によって生成されたデバイスに対する割り当てられた資格証明書199も含み得る。
さまざまなデバイスおよびユーザーに対するさまざまなバケットを含めて説明されているが、図8のストレージ要素118の図は、単なる例であり、説明を目的として使用されているだけであることは理解されるであろう。実施形態は、図8に示され、図8を参照しつつ説明されているバケットの内容または配置構成に限定されるべきでない。むしろ、当業者であれば、さまざまな実装で使用される可能性のある無数の変更形態を認識するであろう。
図9は、一実施形態による本明細書で説明されている同期化メカニズムを組み込むプロトコルスタック200を示す図である。一般的に、いくつかの実施形態では、本明細書で説明されている分散状態の分配のためのサブスクリプション通知メカニズム(SMSDS)は、転送制御プロトコル/インターネットプロトコル(TCP/IP)モデルにおけるハイパーテキスト転送プロトコルセキュア(HTTPS)スタックの最上部に置かれる。
特に、プロトコルスタック200は、物理レイヤ202、データリンクレイヤ204、ネットワークレイヤ206、トランスポートレイヤ208、およびアプリケーションレイヤ210を含む。物理レイヤ202は、RS-232、EIA-422、10BASE-Tなどの、基本的なネットワークハードウェア伝送技術からなる。データリンクレイヤ204は、ワイドエリアネットワーク(WAN)内の隣接するネットワークノード間、または同じローカルエリアネットワーク(LAN)セグメント上のノード間でデータを転送し、イーサネット(登録商標)、Wi-Fi、トークンリングなどの技術を使用する。ネットワークレイヤ206はパケット回送を行い、インターネットプロトコル(IPv4/IPv6/など)などの技術を使用する。トランスポートレイヤ208は、アプリケーションに対するエンドツーエンド通信サービスを提供し、TCP、ユーザーデータグラムプロトコル(UDP)、データグラム輻輳制御プロトコル(DCCP)、ストリーム制御伝送プロトコル(SCTP)などの技術を使用する。アプリケーションレイヤ210は、プロセス間通信を確立し、HTTP、HTTPS、ファイル転送プロトコル(FTP)などの技術を使用する第1のレイヤ210A、およびSMSDSを実装する第2のレイヤ210Bを含む。
特定の一実施形態において、SMSDSは、GET、PUT、およびPOSTなどのHTTPコマンドを使用することができ、HTTPは、一般にTCPの上に実装される。本明細書では、このようなコマンドを使用してさまざまな例が開示されている。しかし、本開示の範囲は、それに限定されず、これは他の実施形態では、SMSDSはUDP、DCCPなどの、TCP以外のプロトコルの上に実装され得るからである。したがって、図9のプロトコルスタック200の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を限定するものとしてみなされるべきでない。
サブスクリプションベースの通知を使用して分散状態の同期化を円滑にするためのプロセス
図10は、一実施形態による監視デバイスをリモートサーバーに接続するためのプロセスの通信シーケンス300を示している。理解しやすくするために、プロセス300は、図1から図8を参照しつつ説明されているが、プロセス300の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
一般的に、監視デバイス108は、同期化の準備をする接続プロセスを、次いで、システム100の他のエンティティと共に定常状態を維持する同期化プロセスを実行する。監視デバイス108が、接続プロセスを実行する状況として、(1)初期接続(例えば、インストール後に監視デバイスが最初にシステム100に接続されるとき、リセット後に監視デバイスが最初にシステム100に接続されるとき、など)、および(2)その後接続(例えば、停電、通信問題などが生じた後に監視デバイスがシステム100に再接続するとき)の2つがある。これら2つの状況に対するさまざまな実施形態において実施され得る微妙な差異について、図10を参照しつつ説明する。
オペレーション302において、監視デバイス108は、登録サーバー112とのセキュア接続を確立する。監視デバイス108は、例えば、監視デバイス108内にハードコーディングされた登録サーバーロケーション128Aを使用して、登録サーバー112のロケーション(例えば、URI)を最初に識別することができる。登録サーバー112のロケーションを識別した後、監視デバイス108のセキュリティモジュール120が、登録サーバー112のセキュリティモジュール140を介して登録サーバー112とのセキュア接続を確立することができる。セキュリティモジュールは、TSL、およびSSLなどのさまざまなセキュリティ通信プロトコルのうちの1つまたは複数を使用して、その後の通信のハンドシェイク、認証(登録サーバー112の)、および暗号化を実行することができる。
監視デバイス108と登録サーバー112との間でセキュア接続が確立された後、処理がオペレーション304に進み、そこで、監視デバイス104は、登録サーバー112に登録要求を伝達する。登録要求は、とりわけ、同期化サーバー114Aから114Mのうちの1つに割り当てられるべき要求である。登録要求は、デバイス識別子128B、現在のソフトウェアバージョン128Cなどのさまざまな情報のうちの1つまたは複数を含むものとしてよい。特定の一実施形態において、本明細書でさらに説明されているように、登録要求は、監視デバイス108を登録サーバー112に対して認証するのを補助するための既定の資格証明書を含み得る。例えば、認証モジュール122は、監視デバイス108上のストレージ要素128に格納されている既定の資格証明書128Eを識別し、それらの資格証明書を登録サーバー112に伝達することができる。
登録要求を受信すると、登録サーバー112は、さまざまなオペレーションを実行し、その一部はオペレーション306から314を参照しつつ図示され説明されている。一実施形態において、本明細書でもさらに説明されているように、登録サーバー112は、受信された既定の資格証明書に基づき、割り当てられた資格証明書(すなわち、監視デバイス108に一意的に割り当てられた資格証明書)を生成し、オペレーション306において、割り当てられた資格証明書を監視デバイス108に返す。例えば、登録サーバー112は、認証モジュール142を使用して、受信された既定の資格証明書の有効性を検証し、そこから割り当てられた資格証明書を生成し、割り当てられた資格証明書を監視デバイス108の認証モジュール122に伝達し、次いで、このデバイスは割り当てられた資格証明書を割り当てられた資格証明書128Fとしてストレージ要素128に格納することができる。
別の実施形態において、登録サーバーは、層リダイレクションを実行し、登録サーバー112は、監視デバイス108をリモートサーバー102の別のインスタンスにリダイレクトする(例えば、監視デバイス108を登録サーバー112の別のインスタンスにリダイレクトすることによって)。例えば、登録サーバー112は、層リダイレクションモジュール144を使用して、監視デバイス108がリダイレクトされる必要があるかどうかを判定し、もしそうならば、リダイレクトターゲットロケーション(例えば、URI)を監視デバイス108に伝達することができる。監視デバイス108は、監視デバイス108が未認証のソフトウェアを実行している場合にリモートサーバー102の別のインスタンスにリダイレクトされ得、かつ/または監視デバイス108がシステム100の別のインスタンスにマッピングされる場合にシステム100の別のインスタンスにリダイレクトされ得る。このようなリダイレクションを円滑にするために、登録では、例えば、受信された現在のソフトウェアバージョン128Cと併せたソフトウェアバージョン/層マップ150C、および/または受信されたデバイス識別子128Bと併せたデバイスID/層マップ150Dを使用することができる。
監視デバイス108が、システム100の別のインスタンスにリダイレクトされる場合、オペレーション308において、登録サーバー112は、リダイレクトターゲットロケーションを監視デバイス108に伝達する。その時点において、監視デバイス108は、もう一度、接続プロセス300を実行するが、リダイレクトされたターゲットロケーションにおいてである。そうでない場合、接続プロセス300は続けることができる
登録サーバー112は、いくつかの実施形態において、監視デバイス108が所望のバージョンのソフトウェアを実行していることを保証するためにソフトウェア更新プロセスを開始することができる。多数の異なるソフトウェア更新プロセスが実施され得るが、特定の一実施形態において、登録サーバー112は、監視デバイス108の所望のソフトウェアバージョンおよびターゲットロケーション(例えば、URI)を識別し、監視デバイス108は、更新されたソフトウェアを取得し、その情報を監視デバイス108に伝達することができる。例えば、登録サーバー112は、ソフトウェアバージョン/アップデータマップ150Bを使用して、この情報を識別することができ、その後、オペレーション310においてこの情報を監視デバイス108に伝達することができる。
大半の実施形態において、登録サーバー112は、監視デバイス108に割り当てられ、したがって、監視デバイス108に代わって同期化を実行する複数の同期化サーバー114Aから114Mのうちの1つを識別する。したがって、オペレーション312において、登録サーバー112は、同期化サーバー114Aから114Mのうちの特定の1つ(すなわち、割り当てられた同期化サーバー)のロケーション識別子(例えば、URI)を伝達する。しかし、他の実施形態では、同期化サーバーは1つしかなくてもよい。いずれかの場合において登録サーバー112はその1つの同期化サーバーのロケーションをオペレーション312において監視デバイス108に伝達するか、または他の実施形態では、その同期化サーバーのロケーションは、監視デバイス108上に事前に格納され得る。
登録サーバー112が、割り当てられた同期化サーバーの同一性を監視デバイス108に伝達した後、処理はオペレーション314に進むことができ、そこで、登録サーバー112は、監視デバイス108に対するバケットを作成するように、割り当てられた同期化サーバー114に要求する。要求は、適切なバケットを作成するように同期化サーバー114に指令するためのさまざまな情報を含み得る。例えば、要求は、同期化サーバー114内のバケット生成器168がストレージ要素118内に好適なバケットを作成するために次に使用することができる監視デバイス108のデバイス識別子128Bを含み得る。オペレーション314はオペレーション312後に続く必要はないが、むしろ、適切なバケットを作成するように同期化サーバー114に指令するための情報を受信するか、または生成した後の適切な任意の他の時間に、例えば、デバイス識別子128Bを受信した後いつでも、実行することが可能であることが理解されるであろう。
監視デバイス108が、割り当てられた同期化サーバーのロケーションを取得した後、監視デバイス108は、割り当てられた同期化サーバーとの通信を確立することができる。一実施形態において、監視デバイス108は、例えば、セキュリティモジュール120を使用してオペレーション316に示されているように同期化サーバーとのセキュア接続を確立する。割り当てられた同期化サーバー114は、同様に、セキュリティモジュール160を使用してセキュア接続を確立することができ、セキュア接続は、オペレーション302を参照しつつ説明されているものと類似しているものとしてよいが、この場合、登録サーバー112ではなく同期化サーバー114の同一性を監視デバイス108に対して認証するように動作し得る。少なくとも1つの実施形態において、セキュア接続は、監視デバイスに一意的である同期化サーバー114のポートを使用して確立され得る。そのような場合、同期化サーバー114は、デバイスが接続した接続ポートを介してそれに接続するデバイスのクラスを識別することができる。いくつかの実施形態では、ポートは、特定の種類の監視デバイスに対して一意的であるか、または監視デバイス上で実行しているソフトウェアの特定のバージョンに対して一意的であるものとしてよい。そのような場合、同期化サーバー114は、それに接続されているデバイスが監視デバイスであるかどうかだけでなく、監視デバイスの種類、監視デバイス上で実行しているソフトウェア(例えば、オペレーティングシステム)のバージョンなども識別することができる。
監視デバイス108と割り当てられた同期化サーバー114との間でセキュア接続が確立された後、処理がオペレーション318に進み、そこで、監視デバイス108は、それに関連するすべてのバケットを要求する。この文脈において関連するバケットは、監視デバイス108と同期化サーバー114などのシステム100の他の要素との間で同期されるべきバケットである。
同期化サーバー114が、例えば、関連するバケット識別子166およびデバイス識別子/バケットマップ178Cを使用して監視デバイス108に関連するバケットを識別した後、同期化サーバー114は、オペレーション320に示されているように関連するバケットのそれぞれに対するバケット識別子を監視デバイス108に伝達することができる。いくつかの実施形態では、それが初期接続であるかまたはその後の接続であるかに基づき監視デバイス108に異なる情報が伝達され得る。それが監視デバイス108と同期化サーバー114との間の初期接続である場合(同期化サーバー114が実行し得る決定)、ストレージ要素118に配置される監視デバイス108に対するバケットは、初期値を書き込まれない。すなわち、これらは新規に作成されたバケットとなり、したがって、これらの内容は、事実上空となるか、または他の何らかの形で無となり、タイムスタンプおよび/またはバージョン識別子が実装される実施形態では、ストレージ要素118側のバケットのタイムスタンプおよび/またはバージョン識別子も同様にヌルまたは無となり得る。したがって、ストレージ要素118側の関連するバケットに関して、同期化サーバー114は、すでに述べられているように、関連するバケットに対するデバイス識別子のみを監視デバイス108に伝達することができる。しかし、それがその後の接続である場合、ストレージ要素118側のバケットは、初期値として内容、およびいくつかの実施形態における、タイムスタンプおよび/またはバージョン識別子を書き込まれ得る。したがって、その後の接続については、同期化サーバー114は、オペレーション320において、関連するバケットに対するバケット識別子だけでなく、バケットの内容、タイムスタンプ、および/またはバージョン識別子で応答することができる。
オペレーション322も、監視デバイス108と同期化サーバー114との間の接続が初期接続であるか、その後の接続であるかに応じて異なる仕方で実施され得る。それが初期接続である場合、同期化サーバー114側のバケットは、事実上空であるが、監視デバイス108側のバケットは、初期値を書き込まれ得る。監視デバイス108側のバケットは、センサー、ユーザー入力、既定値から、または他の様式で初期値を書き込まれ得る。そのような場合、同期化サーバー114を監視デバイス108と同じ初期状態にするために、監視デバイス108は、関連するバケット(すなわち、オペレーション320で識別されているバケット)の内容を同期化サーバー114に伝達する。タイムスタンプおよび/またはバージョン識別子が使用される実施形態では、この初期状態において、監視デバイス108側のバケットは、タイムスタンプおよび/またはバージョン識別子が、多くの実施形態において、バケットの内容を受信した後、同期化サーバーによって割り当てられるので、タイムスタンプおよび/またはバージョン識別子にまだ関連付けられない。したがって、初期接続時に、オペレーション322において、監視デバイス108側のバケットに関して、監視デバイス108は、バケットの内容(および、例えば、同期化サーバー114側でのバケット識別を円滑にするためのバケット識別子)のみを同期化サーバーに伝達することができる。
一方で、それがその後の通信である場合、監視デバイス108と同期化サーバー114の両方におけるバケットは、内容を有しているべきであり、いくつかの実施形態では、タイムスタンプおよび/またはバージョン識別子も有しているべきである(これらは、例えば、監視デバイスがオフラインである間に同期化サーバーが更新されたか、または監視デバイスが同期化サーバーへの再接続の前に更新された場合には、同一でないことがあるが)。したがって、監視デバイス108は、バケットの内容のすべてを同期化サーバー114に伝達しなくてもよい(いくつかの実施形態では、そうすることもできるが)。むしろ、監視デバイス108は、それが同期化サーバー114側のバケットよりも新しいバケットを有しているかどうかを判定することができ、もしそうならば、より新しいバケットの内容のみを伝達することができる。いくつかの場合において、監視デバイス108がより新しいバケットを有しているとしても、これは、いかなる内容も同期化サーバー114に伝達し得ない。
すべての内容またはより新しい内容のみのいずれかを受信すると、同期化サーバー114は、オペレーション324に示されているように応答を生成し伝達することができる。バケットの内容を受信すると、同期化サーバー114は、いくつかの実施形態では、バケットに対するタイムスタンプを生成し(例えば、タイムスタンプ生成器172を使用して)、かつ/またはバケットに対するバージョン識別子を生成する(例えば、バージョン生成器170を使用して)。次いで、同期化サーバー114は、生成されたタイムスタンプおよび/またはバージョン識別子をバケットに割り当て、それぞれの割り当てられたタイムスタンプおよび/またはバージョン識別子を(タイムスタンプおよび/またはバージョン識別子に関連付けられているバケット識別子に加えて)監視デバイス108に戻す形で伝達することができる。次いで、監視デバイス108は、受信されたタイムスタンプおよび/またはバージョン識別子を、監視デバイス108側のバケットの状態(例えば、監視デバイス108の関連するバケットの内容、タイムスタンプ、およびバージョン識別子)が同期化サーバー114側のバケットの状態(ストレージ要素118側の関連するバケットの内容、タイムスタンプ、およびバージョン識別子)と同じになるように、自バケットに割り当てることができる。
この初期状態同期化が完了した後、監視デバイス108は、同期化サーバー114によりすべての関連するバケットにサブスクライブする。すなわち、監視デバイス108は、同期化サーバー114に、オペレーション326で示されているようにすべての関連するバケットにサブスクライブする要求を伝達することができる。監視デバイス108は、オペレーション320においてそれに与えられる関連するバケットの識別子に基づき、サブスクライブする関連するバケットを識別することができる。関連するバケットにサブスクライブすることによって、監視デバイス108は、同期化サーバー114によって、同期化サーバー114側の関連するバケットへの変更を通知するように要求する。
特定の一実施形態において、サブスクリプション要求は、長いポーリングを使用して実施され得る。すなわち、同期化サーバー114は、関連するバケットのうちの1つへの変更が同期化サーバー114側に加えられるか、または伝達されるまで、またはいくつかの実施形態では、タイムアウト期間に達するまで、サブスクリプション要求を保持する(すなわち、要求に応答しない)ものとしてよい。この様式で、監視デバイス108は、その稼働電力を著しく低減するのによく適しているものとしてよいが、これは、同期化サーバー114との通信(例えば、電力を消費するワイヤレス通信)を定期的に実行する必要がある場合がある(すなわち、サブスクリプション要求を定期的に伝達するだけでよい)からである。タイムアウト期間(および、したがって監視デバイス108が登録サーバー112を通じて再接続プロセスを回避するため新しいサブスクリプション要求を伝達する必要がある期間)は、電力効率と通信信頼性の推定との間のバランスをとるように設定され得る。例えば、タイムアウト期間は、15分、30分、60分、75分、90分、15から90分の範囲内、15分未満、または90分超とすることができる。タイムアウト期間が終了した後、多くの実施形態では、同期化サーバー114は、タイムアウト期間の終了を指示する情報をクライアントデバイス104に伝達する。例えば、同期化サーバー114は、HTTP 200ステータスコードをクライアントデバイス104に送信することができる。いくつかの実施形態では、タイムアウト期間が終了した場合に、クライアントデバイス104は再初期化プロセス(例えば、図10を参照しつつ説明されているような)をその後開始することができるが、他の実施形態では、クライアントデバイス104は、最初に、その関連するバケットに再サブスクライブすることを試み(例えば、オペレーション326で説明されているように)、長いポーリングを維持することができることは理解されるであろう。
いくつかの実施形態では、監視デバイス108は、関連するバケットへの変更の通知を受信することからアンサブスクライブすることを望んでいる場合がある。そうするために、監視デバイス108は、同期化サーバー114への接続を閉じるだけでよい。例えば、本明細書で説明されている技術がHTTP/TCPで実施される実施形態では、監視デバイス108は、同期化サーバー114へのHTTP/TCP接続を閉じるだけでよい。さらに、HTTP/TCPプロトコルが実施される実施形態では、好適なHTTPコマンドが、サブスクリプション要求を円滑にするために使用され得る。例えば、サブスクリプション要求は、「POST/subscribe」などのHTTP POSTコマンドを使用して実施され得る。さらに、いくつかの実施形態では、セッション識別子が実装されるものとしてよく、セッション識別子は、監視デバイス108と同期化サーバー114との間の一意的な通信セッションを識別する。このような実施形態では、監視デバイス108は、セッション識別子を生成し(例えば、セッションID生成器モジュール126を使用して)、セッション識別子をサブスクリプション要求と共に同期化サーバー114に伝達することができる。
図10に図示されている特定のオペレーションは、一実施形態により監視デバイスをリモートサーバーに接続するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図10に例示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図11は、一実施形態によるアクセスデバイスをリモートサーバーに接続するためのプロセスの通信シーケンス400を示す図である。理解しやすくするために、プロセス400は図1から図8を参照しつつ説明されているが、プロセス400の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
バケットの内容の「所有者」である(すなわち、既定でバケットの内容を生成する)監視デバイス108とは対照的に、アクセスデバイス110は、一般的に、監視デバイス108のバケットの内容にアクセスし、いくつかの実施形態では、変更する。しかしながら、監視デバイス108と同様に、アクセスデバイス110も、同期化の準備をする接続プロセスを、次いで、このデバイスがシステム100の他のエンティティと共に定常状態を維持する同期化プロセスを実行する。
起動した後(例えば、アクセスデバイスの電源投入後、ウェブブラウザを開いたとき、ソフトウェアアプリケーションを実行したときなど)、アクセスデバイス110は、オペレーション402に示されているように登録サーバー112とのセキュア接続を確立する。オペレーション402は、オペレーション302と類似しているが、この場合、登録サーバーロケーション128Aは、アクセスデバイス110内に必ずしもハードコーディングされ得ず、むしろ、インストールされているソフトウェアアプリケーションの一部とすることも可能である。セキュア接続を確立した結果として、その後の通信は暗号化され、登録サーバー112の同一性は、アクセスデバイス110に対して認証され得る。この実施形態ではアクセスデバイス110は図9を参照しつつ説明されているように監視デバイス108と同じ登録サーバー112とのセキュア接続を確立するが、他の実施形態では、類似の機能を有する複数の登録サーバーがあり得、アクセスデバイスは1つの登録サーバーを使用し、監視デバイスは1つの異なる登録サーバーを使用する。
次いで、アクセスデバイス110は、オペレーション304と類似している、オペレーション404に示されているように登録要求を登録サーバー112に伝達することができる。しかし、この場合、アクセスデバイス110は、中にハードコーディングされているデバイス識別子を有し得ない。むしろ、いくつかの実施形態では、ユーザーは、ユーザー識別子(例えば、ログイン名)を、その後登録要求の一部として伝達されるデバイス識別子として入力することができる。次いで、登録サーバー112は、層リダイレクション(オペレーション308と類似している、オペレーション406)、ソフトウェア更新(オペレーション310と類似している、オペレーション408)、および割り当てられた同期化サーバーの識別(オペレーション312と類似している、オペレーション410)などのさまざまなオペレーションを実行することができる。多くの実施形態において、アクセスデバイス110は、1つまたは複数の監視デバイス108に関連付けられ得る。例えば、アクセスデバイス110および1つまたは複数の監視デバイス108の両方が同じユーザーアカウントとペアリングされ得る。ペアリングオペレーションを実行するためのさまざまな技術が、上記の米国特許第13/275,311号で説明されている。そのような場合、アクセスデバイス110に割り当てられた同期化サーバーは、関連付けられている監視デバイスに割り当てられた同期化サーバーと同じものとしてよい。
アクセスデバイス110が、割り当てられた同期化サーバーのターゲットロケーションを取得した後、アクセスデバイス110は、割り当てられた同期化サーバーとの通信を確立することができる。一実施形態において、アクセスデバイス110は、オペレーション316と類似している、オペレーション412に示されているように同期化サーバーとのセキュア接続を確立する。しかし、この場合、セキュア接続は、アクセスデバイスに一意的である同期化サーバー114のポートを使用して確立され得る。そのような場合、同期化サーバー114は、接続ポートを介してそれに接続するアクセスデバイスのクラスを識別するように動作可能であるものとしてよい。いくつかの実施形態では、ポートは、特定の種類のアクセスデバイスに対して一意的であるか、またはアクセスデバイス上で実行しているソフトウェアの特定のバージョンに対して一意的であるものとしてよい。そのような場合、同期化サーバー114は、それに接続されているデバイスがアクセスデバイスであるかどうか(監視デバイスまたは他の種類のクライアントデバイスと対比して)だけでなく、アクセスデバイスの種類、アクセスデバイス上で実行しているソフトウェア(例えば、オペレーティングシステム)のバージョンなども識別することができる。
セキュア接続が確立された後、処理はオペレーション414に進むことができ、そこで、アクセスデバイス110は、それに関連するすべてのバケットを要求する。この文脈において関連するバケットは、アクセスデバイス110と1つまたは複数の監視デバイス108などのシステム100の他の要素との間で同期されるべきバケットである。いくつかの実施形態では、ここで関連するバケットは、ペアリングされた監視デバイスに関連しているものと同じであってよい。しかし、他の実施形態では、ここで関連するバケットは、ペアリングされた監視デバイスに関連しているもののサブセットであるものとしてよい。例えば、初期化後、アクセスデバイス110は、例えば、帯域幅の制約により、関連するすべてのバケットを要求し得ない。そのため、アクセスデバイス110は、比較的多数のフィールド-値ペアを有するバケットを要求し得ない。いくつかの場合において、初期化時に要求されないバケットは、その後、要求されてもよい。例えば、アクセスデバイスがタブ付きグラフィカルユーザーインターフェース(GUI)を実装する場合、ユーザーに対して表示される初期タブは、初期化時に要求されるバケットに対するデータを反映することができる。ユーザーが異なるタブに切り替えたときに、アクセスデバイスは、異なるタブの一部として要求されたデータを反映するために必要なバケットに対する要求をサブミットすることができる。
同期化サーバー114が、例えば、関連するバケット識別子166およびデバイス識別子/バケットマップ178Cを使用してアクセスデバイス110に関連するバケットを識別した後、同期化サーバー114は、オペレーション416に示されているように関連するバケットのそれぞれに対するバケットの内容(およびそれらの内容に関連するバケットを識別するためのバケット識別子)をアクセスデバイス110に伝達することができる。タイムスタンプおよび/またはバージョン識別子が使用される実施形態では、これらもアクセスデバイス110に伝達され得る。多くの実施形態において、バケットの内容は、図11に示されているように初期化期間毎に伝達されるが、これは、それらの内容が、アクセスデバイス110が同期化サーバー114との接続を閉じた場合(例えば、アクセスデバイス110の電源が切られた場合、ウェブブラウザのウインドウが閉じられた場合、アプリケーションソフトウェアプロセスが終了した場合など)に消去されるか、または他の何らかの形で無効化され得るからである。しかし、他の実施形態では、バケットの現在の状態(例えば、バケットバージョン)の指示が、バケットの内容の代わりに伝達されることも可能であり、アクセスデバイス110は、同期化サーバー114側に格納されているバケットがアクセスデバイス110側に格納されているバケットよりも新しいかどうかを判定することが可能である。アクセスデバイス110は、その後、アクセスデバイス110側のバケットの内容よりも同期化サーバー114側のバケットの内容の方が新しい場合のみバケットの内容を要求し、受信することができる。
この初期状態同期化が完了した後、アクセスデバイス110は、オペレーション418で示されているように同期化サーバー114によりすべての関連するバケットにサブスクライブする。これは、オペレーション326と類似しているが、この場合、アクセスデバイス110は、関連するすべてのバケットに、または上で説明されているように、関連するバケットのサブセットにサブスクライブすることができる。
図11に図示されている特定のオペレーションは、一実施形態によりアクセスデバイスをリモートサーバーに接続するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図11に示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。例えば、アクセスデバイスは、オペレーション408を参照しつつ説明されているように登録サーバーからソフトウェア更新を受信せず、むしろ、ソフトウェアリポジトリからのユーザーによって始められる、またはオペレーティングシステムによって始められるダウンロードなどによって、他の様式でソフトウェア更新を受信ことができる。別の例では、アクセスデバイスは、層リダイレクション(すなわち、オペレーション406)には関わり得ない。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図12は、一実施形態によるシステムの監視デバイス側に状態の変化が引き起こされたときにシステムのいくつかのエンティティにまたがって状態を同期させるためのプロセスの通信シーケンス500を示す図である。この特定の例では、バケットの状態は、監視デバイス108側で修正され、ストレージ要素118内の対応するバケットの状態と同期され、他の監視デバイスおよび/または1つまたは複数のアクセスデバイスなどの他のクライアントデバイス側の対応するバケットと同期される。理解しやすくするために、プロセス500は図1から図8を参照しつつ説明されているが、プロセス500の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
オペレーション502において、監視デバイス108に関連付けられている別のクライアントデバイス(例えば、アクセスデバイス110)は、同期化サーバー114にサブスクリプション要求を伝達し、この場合、要求は、監視デバイス108で与えられるバケットにサブスクライブする要求である。
オペレーション504において、監視デバイス108は、それがすでにサブスクライブしているバケットへの所望の更新を(ユーザーによって、監視デバイス108に備えられているアルゴリズムによって、など)受信した後、更新することを望んでいるバケットを含むサブスクリプション要求を破棄する。監視デバイス108は、さまざまな様式のうちの1つまたは複数の様式でサブスクリプション要求を破棄することができる。例えば、オペレーション326において、監視デバイス108がそれに関連するバケットにサブスクライブする場合、サブスクリプション要求は、長いポーリングプロセスを介して特定のソケット上で伝達され得る。次いで、監視デバイス108は、その特定のソケットを閉じて、別のソケット上で同期化サーバー114とのさらなる通信を実行することができる。別の例として、監視デバイス108は、要求で識別されたバケット(例えば、関連するバケット)への変更を監視デバイス108に通知するのを停止するように同期化サーバー114に要求するサブスクリプションキャンセル要求を同期化サーバー114に伝達することができる。
サブスクリプション要求が破棄された後、監視デバイス108は、オペレーション506で、その所望のバケット更新を同期化サーバーに伝達する。所望の更新は、新しいバケットの内容および新しい内容に関連付けられているバケットを識別するバケット識別子を含むものとしてよい。いくつかの場合において、監視デバイス108は、タイムスタンプおよび/またはバージョン識別子などの他の情報を、所望の更新と共に含んでいてよい。
所望のバケット更新を受信した後、同期化サーバー114は、オペレーション508で、所望のバケット更新とストレージ要素118側に格納されている対応するバケットとの調整を行う。所望の更新とストレージ要素118側の対応するバケットとの調整を行うことによって、同期化サーバー114は、所望の更新を受け入れるか、または所望の更新を拒絶することができる。所望の更新を受け入れる際に、同期化サーバーは、その更新をストレージ要素118側の対応するバケット内にマージするか、場合によっては、ストレージ要素118側の対応するバケットの内容を所望の更新で完全に上書きすることもできる。同期化サーバー114は、所望の更新を受け入れるかまたは拒絶することができるので、同期化サーバー114側のバケットの結果として得られる内容は、監視デバイス108によって予期されているとおりであり得るか(所望の更新が受け入れられた場合)、または監視デバイス108によって予期されているものと異なることもあり得る(所望の更新が拒絶された場合)。このような調整は、例えば、調整モジュール174を介して実行され得る。
所望の更新が、ストレージ要素118側に格納されている対応するバケットと調整された後、オペレーション510で、同期化サーバーは、監視デバイスのバケットとストレージ要素118側の対応するバケットとの調整を行うための情報を監視デバイス108に伝達する。これは、所望の更新の受け入れを認めるか、または所望の更新の拒絶を示す情報を含み得る。これは、監視デバイス側のバケットに対する新しいタイムスタンプ、新しいバージョン識別子、および場合によっては、新しい内容などの情報も含むか、または代替的に含み得る。
そのような情報を受信すると、オペレーション512において、監視デバイス108は、格納されているバケットとストレージ要素118側の対応するバケットとの調整を行う。例えば、所望の更新が受け入れられた場合、監視デバイスは、新しいタイムスタンプおよび/またはバージョン識別子を受信して、その既存のバケットに適用することができる。しかし、所望の更新が拒絶され、新しいバケットの内容が同期化サーバー114から送信された場合、監視デバイス108は、同期化サーバー114から受信したものでその既存のバケットの内容を上書きし(またはマージし)、同期化サーバー114から受信したときの新しいタイムスタンプおよび/またはバージョン識別子を適用することができる。このような調整は、例えば、調整モジュール124を介して実行され得る。この調整の結果、監視デバイス108側のバケットの状態は、同期化サーバー114側のバケット(すなわち、ストレージ要素118側の対応するバケット)の状態と同一であるべきである。
オペレーション514において、監視デバイス108は、もう一度、オペレーション326と同様に、サブスクリプション要求を同期化サーバーに伝達することができる。しかし、サブスクリプション要求の破棄および再伝達は、純粋にオプションであり、いくつかの実施形態では、そのようなオペレーションは一部または全体を省くことができることは理解されるであろう。
同期化サーバー114が、所望の更新と対応する自バケットとの調整を行った後、同期化サーバー114は、調整情報を監視デバイスだけでなく、ストレージ要素118側のそのバケットにサブスクライブされる他のデバイスにも伝達することができる。例えば、この場合、別のクライアントデバイスが、バケットに対する保留中のサブスクリプション要求を有しているため(オペレーション502の結果として)、同期化サーバーは、オペレーション516において、他のクライアントデバイスのバケットと同期化サーバー114側の対応するバケットとの調整を行うための情報を他のクライアントデバイスに伝達することができる。このような通信は、所望の更新が受け入れられたが省くことができる状況に特によく適しており、同期化サーバー側のバケットの状態は、監視デバイス108から所望の更新を受信したにも拘らず変更されないままである。
調整情報が他のクライアントデバイスに伝達される場合、オペレーション518において、他のクライアントデバイスはその情報を使用して格納されている自バケットと同期化サーバー114側の対応するバケットとの調整を行うことができる。その結果、他のクライアントデバイス側のバケットの状態は、同期化サーバー114側のバケットの状態だけでなく、監視デバイス108側の対応するバケットの状態とも同一であるべきである。
図12に示されている特定のオペレーションは、一実施形態によるシステムの監視デバイス側に状態の変化が引き起こされたときにシステムのいくつかのエンティティにまたがって状態を同期させるための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。特定の一実施形態において、オペレーション516は、オペレーション508の直後、および/またはオペレーション510と同時に実行され得る。さらに、図12に示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図13は、一実施形態によるシステムのアクセスデバイス側に状態の変化が引き起こされたときにシステムのいくつかのエンティティにまたがって状態を同期させるためのプロセスの通信シーケンス600を示している。この特定の例では、バケットの状態は、アクセスデバイス110側で修正され、ストレージ要素118内の対応するバケットの状態と同期され、関連する監視デバイス108側の対応するバケットと同期される。理解しやすくするために、プロセス600は図1から図8を参照しつつ説明されているが、プロセス600の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
オペレーション602において、監視デバイス108は、サブスクリプション要求を同期化サーバー114に伝達し、この場合、要求は、関連するアクセスデバイス110が変更を望んでいるバケットにサブスクライブする要求である。
オペレーション604において、アクセスデバイス110は、監視デバイス108側で与えられ、それがすでにサブスクライブしているバケットへの所望の更新を(例えば、アクセスデバイスのユーザーによって)受信した後、更新することを望んでいるバケットを含むサブスクリプション要求を破棄する。アクセスデバイス110は、図12を参照しつつ説明されているものと同様に、さまざまな様式のうちの1つまたは複数の様式でサブスクリプション要求を破棄することができる。
サブスクリプション要求が破棄された後、アクセスデバイス110は、オペレーション606で、その所望のバケット更新を同期化サーバーに伝達する。所望の更新は、新しいバケットの内容および新しい内容に関連付けられているバケットを識別するバケット識別子を含むものとしてよい。いくつかの場合において、アクセスデバイス110は、タイムスタンプおよび/またはバージョン識別子などの他の情報を、所望の更新と共に含んでいてよい。
所望のバケット更新を受信した後、同期化サーバーは、オペレーション608で、所望のバケット更新とストレージ要素118側に格納されている対応するバケットとの調整を行う。所望の更新とストレージ要素118側の対応するバケットとの調整を行うことによって、同期化サーバー114は、所望の更新を受け入れるか、または所望の更新を拒絶することができ、オペレーション508を参照しつつ説明されているものと同様に、ストレージ要素118側のバケットの内容をマージするか、または置き換えることができる。このような調整は、例えば、調整モジュール174を介して実行され得る。
所望の更新が、ストレージ要素118側に格納されている対応するバケットと調整された後、同期化サーバーは、アクセスデバイスのバケットとストレージ要素118側の対応するバケットとの調整を行うための情報をアクセスデバイス110に伝達する。これは、所望の更新の受け入れを認めるか、または所望の更新の拒絶を示す情報を含み得る。これは、バケットに対する新しいタイムスタンプ、新しいバージョン識別子、および場合によっては、新しい内容などの情報も含むか、または代替的に含み得る。
そのような情報を受信すると、オペレーション612において、アクセスデバイス110は、格納されているバケットとストレージ要素118側の対応するバケットとの調整を行う。例えば、所望の更新が受け入れられた場合、アクセスデバイスは、新しいタイムスタンプおよび/またはバージョン識別子を受信して、その既存のバケットに適用することができる。しかし、所望の更新が拒絶され、新しいバケットの内容が同期化サーバー114から送信された場合、アクセスデバイス110は、同期化サーバー114から受信したものでその既存のバケットの内容を上書きし(またはマージし)、同期化サーバー114から受信したときの新しいタイムスタンプおよび/またはバージョン識別子を適用することができる。このような調整は、例えば、調整モジュール124を介して実行され得る。この調整の結果、アクセスデバイス110側のバケットの状態は、同期化サーバー114側のバケット(すなわち、ストレージ要素118側の対応するバケット)の状態と同一であるべきである。
オペレーション614において、アクセスデバイス110は、もう一度、オペレーション418と同様に、サブスクリプション要求を同期化サーバーに伝達することができる。しかし、サブスクリプション要求の破棄および再伝達は、純粋にオプションであり、いくつかの実施形態では、そのようなオペレーションは一部または全体を省くことができることは理解されるであろう。
同期化サーバー114が、所望の更新と対応する自バケットとの調整を行った後、同期化サーバー114は、調整情報をアクセスデバイスだけでなく、1つまたは複数の監視デバイスを含む、そのバケットにサブスクライブされる他のデバイスにも伝達することができる。例えば、この場合、監視デバイス108が、バケットに対する保留中のサブスクリプション要求を有しているため(オペレーション602の結果として)、同期化サーバーは、オペレーション616において、監視デバイス108のバケットと同期化サーバー114側の対応するバケットとの調整を行うための情報を監視デバイス108に伝達することができる。このような通信は、所望の更新が受け入れられたが省くことができる状況に特によく適しており、同期化サーバー側のバケットの状態は、アクセスデバイス110から所望の更新を受信したにも拘らず変更されないままである。
調整情報が監視デバイス108に伝達される場合、オペレーション618において、監視デバイス108はその情報を使用して格納されている自バケットと同期化サーバー114側の対応するバケットとの調整を行うことができる。その結果、監視デバイス108側のバケットの状態は、同期化サーバー114側のバケットの状態だけでなく、アクセスデバイス110側の対応するバケットの状態とも同一であるべきである。
図13に示されている特定のオペレーションは、一実施形態によるシステムのアクセスデバイス側に状態の変化が引き起こされたときにシステムのいくつかのエンティティにまたがって状態を同期させるための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図13に示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。特定の一実施形態において、オペレーション616は、オペレーション608の直後、および/またはオペレーション610と同時に実行され得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図14は、一実施形態によるシステムの同期化サーバー側に状態の変化が引き起こされたときにシステムのいくつかのエンティティにまたがって状態を同期させるためのプロセスの通信シーケンス700を示している。この特定の例では、バケットの状態は、同期化サーバー102側で修正され、1つまたは複数のクライアントデバイス104側の対応するバケットの状態と同期される。理解しやすくするために、プロセス700は図1から図8を参照しつつ説明されているが、プロセス700の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
オペレーション702において、クライアントデバイス(例えば、1つまたは複数の監視デバイス108および/または1つまたは複数のアクセスデバイス110)は、サブスクリプション要求を同期化サーバー114に伝達し、この要求は、同期化サーバー102側で(例えば、ストレージ要素118内に)与えられるバケットにサブスクライブする要求である。
オペレーション704において、同期化サーバー102は、サブスクライブされたバケットの状態を変更する。例えば、同期化サーバー102は、同期化サーバー102側で実行している1つまたは複数のアルゴリズムに応答してリモートサーバー102側のバケットの内容を変更することができる。
同期化サーバー102側のバケットの状態が変更された後、同期化サーバーは、バケットにサブスクライブされるクライアントデバイス識別することができる。これは、例えば、調整モジュール174を介して実行され得る。次いで、オペレーション706において、同期化サーバー706が、識別されたクライアントデバイスに、クライアントデバイスのバケットとストレージ要素118側の対応するバケットとの調整を行うための情報を伝達する。これは、バケットに対する新しいタイムスタンプ、新しいバージョン識別子、および多くの場合において、新しい内容などの情報を含み得る。
そのような情報を受信すると、オペレーション708において、クライアントデバイス104は、格納されているバケットとストレージ要素118側の対応するバケットとの調整を行う。例えば、クライアントデバイス104は、その既存のバケットの内容を同期化サーバー114から受信した内容で上書きし(またはマージし)、同期化サーバー114から受信したときの新しいタイムスタンプおよび/またはバージョン識別子を適用することができる。このような調整は、例えば、調整モジュール124を介して実行され得る。この調整の結果、クライアントデバイス104側のバケットの状態は、同期化サーバー114側のバケット(すなわち、ストレージ要素118側の対応するバケット)の状態と同一であるべきである。
図14に示されている特定のオペレーションは、一実施形態によるシステムの同期化サーバー側に状態の変化が引き起こされたときにシステムのいくつかのエンティティにまたがって状態を同期させるための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図14に示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図15Aは、一実施形態によりオペレーション308および/または406で説明されているものなどの層リダイレクションを実行するためのプロセスの通信シーケンス800を示している。理解しやすくするために、プロセス800は図1から図8を参照しつつ説明されているが、プロセス800の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
すでに説明されているように、層リダイレクションは、デバイス識別子およびソフトウェアバージョンのうちの1つまたは複数に基づき実行され得る。したがって、オペレーション802において、クライアントデバイス104は、デバイス識別子(例えば、デバイス識別子128B)および/または現在のソフトウェアバージョン(例えば、現在のソフトウェアバージョン128C)を登録サーバーに提供することができる。クライアントデバイス104がシステム100の別のインスタンスにリダイレクトされる必要があると判定すると、オペレーション804において、登録サーバー112は、クライアントデバイス104を二次登録サーバー(すなわち、登録サーバー112の別のインスタンス)にリダイレクトする。例えば、登録サーバー112は、二次登録サーバーのターゲットロケーション(例えば、URI)をクライアントデバイス104に伝達することができる。次いで、クライアントデバイス104は、二次登録サーバーによる初期化プロセス(例えば、図10または図11を参照しつつ説明されているような)を実行することができる。
図15Bは、一実施形態によるクライアントデバイスが層リダイレクションを実行するプロセス810の流れ図である。オペレーション812において、クライアントデバイス104は、デバイス識別子および/またはソフトウェアバージョンを登録サーバーに送信する。オペレーション814において、クライアントデバイス104は、それがリダイレクトを受信したかどうかを判定する。受信しなければ、処理はオペレーション816に進み、クライアントデバイス104は、その初期化プロセスを続ける。受信すれば、処理はオペレーション818に進み、クライアントデバイス104は、二次登録サーバーにより新しい初期化プロセスを開始する。
図15Cは、一実施形態による登録サーバーが層リダイレクションを実行するプロセス820の流れ図である。オペレーション822において、登録サーバー112は、クライアントデバイス104からデバイス識別子および/またはソフトウェアバージョン識別子を受信する。オペレーション824において、登録サーバーは、クライアントデバイス104の層を決定する。例えば、受信されたデバイス識別子はデバイス識別子/層マップ150Dと比較され、かつ/またはソフトウェアバージョン識別子はソフトウェアバージョン/層マップ150Cと比較され得る。層マップは、ソフトウェアバージョンおよび/またはデバイス識別子に基づきクライアントデバイスが属す層を指示し、したがって、クライアントデバイスがシステム100の別のインスタンスにリダイレクトされるべきかどうかを指示し得る。リダイレクトが必要でないと判定された場合、処理はオペレーション828に進み、登録サーバー820は、クライアントデバイス104と共に初期化プロセスを続ける。そうでなければ、処理はオペレーション830に進み、登録サーバー830は、クライアントを二次登録サーバー830にリダイレクトする。いくつかの実施形態では、登録サーバー112を参照しつつ説明されているオペレーションのうちの1つまたは複数は、層リダイレクションモジュール144などの、登録サーバー112内の好適なソフトウェアまたはハードウェアモジュールによって実行され得る。
図15Aから図15Cに示されている特定のオペレーションは、さまざまな実施形態により層リダイレクションを実行するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図15Aから図15Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図16Aは、一実施形態によりオペレーション310および/または408で説明されているものなどのソフトウェア更新を実行するためのプロセスの通信シーケンス900を示している。理解しやすくするために、プロセス900は図1から図8を参照しつつ説明されているが、プロセス900の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
オペレーション902において、登録サーバー112は、適切なソフトウェアバージョンを指示する情報をクライアントデバイス104に提供することができる。適切なソフトウェアバージョンを示す情報は、登録サーバーがクライアントデバイスに実行させたいソフトウェアのバージョンを指示することができる。登録サーバー112も、オペレーション904において、ソフトウェア更新サーバーまたはシステムのターゲットロケーション(例えば、URI)を提供することができ、クライアントデバイス104は、そのソフトウェアを取得することができる。その後、クライアントデバイス104は、ソフトウェア更新を必要とすると判定した場合、オペレーション906において、登録サーバーによって識別されたソフトウェア更新サーバーからソフトウェア更新に対する要求を伝達する。次いで、ソフトウェア更新サーバーは、オペレーション908において、更新されたソフトウェアをクライアントデバイス104に提供することによって応答することができる。
図16Bは、一実施形態によるクライアントデバイスがソフトウェア更新を実行するプロセス910の流れ図である。オペレーション912において、クライアントデバイス104は、登録サーバー112から適切なソフトウェアバージョン902およびソフトウェア更新サーバー904のターゲットロケーションを示す情報を受信する。次いで、クライアントデバイス104は、オペレーション914において、それがソフトウェア更新を必要とするかどうかを判定する。例えば、クライアントデバイスは、現在のソフトウェアバージョン128Cを適切なソフトウェアバージョンを示す受信された情報と比較することができ、それらが同じであれば、クライアントデバイスは、ソフトウェア更新を必要としないと判定し、処理はオペレーション916に進むことができ、そこで初期化プロセスが続けられる。そうでない場合、処理はオペレーション918に進むものとしてよく、クライアントデバイスは、ソフトウェア更新サーバーにソフトウェア更新を要求する。オペレーション920において、クライアントデバイスは、ソフトウェアの更新されたバージョンを受信し、オペレーション922において、更新されたバージョンに基づき現在のソフトウェアを更新する。
図16Cは、一実施形態による登録サーバーがソフトウェア更新を実行するプロセス930の流れ図である。オペレーション932において、登録サーバー112は、クライアントデバイス104に対するデバイス識別子を受信する。処理はオペレーション934に進み、クライアントデバイス104の適切なソフトウェアバージョンが決定される。例えば、登録サーバー112は、受信されたデバイス識別子をデバイスソフトウェアバージョン/アップデータマップ150Bと比較して、クライアントデバイス104に対する適切なソフトウェアバージョンを識別することができる。オペレーション936において、登録サーバー112は、登録サーバー112側に格納され得る、ソフトウェアバージョン/アップデータマップ150B内に含まれ得る、または登録サーバー112によって他の何らかの形でアクセスされ得る、ソフトウェア更新サーバーのターゲットロケーションを決定する。次いで、登録サーバー112は、オペレーション938において、適切なソフトウェアバージョンおよびソフトウェア更新サーバーのターゲットロケーションを示す情報をクライアントデバイス104に伝達することができる。いくつかの実施形態では、登録サーバー112を参照しつつ説明されているオペレーションのうちの1つまたは複数は、ソフトウェア更新モジュール146などの、登録サーバー112内の好適なソフトウェアまたはハードウェアモジュールによって実行され得る。
図16Aから図16Cに示されている特定のオペレーションは、さまざまな実施形態によりソフトウェア更新を実行するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図16Aから図16Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図17Aは、一実施形態によりオペレーション312および/または410で説明されているものなどの割り当てられた同期化サーバーを識別するためのプロセスの通信シーケンス1000を示している。理解しやすくするために、プロセス1000は図1から図8を参照しつつ説明されているが、プロセス1000の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
図10および図11を参照しつつすでに説明されているように、登録サーバー112は、割り当てられた同期化サーバーの同一性(例えば、ターゲットロケーション)を判定し、それを伝達することができる。そうする際に、登録サーバー112は、オペレーション1002において、割り当てられた同期化サーバーの同一性に対する要求を複数の同期化サーバー114Aから114Mのうちの1つに伝達することができる。この特定の例において、この要求は、ランダムに選択されるか、または他の技術を使用して選択され得る、同期化サーバー114Bに伝達される。この要求は、デバイス識別子を含む。次いで、同期化サーバー114Bは、同期化サーバー114Aから114Mのうちのどれがクライアントデバイスに割り当てられるべきかを決定することができる。次いで、オペレーション1004において、同期化サーバー114Bは、割り当てられた同期化サーバー(同期化サーバー114Aから114Mのうちのどれか1つであってよい)の同一性(例えば、URI)を登録サーバー112に伝達することができる。次いで、登録サーバー112が割り当てられた同期化サーバーの同一性をクライアントデバイス108に回送することができる。
図17Bは、一実施形態による登録サーバーが割り当てられた同期化サーバーを識別するプロセス1010の流れ図である。オペレーション1012において、登録サーバーは、要求(割り当てられた同期化サーバーの識別の要求)のサブミット先である同期化サーバー114Aから114Mのうちの1つを識別する。例えば、登録サーバー112は、同期化サーバーを、ランダムに、順次、ロードバランサー(例えば、最小の負荷を有する同期化サーバーに要求を伝達する)を介して、または他の何らかの好適な様式で識別することができる。この特定の例では、登録サーバーは、同期化サーバー114Bを識別した。オペレーション1014において、登録サーバーは、識別された同期化サーバー(この例ではサーバー114B)に、クライアントデバイスに割り当てられた同期化サーバーの識別の要求を送信する。オペレーション1016において、登録サーバー112(例えば、同期化サーバー識別モジュール148)は、同期化サーバーの識別子が受信されたかどうかを判定する。受信されなかった場合、処理はオペレーション1014に戻ることができ、そこで要求が再送される。受信された場合、処理はオペレーション1018に進むものとしてよく、受信された識別子は、クライアントデバイスに伝達される。いくつかの実施形態では、登録サーバー112を参照しつつ説明されているオペレーションのうちの1つまたは複数は、同期化サーバー識別モジュール148などの、登録サーバー112内の好適なソフトウェアまたはハードウェアモジュールによって実行され得る。
図17Cは、一実施形態による同期化サーバーが割り当てられた同期化サーバーを識別するプロセス1020の流れ図である。オペレーション1022において、同期化サーバー(この特定の例では、同期化サーバー114B)は、受信されたデバイス識別子によって識別されたクライアントで媒質に割り当てられた同期化サーバーを識別する要求を受信する。オペレーション1024において、同期化サーバー114Bは、割り当てられた同期化サーバーの同一性を判定する。例えば、同期化サーバー114Bは、そのような判定を実行するコンシステントハッシュ化アルゴリズムを実施することができる。特定の同期化サーバーを識別しやすくするために、それぞれの同期化サーバー114Aから114Mは、システム100内のすべての同期化サーバーを知っているものとしてよい。これは、例えば、同期化サーバー識別子178Aを使用することによって、提供され得る。次いで、同期化サーバー(例えば、同期化サーバー114B)は、コンシステントハッシュ化アルゴリズムおよび同期化サーバー識別子を使用して受信されたデバイス識別子をハッシュ化することができる。割り当てられた同期化サーバーの同一性が判定された後、同期化サーバー114Bは、オペレーション1026において、その同一性を登録サーバー112に伝達することができる。いくつかの実施形態では、同期化サーバー114Bを参照しつつ説明されているオペレーションのうちの1つまたは複数は、クライアントアロケータモジュール164などの、同期化サーバー内の好適なソフトウェアまたはハードウェアモジュールによって実行され得る。
図17Aから図17Cに示されている特定のオペレーションは、さまざまな実施形態により割り当てられた同期化サーバーを識別するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図17Aから図17Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図18Aは、一実施形態によりオペレーション314で説明されているものなどのバケットを作成するためのプロセスの通信シーケンス1100を示している。理解しやすくするために、プロセス1100は図1から図8を参照しつつ説明されているが、プロセス1100の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
図10を参照しつつすでに説明されているように、同期化サーバーは、その監視デバイス108を登録サーバー112に最初に接続した後、監視デバイス108に対する情報のバケットを作成することができる。このプロセスを円滑にするために、オペレーション1102において、登録サーバー112は、同期化サーバー114にクライアントデバイスに対するバケットを作成するように要求する要求を同期化サーバー114に伝達することができる。この要求は、割り当てられた同期化サーバーに送信され得、デバイス識別子を含み得る。それに応答して、同期化サーバー114は、バケットを生成することができ、オペレーション1104において、バケットが作成されたことを認めるアクノリッジメントを登録サーバー112に伝達することができる。
図18Bは、一実施形態による登録サーバーが情報のバケットを作成するプロセス1110の流れ図である。オペレーション1112において、登録サーバー112は、クライアントデバイスに対するバケットを作成する要求を生成する。この要求は、クライアントデバイスから受信されたデバイス識別子を含み得る。オペレーション1114において、登録サーバー112は、この要求を割り当てられた同期化サーバーに伝達する。オペレーション1116において、登録サーバー112は、バケットが作成されたことを認めるアクノリッジメントが受信されたかどうかを判定する。受信されなかった場合、処理はオペレーション1114に戻ることができ、そこで要求が再送される。受信されれば、処理はオペレーション1118に進むことができ、そこで初期化プロセスが続けられる。
図18Cは、一実施形態による同期化サーバーが情報のバケットを作成するプロセス1120の流れ図である。オペレーション1122において、同期化サーバー114は、監視デバイス108などのクライアントデバイスに対するバケットを作成する要求を受信する。オペレーション1124において、同期化サーバーは、監視デバイスに対してどのバケットを作成するかを決定する。例えば、同期化サーバー114は、受信されたデバイス識別子をデバイス識別子/バケットマップ178Cと比較して、そのデバイス識別子に対して作成する適切なバケットを決定することができる。異なる種類のクライアントデバイスは、その使用のために作成されるバケットの異なるセットを有することができる。例えば、サーモスタットでは、温度関係のバケットが作成され得るが、ハザード検出ユニット(例えば、煙検出器)では、煙関係のバケットが作成され得る。オペレーション1126において、同期化サーバー114は、監視デバイスに対するバケットを作成する。オペレーション1128において、同期化サーバー114は、ストレージ要素118内にヌル値のフィールドを有するバケットを格納する。オペレーション1130において、同期化サーバー114は、作成されたバケットをデバイスに関連付け、オペレーション1132において、バケットが正常に作成されたことを認めるアクノリッジメントを登録サーバー112に送信する。いくつかの実施形態では、同期化サーバー114を参照しつつ説明されているオペレーションのうちの1つまたは複数は、バケット生成器モジュール168などの、同期化サーバー114内の好適なソフトウェアまたはハードウェアモジュールによって実行され得る。
図18Aから図18Cに示されている特定のオペレーションは、さまざまな実施形態によりバケットを作成するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図18Aから図18Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図19Aは、一実施形態によりオペレーション318および414で説明されているものなどの関連するバケットを要求するためのプロセスの通信シーケンス1200を示している。理解しやすくするために、プロセス1200は図1から図8を参照しつつ説明されているが、プロセス1200の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
図10および図11を参照しつつすでに説明されているように、クライアントデバイスは、そのデバイスに関連するバケットに関する情報を同期化サーバーに要求し、取得することができる。このプロセスを円滑にするために、オペレーション1202において、クライアントデバイス104は、同期化サーバー114にクライアントデバイス104に関連するすべてのバケットに関する情報を要求する要求を伝達することができる。この要求は、クライアントデバイス104のデバイス識別子を含み得る。それに応答して、オペレーション1204において、同期化サーバー114は、クライアントデバイスに関連するバケットに関する情報を提供することができる。すでに説明されているように、この応答は、関連するバケットに対するバケット識別子、バケットの内容、タイムスタンプ、およびバージョン識別子の一部または全部を含み得る。
図19Bは、一実施形態によるクライアントデバイスがこのデバイスに関連するバケットを要求するプロセス1210の流れ図である。オペレーション1212において、クライアントデバイス104は、関連するバケットに対する要求を生成する。例えば、HTTP通信を使用する実施では、要求は「HTTP GET」コマンドの形態をとり得る。オペレーション1214において、クライアントデバイス104は、この要求を割り当てられた同期化サーバー114に伝達する。オペレーション1216において、クライアントデバイス104は、要求に対する応答が受信されたかどうかを判定する。受信されなければ、処理はオペレーション1214に戻ることができ、クライアントデバイス104は、要求を再送することができる。受信された場合、処理はオペレーション1218に進むものとしてよく、クライアントデバイス104は、その応答を自バケット構造内に組み込む。
応答を組み込むための技術は、デバイスの種類(例えば、監視デバイス、アクセスデバイスなど)、およびデバイスの稼働履歴(例えば、初期接続、その後の接続など)に依存し得る。初期接続を実行する監視デバイスについては、応答はバケット識別子のみを含むことができ、その場合、監視デバイス108は、バケット修正を実行し得ないが、むしろ、受信されたバケット識別子を使用してどのバケットの内容をその後同期化サーバーに伝達するかを決定することができる。その後の接続を実行する監視デバイスについては、応答は、タイムスタンプおよび/またはバージョン識別子と共にバケット識別子を含み得る。このような場合に、バケット識別子は、前の場合と同様に使用され得、受信されたタイムスタンプおよび/またはバージョン識別子は、監視デバイス108側の関連するバケットに関連付けられ得る。アクセスデバイスについては、応答は、バケット識別子、バケットの内容、タイムスタンプ、および/またはバージョン識別子を含み、この場合、アクセスデバイス110は、アクセスデバイス側の識別された関連するバケットのバケット内容を格納し、これにタイムスタンプおよび/またはバージョン識別子を割り当てることができる。
応答が同期化サーバー114から受信され、クライアントデバイス104のバケット構造内に組み込まれた後、処理はオペレーション1220に進むことができ、クライアントデバイス104は、その初期化プロセスを続ける。
図19Cは、一実施形態による同期化サーバーがクライアントデバイスに関連するバケットの要求に応答するプロセス1230の流れ図である。オペレーション1232において、同期化サーバー114は、クライアントデバイス104から関連するバケットに対する要求を受信する。オペレーション1234において、同期化サーバー114は、デバイスの種類(例えば、監視デバイス108、アクセスデバイス110など)、およびデバイスの稼働履歴(例えば、初期接続、再接続など)を決定する。デバイスの種類を決定するために、同期化サーバー114は、同期化サーバー114に接続するためにクライアントデバイス104が使用した接続ポート、デバイス識別子、または他の好適な情報を参照してよい。デバイスの稼働履歴を決定するために、同期化サーバー114は、例えば、クライアントデバイスとの接続の記録を維持することができる。オペレーション1236において、同期化サーバーは、デバイスの種類および/またはデバイスの稼働履歴に基づきクライアントデバイス104に対する関連するバケット識別子および関連付けられている情報(例えば、バケットの内容、タイムスタンプ、バージョン識別子など)を決定する。特定の一実施形態において、同期化サーバー114は、受信されたデバイス識別子をデバイス識別子/バケットマップ178Cと比較して、そのクライアントデバイスに対する関連するバケットを決定することができる。オペレーション1238において、同期化サーバー114は、関連するバケット識別子、および適切な場合に、関連付けられている情報(例えば、バケットの内容、タイムスタンプ、バージョン識別子など)をクライアントデバイス104に伝達する。いくつかの実施形態では、同期化サーバー114を参照しつつ説明されているオペレーションのうちの1つまたは複数は、関連バケット識別子モジュール166などの、同期化サーバー114内の好適なソフトウェアまたはハードウェアモジュールによって実行され得る。
図19Aから図19Cに示されている特定のオペレーションは、さまざまな実施形態によりバケットを要求するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図19Aから図19Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図20Aは、一実施形態によりオペレーション322で説明されているものなどのバケットの内容を送信するためのプロセスの通信シーケンス1300を示している。理解しやすくするために、プロセス1300は図1から図8を参照しつつ説明されているが、プロセス1300の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
図10を参照しつつすでに説明されているように、監視デバイスは、関連するバケットの内容を同期化サーバーに伝達することができる。このプロセスを円滑にするために、オペレーション1302において、監視デバイス108は、関連するバケットの内容を同期化サーバーに伝達し、オペレーション1304において、同期化サーバー114から応答を受信することができる。初期接続において、監視デバイス108は、図20Bおよび図20Cを参照しつつ説明されているようにすべての関連するバケットの内容を伝達することができる。その後の接続において、監視デバイス108は、図20Dおよび図20Eを参照しつつ説明されているように、同期化サーバー側の対応するバケットよりも新しい関連するバケットのみの内容を伝達することができる。
図20Bは、一実施形態による監視デバイスが初期接続時に関連するバケットの内容を同期化サーバーに送信するプロセス1310の流れ図である。オペレーション1312において、監視デバイス108は、その関連するバケットの内容を、同期化サーバーからすでに受信されている関連するバケット識別子に基づき識別する。オペレーション1314において、監視デバイス108は、すべての関連するバケットの内容を(バケット識別子と共に)同期化サーバーに送信する。オペレーション1316において、監視デバイス108は、応答が同期化サーバー114から受信されたかどうかを判定する。受信されなければ、処理はオペレーション1314に戻ることができ、監視デバイス108は、関連するバケットの内容を再送する。受信された場合は、処理はオペレーション1318に進むものとしてよい。この場合、応答がすべての関連するバケットに対するタイムスタンプ、およびバージョン識別子などの情報を含むべきであるため、オペレーション1318において、監視デバイス108は、受信された情報をそれぞれの関連するバケットに関連付ける。
図20Cは、一実施形態による同期化サーバーが初期接続時にバケットの内容を受信すると応答を監視デバイスに送信するプロセス1320の流れ図である。オペレーション1322において、同期化サーバー114は、監視デバイス108からすべての関連するバケットの内容を受信する。オペレーション1324において、同期化サーバー114は、それぞれの関連するバケットに対するタイムスタンプ(例えば、タイムスタンプ生成器172を使用して)および/またはバージョン識別子(例えば、バージョン生成器170を使用して)を生成する。オペレーション1326において、同期化サーバー114は、生成されたタイムスタンプおよび/またはバージョン識別子をそれぞれの関連するバケットに割り当てる。オペレーション1328において、同期化サーバー114は、ストレージ要素118側のそれぞれの関連するバケットに対するバケットの内容、タイムスタンプ、および/またはバージョン識別子を格納する。オペレーション1330において、同期化サーバー114は、それぞれの関連するバケットに対するタイムスタンプおよび/またはバージョン識別子を監視デバイス108に送信する。
図20Dは、一実施形態による監視デバイスがその後の接続時に関連するバケットの内容を同期化サーバーに送信するプロセス1340の流れ図である。オペレーション1342において、監視デバイス108は、その関連するバケットの内容を、同期化サーバー114からすでに受信されている関連するバケット識別子に基づき識別する。オペレーション1344において、監視デバイス108は、そのバケットが同期化サーバー114側の(すなわち、ストレージ要素118側の)対応するバケットよりも新しいかどうかを判定する。特定の一実施形態において、これは、オフラインになっている(リモートサーバー102に接続されていない)ときに監視デバイスがそのバケットへの変更を追跡することによって実行され得る。監視デバイスは再接続した後、オフラインの間に変更されたバケットを同期化サーバー側の対応するバケット「よりも新しい」とみなす。監視デバイス108側のバケットが、同期化サーバー114側のバケットよりも新しくないと判定された場合、処理はオペレーション1346に進むことができ、監視デバイス108は、その初期化プロセスを続ける。新しい場合、処理はオペレーション1348に進むものとしてよく、監視デバイス108は、より新しいバケットのバケット内容(およびバケット識別子)を同期化サーバーに送信する。オペレーション1350において、監視デバイス108は、同期化サーバー114から応答を受信したかどうかを判定する。応答が受信されない場合、処理はオペレーション1348に戻ることができ、監視デバイス108は、バケットの内容を再送する。受信された場合、処理はオペレーション1352に進むものとしてよい。この場合、応答が同期化サーバー114側よりも監視デバイス108側の方が新しかった関連するバケットのみに対するタイムスタンプ、およびバージョン識別子などの情報を含むべきであるため、オペレーション1352において、監視デバイス108は、受信された情報を、監視デバイス108側でより新しかった関連するバケットに関連付ける。
図20Eは、一実施形態による同期化サーバーがその後の接続時にバケットを受信すると応答を監視デバイスに送信するプロセス1360の流れ図である。オペレーション1362において、同期化サーバー114は、同期化サーバー114側のバケットよりも新しい、監視デバイス108側の関連するバケットの内容を受信する。オペレーション1364において、同期化サーバー114は、これらの関連するバケットのそれぞれに対するタイムスタンプ(例えば、タイムスタンプ生成器172を使用して)および/またはバージョン識別子(例えば、バージョン生成器170を使用して)を生成する。オペレーション1366において、同期化サーバー114は、生成されたタイムスタンプおよび/またはバージョン識別子を監視デバイス108側のより新しかった関連するバケットのそれぞれに割り当てる。オペレーション1368において、同期化サーバー114は、ストレージ要素118側の関連するバケットのそれぞれに対するバケットの内容、タイムスタンプ、および/またはバージョン識別子を格納する。オペレーション1370において、同期化サーバー114は、関連するバケットのそれぞれに対するタイムスタンプおよび/またはバージョン識別子を監視デバイス108に送信する。
図20Aから図20Eに示されている特定のオペレーションは、さまざまな実施形態により接続プロセスにおいて監視デバイスからのバケットの内容を同期化サーバーに伝達するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図20Aから図20Eに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図21Aは、一実施形態によりオペレーション326および418で説明されているものなどの関連するバケットにサブスクライブするためのプロセスの通信シーケンス1400を示している。理解しやすくするために、プロセス1400は図1から図8を参照しつつ説明されているが、プロセス1400の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。オペレーション1402において、クライアントデバイス104は、すべての関連するバケットにサブスクライブする要求を伝達し、オペレーション1404において、同期化サーバー114は、応答をサブスクリプション要求に提供する。
図21Bは、一実施形態によるクライアントデバイスが関連するバケットにサブスクライブするプロセス1410の流れ図である。オペレーション1412において、クライアントデバイス104は、それに関連するバケットを識別する。オペレーション1414(セッション識別子を使用する実装に組み込まれ得る)において、クライアントデバイス104は(例えば、セッションID生成器モジュール124を使用して)セッション識別子を生成し、オペレーション1416(例えば、TCPベースの通信を使用する実装に組み込まれ得る)において、クライアントデバイス104は新しい通信ソケットを開く。オペレーション1418において、クライアントデバイス104は、新しい通信ソケットを介して関連するバケットにサブスクライブする要求を同期化サーバー114に伝達する。要求は、関連するバケットのバケット識別子、および監視デバイス108側の関連するバケットのタイムスタンプおよび/またはバージョン識別子などの、さまざまなバケット関係の情報を含み得る。
図21Cは、第1の実施形態による同期化サーバーがサブスクリプション要求を受信するプロセス1420の流れ図である。オペレーション1422において、同期化サーバー114は、クライアントデバイス104から関連するバケットにサブスクライブする要求を受信する。オペレーション1424において、同期化サーバー114は、ストレージ要素118側の関連するバケット(例えば、要求に含まれるバケット識別子を使用して識別される)を、要求を行うクライアントデバイス(例えば、デバイス識別子を使用して識別される)と関連付ける。そのような関連付けを行うことによって、ストレージ要素118側の関連するバケットに変更が加えられたときに、それらの変更は、適切なクライアントデバイスに伝搬され得る。
オペレーション1426(セッション識別子を使用する実装に組み込まれ得る)において、同期化サーバー114は、受信されたセッション識別子を関連するバケットと関連付ける。そのような関連付けを行うことによって、関連するバケットのどれかに対するその後の変更がクライアントデバイスによって要求され、関連するバケットに関連付けられているセッション識別子がその変更要求に含まれるセッション識別子と同一である場合に、同期化サーバーは、さもなければ応答に使用したであろう情報の一部を抑制することによって応答することができる(例えば、ストレージ要素118側の更新されたバケットの新しいタイムスタンプおよび/またはバージョンのみを提供し、バケットの内容全体を提供しない)。セッション識別子の使用は、サブスクリプション要求が破棄されない実施形態において特に有利であるものとしてよいが、これは、セッション識別子を使用することで同期化サーバーからの不要な応答を抑制することができるからである。
いくつかの実施形態では、セッション識別子はデバイス識別子と置き換えることができることは理解されるであろう。例えば、オペレーション1426において、セッション識別子をサブスクリプション要求に関連付ける代わりに、同期化サーバー114は、受信されたデバイス識別子(例えば、割り当てられた資格証明書で受信される)をサブスクリプション要求に関連付けることができる。そのような技術により、同様に、同期化サーバー114はその後クライアントデバイス104からの変更要求への応答を抑制することができる。デバイス識別子の使用は、クライアントデバイス104が当然のことながら一意的なデバイス識別子を有し、これをリモートサーバー102に送信する実施形態において特に有利な場合があるが(例えば、監視デバイス108および割り当てられた資格証明書)、セッション識別子の使用は、クライアントデバイス104が当然のことながらリモートサーバー102に一意的なデバイス識別子を送信し得ない実施形態において特に有利な場合がある(例えば、アクセスデバイス110)。
オペレーション1428(アクノリッジメントが使用される実施形態の場合)において、同期化サーバー114は、サブスクリプション要求が正常に受信され処理されたことを認めるアクノリッジメントをクライアントデバイス104に伝達する。オペレーション1430において、同期化サーバー104は、サブスクライブされたバケットへの変更を待つ。
図21Dは、第2の実施形態による同期化サーバーがサブスクリプション要求を受信するプロセス1440の流れ図である。オペレーション1442から1446は、オペレーション1422から1426と類似しており、したがってこれ以上の説明は省く。しかし、オペレーション1448において、同期化サーバー114は、要求がタイムスタンプおよび/またはバージョン情報を含むかどうかを判定する。含まない場合、処理はオペレーション1450に進み、同期化サーバー114は、バケットの内容、タイムスタンプ、および/またはバージョン識別子をクライアントデバイス104に伝達する。タイムスタンプおよび/またはバージョン識別子は、例えば、オペレーション1324または例えば、オペレーション1364の結果としてすでに生成されていてもよい。次いで、処理はオペレーション1454に進むことができ、同期化サーバーは、サブスクライブされたバケットへの変更を待つ。しかし、オペレーション1448において、要求がタイムスタンプおよび/またはバージョン情報を含むと判定された場合、処理はオペレーション1452に進み、同期化サーバー114は、受信されたタイムスタンプおよび/またはバージョン識別子が関連するバケットに対する同期化サーバー114側に格納されているものと一致しているかどうかを判定する。一致していない場合、処理はオペレーション1450に進む。一致している場合、処理はオペレーション1454に進む。この様式で、同期化サーバー114は、サブスクリプション要求を受信すると、クライアントデバイス104側のバケットの状態と同期化サーバー114側のバケットの状態とが同一であることを保証することができる。
図21Aから図21Dに示されている特定のオペレーションは、さまざまな実施形態によりバケットにサブスクライブするための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図21Aから図21Dに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図22Aは、一実施形態によるクライアントデバイス側のバケットへの変更を同期化サーバー側の対応するバケットと同期させるようにクライアントデバイスを動作させるプロセス1500の流れ図である。いくつかの実施形態では、クライアントデバイス104は、図12を参照しつつ説明されているように所望のバケット更新を伝達する監視デバイス108である。他の実施形態では、クライアントデバイス104は、図13を参照しつつ説明されているように所望のバケット更新を伝達するアクセスデバイスである。理解しやすくするために、プロセス1500は図1から図8を参照しつつ説明されているが、プロセス1500の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
オペレーション1502において、クライアントデバイスは、バケットへの所望の更新を生成する。例えば、ユーザーは、バケットへの所望の変更(温度設定点への所望の変更など)を入力することができる。別の例では、クライアントデバイス側で実行しているアルゴリズムは、バケットへの所望の変更を要求することができる。所望の更新は、典型的には、クライアントデバイス側のバケットの内容への所望の変更であり、したがって、バケットの内容はある状態(例えば、バケットのフィールド-値ペア内のある値)から別の状態(例えば、フィールド-値ペア内の別の異なる値)に変わる。
オペレーション1504において、クライアントデバイスは、その保留中のサブスクリプション要求を破棄する。クライアントデバイスに関連するバケットに対するサブスクリプション要求は、クライアントデバイスが関連するバケットにサブスクライブする初期化プロセスの結果として保留となる(例えば、オペレーション326)。したがって、クライアントデバイスは、すでに説明されている技術を使用してその保留中のサブスクリプション要求を破棄することができる。他の実施形態では、クライアントデバイスは、サブスクリプション要求を保留のままにすることができる。
オペレーション1506において、クライアントデバイスは、所望の更新を(割り当てられた)同期化サーバーに送信する。所望の更新は、新しいバケットの内容および新しい内容に関連付けられているバケットを識別するバケット識別子を含むものとしてよい。いくつかの場合において、クライアントデバイスは、タイムスタンプおよび/またはバージョン識別子などの他の情報を、所望の更新と共に含んでいてよい。HTTPの実装では、所望の更新は、「HTTP PUT」コマンドの形態をとり得る。
オペレーション1508において、クライアントデバイスは、所望の更新に対する応答が受信されたかどうかを判定する。応答が受信されない場合、これは、クライアントデバイスと同期化サーバーとの間の通信における一時的な障害を示すものとしてよく、したがって処理はオペレーション1510に進み得る。
オペレーション1510において、クライアントデバイスは、エラー処理を実行する。エラー処理は、所望の更新を特定の回数だけ再送することを試みることを含み得る。応答がまだ受信されない場合、これは、クライアントデバイスと同期化サーバーとの間の通信における恒久的な障害を示すものとしてよく、この場合、クライアントデバイスは、再初期化のために登録サーバーに再接続することを試みることができる。登録サーバーとの接続試行も失敗した場合、クライアントデバイスは、再接続試行の間の時間を増やす(線形的に、指数関数的に、など)ことを開始する、電力が利用可能であるときのみ再接続試行を実行する、などを行うことができる。他の実施形態では、クライアントデバイスは、所望の更新を再送することを試みることなく登録サーバーとの再接続を試みることができる。
一方で、応答が同期化サーバーから受信されたと判定された場合、処理はオペレーション1512に進む。オペレーション1512において、クライアントデバイスは、その格納されているバケットと同期化サーバー側のバケットとの調整を行う。クライアントデバイスは、同期化サーバーから受信された応答に基づきそのような調整を実行することができ、いくつかの場合において、調整モジュール124を使用して、そのようなオペレーションを実行することができる。このような調整オペレーションの結果、クライアントデバイス側のサブスクライブされたバケットの状態は、同期化サーバー側の対応するバケットの状態と同一であるべきである。バケットの調整を行うための1つの特定の技術は、図22Bを参照しつつ説明されている。
サブスクリプション要求が破棄された実施形態では、処理はオペレーション1514に進むことができ、そこでクライアントデバイスはそれに関連するバケットに再サブスクライブする。これは、例えば、オペレーション326と同様に実行され得る。サブスクリプション要求が破棄されなかった実施形態では、再サブスクリプションオペレーションが回避され得る。
処理はオペレーション1516に進み、クライアントデバイスは、関連する(すなわち、サブスクライブされた)バケットへの変更を待つ。そのような変更は、クライアントデバイス側で、または同期化サーバー、他のクライアントデバイスなどのシステム100の他のエンティティ側で引き起こされ得る。
図22Bは、図22Aを参照しつつ説明されているオペレーション1512を実行するプロセスの流れ図である。すなわち、図22Bは、クライアントデバイス側に格納されているサブスクライブされたバケットと同期化サーバー側の対応するバケットとの調整を行うための特定の一実施形態を示している。
オペレーション1512Aにおいて、クライアントデバイスは、同期化サーバーから新しいバケットタイムスタンプおよび/またはバージョンを受信したかどうかを判定する。受信されない場合、これは、クライアントデバイスと同期化サーバーとの間の通信における一時的な障害を示すものとしてよく、その場合、処理はオペレーション1512Bに進むことができ、クライアントデバイスは、エラー処理を実行する。オペレーション1512Bでエラー処理を実行するステップは、オペレーション1510を参照しつつ説明されているものと類似している。
一方で、新しいバケットタイムスタンプおよび/またはバージョン識別子が同期化サーバーから受信されたと判定された場合、処理はオペレーション1512Cに進むことができ、クライアントデバイスは、その既存のタイムスタンプおよび/またはバージョン識別子を受信されたもので上書きする。例えば、クライアントデバイスがバケットAへの所望の更新を伝達する場合、それに応答して、クライアントは、バケットAに対する新しいタイムスタンプおよび/またはバージョン識別子を受信することができる。次いで、クライアントデバイスは、バケットAに対するその既存のタイムスタンプおよび/またはバージョン識別子を受信されたもので置き換える。
次いで、処理はオペレーション1512Dに進み、クライアントデバイスは、同期化サーバーから新しいバケットの内容を受信したかどうかを判定する。受信しなかった場合、これは、所望の更新が受け入れられたことを示し、その場合、クライアントデバイスは関連するバケットへの再サブスクライブに進むか、または関連するバケットへのさらなる変更を待つことができる(例えば、オペレーション1516)。
しかし、クライアントデバイスが、同期化サーバーから新しいバケットの内容を受信したと判定した場合、これは、更新が拒絶されたこと、クライアントデバイスによって予期されていない値を含んでいた同期化サーバー側のバケットへの更新が受け入れられたこと、または更新が受け入れられており、同期化サーバーは、バケットの内容を、それらがクライアントデバイスによって予期されているとおりであったとしてもクライアントデバイスに伝達していることを示すものとしてよい。いずれの場合も、処理はオペレーション1512Eに進み、クライアントデバイスは、そのバケットの既存の内容を、同期化サーバーから受信されたもので上書きする。いくつかの実施形態では、そのバケットの既存の内容を上書きする代わりに、クライアントデバイスは、受信された内容をそのバケット内にすでに格納されているものとマージすることができる。
図22Aおよび図22Bに示されている特定のオペレーションは、一実施形態によるクライアントデバイス側のバケットへの変更を同期化サーバー側の対応するバケットと同期させるようにクライアントデバイスを動作させる特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図22Aおよび図22Bに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図23Aは、一実施形態によるクライアントデバイスによって要求されたバケットへの変更を同期化サーバー側の対応するバケットおよび他のクライアントデバイス側の対応するバケットと同期させるように同期化サーバーを動作させるプロセス1600の流れ図である。理解しやすくするために、プロセス1600は図1から図8を参照しつつ説明されているが、プロセス1600の実施形態は、図1から図8を参照しつつ説明されている例示的なシステムおよび装置に限定されないことは理解されるであろう。
オペレーション1602において、同期化サーバーは、クライアントデバイスからバケットへの所望の更新を受信する。所望のバケット更新は、監視デバイス108から受信されるか(図12を参照しつつ説明されているように)、アクセスデバイス110から受信されるか(図13を参照しつつ説明されているように)、または同期化サーバーによって生成され得る(図14を参照しつつ説明されているように)。
所望の更新を受信した後、処理はオペレーション1604に進み、同期化サーバーは、所望のバケット更新とストレージ要素118側に格納されている対応するバケットとの調整を行う。所望の更新とストレージ要素118側の対応するバケットとの調整を行うことによって、同期化サーバー114は、所望の更新を受け入れるか、または所望の更新を拒絶することができる。バケットの調整を行うための1つの特定の技術は、図23Bを参照しつつ説明されている。このような処理は、例えば、調整モジュール174を介して実行され得る。
所望の更新が同期化サーバー側の対応するバケットと調整された後、処理はオペレーション1606に進み、同期化サーバーは、クライアントデバイスと同期化サーバーとの調整を行うための情報を送信する。これは、所望の更新の受け入れを認めるか、または所望の更新の拒絶を示す情報を含み得る。クライアントデバイスと同期化サーバーとの調整を行う情報を送信するための1つの特定の技術について、図23Cを参照しつつ説明されている。このような処理は、例えば、調整モジュール174を介して実行され得る。
オペレーション1608において、同期化サーバーは、任意の他のクライアントデバイスがバケットにサブスクライブされているかどうかを判定する。任意の他のクライアントデバイスがバケットにサブスクライブされているかどうかを判定する際に、同期化サーバーは、バケットに対して保留中のサブスクリプション要求があるかどうかを判定することができる。もしあれば、同期化サーバーは、保留中のサブスクリプション要求を発行したクライアントデバイスを識別することができる。
バケットにサブスクライブされている他のクライアントデバイスがないと判定された場合、処理はオペレーション1614に進むことができ、同期化サーバーは、サブスクライブされたバケットへの変更を待つ。これは、同期化サーバー側で行われた変更、およびクライアントデバイスから伝達された変更要求などを含み得る。
一方で、少なくとも1つの他のクライアントデバイスがバケットにサブスクライブされていると判定された場合、処理はオペレーション1610に進む。オペレーション1610において、同期化サーバーは、同期化サーバー側のバケットの構造が調整オペレーション1604の結果として変更されたかどうかを判定する。バケットの構造を変更することによって、内容、タイムスタンプ、および/またはバージョン識別子のうちの1つまたは複数が変更されている可能性がある。
バケットの構造が変化しなかったと判定された場合、これは、同期化サーバーが所望の更新を拒絶したことを示しているものとしてよく、したがって、変更を他のサブスクライブされているクライアントデバイスに伝達する必要はない。そこで、処理はオペレーション1614に進むものとしてよい。一方で、バケット構造が変化したと判定された場合、これは、同期化サーバーが、少なくとも一部は、所望の更新を受け入れたことを示しているものとしてよい。したがって、同期化サーバー側のバケットの新しい状態は、すべてのサブスクライブされているデバイスが同じ状態の対応するバケットを有するように他のサブスクライブされているデバイスに伝達されるべきである。そこで、処理はオペレーション1612に進むことができ、同期化サーバーは、他のデバイスのバケット(すなわち、サブスクライブされているクライアントデバイス側の対応するバケット)と更新された同期化サーバーのバケットとの調整を行うための情報を送信する。特定の一実施形態において、オペレーション1612は、図23Cに示され、オペレーション1606を参照しつつ説明されているものと類似するさまざまなサブオペレーションを含み得る。
図23Bは、図23Aを参照しつつ説明されているオペレーション1604を実行するプロセスの流れ図である。すなわち、図23Bは、クライアントデバイスから受信された所望のバケット更新と同期化サーバー側の1つまたは複数の対応するバケットとの調整を行うための特定の一実施形態を示している。
オペレーション1604Aにおいて、同期化サーバーは、新しいタイムスタンプおよびバージョン識別子を受信されたバケットに割り当てる。これは、例えば、最初に、タイムスタンプ生成器172を使用して、更新要求が受信された時刻を示すタイムスタンプを生成し、バージョン生成器170を使用して新しい一意的なバージョン識別子を生成することによって行える。新しく生成されたタイムスタンプおよびバージョン識別子は、その後の使用のために受信されたバケットに割り当てられ得る。
新しいタイムスタンプおよびバージョン識別子が割り当てられた後、処理はオペレーション1604Bに進む。オペレーション1604Bにおいて、同期化サーバーは、要求された更新が要求された更新に対応する同期化サーバー側のバケットよりも新しいかどうかを判定する。例えば、同期化サーバーは、新しく割り当てられたタイムスタンプを同期化サーバー側の対応するバケットの格納されているタイムスタンプと比較することができる。新しく割り当てられたタイムスタンプが、対応するバケットの格納されているタイムスタンプより新しい場合(ほとんどの場合、そうであるべきである)、処理はオペレーション1604Cに進む。
オペレーション1604Cにおいて、同期化サーバーは、同期化サーバー側の対応するバケットがクライアントデバイスによって予期されているものと同一である(すなわち、同じ状態である)かどうかを判定する。すなわち、クライアントデバイスは、同期化サーバー側の対応するバケットの内容がクライアントデバイス側の対応するバケットの内容と同一になることを予期し、所望の更新はクライアントデバイス側のバケットの状態への所望の変更である。一実施形態において、そのような判定を行うために、同期化サーバーは、クライアントデバイスから受信されたバージョン識別子を同期化サーバー側に格納されている対応するバケットに対するバージョン識別子と比較することができる。それらが同一であれば、同期化サーバーは、同期化サーバー側のバケットがクライアントによって予期されているものと同一であると判定する。そのような場合、処理はオペレーション1604Dに進むことができる。
オペレーション1604Dにおいて、同期化サーバーは、所望の更新におけるバケットの内容を同期化サーバー側の対応するバケットの内容とマージする。この様式で、同期化サーバー側のバケットの内容は、クライアントデバイス側の対応するバケットのものと同一にされる。いくつかの実施形態では、マージする代わりに、同期化サーバーは、同期化サーバー側の対応するバケットのすべての内容を所望の更新におけるバケットの内容で上書きし得ることは理解されるであろう。
オペレーション1604Cを再び参照すると、同期化サーバーが、同期化サーバー側の対応するバケットがクライアントデバイスによって予期されているものと同一でない(例えば、バケットのバージョン識別子が異なる)と判定した場合、同期化サーバーは、(それにもかかわらず)所望の更新を受け入れるか、または更新を拒絶するかを決定することができる。多くの実施形態において、同期化サーバーは、既定により一方または他方を実行するように構成され得る。例えば、処理は、オペレーション1604Cからオペレーション1604Dまたはオペレーション1604Fに進み得る。しかし、いくつかの実施形態では、クライアントデバイスは、同期化サーバーがそのような状況で更新を受け入れるべきかどうかを示し得る。そうするために、クライアントデバイスは、楽観的同時並行性フラグを更新要求と共に同期化サーバーに伝達することができる。楽観的同時並行性フラグがセットされた場合、さもなければクライアントデバイスが、同期化サーバー側の対応するバケットがクライアントデバイスによって予期されているものと同一でない場合に更新を受け入れさせたくないことを示す場合に、処理はオペレーション1604Fに進むことができ、そこで、同期化サーバーは、所望の更新をその対応するバケットとマージすることを拒絶するか、さもなければ所望の更新を受け入れることを拒絶する。対照的に、楽観的同時並行性フラグがセットされていない場合、さもなければクライアントデバイスが、同期化サーバー側の対応するバケットがクライアントデバイスによって予期されているものと同一でない場合であっても更新を受け入れさせたいことを示す場合に、処理はオペレーション1604Dに進むことができる。この特定の例では、同期化サーバーの既定のオペレーションは、同期化サーバー側の対応するバケットがクライアントデバイスによって予期されているものと同一でない場合であっても所望の更新をマージする。楽観的同時並行性フラグは、こうして、この既定の運用性をオーバーライドするように動作する。
オペレーション1604Bを再び参照すると、いくつかの場合において、同期化サーバーは、要求された更新が要求された更新に対応する同期化サーバー側のバケットよりも新しくないと判定し得る。これは、例えば、オペレーション1604Bの前、ただしオペレーション1604Aの後に、別のクライアントデバイスが変更を要求し、タイムスタンプ(オペレーション1604Aで発行されたものより新しいか、または同じである)を割り当てられた場合に生じるものとしてよく、他のクライアントデバイスに対する要求された変更が受け入れられる(他のクライアントデバイスに対するタイムスタンプが同期化サーバー側に格納されるように)。その結果、オペレーション1604Aで発行されたタイムスタンプは、同期化サーバー側に格納されているものよりも新しくなく、その場合、処理はオペレーション1604Gに進み得る。
オペレーション1604Gにおいて、同期化サーバーは、要求された更新が要求された更新に対応する同期化サーバー側のバケットよりも古いかどうかを判定する。ここでもまた、これは、タイムスタンプ同士を比較することによって実行され得る。要求された更新が要求された更新に対応する同期化サーバー側のバケットよりも古い場合、これは、同期化サーバーが更新を要求するクライアントデバイス側のものよりも新しいバケットを有することを示すものとしてよい。この特定の実施形態では、そのような場合、処理はオペレーション1604Fに進み、そこで、要求された更新は拒絶される。
一方で、オペレーション1604Gにおいて、同期化サーバーは、要求された更新が要求された更新に対応する同期化サーバー側のバケットよりも古くないと判定し得る。この場合、要求された更新は、同期化サーバー側のバケットと「同じ年齢」である。例えば、バケットは、同一のスタンプを有していてもよい。この状況において、処理はオペレーション1604Hに進むことができる。
オペレーション1604Hにおいて、同期化サーバーは、所望のバケット更新を同期化サーバー側の対応するバケットとランダムにマージする。これは、多数の異なる様式で実装され得る。例えば、同期化サーバーは、更新を要求するクライアントデバイス側のバケットのバージョン識別子(例えば、バージョン識別子は更新の一部として送信され得る)、および同期化サーバー側の対応するバケットのバージョン識別子に注目することができる。所定のバケットに対するバージョン識別子は、常に一意的であるため、バージョン番号は異なるものになる。次いで、同期化サーバーは、バージョン識別子を比較することによってマージするかマージしないかを任意に選択することができる。例えば、同期化サーバーは、クライアントデバイスのバケットのバージョン識別子が同期化サーバー側の対応するバケットのバージョン識別子の数値よりも高い数値であるときのみ要求された更新を同期化サーバー側の対応するバケットとマージすることを選択することができる。別の例では、同期化サーバーは、クライアントデバイスのバケットのバージョン識別子が同期化サーバー側の対応するバケットのバージョン識別子の数値よりも低い数値であるときのみ要求された更新を同期化サーバー側の対応するバケットとマージすることを選択することができる。同期化サーバーは所望の更新を対応するバケットと「ランダムに」マージするが、多くの実施形態では、同じマージアルゴリズムが同期化サーバー114Aから114Mのすべてによって使用されることは理解されるであろう。この様式で、システム100は、有利に結果整合性を達成することができる。
図23Cは、図23Aを参照しつつ説明されているオペレーション1606を実行するプロセスの流れ図である。すなわち、図23Cは、クライアントデバイスと同期化サーバーとの調整を行う情報を送信するための特定の一実施形態を示している。
オペレーション1606Aにおいて、同期化サーバーは、クライアントデバイスから伝達される所望のバケット更新が受け入れられているかどうかを判定する。所望のバケット更新が受け入れられていない場合、例えば、同期化サーバーが所望の更新を同期化サーバー側の対応するバケットとマージすることを拒絶することを決定した場合(オペレーション1604Fなどにおいて)、これは、同期化サーバー側のバケットの状態がクライアントデバイスによって予期されているものと異なることを示すものとしてよい。したがって、処理はオペレーション1606Bに進むことができ、同期化サーバーは、その既存のバケットの内容、タイムスタンプ、および/またはバージョン識別子(すなわち、更新要求内のバケットに対応する同期化サーバー側のバケットのもの)をクライアントデバイスに伝達する。そうでない場合、処理はオペレーション1606Cに進むものとしてよい。
オペレーション1606Cにおいて、同期化サーバーは、そのバケットがクライアントデバイスによって予期されているものと同一であるかどうかを判定する。そのような判定を行うために、同期化サーバーは、要求に含まれるバージョン識別子を同期化サーバー側の対応するバケットのバージョン識別子と比較することができる。これらが同じである場合、同期化サーバーは、そのバケットがクライアントデバイスによって予期されているものと同一であると判定することができる。そうでない場合、同期化サーバーは、そのバケットがクライアントデバイスによって予期されているものと同一でないと判定することができる。
同期化サーバーがそのバケットがクライアントデバイスによって予期されているものと同一でないと判定した場合、処理はオペレーション1606Dに進むことができ、同期化サーバーは、マージされたバケットの内容および新しいタイムスタンプおよび/またはバージョン識別子(例えば、オペレーション1604Aで生成されたもの)をクライアントデバイスに伝達する。これは、所望の更新が、同期化サーバー側のバケットがクライアントデバイスによって予期されているとおりでないとしても同期化サーバーによって受け入れられる状況に対して有用な場合がある。そのような場合、クライアントデバイスのバケットが同期化サーバーの対応するバケットと同じ状態にあることを保証するために、バケットの内容全体がクライアントデバイスに伝達され得る。
一方で、同期化サーバーがそのバケットがクライアントデバイスによって予期されているものと同一であると判定した場合、処理はオペレーション1606Eに進むことができ、同期化サーバーは、新しいタイムスタンプおよびバージョン識別子(例えば、オペレーション1604Aで生成されたもの)のみをクライアントデバイスに伝達する。この場合、マージされたバケットの内容は、それらの内容がすでに同一であるため、クライアントデバイスに伝達される必要はない。もちろん、いくつかの実施形態において、同期化サーバーは、それにもかかわらず、マージされたバケットの内容をクライアントデバイスに送信することもできる。
図23Aから図23Cに示されている特定のオペレーションは、一実施形態によるクライアントデバイスによって要求されたバケットへの変更を同期化サーバー側の対応するバケットおよび他のクライアントデバイス側の対応するバケットと同期させるように同期化サーバーを動作させる特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図23Aから図23Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図24Aから図26Cは、クライアントデバイスおよびリモートサーバーの対応するバケットの状態を、クライアントデバイスが所望の更新をリモートサーバーに伝達すると同期するさまざまな例を示している。特に、図24Aおよび図24Bは、クライアントデバイス104がリモートサーバー102側のバケット1702よりも古いバケット1700を有し、クライアントデバイス104がそのバケットを変更することを試みるが、その変更は、クライアントデバイス104がリモートサーバー102側のより新しいバケットを認識していないためリモートサーバー102によって拒絶される状況を示している。特に、図24Aに示されているように、クライアントデバイス104は、内容AおよびB、バージョンv1、ならびにタイムスタンプt1を有するバケットB1を格納する。クライアントデバイス104は、AをA'に変更する。要求された変更1704は、リモートサーバー102に送信され、バケット識別子B1、バージョン識別子v1、および所望の変更A'を含む。受信後、リモートサーバー102は、B1に対する新しいタイムスタンプt3およびバージョンv3を生成する(そもそも割り当てないが)。図24Bに示されているように、リモートサーバーの既存バケットB1はデータAおよびB'、バージョンv2、ならびにタイムスタンプt2を有し、t2はt3よりも新しい。t2は、t3よりも新しいので、リモートサーバー102は、クライアントデバイス104によって送信されるものよりも新しいバケットB1を有する。この場合、リモートサーバー102は、提案された変更を拒絶し、その自バケットの状態(B1、AおよびB'、v2、t2)を定義するバケット1706をクライアントデバイス104に送信し、t3およびv3を破棄する。クライアントデバイス104は、そのバケットB1をリモートサーバー102から受信されたものと置き換え、したがって、バケットB1は状態をバケット1708からバケット1710に変更する。
図25Aから図25Dは、クライアントデバイス104がリモートサーバー102側に格納されているものよりも新しいバケット(すなわち、クライアントデバイス104によって受信された提案変更に割り当てられたタイムスタンプがリモートサーバー102によって格納されている対応するバケットのタイムスタンプよりも新しい)を送信し、リモートサーバー102側に格納されているバケットがクライアントデバイス104によって予期されているとおりであるか、または異なるものとしてよい状況を示している。
図25Aおよび図25Bは、リモートサーバーのバケットがクライアントデバイス104によって予期されているとおりである状況を示している。この場合、クライアントデバイス104がそのバケットを変更しようと試みたときに、リモートサーバー102は、その変更を既存のバケットとマージし、クライアントデバイス104に対してマージの成功を認める。特に、図25Aに示されているように、クライアントデバイス104は、バケット識別子B1、内容AおよびB、バージョンv1、ならびにタイムスタンプt1を有するバケット1712を格納する。クライアントデバイス104は、AをA'に変更する。要求された変更は、バケット1714でリモートサーバー102に送信され、B1、v1、およびA'を含む。受信後、リモートサーバー102は、B1に対する新しいタイムスタンプt2およびバージョンv2を生成する。図25Bに示されているように、バケット識別子B1を有するリモートサーバーの既存のバケット1716は、クライアントデバイス104側のバケットと同一である。リモートサーバーのバケットB1のバージョンv1は、クライアントデバイスのバケットB1のバージョンv1と同じなので、リモートサーバーのB1は、クライアントデバイス104によって予期されたとおりである。また、タイムスタンプt2はt1よりも新しいので、クライアントデバイスの要求された変更は、リモートサーバーの格納されているバケットよりも新しい。この場合、リモートサーバー102は、A'をB1にマージし、新しいタイムスタンプt2およびバージョンv2をB1に割り当て、新しいバケット1718を格納することによって提案された変更を受け入れる。次いで、リモートサーバー102は、バケット1720について、識別子B1、v2、およびt2のみをクライアントデバイス104に送信する。クライアントデバイス104は、AをA'で置き換え、その古いバージョン/タイムスタンプv1/t1をリモートサーバー102によって送信されたもの(すなわち、v2/t2)で置き換えるので、そのバケットB1は状態をバケット1722からバケット1724に変更する。
図25Aおよび図25Cは、リモートサーバーのバケットがクライアントデバイス104によって予期されているものと異なる状況を示している。この場合、クライアントデバイス104がそのバケットを変更しようと試みたときに、リモートサーバー102は、その変更を既存のバケットとマージし、また、リモートサーバーのバケット(場合によっては、結果として得られるマージされたバケット)の内容がクライアントデバイス104によって予期されているものと異なっていたため、クライアントデバイス104に対してマージの成功を認めることに加えてマージされたバケットの内容をクライアントデバイス104に送信もする。特に、図25Aに示されているように、クライアントデバイス104は、バケット識別子B1、内容AおよびB、バージョンv1、ならびにタイムスタンプt1を有するバケット1712を格納する。クライアントデバイス104は、AをA'に変更する。要求された変更は、リモートサーバー102に送信され、B1、v1、およびA'を含む。受信後、リモートサーバー102は、B1に対する新しいタイムスタンプt3およびバージョンv3を生成する。図25Cに示されているように、バケット識別子B1を有するリモートサーバーの既存のバケット1726は、クライアントデバイスのものと異なり、内容AおよびB'、タイムスタンプt2、ならびにバージョンv2を有する。v2はv1と異なるので、リモートサーバーのB1はクライアントデバイスのB1と異なる。また、タイムスタンプt3はt2よりも新しいので、クライアントデバイスの要求された変更は、リモートサーバーの格納されているバケットよりも新しい。しかしながら、この場合、リモートサーバー102は、ここでもまた、A'をB1にマージし、新しいタイムスタンプt3およびバージョンv3をB1に割り当て、新しいバケット1728を格納することによって提案された変更を受け入れる。前の例とは対照的に、バケット識別子、タイムスタンプ、およびバージョンのみを送信する代わりに、この場合は、リモートサーバー102は、バケット1730について、内容A'およびB'もクライアントデバイス104に送信する。クライアントデバイス104は、そのバケットB1の内容全体をリモートサーバー102から受信されたもので置き換え、また受信されたタイムスタンプt3およびバージョンv3を使用し、したがって、そのバケットB1は状態をバケット1732からバケット1734に変更する。
図25Aおよび図25Dは、リモートサーバーのバケットがクライアントデバイス104によって予期されているものと異なるが、楽観的同時並行性フラグ(すなわち、オーバーライドフラグ)がセットされている状況を示している。楽観的同時並行性フラグをセットすることによって、リモートサーバー102は、リモートサーバーのバケットがクライアントデバイスのものと同じバージョンを有しない場合に、要求された変更(マージ、上書き、または他の何らかの操作による)を受け入れることを拒絶する。これは、いくつかの状況において、要求された変更を未知のデータとマージすると、望ましくない、または予測不可能な結果が生じ得るからである。特に、図25Aに示されているように、クライアントデバイス104は、バケット識別子B1、内容AおよびB、バージョンv1、ならびにタイムスタンプt1を有するバケット1712を格納する。クライアントデバイス104は、AをA'に変更する。要求された変更は、リモートサーバー102に送信され、B1、v1、およびA'を含む。受信後、リモートサーバー102は、B1に対する新しいタイムスタンプt3およびバージョンv3を生成する。図25Dに示されているように、バケット識別子B1を有するリモートサーバーの既存のバケット1736は、クライアントデバイスのものと異なり、内容AおよびB'、タイムスタンプt2、ならびにバージョンv2を有する。v2はv1と異なるので、リモートサーバーのB1はクライアントデバイスのB1と異なる。また、タイムスタンプt3はt2よりも新しいので、クライアントデバイスの要求された変更は、リモートサーバーの格納されているバケットよりも新しい。しかし、リモートサーバー102が要求された変更をマージした前の例とは対照的に、楽観的同時並行性フラグがセットされているので、リモートサーバー102は、ここで、提案された変更を受け入れることを拒絶する。その代わりに、リモートサーバー102は、B1の既存のバージョンを維持し、バケット1738で、B1のコピー(識別子B1、内容AおよびB'、バージョンv2、ならびにタイムスタンプt2を含む)をクライアントデバイス104に送信する。次いで、クライアントデバイス104は、そのバケットB1の内容全体をリモートサーバー102から受信されたもので置き換え、また受信され
たタイムスタンプt2およびバージョンv2を使用し、したがって、そのバケットB1は状態をバケット1740からバケット1742に変更する。
図26Aから図26Cは、クライアントデバイス104がバケットを、リモートサーバー102が同じバケットへの変更を生成するかまたは(別のデバイスから)受信したときと全く同じときに送信する状況を示している。したがって、リモートサーバー102側のバケットのタイムスタンプとクライアントデバイス104から受信されたバケットのタイムスタンプは同一であるが、バージョンは、ランダムに生成されるので異なる。バケットの内容は、異なっていてもよい。この場合、バケットの内容を変更するクライアントデバイスの要求に応答して、リモートサーバー102は、変更要求を拒絶するか、または変更要求を受け入れるかを決定しなければならない。実施形態において、リモートサーバー102は、最大のバージョン番号を有するバケットが「勝つ」というルールを備えるアルゴリズムを実施する。バージョン番号はランダムに生成されるので、内容の変更が受け入れられるかどうかも、ランダムに決定される。
図26Aおよび図26Bは、リモートサーバーのバケットタイムスタンプがクライアントデバイスの要求された変更の割り当てられたタイムスタンプと同一であり、リモートサーバーのバケットバージョンが、リモートサーバー102が「勝つ」ようにクライアントデバイスのバケットバージョンよりも大きい状況を示している。この場合、クライアントデバイス104がバケットを変更しようと試みるときに、リモートサーバー102は、その変更を拒絶し、その代わりに、バケットをクライアントデバイス104に送信する。特に、図26Aに示されているように、クライアントデバイス104は、バケット識別子B1、内容AおよびB、バージョンv1、ならびにタイムスタンプt1を有するバケット1744を格納する。クライアントデバイス104は、AをA'に変更する。要求された変更1746は、リモートサーバー102に送信され、B1、v1、およびA'を含む。受信後、リモートサーバー102は、B1に対する新しいタイムスタンプt2およびバージョンv3を生成する。図26Bに示されているように、バケット識別子B1を有するリモートサーバーの既存のバケット1748は、クライアントデバイスの要求された変更の新しく割り当てられたタイムスタンプt2に等しいタイムスタンプt2を有する。タイムスタンプは同じなので、リモートサーバー102は、「勝利者」を選択しなければならない。この例では、リモートサーバーのバケットバージョンv2は、クライアントデバイスのバケットバージョンv1より大きく、したがって、リモートサーバー102が「勝つ」。その結果、リモートサーバー102は、提案された変更を拒絶し、その代わりに、バケット識別子B1、内容AおよびB'、バージョンv2、およびタイムスタンプt2を含むバケット1750を送り返す。次いで、クライアントデバイス104は、そのバケットB1の内容全体をリモートサーバー102から受信されたもので置き換え、また受信されたタイムスタンプt2およびバージョンv2を使用し、したがって、そのバケットB1は状態をバケット1752からバケット1754に変更する。
図26Aおよび図26Cは、リモートサーバーのバケットタイムスタンプがクライアントデバイスの要求された変更の割り当てられたタイムスタンプと同一であり、リモートサーバーのバケットバージョンが、クライアントデバイス104が「勝つ」ようにクライアントデバイスのバケットバージョンよりも小さい状況を示している。この場合、クライアントデバイス104がバケットを変更しようと試みるときに、リモートサーバー102は、その変更を受け入れ、変更を既存のバケットにマージし、その結果得られるマージされたバケットをクライアントデバイス104に送信する。特に、図26Aに示されているように、クライアントデバイス104は、バケット識別子B1、内容AおよびB、バージョンv1、ならびにタイムスタンプt1を有するバケット1744を格納する。クライアントデバイス104は、AをA'に変更する。要求された変更は、リモートサーバー102に送信され、B1、v1、およびA'を含む。受信後、リモートサーバー102は、B1に対する新しいタイムスタンプt2およびバージョンv3を生成する。図26Cに示されているように、バケット識別子B1を有するリモートサーバーの既存のバケット1756は、クライアントデバイスの要求された変更の新しく割り当てられたタイムスタンプt2に等しいタイムスタンプt2を有する。タイムスタンプは同じなので、リモートサーバー102は、「勝利者」を選択しなければならない。この例では、リモートサーバーのバケットバージョンv2は、クライアントデバイスのバケットバージョンv1より小さく、したがって、クライアントデバイス104が「勝つ」。その結果、リモートサーバー102は、提案された変更を受け入れ、バケットB1が状態をバケット1756からバケット1758に変更するように変更をB1にマージし、v3をB1に割り当てる。次いで、リモートサーバー102は、マージされたバケット1760(識別子B1、バケットの内容AおよびB'、バージョンv3、およびタイムスタンプt2を含む)をクライアントデバイス104に送り返す。次いで、クライアントデバイス104は、そのバケットB1の内容全体をリモートサーバー102から受信されたもので置き換え、また受信されたタイムスタンプt2およびバージョンv3を使用し、したがって、そのバケットB1は状態をバケット1762からバケット1764に変更する。
図26Aから図26Cを参照しつつ説明されている等しいタイムスタンプの状況において図25Dを参照しつつ説明されている楽観的同時並行性フラグのコンセプトも使用することができることは理解されるであろう。すなわち、楽観的同時並行性フラグがセットされている場合、リモートサーバーのバケットの内容はクライアントデバイス104によって予期されているものと異なり得るため、図25Cを参照しつつ説明されているようにクライアントデバイス104が「勝つ」ときに要求された変更をマージする代わりに、リモートサーバー102は、マージを実行することを拒絶することができる。このような場合、リモートサーバー102は、図26Bを参照しつつ説明されているようにその既存のバケットをクライアントデバイス104に返すであろう。
さらに、図24Aから図26Cに示されている特定のオペレーションは、クライアントデバイスおよびリモートサーバーの対応するバケットの状態を、クライアントデバイスが所望の更新をリモートサーバーに伝達すると同期するための特定の例を構成することは理解されるであろう。これらの例は、例示することのみを目的としている。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
リモートサーバーと通信するデバイスを認証するためのプロセス
概要。リモートサーバー102と通信しているときに、クライアントデバイス104は、同一性および一致する秘密を使用して自己を認証することができる。このペアは、デバイス資格証明書と総称され、クライアントデバイスとリモートサーバーとの間の信用関係の基礎をなす。リモートサーバーの観点からは、有効なデバイス同一性および秘密を保持するものは何でもそのデバイスであり、同じ特権を提供される。
デバイス資格証明書は、リモートサーバーに対して自己を認証するクライアントデバイスのための一手段となるが、いくつかの実施形態では、クライアントデバイスに対して自己を認証するリモートサーバーのための一手段とはなり得ない。したがって、デバイス資格証明書は、サービスの同一性を確認することができる別のプロトコル(例えば、SSL)の文脈で使用され得る。
任意の時点において、クライアントデバイスは、最大2セットまでの資格証明書、すなわち、既定の資格証明書のセットとオプションの、割り当てられた資格証明書のセットを保持することができる。既定の資格証明書は、製造時にデバイスに与えられ、その寿命が尽きるまでデバイスと共に存続する。例えば、図27Aは、クライアントデバイスへの既定の資格証明書の伝達を示すブロック図である。製造業者101は、既定の資格証明書をクライアントデバイス104に送信する。それに応答して、クライアントデバイス104は、受信した既定の資格証明書をストレージ要素128に格納する。
割り当てられた資格証明書は、リモートサーバー/クライアントデバイスの相互にやり取りする通常の過程でリモートサーバー102によってクライアントデバイスに与えられる。例えば、図27Bは、クライアントデバイスへの割り当てられた資格証明書の伝達を示すブロック図である。リモートサーバー102は、割り当てられた資格証明書をクライアントデバイス104に送信する。それに応答して、クライアントデバイス104は、受信した割り当てられた資格証明書をストレージ要素128に格納し、その結果、既定の資格証明書と割り当てられた資格証明書の両方を有するようになる。
既定の資格証明書は、認可された企業体によって製造された正規のデバイスであることを主張するクライアントデバイスのための一手段となる。割り当てられた資格証明書は、サービスによってそれが信頼できるものとしてみなされており、すべての相互のやり取りにおいて完全な特権を付与されるべきであることを主張するクライアントデバイスのための一手段となる。
クライアントデバイス104は、割り当てられた資格証明書のセットを保持した後、もっぱらリモートサーバー102に対して認証するときにこれらを使用する。クライアントデバイス104は、割り当てられた資格証明書を有していない場合、または割り当てられた資格証明書を使用した認証が失敗した場合にのみ既定の資格証明書に頼ることができる。
デバイス資格証明書は、広範なプロトコルと互換性を有するように設計され得る。ユーザー名とパスワードとを採用し、それらのフィールドに対して許容可能な長さ制限を設けるプロトコルでは、認証のためにデバイス資格証明書を使用することが可能であるべきである。多くの実施形態において、デバイス資格証明書は、HTTPSプロトコルの下で使用される。したがって、デバイス資格証明書のさらなる説明は、HTTPSプロトコルの文脈においてなされるが、当業者であれば、FTP、SMTP、TELNET、SSH、X400、X500、CMIPなどの他のプロトコルにもデバイス資格証明書を同様に適用できることを理解するであろう。
デバイス資格証明書の構造。デバイス資格証明書は、可変長の構造化ASCII文字列の形態をとり得る。いくつかの実施形態では、これらの文字列が十分に小さく、その文字セットが他のプロトコルに含めることに関して可能な限り目立たないものであるものとなるように気をつける。いくつかの実施形態では、デバイス資格証明書の構造化された性質により、デバイス資格証明書が、それらが形成された仕方およびそれらを検証するために必要なアルゴリズムに関する情報を伝えることができる。
いくつかの実施形態におけるデバイス資格証明書は、ピリオドで区切られた複数のコンポーネント文字列から構成される。それぞれのコンポーネント文字列は、ASCII文字A〜Z、a〜z、0〜9、ダッシュ、および下線に限定される。したがって、資格証明文字列に対する正当な文字は全体としてこれらの文字にピリオドを加えたものである。許容可能な文字セットを外れたコンポーネント値(2進ハッシュ値など)は、URLに含むように設計されたBase64のバリエーションである、URL64形式で符号化される。URL-64の使用は、構文的に中立の同一性文字列に対応する場合に特に有益であり、これにより特別なエスケープを多数使用することなくデバイス資格証明書をURLまたは他のテキスト文脈で受け渡すことができる。しかし、他の実施形態におけるデバイス資格証明書は、EBCDIC、ISO 8859、ISCII、TSCII、VISCIIなどの、1つまたは複数の異なる文字セットを含む異なる形式をとり得ることは理解されるであろう。
一実施形態において、デバイス資格証明書の第1のコンポーネントは、スキームと称される。スキームは、資格証明書の種類およびそれらが形成されたプロセスを識別する短い文字列である。スキームを使用することで、リモートサーバー102は、提示されている資格証明書の種類を即座に認識することができる。新しい認証メカニズムが導入されたときにも、スキームは資格証明書の古い形式と新しい形式とを区別するのに役立つ。他の実施形態では、単一の種類の認証メカニズムのみが使用される場合、または提示されている資格証明書の種類についてリモートサーバー102に通知するために他のメカニズムが実装される場合などでは、スキームコンポーネントを省くことができる。
デバイス資格証明書の他のコンポーネントの数および意味は、一般的に、資格証明書の種類毎に異なり、スキームコンポーネントが含まれる実施形態では、スキームによって決定され得る。
既定の資格証明書。製造時に、クライアントデバイス104は、既定の資格証明書の一意的なセットを与えられる。デバイスの既定の資格証明書は、リモートサーバー102との最初の相互のやり取りにおいてデバイスを認証するために使用される。これらは、エンドユーザーの直接アクションによって、またはリモートサーバー102を介して間接的に、デバイスが工場既定値に「一掃される」つまりリセットされる場合にも使用される。既定の資格証明書は、その寿命が尽きるまで物理的デバイスに留まり、これらが決して(例えば、ファームウェアのアップグレード時に)失われないように気をつける。
既定の資格証明書は、マスターキーから計算で生成される。製造プロセスにおいて、製造ライン上のプロビジョニング機器が、マスターキーから資格証明書を生成し、それらをデバイスの永続的メモリ内に投入する。いくつかの実施形態では、これは、クライアントデバイス104がシリアル番号を割り当てられるのと同時に行われるものとしてよい。いくつかの実施形態では、既定の資格証明書は以下の構造を有する。
<default-scheme> : = 'd'
<default-id> : = <default-scheme> + '.' + <serial-num> + '.' + <manufacturing-key-id>
<default-secret> : = <default-scheme> + '.' + URL64 (<default-MAC>)
ここで、<serial-num>は、クライアントデバイス104のユーザーに見えるシリアル番号であり、<default-MAC>は、256ビットメッセージ認証コード(MAC)であり、<manufacturing-key-id>は、MACを生成するために使用される特定のマスターキーを識別する文字列である。URL64()関数は、URL-64形式でバイト列を符号化することを指示する。
既定の秘密において使用されるMACは、以下のアルゴリズムを使用して既定の同一性およびマスター製造キーから生成される。
<default-MAC> := HMAC-SHA256 (<manufacturing-key> , ASCII (<default-id>))
ここで、HMAC-SHA256()は、ハッシュベースのメッセージ認証コードアルゴリズムの、SHA-256のバリエーションであり、<manufacturing-key>は、デバイスが作製された製造ラインに割り当てられているランダムに生成された512ビット列である。ASCII()関数は、終端ヌル文字を含まない、ASCII形式のバイト列として文字を符号化することを指示する。
実施形態はこの特定の構造を有する既定の資格証明書に限定されないことは理解されるであろう。例えば、既定のスキームを省くことができる。<default-id>は、manufacturing-key-idを含む必要がなく、またserial-numすら含む必要がないが、むしろ、クライアントデバイスを一意的に識別する他の文字列またはデータ列を使用することができる。さらに、<default-secret>は、既定のスキームを含む必要がなく、またURL-64符号化MACを含む必要がないが、むしろ、クライアントデバイス104呼びリモートサーバー102にのみ知られている秘密を形成する他の文字列またはデータ列を使用することができる。
割り当てられた資格証明書。既定の資格証明書に加えて、クライアントデバイス104は、割り当てられた資格証明書と称される資格証明書の第2のセットを取得することができる。これらの資格証明書は、セキュア接続を介してリモートサーバー102によってクライアントデバイス104に与えられる。クライアントデバイス104は割り当てられた資格証明書のセットを保持した後、それらを失うとき(例えば、工場設定リセット状態シナリオで)、それらが交換されるとき、または無効になるときまで、既定の資格証明書に優先してそれらを使用する。通常のオペレーションの過程において、攻撃の機会を制限するために、リモートサーバー102は、定期的に、新しい資格証明書をクライアントデバイスに割り当てる。
いくつかの実施形態では、割り当てられた資格証明書は以下の構造を有する。
<assigned-scheme> : = 'a'
<assigned-id> : = <assigned-scheme> + '.' + <serial-num>
<assigned-secret> : = <assigned-scheme> + '.' + URL64 (<random-128>)
ここで、<serial-num>は、クライアントデバイス104のユーザーに見えるシリアル番号であり、<random-128>は、リモートサーバーによってデバイスに割り当てられたランダムに生成される128ビット列である。
しかし、実施形態はこの特定の構造を有する割り当てられた資格証明書に限定されないことは理解されるであろう。例えば、既定のスキームを省くことができる。<assigned-id>は、serial-numを含む必要がないが、むしろ、クライアントデバイスを一意的に識別する他の文字列またはデータ列を使用することができる。さらに、<assigned-secret>は、既定のスキームを含む必要がなく、またURL-64符号化乱数を含む必要がないが、むしろ、クライアントデバイス104およびリモートサーバー102にのみ知られている秘密を形成する他の文字列またはデータ列を使用することができる。
資格証明書の妥当性確認。いくつかの実施形態では、既定の資格証明書および割り当てられた資格証明書は、共通のプロセスを使用して妥当性確認される。リモートサーバー102は、それぞれの知られているデバイスについて資格証明書のデータベースを維持し、例えば、データベースは、ストレージ要素118内に、またはストレージ要素118から離れた場所にあるストレージ要素(図示せず)内に格納され得る。喪失を防ぐため、リモートサーバー102は、SHA-256一方向性ハッシュ関数などの、一方向性ハッシュ関数を使用して資格証明書の秘密部分をハッシュ化形式で格納する。妥当性確認を行うときに、クライアントデバイスによって提示される秘密は、同じ関数、およびデータベースに格納されている対応する値と比較された結果の値を使用してハッシュ化される。2つの値が一致する場合、提示される資格証明書は本物であるとみなされる。
秘密ハッシュは、以下のように生成され得る。
<hashed-secret> : = SHA256 (ASCII(<secret>))
秘密のハッシュ化形式は、不可逆であるため、デバイス認証を実行するフロントエンドサーバーは、性能を改善するために、ハッシュ化された資格証明書をローカルにキャッシュすることができる。例えば、登録サーバー112、同期化サーバー114、および/またはロギングサーバー116は、ハッシュ化された資格証明書を格納することができ、ハッシュ化されていない資格証明書は、ストレージ要素118内に、またはストレージ要素118から離れた場所にあるストレージ要素(図示せず)内に格納される。これが生じた場合、キャッシュされている資格証明書は、定期的に再妥当性確認され得る。例えば、少なくとも6時間、12時間、18時間、24時間、30時間、36時間、6時間から36時間の範囲内、6時間以内の期間、または36時間を超える期間毎に行われ得る。キャッシュされている資格証明書の再妥当性確認を行うことによって、デバイス認証を実行するフロントエンドサーバーは、ハッシュ化された資格証明書がまだ正確であることを確認する。さらに、キャッシュされた資格証明書は、定期的でない間隔で再妥当性確認を行ってもよい。例えば、ハッシュ化された資格証明書は、認証に失敗すると、再妥当性確認が行われてもよい。
情報漏洩を防ぐために、いくつかの実施形態では、リモートサーバー102は、秘密ハッシュを比較するときに一定時間比較アルゴリズムを使用することができる。
認証プロトコル。クライアントデバイス104とリモートサーバー102との間の認証は、FTP、SMTP、TELNET、SSH、X400、X500、CMIPなどの任意の数の異なる通信プロトコルの文脈内で実行され得る。説明のため、以下の説明ではHTTPでの相互のやり取りの文脈におけるデバイス認証を説明する。
HTTPの文脈では、クライアントデバイス104は、HTTPベーシックアクセス認証プロトコル(例えば、RFC-2617で説明されているような)を使用して、リモートサーバー102との認証相互運用のとりまとめを行う。HTTP Authorizationヘッダーを形成するときに、デバイスの同一性および秘密は、それぞれ、useridおよびパスワードとして使用される。
クライアントデバイス104およびリモートサーバー102は、HTTPプロトコルによって定義された標準認証交換を実装している。特に、いつでも、サービスは認証を必要とする401 (Unauthorized)応答でデバイスからの要求に応答することができる。401応答は、Basic認証の使用を要求するWWW-Authenticateヘッダーを含み得る。401応答を受信すると、クライアントデバイス104は、デバイス資格証明書を含むAuthorizationヘッダーを含む要求を再発行する。Authorizationヘッダーを含む要求を受信した後、リモートサーバー102は、デバイス資格証明書をアンパックし、資格証明書の妥当性確認の節で説明されているようにその妥当性確認を行う。
クライアントデバイス104は、資格証明書(既定の、または割り当てられた)のセットを常に保持するので、いくつかの実施形態では、リモートサーバー102が401応答で応答するのを待つことなくAuthorizationヘッダーを要求の中に含めることによって認証の必要性を予想することができる。これは、デバイスとリモートサーバー102との間の余分な最初の往復を回避するために使用され得る。
デバイスによって供給される資格証明書が無効である場合、リモートサーバー102は、401 (Unauthorized)応答で要求に応答する。デバイスは、それが関連する要求でAuthorizationヘッダーを送信したかどうかを観察することによって認証失敗を示す401を区別する-そうした場合、要求で使用される資格証明書は不正である。
デバイスが割り当てられた資格証明書を使用している間に認証失敗が生じた場合、デバイスは、その永続的メモリから資格証明書を破棄し、既定の資格証明書を使用して認証を繰り返す。これは、デバイスに対する特権の喪失を引き起こす可能性があることに留意されたい(割り当てられた資格証明書のセキュリティの意味の節を参照)。
デバイスが既定の資格証明書を使用している間に認証失敗が生じた場合、デバイスは、短い期間待機し、同じ資格証明書を使用して要求を再度試みることができる。失敗が続く場合、いくつかの実施形態では、デバイスが再試行の間に徐々に長くなる期間で待つことができる。これは、5分毎に1回、10分毎に1回、15分毎に1回、5分毎に1回から15分毎に1回までの範囲、5分未満の期間に1回、または15分を超える期間に1回などの最大持続時間に到達し得る。
いくつかの実施形態では、クライアントデバイス104とリモートサーバー102との間のすべての認証相互運用は、例えば、SSLを使用してセキュア接続を介して実行される。SSL接続ネゴシエーションでは、クライアントデバイス104は、例えば、標準証明書ベースのSSLサーバー認証を使用してリモートサーバー102を認証する。いずれのときも、クライアントデバイス104は、非セキュア接続を介して、または特定のエンティティに属しているものとして適切に認証されていないサーバーに、資格証明書を含むAuthorizationヘッダーを送信しない。同様に、リモートサーバー102は、永久的失敗により、非セキュア接続を介してクライアントデバイス104を認証する試みを拒絶することができる。
資格証明書割り当てプロトコル。リモートサーバー102が新しい資格証明書をクライアントデバイス104に割り当てる場合、資格証明書は、通常のHTTP相互運用の一部としてデバイスに伝達され得る。特に、新しい資格証明書は、リモートサーバー102からのHTTP応答に含まれるX-nl-set-client-credentialsヘッダーで伝達され得る。このようなヘッダーの構文は以下のとおりである。
'X-nl-set-client-credentials' ':' 1*SP <device-id> 1*SP <device-secret>
ここで、<device-id>および<device-secret>は、デバイスの新しい同一性および秘密を表す文字列であり、「1*SP」は1つまたは複数のASCII空白文字を表す。同一性および秘密文字列の内容は、いくつかの実施形態では、ASCII文字A〜Z、a〜z、0〜9、コロン、ダッシュ、下線、およびピリオドに限定される。他の実施形態では、同一性および/または秘密文字列は、EBCDIC、ISO 8859、ISCII、TSCII、VISCIIなどの、1つまたは複数の異なる文字セットを含む異なる形式をとり得る。
X-nl-set-client-credentialsヘッダーは、リモートサーバー102によって生成される応答に含まれ得る。クライアントデバイス104によって受信された後、クライアントデバイス104は、保持する既存の割り当てられた資格証明書を破棄し、新しい資格証明書をその永続的メモリ内に格納する。その時点以降、デバイスは、リモートサーバー102とのその後に認証された相互のやり取りにおいて新しい資格証明書を使用する。
すでに述べているように、いくつかの実施形態では、クライアントデバイス104は、セキュア接続(例えば、SSL)を介してのみ新しい割り当てられた資格証明書を受け入れ、接続の他方の側の当事者は、リモートサーバー102(例えば、SSLサーバー認証によって確立されているような)であることが知られている。同様に、リモートサーバー102は、新しい資格証明書を含むX-nl-set-client-credentialsヘッダーのみをセキュア接続を介してデバイスに送信することができる。それに加えて、リモートサーバー102は、デバイス資格証明書の有効なセットで認証された要求に応答してのみ新しい資格証明書を送信する(認証プロトコルに記述されているメカニズムを使用して)。
割り当てられた資格証明書の管理。クライアントデバイス104は最初にリモートサーバー102に接続したときに、既定の資格証明書を使用して自己を認証する。この最初の相互のやり取りの際に、デバイスは、リモートサーバー102とさらに通信する際に使用しなければならない割り当てられた資格証明書の新しいセットを与えられる。これ以降、いくつかの実施形態では、リモートサーバー102は、その後の相互のやり取りにおいて新しい資格証明書をデバイスに割り当てる。割り当てられた資格証明書のローテーションは、定期的に、例えば、毎週、毎月、毎年、1週間から1年までの範囲内の期間の後、1週間未満の期間内、または1年を超える期間内で行われ得る。割り当てられた資格証明書のローテーションは、非定期的にも行われるか、または代替的に非定期的に行われ得る。例えば、クライアントデバイス104がリモートサーバー102に特定の回数だけ接続した後に行われる。
割り当てられた資格証明書は、リモートサーバー102によって置き換えられるまで有効なままである。資格証明書のローテーションは、典型的には、クライアントデバイス104およびリモートサーバー102が相互にやり取りしている時点で行われるので、長期間にわたってリモートサーバー102と通信することができないデバイスは、認証の能力を失わない。
リモートサーバー102は、いくつかの実施形態では、その自スケジュールに従って新しい資格証明書を割り当てる努力をする。特に、外部エンティティは、リモートサーバー102に、有効な既定の資格証明書のセットで認証する以外の方法で新しい割り当てられた資格証明書を生成させることはできない。既定の資格証明書の盗まれたセットを使用して新しい割り当てられた資格証明書を生成する試みを繰り返すことを制限するために、リモートサーバー102は、クライアントデバイス104が既定の資格証明書の特定のセットで認証できる割合を、1時間当たり少ない回数(例えば、5、10、15、5から15の範囲内、5未満、または15超)に制限することができる。
通信障害により、クライアントデバイス104に割り当てられた資格証明書はリモートサーバー102に格納されているものから同期が外れている可能性がある。特に、資格証明書の新しいセットをクライアントデバイス104に伝えるメッセージが失われた場合、リモートサーバー102は、クライアントデバイス104が古い資格証明書でそのまま動作している間に新しい資格証明書を保持する。クライアントデバイス104がこの状態から復旧するのを可能にするため、リモートサーバー102は、新しい資格証明書または古い資格証明書のいずれかを使用してクライアントデバイス104が認証するのを許す猶予期間を実施する。猶予期間は、典型的には、クライアントデバイス104が古い資格証明書を使用して認証する時点から始まり、リモートサーバー102は、新しいセットを割り当てる時間であると判定するが、他の実施形態では、異なる開始時点が選択され得る。猶予期間が始まった後、古い資格証明書の使用で、リモートサーバー102が新しい資格証明書をクライアントデバイス104に再送することがトリガーされる。猶予期間が終了した後、リモートサーバー102は、古い資格証明書を破棄し、それらの資格証明書による認証のさらなる試みは拒絶される。猶予期間の持続時間は、例えば、12時間、24時間、36時間、12時間から36時間の範囲内、12時間未満、または90時間超とすることができる。いくつかの実施形態では、猶予期間が終了したとしても、クライアントデバイス104は、まだ、既定の資格証明書を使用して自己を認証することができる。
既定の秘密ハッシュの生成。リモートサーバー102内では、デバイス認証はそれぞれの知られているクライアントデバイス104に対する秘密ハッシュを含む資格証明書データベース(例えば、登録サーバー112、同期化サーバー114、ロギングサーバー116などにおいて与えられる)によってサポートされる。新しいデバイスがリモートサーバー102に接続する前に、新しいデバイスに対する既定の秘密ハッシュが生成され、資格証明書データベースにロードされ得る。秘密ハッシュ生成プロセスは、入力として、デバイスシリアル番号などの、デバイス識別子のリストを受け取る。秘密ハッシュ生成プロセスは、製造業者によって使用されているものと同じ暗号化アルゴリズムを採用して既定の資格証明書をクライアントデバイス104に提供する。例えば、リモートサーバー102は、製造キー(例えば、クライアントデバイス104によって提供される既定の資格証明書によって識別されるキー)およびその製造キーに関連付けられているクライアントデバイスのシリアル番号を使用してHMA-SHA256アルゴリズムを適用することができる。
割り当てられた資格証明書のセキュリティの意味。割り当てられた資格証明書の有効なセットを保持しているとしても、必ずしも、クライアントデバイス104がいかなる形でも信頼できることを意味するわけではないこと、または特権情報またはサービスへのアクセスを付与されるべきであることは理解されるであろう。クライアントデバイス104の信頼性は、むしろ、デバイス認証メカニズムの外部の手段によって、例えば、所有者にクライアントデバイス104をアカウントに関連付ける(例えば、ペアリングする)ためのパスコードを入力するように促すことによって、確立され得る。信頼が確立された後、デバイスの割り当てられた資格証明書は、注目しているクライアントデバイス104が実際に信頼関係が存在するデバイスであることをリモートサーバー102に対して証明するために使用される。
これから、信頼関係は、ユーザーのアカウントとデバイスの資格証明書との間の関係であり得ることが分かる。信頼が確立された後、信頼されたデバイスの資格証明書を有するものは、どの点から見ても、それらが実際にクライアントデバイス104を物理的に保持しているかどうかに関係なく、そのクライアントデバイス104である。逆に、クライアントデバイス104は、その資格証明書を失った場合、最初に信頼されたときに使用されているものと同じ(またはより強い)手段によって信頼関係を再確立することを強制され得る(すなわち、クライアントデバイス104は、ユーザーのアカウントと再ペアリングされる必要があり得る)。
既定の資格証明書のセキュリティの意味。クライアントデバイス104が既定の資格証明書の有効なセットを提示することができると、クライアントデバイス104が実際に特定の企業体によって製造された本物のハードウェア品であることをリモートサーバー102に確信させることができる。しかし、この確信は絶対的ではない。クライアントデバイス104に合法的にアクセスする悪意のある人、すなわち、製造プロセスに関わっている人、またはサードパーティデバイス設置業者/販売業者の従業員は、デバイスの既定の資格証明書を抽出して、それらを後で使用してそのデバイスになりすますことが可能である。さらに、既定の資格証明書を作成するために使用されるマスターキーは、直接または社会工学的攻撃には脆弱である場合がある。
これらの理由から、既定の資格証明書を介して認証されるクライアントデバイス104は、いくつかの実施形態では、リモートサーバー102に関して重要な特権を決して付与されない。リモートサーバー102がそのようなクライアントデバイス104に付与する主要な特権は、信頼を確立する第一歩である、新しい割り当てられた資格証明書を取得することができることである。
既定の資格証明書の相対的強度もまた、リモートサーバー102がクライアントデバイス104から受信するいくつかの種類の情報を信頼することを可能にする。例えば、リモートサーバー102は、既定の資格証明書により認証されたクライアントデバイス104からのログデータを記録し、監視することができ、これにより、カスタマーサポート要員はクライアントデバイス104が完全に信頼できるようになることを妨げている接続または認証問題を診断することができる。これにもかかわらず、リモートサーバー102は、悪意のある人がクライアントデバイス104から既定の資格証明書のセットを抽出し、それらを使用して大量の偽のログ情報をシステムに送りつける可能性があるため、まだ、この特権の悪用に対する十分な予防策を講じなければならない。
リモートサーバーに対する認証時のデバイスの挙動
初期コンタクトおよび通常オペレーション。新しいクライアントデバイス104が起動したときに、多くの実施形態において、その最初の要求は、登録サーバー112への要求である。この相互のやり取りは、いくつかの実施形態ではHTTP Authorizationヘッダーでリモートサーバー102に提示される、デバイスの既定の資格証明書を使用して認証される。
登録サーバー112は、この要求に応答すると、例えば、X-nl-set-client-credentials応答ヘッダーでクライアントデバイス104に対する割り当てられた資格証明書の初期セットを返す。このヘッダーを受信した後、クライアントデバイス104は、新しい資格証明書を抽出し、それらをストレージ要素128などの永続的ストレージ内に格納する。
その後、クライアントデバイス104は、すべての要求の割り当てられた資格証明書をリモートサーバー102に提示する。割り当てられた資格証明書は、1)リモートサーバーによってローテーションから外されるまで、2)クライアントデバイスが工場既定値にリセットされるまで、または3)強制的にクライアントデバイスに資格証明書をリセットさせるエラーが発生するまで有効なままである。
資格証明書のローテーション。定期的に(または非定期的に)、リモートサーバー102は、クライアントデバイス104に、割り当てられた資格証明書の新しいセットを配信し、その既存の資格証明書と交換する。初期コンタクトの場合と同様に、新しい資格証明書は、X-nl-set-client-credentials応答ヘッダーを介して返され得る。資格証明書のローテーションは、登録サーバー112、同期化サーバー114、またはロギングサーバー116などの、リモートサーバー102のエンドポイントのうちの1つとの相互のやり取りで生じ得る。
クライアントデバイス104は、新しい割り当てられた資格証明書を受信した場合、永続的ストレージに格納した割り当てられた資格証明書のコピーを更新する。多くの実施形態において、これは、リモートサーバー102からX-nl-set-client-credentialsヘッダーを受信するとすぐに生じる。少なくとも1つの実施形態において、クライアントデバイス104は、長いポーリングを使用することができ、そこで、すべての関連するバケットにサブスクライブする要求を伝達する(例えば、図10を参照しつつ説明されているステップ326を参照)。そのような場合、クライアントデバイス104は、応答(もしあれば)の本体が入ったときではなく、長いポーリングの応答の見出しが受信されるとすぐに資格証明書を更新することができる。
認証失敗の処理。いくつかのまれな状況において、クライアントデバイス104は、リモートサーバー102が無効とみなす割り当てられた資格証明書のセットで終わることができる。これが生じた場合、リモートサーバー102は、例えば、HTTP 401 Unauthorized応答で、これらの資格証明書を使用する要求を拒絶する。クライアントデバイス104は、リモートサーバー102からこのエラーを受信すると必ず、割り当てられた資格証明書のローカルコピーを即座に破棄し、既定の資格証明書を使用して登録サーバー112に戻る。この挙動は、クライアントデバイス104からリモートサーバー102のエンドポイントへの要求について生じ得る。
いくつかの実施形態では、認証失敗からクライアントデバイス104が登録サーバー112から新しい割り当てられた資格証明書を受信することに成功した時点までの時間に、クライアントデバイス104は、登録サーバー112との通信およびいくつかの場合におけるロギングサーバー116との通信を除き、リモートサーバー102とのすべての通信を抑制する。他の実施形態では、クライアントデバイス104は、資格証明書を破棄して、登録サーバー112に戻る前に1つまたは複数の再試行を試み得る。
すべてのクライアントデバイスが、有効な既定の資格証明書を付けて製造されるべきなので、リモートサーバー102は、HTTP 401 Unauthorized応答を既定の資格証明書を使用するクライアントデバイス104に決して返すべきでない。しかし、いくつかの状況では(例えば、盗まれたデバイス、盗まれた既定の資格証明書など)、これが生じ得る。リモートサーバー102がクライアントデバイス104の既定の資格証明書を拒絶した場合、クライアントデバイス104はバックオフアルゴリズムを実行し、再試行から次の再試行までの間の期間を徐々に長くしながら成功するまで待つ。
ユーザーが工場既定の機能へのデバイスのリセットを起動した場合、クライアントデバイス104は、割り当てられた資格証明書をクリアして、上述の初期コンタクト挙動に戻る。
クライアントデバイスの認証時のリモートサーバーの挙動
登録サーバーの認証挙動。クライアントデバイスは、既定の資格証明書または割り当てられた資格証明書のいずれかを使用して登録サーバー112に対して認証することが許される。クライアントデバイス104が、既定の資格証明書を使用して認証する場合、リモートサーバー102の挙動は、クライアントデバイス104がすでにリモートサーバー102とコンタクトしているかどうかに依存する。
初期コンタクト。登録サーバー112が、クライアントデバイス104から要求を受信したときに、例えば、ストレージ要素118の割り当てられた資格証明書198においてクライアントデバイス104に対して割り当てられた資格証明書が存在しない場合、リモートサーバー102は、その要求をクライアントデバイス104とリモートサーバー102との間の初期コンタクトであるとみなす。この場合、リモートサーバー102は、割り当てられた資格証明書の新しいセットを即座に生成し、それらをクライアントデバイス104に返す。次いで、クライアントデバイス104は、リモートサーバー102とのさらなる相互のやり取りのためにこれらの資格証明書を使用することが予期される。
デバイスの戻り。通常の状況では、クライアントデバイス104が登録サーバー112に戻ると、これは、割り当てられた資格証明書を使用して認証する。この相互のやり取りにおいて、デバイスの割り当てられた資格証明書は、すでに説明され、また以下でさらに説明されるように定期的ローテーションを受けるものとしてよい。
喪失資格証明書。いくつかの状況において、すでに割り当てられた資格証明書を付与されているクライアントデバイス104は、既定の資格証明書を使用して登録サーバー112に戻ることができる。この状況は、次の少なくとも2つの場合に発生し得る。(1)クライアントデバイス104が、最初に登録サーバー112とコンタクトし、その既定の資格証明書を提示する。登録サーバー112は、割り当てられた資格証明書の新しいセットで応答するが、応答が、例えば、接続性に問題があるため、失われる。その後、クライアントデバイス104が、既定の資格証明書を再び使用して、登録サーバー112に対して要求を再試行する。これは「初期コンタクト」シナリオである。(2)クライアントデバイス104が、失効した割り当てられた資格証明書を使用してリモートサーバー102にコンタクトする。リモートサーバー102は、失効した資格証明書を検出し、資格証明書の新しいセットを割り当てるが、応答が失われている。その後、クライアントデバイス104は、割り当てられた資格証明書の猶予期間よりも長い期間にわたってオフラインになる。接続性が回復したときに、クライアントデバイス104は、リモートサーバー102が、例えば、HTTP 401 Unauthorized応答で拒絶する古い資格証明書を使用して接続を試みる。これを受信した後、クライアントデバイス104は割り当てられた資格証明書を破棄し、既定の資格証明書を使用して登録サーバー112に戻る。これは「喪失資格証明書」シナリオである。
リモートサーバー102は、例えば、ストレージ要素118内の割り当てられた資格証明書の存在を検出することによって、喪失資格証明書シナリオを初期コンタクトシナリオから区別することができる。リモートサーバー102が、クライアントデバイス104が資格証明書を喪失したことを検出すると、これは、例えば、ストレージ要素118内のデバイスの認証状態をリセットし、プロセスにおける古い資格証明書情報を破棄し、クライアントデバイス104に対する割り当てられた資格証明書の新しいセットを生成する。それと同時に、リモートサーバー102は、クライアントデバイス104とその構造とのペアリングを解除し(すなわち、クライアントデバイス104とすでにペアリングされているユーザーアカウントとのペアリングを解除し)、ユーザーデータにアクセスする許可を証明することをペアリングプロセスを通じてクライアントデバイス104に強制する。
不正資格証明書。無効な資格証明書(既定の、または割り当てられた)を使用してクライアントデバイス104が登録サーバー112に対して認証する試行は、ログに記録され(例えば、ロギングサーバー116によって)、例えば、HTTP 401 Unauthorized応答で即座に拒絶され得る。
同期化サーバーの認証挙動。多くの実施形態において、クライアントデバイス104と割り当てられた同期化サーバー114との間のすべての相互のやり取りで、割り当てられた資格証明書を使用する。既定の資格証明書を使用してクライアントデバイス104が同期化サーバー114に対して認証する試行は、即座にログに記録され(例えば、ロギングサーバー116を使用して)、例えば、HTTP 401 Unauthorized応答で拒絶され得る。同様に、無効な資格証明書(既定の、または割り当てられた)を使用してクライアントデバイス104が同期化サーバー114に対して認証する試行は、ログに記録され、例えば、HTTP 401 Unauthorized応答で即座に拒絶され得る。
同期化サーバー114との相互のやり取りにおいて、デバイスの割り当てられた資格証明書は、すでに説明され、また以下でさらに説明されるようにローテーションを受けるものとしてよい。
ロギングサーバーの認証挙動。クライアントデバイス104は、割り当てられた資格証明書または既定の資格証明書のいずれかを使用してロギングサーバー116に対して認証することができる。両方の場合において、ロギングサーバー116は、クライアントデバイス104からのログファイルアップロードを受け入れ、格納する。いくつかの実施形態では、クライアントデバイスがログを常にアップロードできるように、ロギングサーバー116は、無効な資格証明書(割り当てられた、または既定の)で認証するクライアントデバイス104からのログファイルも受け入れる。
しかし、ロギングサーバー116は、提示される認証資格証明書の種類および/または認証資格証明書の有効性に基づきアップロードされたログファイルを特徴付けることができる。例えば、ロギングサーバー116は、すべてのアップロードされたログファイルをクライアントデバイス104が有効な割り当てられた資格証明書で認証しない限り未認証であるとして特徴付けることができる。別の例では、ロギングサーバー116は、アップロードされたログファイルをクライアントデバイス104が有効な割り当てられた資格証明書または有効な既定の資格証明書で認証しない限り未認証であるとして特徴付けることができる。さらに、いくつかの実施形態では、「未認証」および「認証済み」以外の特徴付けの追加の種類があり得る。例えば、有効な割り当てられた資格証明書が最高レベルの認証に関連付けられる、有効な既定の資格証明書が中間レベルの認証に関連付けられる、かつ無効な資格証明書が最低レベルの認証に関連付けられる、の3つのレイヤの特徴付けがあり得る。
いくつかの実施形態では、クライアントデバイス104が、有効な割り当てられた資格証明書をロギングサーバー116に提示する場合には必ず、資格証明書はすでに説明され、以下でさらに説明されるように通常のローテーションを受ける。
さらに、いくつかの実施形態では、登録サーバー112とは異なり、クライアントデバイス104が既定の資格証明書を使用してロギングサーバー116に対して認証するときに、リモートサーバー102は、クライアントデバイス104に対する新しい割り当てられた資格証明書を生成しない。これにより、クライアントデバイス104が登録サーバー112に戻り、ログをロギングサーバー116に同時にアップロードしながら新しい資格証明書を取得する喪失資格証明書シナリオにおける競合状態を回避することができる。
資格証明書のローテーション。割り当てられた資格証明書はクライアントデバイス104に対して存在するようになると、リモートサーバー102とのコンタクト毎に定期的ローテーションを受けるものとしてよい。ローテーションは、クライアントデバイス104がリモートサーバー102のエンドポイントに対して認証し、リモートサーバー102が現在のデバイス資格証明書がその構成された寿命を超えたと判定したときに生じる。割り当てられた資格証明書のローテーションは、定期的に、例えば、毎週、毎月、毎年、1週間から1年までの範囲内の期間の後、1週間未満の期間内、または1年を超える期間内で行われ得る。割り当てられた資格証明書のローテーションは、非定期的にも行われるか、または代替的に非定期的に行われ得る。例えば、クライアントデバイス104がリモートサーバー102に特定の回数だけ接続した後に行われる。資格証明書のローテーションは、リモートサーバー102の1つまたは複数のエンドポイントで生じ得る。
古い割り当てられた資格証明書の使用。資格証明書のローテーションが生じた後、クライアントデバイス104は、古い資格証明書を使用して、特に一番最近のローテーションの直前に有効であった資格証明書を使用してリモートサーバー102に要求を行うことが可能である。これは、次の少なくとも2つの状況で発生し得る。(1)リモートサーバー102が新しい資格証明書を含む応答を生成するが、その応答はクライアントデバイス104に届く前に失われている(例えば、通信エラーにより)。この場合、クライアントデバイス104は、リモートサーバー102が新しい資格証明書を予期されている間に古い資格証明書をまだ有している。(2)クライアントデバイス104がリモートサーバー102に対して複数の同時要求を行った場合(例えば、同期化サーバー114への要求とロギングサーバー116への要求)、ネットワークまたはサーバーの処理の待ち時間が生じ、その結果、古い資格証明書を含む要求が、同じクライアントデバイス104からの別の要求が資格証明書のローテーションを引き起こした後に、リモートサーバー102によって処理され得る。
これらの状況を取り扱うために、リモートサーバー102がデバイスの割り当てられた資格証明書をローテーションするときには必ず、リモートサーバー102は、デバイスの古い資格証明書を認証するために必要な情報を保持するものとしてよい。これ以降、構成可能な期間(すなわち、例えば、12時間、24時間、36時間、12時間から36時間までの範囲内、12時間未満、または36時間超とすることができる猶予期間)に、リモートサーバー102により、クライアントデバイス104は、現在の資格証明書または古い資格証明書のいずれかを使用して認証することができる。クライアントデバイス104が、この猶予期間の間に古い資格証明書を使用して認証する毎に、リモートサーバー102は(もう一度)クライアントデバイス104にその資格証明書を現在の資格証明書に更新するよう指令することができる。多くの実施形態において、猶予期間が終了した後、古い資格証明書を使用して認証をさらに試みると、リモートサーバー102によってHTTP 401 Unauthorized応答で即座に拒絶される。
次に図を参照すると、図28Aから図32Cは、さまざまな前述の認証プロセスのうちのいくつかを図示している。特に、図28Aは、一実施形態による割り当てられた同期化サーバーと通信するようにクライアントデバイスを認証するためのプロセスの通信シーケンス1800を示している。プロセス1800は、さまざまな状況で実行され得る。例えば、プロセス1800はクライアントデバイス104をリモートサーバー102に最初に接続した後、クライアントデバイス104がその割り当てられた資格証明書を喪失した後のその後の接続時などに実行され得る。オペレーション1802において、クライアントデバイス104は、既定の資格証明書を登録サーバー112に伝達する。それに応答して、登録サーバー112は、割り当てられた資格証明書を生成し、クライアントデバイス104に送信する。次いで、クライアントデバイスは、これらの割り当てられた資格証明書を使用して、割り当てられた同期化サーバー114Aなどの、リモートサーバー102の他の要素との通信を確立することができる。
図28Bは、一実施形態によるクライアントデバイスが割り当てられた同期化サーバーと通信するプロセス1810の流れ図である。オペレーション1812において、クライアントデバイス104は、登録サーバー112との接続を確立する。クライアントデバイス104は、例えば、ストレージ要素128に備えられている登録サーバーロケーション128Aを使用して、接続を確立することができる。接続された後、既定の資格証明書を送信する前に、オペレーション1814において、クライアントデバイス104は、それが登録サーバー112と確立した接続がセキュア(例えば、SSL、TSLなど)接続であるかどうかを判定することができる。セキュア接続でない場合、処理はオペレーション1816に進むことができ、クライアントデバイス104は、バックオフアルゴリズムを実行することができる。バックオフアルゴリズムを実行する際に、クライアントデバイス104は、登録サーバー112とのセキュア接続を確立することを試みる前に徐々に長くなる期間を待つことができる。しかし、いくつかの実施形態では、クライアントデバイス104は、バックオフアルゴリズムを実施しないが、むしろ、例えば、定期的間隔で、登録サーバー112とのセキュア接続を再確立することを連続的に試みることができる。
しかし、セキュア接続であると判定された場合、処理はオペレーション1818に進むことができる。オペレーション1818において、クライアントデバイス104は、既定の資格証明書(例えば、既定の資格証明書128E)を登録サーバー112に伝達する。既定の資格証明書は、典型的には、デバイス識別子およびデバイス秘密を含む。
既定の資格証明書が送信された後、クライアントデバイス104は、登録サーバー112が割り当てられた資格証明書をクライアントデバイス104に提供することを予期する。したがって、オペレーション1820において、クライアントデバイス104は、それが登録サーバー112から割り当てられた資格証明書を受信しているかどうかを判定する。クライアントデバイス104が割り当てられた資格証明書を(例えば、特定の期間の後に)受信しない場合、これは、通信障害または他の種類の障害を示し得る。したがって、処理はオペレーション1816に進むものとしてよい。
そうでなければ、処理はオペレーション1822に進み、クライアントデバイス104は、受信された割り当てられた資格証明書を格納する。例えば、クライアントデバイス104は、受信された資格証明書を割り当てられた資格証明書128Fとしてストレージ要素128に格納し得る。
クライアントデバイス104は割り当てられた資格証明書を取得した後、リモートサーバー102の1つまたは複数の要素との通信に成功し得る。この特定の実施形態では、オペレーション1824において、クライアントデバイス104は、割り当てられた資格証明書128Fを使用して割り当てられた同期化サーバー114との接続を確立する。しかし、クライアントデバイス104は、登録サーバー112、ロギングサーバー116など、割り当てられた資格証明書を使用するリモートサーバー102の他の要素との接続も確立することができ、または代替的にこの要素との接続を確立することができることは理解されるであろう。
図28Cは、一実施形態による登録サーバーがクライアントデバイスに対する割り当てられた資格証明書を生成するプロセス1830の流れ図である。オペレーション1832において、登録サーバー112は、1つまたは複数のクライアントデバイスからの通信を監視する。クライアントデバイス104から通信を受信した後、処理はオペレーション1834に進み、登録サーバー112は、それがクライアントデバイス104から既定の資格証明書を受信したかどうかを判定する。受信しなかった場合、登録サーバー112は、クライアントデバイス104からの通信を監視し続けることができ、オプションにより、特定の期間の経過後にクライアントデバイスから切断することができる。受信した場合、処理はオペレーション1836に進むものとしてよい。
オペレーション1836において、登録サーバー112は、割り当てられた資格証明書をクライアントデバイスに送信する前に、クライアントデバイス104との接続がセキュア接続であるかどうかを判定する。セキュア接続でない場合、処理はオペレーション1838に進むことができ、登録サーバー112は、登録サーバー112によって提供される1つまたは複数のリソース(例えば、割り当てられた資格証明書)へのクライアントデバイス104のアクセスを拒否する。リソースへのアクセスを拒否する際に、登録サーバー112は、オプションにより、例えば、特定の期間後に、クライアントデバイスから切断することができる。登録サーバー112が、クライアントデバイス104との接続がセキュア接続であると判定した場合、処理はオペレーション1840に進むものとしてよい。
オペレーション1840において、登録サーバー112は、既定の資格証明書が特定のクライアントデバイスから登録サーバー112に伝達された速度がプリセットされた速度を超えるかどうかを判定する。例えば、登録サーバー112は、特定のクライアントデバイス104が既定の資格証明書を、1時間に5回、1時間に10回、1時間に15回、1時間に5から15回の範囲内の速度、1時間に5回未満の速度、または1時間に15回を超える速度で提示したかどうかを判定することができる。クライアントデバイス104が既定の資格証明書をそのような速度で提示した場合、これは、既定の資格証明書の盗まれたセットを使用して新しい割り当てられた資格証明書を生成する試みを繰り返すなどのセキュリティ違反を示し得る。したがって、プリセットされた速度を超えた場合、処理はオペレーション1838に進むことができる。超えていない場合、処理はオペレーション1842に進むものとしてよい。
オペレーション1842において、登録サーバー112は、既定の資格証明書が有効であるかどうかを判定する。例えば、登録サーバー112は、受信された既定の資格証明書を接続されたクライアントデバイス104に関連付けられている登録サーバー112によって格納されている既定の資格証明書(例えば、登録サーバー112によってストレージ要素118に格納されている既定の資格証明書198のうちの1つ)と比較することができる。特定の一実施形態において、受信された既定の資格証明書は、既定の識別子および既定の秘密を含むものとしてよく、既定の識別子は、クライアントデバイスを一意的に識別するものであり、既定の秘密は、クライアントデバイスおよび登録サーバーにのみ知られているクライアントデバイスに関連付けられている一意的な文字列またはデータ列である。既定の資格証明書を受信した後、登録サーバー112は、既定の識別子を使用して、クライアントデバイスに対応する既定の秘密(例えばストレージ要素118側に格納されている)を識別する。次いで、登録サーバー112は、受信された既定の秘密を格納されている既定の秘密と比較する。それらが一致した場合、既定の資格証明書は有効であるとみなされる。一致しない場合、それらは無効であるとみなされる。
いくつかの実施形態では、既定の識別子は、既定の秘密を暗号化するために使用される製造キーを識別する製造キー識別子を含み得る。既定の秘密は、例えば、製造キー識別子によって識別される製造キーを使用して暗号化された既定の識別子でよい。したがって、登録サーバーは、最初に、受信された製造キー識別子によって識別された製造キーを識別し、このキーを使用して既定の識別子を暗号化し(例えば、HMAC-SHA256などのアルゴリズムを使用して一方向ハッシュを実行し)、その結果を受信された既定の秘密と比較して既定の資格証明書が有効であるかどうかを判定することができる。そのような場合、さまざまなデバイス104に対応する既定の秘密は、登録サーバー112側に事前に格納されていてもよく、いくつかの実施形態では、事前に格納されていなくてもよいが、むしろ受信された既定の識別子および格納されている製造キーから生成され得る。
いくつかの実施形態では、既定の資格証明書は、クライアントデバイスから伝達される資格証明書の種類を識別するスキーム識別子を含むこともできる。この特定の実施形態では、スキームは、資格証明書が既定の資格証明書であることを示す。このようなスキームは、既定の資格証明書、割り当てられた資格証明書、または別の種類のデバイス資格証明書がクライアントデバイスから伝達されているかどうかを登録サーバー112が素早く効果的に判定することを可能にするために、登録サーバー112(およびリモートサーバー102の他の要素)によって使用され得る。
登録サーバー112が、受信された既定の資格証明書が有効であると判定した場合、処理はオペレーション1844に進み、登録サーバー112は、クライアントデバイス104からのコンタクトが初期コンタクトであるか(例えば、最初にクライアントデバイスが割り当てられた資格証明書を要求している)またはその後のコンタクト(例えば、第2回、第3回、またはその後の回にクライアントデバイスが割り当てられた資格証明書を要求している)であるかを判定する。
登録サーバー112は、多数の異なる技術のうちの1つまたは複数を使用してこのような判定を行うことができる。一実施形態において、登録サーバー112は、接続されているクライアントデバイス104について格納されている割り当てられた資格証明書(例えば、割り当てられた資格証明書150Gのうちの1つ)を有するかどうかを確認することができる。別の実施形態において、登録サーバー112は、接続されているクライアントデバイス104に対する初期コンタクトフラグがセットされているかどうかを調べるものとしてよく、初期コンタクトフラグは、最初にクライアントデバイス104が既定の資格証明を登録サーバー112に提示するときにセットされ得る。
登録サーバー112が、クライアントデバイス104からのコンタクトが初期コンタクトであると判定した場合、処理はオペレーション1846に進むものとしてよい。オペレーション1846において、登録サーバー112は、接続されたクライアントデバイス104に対する割り当てられた資格証明書を生成し、割り当てられた資格証明書をリモートサーバー102のさまざまな要素によってアクセス可能なストレージ要素内に格納する。例えば、登録サーバー112は、割り当てられた資格証明書を割り当てられた資格証明書199としてストレージ要素118に格納し得る。割り当てられた資格証明書は、例えば、クライアントデバイス104を一意的に識別する割り当てられた識別子を含み得る。一実施形態において、割り当てられた識別子は、受信された既定の資格証明書から抽出されたデバイスシリアル番号を含む。割り当てられた資格証明書は、割り当てられた秘密も含むことができ、割り当てられた秘密は、クライアントデバイスおよび登録サーバーにのみ知られているクライアントデバイスに関連付けられている一意的な文字列またはデータ列であり、リモートサーバー102によって提供される。割り当てられた秘密は、一実施形態では、乱数、例えば、ランダムに生成される128ビット列である。割り当てられた資格証明書が生成された後、オペレーション1848において、割り当てられた資格証明書は、クライアントデバイス104に伝達される。
一方で、オペレーション1844において、登録サーバー112が、クライアントデバイス104からのコンタクトが初期コンタクトでない(すなわち、その後のコンタクトである)と判定した場合、処理はオペレーション1850に進むものとしてよい。登録サーバー112が、クライアントデバイス104からのコンタクトが初期コンタクトでないと判定した場合、これは、クライアントデバイス104が何らかの形で割り当てられた資格証明書を喪失したことを示し得る。これは、セキュリティ違反を示すものとしてよく、したがって、登録サーバー112は、クライアントデバイス104とユーザーアカウントとの再ペアリングを必要に応じて強制し得る。そこで、オペレーション1850において、登録サーバー112は、クライアントデバイスがユーザーカウントとペアリングされているかどうかを判定する。ペアリングされている場合、処理はオペレーション1852に進むことができ、登録サーバー112は、そのアカウントからデバイスをペアリング解除し、事実上、クライアントデバイス104のユーザーに、デバイスとアカウントとの再ペアリングを行うことを強制し、その後、処理はオペレーション1846に進む。ペアリングされていない場合、処理はデバイスのペアリング解除なしでオペレーション1846に進むことができる。
図28Dは、一実施形態による同期化サーバーが割り当てられたクライアントデバイスと通信するプロセス1860の流れ図である。プロセス1860は、同期化サーバー114との通信の文脈において説明されているが、登録サーバー112、ロギングサーバー116など、割り当てられた資格証明書を使用するリモートサーバー102の他の要素との通信を円滑にするために類似のプロセスを使用することができることは理解されるであろう。
オペレーション1862において、同期化サーバーは、1つまたは複数のクライアントデバイスからの通信を監視する。クライアントデバイス104から通信を受信した後、処理はオペレーション1864に進み、同期化サーバー114は、それがクライアントデバイス104から割り当てられた資格証明書を受信したかどうかを判定する。受信しなかった場合、同期化サーバー114は、クライアントデバイス104からの通信を監視し続けることができ、オプションにより、特定の期間の経過後にクライアントデバイスから切断することができる。さもなければ、処理はオペレーション1866に進むものとしてよい。
オペレーション1866において、同期化サーバー114は、1つまたは複数のセキュアリソースにアクセスを付与する前に、クライアントデバイス104との接続がセキュア接続であるかどうかを判定する。セキュア接続でない場合、処理はオペレーション1868に進むことができ、同期化サーバー114は、同期化サーバー114によって提供される1つまたは複数のリソース(例えば、データバケット)へのクライアントデバイス104のアクセスを拒否する。リソースへのアクセスを拒否する際に、同期化サーバー114は、オプションにより、例えば、特定の期間後に、クライアントデバイスから切断することができる。同期化サーバー114が、クライアントデバイス104との接続がセキュア接続であると判定した場合、処理はオペレーション1870に進むものとしてよい。
オペレーション1870において、同期化サーバー114は、クライアントデバイスによって提示された割り当てられた資格証明書が有効であるかどうかを判定する。それらが有効である場合、処理はオペレーション1872に進むことができ、同期化サーバー114は、クライアントデバイスにセキュアリソース(例えば、デバイスに関連付けられているデータバケット)へのアクセスを付与する。有効でない場合、処理はオペレーション1868に進むものとしてよく、アクセスは拒否される。
図28Eを簡潔に参照すると、図28Eは、第1の実施形態による割り当てられた資格証明書が有効であるかどうかを判定するためのプロセス1870の流れ図である。オペレーション1870Aにおいて、同期化サーバー114は、受信された割り当てられた資格証明書をすでに格納されている割り当てられた資格証明書と比較するが、その場合、すでに格納されている割り当てられた資格証明書が、例えば、オペレーション1846において説明されているように登録サーバー112によって生成され格納されている。受信された割り当てられた資格証明書が接続されているクライアントデバイス104に関連付けられているすでに格納されている割り当てられた資格証明書と同一である場合、処理はオペレーション1870Bに進み、そこで、受信された資格証明書が有効であると判定される。そうでない場合、処理はオペレーション1870Cに進み、そこで、受信された資格証明書が無効であると判定される。
特定の一実施形態において、受信された割り当てられた資格証明書は、割り当てられた識別子および割り当てられた秘密を含むものとしてよく、割り当てられた識別子は、クライアントデバイスを一意的に識別するものであり、割り当てられた秘密は、クライアントデバイスおよびリモートサーバーにのみ知られているクライアントデバイスに関連付けられている一意的な文字列またはデータ列であり、リモートサーバーによって割り当てられる。割り当てられた資格証明書を受信した後、同期化サーバー114は、割り当てられた識別子を使用して、クライアントデバイスに対応する割り当てられた秘密(例えばストレージ要素118側に格納されている)を識別する。次いで、同期化サーバー114は、受信された割り当てられた秘密を格納されている割り当てられた秘密と比較する。それらが一致した場合、割り当てられた資格証明書は有効であるとみなされる。一致しない場合、それらは無効であるとみなされる。
いくつかの実施形態では、割り当てられた資格証明書は、クライアントデバイスから伝達される資格証明書の種類を識別するスキーム識別子を含むことができる。この特定の実施形態では、スキームは、資格証明書が割り当てられた資格証明書であることを示す。このようなスキームは、既定の資格証明書、割り当てられた資格証明書、または他の種類のデバイス資格証明書がクライアントデバイスから伝達されているかどうかを同期化サーバー114が素早く効果的に判定することを可能にするために、同期化サーバー114(およびリモートサーバー102の他の要素)によって使用され得る。
次に図28Fを参照すると、図28Fは、第2の実施形態による割り当てられた資格証明書が有効であるかどうかを判定するためのプロセス1870の流れ図である。確かに、図28Eを参照しつつ説明されている実施形態は、資格証明書のローテーションが使用されない場合に適用可能であり、また資格証明書のローテーションが使用されるが、同期化サーバー114は、新しい割り当てられた資格証明書が最近生成されていないと判定した場合に適用可能である。すなわち、オペレーション1870は、例えば、「割り当てられた資格証明書の管理」の節で説明されている猶予期間を外れている。対照的に、図28Fに示され、図28Fを参照しつつ説明されている実施形態は、資格証明書のローテーションが使用され、割り当てられた資格証明書の新しいセットが最近(例えば、最近24時間以内に)生成され、クライアントデバイスに伝達されている場合に適用可能である。したがって、リモートサーバー102は、少なくとも一時的には、クライアントデバイス104がリモートサーバー100のエンティティへのアクセスを得るために使用することができる割り当てられた資格証明書の2つのセットを有することができる。これらは、「以前に割り当てられた資格証明書」および「最近割り当てられた資格証明書」を含み、以前に割り当てられた資格証明書は、最近割り当てられた資格証明書の生成の前にクライアントデバイスを認証するために生成され、使用されており、以前に割り当てられた資格証明書および最近割り当てられた資格証明書は両方とも、猶予期間にクライアントデバイスを認証するために使用することができ、最近割り当てられた資格証明書のみは、猶予期間が終了した後にクライアントデバイスを認証するために使用することができる。
オペレーション1870Gにおいて、クライアントデバイス104から割り当てられた資格証明書を受信した後、同期化サーバー114は、受信された割り当てられた資格証明書を、例えば、ストレージ要素118内に格納されている最近割り当てられた資格証明書と比較する。受信された資格証明書が、最近割り当てられた資格証明書と同じである場合、クライアントデバイスは、猶予期間に正しい資格証明書を使用しており、したがって、処理はオペレーション1870Kに進むことができ、そこで、同期化サーバー114は、受信された資格証明書が有効であると判定する。
対照的に、受信された資格証明書が最近割り当てられた資格証明書と異なる場合、処理はオペレーション1870Hに進むことができ、受信された資格証明書は、例えば、ストレージ要素118内に格納されている以前に割り当てられた資格証明書と比較される。受信された資格証明書が、この時点で以前に割り当てられた資格証明書と同じでない場合、受信された資格証明書は、最近割り当てられた、または以前に割り当てられた資格証明書のいずれとも同じでなく、したがって、処理はオペレーション1870Iに進み、同期化サーバー114は、受信された資格証明書が無効であると判定する。
同期化サーバー114が、受信された資格証明書が以前に割り当てられた資格証明書と同じであると判定した場合、これは、新しい割り当てられた資格証明書がクライアントデバイスに対して生成されたものであるが、クライアントデバイスは、それらをまだ受信していないか、またはそれらの使用を開始していない(例えば、通信障害のため)ことを示すものとしてよい。したがって、処理はオペレーション1870Jに進むことができ、同期化サーバー114は(再び)最近割り当てられた資格証明書をクライアントデバイス104に送信し、その後、オペレーション1870Kが続き、同期化サーバー114は、受信された資格証明書が有効であると判定する。
次に図28Gを参照すると、図28Gは、第3の実施形態による割り当てられた資格証明書が有効であるかどうかを判定するためのプロセス1870の流れ図である。図28Fを参照しつつ説明されている実施形態と同様に、この実施形態は、資格証明書のローテーションが使用され、割り当てられた資格証明書の新しいセットが最近生成され、クライアントデバイスに伝達されている場合に適用可能である。さらに、この実施形態は、資格証明書の秘密部分がフロントエンドサーバー(例えば、登録サーバー112、同期化サーバー114、および/またはロギングサーバー116)側にハッシュ化形式で格納されている場合、また(いくつかの場合において)非ハッシュ化形式はリモートストレージ(例えば、ストレージ要素118)内に格納されている場合に適用可能である。このような場合、同期化サーバー114では、割り当てられた秘密のハッシュ化されたバージョンのみを格納しており、一般的には、クライアントデバイス側で割り当てられた資格証明書が必要になったときにクライアントデバイスに送り返すために割り当てられた資格証明書を再生成することはできないという新たな問題が発生する。割り当てられた資格証明書を再生成するために、同期化サーバー114は、リモートに格納されている非ハッシュ化資格証明書が存在している場合には非ハッシュ化資格証明書にアクセスし、またはいくつかの実施形態において、本明細書で説明されているように追加の処理を実行することができる(潜在的にセキュリティリスクを高める)。
オペレーション1870Oにおいて、同期化サーバー114は、受信された割り当てられた資格証明書から割り当てられた秘密を抽出する。オペレーション1870Pにおいて、同期化サーバー114は、抽出された割り当てられた秘密をハッシュ化する。同期化サーバー114は、ハッシュ関数が、割り当てられた資格証明書がクライアントデバイスに対して生成されたときにすでに使用されていたものと同じである限り、SHA-256一方向性ハッシュ関数などの好適なハッシュ関数を適用することができる。
次いで、処理はオペレーション1870Qに進み、同期化サーバー114は、抽出された割り当てられた秘密のハッシュを以前に割り当てられた資格証明書に対する割り当てられた秘密のハッシュ(すでに述べたように、フロントエンドサーバー内にキャッシュされ得る)と比較する。これらが同じである場合、クライアントデバイスは、猶予期間に正しい資格証明書を使用しており、したがって、処理はオペレーション1870Rに進むことができ、そこで、同期化サーバー114は、受信された資格証明書が有効であると判定する。
対照的に、これらが異なる場合、処理はオペレーション1870Nに進むことができ、抽出された割り当てられた秘密のハッシュは、最近割り当てられた資格証明書に対する割り当てられた秘密のハッシュ(すでに述べたように、やはりフロントエンドサーバー内にキャッシュされ得る)と比較される。これらが、この時点で同じでない場合、受信された資格証明書は、最近割り当てられた、または以前に割り当てられた資格証明書のいずれとも同じでなく、したがって、処理はオペレーション1870Tに進み、同期化サーバー114は、受信された資格証明書が無効であると判定する。
同期化サーバー114が、それらが同じであると判定した場合、これは、新しい割り当てられた資格証明書がクライアントデバイスに対して生成されたものであるが、クライアントデバイスは、それらをまだ受信していないか、またはそれらの使用を開始していない(例えば、通信障害のため)ことを示すものとしてよい。したがって、処理はオペレーション1870Uに進むことができ、同期化サーバー114は、最近割り当てられた資格証明書の暗号化バージョンを暗号解読する。図29Cを参照しつつ後で説明されるように、割り当てられた資格証明書が新規に生成される場合(ローテーション時)、割り当てられた資格証明書の暗号化バージョンは、フロントエンドサーバー内にハッシュ化バージョンと共に一時的に格納され得る(例えば、猶予期間中に)。割り当てられた資格証明書は、ハッシュ化バージョンから決定され得ないが(例えば、一方向性ハッシュ関数であるため)、暗号化バージョンから決定され得る。この様式で、フロントエンドサーバーは、割り当てられた資格証明書の未暗号化バージョンを格納することなく(比較的セキュリティが高くない)、また未暗号化バージョンのリモートに格納されているコピー(例えば、ストレージ要素118の)に頼ることなく、割り当てられた資格証明書を再生成することができる。
また図29Cを参照しつつ説明されているように、フロントエンドサーバー側に格納されている最近割り当てられた資格証明書は、リモートサーバー102およびクライアントデバイス104の両方に知られている好適なキーを使用して暗号化され得る。これは対称キー、非対称キー、または任意の他の好適なキーであってよい。特定の一実施形態において、最近割り当てられた資格証明書は、以前に割り当てられた資格証明書を使用して暗号化される。この様式で、フロントエンドサーバーは、キーを永久的に格納しておく必要はなく、むしろ、デバイスを認証する際に当然のことながらクライアントデバイスからキーを全く都合よく受信する(すなわち、オペレーション1870Oにおいて)。
暗号化された最近割り当てられた資格証明書が暗号解読された後、処理はオペレーション1870Vに進み、同期化サーバー114は、(今は暗号解読されてある)最近割り当てられた資格証明書をクライアントデバイス104に伝達する。次いで、処理はオペレーション1870Wに進むことができ、同期化サーバー114(または暗号化された資格証明書が格納されたフロントエンドサーバー)は、最近割り当てられた資格証明書(すなわち、暗号解読された資格証明書)を削除する。最近割り当てられた資格証明書をフロントエンドサーバーから削除することによって、これは、最近割り当てられた資格証明書が悪用される危険性を有利に低減することができる。次いで、処理はオペレーション1870Rに進み、同期化サーバー114は、受信された資格証明書が有効であると判定する。
図28Aから図28Gに示されている特定のオペレーションは、さまざまな実施形態により割り当てられた同期化サーバーと通信するようにクライアントデバイスを認証するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図28Aから図28Gに示されている個別のオペレーションは、個別のオペレーションに適してさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図29Aは、一実施形態による割り当てられた資格証明書をローテーションするためのプロセスの通信シーケンス1900を示す。オペレーション1902において、クライアントデバイス104は、リモートサーバー102との通信を確立する。この通信は、登録サーバー112、割り当てられた同期化サーバー114、ロギングサーバー116などのリモートサーバー102の任意のエンティティとの通信であってよい。オペレーション1904において、リモートサーバー102は、新規に割り当てられた資格証明書をクライアントデバイス104に伝達する。それに応答して、オペレーション1906において、クライアントデバイス104は、リモートサーバー102とのその後の通信において新規に割り当てられた資格証明書を使用し始める。
図29Bは、一実施形態によるクライアントデバイスが割り当てられた資格証明書をローテーションするプロセス1910の流れ図である。オペレーション1912において、クライアントデバイス104は、割り当てられた資格証明書を使用してリモートサーバー102と通信する。例えば、割り当てられた資格証明書は、オペレーション306を参照しつつ説明されているものなどの初期化プロセスの一部として登録サーバー112からクライアントデバイス104に送信されていてもよい。
リモートサーバー102との通信において、処理はオペレーション1914に進み、クライアントデバイス104は、それが新しい割り当てられた資格証明書を受信したかどうかを判定する。受信していない場合、処理はオペレーション1912に戻り、クライアントデバイス104は、割り当てられた資格証明書を使用してリモートサーバー102との通信を続ける。受信した場合、処理はオペレーション1916に進む。
オペレーション1916において、クライアントデバイス104は、セキュア接続を介してリモートサーバー102と通信しているかどうかを判定する。いくつかの実施形態では、クライアントデバイスは、セキュア接続のみを介して新しい割り当てられた資格証明書を受け入れる。しかし、他の実施形態では、クライアントデバイスは、非セキュア接続を介して新しい割り当てられた資格証明書を受け入れることができる。この特定の実施形態では、前者を説明しており、そこでは、クライアントデバイス104は、非セキュア接続を介してリモートサーバー102と通信していると判定した場合に、割り当てられた資格証明書を拒絶する。この特定の場合において、処理はオペレーション1912に戻り、クライアントデバイス104は、以前に割り当てられた資格証明書を使用してリモートサーバー102との通信を続けるが、他の場合には、クライアントデバイス104は、セキュア接続を確立することを試みること、現在の接続を閉じること、登録サーバー112との接続を確立することなど、異なる方法で応答することができる。
その一方で、クライアントデバイス104が、セキュア接続を介してリモートサーバー102と通信していると判定した場合、処理はオペレーション1918に進み、そこで、クライアントデバイス104は、以前に割り当てられた資格証明書を破棄し、オペレーション1920に進み、そこで、クライアントデバイス104は、リモートサーバー102から受信された新規に割り当てられた資格証明書を使用してリモートサーバー102との通信を続ける。
図29Cは、一実施形態によるリモートサーバーがクライアントデバイスに対する割り当てられた資格証明書をローテーションするプロセス1930の流れ図である。オペレーション1932において、リモートサーバー102は、クライアントデバイス104から割り当てられた資格証明書を受信し、それらを使用してクライアントデバイス104を認証する。オペレーション1934において、リモートサーバー102は、クライアントデバイスによって現在使用されている割り当てられた資格証明書が失効したかどうかを判定する。いくつかの実施形態では、割り当てられた資格証明書は、定期的に、例えば、毎週、毎月、毎年、1週間から1年までの範囲内の期間の後、1週間未満の期間内、または1年を超える期間内で失効する。他の実施形態では、割り当てられた資格証明書は、非定期的に、例えば、クライアントデバイス104がリモートサーバー102に特定の回数だけ接続した後に失効する。
リモートサーバー102が、割り当てられた資格証明書が失効していないと判定した場合、処理はオペレーション1932に戻り、リモートサーバー102は、現在割り当てられている資格証明書を使用してクライアントデバイス104から通信を受信し、認証することを続ける。失効している場合、処理はオペレーション1936に進むものとしてよい。
オペレーション1936において、リモートサーバー102は、セキュア接続を介してクライアントデバイス104と通信しているかどうかを判定する。いくつかの実施形態では、リモートサーバーは、セキュア接続のみを介して新しい割り当てられた資格証明書を生成し、送信する。しかし、他の実施形態では、リモートサーバーは、非セキュア接続を介して新しい割り当てられた資格証明書を生成し、送信することができる。この特定の実施形態では、前者を説明しており、そこでは、リモートサーバー102は、非セキュア接続を介してクライアントデバイス104と通信していると判定した場合に、新しい割り当てられた資格証明書を生成し送信することを拒絶する。この特定の場合において、処理はオペレーション1932に戻り、リモートサーバー102は、以前に割り当てられた資格証明書を使用してクライアントデバイス104との通信を続けるが、他の場合には、リモートサーバー102は、セキュア接続を確立することを試みること、現在の接続を閉じること、登録サーバー112との接続をクライアントデバイスに確立させることなど、異なる方法で応答することができる。
その一方で、リモートサーバー102が、セキュア接続を介してクライアントデバイス104と通信していると判定した場合、処理はオペレーション1938に進み、リモートサーバー102は、接続されたクライアントデバイス104に対する新しい割り当てられた資格証明書を生成する。すでに述べているように、割り当てられた資格証明書は、割り当てられた識別子および割り当てられた秘密を含むものとしてよい。割り当てられた識別子は、例えば、クライアントデバイスのシリアル番号を含み得る。特定の一実施形態において、シリアル番号は、リモートサーバー102に提示されている割り当てられた資格証明書から抽出され得る。さらに、割り当てられた秘密は、例えば、リモートサーバー102によって生成され得る乱数を含み得る。次いで、リモートサーバー102は、オペレーション1940において、新しい割り当てられた資格証明書をクライアントデバイスに送信し、いくつかの場合において、新しい割り当てられた資格証明書をリモートサーバー102側に格納することができる。
特定の一実施形態において、新規に割り当てられた資格証明書が悪用されるリスクを低減するために対策が講じられ得る。例えば、新規に割り当てられた資格証明書は、ストレージ要素118などの、リモートストレージに格納され得るが、新規に割り当てられた資格証明書の暗号化されハッシュ化されたバージョンは、フロントエンドサーバー(例えば、割り当てられた同期化サーバー114)側に格納され得る。
したがって、オペレーション1942において、リモートサーバー102は、新規に割り当てられた資格証明書をハッシュ化することができる。特に、リモートサーバー102は、前に説明されているハッシュ化アルゴリズムを使用して、資格証明書に含まれる割り当てられた秘密をハッシュ化することができる。オペレーション1944において、リモートサーバー102は、新規に割り当てられた資格証明書のハッシュを、同期化サーバー114のストレージ要素178などの、フロントエンドサーバー内に格納する。この様式で、ハッシュは素早くアクセスされ、図28Fを参照しつつ説明されているように受信された資格証明書のハッシュと比較され得る。
オペレーション1946において、リモートサーバー102は、新規に割り当てられた資格証明書を暗号化する。また図28Fを参照しつつ説明されているように、新規に割り当てられた資格証明書は、キーがリモートサーバー102およびクライアントデバイス104の両方に一般に知られている好適な暗号化アルゴリズムを使用して暗号化され得る。オペレーション1948において、新規に割り当てられた資格証明書の暗号化されたバージョンも、フロントエンドサーバー側に、いくつかの実施形態では割り当てられた資格証明書のハッシュと共に格納される。しかし、暗号化されたバージョンは、一時的に格納しておくこともでき、それらは、猶予期間の持続時間でのみ格納される。この様式で、クライアントデバイス104が以前に生成された資格証明書または新規に生成された資格証明書のいずれかを使用して認証され得る猶予期間において、リモートサーバー102は、新規に割り当てられた資格証明書の暗号化されたバージョンを使用して、新規に割り当てられた資格証明書を生成することができる。次いで、以前に割り当てられた資格証明書を使用して猶予期間中にクライアントデバイス104が自己を認証する場合、新規に割り当てられた資格証明書(未暗号化)がクライアントデバイス104に送信され得る。
暗号化された新規に割り当てられた資格証明書が格納された後、オペレーション1950において、リモートサーバー102は、新規に割り当てられた資格証明書を削除することができる。いくつかの実施形態では、リモートサーバーは、新規に割り当てられた資格証明書をフロントエンドサーバーから削除するが、(暗号化されていない、ハッシュ化されていない)新規に割り当てられた資格証明書のコピーをリモートストレージ内に維持する(バックアップ目的で)ことができる。
図29Aから図29Cに示されている特定のオペレーションは、さまざまな実施形態により割り当てられている資格証明書をローテーションするための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図29Aから図29Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図30Aは、一実施形態による拒絶された割り当てられた資格証明書を処理するためのプロセスの通信シーケンス2000を示す。オペレーション2002において、クライアントデバイス104は、同期化サーバー114に割り当てられた資格証明書を送信することによって同期化サーバー114(またはリモートサーバー102の他のエンティティ)との通信を確立することを試みる。オペレーション2004において、これらの割り当てられた資格証明書は拒絶され、したがって、同期化サーバー114は、割り当てられた資格証明書の拒絶をクライアントデバイス104に伝達する。その拒絶を受信すると、クライアントデバイス104は登録サーバーに戻り、割り当てられた資格証明書を再取得することを試み、これを、オペレーション2006における既定の資格証明書を登録サーバー112に伝達することによって行う。
図30Bは、一実施形態によるクライアントデバイスが拒絶された割り当てられた資格証明書を処理するプロセス2010の流れ図である。オペレーション2012において、クライアントデバイス104は、同期化サーバー114(またはリモートサーバー102の他のエンティティ)との接続を確立する。クライアントデバイス104は、例えば、オペレーション312で受信された同期化サーバー識別子などを使用して、接続を確立することができる。接続された後、割り当てられた資格証明書を送信する前に、オペレーション214において、クライアントデバイス104は、同期化サーバー114と確立した接続がセキュア(例えば、SSL、TSLなど)接続であるかどうかを判定することができる。セキュア接続でない場合、処理はオペレーション2016に進むことができ、クライアントデバイス104は、バックオフアルゴリズムを実行する。バックオフアルゴリズムを実行する際に、クライアントデバイス104は、同期化サーバー114とのセキュア接続を確立することを試みる前に徐々に長くなる期間を待つことができる。しかし、いくつかの実施形態では、クライアントデバイス104は、バックオフアルゴリズムを実施しないが、むしろ、例えば、定期的間隔で、同期化サーバー114とのセキュア接続を再確立することを連続的に試みることができる。
しかし、セキュア接続であると判定された場合、処理はオペレーション2018に進むことができる。オペレーション2018において、クライアントデバイス104は、割り当てられた資格証明書(例えば、割り当てられた資格証明書128F)を同期化サーバー114に伝達する。割り当てられた資格証明書は、典型的には、デバイス識別子およびデバイス秘密を含む。
次いで、処理はオペレーション2020に進むことができ、クライアントデバイスは、同期化サーバー114に伝達した割り当てられた資格証明書が同期化サーバー114によって正常に受け入れられた(すなわち、有効であると判定された)かどうかを判定する。例えば、クライアントデバイスは同期化サーバー114から拒絶を受信した場合、資格証明書が受け入れられなかったと判定することができる。受信しなかった場合、これは、資格証明書が受け入れられたと判定することができる。
割り当てられた資格証明書が受け入れられた場合、処理はオペレーション2022に進むことができ、クライアントデバイスは、割り当てられた資格証明書を使用して同期化サーバー通信する。受け入れられなかった場合、処理はオペレーション2024に進むものとしてよく、クライアントデバイス104は、割り当てられた資格証明書を破棄する。この場合、クライアントデバイス104は、その割り当てられた資格証明書が無効であること、および新しい割り当てられた資格証明書を取得する必要があることを予期する。したがって、クライアントデバイスは、同期化サーバー114から切断し、オペレーション2026において、登録サーバーから新しい割り当てられた資格証明書を取得する。新しい割り当てられた資格証明書を取得するために、クライアントデバイスは、例えば、図28Bを参照しつつ説明されているような処理を実行することができる。
いくつかの実施形態では、クライアントデバイス104は、割り当てられた資格証明書を破棄し、新しい資格証明書を取得する前に、同期化サーバーにより複数回、割り当てられた資格証明書の使用を試みることができることは理解されるであろう。さらに、登録サーバーおよび同期化サーバーの処理は、図28Cおよび図28Dでそれぞれ説明されているものと類似している場合があるので、この特定の実施形態についてはさらに説明することはしない。
図30Aから図30Bに示されている特定のオペレーションは、拒絶された割り当てられた資格証明書を処理するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図30Aから図30Bに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図31Aは、一実施形態による情報をロギングサーバーに伝達するためのプロセスの通信シーケンス2100を示す。オペレーション2102において、クライアントデバイス102は、既定のまたは割り当てられた資格証明書を送信することによってロギングサーバー116との通信を確立し、これらの資格証明書は有効であるかまたは無効であるものとすることができる。このような資格証明書を提供した後に、オペレーション2104において、クライアントデバイス104は、ログ情報をロギングサーバー116に伝達する。それに応答して、オペレーション2106において、ロギングサーバー116は、ログ情報が受け入れられていることを認めるアクノリッジメントを送信する。
図31Bは、一実施形態によるクライアントデバイスがログ情報をロギングサーバーに伝達するプロセス2110の流れ図である。オペレーション2112において、クライアントデバイス104は、ロギングサーバー116との接続を確立する。接続を確立する際に、クライアントデバイスはセキュア接続(例えば、SSL、TSL、または他のセキュア接続)、または非セキュア接続を確立することができる。
クライアントデバイス104は、ロギングサーバー116に接続した後(または場合によってはその前)に、割り当てられた資格証明書(例えば、割り当てられた資格証明書128F)を有しているかどうかを判定する。有していない場合、処理はオペレーション2116に進むことができ、クライアントデバイス104は、既定の資格証明書(例えば、既定の資格証明書128E)をロギングサーバー116に伝達する。有している場合、処理はオペレーション2118に進むことができ、クライアントデバイス104は、割り当てられた資格証明書(例えば、割り当てられた資格証明書128F)をロギングサーバー116に伝達する。いずれの場合も、次いで、処理はオペレーション2120に進み、クライアントデバイスは、ログ情報をロギングサーバー116に送信し、いくつかの場合にオペレーション2122において、ログ情報が正常に伝達されたことを認めるアクノリッジメントを受信する。
図31Aおよび図31Bを参照しつつ説明されている実施形態は、クライアントデバイスがログ情報をロギングサーバーに伝達するという文脈におけるものであるが、類似のオペレーションは、クライアントデバイスが情報をリモートサーバー102のエンティティに伝達するときに実行され得ることは理解されるであろう。例えば、クライアントデバイス104は、情報のバケットを割り当てられた同期化サーバー114に送信することを望んでいる場合に、最初に、割り当てられた資格証明書を送信することを試み、それが何も有していない場合に、既定の資格証明書を送信することができる。
図31Cを参照すると、図31Cは、一実施形態によるロギングサーバーがクライアントデバイスから伝達された情報を受信し、分類するプロセス2130の流れ図である。ロギングサーバーは、この実施形態において、クライアントデバイス側の認証のレベルに基づき情報を分類する。オペレーション2132において、ロギングサーバー116は、クライアントデバイス104との接続を確立する。いくつかの実施形態では、接続はセキュア接続であり、他の実施形態では、接続は非セキュア接続であるものとしてよい。
オペレーション2134において、ロギングサーバー116は、クライアントデバイス104からデバイス資格証明書を受信する。デバイス資格証明書は、既定の資格証明書、割り当てられた資格証明書、または他の何らかの種類の資格証明書とすることができる。オペレーション2136において、ロギングサーバーは、クライアントデバイス104からロギング情報を受信する。
ロギングサーバー116は、デバイス資格証明書およびロギング情報を受信した後、オペレーション2138において、受信されたデバイス資格証明書が割り当てられた資格証明書であるかどうかを判定する。そうでない場合、処理はオペレーション2140に進み、ロギングサーバーは、受信されたロギング情報を「未認証」デバイスから来たものとして分類する。さもなければ、処理はオペレーション2142に進み、ロギングサーバー116は、クライアントデバイス104から受信された割り当てられた資格証明書が有効かどうかを判定する。このような判定を行うためのさまざまな技術は、本明細書で説明されており、このような技術はどれも、ここで適用され得る。ロギングサーバー116が、割り当てられた資格証明書が有効でないと判定した場合、処理はオペレーション2140に進み、これは、受信されたロギング情報を「未認証」デバイスから来たものとして分類する。有効でないと判定しない場合、処理はオペレーション2144に進み、これは、受信されたロギング情報を「認証済み」デバイスから来たものとして分類する。
いくつかの実施形態では、「未認証」および「認証済み」以外の特徴付けの追加の種類があり得ることは理解されるであろう。例えば、有効な割り当てられた資格証明書が最高レベルの認証に関連付けられる、有効な既定の資格証明書が中間レベルの認証に関連付けられる、および無効な資格証明書が最低レベルの認証に関連付けられる、の3つのレイヤの特徴付けがあり得る。別の例として、ロギング情報は(それに加えて、または代替的に)、ロギング情報がセキュア接続で伝達されたかまたは非セキュア接続で伝達されたかに基づき特徴付けられるものとしてよく、セキュア接続は、非セキュア接続よりも高いレベルの認証であることを示す。
図31Aから図31Cに図示されている特定のオペレーションは、ロギング情報を伝達し、分類するための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図31Aから図31Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
図32Aは、一実施形態によるクライアントデバイスが異なる種類の情報にアクセスするためのプロセスの通信シーケンス2200を示す。クライアントデバイスと特定のユーザーアカウントとのペアリングが行われたときに、クライアントデバイスは、そのアカウントに関連付けられている情報へのアクセスを取得することができる。そうでない場合、クライアントデバイスは、そのような情報へのアクセスを拒否され得る。オペレーション2202において、クライアントデバイス104は、割り当てられた資格証明書を使用して同期化サーバー114との通信を確立する。それに応答して、オペレーション2204において、同期化サーバー114は、クライアントデバイス104とペアリングされたユーザーアカウント、または任意のアカウントのいずれかへのアクセスをクライアントデバイス104に提供する。
図32Bは、一実施形態によるクライアントデバイスが異なる種類の情報にアクセスするためのプロセス2210の流れ図である。オペレーション2212において、クライアントデバイス104は、割り当てられた資格証明書を同期化サーバーに送信する。オペレーション2214において、クライアントデバイス104は、クライアントデバイス104に関連付けられているユーザーアカウントへのアクセスを取得したかどうかを判定する。取得していない場合、クライアントデバイス104は、オペレーション2216において任意のアカウントにアクセスすることができる。いくつかの実施形態では、任意のアカウントにアクセスする代わりに、クライアントデバイス104は、他の何らかの形で、それが伝達し、かつ/または同期化サーバー114から受信し得る情報の種類の点で制限され得る。オペレーション2214において、クライアントデバイス104が、ユーザーアカウントへのアクセスを取得したと判定した場合、処理はオペレーション2218に進み、クライアントデバイスは、ユーザーアカウントへのアクセスを取得する。
図32Cは、一実施形態による同期化サーバーが異なる種類の情報へのアクセスをクライアントデバイスに提供するためのプロセス2220の流れ図である。オペレーション2222において、同期化サーバー114は、有効な割り当てられた資格証明書をクライアントデバイス104から受信する。いくつかの実施形態では、有効な割り当てられた資格証明書は、セキュア接続を介して受信されなければならない。オペレーション2224において、同期化サーバー114は、クライアントデバイスがユーザーカウントとペアリングされているかどうかを判定する。例えば、同期化サーバー114は、受信されたデバイス識別子(例えば、割り当てられた資格証明書に含まれるデバイス識別子)をデバイス識別子/ユーザーアカウントマップ178Dと比較して、ユーザーアカウントがデバイス識別子に関連付けられているかどうかを判定することができる。関連付けられていない場合、処理はオペレーション2226に進むことができ、同期化サーバー114は、クライアントデバイスに、ほとんどの実施形態において機密情報を含まない任意のアカウントへのアクセスを提供する。対照的に、デバイス識別子に関連付けられているユーザーアカウントがある場合、オペレーション2228において、同期化サーバー114は、クライアントデバイス104に、そのユーザーアカウントへのアクセスを提供する。
図32Aから図32Cに示されている特定のオペレーションは、クライアントデバイスが異なる種類の情報にアクセスするための特定のプロセスを構成することは理解されるであろう。オペレーションの他のシーケンスも、代替的実施形態により実行され得る。例えば、本発明の代替的実施形態は、上で概要を述べたオペレーションを異なる順序で実行することができる。さらに、図32Aから図32Cに示されている個別のオペレーションは、個別のオペレーションに適しているさまざまなシーケンスで実行され得る複数のサブオペレーションを含み得る。さらに、特定の用途に応じて追加のオペレーションを加えたり、既存のオペレーションを取り除いたりできる。当業者であれば、多くの変更形態、修正形態、および代替的形態を認識し、理解するであろう。
デバイス、サーバー、およびシステムの例
図33は、例示的な一実施形態による監視デバイス108のコンポーネントを示している。図33を参照しつつ説明されているコンポーネントは、図4を参照しつつクライアントデバイス104について説明されているコンポーネントに加えたもの、またはその代替となるものであってよいことは理解されるであろう。この特定の例では、監視デバイス108は、インテリジェント型マルチセンサーネットワーク接続デバイスである。監視デバイス108は、1つまたは複数のセンサー2302、ユーザーインターフェースコンポーネント2304、電源(例えば、電源接続部2306および/またはバッテリ2308を含む)、通信コンポーネント2310、モジュール式ユニット(例えば、ドッキングステーション2312および交換可能モジュール2314を含む)、およびインテリジェント型コンポーネント2316を含むことができる。特定のセンサー2302、ユーザーインターフェースコンポーネント2304、電源構成、通信コンポーネント2310、モジュール式ユニットおよび/またはインテリジェント型コンポーネント2316は、いくつものデバイス108にまたがって同じ、または類似のものであり得るか、またはデバイスの種類もしくはモデルに応じて異なり得る。
例えば、限定はしないが、デバイス108内の1つまたは複数のセンサー2302は、例えば、加速度、温度、湿度、水分、供給電力、近接度、外部運動、デバイス運動、音波信号、超音波信号、光信号、火災、煙、一酸化炭素、全地球測位衛星(GPS)信号、無線周波(RF)、または他の電磁信号もしくは場を検出することができるものとしてよい。したがって、例えば、センサー2302は、温度センサー、湿度センサー、ハザード関係センサーもしくは他の環境センサー、加速度計、マイクロフォン、カメラも含めた光センサー(例えば、電荷結合素子またはビデオカメラ)、能動的または受動的放射線センサー、GPS受信機、または無線周波識別検出器を含み得る。図33は、単一のセンサーを使用する実施形態を示しているが、多くの実施形態は複数のセンサーを含む。いくつかの場合において、デバイス108は、1つまたは複数の一次センサーおよび1つまたは複数の二次センサーを備える。一次センサーは、デバイスのコアオペレーション(例えば、サーモスタットで温度を感知するか、または煙検出器で煙を検出する)の中心にあるデータを感知することができる。二次センサーは、他の種類のデータ(例えば、運動、光、または音)を感知することができ、これはエネルギー効率の目的またはスマートオペレーションの目的に使用され得る。いくつかの場合において、平均的なユーザーは、二次センサーの存在に気づくことすらない場合もある。
デバイス108内の1つまたは複数のユーザーインターフェースコンポーネント2304は、視覚的ディスプレイ(例えば、薄膜トランジスタディスプレイまたは有機発光ダイオードディスプレイ)および/またはスピーカーを介して情報をユーザーに提示するように構成され得る。ユーザーインターフェースコンポーネント2304は、タッチスクリーン、ボタン、スクロールコンポーネント(例えば、移動可能または仮想リングコンポーネント)、マイクロフォン、またはカメラ(例えば、ジェスチャーを検出するためのもの)などの、ユーザーからの情報を受信するための1つまたは複数のユーザー入力コンポーネントも含むことができる。一実施形態において、ユーザー入力コンポーネント2304は、クリックして回転する環状リングコンポーネントを含み、ユーザーは、このコンポーネントを、リングを回転させること(例えば、設定を調整するために)および/またはリングを内向きにクリックすること(例えば、調整された設定を選択するか、またはオプションを選択するため)によってインタラクティブに操作することができる。別の実施形態において、ユーザー入力コンポーネント2304は、カメラを含み、これにより、ジェスチャーを検出することができる(例えば、デバイスの電力またはアラーム状態が変わることを示すため)。
デバイス108内の電源コンポーネントは、電源接続部2306および/またはローカルバッテリ2308を含むことができる。例えば、電源接続部2306は、デバイス108を線間電圧源などの電源に接続することができる。いくつかの場合において、AC電源への接続部2306は、(例えば、充電式)ローカルバッテリ2308を繰り返し充電するために使用され得、この場合、バッテリ2308は、後で、AC電力切断または他の電力不足シナリオが生じた場合に必要ならば過剰なDC電力を供給するために使用され得る。
デバイス108内の通信コンポーネント2310は、デバイス108が本明細書で説明されている別のデバイスまたは携帯型ユーザーデバイスなどの、中央サーバーもしくはリモートデバイスと通信することを可能にするコンポーネントを含み得る。通信コンポーネント2310により、デバイス108は、例えば、非限定的な例としてWi-Fi、ZigBee、3G/4Gワイヤレス、CAT6有線イーサネット(登録商標)、HomePlugもしくは他の電力線通信方法、電話、または光ファイバーを介して通信することが可能である。通信コンポーネント2310は、ワイヤレスカード、イーサネット(登録商標)プラグ、または他のトランシーバ接続を含み得る。
デバイス108内のモジュール式ユニットは、静的物理的接続部、および交換可能モジュール2314を含み得る。したがって、モジュール式ユニットは、デバイス108を完全に取り付け直すことなく(例えば、配線を温存するため)、交換可能モジュール2314をアップグレードする機能を提供することができる。静的物理的接続部は、建物構造に取り付けることができるドッキングステーション2312(インターフェースボックスとも称され得る)を含み得る。例えば、ドッキングステーション2312は、ねじで壁に装着するか、または接着剤で天井に張り付けることが可能である。ドッキングステーション2312は、いくつかの場合において、建物構造の一部を貫通するものとしてもよい。例えば、ドッキングステーション2312は、壁の石膏ボードにあけた穴を介して壁の背後の配線(例えば、120V線間電圧線)に接続することができる。ドッキングステーション2312は、電源接続部回路2306および/またはAC-DC給電回路などの回路を含み、またユーザーが高電圧線に対して曝されることを防ぐことができる。いくつかの場合において、ドッキングステーション2312は、デバイスの種類またはモデルに固有のものであり、例えば、サーモスタットデバイスは、煙検出器デバイスと異なるドッキングステーションを含む。いくつかの場合において、ドッキングステーション2312は、複数の種類および/またはモデルのデバイス108にまたがって共有することもできる。
モジュール式ユニットの交換可能モジュール2314は、デバイスのいくつかのまたはすべてのセンサー2302、プロセッサ、ユーザーインターフェースコンポーネント2304、バッテリ2308、通信コンポーネント2310、インテリジェント型コンポーネントなどを含み得る。交換可能モジュール2314は、ドッキングステーション2312に取り付ける(例えば、差し込むか、または接続する)ように構成され得る。いくつかの場合において、交換可能モジュール2314のセットが生産されるが、その際に、機能、ハードウェア、および/またはソフトウェアは交換可能モジュール2314同士で異なる。したがって、ユーザーは、すべてのデバイスコンポーネントを交換しなくても、またはデバイス108を完全に取り付け直さなくても、交換可能モジュール2314を容易にアップグレードまたは交換することができる。例えば、ユーザーは、インテリジェント機能およびソフトウェアの能力が制限されている最初の交換可能モジュールを含む安価なデバイスから始めることができる。その後、ユーザーは、より能力の高い交換可能モジュールを含むようにデバイスを容易にアップグレードすることができる。別の例として、ユーザーは地下室にModel #1デバイスを、リビングルームにModel #2デバイスを有しており、リビングルームのデバイスをModel #3交換可能モジュールを含むようにアップグレードする場合、Model #2交換可能モジュールを地下室に移動して既存のドッキングステーションに接続することができる。次いで、Model #2交換可能モジュールは、例えば、新しい場所を識別するためにイニシエーションプロセスを開始することができる(例えば、ユーザーインターフェースを介してユーザーに情報を要求することによって)。
デバイスのインテリジェント型コンポーネント2316は、さまざまな異なるデバイス機能のうちの1つまたは複数をサポートすることができる。インテリジェント型コンポーネント2316は、一般的に、本明細書で説明されている有利な機能のうちの1つまたは複数を実行する、かつ/または実行させるように構成され、かつプログラムされた1つまたは複数のプロセッサを含む。インテリジェント型コンポーネント2316は、ローカルメモリ(例えば、フラッシュメモリ、ハードドライブ、ランダムアクセスメモリ)内に格納されているコンピュータコードを実行する汎用プロセッサ、専用プロセッサもしくは特定用途向け集積回路、これらの組み合わせの形態で、かつ/または他の種類のハードウェア/ファームウェア/ソフトウェア処理プラットフォームを使用して実装され得る。インテリジェント型コンポーネント2316は、Asynchronous Java(登録商標)script and XML (AJAX)または類似のプロトコルを使用してクラウドサーバーから提供される命令を実行するJava(登録商標)仮想マシン(JVM)を稼働させることなどで、中央サーバーまたはクラウドベースシステムによってリモートで実行されるか、または制御されるアルゴリズムのローカライズされたバージョンもしくは対応物としてさらに実装され得る。例えば、インテリジェント型コンポーネント2316は、特定の人によって占有されているかどうか、または特定の人数の人々によって占有されているかどうか(例えば、1つまたは複数の閾値に関して)を含めて、場所(例えば、家もしくは部屋)が占有されている時点を検出するように構成されたインテリジェント型コンポーネント2316であってよい。そのような検出は、例えば、マイクロフォン信号を分析すること、ユーザーの移動(例えば、デバイスの前の)を検出すること、ドアもしくは車庫の扉の開閉を検出すること、ワイヤレス信号を検出すること、受信信号のIPアドレスを検出すること、または時間窓内の1つまたは複数のデバイスの動作を検出することによって行われ得る。インテリジェント型コンポーネント2316は、特定の占有者または物体を識別するために画像認識技術を含むことができる。
いくつかの場合において、インテリジェント型コンポーネント2316は、所望の設定を予測し、かつ/またはそれらの設定を実施するように構成され得る。例えば、存在検出に基づき、インテリジェント型コンポーネント2316は、例えば、家に誰もいないとき、もしくは特定の部屋内で節電するように、またはユーザーの選好(例えば、一般的な自宅選好またはユーザー特有の選好)に合わせるようにデバイス設定を調整することができる。別の例として、インテリジェント型コンポーネント2316は、特定の人、動物、または物体(例えば、子供、ペット、またはなくした物体)の検出に基づき、人、動物、または物体の位置を示す音響的もしくは視覚的インジケータを起動するか、または特定の条件下で(例えば、夜間もしくは照明が消えているときに)認識されていない人が検出された場合にアラームもしくはセキュリティ機能を起動することができる。さらに別の例として、インテリジェント型コンポーネント2316は、ユーザー設定の時間毎、週毎、さらには季節毎の傾向を検出して、設定をしかるべく調整することができる。例えば、インテリジェント型コンポーネント2316は、特定のデバイスが平日毎に6:30amにオンにされること、またはデバイス設定が最後の3時間にわたって高設定から低設定に徐々に調整されることを検出することができる。次いで、インテリジェント型コンポーネント2316は、デバイスが平日毎に6:30amにオンにされること、または設定がより長い期間にわたって徐々に下げ続けるべきであることを予測することができる。
いくつかの場合において、デバイスは、第1のデバイスによって検出された事象が第2のデバイスのアクションに影響を及ぼすように相互作用することができる。例えば、第1のデバイスは、ユーザーが車庫に入ったことを検出することができる(例えば、車庫内の運動を検出すること、車庫内の照明の変化を検出すること、または車庫の扉が開いたことを検出することによって)。第1のデバイスは、この情報を第2のデバイスに送信することができ、これにより、第2のデバイスは、例えば、家の温度設定、照明設定、音楽設定、および/または防犯アラーム設定を調整することができる。別の例として、第1のデバイスは、ユーザーが正面玄関に接近していることを検出することができる(例えば、運動または急な照明パターンの変化を検出することによって)。第1のデバイスは、例えば、一般的な音響的または視覚的信号を提示するか(例えば、ドアベルが鳴るなど)、または場所特有の音響的または視覚的信号を提示する(例えば、ユーザーが占有している部屋の中の訪問者の存在を告知するため)ことができる。
いくつかの実施形態における監視デバイス108は、図33を参照しつつ説明されているコンポーネント(および/または図4を参照しつつ説明されているコンポーネント)を含むインテリジェント型マルチセンサーネットワーク接続デバイスである。しかし、当業者であれば、そのようなデバイスは、図33に示されているものよりも少ない、または多い数のコンポーネントを有して等しく適切に動作できることを理解するであろう。したがって、図33のシステム108の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を限定するものとしてみなされるべきでない。
図34は、本明細書でさらに説明されているデバイス、方法、システム、サービス、および/またはコンピュータプログラム製品のうちの1つまたは複数が適用可能なスマートホーム環境2400の一例を示している。図示されているスマートホーム環境は、構造物2401を含み、これは例えば、家、オフィスビル、車庫、またはトレーラーハウスを含み得る。デバイスは、アパート、コンドミニアム、またはオフィススペースなどの、構造物2401全体を含むわけではないスマートホーム環境内に組み込まれ得ることは理解されるであろう。さらに、スマートホーム環境は、実際の構造物2401の外部のデバイスを制御し、かつ/またはそれに結合され得る。実際、スマートホーム環境内の複数のデバイスは、構造物2401内に物理的に存在する必要は全くない。例えば、プールヒーターまたは灌漑システムを制御するデバイスは、構造物2401の外部に配置され得る。
図示されている構造物2401は、壁2403を介して互いに少なくとも部分的に隔てられている、複数の部屋2402を含む。壁2403は、内壁または外壁を含むことができる。それぞれの部屋は、床2404と天井2405とをさらに含むことができる。デバイスは、壁2403、床または天井に装着され、一体化され、かつ/または支持され得る。
図34に示されているスマートホームは、スマートホームのさまざまな有益な目的を達成するために互いに、かつ/またはリモートサーバーシステムと継ぎ目なく一体化することができるインテリジェント型マルチセンサーネットワーク接続デバイスを含む複数のクライアントデバイスを含む。スマートホーム環境および/または図34に示されているデバイスのうちの1つ、複数、またはそれぞれは、図33を参照しつつ説明されているような1つまたは複数のセンサー、ユーザーインターフェース、電源、通信コンポーネント、モジュール式ユニット、およびインテリジェント型コンポーネントを含むことができる。さらに、図34に示されているデバイスのうちの1つ、複数、またはそれぞれは、本明細書で開示されている技術を使用して互いに、かつ/またはリモートサーバーと同期することができ、また本明細書で開示されている技術を使用してリモートサーバーに対して同一性を認証するように動作可能であるものとしてよい。
インテリジェント型マルチセンサーネットワーク接続サーモスタット2406は、周囲気候特性(例えば、温度および/または湿度)を検出し、冷暖房空調設備(HVAC)システム2407を制御することができる。1つまたは複数のインテリジェント型ネットワーク接続マルチセンサーハザード検出ユニット2408は、家庭環境内の危険な物質および/または危険な状態(例えば、煙、火、または一酸化炭素)の存在を検出することができる。「スマートドアベル」と称することができる、1つまたは複数のインテリジェント型マルチセンサーネットワーク接続通用門インターフェースデバイス2409は、人がある場所に接近する、またはある場所から出て行くのを検出し、可聴機能を制御し、音響的または視覚的手段を介して人が接近する、もしくは出て行くのを告知し、または防犯システムの設定を制御する(例えば、防犯システムを作動または解除するため)ことができる。
複数のインテリジェント型マルチセンサーネットワーク接続壁面照明スイッチ2410のそれぞれは、周囲照明状態を検出し、室内占有状態を検出し、1つまたは複数の照明の電力および/または減光状態を制御することができる。いくつかの場合において、照明スイッチ2410は、天井の扇風機などの扇風機の電力状態または速度をさらに、または代替的に制御することができる。複数のインテリジェント型マルチセンサーネットワーク接続壁コンセントインターフェース2411のそれぞれは、部屋またはエンクロージャの占有を検出し、1つまたは複数の壁コンセントへの電力の供給を制御する(例えば、家の中に誰もいない場合に電力をコンセントに供給しないように)ことができる。スマートホームは、冷蔵庫、ストーブおよび/またはオーブン、テレビ、洗濯機、乾燥機、照明(構造物2401の内側および/または外側)、ステレオ、インターコムシステム、車庫扉開閉装置、床の扇風機、天井の扇風機、家全体の扇風機、壁面設置型エアコン、プールヒーター2414、灌漑システム2416、防犯システムなどの、複数のインテリジェント型マルチセンサーネットワーク接続アプライアンス2412をさらに含むことができる。
1つまたは複数のアクセスデバイスは、LAN、WAN、または他のワイヤレスもしくは有線通信ネットワークのいずれかを通じてクライアントデバイスと通信するように動作可能であるものとしてよい。例えば、アクセスデバイス2420は、スマートホーム環境2400内の1つまたは複数のクライアントデバイスと通信することができ、アクセスデバイス2422は、インターネット2400を介してスマートホーム環境内のクライアントデバイスのうちの1つまたは複数と通信することができる。すべてのクライアントデバイスおよびアクセスデバイスは、リモートサーバー2424とも通信することもでき、これにより、本明細書で説明されているように、すべてのデバイスにおける状態の同期化および/またはデバイスの認証を円滑にすることができる。図34の説明では、特定のデバイスに関連付けられている特定のセンサーおよび機能を識別することができるが、さまざまなセンサーおよび機能(明細書全体を通して説明されているものなどの)はどれもデバイスに組み込むことができることは理解されるであろう。
処理および感知機能を収容することに加えて、スマートホーム環境2400内のデバイスのそれぞれは、述べたように、スマートホーム環境2400内の任意の他のデバイスと、さらには、アクセスデバイス2422および/またはリモートサーバー2424などのスマートホーム環境2400の外部にあるデバイスと、データ通信および情報共有を行うことができる。これらのデバイスは、さまざまな特注、または標準的なワイヤレスプロトコル(Wi-Fi、ZigBee、6LoWPANなど)および/またはさまざまな特注または標準的な有線プロトコル(CAT6 Ethernet(登録商標)、HomePlugなど)を介して通信を送受信することができる。壁コンセントインターフェース2411は、ワイヤレスまたは有線リピータとして使用することができ、かつ/または(i)ACコンセントに差し込まれ、Homeplugまたは他の電力線プロトコルを使用して通信するデバイスと、(ii)ACコンセントに差し込まれていないデバイスとの間のブリッジとして機能し得る。
例えば、第1のデバイスは、ワイヤレスルーター2434を介して第2のデバイスと通信することができる。デバイスは、インターネット2436などの、ネットワークへの接続を介してリモートデバイスとさらに通信することができる。インターネット2436を通じて、デバイスは中央(すなわち、リモート)サーバーまたはクラウドコンピューティングシステム2424と通信することができる。リモートサーバーまたはクラウドコンピューティングシステム2424は、デバイスに関連付けられている製造業者、サポートエンティティ、またはサービスプロバイダと関連付けられ得る。一実施形態において、ユーザーは、電話またはインターネット接続コンピュータなどの他の通信手段を使用することなくデバイス自体を使用してカスタマーサポートとコンタクトをとることができるものとしてよい。さらに、ソフトウェア更新は、リモートサーバーまたはクラウドコンピューティングシステム2424からデバイスに自動的に送信され得る(例えば、利用可能になったとき、購入したとき、または定期的間隔で)。
さらにデバイスのネットワーク接続は、ユーザーがデバイスの近くにいない場合であっても、ユーザーがデバイスをインタラクティブに操作することを可能にする。例えば、ユーザーは、コンピュータ(例えば、デスクトップコンピュータ、ラップトップコンピュータ、もしくはタブレット)または他の携帯型電子デバイス(例えば、スマートフォン)(例えば、アクセスデバイス2422)を使用してデバイス(例えば、サーモスタット2406)と通信することができる。ウェブページまたはアプリは、ユーザーからの通信を受信し、通信に基づきデバイスを制御し、かつ/またはデバイスの動作に関する情報をユーザーに提示するように構成され得る。例えば、ユーザーは、デバイスに対する現在の設定点温度を見て、コンピュータを使用してそれを調整することができる。ユーザーは、このリモート通信の間は構造物内にいてもよいし、または構造物の外部にいてもよい。
スマートホーム環境2400は、壁コンセントインターフェース2411を使って、粗くはあるが(ON/OFF)、制御できる古い従来型の洗濯機/乾燥機、および冷蔵庫などの、さまざまな非通信型のレガシーアプライアンス2430も含むことができる。スマートホームは、ハザード検出ユニット2408または照明スイッチ2410によって供給されるIR信号によって制御され得る、IR制御壁面設置型エアコンまたは他のIR制御デバイスなどの、さまざまな部分的な通信を行うレガシーアプライアンス2432をさらに含むことができる。
いくつかの実施形態におけるスマートホーム2400は、リモートサーバーを介して互いに通信し、同期化を実行するようにすべて動作可能である多数のクライアントデバイスおよびアクセスデバイスを含む環境である。しかし、当業者であれば、そのような環境は、図34に示されているものよりも少ない、または多い数のコンポーネントを有して等しく適切に動作できることを理解するであろう。したがって、図34のスマートホーム環境2400の図は、本質的に例示的であるとみなされ、本発明の教示の範囲を限定するものとしてみなされるべきでない。
図35は、一実施形態による専用コンピュータシステム2500を示している。本明細書で説明されているリモートサーバー102、監視デバイス108、および/またはアクセスデバイス110などのさまざまなエンティティは、そのようなコンピュータシステムとして実装され得る。上記のプロセスは、上述の方法およびコンポーネントのアクションを実行するようにコンピュータシステムに指令するコンピュータプログラム製品によって実装され得る。それぞれのそのようなコンピュータプログラム製品は、対応するアクションを実行するようにコンピュータシステムのプロセッサに指令するコンピュータ可読記録媒体上に具現化された命令(コード)のセットを備えることができる。これらの命令は、逐次的に、または並行して(異なる処理スレッドなどの下で)、またはこれらの組み合わせで実行するように構成され得る。
専用コンピュータシステム2500は、コンピュータ2502、コンピュータ2502に結合されたモニター2504、コンピュータ2502に結合された(オプションの)1つまたは複数の追加のユーザー出力デバイス2504、コンピュータ2502に結合された1つまたは複数のユーザー入力デバイス2506(例えば、キーボード、マウス、トラックボール、タッチスクリーン)、コンピュータ2502に結合されたオプションの通信インターフェース2508、コンピュータ2502内の有形のコンピュータ可読メモリに格納されているコンピュータプログラム製品2510を備える。コンピュータプログラム製品2510は、上で説明されている方法を実行するようにシステム2500に指令する。コンピュータ2502は、バスサブシステム2514を介して多数の周辺デバイスと通信する1つまたは複数のプロセッサ2512を含むことができる。これらの周辺デバイスは、ユーザー出力デバイス2504、ユーザー入力デバイス2506、通信インターフェース2508、および有形のコンピュータ可読メモリの形態をとる、ランダムアクセスメモリ(RAM)2514および不揮発性ストレージドライブ2516(例えば、ディスクドライブ、光ドライブ、ソリッドステートドライブ)などの、ストレージサブシステムを含み得る。
コンピュータプログラム製品2510は、コンピュータ2502にアクセス可能な不揮発性ストレージドライブ2516または別のコンピュータ可読記録媒体に格納され、メモリ2514内にロードされ得る。それぞれのプロセッサ2512は、Intel(登録商標)またはAdvanced Micro Devices, Inc.(登録商標)などのマイクロプロセッサを備え得る。コンピュータプログラム製品2510をサポートするために、コンピュータ2502は、上述のコンポーネントとの製品2510の通信、さらにはコンピュータプログラム製品2510をサポートする上述のコンポーネントの間の通信を処理するオペレーティングシステムを稼働させる。オペレーティングシステムの例として、Microsoft CorporationのWindows(登録商標)など、Sun MicrosystemsのSolaris(登録商標)、LINUX(登録商標)、およびUNIX(登録商標)などが挙げられる。
ユーザー入力デバイス2506は、情報をコンピュータシステム2502に入力するための可能なあらゆる種類のデバイスおよびメカニズムを含む。これらは、キーボード、キーパッド、マウス、スキャナー、デジタルドローイングパッド、ディスプレイに組み込まれたタッチスクリーン、音声認識システムなどのオーディオ入力デバイス、マイクロフォン、および他の種類の入力デバイスを含み得る。さまざまな実施形態において、ユーザー入力デバイス2506は、典型的には、コンピュータマウス、トラックボール、トラックパッド、ジョイスティック、ワイヤレスリモート、ドローイングタブレット、音声コマンドシステムとして具現化される。ユーザー入力デバイス2506は、典型的には、ユーザーがボタンのクリックなどのコマンドを介して、モニター2504上に現れるオブジェクト、アイコン、およびテキストなどを選択することを可能にする。ユーザー出力デバイス2504は、情報をコンピュータシステム2502から出力するための可能なあらゆる種類のデバイスおよびメカニズムを含む。これらは、ディスプレイ(例えば、モニター2504)、プリンタ、オーディオ出力デバイスなどの非視覚的ディスプレイ、などを含み得る。
通信インターフェース2508は、他の通信ネットワーク2518およびデバイスへのインターフェースを提供し、他のシステム、WAN、および/またはインターネットからデータを受信し、これらにデータを送信するためのインターフェースとして使用され得る。通信インターフェース2508の実施形態は、典型的には、イーサネット(登録商標)カード、モデム(電話、衛星、ケーブル、ISDN)、(非同期)デジタル加入者回線(DSL)ユニット、Fire Wire(登録商標)インターフェース、USB(登録商標)インターフェース、およびワイヤレスネットワークアダプタなどを含む。例えば、通信インターフェース2508は、コンピュータネットワーク、またはFire Wire(登録商標)バスなどに結合され得る。他の実施形態では、通信インターフェース2508は、コンピュータ2502のマザーボード上に物理的に一体化され、かつ/またはソフトウェアプログラムなどであってもよい。
RAM2514および不揮発性ストレージドライブ2516は、実行可能コンピュータコード、または人間可読コードなどを含む、本発明のコンピュータプログラム製品の実施形態などのデータを格納するように構成された有形のコンピュータ可読記録媒体の例である。他の種類の有形のコンピュータ可読記録媒体として、フロッピィ(登録商標)ディスク、取り外し可能ハードディスク、CD-ROM、DVD、バーコードなどの光記憶媒体、フラッシュメモリ、リードオンリーメモリ(ROM)、バッテリバックアップ揮発性メモリなどの半導体メモリ、およびネットワーク接続ストレージデバイスなどが挙げられる。RAM2514および不揮発性ストレージドライブ2516は、上で説明されているように、本発明のさまざまな実施形態の機能を提供する基本プログラミングおよびデータ構造体を格納するように構成され得る。
本発明の機能を提供するソフトウェア命令セットは、RAM2514および不揮発性ストレージドライブ2516内に格納され得る。これらの命令セットまたはコードは、プロセッサ2512によって実行されるものとしてよい。RAM2514および不揮発性ストレージドライブ2516は、本発明に従って使用されるデータおよびデータ構造体を格納するためのリポジトリも提供することができる。RAM2514および不揮発性ストレージドライブ2516は、プログラム実行時に命令およびデータを格納するための主ランダムアクセスメモリ(RAM)、ならびに固定された命令が格納されるリードオンリーメモリ(ROM)を含む多数のメモリを含むことができる。RAM2514および不揮発性ストレージドライブ2516は、プログラムおよび/またはデータファイルの永続的(不揮発性)ストレージを構成するファイルストレージサブシステムを含み得る。RAM2514および不揮発性ストレージドライブ2516は、取り外し可能フラッシュメモリなどの取り外し可能ストレージシステムも含むことができる。
バスサブシステム2514は、コンピュータ2502のさまざまなコンポーネントおよびサブシステムが意図されたとおりに互いに通信することを可能にするメカニズムを提供する。バスサブシステム2514は、単一のバスとして概略が示されているが、バスサブシステムの代替的実施形態は、コンピュータ2502内の複数のバスまたは通信経路を利用することができる。
ファームウェアおよび/またはソフトウェア実装では、これらの方法は、本明細書で説明されている機能を実行するモジュール(例えば、プロシージャ、関数など)で実施され得る。命令を明白に具体化する機械可読記録媒体は、本明細書で説明されている方法を実施する際に使用され得る。例えば、ソフトウェアコードは、メモリ内に格納され得る。メモリは、プロセッサ内に、またはプロセッサの外部に実装することができる。本明細書で使用されているように、「メモリ」という用語は、任意の種類の長期的な、短期的な、揮発性の、不揮発性の、または他の記憶媒体を指し、メモリの特定の種類、メモリの特定の数、またはメモリが置かれる媒体の種類に限定されない。
さらに、本明細書で開示されているように、「記憶媒体」という用語は、リードオンリーメモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気RAM、コアメモリ、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および/または情報を格納するための他の機械可読記録媒体を含む、データを格納するための1つまたは複数のメモリを表し得る。「機械可読記録媒体」という用語は、限定はしないが、携帯型ストレージデバイスまたは固定ストレージデバイス、光ストレージデバイス、ワイヤレスチャネル、および/または命令および/またはデータを収容するか、または搬送する格納することができる他の記憶媒体を含む。
図36は、図33のスマートホームと統合できる拡張可能なデバイスおよびサービスプラットフォームのネットワークレベルの図である。図34の構造物2401を参照しつつ説明されているインテリジェント型ネットワーク接続デバイスのそれぞれは、1つまたは複数のリモートサーバーまたはクラウドコンピューティングシステム2424と通信することができる。通信は、インターネット2436への接続の確立を、直接(例えば、ワイヤレスキャリアへの3G/4G接続を使用して)、ハブ型ネットワーク(単純なワイヤレスルーターから、例えば、インテリジェント型の専用の家全体の制御ノードに至るスキームとすることができる)を通じて、またはこれらの組み合わせを通じて確立することによって使用可能になる。
リモートサーバーまたはクラウドコンピューティングシステム2424は、スマートホームデバイスから動作データ2602を収集することができる。例えば、デバイスは、定期的に動作データを送信するか、または特定の場合(例えば、カスタマーサポートに依頼するとき)に動作データを送信することができる。リモートサーバーまたはクラウドコンピューティングシステム2424は、1つまたは複数のサービス2604をさらに提供することができる。サービス2604は、例えば、ソフトウェア更新、カスタマーサポート、センサーデータ収集/ロギング、リモートアクセス、リモート制御または分散制御、または使用提案(例えば、性能を改善する、光熱費を低減するなどのための収集された動作データ2602に基づく)を含み得る。サービス2604に関連付けられているデータは、リモートサーバーまたはクラウドコンピューティングシステム2424側に格納され得、リモートサーバーまたはコンピューティングシステム2424は、適切なタイミングで(例えば、規則正しい間隔で、ユーザーから要求を受信した後などに)データを取り出し、送信することができる。
図36に示されているような、説明されている拡張可能デバイスおよびサービスプラットフォームの突出した一特徴は、限定することなく、処理エンジン2606であり、これは、単一のデータ処理サーバー2607(リモートサーバー2424に含まれるか、または別であってもよい)に集中するか、またはいくつかの異なるコンピューティングエンティティ間に分散され得る。処理エンジン2606は、デバイスのセットからデータを(例えば、インターネットまたはハブ型ネットワークを介して)受信し、データにインデックスを付け、データを分析し、かつ/または分析に基づきもしくは分析の一部として統計量を生成するように構成されたエンジンを含み得る。分析されたデータは、派生データ2608として格納され得る。分析の結果または統計量は、これ以降、結果を導き出すために使用される動作データを提供するデバイス、他のデバイス、デバイスのユーザーにウェブページを提供するサーバー、または他の非デバイスエンティティに送り返すことができる。例えば、使用統計量、他のデバイスの使用に関する使用統計量、使用パターン、および/またはセンサー読み取り値を要約した統計量を送信することができる。これらの結果または統計量は、インターネット2436を介して提供され得る。この様式で、処理エンジン2606は、スマートホームから得られた動作データからさまざまな有用な情報を導き出すように構成され、プログラムされ得る。単一のサーバーが、1つまたは複数のエンジンを含むことができる。
導き出されたデータは、家、近所、または地域毎のデバイスの明示的なプログラムされた制御(例えば、電力事業のための需要応答プログラム)から、家毎に支援することができる推論抽象化の生成(例えば、家の所有者がバケーションに出かけたため、防犯用検出機器を最高感度に設定できるという推論を下せる)、統治または慈善目的に使用され得る統計量および関連する推論抽象化の生成に至る、さまざまな有用な目的のためにさまざまな異なる粒度で高度に有益であり得る。例えば、処理エンジン2606は、デバイスの集団におけるデバイス使用度に関する統計量を生成し、その統計量をデバイスユーザー、サービスプロバイダ、または他のエンティティ(例えば、統計量に対する金銭的補償を要求したか、または提供している可能性のある)に送信することができる。具体例として、統計量は、慈善団体2622、政府機関2624(例えば、食品医薬品局または環境保護庁)、学術機関2626(例えば,大学の研究者)、企業2628(例えば、デバイス保証またはサービスを関係する機器に提供する)、または公益事業会社2630に送信され得る。これらのエンティティは、データを使用して、エネルギー使用度を減らす、機先を制して欠陥機器を整備する、高いサービス需要に応じる準備をする、過去のサービス実績などを追跡する、または現在知られているか、もしくは今後開発されるさまざまな有益な機能もしくはタスクを実行するためのプログラムを形成することができる。
図37は、処理エンジン2606、さらにはスマートホームのデバイスを特に参照している、図36の拡張可能なデバイスおよびサービスプラットフォームの抽象化機能図である。スマートホーム内に置かれているデバイスは、無数のさまざまな異なる個別の能力および制限を有するが、すべて、それぞれがデータコンシューマ2702(DC)、データソース2704(DS)、サービスコンシューマ2706(SC)、およびサービスソース2708(SS)であるという点で共通の特性を共有しているものと考えられ得る。有利には、デバイスがローカルの直接的な目的を達成するために必要な本質的制御情報を提供することに加えて、拡張可能デバイスおよびサービスプラットフォームは、これらのデバイスから流れ出る大量のデータを利用するように構成することもできる。それらの直接的機能に関してデバイス自体の実際の動作を強化または最適化することに加えて、拡張可能デバイスおよびサービスプラットフォームは、さまざまな有用な目的を達成するためにさまざまな自動化された、拡張可能な、柔軟性の高い、かつ/またはスケーラブルな方法でそのデータの「目的を設定し直す」ことを対象とすることもできる。これらの目的は、例えば、使用度パターン、デバイス効率、および/またはユーザー入力(例えば、特定の機能を要求する)に基づき事前に定義されるか、または適応するように識別され得る。
例えば、図37は、多数のパラダイム2710を含むものとして処理エンジン2606を示している。処理エンジン2606は、一次または二次デバイス機能を監視し、管理する管理サービスパラダイム2710aを含むことができる。デバイス機能は、ユーザー入力を与えられたデバイスの適切な動作を保証すること、侵入者が住居内にいるか、または住居内に入ろうとしているのを推定する(例えば、さらにそれに応答する)こと、デバイスに結合されている機器の故障(例えば、電球が切れている)を検出すること、エネルギー需要反応事象を実施するか、または他の何らかの形でこれに応答すること、または現在の、もしくは予測された将来の事象もしくは特性をユーザーに警告することを含み得る。処理エンジン2606は、デバイス使用度に基づきユーザーの注目する特性(例えば、人口統計情報)、要望、および/または製品を推定する広告/通信パラダイム2710bをさらに含むことができる。次いで、サービス、販促、製品、またはアップグレードがユーザーに対してオファーされるか、または自動的に提供され得る。処理エンジン2606は、ソーシャルネットワークからの情報を使用するか、または情報をソーシャルネットワークに提供し(例えば、デバイス使用度に基づき)、かつ/またはユーザーおよび/またはデバイスとソーシャルネットワークプラットフォームとの相互のやり取りに関連付けられているデータを処理するソーシャルパラダイム2710cをさらに含むことができる。例えば、ソーシャルネットワーク上の信頼できる連絡先に報告されるようなユーザーのステータスは、照明検出、防犯システム停止またはデバイス使用度検出器に基づき、ユーザーが家にいついるかを示すように更新することが可能である。別の例として、ユーザーは、デバイス使用度統計量を他のユーザーと共有することができるものとしてよい。処理エンジン2606は、ユーザーに難題、規則、コンプライアンス規定、および/または報酬を通知する、かつ/または動作データを使用して難題を乗り切ったかどうか、規則または規定を順守しているかどうか、かつ/または報酬が獲得されたかどうかを判定する難題/規則/コンプライアンス/報酬パラダイム2710dを含むことができる。難題、規則、または規定は、省エネ、安全な生活(例えば、有毒物質または発癌物質への露出を低減する
)、お金の節約および/または機器の延命、健康改善などの取り組みに関係し得る。
処理エンジンは、外来ソースからの外来情報2716を統合するか、または他の何らかの形で利用して、1つまたは複数の処理パラダイムの機能を改善することができる。外来情報2716は、デバイスから受信された動作データを解釈する、デバイスの近くの環境(例えば、デバイスが封じ込められている構造物の外)の特性を判定する、ユーザーから利用可能なサービスまたは製品を決定する、ソーシャルネットワークまたはソーシャルネットワーク情報を識別する、デバイスなどの近くのエンティティ(例えば、救急隊、警察、または病院などの公共サービスエンティティ)の連絡先情報を決定する、家または近所に関連付けられている統計的条件または環境的条件、傾向、もしくは他の情報を識別する、などのために使用され得る。
並外れて広範な、さまざまな利点が、通常のものから深いものに至る、説明されている拡張可能デバイスおよびサービスプラットフォームによってもたらされ、またその範囲内に収まり得る。したがって、「通常の」一例において、スマートホームのそれぞれの寝室は、占有センサーを含む煙/火災/CO警報装置を備えることができ、占有センサーは、占有者が眠っているか、または目覚めているかを推論する(例えば、運動検出、顔認識、可聴音パターンなどを用いて)こともできる。重大な火災事象が感知された場合、離れたところにある防犯/監視サービスまたは消防署は、それぞれの寝室に何人の占有者がいるか、それらの占有者がまだ眠っている(もしくは動けない)か、または寝室から適切に退去しているかどうかの知らせを受ける。これは、もちろん、説明されている拡張可能デバイスおよびサービスプラットフォームが備える非常に有利な機能であるが、利用可能にすることができるより大きな「インテリジェンス」の潜在的可能性を真に示すことができる実質的により「深い」例があり得る。たぶんより「深い」例を用いることで、火災安全のために使用されている同じデータの寝室占有データについて、近隣の子供の成長および教育の社会的パラダイムの文脈において処理エンジン2606によって「目的を設定し直す」こともできる。したがって、例えば、「通常の」例で説明されている同じ寝室占有データおよび運動データを収集し、特定の郵便番号の地域内の学童の睡眠パターンが識別され追跡され得る処理(適切に匿名化されて)に利用可能にできる。学童の睡眠パターンの局部的変動が識別され、例えば、地域の学校の異なる栄養プログラムに対して相関され得る。
本特許明細書で説明されている同期化/認証技術は、理論的に達成可能であるものと毎日のホームオートメーションおよび制御に対して費用効果があり顧客にとって都合のよい様式で実施するために実用的であるものとの間に有利なバランスが得られるという点で、本明細書で説明されているスマートホームデバイスの多くに関連して適用されたときに特に望ましいものであることが判明している。したがって、デバイス同期化に関して、説明されている方法はほぼ間違いなくある程度の待ち時間またはある程度の不完全さを「競合状態」結果においてもたらす可能性があるが(例えば、2台のスマートフォンが同時に同じサーモスタットを制御しようとしている場合)、ホームネットワーク問題、Wi-Fiの途切れ、およびいくつかのデバイス(エネルギーバッファリングされた盗電するサーモスタットなど)がかなりの時間、「スリープ」モードに入っている必要があることなどの、さまざまな有害事象に対処し、それらから復旧することをよりうまく行える。さらに、これらの方法は、適度のコストで一般的に利用できるデータサービスプラットフォーム上で有利に実施可能である。同様に、デバイス認証に関して、説明されている方法は、結果として未認証の第三者スマートデバイスがリモートサービスによってサービスされる利点を享受することになるおそれのあるいくつかの理論的な弱点をほぼ間違いなく引き起こす可能性があるが(しかし、サービスの合法的顧客の機密顧客データへのアクセスはないことが重要である)、新しいデバイスに対する実用的な現実世界の接続性および切断されたデバイスに対する再接続性をユーザーによる広範な手動プロセス(例えば、MACアドレスを入力する、パスワードをリセットするために電話をかける、など)なしで促進することがよりうまく行える。
上記の説明では、実施形態を十分理解できるように、具体的に詳細を述べている。しかし、実施形態は、これらの具体的な詳細がなくても実施され得ることは理解される。例えば、回路は、不要な詳しさで実施形態を分かりにくくしないようにブロック図で示され得る。他の場合には、よく知られている回路、プロセス、アルゴリズム、構造、および技術は、これらの実施形態が不明確にならないよう、不要な詳細を述べることなく示され得る。
上で説明されている技術、ブロック、ステップ、および手段の実装は、さまざまな方法で実行され得る。例えば、これらの技術、ブロック、ステップ、および手段は、ハードウェア、ソフトウェア、またはこれらの組み合わせで実装することができる。ハードウェアによる実装では、処理ニットは、1つまたは複数の特定用途向け集積回路(ASIC)、デジタルシグナルプロセッサ(DSP)、デジタル信号処理デバイス(DSPD)、プログラマブルロジックデバイス(PLD)、フィールドプログラマブルゲートアレイ(FPGA)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、上で説明されている機能を実行するように設計されている他の電子ユニット内に、かつ/またはこれらの組み合わせで実装することができる。
また、実施形態は、流れ図、フローダイアグラム、データフローダイアグラム、構造図、またはブロック図として示されているプロセスとして説明され得ることに留意されたい。流れ図ではオペレーションを逐次プロセスとして記述している場合があるが、オペレーションの多くは、並列または同時実行することが可能である。それに加えて、オペレーションの順序を変更することができる。プロセスは、そのオペレーションが完了した場合に終了するが、図に含まれていない追加ステップを有している場合もある。プロセスは、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応している場合、その終了は呼び出し側関数またはメイン関数への関数の戻りに対応する。
さらに、実施形態は、ハードウェア、ソフトウェア、スクリプト言語、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、および/またはこれらの組み合わせによって実施され得る。ソフトウェア、ファームウェア、ミドルウェア、スクリプト言語、および/またはマイクロコードで実施される場合、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、記憶媒体などの機械可読記録媒体内に格納することができる。コードセグメントまたは機械実行可能命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、スクリプト、クラス、または命令、データ構造体、および/もしくはプログラムステートメントの組み合わせを表し得る。コードセグメントは、情報、データ、引数、パラメータ、および/またはメモリ内容を受け渡し、かつ/または受信することにより、他のコードセグメントまたはハードウェア回路に結合され得る。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク伝送などを含む、任意の好適な手段を介して受け渡されるか、転送されるか、または伝送され得る。
本開示の原理が特定の装置および方法に関連して上で説明されたが、この説明は例によってのみなされており、本教示の範囲に関する限定としてなされないことを、明確に理解されたい。