JP6975416B2 - ビデオベースのデータ収集、画像のキャプチャおよび解析構成 - Google Patents

Description

関連出願との相互参照
[0002] 本願は2016年10月25日に出願された米国仮出願第62/412,764号について、その利益を主張するとともに、全体を参照によって本明細書に含める。
[0003] 本開示は概してビデオベースのデータ収集システムに関し、より具体的には画像、ビデオ、およびセンサーデータのキャプチャ、記憶、送信、および解析に関する。

[0004] スマートフォンや、インターネットおよびソーシャルネットワークへのユビキタスな接続性が広く行き渡ることにより、ソフトウェアアプリケーションおよびカメラは、我々の日常生活において個人が利用するありふれた存在になってきている。我々は自身のスマートフォンであらゆる種類のイベント、物品および状況の写真やビデオを撮影し、それらをクラウドサービスに簡単にアップロードし、友人、家族、および自身の共有コンテンツを購読またはフォローする他の人々と共有する。

[0005] スマートホームまたは自動化ホームマーケットセグメントにも多数の製品およびサービスが存在している。常に、あるいはモーションセンサのようなイベントベースのトリガによって記録を行い、記録されたビデオをローカルのビデオサーバに保存するか、ホームルータを通じた有線接続またはホームネットワークに接続されたＷｉＦＩを用いてクラウドサービスにアップロードする、自宅または職場周辺のセキュリティカメラは広く用いられている。通常、記録されたビデオは一定期間ユーザが利用可能であり、スマートフォンのソフトウェアアプリケーションか、ウェブサイトを通じてリアルタイムにアクセス可能である。マルチカメラシステムは、自宅周辺の様々なカメラからのビデオフィードを保存し、共通ユーザインタフェースを通じて様々なフィードをユーザが利用できるようにする。一部のサービスは、ソーシャルネットワークを通じてだけでなく、他のファクタに基づいてこれらのビデオを他のユーザと共用できる能力を提供する。例えば、カリフォルニア州サンタモニカのBot Home Automation社は、Ringと呼ばれる、カメラを備えた玄関ベルを提供している。顧客は、ウエブサイトring.comを通じて、Ringカメラからのビデオにアクセスすることができる。Ringシステムの１機能は「Ring Neighborhoods」と呼ばれる（https://ring.com/neighborhoodsで説明されている）。ユーザはRingカメラを設置した自宅の周辺に半径を設定し、設定した半径内の他のユーザがRingプラットフォームでビデオを共有すると自動的に通知を受けることができる。ユーザは、近隣の他のユーザが興味を持つと思われるビデオを共有することができる。しかし、このシステムでは、興味を引くかもしれないビデオを探すためにユーザが自身のビデオを全て見直し、見つけたビデオを予め規定した距離範囲内の他のRingユーザと共有するためにアップロードする必要がある。

[0006] カメラが利用されている別の領域は、車両内である。バックアップ用のセーフティカメラや、サイドビューカメラは普通のものとなりつつある。タクシーや他の自動車隊(vehicle fleet)のような商用車のために、セキュリティカメラシステムは安全および管理を目的として、車両の内部および外部からビデオを記録する。例えば、ミシガン州BellevilleのSafety Track社は、リアルタイムで車両からビデオをストリーミングするためにＵＳＢを通じてカメラシステムに接続する３Ｇ／４Ｇセルラドングルを備えた、２チャンネルのダッシュボード設置型カメラシステムを提供している（http://www.safetytrack.net/dual-lens-in-vehicle-fleet-camera-system/で説明されている）。しかし、これら車両内システムは、平均的な消費者にとって設置が簡単でなく、他のシステムとのビデオ共有機能を持たず、かつイベントを自動的にタグ付けしたり共有したりしない。

[0007] 従来技術の問題点を解決するビデオ収集および共有プラットフォームが必要とされている。

[0008] 本発明の様々な実施形態によれば、ビデオデータ収集と共有プラットフォームが提供される。

[0009] 一実施形態において、ビデオデータキャプチャおよび共有のためのクラウドベースのシステムは、複数のクライアント機器を有する。各クライアント機器は、１つ以上のビデオカメラと、１つ以上のセンサと、プロセッサと、メモリと、セルラ通信モジュールとを含みうる。好ましくはクライアント機器は、ビデオデータをキャプチャし、ビデオデータに関するメタデータを生成するように構成されることができる。好ましくはメタデータは、少なくとも一部に、１つ以上のセンサから得られるデータを含むことができる。クラウドベースのシステムは、複数のクライアント機器と同時に通信することができ、また接続中に複数のクライアント機器からメタデータを受信するように構成されてよい。クラウドベースのシステムはさらに、クライアント機器から、複数のクライアント機器の他のクライアント機器がキャプチャしたビデオデータを共有するための要求を受信するように構成されてもよい。クラウドベースのシステムは、複数のクライアント機器のサブセットからのメタデータを要求と照合させ、要求に指定されている関心オブジェクトに関してクライアント機器のサブセットに画像検索クエリを送信し、１つ以上のクライアント機器から、１つ以上の特定されたクライアント機器によってキャプチャされたビデオデータに関心オブジェクトが見つかったことを示す肯定マッチ応答を受信することによって１つ以上のクライアント機器を特定するように構成されてもよい。

[0010] 代替実施形態においてクラウドベースのシステムは、代替実施形態においてクラウドベースのシステムは、プリセットされた量のビデオデータのキャプチャに応じて、プリセットされた時間量のビデオデータのキャプチャに応じて、あるいは要求に応じて、複数のクライアント機器のそれぞれから周期的にメタデータを受信するように構成されてもよい。必要に応じて、プリセットされた量のビデオデータは１から３０秒の間であってよく、ビデオデータに関するメタデータは位置情報および／または向きの情報を含んでもよい。

[0011] 一部の実施形態において、１つ以上のセンサは、位置センサ、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ(significant motion sensor)、歩数センサ(step counter sensor)、または歩き検出センサ(step detector sensor)の１つ以上を含んでよい。必要に応じて、一実施形態において、１つ以上のクライアント機器は移動車両に設置されたダッシュボード設置型カメラ機器であり、他のクライアント機器は固定構造物に設置された固定カメラ機器であってよい。一部の実施形態において、システムは、クライアント機器からビデオデータを受信するためにクライアント機器とデータ通信を確立するように構成されたモバイル機器を、必要に応じてさらに含んでもよい。

[0012] 一実施形態によれば、複数のカメラからのビデオを共有することは、ビデオデータの共有要求を受信することを含み、要求は、要求されたビデオデータに関するメタデータと、関心オブジェクトを特定する画像クエリとを含む。共有することはまた、ビデオデータに関するメタデータを複数のカメラ機器から取得することと、カメラ機器から取得したたメタデータおよび要求に指定されたメタデータに基づいてカメラ機器のサブセットを特定することと、カメラ機器のサブセットに画像クエリを送信することとを含む。カメラ機器のサブセットの１つ以上のカメラ機器から、１つ以上のカメラ機器がキャプチャしたビデオデータにおける関心オブジェクトについての肯定マッチを示す応答を受信すると、肯定的にマッチしているビデオデータを共有するための許可が取得され、例えばプレイリストまたはマニフェストファイルの１つを、肯定的にマッチしているビデオデータの少なくとも一部の位置を特定している１以上のユーザに送信することにより、肯定的にマッチしているビデオデータがその１以上のユーザ間で共有されてよい。

[0013] 必要に応じて、ビデオデータに関するメタデータは位置情報および／または向き情報を含んでよい。一実施形態において、ビデオデータに関するメタデータは、少なくとも部分的に、位置センサ、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ(significant motion sensor)、歩数センサ(step counter sensor)、または歩き検出センサ(step detector sensor)の１つ以上から取得されてよい。一実施形態において、１つ以上のセンサからの入力から判定されるイベントについて自動生成されたビデオクリップに関するメタデータが受信され、要求されるビデオデータは同一の自動生成されるイベントに関連する。一部の実施形態において、要求は、サーバシステムで稼働するコンピュータソフトウェアモジュールからのコンピュータプログラムコールであってよい。

[0014] 別の実施形態において、１つ以上のプロセッサで実行されるとその１つ以上のプロセッサにソフトウェアモジュールセットを実行させる命令を含んだコンピュータ可読媒体を有する、複数のカメラからのビデオを共有するためのシステムが提供される。システムは複数のモジュールを含んでよい。例えばシステムは、例えばシステムは、ビデオデータを共有する要求であって、要求されるビデオデータに関するメタデータと関心オブジェクトを特定する画像クエリとを有する要求を受信するためのモジュールを含んでよい。システムはさらに、ビデオデータに関するメタデータを複数のカメラ機器から取得するためのモジュールを含んでよい。システムはさらに、カメラ機器から取得されたメタデータおよび要求に指定されたメタデータに基づいてカメラ機器のサブセットを特定するためのモジュールを含んでよい。システムはさらに、カメラ機器のサブセットに画像クエリを送信するためのモジュールを含んでよい。さらに、システムは、カメラ機器のサブセットの１つ以上のカメラ機器から、その１つ以上のカメラ機器がキャプチャしたビデオデータにおける関心オブジェクトの肯定的マッチを示す応答を受信するためのモジュールと、肯定的にマッチするビデオデータを共有するための許可を取得するためのモジュールと、肯定的にマッチするビデオデータを１以上のユーザと共有するためのモジュールとを含んでよい。別の実施形態においてシステムは、１つ以上のセンサからの入力から判定されたイベントに関して自動生成されたビデオクリップに関連するメタデータを受信するモジュールをさらに含んでよく、要求されるビデオデータは同じイベントに関するものであってよい。必要に応じて、要求を受信するためのモジュールは、１つ以上のプロセッサで稼働するコンピュータソフトウェアモジュールからのコンピュータプログラムコールを受信するためのプログラム命令を含む。

[0015] 一実施形態において、肯定的にマッチするビデオデータをシステムのユーザと共有するためのモジュールは、肯定的にマッチするビデオデータの少なくとも一部の位置についての特定情報とともにプレイリストまたはマニフェストファイルをユーザに送信するためのモジュールをさらに含む。必要に応じて、要求は、位置情報および／または向き情報を含みうるメタデータを含む。一実施形態において、ビデオデータに関するメタデータは、少なくとも部分的に、位置センサ、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ(significant motion sensor)、歩数センサ(step counter sensor)、または歩き検出センサ(step detector sensor)の１つ以上から取得されてよい。

[0016] 別の実施形態によれば、ビデオデータキャプチャおよび共有のためのクラウドベースのシステムが提供される。クラウドベースのシステムは、１つ以上のビデオカメラと、１つ以上のセンサと、プロセッサと、メモリと、セルラ通信モジュールとを有する、移動車両に設置されるクライアント機器を含んでよい。クライアント機器は、移動車両からビデオデータをキャプチャし、ビデオデータに関するメタデータであって、１つ以上のセンサから得られるデータを少なくとも部分的に含んだメタデータを生成するように構成されてよい。システムはさらに、１つ以上のビデオカメラと、プロセッサと、メモリと、無線通信モジュールとを有する固定補助カメラ機器を含んでもよい。固定補助カメラ機器は、固定位置からビデオデータをキャプチャし、キャプチャしたビデオデータに関するメタデータを生成するように構成されてよい。システムはさらに、タッチスクリーンと無線通信モジュールとを有するモバイル機器を含んでもよい。モバイル機器は、モバイル機器で再生可能なビデオクリップのリストをタッチスクリーンに表示するように構成されてよい。クラウドベースのシステムは、移動車両に設置されるクライアント機器とセルラデータ接続を通じて通信し、また固定補助カメラ機器および移動機機とはインターネットへの無線接続を通じて通信することができる。クラウドベースのシステムは、移動車両に設置されるクライアント機器および固定補助カメラ機器からメタデータを受信し、移動車両に設置されるクライアント機器がキャプチャしたビデオデータに関するモバイル機器メタデータと、固定補助カメラ機器がキャプチャしたビデオデータに関するメタデータとを送信するように構成されてよい。必要に応じて、メタデータは、少なくともその一部において、モバイル機器で再生可能なビデオクリップをリストするための情報を提供してもよい。

[0017] 図１は、本開示の一実施形態に係る例示的なビデオベースのデータキャプチャおよび解析システムを示す図である。 [0018] 図２は、本開示の一実施形態に係るクライアント機器の機能ブロック図である。 [0019] 図３は、一実施形態に係るダッシュカメラクライアント機器のブロック図である。 [0020] 図４ａは、一実施形態に係る、モバイル機器１０４におけるモバイルアプリケーションの「クリップペイン」のためのグラフィカルユーザインタフェース(GUI)を示す図である。 [0021] 図４ｂは、一実施形態に係る、モバイル機器１０４におけるモバイルアプリケーションの「カメラペイン」のためのグラフィカルユーザインタフェース(GUI)を示す図である。 [0022] 図４ｃは、一実施形態に係る、モバイル機器１０４におけるモバイルアプリケーションの「ニュースペイン」のためのグラフィカルユーザインタフェース(GUI)を示す図である。 [0023] 図５は、一実施形態に係るビデオデータ収集方法を示すフローチャートである。 [0024] 図６ａは、一実施形態に係る、クラウドベースのデータ収集およびイベントベースのデータの解析のための方法を示すフローチャートである。 [0025] 図６ｂは、一実施形態に係る、所与のビデオデータオブジェクトまたはファイルに関するメタデータをキャプチャするためのデータモデルを示す図である。 [0026] 図６ｃは、一実施形態に係る、所与のイベントベースのビデオクリップに関するメタデータをキャプチャするためのデータモデルを示す図である。 [0027] 図７は、一実施形態に係る、イベントベースのビデオクリップを生成するための方法を示すフローチャートである。 [0028] 図８は、一実施形態に係る、イベントベースのビデオを共有するための方法を示すフローチャートである。 [0029] 図９は、一実施形態に係る、イベントベースのビデオデータファイルの許可を検証するための方法を示すフローチャートである。 [0030] 図１０は、一実施形態に係る、クライアント機器をセットアップするための方法を示すフローチャートである。

[0031] 図面は本開示の様々な例示的な実施形態を、例示のみを目的として図示している。本技術分野に属する当業者は、以下の検討から、本開示の本質を離れることなく代替構成および方法に基づく他の例示的な実施形態を実施しうること、またそのような他の例示的な実施形態が本開示の範囲に包含されることを容易に理解するであろう。

[0032] 図面および以下の説明は、例示のみを目的として特定の実施形態を説明する。本技術分野に属する当業者は、以下の検討から、ここで説明される本質を離れることなく、ここで説明される構成や方法の代替実施形態を実施しうることを容易に理解するであろう。以下、添付図面に例が図示されるいくつかの実施形態について説明する。

[0033] 上述した、および他の必要性は、没入型ビデオコンテンツのストリーミングおよび再生のための、開示される方法、実行可能なコードを格納する恒久的コンピュータ可読記憶媒体、およびシステムによって充足される。

[0034] 図１を参照すると、本開示の一実施形態に係る、例示的な車両ビデオベースのデータキャプチャおよび解析システム１００が示されている。クライアント機器１０１は、車両に設置するのに好適な、専用のデータキャプチャおよび記録システムである。一実施形態において、クライアント機器１０１はクルマのダッシュボードまたはフロントガラスに設置するために設計されたビデオベースのダッシュカメラシステムである。クライアント機器１０１はクラウドベースのシステム１０３に接続される。一実施形態において、クラウドベースのシステム１０３は、サーバシステム１０２および（例えばインターネットへの）ネットワーク接続を含んでいる。一実施形態において、クラウドベースのシステム１０３は、アマゾンウェブサービス(AWS)データセンタ、グーグルクラウドプラットフォームデータセンタなどといった、公衆データセンタで稼働するソフトウェアサービスおよびプログラムの集合である。クラウドベースのシステム１０３は、モバイル機器１０４およびウェブベースのシステム１０５を通じてアクセス可能である。一実施形態において、モバイル機器１０４は、iPhone（登録商標）、iPad（登録商標）、iPod（登録商標）を含む、アップルiOSベースの機器や、サムスンギャラクシースマートフォン、タブレットなどのようなAndroidベースの機器といったモバイル機器を含む。そういったモバイル機器は、プロセッサで稼働するアプリケーションプログラムまたはアプリ(app)を含んでいる。ウェブベースのシステム１０５は、例えばウィンドウズ（登録商標）ＰＣまたはタブレット、Macコンピュータなどのような、ウェブブラウザを稼働させることのできる任意のコンピュータ機器であってよい。ウェブベースのシステム１０５は、新規または潜在的なユーザのための、システム動作に関する情報や販促資料へのアクセスを提供することができる。さらに、ウェブベースのシステム１０５は、以下でさらに説明するモバイルアプリと同様のソフトウェアプログラムまたはアプリケーションを通じ、必要に応じてユーザにアクセスを提供してもよい。一実施形態において、システム１００は１つ以上の補助カメラモジュール１０６をさらに含んでいる。例えば、ユーザの自宅、別荘、または職場にある１つ以上のカメラモジュールである。補助カメラモジュール１０６は、クライアント機器１０１として実施され、同様に動作することができる。一実施形態において、補助カメラモジュール１０６は、部品および機能性のサブセットを有するクライアント機器１０１のバージョンである。例えば、一実施形態において、補助カメラモジュール１０６は１つのカメラクライアント機器１０１である。

[0035] クライアント機器１０１は、接続１０７を通じてクラウドベースのシステム１０３に接続される。一実施形態において、接続１０７は、３Ｇ、４Ｇ、ＬＴＥ、５Ｇ、または同様の接続といった、セルラベースの無線パケットデータ接続である。他のシステム構成要素とクラウドベースのシステム１０３との間の接続１０８ａ〜１０８ｃは、有線または無線の、インターネットベースの接続である。例えば、一実施形態において、モバイル機器１０４は、その時々において、Wi-Fi（すなわち、任意のIEEE802.11ベースの接続または同様の技術）および（例えば４Ｇ、ＬＴＥなどを用いる）セルラデータを通じてクラウドベースのシステム１０３に接続することができる。一実施形態において、ウェブベースのシステム１０５は、DSL、ケーブルモデムなどの有線インターネット接続を用いて、ワールドワイドウェブ上でクラウドベースのシステム１０３に接続される。同様に、一実施形態において、補助カメラモジュール１０６は、ケーブルモデム、DSLなどを通じてインターネットに接続されるホームルータへのWi-Fi接続を通じてクラウドベースのシステム１０３に接続される。システムの構成要素をクラウドベースのシステム１０３にインターネットまたは同様のネットワークを通じて接続するために、利用可能な接続を任意に組み合わせて用いることができる。

[0036] 図２を参照すると、一実施形態に係るクライアント機器１０１についての機能システム図が示されている。別の実施形態では、図２に示される構成要素のサブセットおよび／または図示されていない他の構成要素を含みうる。代替実施形態において、図２に示される構成要素（および、例えばUDMIモジュール、充電器、および／または電源モジュールなどの不図示の追加構成要素）は、システムオンチップ(SoC)、基板上の複数のチップ、ASICなどの一部であってよい。シリコンベースの集積回路またはソフトウェアにおける構成要素の物理的な実施は、本発明の範囲内で本技術分野に属する当業者が、適宜設計する事項である。クライアント機器１０１は、データバス２０２およびメモリデバイス２０３に接続されたマイクロプロセッサ２０１と、他の機能モジュールとを含んでいる。一実施形態において、マイクロプロセッサ２０１はQualcomm社のSnapdragon MSM8953であるが、Qualcomm社の他のSnapdragonプロセッサ、ARM社のCortex A8/9プロセッサ、Nvidia社のTargaプロセッサ、Texas Instruments社のOMAPプロセッサなど、他のマイクロプロセッサを用いて発明を実施してもよい。マイクロプロセッサ２０１は、Linux（登録商標）、Android、iOSなどといったオペレーティングシステムソフトウェア、ファームウェア、ドライバ、およびアプリケーションソフトウェアを実行する。

[0037] この例示的な実施形態においてクライアント機器１０１は、測位モジュール２０４、無線送受信機モジュール２０５、オーディオＩ／Ｏモジュール２０６、ビデオモジュール２０７、タッチスクリーンモジュール２０８、センサモジュール２０９、およびＩ／Ｏモジュール２１６を含んでいる。本実施形態において、様々なモジュールはハードウェアおよびソフトウェアモジュールに実装される。代替実施形態において、これらのモジュールはハードウェア、ソフトウェア、またはそれらの組み合わせであってよい。例えば、代替実施形態は、無線モデム、マルチメディアプロセッサ、セキュリティおよび随意の他のシグナルコプロセッサ、例えば１つ以上のグラフィックスプロセッサユニット(GPU)コア、１つ以上のホログラフィック処理ユニット(HPU)コア、および／または１つ以上のビジョン処理ユニット(VPU)などをさらに含むSoC上の１つ以上の中央プロセッサ(CPU)コアによって与えられる。以下でさらに説明するように、一実施形態において、本発明の実施するために用いられる１つ以上のSoCプロセッサは、CPU、GPU、VPU、HPU、および他のコプロセッサ、マザーボードバス、メモリコントローラ、スクリーンコントローラ、サウンドチップセット、カメラモジュール、オンボードメモリ、および、例えばセルラ、Wi-Fi、ブルートゥース（登録商標）送受信機を含むいくつかの周辺機器を包含する。代替実施形態は、バス２０２で相互接続される回路基板上のディスクリートな部品、もしくは、ディスクリートな部品と、内蔵機能モジュールの少なくとも一部を有する１つ以上のSoCモジュールとの組み合わせとしてのモジュールを含む。

[0038] 一実施形態において、測位モジュール２０４は、全地球測位システム(GPS)、全地球ナビゲーション衛星システム(GLONASS)、および／またはバイドゥ衛星システムのような測位衛星システムからの信号を受信ならびにデコードするための１つ以上の衛星受信機を含んでよい。一実施形態において、測位モジュール２０４は、GPS衛星信号を受信してクライアント機器１０１の位置の地理的座標（緯度および経度）を与えるためにGPSアンテナに接続する、Qualcomm社のQTR2965またはQualcomm社のQGR7640受信機である。無線送受信機モジュール２０５は、例えば3G/UMTS、4G/LTE、5Gまたは同様の無線セルラ規格に準拠するセルラモデム、例えばIEEE 802.11規格または同様のローカルエリアネットワーク規格に準拠するWi-Fi送受信機、および例えばIEEE 802.15規格または同様の短距離無線通信規格に準拠するブルートゥース送受信機を含む。一実施形態において、無線送受信機モジュール２０５はSierra Wireless社のHL-7588である。

[0039] オーディオＩ／Ｏモジュール２０６は、１つ以上のアナログおよび／またはデジタルオーディオ入出力ポートと、１つ以上のD/AコンバータおよびA/Dコンバータとを備えるオーディオチップセットを含み、１つ以上のフィルタ、サンプルレートコンバータ、ミキサ、マルチプレクサなどを含みうる。例えば、一実施形態においてはQualcomm社のWCD9326チップセットが用いられるが、他のオーディオコーデックが用いられてもよい。一実施形態において、ビデオモジュール２０７は、例えばMPEG-2、MPEG-4、H.264、H.265などを含む、様々なビデオ圧縮フォーマットおよび規格を処理するためのビデオアクセラレータハードウェアを備える、ビデオ画像処理のためのDSPコアを含む。一実施形態において、ビデオモジュール２０７はプロセッサ２０１とともに、SoC「マルチメディアプロセッサ」に統合される。例えば、一実施形態においてクライアント機器１０１はQualcomm社のMSM8953内部の統合GPUを含むが、代替実施形態ではビデオモジュール２０７の別の実装を含みうる。

[0040] 一実施形態において、タッチスクリーンモジュール２０８は、本技術分野において既知であるように、容量式タッチスクリーンコントローラを備えた低消費電力タッチスクリーンセンサICである。他の実施形態は、シングルタッチセンサ、マルチタッチセンサ、容量式センサ、抵抗式センサなど、様々な構成要素を備えるタッチスクリーンモジュール２０８を実装してもよい。一実施形態において、タッチスクリーンモジュール２０８は、クライアント機器のLCD画面へのビデオ出力を制御するためのLCDコントローラを含む。例えば、一実施形態において、タッチスクリーンモジュール２０８は「LCDコントロールに用いられる実際のデバイス」を含む。LCDコントローラはタッチスクリーンモジュール２０８に統合されてもよいし、代替実施形態においてはビデオモジュール２０７の一部や独立したモジュールとして提供されてもよいし、様々な他のモジュールに分散されてもよい。

[0041] 一実施形態において、センサモジュール２０９は、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ(significant motion sensor)、歩数センサ(step counter sensor)、または歩き検出センサ(step detector sensor)などを含む、複数のハードウェアおよび／またはソフトウェアベースのセンサのためのコントローラを含む。例えば、一実施形態において、センサモジュール２０９はInvensense社のICM-20608である。別の実施形態ではセンサモジュール２０９の別の実装が提供されうる。例えば、一実施形態において、センサモジュール２０９は、１つ以上の多軸加速度計および１つ以上の多軸ジャイロスコープを含む統合動きセンサMEMSデバイスである。

[0042] クライアント機器１０１は、１つ以上のＩ／Ｏモジュール２１０をさらに含んでよい。一実施形態において、Ｉ／Ｏモジュール２１０はユニバーサルシリアルバス(USB)コントローラ、コントローラエリアネットワーク(CANバス)および／またはLIN (Local Interconnect Network)コントローラを含む。

[0043] 一実施形態において、クライアント機器１０１はタッチスクリーン２１１をさらに含む。代替実施形態において、キーボード、マウス、スタイラスなど、他のユーザ入力デバイス（不図示）が用いられてもよい。タッチスクリーン２１１はユーザからのタッチ入力を受け付けるためにタッチスクリーンモジュール２０８によって制御される容量式タッチアレイであってよい。タッチスクリーン２１１の他の実施形態においては、例えば、フォースセンシングタッチスクリーン、抵抗型タッチスクリーン、電界トモグラフィータッチセンサ、無線周波数(RF)タッチセンサなどのような、他のタッチスクリーン技術が用いられてもよい。さらに、ユーザ入力は１つ以上のマイク２１２を通じて受け付けられてもよい。一実施形態において、マイク２１２はユーザ命令やコマンドのようなユーザ会話入力を受け付けるためにオーディオモジュール２０６に接続されたデジタルマイクである。マイク２１２は、ユーザ通信、ビデオ記録のオーディオ要素などのような、他の機能のために用いられてもよい。クライアント機器はさらに、スピーカやスピーカアレイのような１つ以上のオーディオ出力デバイス２１３を含んでもよい。代替実施形態において、オーディオ出力デバイス２１３は、自動車スピーカシステム、ヘッドフォン、スタンドアロン「スマート」スピーカなどのような、他の構成要素を含んでもよい。

[0044] クライアント機器１０１は、１つ以上のカメラ２１４、１つ以上のセンサ２１５、および画面２１６をさらに含むことができる。一実施形態において、クライアント機器１０１は２つのカメラ２１４ａおよび２１４ｂを含む。各カメラ２１４は、例えば1440p、1080p、720pのような高解像度フォーマット、および／または2K（例えば2048×1080または同様の解像度）、4Kまたは2160p、2540p、4000p、8Kまたは4320p、または同様のビデオモードのような超高解像度フォーマットを含む、１つ以上のビデオモードでビデオを記録可能な高解像度のCMOSベースの撮像素子カメラである。カメラ２１４は例えば１秒当たり１から３００フレームの間のフレームレートのような可変フレームレートを用いてビデオを記録する。例えば、一実施形態において、カメラ２１４ａおよび２１４ｂはOmnivision社のOV-4688カメラである。別の実施形態においては、これらのビデオモードおよび他のビデオモードの任意の組み合わせでビデオを記録可能な別のカメラ２１４が与えられてよい。例えば、他のCMOSセンサまたはCCD撮像素子が用いられてよい。以下でさらに説明するように、カメラ２１４はビデオ入力を記録するためにビデオモジュール２０７によって制御される。異なる視野や角度をカバーするため、１つのクライアント機器１０１が複数のカメラを含んでよい。例えば、車両ベースのシステムにおいて、クライアント機器１０１はフロントカメラ、サイドカメラ、バックカメラ、インサイドカメラ、等を含んでよい。

[0045] クライアント機器１０１は１つ以上のセンサ２１５を含むことができる。例えばセンサ２１５は、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ(significant motion sensor)、歩数センサ(step counter sensor)、または歩き検出センサ(step detector sensor)などを含む、１つ以上のハードウェアおよび／またはソフトウェアベースのセンサを含んでよい。一実施形態において、クライアント機器１０１は加速度計２１５ａ、ジャイロスコープ２１５ｂ、および光センサ２１５ｃを含む。図３は、本発明に係る、ダッシュカメラシステムとして実施されたクライアント機器の例示的な実施形態を示している。

[0046] 図１に戻って、システム１００の別の構成要素はモバイル機器１０４である。モバイル機器１０４はiPhone、iPad、またはiPodのようなアップル社のiOSベースの機器、または例えばサムスン社のGalaxyスマートフォン、タブレット、PDAなどのようなAndroidベースの機器であってよい。一実施形態において、モバイル機器１０４は１つ以上のカメラ、マイク、スピーカ、無線通信能力、およびセンサを有するスマートフォンである。例えば、モバイル機器１０４はアップル社のiPhone 7であってよい。モバイル機器１０４の無線通信能力は好ましくは802.11互換通信またはWi-Fiのような無線ローカルエリアネットワーク通信、802.15語間通信またはブルートゥースのような短距離低消費電力無線通信、およびセルラ通信（例えば4G/LTE、5Gなど）を含む。さらに、モバイル機器１０４は、プロセッサで稼働するアプリケーションプログラムまたはアプリ(app)を含むことが好ましい。本技術分野に属する当業者は、モバイルオペレーティングシステムおよびモバイルアプリに通じている。モバイルアプリは、アップルアップストアやグーグルプレイストアのような電子「ストア」を通じて、またはアプリ提供者自身のウェブサイトを通じてアプリ提供者から直接といったように、電子的な手段を通じて入手可能にされ、また配布されるのが一般的である。なお、モバイルアプリはシステムの動作に必須ではなく、例えばカメラ機器１０１／１０８はチャットボットインタフェースのような音声利用可能なインタフェースを含んでよい。しかし、いくつかの実施形態はモバイルアプリの利用を伴う。

[0047] モバイル機器１０１上のモバイルアプリは、クラウドシステム１０３上のユーザアカウントおよびクライアント機器１０１にユーザインタフェースを提供する。一実施形態において、モバイルアプリは補助カメラ１０６と似た機能を含む。例えば、モバイルアプリは、本開示の一実施形態に従ってビデオイベントを記録するためにモバイル機器１０４の１つ以上のカメラを用いる。ここで説明するビデオ記録、バッファ管理、および他の方法および技術は、本発明の１つ以上の実施形態においてモバイルアプリにも組み込まれてよい。

[0048] 図４ａ〜４ｃには、一実施形態に係るモバイル機器１０４のアプリのためのユーザインタフェースが示されている。一実施形態において、モバイルアプリは１つ以上のペイン４０１を含む。例えば、図４ａは、一実施形態に係る、モバイル機器１０４におけるモバイルアプリケーションのクリップペイン４０１ａのためのグラフィカルユーザインタフェース(GUI)を示している。モバイルアプリはビデオクリップを複数のソースから受信し、それらをローカル保存することができる。例えば、ビデオクリップはクラウドシステム１０３から受信することができる。ユーザおよび他のユーザのクライアント機器１０１、補助カメラ１０６、およびモバイル機器１０４は、ビデオクリップをクラウドシステム１０３にアップロードすることができる。ビデオクリップはまた、例えばクライアント機器１０１や補助カメラ１０６から、モバイル機器１０４に直接送信されてもよい。ビデオクリップはさらに、モバイル機器１０４でローカル的に生成されてもよい。代替実施形態においては、モバイルアプリにはクリップに関するメタデータだけが提供され、クリップに関するビデオデータはリモート保存される。例えば、（例えばファイル、データレコード、データオブジェクトなどといった）ビデオデータオブジェクトは、クラウドサーバ１０２に、あるいはクライアント機器１０１、補助カメラ１０６、または他のモバイル機器１０４のローカルメモリに保存され、インターネットを通じてリモートアクセス可能であってよい。

[0049] 一実施形態によれば、１つ以上のこれらソースからの１つ以上のタイプのビデオクリップは、図４ａに示すようなモバイルアプリのクリップペイン４０１ａを通じて利用可能にされてよい。クリップペイン４０１ａは、ユーザがモバイル機器１０４を用いてアクセス可能なビデオクリップのリストを含む。一実施形態において、クリップは、モバイル機器１０４上でのユーザへのアラートとともにクリップペイン４０１ａに追加される。例えば、クライアント機器１０１がクリップを生成するごとに、クライアント機器はクリップアラートをユーザのモバイル機器１０４に表示させ、生成したクリップがユーザからアクセスに利用可能なクリップペイン４０１ａにリストされる。利用可能なビデオクリップごとに、デスクリプタ４０２ａ〜４０２ｎおよびクリップタイプアイコン４０３ａ〜４０３ｎが与えられる。一実施形態において、クリップタイプアイコン４０２は、ビデオクリップのソースの視覚的目安(visual indicator)を提供する。例えば、クリップタイプアイコン４０２ａ〜４０２ｂは、それらのクリップが自動タグ付け方法（以下でさらに説明する）を用いて自動的に生成されたものであることを示し、クリップタイプ４０２ｃはそのクリップがユーザによって生成されたものであることを示す。さらなる実施形態において、これらおよび他のクリップタイプが用いられてよい。例えば一実施形態においては、以下でさらに説明するように、例えば同一イベントの異なる視点を提供する異なるカメラ機器から生成された複数のクリップのような同一イベントに関する複数のクリップが利用可能であることを示すためにマルチクリップタイプアイコンが用いられてもよい。デスクリプタ４０２は、以下でさらに説明するように、例えばユーザが生成した説明や自動タグデスクリプタのような、ビデオクリップに関するテキストを提供する。本技術分野に属する当業者が理解するであろうように、本開示に従って、異なるクリップタイプについての他のアイコン４０３や、デスクリプタ４０２がクリップペイン４０１ａで用いられてよい。モバイルアプリのユーザは、クリップペイン４０１ａにリストされているビデオクリップをクリックまたはタッチすることにより、クリップペイン４０１ａにリストされたビデオクリップをモバイル機器に再生させることができる。モバイルアプリは、内蔵された、もしくはモバイル機器１０４のオペレーティングシステムを通じて提供されるメディアプレーヤに、選択されたビデオクリップを再生させる。

[0050] 一実施形態によれば、図４ｂに示すように、モバイルアプリのカメラペイン４０１ｂを通じて、複数のソースからのライブカメラフィードをモバイル機器１０４に表示することができる。一実施形態において、カメラペイン４０１ｂはカメラフィードウィンドウ４１０、カメラ制御インタフェース４１１、およびカメラ選択インタフェース４１２を含む。代替実施形態では、カメラペイン４０１ｂ内にこれらの一部または他の要素を含むことができる。例えば、カメラ選択インタフェース４１２はカメラ１台の実施形態では含まれなくてよい。カメラフィードウィンドウ４１０は、現在選択されているカメラからのビデオフィードを表示する。カメラはカメラ選択インタフェース４１２を用いて選択されてよい。例えば、カメラ選択インタフェース４１２は第１から第ｎまでの利用可能なカメラのそれぞれに対する選択オプション４１２ａ〜４１２ｎを表示することができる。一実施形態において、ホームカメラ（例えば補助カメラ１０５）、車載カメラ（例えばクライアント機器１０１）、および電話機カメラ（例えばモバイル機器１０６のカメラ）といった利用可能なカメラのそれぞれを表現するために、アイコンが用いられる。任意数のさらなるカメラが利用可能とされてよく、選択インタフェース４１２はドロップダウンメニュー、ポップアップ「編集」メニュー、ピッカーメニュー、ローリングメニューなどを通じて選択できるように変更される。

[0051] 一実施形態において、以下でさらに説明するように、プレイリストファイルやマニフェストファイルに基づいてビデオクリップを提供するのと同じ手法を用いて、リアルタイムカメラフィードがモバイルアプリに提供される。リアルタイムフィードに関し、プレイリストファイルは、関連するカメラによってキャプチャされ新たに生成されたビデオデータオブジェクトまたはファイルのそれぞれを含むように動的に更新される。新たなビデオファイルのそれぞれについて、更新されたプレイリストにはファイル位置(file location)が与えられ、プレイリストファイルはクラウドシステム１０３を通じて、あるいはビデオフィードのソースから直接、更新される。例えば、一実施形態において、ビデオをストリーミングするためのプレイリストファイルは、（例えば2017年5月22日にIETFにアップル社が提出したインターネットドラフトdraft-pantos-http-live-streaming-23 に記述されるようなものであり、）参照によってその全体を本開示に組み込むHTTPライブストリーミング仕様に記述されるように動的に更新される。他の実施形態では、例えばMPEG-DASH (ISO/IEC 23009-1)、アドビ社のHTTP Dynamic Streaming、マイクロソフト社のSmooth Streamingなどを含む、別のストリーミング技術が用いられてもよい。

[0052] 一実施形態において、カメラペイン４０１ｂはカメラ制御要素４１１を含む。例えば、（以下でさらに説明するように）現在選択されているカメラに現在表示されているビデオに関するクリップを生成するよう指示するために、録画または手動タグ付け制御要素４１１ａがユーザに提供される。例えば、ユーザがビデオクリップ生成イベント（例えば自動車事故、検問(police stop)、侵入(break-in)など）に関与している場合、クライアント機器を通じて手動もしくは自動で生成されるビデオクリップに加え、別のアングルや視点からそのイベントに関するさらなるビデオクリップを生成するためにもモバイル機器１０４を用いることができる。さらに、以下でさらに説明するように、一実施形態においてはモバイルアプリがモバイル機器１０４で稼働しているときは常にモバイル機器１０４の１つ以上のカメラがビデオデータを記録しており、手動でタグ付けされたビデオクリップを生成するために手動タグ付け制御要素４１１ａが用いられる。したがって、その実施形態によれば、モバイル機器１０４をクライアント機器１０１または補助カメラ機器１０６として用いることができる。

[0053] 一実施形態において、カメラペイン４０１ｂはさらに、現在選択されているカメラのバッファに保存されている非ライブビデオにアクセスするためのボタン、アイコン、または他の選択要素やメニューといった、追加の制御要素４１１を含んでもよい。例えば、ユーザは、ユーザのクライアント機器１０１のバッファにックの得されているビデオデータオブジェクトまたはファイルの全セット（例えば過去２４時間分のビデオファイル）に、ユーザ制御要素４１１を通じてリモートアクセスしてもよい。一実施形態において、バッファされたビデオのストリーミングを開始する時点を選択するユーザ入力に基づいて、ソースカメラ機器（例えばクライアント１０１、補助カメラ１０６、または他のカメラ機器）は、次のプリセット期間（例えば１分間）についてのビデオファイルを含んだ動的プレイリストまたはマニフェストファイルを生成する。そして、動的プレイリストまたはマニフェストファイルは、同じ量の期間が経過するごとに（例えば１分ごとに）、ビデオファイルの次のセットによって漸進的かつ動的に更新される。以下でビデオクリップ生成方法に関してさらに説明するようにして、プレイリストまたはマニフェストファイルは生成される。

[0054] 図４ｃを参照すると、一実施形態において、モバイル機器１０４上のモバイルアプリはさらにニュースペイン４０１ｃを含んでもよい。ニュースペイン４０１ｃは、クラウドサービスプロバイダからの情報をユーザに提供する。一実施形態において、ニュースペイン４０１ｃはユーザに、ユーザの１つまたは複数の機器によって生成されたビデオクリップに関連する、クラウドサービス１０３上のビデオクリップへのリンクを提供することができる。例えば、ユーザのイベントビデオクリップ（例えば自動車事故、侵入など）とほぼ同じ時間に生成され、かつ他のユーザから利用可能である、近隣のカメラ機器からのビデオへのリンクが、ニュースペイン４０１ｃでユーザに提供されてよい。以下でさらに説明するように、一実施形態において、ユーザのビデオクリップに関する共有要求もニュースペイン４０１ｃを通じて提供されてよい。

[0055] 先に述べたように、モバイルアプリに関して説明した機能は、モバイルアプリに関して説明した機能を実装するために従来のウェブサイトプログラミング技術を用いるウェブベースのシステム１０５を通じても提供されてもよい。

[0056] 再び図１を参照して、クライアント機器１０１の動作についてさらに詳細に説明する。好ましくは、クライアント機器１０１は２つ以上のカメラ２１４を含む。例えば、一実施形態において、第１の「イン」カメラ２１４ａは車両の内側（すなわちキャビン、ドライバー、および同乗者）に向けられ、第２の「アウト」カメラ２１４ｂは車両前方の道に向けられている。代替実施形態において、例えば車両の後方および／または側方、車両の複数の室内エリアを向いたものや、車両周囲３６０°の視野を提供する広角レンズを備えた１つ以上のトップカメラのような追加カメラ２１４が用いられてよい。

[0057] 一実施形態によれば、クライアント機器１０１は、動作に十分な電力を有する限り常にオン状態である。カメラ２１４ａおよび２１４ｂは常時オンされ、ビデオを記録している。カメラ２１４で記録されたビデオは、メモリデバイス２０３にバッファされる。一実施形態において、メモリデバイス２０３は環状バッファとして構成される。例えば、一実施形態において、メモリデバイス２０３は３２Ｇバイトのフラッシュメモリデバイスであってよい。クライアント機器１０１は、予め定められかつプログラマブルである設定時間分のビデオデータを保存するため、メモリデバイス２０３内のバッファを管理する。例えば、一実施形態において、メモリデバイス２０３は２つのカメラ２１４ａおよび２１４ｂからのビデオデータを直前の２４時間分バッファする。

[0058] 一実施形態において、クライアント機器１０１は、カメラ２１４によって生成され、メモリ２０３にバッファされるデータ量（例えばバイト量）を制御するため、カメラ２１４を管理するためのソフトウェアを含む。一実施形態において、カメラ２１４は様々な選択可能なビデオモードおよびレートでデータを記録する。例えば、カメラ２１４ａおよび２１４ｂは、例えば1440p、1080p、720p、360p、240pなどを含む様々な解像度でビデオをキャプチャするために、クライアント機器１０１により設定することができる。さらに、各カメラ２１４で収集されるビデオについてのフレームレートは、クライアント機器２０１によって設定することができる。例えば、一実施形態において、各カメラ２１４は、自身のビデオキャプチャレートを１秒当たり０から３０フレームの間で独立して変更することができる。

[0059] 図５を参照すると、一実施形態に従ってビデオバッファリングを管理するためのビデオ収集方法が示されている。一実施形態において、利用可能なカメラそれぞれについての解像度およびフレームレートを変更するために様々な入力が用いられる。電源が投入されると、カメラはデフォルト記録設定に設定される（５０１）。複数の入力が様々なソースから受信される（５０２）。例えば、一実施形態において、プロセッサ２０１は、位置および／または動きデータを測位モジュール２０４から、加速度データを加速度計センサ２１５ａから、例えば車両のエンジンの１分あたりの回転数(RPM)、車両のバッテリー充電レベルなどのような車両ステータスデータをCANバスに接続されたＩ／Ｏモジュール２０１から、時刻（例えばLTEネットワーク時刻）を無線モジュール２０５から、画像処理入力（例えば顔認識、人体認識など）をビデオモジュール２０７から、といったように受信する。入力は、例えば、動きまたは動きなし、ユーザの存在、ユーザ以外の人物の存在などといった、車両の動作モードに影響を与える関連特徴(relevant features)を判定するために用いられる。

[0060] 受信した入力に基づいて、動作モードが決定される（５０３）。例えば、一実施形態に係る車両一体型クライアント機器１０１の可能性のある動作モードとしては、デフォルト、ドライビング、最近駐車(recently parked)、駐車中(parked)、アームド(armed)、バッテリー容量低下(low battery)、バッテリー容量極小(very low battey)を含んでよい。別の実施形態では、動作モードのサブセットあるいは追加の動作モードを提供することができ、それらは車両や、クライアント機器１０１（または補助カメラ）が位置しうる他の場所に応じて変化しうる。表１は、一実施形態にしたがって社楼の各ステータスを規定するための例示的な入力セットを示している。本技術分野に属する当業者が理解するであろうように、本発明の範囲を逸脱することなく、他の動作モードおよび他の入力を提供することができる。

[0061] ステータス変化がステップ５０４で判定される。例えば、起動後、入力データが受信されると、動作モードはもはや「デフォルト」ではない。決定された動作モードに基づいて、記録されているビデオのデータ量を増減するためにカメラ設定（例えば解像度およびフレームレート）が変更される（５０５）。例えば、表２は、一実施形態にしたがった、「イン」カメラ２１４ａと「アウト」カメラ２１４ｂとを有する、車両内の２つのカメラクライアント機器１０１の例示的なカメラ設定を示している。本技術分野に属する当業者が理解するであろうように、本発明の範囲を逸脱することなく、異なる数のカメラおよび動作モードについての異なる設定を提供することができる。

[0062] カメラ設定が変更されると、カメラ設定を用いてビデオ記録が行われる（５０６）。この場合、バッファを管理するため、関心のあるイベントについてビデオをキャプチャする可能性がより高い動作モードの間はより多くのビット数を有するより高品質のデータを、関心のあるビデオをキャプチャする可能性がより低い動作モードの間はより少ないビット数を有するより低品質のデータを保存することにより、ビデオデータオブジェクト、レコード、またはファイルのサイズを変化させる。

[0063] 代替実施形態において、図５に示すように、様々な動作モードに追加動作が関連づけられてもよい。本実施形態では、方法は５０７において、動作モードが追加動作を必要とするか否かをチェックする。もし必要であれば、動作がステップ５０８で実行される。例えば、一実施形態において、「バッテリー容量低下(Low Battery)」モードと判定されると、クライアント機器１０１は例えばユーザに通知、例えばモバイル機器上のアプリを通じたテキストメッセージ、電子メールなどを送信する。別の例として、「バッテリー容量極小」モードと判定されると、システムは同様のユーザ通知を送信したのちに電源をオフすることができる。同様に、例えばシステムが長い時間にわたって用いられている場合、所定時間（例えば２４時間）内に生成されたデータ量がバッファサイズを超えようとしており、例えばシステムが保存されているビデオデータを所定時間が満了前にシステムが上書きしなくてはならないであろう場合、「バッファサイズ限界」モードと判定することができる。その場合、カメラ設定を削減するのに加え、システムはユーザに通知を送信してもよい。本技術分野に属する当業者が理解するであろうように、本発明の範囲内でシステムに付加機能を提供するため、異なるモードに対して異なる動作を関連づけることができる。動作の１つがシステムの電源をオフしない場合、上述したようにステップ５０６において記録を継続することができる。

[0064] 一実施形態の別の態様によれば、予め設定される、プログラム可能な時間量を超えてビデオデータがメモリデバイスに保存されないことを確実にするため、クライアント機器１０１で用いられるバッファ管理手順は、バッファリングに利用可能なメモリを最適化するであろう。例えば、バッファリング時間が２４時間に設定されているとすると、クライアント機器１０１は、２４時間の限界に近付くにつれて「古くなった」ビデオデータが新しいビデオデータによって上書きされることを確実にするため、ビデオデータオブジェクトまたはファイルのサイズを変更するためにカメラ設定を変更することができる。例えば、一実施形態において、車両の動作モードが「駐車中」と判定されていても、プロセッサ２０１は、循環バッファ内でより古いビデオデータが上書きされることを確実にするために、そのモードを「ドライビング」モードに関連づけられたカメラ設定に上書きすることができる。利用可能な最高品質のビデオおよび最大フレームレートを使用している場合であっても、バッファ内の一部のビデオデータが２４時間後も残っている場合には、システムはビデオデータを削除する。

[0065] 本発明の別の態様によれば、一実施形態において、バッファ管理手順は、機器のバッファメモリ内のビデオデータの保存をさらに最適化するための学習機能をさらに含む。一実施形態によれば、バッファ管理アルゴリズムへのさらなる適用のために、カメラ機器はカメラ機器の利用を監視して利用履歴データを生成する。例えば、一実施形態において、各モードがアクティベートされた時刻と、各モードがどれくらいの長さでアクティベートされたかが記録される。そして、バッファ管理手順はバッファの利用を最適化するために、および／またはバッファあふれを回避するために、モード履歴情報を用いる。例えば、直近の２４時間タイムフレーム内で使用されたバッファのパーセンテージと、履歴情報に基づいた残り時間について予期される使用量とが、所与のモードに対するカメラ品質設定を削減もしくは増加するためにカメラ設定変更ステップ５０５において考慮される。例えば、２４時間の期間の２０時間目においてドライビングモードを設定すべきと決定した後、方法はさらにバッファ使用率をチェックし、例えば履歴的には８０％である際に５０％であれば余分な容量があると判断し、また、使用履歴データに基づいて、２４時間における次の４時間でバッファを２０％利用することが予期されると判断する。バッファが十分に利用されていないため、方法は、ドライビングモードに対するビデオ品質を、例えば両方のカメラについて1440p/30fpsに高める。

[0066] 別の実施形態において、車両に設置されたクライアント機器１０１は、ドライビングについてのユーザの典型的なスケジュールおよび対応するモード（朝に通勤、昼まで駐車、ランチ「ドライブ」、午後は「駐車」など）を学習し、各時点で予期されるバッファ利用を考慮する、バッファ管理のための学習アルゴリズムを含む。この実施形態において、ある１日について２４時間の期間の早い段階でより高品質なカメラ設定を必要とするモードをもたらす普通でないイベントが存在する場合、その日におけるその後の低品質設定モード（例えば駐車中モード）のカメラ設定を、そのモードにおける通常の設定よりも低い解像度およびフレームレートにさらに削減することができる。あるいは、典型的な動作スケジュールにおける変更を示すためにユーザの直接入力がさらに与えられてもよい。例えば、ユーザはシステムを長旅に利用することを指示することができ、ユーザ入力はその時間期間について予期されるスケジュールを上書きするために用いられる。

[0067] 本発明の別の態様によれば、一実施形態において、システムが学習したバッファ利用履歴データが動作モード決定ステップ５０３にさらに入力される。この実施形態においては、入力の組み合わせの強さに基づいて各動作モードについての確率を決定するために、重み付け関数が用いられる。例えば、GPS入力が動きの無いことを示しているが、CANバス入力がいくらかのRPM＜を示している場合、GPSおよびCANバス入力の両方が動きの無いことを示している場合よりも、モード決定に関して動き成分の信頼性は低い。同様に、顔認識の肯定入力(positive input)はモードが「ドライビングモード」である確率を高めるであろう。必要に応じて、任意の画像認識入力の信頼性レベルは、モード決定に関する重み係数としても用いることができる。例えば、肯定的な画像認識マッチの信頼性又は確からしさ(likelihood)（例えば、顔、ユーザの顔、身体、ユニフォーム、点滅する光などの肯定的な認識の確からしさ）は、モード決定に対するマッチの寄与に対する乗数として用いられる。動作モードの決定は、複数の入力からの様々な確率が閾値を超えた場合に確立される。一実施形態において、モード確率閾値は、バッファ使用履歴データに基づいて変更される。例えば、バッファ保存期間（例えば２４時間）のうち、所与の時間に対するバッファ保存が予期される使用レベルを超える場合には、より高い解像度／フレームレートを用いるモードの決定にはより高い閾値を用いる。逆に、使用履歴データに基づいてバッファ保存が少ない場合には、同じモードに対するモード閾値を低減することができる。

[0068] 図６ａを参照して、一実施形態に従ったビデオのキャプチャおよび保存のための方法を提供する。上述したように、様々な機器のビデオカメラは好ましくは常時オンかつビデオを記録している。ビデオが記録され始めると、方法は６０１から、機器がオフされるまで、あるいはモバイル機器１０４であればモバイルアプリが稼働を停止するまで継続する。各カメラについて、撮像素子は、図５に関して上述したように、現在の動作モードに関するカメラ設定に従ってビデオデータを生成する。ビデオデータは受信され（６０２）、MPEG-4、H.264、H.265、あるいは他の任意のビデオ圧縮および符号化仕様のような、ビデオ圧縮および符号化仕様に従って、予め設定された時間期間ごとにビデオが符号化される（６０３）。ビデオの各ブロックに対応する時間期間は、予め定められてもよいし、（例えばユーザ設定に基づいて）可変であってもよく、例えば２、４、６、または１０秒であってよい。一実施形態において、２秒ごとにビデオはビデオデータオブジェクト、レコード、またはファイルにまとめて符号化される。別の実施形態では、例えばビデオの使用目的、システムの目的、システムが展開される場所、利用可能なメモリの量、利用可能な処理能力、あるいは他の関連する要因に応じて、異なる時間期間を用いてもよい。同一時間期間に対するメタデータが、キャプチャされたビデオデータに関する情報として６０４でさらにキャプチャされる。６０４のメータデータキャプチャの一部として、その時間期間についてのビデオデータおよびメタデータを一意に特定するために、全体で一意なID（GUTD)が生成される。

[0069] 一実施形態において、ビデオデータは暗号化される（６０５）。例えばAES(Advanced Encyption Standard)、Blowfish、Twofish、DES (Data Encryptiuon Standard)（例えばTriple-DES)、RSAなどに準拠した暗号化アルゴリズムのような、任意の暗号化アルゴリズムを用いることができる。好ましくは、ビデオデータは６０５においてユーザが指定した暗号鍵に基づいて暗号化される。車両ベースの実施形態において、暗号鍵は車両の運転を許可された各ドライバーに対して提供される。例えば、この実施形態では、システムを動作させるためにドライバーからの生体入力を必要とし、認定ドライバーを特定するために指紋認識、音声認識、または顔認識ベースの認証などが用いられる。各認定ドライバーに対して、対応する、ランダムに生成された暗号鍵がデータテーブルに維持される。認定ドライバーが車両を運転していると判定されている間に生成されたビデオは、ドライバー固有の鍵を用いて暗号化される（６０５）。その後は、プライバシーを提供するため、生体認証を用いて認定ドライバーだけが暗号化されたビデオにアクセスすることができる。

[0070] 別の実施形態において、ビデオ暗号化６０５は別の形態のユーザIDに基づく。例えば、一実施形態において、認定ユーザのモバイル機器１０４についてのブルートゥースIDが、認証に用いられる。この実施形態では、例えば、クライアント機器１０１は、関連づけられたブルートゥースIDの存在をクライアント機器１０１が認識したユーザの写真または複数の写真を表示することができる。認識されたドライビング中のユーザは、クライアント機器１０１の画面上の自身の写真を選択することができ、対応する暗号鍵がビデオの暗号化に用いられる。別の実施形態では暗号鍵を選択するための別の手法を用いることができる。例えば、複数の認定ユーザが検出されている状況において、認識された認定ユーザのうち最高レベルの認定ユーザに対する暗号鍵がビデオの暗号化に用いられるように、オーナーレベル対ゲストレベル、または親レベル対子供レベルといった、認定ユーザの階層的なレベルが提供されてもよい。あるいは、一部の実施形態において、暗号化６０５はユーザベースでなくてもよい。例えば、暗号鍵は各機器に固有なランダム鍵であってもよい。さらに、一部の実施形態において、システムはステップ６０５を省略してビデオを非暗号化形式で記録してもよい。

[0071] 本発明の別の態様によれば、カメラ機器を備える車両の乗客に対して、いくつかの他のプライバシー対策が必要に応じて提供されてもよい。例えば、ライドシェアリングアプリケーションに関して、顧客／乗客は、クライアント機器１０１による情報取得から自身のプライバシーを保護することを望みうる。この実施形態では、ライドシェアリングモバイル機器アプリが、ユーザによるカスタマイズが可能なプライバシー機能を提供する。車両内でユーザ／顧客を検出すると、クライアント機器１０１は検出された乗客に関するプライバシー設定を検索し、それを適用する。例えば、顔認識、ブルートゥースID、または乗客を認識する他の手段を用いて、所定のカメラをオンまたはオフする、ビデオまたはその一部（例えば顔）をぼかす、収集されたセンサデータのうち、保存するものの数の増減、および／またはクライアント機器１０１の他の機能の有効化もしくは無効化などのような、ライドシェアリングしている乗客の設定(preference)がクライアント機器１０１に適用されてよい。一実施形態において、カスタマイズ可能な設定へのアクセスを提供するには顧客の資格(qualifications)が必要とされてもよい。カスタマイズ可能な設定は、例えばライドシェアリングサービスの継続利用（例えばロイヤルティポイント／レベル）、支払いレベルなどに基づく、異なる階層でアクセス可能であってよい。

[0072] 図６ａに戻って、所与の時間期間についての暗号化されたビデオデータおよび関連するメタデータは、バッファに保存される（６０６）。得られたビデオデータオブジェクトまたはファイルは、適用されたカメラ設定（例えば解像度、フレームレートなど）のみならず、適用された圧縮フォーマットおよび符号化のような他の要因にも応じた様々なサイズを有するであろう。そして、６０７においてビデオデータオブジェクトは、キャプチャされたビデオに対する固有ハッシュ、すなわちビデオデータハッシュを生成するため、SHA、MD5、または同様のアルゴリズムのような１方向ハッシュ関数を用いてハッシュされる。必要に応じて、ハッシュ関数はビデオデータとメタデータの両方を含んだファイルに適用されてもよい。あるいは、メタデータはビデオデータと関連付けられた上で別個に保存されてもよく、したがってメタデータは６０７におけるハッシュ生成には含まれない。

[0073] 一実施形態においては、６０８で、各時間期間に対するメタデータと、対応するビデオデータハッシュとを含んだメッセージが生成される。好ましくは、メッセージペイロードが正当な機器から発せられたことを保証するため、このメッセージはその後６０９で暗号法的に署名される。例えば、システムに認可された機器に関連づけられた秘密鍵が、メッセージペイロードの一方向ハッシュを生成するために用いられてもよい。別の実施形態において秘密鍵はメッセージのペイロードを暗号化するために用いられる。一実施形態において、クライアント機器１０１、補助カメラ１０６、およびモバイル機器１０４のそれぞれは、固有の暗号鍵ペアに関連づけられる。機器は、秘密鍵を安全に保存する。クラウドシステム１０３は、認定機器から受信するメッセージを検証できるように、各機器に関する公開鍵へのアクセスを維持する。例えば、クラウドシステム１０３は、システム内の各認定機器に関する機器IDを、対応する、その機器から受信したメッセージに適用する公開鍵に一意に関連づける、レコードセットを維持する。例えば、受信メッセージのそれぞれが、認定機器からの秘密鍵を用いて暗号化された署名または暗号化されたペイロードを含むことを検証するために、秘密−公開−鍵暗号化署名手法を用いることができる。
さらに別の実施形態では、例えば、実際のビデオデータオブジェクトをクラウドシステム１０３のような別の機器に送信もしくはアップロードする場合、クライアント機器はステップ６０７で、必要に応じて、ビデオデータオブジェクトをハッシュする代わりに、ビデオデータオブジェクト自体に暗号法的に署名する、もしくはビデオデータオブジェクト自体を暗号化するために、自身の秘密暗号鍵を用いる。これは、上述したように、必要に応じてステップ６０９とともに実行してもよい。

[0075] 最後に、メッセージはクラウドシステムに送信される（６１０）。好ましくは、メッセージは例えばTCP/IP上のSSL/HTTPS接続のようなセキュアな接続を用いて送信される。そして、処理は引き続く時間期間にキャプチャされるビデオデータおよびメタデータに関して繰り返される。好ましくは、図６ａの処理を実行するために必要な時間は、選択された時間期間よりも短い。例えば、増加量（時間期間）２秒でビデオデータをキャプチャする機器は、メタデータおよびビデオハッシュメッセージをクラウドシステム１０３に２秒ごとに送信する。ある時点でクラウドへのデータ接続が中断され、もしくは利用できなくなった場合、システムは、再接続に応じてクラウドシステム１０３へ送信するため、メッセージをローカルキャッシュすることができる。

[0076] 代替実施形態において、メッセージ署名ステップ６０９は省略される。代わりに、機器はクラウドシステム１０３とSSL/HTTPS接続のようなセキュアな接続を確立し、サーバ１０２に対して自らの認証を行う。例えば、機器は自身の機器IDと、機器の秘密鍵を用いて自身の機器IDを暗号法的に署名したものとを提供する。サーバ１０２は提供された機器IDに対応する公開鍵を検索し、署名された機器IDの合致について検証する。認証がなされると、サーバは機器に、所与のセッションに関するその機器からの通信を一意に特定するセッショントークンを機器に提供する。その後、６１０でメッセージは、セキュアな接続上で、メタデータおよびビデオハッシュとともに、かつサーバから提供されたトークンを含めて送信される。

[0077] 図６ｂには、一実施形態に係る、所与のビデオデータオブジェクトまたはファイルに関するメタデータをキャプチャするためのデータモデルが示されている。一実施形態において、ビデオオブジェクトメタデータ６２０は、機器テレメトリー情報としてクラウドシステム１０３に繰り返し送信される。一実施形態において、テレメトリー情報６２０は、（例えば２秒、６秒、８秒、１０秒などごとの）各ビデオオブジェクトの記録後に送信される。ビデオオブジェクトメタデータ６２０は、例えば機器ID６２１、原子時計タイムスタンプ６２２、GPSタイムスタンプ６２３、緯度値６２４、経度値６２５、高度６２６、速度６２７、磁針方位(compass heading)６２８、水平測位精度値６２９、垂直測位精度値６３０、ソフトウェアバージョン６３１、ロケーションストリング値（例えば「ジオハッシュ」）６３２、接続タイプ識別子（例えば２Ｇ、３Ｇ、４Ｇ、ＷｉＦｉなど）６３３、無線信号強度値６３４、および／またはキャリア識別子６３５を含む、１つ以上のメタデータ項目を含みうる。本技術分野に属する当業者は、これらメタデータ値の任意の組み合わせがメタデータの実装および用途に応じて用いられ得ることを理解するであろう。

[0078] 図６ｃには、一実施形態に係る、自動生成されるビデオクリップ、ユーザが生成するビデオクリップなどのような、所与のイベントベースのビデオクリップに関するメタデータをキャプチャするためのデータモデルが示されている。一実施形態において、各ビデオクリップとともにイベントメタデータ６５０が生成され保存される。イベントメタデータ６５０は、例えば、機器ID６５１、原子時計タイムスタンプ６５２、ロケーションストリング値（例えばジオハッシュ）６５３、イベントまたはタグタイプ６５４、イベントまたはタグタイプ６５５、イベントまたはタグタイトル６５６、イベントまたはタグ緯度値６５７、イベントまたはタグ経度値６５８、イベントまたはタグ高度６５９、イベントまたはタグ速度６６０、イベントまたはタグ磁針方位６６１、イベントまたはタグ水平測位精度値６６２、イベントまたはタグ垂直測位精度値６６３、イベントまたはタグクリップファイル（例えばマニフェストファイル）についての完全ファイル名６６４、ソフトウェアバージョン６６５、機器タイプID６６４、および、イベントまたはタグクリップが閲覧６６５ａ、共有６６５ｂ、削除６６５ｃなどされたか否かを示す１つ以上のブール変数を含む、１つ以上のメタデータ項目を含みうる。

[0079] 図７を参照して、一実施形態に係る、イベントベースのビデオクリップを生成するための方法を説明する。システムが起動されると、方法が開始する（７００）。ビデオが継続的にキャプチャされながら、様々な入力が監視される（７０１）。タグ付けするイベントが検出されなければ（７０２）、システムは監視を継続する。タグ付けするイベントが検出されれば（７０２）、バッファ内の、関連するビデオデータが特定され、選択される（７０３）。例えば、イベントが一旦検出されると（７０２）、イベント前後の予め定められた時間期間のビデオファイルがバッファ内で特定される。一例として、イベントの前後１５秒が用いられる。好ましくは１０から３０秒である時間量は、予めプログラムされていてもよいし、ユーザが選択可能であってもよい。さらに、イベント前の時間とイベント後の時間とで、２つの異なる時間期間を用いてもよい。一実施形態において、時間期間は検出されたイベントに応じて異なってもよい。例えば、一部のイベントに関しては時間期間がイベント前３０秒、イベント後１または２分であり、他のイベントでは前後とも１５秒であってよい。

[0080] 選択されたビデオデータは、７０４でより長い期間バッファされるようにマークされる。例えば、選択された時間期間についてのビデオファイルは、ビデオをより長い期間維持する別のバッファリングポリシを有する第２のシステムバッファにコピーされる。一実施形態において、２４時間分のビデオを保存するバッファ内で選択されたビデオデータは、ビデオを７２時間保存する第２のバッファへ移される。

[0081] 図７に戻り、選択されたビデオデータを用いてビデオクリップが生成される（７０５）。個々のビデオオブジェクトと同様に、生成される個々のビデオクリップは、グローバルに固有の識別子(GUTD)と関連づけられる。一実施形態において、ビデオクリップは、本技術分野で既知のように、プレイリストファイルまたはマニフェストファイルを用いて生成される。各プレイリストまたはマニフェストファイルは、GUIDを含んでいる。例えば、一実施形態において、（例えば2017年5月22日にIETFにアップル社が提出したインターネットドラフトdraft-pantos-http-live-streaming-23 に記述されるような）HTTPライブストリーミング仕様にしたがって、ｍ３ｕ８プレイリストファイルが生成される。他の実施形態では、例えばMPEG-DASH (ISO/IEC 23009-1)、アドビ社のHTTP Dynamic Streaming、マイクロソフト社のSmooth Streamingなどを含む、別のストリーミング技術が用いられてもよい。プレイリストまたはマニフェストファイルは、７０３で選択されたビデオデータオブジェクトについての、ネットワークベースの位置を与える。例えば、ユニバーサルリソースロケータ(URL)が、ビデオファイルセットごとに与えられてよい。この手法を用いることで、ネットワークアクセス可能な任意のストレージにビデオデータを保存することができる。例えば、所与のプレイリストで特定されるビデオファイルは、カメラ機器（例えばクライアント機器１０１、補助カメラ１０６、またはモバイル機器１０４）に保存することができ、その場所における各ファイルについてのネットワークアドレスロケータが提供される。代替実施形態においては、他のビデオクリップ生成手法が用いられてもよい。例えば、一実施形態において、７０３で選択されたビデオデータは、必要に応じてアップロードおよびダウンロードされてよい、MPEGビデオファイルのような１つのビデオファイルを生成するために用いられる。

[0082] 一実施形態において、ビデオデータオブジェクトはカメラ機器のネットワークアクセス可能なバッファに保存され、イベントベースのビデオクリップを生成するためのプレイリストまたはマニフェストファイルは、ビデオデータオブジェクトまたはファイルを保存する記憶バッファ記憶位置に関するネットワークアドレスを特定する。あるいは、７０３において関連するビデオデータオブジェクトを特定および選択すると、ビデオデータを７０４で長期バッファに移すことに加えて、あるいはその代わりに、ビデオデータをクラウドシステム１０３にアップロードしてもよい。そして、クリップ生成ステップ７０５は、プレイリストまたはマニフェストファイルにおいて、クラウドシステム１０３に保存されているビデオデータについてのネットワークドレスを特定する。システム内で用いられるカメラ機器についての記憶容量およびネットワーク能力に応じて、あるいは可能性のある様々な実装上の選択に従って、これらの手法の組み合わせを用いることができる。

[0083] 一実施形態において、クラウドシステム１０３またはモバイル機器１０４のような他のシステム構成要素は、イベントもしくはイベントベースのビデオクリップを通知される（７０６）。例えば、一実施形態において、ビデオクリップを生成するためのGUTDを含んだメッセージが、（上述したように）暗号法的に署名されたメッセージの中でクラウドシステムに送信される。必要に応じて、プレイリストまたはマニフェストファイルもまたメッセージ内で送信されてもよい。一実施形態において、プレイリストまたはマニフェストファイルは、要求されるまでカメラ機器のローカルメモリ内で維持される。例えば、７０６でクリップ生成が通知されると、クラウドシステムはクリッププレイリストまたはマニフェストファイルを要求することができる。必要に応じて、クラウドシステムは、他のシステム構成要素および／またはクリップの他のユーザに通知することができ（７０６）、他のシステム構成要素またはユーザは、クリップをクラウドシステム１０３に、あるいは直接カメラ機器に要求することができる。例えば、ユーザのモバイルアプリにおけるクリップペイン４０１ａは、７０６で通知を受信すると、クリップ情報を表示することができる。クリップメタデータのデータ量が大きくない（例えば数キロバイト程度）とすると、ユーザアプリはタグイベントが生成された後、ほぼ同時に通知を受けることができる。クリップについてのビデオデータに関する大量のデータは、後で、例えばクラウドシステムを通じて、または直接、モバイル機器に転送することができる。例えば、「駐車車両内に乳児/動物」イベントまたは「位置不連続」イベントが検出されると、ユーザのモバイル機器１０４はタグメタデータだけを用いてタグイベントを直ちに通知されてよい。その後ユーザは、例えば検証を目的として、遠隔保存されているビデオにアクセスするためにビデオクリッププレイリストを用いることができる。

[0084] 一旦ビデオクリップが生成されると（７０５）、そのビデオクリップは同じユーザが所有する他の機器で共有されてよい。また、それが許可されれば、ビデオクリップはシステムの他のユーザで共有されてもよい。例えば、所与のユーザのカメラ機器で生成される個々のビデオクリップについてのGUTDを、クラウドシステム１０３のユーザクリップテーブルに保存することができる。例えば、マルチカメラクライアント機器１０１の全てのカメラからのクリップに関するGUTD、任意の補助カメラ機器１０６からのクリップに関するGUTD、およびユーザのモバイル機器１０４のモバイルアプリが生成したクリップに関するGUTDは、全てユーザクリップテーブルに保存されてよい。ユーザはモバイル機器１０４を通じてユーザクリップテーブルにアクセスすることができる。例えば、モバイルアプリはクラウドシステム内のユーザクリップテーブルと同期されるユーザクリップテーブルを維持することができる。新しいクリップ通知を受信するたびに、モバイルアプリおよびクラウドベースのユーザクリップテーブルは更新されおよび／または同期される。例えば周期的同期手法のような別の同期手法が用いられてもよい。

[0085] GUIDに加え、一実施形態においてユーザクリップテーブルは、ユーザの各クリップについて、例えば名称またはデスクリプタ、ビデオをキャプチャした機器ID、日時情報、タグまたはイベント情報、サムプリント情報などのような他の情報またはメタデータをさらに含んでもよい。さらに、プレイリストまたはマニフェストファイルが、ユーザクリップテーブル内にさらに保存されるか、ユーザクリップテーブル内で特定されてもよい。一実施形態において、ユーザはクリップペイン４０１ａを通じたモバイル機器１０４上のモバイルアプリを通じてビデオクリップにアクセスすることができる。クリップペイン４０１ａを通じたクリップの選択に応じて、モバイルアプリは、対応するプレイリストまたはマニフェストファイルを、クラウドシステム１０３に要求、あるいはカメラ機器（例えばクライアント機器１０１または補助カメラ１０６）に直接要求するために、クリップGUIDを用いる。プレイリストまたはマニフェストファイルを用い、モバイルアプリは、関連するビデオオブジェクトをそれらのネットワークアドレス識別子を用いて要求することにより、ビデオクリップを再生することができる。一実施形態において、ビデオデータオブジェクトが暗号化されていれば、上述したように、ユーザは暗号解除鍵にアクセスするためにID（例えば生体ID、顔認識、ユーザIDとパスワード、など）を提供してもよい。

[0086] 一実施形態によれば、同一ユーザアカウントで登録された複数の機器で生成されたビデオクリップは、自動的にそのユーザによって共有される。本開示の別の態様によれば、ユーザはまた、システムを通じて、または他のインターネットを通じたメッセージのやりとりやインターネット接続性を用いて、他のユーザとビデオクリップを共有することができる。例えば、一実施形態において、モバイル機器１０４上のモバイルアプリ（またはウェブベースのシステム１０５上のウェブサイト）は、フェイスブック、ツイッター（登録商標）、グーグルプラス、またはソーシャルネットワークプラットフォームからの他のサイトのようなソーシャルメディアサイトまたはネットワークに、ビデオクリップをリンクまたはパブリッシュするための機能を含む。ビデオクリップは、電子メール、テキストメッセージング、または同様の電子的通信手法を通じて直接共用されてもよいし、あるいは他のコンピュータシステムにエキスポートされてもよい。一実施形態において、クラウドシステム１０３は所与のビデオクリップに関するビデオデータを、公的にアクセス可能なネットワークストレージロケーションに保存する。クラウドシステム１０３は、本技術分野で知られるようなイベントベースのビデオクリッププレイリストまたはマニフェストファイルを用いてだれもがインターネットを通じてアクセス可能であってよい。ユーザはプレイリストまたはマニフェストファイルを直接、またはインターネットを通じてアクセス可能なストレージロケーション（例えばクラウドシステム１０３または他の同様の場所）に保存されたプレイリストまたはマニフェストファイルへの（URLのような）ネットワークリンクを用いて、共有することができる。

[0087] 本開示の別の態様によれば、ビデオクリップはさらにシステムの他のユーザと自動的に共有されてもよい。例えば、システムに参加すると、自身のビデオクリップをシステムの他のユーザと共有することについて事前に許可するための複数のオプションがユーザに提示されてよい。一実施形態において、ユーザは所定のカメラ機器が生成したビデオクリップへのアクセスを事前に許可するためのオプションを有する。例えば、ユーザは車両ベースのシステムの「アウト」カメラがキャプチャしたビデオデータを用いて生成されたビデオクリップを共有することを許可することができる。必要に応じて、ユーザは他のユーザと共有するビデオクリップに制限を課してもよい。例えば、ユーザは、音声付きまたは音声なしの所定のビデオ品質のビデオクリップなどの共有だけを許可してもよい。例えば、ユーザは車両ベースのシステムにおける「イン」カメラからの、音声なしのビデオクリップの共有を許可することができる。必要に応じて、ユーザのビデオクリップへのアクセスの事前許可のための別のオプションは、位置に基づくものであってよい。例えば、ユーザは「自宅」補助カメラ１０６によって生成されるビデオクリップへのアクセスを、予め定められた半径内の位置で登録されている他のユーザ（例えば隣人）に事前許可することができる。システムの一部であるカメラ機器の位置は、IPアドレスルックアップ、（例えばスマートフォン機器、クライアント機器などからの）GPS位置、または自身による位置の手動入力によって特定することができる。新たなユーザが参加する都度、近くに存在するユーザを判別するために、そのユーザの位置（例えばホームアドレス、お気に入りの場所など）が用いられる。例えば、一実施形態において、ユーザの１組ごとの距離が計算されてデータベースに維持される。そして、どのユーザが他のユーザについて「近隣」しているかを指定するために予め定められた限界半径または距離が適用される。指定は例えば、対ごごとの距離が予め定められた半径未満であるユーザにフラグを付加することにより行われる。一実施形態においては、サインイン処理の間に、システムが、新規ユーザと共有するための同意要求を既存のユーザに送信する。あるいは、別の実施形態では、システムにサインオンすると、各ユーザは少なくとも一部のカメラ固有のビデオを「隣人(neighbors)」または「近隣(nearby)」ユーザと共有することを事前許可する。加えて、ユーザは、隣人と共有されうるビデオクリップに関して追加制限を提供することを許されてもよい。ビデオクリップ共有機能に関する別の態様によれば、ユーザは個々のビデオクリップに共有指定を付加してもよい。一実施形態において、共有するビデオクリップと共有しないビデオクリップとをユーザが制御できるように、この共有指定は他のいかなる事前許可をも上書きするであろう。例えば、共有される隣人のビデオにウェブベースのシステム１０５やモバイル機器１０４を通じてアクセスするといった、ビデオクリップを共有するための別の技術を、以下でさらに説明する。

[0088] 本開示の別の態様によれば、タグ付けイベントの検出（７０２）はシステムによって自動的に行われてもよい。例えば、監視される入力に基づいて、様々な実施形態において車両事故、検問、侵入といったイベントが自動的に検出されてもよい。７０１で監視される入力は例えば、画像処理信号、音声(audio)処理信号、センサ処理信号、会話(speech)処理信号を任意の組み合わせによって含むことができる。一実施形態において、画像処理信号は、１つ以上のカメラからのビデオデータに対して適用される、顔認識アルゴリズム、乳児認識アルゴリズム、および／またはオブジェクト／パターン検出アルゴリズムを含む。例えば、ユーザの顔が車内に存在すると認識されてもよい。別の例として、警察、消防または他の緊急車両の点滅灯がビデオデータで検出されてもよい。別の画像処理アルゴリズムは、ビデオデータ内で（認識されたユーザ以外の）人間の顔や、制服を着た人物の存在を検出する。同様に、音声処理信号は、カメラ機器（例えばクライアント機器１０１、補助カメラ１０６、またはモバイル機器１０４）の１つ以上のマイク２１２で録音された音声に基づくことができる。一実施形態において、音声処理は周波数ドメインに変換された、音声クリップの音声パターンまたは特徴(signature)の解析に基づくことができる。例えば、最小閾値レベル（例えば予め設定されたデシベル単位の数）を超える音声を検出すると、関連する音声信号が記録され、記録された時間領域の音声信号に本技術分野で知られるように高速フーリエ変換(FFT)が実行される。そして、記録された音声信号の周波数ドメイン特徴は、合致するものがあるか否かを判定するために、ガラスが壊れる音、警察のサイレンなどといった、記録されたイベントに関する既知の周波数ドメイン特徴と比較される。例えば、一実施形態において、記録された音声入力の周波数ドメイン特徴内の複数組の点が決定され、選択された点間の比が、認識された音声イベントの音声特徴の同様の点間の比と比較される。

[0089] 音声処理はまた、人間の会話、言葉、および／または命令を認識するための音声認識および自然言語処理を含んでもよい。例えば、所定の「トリガ」語を特定のイベントに関連づけることができる。音声データ中に「トリガ」語の存在が見つかると、対応するイベントを判定することができる。同様に、入手可能なセンサの出力が、イベントに関連するパターンの存在を判定するために受信ならびに処理されてもよい。例えば、GPS信号、アクセル信号、ジャイロスコープ信号、磁力計信号などが、イベントの存在を検出するために受信ならびに解析されてよい。一実施形態においては、交通情報、天気情報、捜査報告などの、無線モジュール２０５を通じて受信されるさらなるデータが検出処理で用いられる。検出処理７０２は、これらの全ての潜在的な入力の組み合わせを可能性のあるイベントに関連づける、アルゴリズムおよび経験則を適用する。

[0090] 以下の表３は、車両実施における本発明の一実施形態に係る、対応するイベントについての例示的な入力、ルール、および経験則を示す。特定の例のセットを示しているが、本発明は用途に応じて、他の可能性のあるイベントを特定可能な多種多様な入力、ルール、および経験則に適用されてよい。

[0091] イベントと入力のこれら組み合わせは例示のみを目的としたものである。一部の実施形態ではこれらの入力および／またはイベントのサブセットが提供されてもよい。他の実施形態では入力および／または別のイベントの別の組み合わせが提供されてもよい。イベント検出アルゴリズムはカメラ機器（例えばクライアント機器１０１）でローカル実施されてもよいし、入力信号およびイベント検出出力は無線通信接続１０７／１０８上でカメラ機器へ／から送信することにより、クラウドサーバ１０２で実行されてもよい。あるいは、一部の実施形態においては、例えばクライアント機器で利用可能な処理能力に応じて、検出アルゴリズムのサブセットがカメラ機器でローカル実施され、他の検出アルゴリズムがクラウドサーバ１０２で実行されてもよい。さらに、一実施形態において、所与の入力の組み合わせについて最も可能性が高く合致するイベントを特定するため、人工知能(”ＡＩ”)アルゴリズムが複数の入力に適用される。例えば、可能性のあるタグ付けイベントのセットを認識するために、システムが用いる入力セットを用いてニューラルネットワークを学習させてもよい。さらに、システムの利用に伴ってニューラルネットワークをより洗練させるために、提案されたタグ付け結果を受け入れもしくは拒否するためのフィードバックの仕組みを、モバイルアプリを通じてユーザに提供してもよい。これは、経時的にシステムの性能を向上させる洗練処理を提供する。同時に、システムはアルゴリズムおよび発見的方法によって与えられる偽陽性を検出し、誤ってイベントにタグ付けすることを回避するためにそれらを改良するための学習を行うことができる。

[0092] 図５に戻って、一実施形態において、イベントを検出７０２すると、動作モードの決定５０３は動作モードを「アームド」などのような高品質設定モードに設定する。あるいは、カメラ設定変更５０５をすべてのカメラについて例えば１４４０ｐおよび３０ｆｐｓのような高品質設定に変更させる「イベント」動作モードが提供されてもよい。

[0093] 本開示の別の態様によれば、一実施形態において、検出処理７０２は、イベントの、ユーザの決定する手動タグ付けを検出するように構成される。ユーザはシステムに、ユーザにとって関心のあるイベントの存在の指示をシステムに与えてもよい。例えば、一実施形態において、ユーザはイベントの発生を示すためにクライアント機器１０１のタッチスクリーンをタッチすることができる。ユーザ「手動タグ付け」入力を検出７０２すると、システムは、図７に関して上述したようにイベントベースのクリップを生成する。代替実施形態においてユーザ指示は、音声コマンド、ブルートゥース送信信号などを含んでよい。例えば、一実施形態においてユーザは予め定められた単語または単語セット（例えば、「アウル、ノートを作って」）を発することができる。音声入力における言葉を検出すると、システムは認識を指示するためのキューを提供することができる。例えば、クライアント機器１０１は、手動タグ付けの認識を示すために、ビープ音を発したり、振動を発したり、または音声を出力したりすることができる。必要に応じて、ユーザ手動タグ付け入力の結果として得られるイベントベースのビデオクリップについての名前またはデスクリプタを与えるために、さらなるユーザ音声が入力されてもよい。例えば、イベントの短い説明がユーザによって発声されてもよい。ユーザの発声は音声テキスト変換アルゴリズムによって処理され、得られたテキストがビデオクリップに関連づけられるメタデータとして保存される。例えば、一実施形態において、ユーザによって与えられる名前またはデスクリプタは、モバイルアプリのクリップペイン４０１ａに、クリップデスクリプタ４０２として、モバイルアプリ上に表示されてもよい。別の実施形態において、さらなるユーザ音声は、さらなるコマンドを含んでもよい。例えば、ユーザは、手動タグ付けを指示したイベントの長さを、例えば３０秒の記録については「ショート」、２分の記録については「ロング」などのように指示してもよい。必要に応じて、ユーザ入力に基づいて任意のビデオクリップの長さを延長することができる。例えば、最初のイベントベースのビデオクリップが生成された後、ユーザはそのビデオクリップを見直し、前または後に追加時間を要求することができ、そして、図７に関して説明したようにして、関連づけられたビデオデータがプレイリストまたはマニフェストファイルに追加される。

[0094] 一実施形態において、タグ付け処理は必要ならプログラマブルであってよい。例えば、カメラ機器は、画像認識と分類器とを用いて道路標識を認識し、認識された標識に関連するメタデータをキャプチャおよび保存するようにプログラムされてよい。例えば、一時停止標識が検出されてよく、一時停止標識に関するメタデータとして速度および他のセンサデータが記録されてよい。この機能は、運転者の行動を監視するために第三者に用いられてよい。例えば、親は子供を監視することができ、保険会社は被保険者を監視することができ、雇用者は従業員を監視することができる、などである。必要に応じて、一実施形態において、カメラ機器は検出された標識およびセンサデータに基づいて運転者フィードバックを提供してもよい。例えば、一実施形態において、カメラ機器は道路駐車標識(street pafking sign)を認識し、ユーザに駐車制限に関して知らせることができる。例えば、機器はユーザに、「駐車禁止」ゾーン、時間制限つき駐車ゾーンに関してユーザに警報を与えることができ、および／または、（例えば標識画像認識、時間および位置情報に基づいて）ユーザが車に戻るのに十分な時間をもって、駐車時間制限が満了する前にユーザに気づかせることができる。本技術分野における当業者は、例えばスピード、交通信号／標識遵守、事故防止などに関するフィードバックのような、運転者フィードバックのさらなる応用が本発明の範囲内で可能であることを認識するであろう。

[0095] 別の実施形態において、画像クエリを遠隔的に与えるため、プログラマブルタグ付けは例えばセルラ通信モジュール２０５を介して遠隔的にアクセスされてもよい。例えば、一実施形態において、「アンバーアラート」に関するナンバープレートおよび／または車の画像クエリが、クラウドシステム１０３を通じ、当局によってシステム内の全カメラ機器に提供されてもよい。一実施形態によれば、すべてのカメラが特定の被写体または物体を探すことを可能にするため、画像クエリの標準的な「定義」を事前にカメラ間で共有することができる。必要に応じて、画像クエリは、カメラ機器が繰り返し画像クエリを実行する時間量を指定する時間成分を含んでもよい。例えば、アンバーアラートは、ある量の時間、例えば２４時間の間探索すべき１つ以上の画像クエリ（例えばナンバープレートおよび／または特定の車両ブランドおよび／または色）を提供することができる。必要に応じて、一実施形態において、ユーザはまた、プログラマブルタグ付け命令を、例えばモバイルアプリまたはウェブベースのインタフェースを通じて与えることができる。例えば、一実施形態において、ユーザはビデオデータを特定の時刻にキャプチャするためのタグ生成イベントをスケジュールするか、コマンドで録画を開始するようにカメラ機器に遠隔的に指示することができる。

[0096] 図８は、イベントベースのビデオクリップを特定および共有するための方法を示している。先に説明した、ビデオクリップを共有するための様々なオプションに加え、一実施形態においてビデオクリップは、異なるカメラ機器によって生成されるイベントに対する潜在的な関連性に基づいて共用されることもできる。そうするために、一実施形態において、ビデオクリップ共有要求が受信される８００。ビデオクリップ共有要求８００は、ユーザによって生成されるか、自動的に生成されてよい。例えば、一実施形態において、ユーザが共有アクセスを要求しうるカメラ機器の位置を表示する地図にアクセス可能であってよい。ユーザはビデオを要求したい１つ以上のカメラ機器を選択することができる。代替実施形態において、ユーザは共有要求を生成したいビデオについての位置、日付、および時間を入力する。

[0097] さらに別の実施形態において、ユーザはカメラ機器の画面に表示されているオブジェクト（例えば自動車、人物、アイテムなど）を選択してもよい。例えば、ビデオの再生中におけるクライアント機器１０１のタッチ画面へのタップ、音声コマンド、あるいはビデオに表示されているオブジェクトを特定することのできる他のユーザ入力デバイスを用いることができる。必要に応じて、関心オブジェクトはビデオ上で自動的に特定されてもよい。例えば、図７に関して上述した自動タグ付け機能の一部として、監視される入力７０１の一部が、画像処理によって得られる関心オブジェクトを含んでもよい。例えば、タグ付けイベントが侵入と判定され、監視される入力の１つが、検出された未認識の人物の顔を含む場合、未認識の顔が選択されたオブジェクトとして用いられていよい。

[0098] 選択されたオブジェクトをビデオから特定し、オブジェクトデスクリプタクエリを生成するために、画像処理アルゴリズムおよび／またはコンピュータビジョン技術が適用される。例えば、画像内の関心領域、例えばズームインされる領域を検出するために、ユーザ入力が適用される。関連領域についてのデータは、画像領域内で検出された関連ポイントを囲う画像データに関するベクトル表現に処理される。関連領域のベクトルまたはデスクリプタから、例えば二次統計、パラメトリックモデル、画像変換から得られる係数、またはこれら手法の組み合わせに基づいて特徴デスクリプタが抽出されるそして、画像内のオブジェクトについての、特徴に基づく表現は、他のビデオデータにおける照合のためのクエリとして用いられる。一実施形態において、ビデオクリップ共有要求は、オブジェクトに関する画像クエリと、オブジェクトが検出されたビデオデータからのメタデータとを含む。

[0099] 図８を再び参照すると、一実施形態において、共有要求を受信８００すると、要求に提供されるメタデータから、他のカメラ機器からのビデオクリップを共有するための関連メタデータが取得される８０１。例えば、一実施形態において、要求は、所望のビデオに関する位置、日付、および時刻を含んでよい。別の実施形態において、オブジェクトが検出されたビデオデータオブジェクトのGUIDを含んでよい。GUIDを用いることにより、そのビデオデータオブジェクトについてのメタデータファイルが取得され８０１、そのビデオデータオブジェクトについてのメタデータがアクセスされる。例えば、クラウドシステム１０３は、システム内の全ビデオデータオブジェクトについてのメタデータを保存する。メタデータはビデオオブジェクトのGUIDによってインデックスが付与されてもよい。代替実施形態において、ビデオクリップの共有要求は、関心オブジェクトが見つかったビデオオブジェクトからのメタデータの関連アイテムを含む。例えば、要求は、ビデオデータを記録したカメラ機器からの位置（例えば地理的座標(geo-coordinates)、GPSデータなど）、カメラの向き（例えば磁力計の計測値）、および時刻（例えば４G/LTEシステムからの原子時データ）含んでよい。

[0100] 取得されたメタデータ値を用い、要求に応答するビデオデータ（例えば同一の関心オブジェクトを含むか、所望の位置、日付、時刻、および／または向きに合致するものであってよい）を有するカメラ機器のセットが特定される８０２。一実施形態において、画像クエリベースの要求に応答して、所与のタイムフレームで所与の地理的半径内に位置するとともに、所望の方向を向いたカメラを有するカメラ機器が最初に特定８０２されてよい。例えば、関心オブジェクトが、駐車場に駐車された車両内で検出された未認識の顔であるとすると、同時に同じ駐車場に存在した他の車両のカメラであって、適切なタイミングにおいて、侵入された車両に向いていたカメラが特定８０２されてよい。必要に応じて、関連するカメラ機器が特定８０２されると、関心オブジェクトについてのクエリとともに画像探索クエリの要求が送信される８０３。この要求を受信するカメラ機器は、合致するものが存在するかを調べるために、自身がバッファしているビデオデータを提供される画像探索クエリを用いて探索することができる。一実施形態において、合致するものがあるか調べるために、関心オブジェクトについての特徴ベクトルが、ビデオデータで特定された潜在的な関連オブジェクトについての特徴ベクトルと比較される。例えば、関心オブジェクトが人間の顔であるとすると、顔特徴ベクトルがクエリとともに提供され、カメラ機器は、ビデオデータ内で顔を特定し、特定した顔についての特徴ベクトルを抽出し、所望の顔の顔特徴ベクトルと比較するために画像処理を用いることができる。必要に応じて、探索要求は、要求に応答して解析する必要のある、バッファされたビデオオブジェクトをさらに削減するために、関心タイムフレームを提供してもよい、

[0101] 一実施形態において、クラウドシステム１０３は、複数のユーザによる同じオブジェクトの選択を特定するため、ユーザオブジェクト選択を監視する。複数のユーザが同一オブジェクトを選択したと判定されると、同一または実質的に同一の画像クエリを生成し、システムは例えばニュースペイン４０１ｃを通じて同様の関心を有する他のユーザを通知してもよい。オブジェクトクエリは位置（例えば最大距離以内のユーザによって特定された同一オブジェクト）、時間、および／またはイベントタイプに基づいてさらに照合されてもよい。

[0102] 探索要求に対する応答が８０４で受信される。合致するものが見つからなければ８０５、共有要求処理は終了する８０６。例えば、探索要求がユーザによって行われたものであれば、ユーザは合致するビデオクリップが見つからなかったことの通知を受けるであろう。合致するビデオクリップが見つかった場合８０５、合致を応答したカメラ機器のユーザに承認要求が送信される８０７。図４ａ〜４ｃに関して上述したように、ユーザのカメラ機器から生成されたクリップは、クリップペイン４０１ａの下にリストされてよい。したがって、ユーザはクライアント機器１０１、補助カメラ１０６、モバイル機器１０４から生成されたクリップ７０５に、さらなる承認の必要なしにアクセスすることができる。例えば、一実施形態において、侵入などの同一イベントに合致するビデオクリップを有するカメラ機器が同一のユーザアカウントに登録されている場合、ユーザは、ダッシュボードに取り付けられたクライアント機器１０１と同じ侵入をキャプチャした家庭用補助カメラ１０６の１つ以上からの共有ビデオクリップに直接アクセスすることができる。したがって、例えば、ユーザは（インカメラ機器からの）犯人の顔、車庫に設置した補助家庭用カメラ機器からの「逃走」車両、およびドライブウェイ補助カメラ機器からの逃走車両のナンバープレートを見せる関連ビデオクリップを当局に提供可能であってよい。侵入イベントに関するビデオクリップは、本発明の一実施形態によるシステムによって統合される複数のカメラ機器から自動的に生成され、「関連」クリップとして関連づけられてよい。

[0103] 一実施形態において、許可要求は、ビデオクリップを他のユーザと共有することを許可するかどうかの決定においてユーザが見直すために動的に生成されたビデオクリップを含んでもよい。一実施形態において、共有要求は、サインオンの間に例えば隣人や特定のカメラなどについて記録された事前許可に基づいて、自動的に満たされてもよい。あるいは、許可要求は他のユーザによって満たされてもよい。例えば、合致するオブジェクトを有する関連ビデオオブジェクトを再生することをユーザに許可することを可能にする要求とともにプレイリストまたはマニフェストファイルが含まれてもよい。上述したように、ビデオオブジェクトは例えばインターネットを通じて、あるいはモバイル機器とカメラ機器との間の直接ネットワーク接続（例えばWi-Fi）を通じて、カメラ機器バッファから直接アクセスされてよいさらに、ビデオオブジェクトが暗号化されている場合、許可要求は、例えば生体ID（例えば顔認識、指紋など）のような必要な暗号鍵を取得するためにユーザID要求を含むことができる。適切な暗号鍵を用いてビデオオブジェクトの暗号化が解除され、共有の許可を得るためにユーザに対して再生される。さらに、一実施形態において、ユーザは共有ビデオクリップにおいて特定されたオブジェクトを不明瞭にするよう、必要に応じてシステムに要求することができる。例えば、人間の顔、ナンバープレート、住所番号、および／または、ユーザが選択した他の任意の身元を特定可能なオブジェクトは、ユーザの要求に応じて、プライバシーを保護するためにビデオデータで自動的にぼかされてよい。あるいは、システムは、システムユーザから解除が要求および／または許可されるまでは、身元が特定可能なオブジェクトをデフォルトで不明瞭にしてもよい。

[0104] 共有許可が得られない場合８０８、共有要求は例えば共有を要求するユーザに利用可能なクリップがないことを通知して終了する８０６。許可が得られた場合８０８、合致したビデオクリップのうち、許可が得られたすべてのビデオクリップが他のユーザと共有される８０９。例えば、一実施形態において、共有要求がユーザからのものである場合、要求したユーザは合致したビデオクリップの利用可能性について通知される。例えば、要求したユーザのモバイル機器１０４のモバイルアプリは、クラウドシステム１０３から通知を受信し、モバイルアプリのユーザインタフェースを通じてユーザに通知を提供する。共有要求がユーザのカメラ機器によって（例えば自動タグ付けイベントから）自動的に生成されたものである場合、ユーザのモバイル機器１０４のモバイルアプリは、ユーザに関連する他のビデオクリップの利用可能性の通知を受信する。そして、モバイルアプリは、利用可能なビデオクリップに関する情報をニュースペイン４０１ｃに表示することができる。必要に応じて、モバイルアプリは、利用可能なビデオクリップをクリップペイン４０１ａのイベント生成クリップに直接リンクしてもよい。暗号化されたビデオデータに関するいかなるビデオクリップも、許可処理を通じて暗号化が解除されるであろうから、非暗号化形式の共有ビデオクリップになっているであろう。

[0105] 一実施形態において、ビデオ共有要求処理は、関心イベントについてのビデオを記録する、分散されたカメラの仮想ネットワークを生成するために用いられる。例えば、ビデオクリップ生成処理は、動的に生成され、所与のイベントについて記録される追加クリップによって更新されるライブストリーミングプレイリストまたはマニフェストファイルを含んでもよい。この手法を用いることにより、システムは、例えば侵入、自動車事故などのような所与のイベントについて、様々なアングルからの視野、視点、および／または、より広い／狭い視野を提供するために動的に生成される仮想ネットワーク内のカメラでキャプチャされた、関連づけられたビデオクリップセットを生成することができる。例えば、一実施形態において、ナンバープレートを認識するのに１つのカメラからのビデオでは不十分な場合に、複数のカメラ機器によってキャプチャされたビデオからの散在する静止画を用いることができる。一実施形態において、ナンバープレートに加え、あるいはナンバープレートが認識できない場合に、車両の色、メーカーおよびモデルを、分類子ベースの画像認識技術に基づいて調べてもよい。図８のビデオ共有処理は、必要に応じて仮想ネットワークに対するカメラ機器の追加および除去を継続して実行する。例えば、イベントが自動車専用道路における自動車事故の場合、適切な向きの（すなわち、事故の方を向いた）車載クライアント機器１０１が、位置、時刻、および向きの合致（すなわち、事故に近く、事故の方を向いていること）や、合致しないこと（すなわち、事故現場を通過した後）に基づいて、仮想ネットワークにおいて動的に追加および除去される。

[0106] 本開示の別の見地によれば、システム内のカメラ機器によって生成されたビデオデータは、一意に特定可能であり、真正かつ修正されていないことが検証可能であってよい。図９を参照して、一実施形態にしたがってビデオデータの真正性を検証するための例示的な方法を説明する。本実施形態において、ビデオデータオブジェクトおよびビデオクリップの両方について真正性を確認することができる。代替実施形態では、本開示の教示から逸脱することなく、ビデオデータオブジェクトまたはビデオクリップのいずれかの真正性を単独で確認することができ、あるいは、必要に応じて一方または他方だけについて真正性を確認することができる。方法は真正性確認要求９００によって開始される。例えば、クラウドシステム１０３に関連づけられたカメラ機器によって生成されたビデオの真正性確認の要求は、例えばシステムウェブサイトへのウェブベースのインタフェース１０５を通じてクラウドサーバ１０２に提出されてよい。一実施形態において、要求とともにファイルが提供される。一実施形態において、要求がビデオクリップまたは、ビデオファイルのようなビデオデータオブジェクトに対するものであるかどうかの判定９０１が行われる。このステップは代替実施形態では省略されてもよい。判定は、例えば、提出されたファイルのタイプ（例えばプレイリストまたはマニフェストファイル、またはビデオデータファイル）に基づいて、ファイルに関連づけられたGUID（例えばビデオクリップについてのGUID や、ビデオデータオブジェクトについてのGUID）に基づいて、あるいは例えば要求で提供される明示的な入力のような他の条件に基づいて行われてよい。

[0107] 一実施形態において、要求がビデオクリップに関するものと判定９０１された場合、そのビデオクリップ内のビデオデータオブジェクトまたはファイルのリストを検索９０２するために、そのビデオクリップについてのプレイリストまたはマニフェストファイルがアクセスされる。最初のビデオデータオブジェクトが選択９０３される。一実施形態において、要求がビデオデータオブジェクトに関するものと判定９０１された場合、または要求がビデオクリップに関するものと判定されてビデオデータオブジェクトが選択９０３された場合、ビデオクリップに関連づけられたメタデータレコードが検索９０４される。例えば、一実施形態において、クラウドベースのシステム１０３に関連づけられたカメラ機器によってキャプチャされたビデオデータオブジェクトに関連づけられたメタデータレコードのリポジトリにアクセスするために、ビデオデータオブジェクトについてのGUIDが用いられる。上述したように、ぞれぞれのカメラ機器は、メタデータと、記録されているそれぞれのデータオブジェクトについてのビデオデータオブジェクトのハッシュとを含む、署名されたメッセージをシステムに送信する。一実施形態において、メタデータレコードは、メタデータと、ビデオデータのハッシュとを含み、関連づけられたGUID によって索引が付与されてよい。

[0108] そして、GUIDに対応するビデオデータオブジェクトの保存されたハッシュは、真正性確認が要求されたビデオデータオブジェクトの一方向性ハッシュと比較９０５される一実施形態において、真正性確認要求は、ビデオデータオブジェクトを含む。その実施形態において、ビデオデータオブジェクトは、システムのカメラ機器が用いるものと同じ一方向性ハッシュ関数を用いてハッシュされる。代替実施形態において、ビデオデータオブジェクトについてのネットワークアドレスが、ビデオクリップファイルで提供される。そのような実施形態において、ビデオデータオブジェクトは、例えばステップ９０３（またはその後のビデオデータオブジェクトについてはステップ９０９）で検索され、上述したようにハッシュされる。システムがビデオデータをメタデータと一緒にハッシュすることに基づいて実装される場合、（要求の一部でない場合）検索９０４されるメタデータは、検証されているビデオデータオブジェクトについてのハッシュ関数において用いられる。ハッシュ関数はサーバ１０２のようなサーバで適用されてもよいし、ウェブベースのクライアント１０５のようなクライアントで実行されてもよく、例えば要求とともに認証システムに提供される。

[0109] 一実施形態において、ハッシュ比較９０５の結果は、ビデオデータオブジェクトについての検証を出力９０６するために用いられる。検証出力は例えば、ビデオデータが真正なものかどうか、あるいは変更されているかどうかを表す肯定または否定結果を提供することができる。一実施形態において、検証出力は、時刻、位置、向きなどのような、ビデオデータオブジェクトに関連づけられた関連メタデータさらに含んでよい。一実施形態において、検証されたビデオデータオブジェクトがビデオクリップの一部でない場合９０７、検証処理は終了９０８する。

[0110] しかし、ビデオデータオブジェクトがビデオクリップの一部である場合９０７、処理はステップ９０９に継続する。ステップ９０９で、検証されたビデオデータオブジェクトがビデオクリップの最初のビデオデータオブジェクトであった場合９０９、次のビデオデータオブジェクトが選択９１０され、ビデオクリップの２番目のビデオデータオブジェクトの検証のために処理はステップ９０４から繰り返す。ビデオデータオブジェクトがビデオクリップの最初のビデオデータオブジェクトでなければ、時間解析９１１が次に実行される。一実施形態において、上述したように、ビデオデータオブジェクトについてのメタデータは、ビデオデータがいつキャプチャされたかを特定するための時刻情報を含んでいる。例えば、一実施形態において、ビデオデータオブジェクトの開始のタイムスタンプおよび、その終わりを示すための持続時間または終了スタンプを生成するために４Ｇ／ＬＴＥサービスプロバイダからの原子時が用いられる。一実施形態において、この時刻情報は、ビデオオブジェクト検証出力９０６とともに提供され、時間解析９１１に用いられる。例えば、ギャップがあるか否かを判定するために、ビデオクリップ内の１番目のビデオデータオブジェクトの終了時刻がそのビデオクリップ内の２番目のビデオデータオブジェクトの開始時刻と比較される。所与のビデオクリップの連続するビデオデータオブジェクトのタイムシーケンス内のギャップは、例えばそのビデオクリップへの編集を示しうる。

[0111] 一実施形態において、ビデオクリップに検証すべきさらなるビデオデータオブジェクトが存在する場合９１２、処理はステップ９１０に遷移し、時間解析ステップ９１１までをそれぞれのビデオデータオブジェクトについて繰り返す。ビデオクリップ内のすべてのビデオデータオブジェクトが検証される９１２と、ビデオクリップ検証出力が提供９１３される。例えば、クリップ内のすべてのビデオデータオブジェクトが肯定的に検証され、時間解析がギャップを特定しなければ、そのビデオクリップに対して肯定的な真正性確認が出力９１３されてよい。必要に応じて、出力は、例えばそのビデオクリップに関する（例えば時刻、継続時間、位置、使用されたカメラ機器、ユーザなどのような）追加情報を含んでもよい。逆に、例えばハッシュが合致しない場合や、ステップ９１１でビデオクリップタイムラインにギャップが見つかった場合のように、ビデオクリップのいずれかについて真正性が確認できない場合、否定的な結果が出力９１３される。出力は、例えば肯定的結果について提供される情報のいずれかに加えて、あるいはその代わりに、否定的結果に関する理由を含んでもよい。例えば、一実施形態において、クライアント機器１０１により自動車事故の検出に応答して生成された２秒間のビデオファイル１５個からなるビデオクリップは、上述した手法を用いてクラウドシステム１０３によって真正であると独自に検証されてもよい。

[0102] 本開示の別の見地によれば、クライアント機器１０１のようなカメラ機器を設定するための手順が提供される。図１０を参照して、一実施形態にしたがってシステム内の動作のためにカメラ機器を設定するための方法を説明する。一実施形態において、クライアント機器１０１のようなカメラ機器は、機器の電源が投入されると直ちに機能するセルラ接続機能を含んでいる。セルラ接続機能はカメラ機器とクラウドシステム１０３との間に、設定手順の間に用いることのできるデータ接続１０７／１０８を提供する。カメラ機器の電源が投入されると、設定手順が始まる１０００。以下のセットアップステップが順番に提供されるが、これらステップに特定の順序は必要ない。例えば、一実施形態において、ユーザ設定ステップ１００１が実行される。一実施形態において、ユーザ設定ステップ１００１は、カメラ機器がユーザを認識することを可能にする。例えば、一実施形態において、クライアント機器１０１は、ユーザの顔の様々なアングルを記録するために、カメラの１つに向きながら様々な向きでポーズをとるようにユーザに指示を与える。必要に応じて、例えば指紋、音声、および虹彩を含む、他のユーザバイオメトリクスを認識するために同様の手順が用いられてよい。例えば、ユーザの指紋の一連の画像を記録するためにタッチセンサが用いられてよい。音声認識ソフトウェアは、ユーザに予め定められたコマンド、ステートメント、またはセンテンスを１回以上繰り返させることによりトレーニングされてよい。一実施形態において、生体光学署名を得るため、ユーザの虹彩は複数の角度から記録される。他の実施形態はこれら生体IDの組み合わせを含んでよく、さらに別のものを含んでもよい。

[0113] ユーザの１つ以上の生体署名はカメラ機器に保存される。一実施形態において、ランダム入力に基づいて暗号鍵がさらに生成され、ユーザの生体IDと関連づけて保存される。必要に応じて、例えば可能性のある運転者が複数存在する車両に対してなど、複数のユーザが必要になる場合は、ユーザ設定手順１０１は各ユーザについて繰り返される。

[0114] 図１０に戻って、別の設定ステップは、カメラ機器と１つ以上のモバイル機器１０４との関連づけを伴う。モバイル機器１０４はそれ自体がカメラ機器でありうるため、ユーザ設定ステップ１００１のような、設定ステップの一部が適用されうることに留意されたい。モバイル機器１０４は、図４ａ〜４ｃに関して上述したように機器にインストールされたモバイルアプリを含んでいる。一実施形態において、モバイル機器１０４およびカメラ機器（例えばクライアント機器１０１）は、ブルートゥース（登録商標）送受信機のような短距離無線モジュールを含んでいる。本技術分野で既知であるように、短距離無線モジュールは、ピコネットの形成、さもなくば互いのペアリングにおいて機器のIDとして他の短距離無線モジュールによって受信可能な固有IDを送信することができる。例えば、ブルートゥース送受信機は、固有の１２桁の１６進アドレス（”BD ADDR”）を、身分証明およびペアリングのために提供することができる。

[0115] 一実施形態において、ユーザはカメラ機器にユーザのモバイル機器１０４とペアリングするように促してもよい。例えば、一実施形態において、ユーザは音声ペアリングコマンドを発したり、タッチスクリーンまたはカメラ機器において利用可能な他のユーザ入力デバイスを通じてペアリングコマンドを与えたりすることができる。一実施形態において、ペアリング手順はブルートゥースペアリング手順を伴う。別の実施形態において、カメラ機器はモバイル機器によってキャプチャされ、クラウドシステム１０３への接続を介してカメラ機器に送り返される固有パターンを表示する。例えば、カメラ機器は無作為に生成された英数字コード、QRコード（登録商標）、無作為な順序の一連の黒画面および白画面、または他の何らかのランダム出力を表示することができる。ランダム出力はモバイルアプリによってモバイル機器にキャプチャまたは入力され、セキュアなインターネット接続を通じて、例えばブルートゥースアドレス、MACアドレスなどのようなモバイル機器の固有識別子とともにクラウドシステム１０３へ送信される。ランダム出力とモバイル機器入力とが比較される、。両者が合致すれば、カメラ機器はモバイル機器固有識別子（例えばブルートゥースアドレスまたはMACアドレス）が真正であることを確認し、その時点から、モバイル機器固有識別子はモバイル機器に関連づけられる。代替実施形態において、クライアント機器の出力をモバイル機器によってキャプチャされた入力と比較する代わりに、両方の機器はサーバで比較される出力を生成する。例えば、各機器は設定手順の間にユーザの顔認識を実行するためにカメラを用い、それらの顔認識結果が、同一ユーザを合致させるための比較のためにサーバに送信される。

[0116] 一実施形態において、QRコードがクライアント機器１０１のディスプレイに表示される。QRコードは、クライアント機器１０１についての機器IDと、クライアント機器１０１との通信のための暗号鍵（または暗号鍵を生成するためのシード）とをエンコードする。モバイル機器１０４上のモバイルアプリは、機器IDおよび暗号鍵を取得するため、QRコードをキャプチャならびに解釈する。機器IDは例えば電話番号、電子メールアドレス、またはクライアント機器１０１を用いた電子メッセージングのための他の手段を含むことができる。暗号鍵を用いて、モバイル機器をクライアント機器に関連づけるために、モバイル機器１０４は以下でさらに詳細に説明するように暗号化通信をクライアント機器１０１へ送信することができる。これは例えば、クライアント機器１０１へモバイル機器１０４についての固有識別子（例えば電話番号、電子メールアドレス、ブルートゥースアドレス、MACアドレスなど）を送信することを含む。QRコードを表示する機器であるクライアント機器１０１に関して説明したが、同様の手法はQRコードを表示するモバイル機器１０４および、モバイル機器１０４に提供される暗号鍵を用いて暗号化メッセージングを開始するクライアント機器１０１に対しても適用することができる。

[0117] 例えばモバイルアプリが１つ以上のモバイル機器センサの出力を記録しながら、提供される指示と合致するようにユーザにモバイル機器を移動させる一連の指示を含む、他の「共有秘密鍵」手法をモバイル機器関連づけ１００２のために用いることができる。例えば、要求された動きと合致する加速度計および／またはジャイロスコープの変化をもたらす無作為な一連の動きでユーザは機器を持ち上げたり下げたり、機器を振ったりなどすることができる。センサが検出した一連の動きは、関連づけのためのカメラ機器命令との照合のためにインターネット接続を通じて提供されてよい。あるいは、一実施形態において、ユーザは登録手順の間に例えばモバイル機器アプリを通じてモバイル機器についての電話番号を提供してもよい。モバイル機器関連づけステップ１００２のために、カメラ機器は機器IDを画面に表示することができる。ユーザは機器IDをモバイルアプリに入力し、機器IDはクラウドシステム１０３へ送信される。クラウドシステムは機器IDを特定し、インターネット接続１０７／１０８を通じてカメラ機器１０１／１０６に、モバイル機器１０４についての電話番号を含んだメッセージを送信する。カメラ機器は、ランダムコードとともにテキストメッセージをモバイル機器１０４に送信する。ユーザは、クラウドシステム１０３またはカメラ機器１０１／１０６による検証のためにランダムコードをモバイルアプリを通じて入力する。ランダムコードがテキストに記載されたコードと合致すれば、モバイル機器が認証される。一旦カメラ機器およびモバイル機器が関連づけられると１００２、モバイル機器についての固有ID（例えばブルートゥースアドレス、MACアドレスなど）に基づいて、カメラ機器はその後のやりとりにおいてモバイル機器を信頼することができる。

[0118] 本開示の別の見地によれば、一実施形態において、設定手順はモバイル機器１０４にモバイルアプリを提供するステップを必要に応じて含む。図１１は、一実施形態に係る初期設定手順についての例示的なフローチャートである。上述したように、カメラ機器１０１／１０８は、設定不要でクラウドシステム１０３と通信するように構成された、インターネットへの無線セルラ接続を含む。カメラ機器が最初にオンされると、画面はQRコード１１０１を表示する。モバイル機器は、QRコードを自身のカメラでキャプチャしてコードを解読１１０２するために自身の既存のアプリの１つを用いることができる。この実施形態において、QRコードは例えばクラウドシステム１０３内のウェブサーバへのリンクまたはURLを提供する。リンクまたはURLは、本技術分野で既知のように、IPアドレスまたはドメイン（例えばwww.owi.us）およびそこにエンコードされたパラメータセットとを含むことができる。パラメータの１つは例えば、例えばモバイル機器番号、電話番号、シリアル番号などのような、設定中のカメラ機器１０１／１０８についての固有IDを含むことができる。必要に応じて、リンクパラメータは、設定手順が実行されるごとに異なる、無作為に生成された番号をさらに含むことができる。あるいは、QRコードを表示する代わりに、リンクおよびパラメータをテキスト／画像として画面に表示し、それらを音声信号にエンコードし、それらを短距離通信（IR、AirDrop、ブルートゥースなど）などを通じて送信することを含む、リンクおよびパラメータを代替形式で提供することにより、同じ手順を実行することができる。

[0119] QRコードを解釈すると、モバイル機器はリンクにエンコードされたパラメータを含むHTTPリクエストをリンクおよびURLで特定されるウェブサーバに送信１１０３するために自身の既存ソフトウェア（例えばウェブブラウザ）を用いる。クラウドシステム１０３はリクエストを受信し、リクエストについてのレコードであって、リンクにエンコードされたパラメータおよび、HTTP要求手順から得られた追加メタデータおよびネットワーク情報（モバイル機器１０４を一意に特定するための情報（例えばHTTPヘッダメタデータ、TCP/IPヘッダ情報など）を含む）を含むレコードを生成１１０４する。さらに、クラウドシステム１０３は、モバイル機器を、適切なモバイルアプリを取得しうる場所にリダイレクト１１０５する。例えば、例えばHTTPリクエストからの”User-Agent”データおよび／またはカメラ機器１０１／１０８についての固有IDを用いるクラウドシステム１０３は、モバイル機器１０４を、User-Agentがモバイル機器がiOS機器であることを示す場合にはアップルアップストアへ、モバイル機器がAndroidベースの機器であると判定される場合にはグーグルプレイストアあるいはネットワークを通じてモバイル機器にモバイルアプリを提供可能な他のサーバへ、リダイレクトする。同様に、クラウドシステム１０３はカメラ機器１０１／１０８の機器IDを用いて決定された適切なバージョンのモバイルアプリへのリダイレクションリンクにパラメータを含めることができる。

[0120] 一度リダイレクトされると、モバイル機器１０４は適切なモバイルアプリ（例えばカメラ機器１０１／１０８およびクラウドシステム１０３とのやりとりのためのアプリ）を取得１１０６する。モバイルアプリのモバイル機器へのダウンロードおよびインストールの後、モバイルアプリは実行されるとステップ１１０４で先に生成したレコードにアクセス１１１７するため、クラウドシステム１０３に連絡する。例えば、モバイルアプリは、同一のパラメータ、メタデータ、またはモバイル機器１０４から入手可能な他の情報を用いて、ステップ１１０３で行われるものと同様のHTTPリクエストを生成する際に、モバイル機器１０４についての固有IDを取得してもよい。一実施形態において、モバイル機器１０４の特定を迅速化するために、HTTPリクエストステップ１１０３とレコードアクセスステップ１１０７との間に時間制限（例えば２〜１５分）が用いられてもよい。クラウドシステム１０３は、その情報に基づいて同じモバイル機器１０４がシステムにアクセスしていることを判定し、以前生成したレコードと、設定手順を完了するために必要となり得る他の追加設定パラメータとを提供１１０８する。例えば、提供される場合、無作為に生成された番号が上述した機器関連づけ手順のための「共有秘密鍵」として提供されてよい。あるいは、カメラ機器についての暗号情報および／またはメッセージング情報が提供されうる。

[0121] 図１０に戻って、カメラ機器１１０／１０８とモバイルアプリ１０４との間の直接接続の設定を含む、本開示の別の態様が開示されている。一実施形態において、カメラ機器１０１／１０８は無線ローカルエリアネットワークへの接続性を含む。この実施形態において、例えばカメラクライアント１０１は必要に応じて、（Wi-Fiネットワークのような）ローカルエリアネットワークのためのアクセスポイント(AP)として動作しうる。モバイル機器１０４はWi-Fi局(STA)として、クライアント機器１０１への接続を確立１０９させることができる。特定の無線ローカルエリアネットワーク接続を説明したが、本発明は例えばピアツーピア接続（例えば”Wi-Fiダイレクト”、アドホックネットワークなど）のような、広範な無線接続モードに対して適用されうることが理解される。カメラ機器は、関連づけされたモバイル機器が、接続を行っているモバイル機器であるか否かを調べるために、モバイル機器関連づけ手順１００２を通じて認証されたMACアドレスを用いることができる。そして、設定、ビデオデータオブジェクト、ビデオクリップ、生体署名などを、機器間におけるセキュアな方法で送信するために、カメラ機器からモバイル機器への直接接続１０９を用いることができる。

[0122] 本技術分野に属する当業者は理解するであろうが、開示された実施形態には、添付した特許請求の範囲のみによって定義される本発明の範囲を逸脱することなく多様な変更を行うことができる。機能および要素を特定の組み合わせで説明したが、各機能および要素は他の機能および要素なしに単独で用いられてもよいし、他の機能および要素とともに、あるいはそれらなしに、様々な組み合わせで用いられてもよい。提供される方法またはフローチャートは、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読記憶媒体に有形的に具現化されたコンピュータプログラム、ソフトウェア、またはファームウェアに実装することができる。

[0123] コンピュータ可読記憶媒体の例には、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクのような磁気メディア、光磁気メディア、およびCD-ROMディスクのような光メディアが含まれる。

[0124] 適切なプロセッサの例には、汎用プロセッサ、特定用途プロセッサ、従来のプロセッサ、デジタルシグナルプロセッサ(DSP)、複数のプロセッサ、DSPコアに関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、他のタイプの集積回路(IC)、および／または状態機械が含まれる。

[0125] コンピュータベースのシステム内のソフトウェアとともに、１つ以上のプロセッサを、様々な実施形態に従ったビデオデータ収集、クラウドベースのデータ収集およびイベントベースのデータの解析、イベントベースのビデオクリップの生成、イベントベースのビデオの共有、イベントベースのビデオデータファイルの真正性の検証、およびクライアント機器の設定の方法、ならびに様々な実施形態に従って所与のビデオデータオブジェクトまたはファイルに関連するメタデータをキャプチャしたり、所与のイベントベースのビデオクリップに関連するメタデータをキャプチャしたりするためのデータモデルであって、これら全てがプロセッサの動作およびプロセッサとコンピュータベースのシステムの他の構成要素とのやりとりを改善する方法やデータモデルを実施するために用いることができる。様々な実施形態に係るカメラ機器は、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイク、テレビ受像機、ハンズフリーヘッドセット、キーボード、ブルートゥースモジュール、周波数変調(FM)ラジオユニット、液晶ディスプレイ(LCD)表示ユニット、有機発光ダイオード(OLED)表示ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク(WLAN)モジュールなど、ハードウェアおよび／またはソフトウェアで実施されるモジュールとともに用いられてもよい。

Claims (22)

1. ビデオデータキャプチャおよび共有のためのクラウドベースのシステムであって、
   複数のクライアント機器であって、
   各クライアント機器は１つ以上のビデオカメラと、１つ以上のセンサと、プロセッサと、メモリと、セルラ通信モジュールとを有し、
   前記クライアント機器はビデオデータをキャプチャするとともに、前記ビデオデータに関するメタデータであって、少なくともその一部に前記１つ以上のセンサから得られたデータを含んだメタデータを生成するように構成されている、複数のクライアント機器と、
   前記複数のクライアント機器と通信するクラウドベースのシステムであって、
   前記クラウドベースのシステムは、前記複数のクライアント機器からメタデータを受信するように構成されるとともに、
   第１のクライアント機器から前記複数のクライアント機器の１つ以上の他のクライアント機器によってキャプチャされたビデオデータを共有することの要求を受信するようにさらに構成され、
   前記複数のクライアント機器からの前記メタデータを前記要求と照合し、
   前記照合によって特定された前記複数のクライアント機器のサブセットに、前記要求に指定された関心オブジェクトについての画像探索クエリを送信し、
   前記サブセットの１つ以上のクライアント機器から、該１つ以上のクライアント機器によってキャプチャされたビデオデータに前記関心オブジェクトが見つかったことを示す肯定マッチ応答を受信する
   ことによって前記１つ以上の他のクライアント機器を特定するようにさらに構成される、クラウドベースのシステムと、を有する、システム。
2. 請求項１に記載のシステムであって、前記クラウドベースのシステムは、プリセットされた量のビデオデータのキャプチャに応じて、プリセットされた時間量のビデオデータのキャプチャに応じて、あるいは要求に応じて、前記複数のクライアント機器のそれぞれから周期的にメタデータを受信するように構成される、システム。
3. 請求項２に記載のシステムであって、ビデオデータの前記プリセットされた量が１から３０秒の間である、システム。
4. 請求項１に記載のシステムであって、前記ビデオデータに関する前記メタデータが位置情報を含む、システム。
5. 請求項１に記載のシステムであって、前記ビデオデータに関する前記メタデータが向き情報を含む、システム。
6. 請求項１に記載のシステムであって、前記１つ以上のセンサは、位置センサ、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ、歩数センサ、または歩き検出センサの１つ以上を含む、システム。
7. 請求項１に記載のシステムであって、第１のクライアント機器が移動車両に設置されたダッシュボード設置型カメラ機器であり、第２のクライアント機器が固定構造物に設置された固定カメラ機器である、システム。
8. 請求項１に記載のシステムであって、前記１つ以上のクライアント機器の第１のクライアント機器からビデオデータを受信するために、前記第１のクライアント機器とデータ通信を確立するように構成されたモバイル機器をさらに有する、システム。
9. 複数のカメラからのビデオを共有する方法であって、
   ビデオデータを共有する要求を受信することであって、前記要求は、要求される前記ビデオデータに関するメタデータと、関心オブジェクトを特定する画像クエリとを有する、受信することと、
   複数のカメラ機器からビデオデータに関するメタデータを取得することと、
   前記カメラ機器から取得された前記メタデータおよび前記要求に指定された前記メタデータに基づいて、カメラ機器のサブセットを特定することと、
   カメラ機器の前記サブセットに画像クエリを送信することと、
   カメラ機器の前記サブセットの１つ以上のカメラ機器から、該１つ以上のカメラ機器がキャプチャしたビデオデータにおける前記関心オブジェクトについての肯定的マッチを示す応答を受信することと、
   前記肯定的にマッチするビデオデータを共有するための許可を取得することと、
   前記肯定的にマッチするビデオデータを１以上のユーザと共有することと、を有する方法。
10. 請求項９に記載の方法であって、前記肯定的にマッチするビデオデータを１以上のユーザと共有することは、前記肯定的にマッチするビデオデータの少なくとも一部の位置を特定するプレイリストまたはマニフェストファイルを前記１以上のユーザに送信することを有する、方法。
11. 請求項９に記載の方法であって、前記要求は位置情報を含んだメタデータを有する、方法。
12. 請求項９に記載の方法であって、前記要求は向き情報を含んだメタデータを有する、方法。
13. 請求項９に記載の方法であって、ビデオデータに関する前記メタデータは、少なくとも部分的に、位置センサ、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ、歩数センサ、または歩き検出センサの１つ以上から取得される、方法。
14. 請求項９に記載の方法であって、１つ以上のセンサからの入力から判定されるイベントについて自動生成されたビデオクリップに関するメタデータを受信することをさらに有し、前記要求されるビデオデータは同一のイベントに関連する、方法。
15. 請求項９に記載の方法であって、前記要求を受信することが、サーバシステムで稼働するコンピュータソフトウェアモジュールからコンピュータプログラムコールを受信することを含む、方法。
16. 複数のカメラからのビデオを共有するためのシステムであって、命令を含んだコンピュータ可読媒体を有し、前記命令は、１つ以上のプロセッサで実行されると、該１つ以上のプロセッサに、
    ビデオデータを共有する要求を受信し、ここで前記要求は、要求される前記ビデオデータに関するメタデータと、関心オブジェクトを特定する画像クエリとを有し、
    複数のカメラ機器からビデオデータに関するメタデータを取得し、
    前記カメラ機器から取得された前記メタデータおよび前記要求に指定された前記メタデータに基づいて、カメラ機器のサブセットを特定し、
    カメラ機器の前記サブセットに画像クエリを送信し、
    カメラ機器の前記サブセットの１つ以上のカメラ機器から、該１つ以上のカメラ機器がキャプチャしたビデオデータにおける前記関心オブジェクトについての肯定的マッチを示す応答を受信し、
    前記肯定的にマッチするビデオデータを共有するための許可を取得し、
    前記肯定的にマッチするビデオデータを１以上のユーザと共有する、ようにさせる、システム。
17. 請求項１６に記載のシステムであって、前記肯定的にマッチするビデオデータを１以上のユーザと共有することは、前記肯定的にマッチするビデオデータの少なくとも一部の位置を特定するプレイリストまたはマニフェストファイルを前記１以上のユーザに送信することを有する、システム。
18. 請求項１６に記載のシステムであって、前記要求は位置情報を含んだメタデータを有する、システム。
19. 請求項１６に記載のシステムであって、前記要求は向き情報を含んだメタデータを有する、システム。
20. 請求項１６に記載のシステムであって、ビデオデータに関する前記メタデータは、少なくとも部分的に、位置センサ、加速度計、ジャイロスコープ、磁力計、光センサ、重力センサ、地磁気フィールドセンサ、線形加速度センサ、回転ベクトルセンサ、動き検出センサ、歩数センサ、または歩き検出センサの１つ以上から取得される、システム。
21. 請求項１６に記載のシステムであって、前記命令は前記１つ以上のプロセッサで実施されると、前記１つ以上のプロセッサに、さらに、１つ以上のセンサからの入力から判定されるイベントについて自動生成されたビデオクリップに関するメタデータを受信するようにさせ、前記要求されるビデオデータは同一のイベントに関連する、システム。
22. 請求項１６に記載のシステムであって、前記要求を受信することは、前記１つ以上のプロセッサで稼働するコンピュータソフトウェアモジュールからのコンピュータプログラムコールを受信することを含む、システム。

Images