JPWO2015141251A1 - 情報処理装置、情報処理方法および記録媒体 - Google Patents

Abstract

【課題】センサ情報に基づいて定義されユーザのアクションに対応するイベントの種類をより正確に特定する。【解決手段】対象のアクションに起因して発生するセンシングデータを取得するデータ取得部と、上記センシングデータに現れるパターン、および上記アクションのコンテキストに基づいて上記アクションに対応するイベントを特定するイベント特定部とを備える情報処理装置が提供される。また、対象のアクションをセンシングすることと、上記センシングによって取得されたセンシングデータを送信することと、上記センシングデータを受信する情報処理装置のプロセッサが、上記センシングデータに現れるパターン、および上記アクションのコンテキストに基づいて上記アクションに対応するイベントを特定する処理を実行することとを含む情報処理方法が提供される。【選択図】図３

Description

本開示は、情報処理装置、情報処理方法および記録媒体に関する。

これまでに、センシングや解析を利用して、スポーツのプレーを支援する技術が多く開発されてきている。例えば、特許文献１には、ユーザによるスポーツのプレーの状態をより的確に把握するために、スポーツをプレーするユーザの挙動を示すセンサ情報を取得し、センサ情報に基づいてスポーツにおけるプレーイベントの発生を検出し、プレーイベントに対応するプレーイベント情報を生成する技術が記載されている。例えば、プレーイベント情報に基づいてユーザに向けた通知情報を生成したり、スポーツのプレー画像の撮像を制御したり、プレー画像に付加情報を設定したりすることによって、ユーザによるスポーツのプレーを効果的に支援することができる。

特開２０１３−１８８４２６号公報

例えば特許文献１に記載された技術のように、スポーツにおけるプレーイベントに対応する情報を生成し、またこの情報をプレーの支援のために利用するような場合、プレーイベントの種類を特定することは重要である。例えば、ユーザがテニスをプレーしているときに、ラケットなどに装着されたセンサから得られるセンサ情報に基づいてプレーイベントの発生が検出された場合、そのイベントがラケットのスイングか否か、スイングである場合サーブなのか、ストロークなのか、スマッシュなのかを特定することは、ユーザにとって有用な通知情報を生成したり、プレー画像の撮像を適切に制御したりするために重要である。

この点について、特許文献１では、検出されたプレーイベントの種類を、機械学習やパターン認識などを用いたセンサ情報の解析によって特定することが記載されている。このような手法によって特定可能なプレーイベントも多くあるが、例えばセンサ情報にはあまり差が現れないが異なる種類であるプレーイベントや、逆にセンサ情報には差があるものの同じ種類であるプレーイベントなどが存在する場合、特許文献１に記載された手法だけではプレーイベントを正確に特定することが困難である。なお、同様の現象は、スポーツにおけるプレーイベントだけではなく、センサ情報に基づいて定義され、ユーザのアクションに対応するイベント一般についても発生しうる。

そこで、本開示では、センサ情報に基づいて定義されユーザのアクションに対応するイベントの種類をより正確に特定することが可能な、新規かつ改良された情報処理装置、情報処理方法および記録媒体を提案する。

本開示によれば、対象のアクションに起因して発生するセンシングデータを取得するデータ取得部と、上記センシングデータに現れるパターン、および上記アクションのコンテキストに基づいて上記アクションに対応するイベントを特定するイベント特定部とを備える情報処理装置が提供される。

また、本開示によれば、対象のアクションに起因して発生するセンシングデータを取得するデータ取得機能と、上記センシングデータに現れるパターン、および上記アクションのコンテキストに基づいて上記アクションに対応するイベントを特定するイベント特定機能とを情報処理装置のプロセッサに実現させるためのプログラムが記録された記録媒体が提供される。

また、本開示によれば、対象のアクションをセンシングすることと、上記センシングによって取得されたセンシングデータを送信することと、上記センシングデータを受信する情報処理装置のプロセッサが、上記センシングデータに現れるパターン、および上記アクションのコンテキストに基づいて上記アクションに対応するイベントを特定する処理を実行することとを含む情報処理方法が提供される。

以上説明したように本開示によれば、センサ情報に基づいて定義されユーザのアクションに対応するイベントの種類をより正確に特定することができる。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の第１の実施形態に係るシステム構成の例を示す図である。 本開示の第１の実施形態に係るシステムの装置構成を概略的に示すブロック図である。 本開示の第１の実施形態における解析処理のための機能構成を示すブロック図である。 本実施形態において定義されるプレーイベントの例を示す図である。 本実施形態において定義されるテニスのプレーに関する状態の例を示す図である。 本開示の第１の実施形態において状態関連情報によらずに特定されるプレーイベントの例を示す図である。 本開示の第１の実施形態において状態関連情報を用いて特定されるプレーイベントの例を示す図である。 本開示の第１の実施形態におけるモーションデータのパターンとプレーイベントと状態との関係の例を示す図である。 本開示の第１の実施形態の変形例を示す図である。 本開示の第２の実施形態における解析処理のための機能構成を示すブロック図である。 本実施形態におけるイベント履歴を参照したプレーイベント特定の処理の例を示すフローチャートである。 本開示の実施形態に係るセンサ装置のハードウェア構成の例を示す図である。 本開示の実施形態に係る情報処理装置のハードウェア構成の例を示す図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．第１の実施形態
１−１．システム構成
１−２．解析処理のための機能構成
１−３．解析処理の具体的な例
１−４．変形例
２．第２の実施形態
３．ハードウェア構成
４．補足

（１．第１の実施形態）
（１−１．システム構成）
図１は、本開示の第１の実施形態に係るシステム構成の例を示す図である。図１を参照すると、システム１０は、センサ装置１００と、スマートフォン２００と、サーバ３００とを含む。

センサ装置１００は、テニスのラケットＲに装着される。センサ装置１００は、例えばモーションセンサを備える。モーションセンサは、例えば加速度センサ、ジャイロセンサ、および地磁気センサなどを含むのに加えて、振動センサを含んでもよい。また、センサ装置１００は、気温や湿度、明るさ、位置など、スポーツをプレーするユーザの環境情報を取得するためのセンサをさらに備えてもよい。センサ装置１００が備える各種のセンサによって検出されたデータは、必要に応じて前処理された上で、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの無線通信によってスマートフォン２００に送信される。

図示された例において、センサ装置１００が直接的に検出するのはラケットＲのモーションであるが、ラケットＲはユーザによって把持され、ユーザの意思に従って運動するため、センサ装置１００はラケットＲのモーションを介して間接的にユーザのモーションを検出しているともいえる。本明細書では、このような場合、センサ装置１００はユーザに間接的に装着されてユーザのモーションを検出しているという。

なお、他の実施形態において、センサ装置１００は、例えばユーザの衣服や靴などに装着されてもよい。この場合も、センサ装置１００が直接的に検出するのは衣服や靴のモーションであるが、衣服や靴はユーザとともに運動するため、センサ装置は間接的にユーザのモーションを検出しているといえる。あるいは、センサ装置１００は、例えばバンドで腕に巻き付けられるなどして、ユーザに直接的に装着されていてもよい。この場合、センサ装置１００は直接的にユーザのモーションを検出しうる。センサ装置１００がユーザのモーションを直接的に検出する場合だけでなく、間接的に検出する場合であっても、検出されるモーションにユーザのモーションが反映されていれば、センサ装置１００が提供する検出結果に基づいて、スポーツをプレーするユーザのモーションに対応するプレーイベントを定義することが可能である。

スマートフォン２００は、例えばスポーツをプレーしているユーザの近傍に配置される。この場合、スマートフォン２００は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信によってセンサ装置１００から送信されたデータを受信し、必要に応じて一時的に蓄積したり処理したりした上で、ネットワーク通信によってデータをサーバ３００に送信する。また、スマートフォン２００は、送信されたデータに基づいてサーバ３００が実行した解析の結果を受信し、ディスプレイやスピーカなどを介してユーザに向けて出力してもよい。なお、解析結果の出力時において、ユーザはスポーツをプレーしていなくてもよい。また、解析結果の出力は、スマートフォン２００とは別の、ユーザによって使用される情報処理端末、例えば各種のパーソナルコンピュータやタブレット端末、ゲーム機、テレビなどによって実行されてもよい。
また、スマートフォン２００は、必ずしも、スポーツをプレーしているユーザの近傍に配置されていなくてもよい。この場合、センサ装置１００は、検出されたデータを内部の記憶領域（メモリまたは外部記憶装置）に蓄積しておく。例えば、スポーツのプレー後、センサ装置１００とスマートフォン２００とが接近したときに、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信によって、データがセンサ装置１００からスマートフォン２００に送信されてもよい。あるいは、スポーツのプレー後、センサ装置１００とスマートフォン２００とがＵＳＢなどで有線接続されたときにデータが送信されてもよい。また、センサ装置１００からスマートフォン２００へのデータの受け渡しには、リムーバブル記録媒体が用いられてもよい。

サーバ３００は、スマートフォン２００とネットワークを介して通信し、センサ装置１００が備える各種のセンサによって検出されたデータを受信する。サーバ３００は、受信されたデータを用いた解析処理を実行し、スポーツのプレーに関するさまざまな情報を生成する。例えば、サーバ３００は、モーションセンサによって取得された、スポーツをプレーするユーザのモーションを直接的または間接的に示すデータに基づいて、プレーイベントを定義する。プレーイベントは、例えばラケットＲを用いた１回のショットに対応する。プレーイベントを定義することによって、例えば、モーションデータによって表されるユーザのプレーを、｛サーブ、ストローク、ボレー、…｝といったような意味をもったプレーの連なりとして把握することができる。

さらに、サーバ３００は、プレーイベントの解析処理によって、プレーイベントが分類される時系列のセグメントや、プレーイベントの時間的な配列から推定されるユーザのプレーパターンなどを特定してもよい。サーバ３００の解析処理によって生成された情報は、例えばスマートフォン２００に送信され、スマートフォン２００のディスプレイやスピーカを介してユーザに向けて出力される。あるいは、サーバ３００は、スマートフォン２００以外の情報処理端末に情報を送信し、ユーザに向けて出力させてもよい。また、サーバ３００は、複数のユーザについてそれぞれ受信されたデータに基づいて解析処理を実行し、各ユーザについて生成されたプレーパターンなどを比較した結果に基づく情報を生成し、各ユーザの情報処理端末に送信してもよい。

図２は、本開示の第１の実施形態に係るシステムの装置構成を概略的に示すブロック図である。図２を参照すると、センサ装置１００は、センサ１１０と、処理部１２０と、送信部１３０とを含む。スマートフォン２００は、受信部２１０と、処理部２２０と、記憶部２３０と、送信部２４０と、撮像部２５０と、入力部２６０と、出力部２７０とを含む。サーバ３００は、受信部３１０と、処理部３２０と、記憶部３３０と、送信部３４０とを含む。なお、それぞれの装置を実現するためのハードウェア構成例（センサ装置および情報処理装置のハードウェア構成例）については後述する。

センサ装置１００では、センサ１１０が取得したデータを処理部１２０が処理し、処理されたデータを送信部１３０がスマートフォン２００に送信する。センサ１１０は、上述の通り、例えばモーションセンサを含み、スポーツをプレーするユーザのモーションを直接的または間接的に検出する。また、センサ１１０は、気温や湿度、明るさ、位置など、ユーザの環境情報を取得するための他のセンサをさらに含んでもよい。処理部１２０は、プログラムに従って動作するプロセッサによって実現され、センサ１１０によって取得されたデータを必要に応じて前処理する。前処理は、例えばサンプリングやノイズ除去などを含みうる。なお、前処理は必ずしも実行されなくてもよい。送信部１３０は、通信装置によって実現され、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの無線通信を利用してデータをスマートフォン２００に送信する。また、図２には示していないが、センサ装置１００は、データを一時的に蓄積するための記憶部や、情報を出力するための出力部を備えてもよい。

スマートフォン２００では、受信部２１０がセンサ装置１００によって送信されたデータを受信し、送信部２４０がデータをサーバ３００に送信する。受信部２１０および送信部２４０は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの無線通信、および有線または無線のネットワーク通信を実行する通信装置によって実現される。受信されたデータは、例えば処理部２２０によって記憶部２３０に一時的に格納されてから送信される。また、受信されたデータについて、処理部２２０が前処理を実行してもよい。処理部２２０はプログラムに従って動作するプロセッサによって実現され、記憶部２３０はメモリまたはストレージによって実現される。受信部２１０は、さらに、サーバ３００から送信された情報を受信してもよい。受信された情報は、例えば処理部２２０の制御に従って出力部２７０からユーザに向けて出力される。出力部２７０は、例えばディスプレイやスピーカを含む。

さらに、スマートフォン２００では、撮像部２５０によって画像が取得される。撮像部２５０は、例えば撮像素子にレンズなどの光学系を組み合わせたカメラモジュールによって実現される。画像は、スポーツをプレーするユーザを被写体として含んでもよい。撮像部２５０によって取得された画像は、例えば受信部２１０によって受信されたデータとともに送信部２４０からサーバ３００に送信される。画像は、サーバ３００において、例えばセンサ装置１００によって取得されたデータとともに解析処理に用いられてもよいし、解析処理によって生成された情報に組み込まれてもよい。入力部２６０は、例えばタッチパネルやハードウェアボタン、および／または音声入力やジェスチャ入力を受け付けるためのマイクロフォンやカメラを含む。処理部２２０は、入力部２６０を介して取得されたユーザ操作に従って、送信部２４０を介してサーバ３００に情報をリクエストしてもよい。

サーバ３００は、受信部３１０と、処理部３２０と、記憶部３３０と、送信部３４０とを備える。受信部３１０は、通信装置によって実現され、スマートフォン２００からインターネットなどのネットワーク通信を利用して送信されたデータを受信する。処理部３２０は、例えばＣＰＵなどのプロセッサによって実現され、受信されたデータを処理する。例えば、処理部３２０は、受信されたデータの処理の解析処理を実行し、解析後のデータをさらに記憶部３３０に蓄積したり、送信部３４０を介して出力したりしてもよい。あるいは、処理部３２０は、スマートフォン２００などにおいて既に解析されたデータの蓄積および出力の制御を実行するだけであってもよい。

以上、本開示の第１の実施形態に係るシステムの構成について説明した。なお、上記で説明された構成は一例であり、他の実施形態ではさまざまな変形が可能である。例えば、上記の例では、センサ装置１００によって取得されたデータを用いた解析処理がサーバ３００の処理部３２０で実行されたが、解析処理はスマートフォン２００の処理部２２０で実行されてもよいし、センサ装置１００の処理部１２０で実行されてもよい。あるいは、解析処理は、処理部１２０，２２０，３２０のうちの一部または全部に分散して実行されてもよい。

また、システム１０は、センサ装置１００と、スマートフォン２００と、サーバ３００とを含むものとして説明されているが、例えばスマートフォン２００の処理部２２０で解析処理が実行される場合には、システム１０にサーバ３００が含まれなくてもよい。つまり、本実施形態に係る処理は、センサ装置１００とスマートフォン２００というクライアント端末の間で完結してもよい。あるいは、この場合に、サーバ３００は、スマートフォン２００で実施された解析処理の結果がアップロードされたものを保存したり、結果をユーザ間で共有したりする機能を提供してもよい。

また、例えばセンサ装置１００の処理部１２０で解析処理が実行される場合には、システム１０にスマートフォン２００およびサーバ３００が含まれなくてもよい。つまり、本実施形態に係る処理は、センサ装置１００という単一の端末装置の中で完結してもよい。あるいは、この場合に、スマートフォン２００またはサーバ３００は、センサ装置１００で実施された解析処理の結果がアップロードされたものを保存したり、結果をユーザ間で共有したりする機能を提供してもよい。センサ装置１００は、例えばユーザまたは用具に装着される専用のセンサ装置であってもよいし、携帯可能な情報処理端末に搭載されたセンサモジュールがセンサ装置１００として機能してもよい。このような場合、センサ装置１００は、サーバ３００と直接的にデータをやりとりしてもよい。

（１−２．解析処理のための機能構成）
図３は、本開示の第１の実施形態における解析処理のための機能構成を示すブロック図である。図３を参照すると、機能構成４００は、入力インターフェース４０１と、モーションデータ取得部４０３と、パターン検出部４０５と、イベント特定部４０９と、出力インターフェース４１３と、状態管理部４１５と、他センサデータ取得部４１７とを含む。機能構成４００のうち、入力インターフェース４０１および出力インターフェース４１３を除いた処理部、すなわちモーションデータ取得部４０３、パターン検出部４０５、イベント特定部４０９、状態管理部４１５、および他センサデータ取得部４１７は、センサ装置１００の処理部１２０、スマートフォン２００の処理部２２０、および／またはサーバ３００の処理部３２０によって実現される。以下、それぞれの機能構成についてさらに説明する。

入力インターフェース４０１は、解析処理に用いられる各種データの入力を受け付ける。例えば、解析処理がセンサ装置１００の処理部１２０で実行される場合、入力インターフェース４０１は、処理部１２０がセンサ１１０から測定値などのデータを受け取るための内部的なインターフェースでありうる。また、例えば、解析処理がスマートフォン２００の処理部２２０、またはサーバ３００の処理部３２０で実行される場合、入力インターフェース４０１は、外部装置であるセンサ装置１００またはスマートフォン２００から送信されるデータを受信するための通信インターフェースでありうる。

モーションデータ取得部４０３は、入力インターフェース４０１を介して、モーションセンサによって提供されたモーションデータを取得する。本実施形態では、センサ装置１００のセンサ１１０にモーションセンサが含まれる。モーションセンサは、例えば、３軸加速度センサや、６軸センサ（３軸加速度センサおよび３軸ジャイロセンサ）、９軸センサ（３軸加速度センサ、３軸ジャイロセンサ、および３軸地磁気センサ）を含む。さらに、モーションセンサは、振動センサを含んでもよい。上述のように、これらのセンサによって提供されるモーションデータは、ユーザによるスポーツのプレーに起因して発生する。モーションデータ取得部４０３は、モーションデータに含まれる測定値、または測定値が前処理されたデータを取得し、パターン検出部４０５に提供する。

パターン検出部４０５は、モーションパターン４０７を参照して、モーションデータ取得部４０３によって取得されたモーションデータに現れるパターンを検出する。モーションパターン４０７は、例えば、機械学習やパターン認識などの手法を用いて、モーションデータに現れる特徴を分類したパターンであり、予め解析処理を実行する装置の記憶部に格納されている。あるいは、モーションパターンは、解析処理を実行する装置とは異なる装置の記憶部に格納されており、パターン検出部４０５はネットワークを介してモーションパターン４０７を参照してもよい。パターン検出部４０５は、例えば、モーションデータに含まれる振動センサの波形に基づいて解析区間を設定し、解析区間における加速度や角速度などの波形をモーションパターン４０７として与えられる波形と比較することによって、モーションデータに現れるパターンを検出してもよい。

イベント特定部４０９は、パターン検出部４０５によって検出されたモーションデータのパターンに基づいて、ユーザのプレーに対応するプレーイベントを特定する。例えば、テニスの場合であれば、ユーザの一連のプレーの中で、ラケットのスイングが発生した場合に、モーションデータには特徴的なパターンが発生しうる。イベント特定部４０９は、パターン検出部４０５が検出した上記のパターンに基づいて、発生したスイングが何のプレーイベントであったかを特定する。

ここで、本実施形態において、プレーイベントは、スポーツのルールやセオリー、慣習などに従って規定される。例えば、テニスの場合、サーブによってラリーが開始され、サーブミスがあった場合には２回までサーブが可能であるというルールがある。また、ラリー中のテニスのショットも、例えばフォアハンドショット、バックハンドショット、ストローク、スライスボレー、スマッシュなどといった観点で分類される。イベント特定部４０９は、このようなルールやセオリー、慣習などに従って、例えば以下の図４に示す例のようなプレーイベントを特定する。

図４は、本実施形態において定義されるプレーイベントの例を示す図である。図示された例では、スイングが発生した場合に検出される８つのパターン（スイング−１〜スイング−８）について、対応するプレーイベントが示されている。例えば、パターン「スイング−１」は、プレーイベント「フォアハンドストローク」に対応付けられている。同様に、パターン「スイング−２」〜「スイング−７」も、それぞれ単一のプレーイベントに対応付けられている。これらのプレーイベントは、モーションデータに現れるパターンが固有であるために、パターンに基づいてプレーイベントを特定することができる。

一方、図示された例において、パターン「スイング−８」はオーバーハンドショットのパターンであるが、このパターンには「スマッシュ」および「サーブ」の２つのプレーイベントが対応付けられている。つまり、「スマッシュ」および「サーブ」のプレーイベントでは、モーションデータに現れるパターンが類似しており、パターンだけではプレーイベントを特定することが困難である。しかしながら、上述したように、「サーブ」のプレーイベントは、テニスのルール上他のショットとは明確に区別されるイベントであるために、「サーブ」のプレーイベントを特定することは、ユーザに有用な情報を提供するために重要である。

そこで、本実施形態において、イベント特定部４０９は、パターン検出部４０５によって検出されたモーションデータのパターンに基づいてプレーイベントを特定するにあたり、さらに、状態関連情報４１１を参照し、適切なプレーイベントを選択する。状態関連情報４１１は、ユーザによるスポーツのプレーの状態を示す情報である。本実施形態では、状態関連情報４１１が、解析処理を実行する装置の記憶部に格納されている。あるいは、状態関連情報４１１は、解析処理を実行する装置とは異なる装置の記憶部に格納されており、イベント特定部４０９はネットワークを介して状態関連情報４１１を参照してもよい。なお、状態関連情報４１１の詳細については、状態管理部４１５の機能とあわせて後述する。

なお、図４に示された例において、パターン「ＮＳ−１」〜「ＮＳ−７」は、スイング以外のユーザのアクションが発生した場合に検出される。これらのパターンは、一括してプレーイベント「ＮＯＴ ＳＷＩＮＧ」に対応付けられている。以下で説明する例では、プレーイベント「ＮＯＴ ＳＷＩＮＧ」はスイング以外のユーザのアクションが発生したこと以上の意味を持たないが、他の例では、パターン「ＮＳ−１」〜「ＮＳ−７」に対応する個別のプレーイベント、例えばボールを受けるときにラケットに当てて止める動作、ラケットを手で叩く動作、ラケットを落とした場合の動作などが特定されてもよい。

再び図３を参照して、イベント特定部４０９は、上記のような処理によって特定されたプレーイベントを示す情報を、出力インターフェース４１３を介して出力する。出力された情報は、例えばユーザにリアルタイムで提供される通知の生成に利用されたり、共有のためにアップロードされたり、さらなる解析処理の入力として利用されたりしてもよい。また、イベント特定部４０９は、プレーイベントを示す情報を、状態管理部４１５に提供してもよい。この場合、状態管理部４１５は、後述するように、発生したプレーイベントに応じて状態関連情報４１５を更新する。

出力インターフェース４１３は、イベント特定部４０９によって特定されたプレーイベントを示す情報を出力する。例えば、解析処理がセンサ装置１００の処理部１２０やスマートフォン２００の処理部２２０で実行される場合、出力インターフェース４１３は、プレーイベントに関連する情報をディスプレイやスピーカなどを介して出力するための内部的なインターフェースでありうる。また、例えば、出力インターフェース４１３は、解析結果を外部装置に送信するための通信インターフェース（例えば送信部１３０、送信部２４０、または送信部３４０）であってもよい。

状態管理部４１５は、状態関連情報４１１を管理する。本実施形態において、状態関連情報４１１は、ユーザによるスポーツのプレーの状態を示す情報であり、イベント特定部４０９がプレーイベントを特定するために参照される。状態管理部４１５は、イベント特定部４０９から提供された情報に基づいて状態関連情報４１５を更新する。また、状態管理部４１５は、他センサデータ取得部４１７から提供される情報に基づいて状態関連情報４１５を更新してもよい。

図５は、本実施形態において定義されるテニスのプレーに関する状態の例を示す図である。図示された例では、モーションデータ取得部４０３が取得するモーションデータなどに基づいて、１ｓｔサーブの待機状態Ｗ１、２ｎｄサーブの待機状態Ｗ２、およびラリー状態Ｒが定義されている。状態間の遷移は、状態Ｗ１と状態Ｒとの間（Ｔ_Ｗ１Ｒ，Ｔ_ＲＷ１）、状態Ｗ２と状態Ｒとの間（Ｔ_Ｗ２Ｒ，Ｔ_ＲＷ２）、および各状態の自己遷移（Ｔ_Ｗ１Ｗ１，Ｔ_Ｗ２Ｗ２，Ｔ_ＲＲ）について定義されている。これらの遷移には、例えばモーションデータに基づいてプレーイベントを特定するイベント特定部４０９から提供されるプレーイベントの情報や、他センサデータ取得部４１７から提供される情報などに基づく条件が対応付けられる。条件の例を、以下の表１に示す。

なお、表１の例では、遷移Ｔ_ＲＷ２に「サーブミスが検出された」という条件が対応付けられているが、サーブミスは、イベント特定部４０９から提供される情報によっては必ずしも検出されない。サーブミスは、例えば、他センサデータ取得部４１７が取得する、ボールがコート外に出たか否かを示す情報、またはユーザがマニュアル入力した情報などに基づいて検出されてもよい。

上記の表１の例にも示されるように、状態管理部４１５は、イベント特定部４０９や他センサデータ取得部４１７によって提供される、イベントの発生やセンサデータの変化を示す情報に基づいて状態関連情報４１１を更新する。また、状態管理部４１５は、イベント特定部４０９からイベントが発生したことを示す情報が提供されていない時間をタイマーなどによって計測し、所定の時間が経過した場合に状態関連情報４１１を更新してもよい。あるいは、状態管理部４１５は、定期的に状態関連情報４１１の更新処理を実行し、更新処理の実行時に、イベント特定部４０９や他センサデータ取得部４１７から提供された情報を状態関連情報４１１に反映させてもよい。

再び図３を参照して、他センサデータ取得部４１７は、入力インターフェース４０１を介して、モーションセンサとは異なる種類のセンシングデータを取得する。そのようなセンシングデータを提供するセンサは、例えばセンサ装置１００のセンサ１１０に含まれていてもよいし、スマートフォン２００に含まれていてもよいし（図２には示されていない）、センサ装置１００ともスマートフォン２００とも異なる装置、例えばテニスコートの周辺に設置されたカメラなどに含まれていてもよい。センサには、例えば、温度センサ、湿度センサ、照度センサ、位置センサ（ＧＰＳ受信機を含む）などユーザの環境情報を取得するためのセンサが含まれてもよい。また、センサには、スポーツをプレーするユーザなどの画像を取得する撮像装置や、ユーザの脈拍などを測定する生体情報センサが含まれてもよい。

上述のように、他センサデータ取得部４１７によって取得されたデータは、状態管理部４１５による状態関連情報４１１の更新に用いられてもよい。なお、主にイベント特定部４０９が提供する情報に基づいて状態管理部４１５が状態関連情報４１１を更新する場合、他センサデータ取得部４１７は必ずしも設けられなくてもよい。あるいは、主に他センサデータ取得部４１７が提供する情報に基づいて状態管理部４１５が状態関連情報４１１を更新する場合、イベント特定部４０９は状態管理部４１５に情報を提供しなくてもよい。

（１−３．解析処理の具体的な例）
図６および図７は、本開示の第１の実施形態において、状態関連情報によらずに特定されるプレーイベントの例と、状態関連情報を用いて特定されるプレーイベントの例とを示す図である。

図６には、プレーイベント「フォアハンドストローク」の例が示されている。テニスをプレーするユーザがフォアハンドストロークでボールを打った場合、ボールのインパクトによって発生する振動波形４０３０ａと、ラケットのスイングによって発生するモーション波形４０３０ｂとが、モーションデータ取得部４０３によって取得される。パターン検出部４０５は、例えば、振動波形４０３０ａに基づいて解析区間を決定し、当該解析区間におけるモーション波形４０３０ｂをモーションパターン４０７０と比較することによって、パターン４０５０ａを検出する。ここで、パターン４０５０ａは、図４の例におけるパターン「スイング−１」である。図４の例に示されるように、パターン「スイング−１」は、プレーイベント「フォアハンドストローク」に１対１で対応付けられている。従って、イベント特定部４０９は、パターン４０５０ａが検出された場合、状態関連情報４１１を参照しなくても、プレーイベント４０９０ａ（フォアハンドストローク）を特定することができる。

一方、図７には、プレーイベント「１ｓｔサーブ」の例が示されている。テニスをプレーするユーザが１本目のサーブを打った場合、図６の例と同様に、ボールのインパクトによって発生する振動波形４０３０ａと、ラケットのスイングによって発生するモーション波形４０３０ｂとがモーションデータ取得部４０３によって取得され（波形自体は図６の例とは異なる）、パターン検出部４０５がパターン４０５０ｂを検出する。ここで、パターン４０５０ｂは、図４の例におけるパターン「スイング−８」である。図４の例に示されるように、パターン「スイング−８」は、「スマッシュ」および「サーブ」の２つのプレーイベントが対応付けられている。従って、イベント特定部４０９は、パターン４０５０ｂが検出された場合、状態関連情報４１１０を参照して、プレーイベント４０９０ｂを特定する。図示された例では、状態関連情報４１１０が１ｓｔサーブの待機状態Ｗ１を示しているため、プレーイベント４０９０ｂは「１ｓｔサーブ」のプレーイベントである（この例では、図４に示された例のプレーイベント「サーブ」に、１本目であることを示す情報が追加されている）。

図８は、本開示の第１の実施形態における、モーションデータのパターンと、プレーイベントと、状態との関係の例を示す図である。なお、以下で説明する例では、図４に示した例と同様にモーションデータのパターンとプレーイベントとの関係が定義され、図５に示した例と同様にテニスのプレーに関する状態が定義されているものとする。

図８を参照すると、まず、状態Ｓ１１（ラリー）において、パターン検出部４０５がフォアハンドストロークのパターンＰ１１（図４の例におけるパターン「スイング−１」であるが、図８の説明では便宜上フォアハンドストロークのパターンと称する。パターンＰ１５についても同様）を検出する。このとき、イベント特定部４０９は、状態関連情報４１１を参照しなくても、フォアハンドストロークのプレーイベントＥ１１を特定することができる。状態管理部４１５は、特定されたプレーイベントＥ１１に基づいて状態関連情報４１１を更新する。ここでは、ラリー状態（Ｓ１１）でショットイベント（Ｅ１１）が発生しているため、ラリー状態Ｒでの自己遷移（Ｔ_ＲＲ）が発生し、結果として状態Ｓ１１は変更されない。

次に、状態Ｓ１１（ラリー）において、パターン検出部４０５がＮＳ（ＮＯＴ ＳＷＩＮＧ）のパターンＰ１２を検出する。このときも、イベント特定部４０９は、状態関連情報４１１を参照しなくても、ＮＳのプレーイベントＥ１２を特定することができる。状態管理部４１５は、特定されたプレーイベントＥ１２に基づいて状態関連情報４１１を更新する。ここでは、ラリー状態（Ｓ１１）でＮＳイベント（Ｅ１２）が発生しているため、ラリー状態Ｒから１ｓｔサーブの待機状態Ｗ１への遷移（Ｔ_ＲＷ１）が発生し、ラリー状態Ｓ１１は待機状態Ｓ１２に変更される。

次に、状態Ｓ１２（１ｓｔサーブの待機）において、パターン検出部４０５がオーバーハンドショットのパターンＰ１３（図４の例におけるパターン「スイング−８」であるが、図８の説明では便宜上オーバーハンドショットのパターンと称する。パターンＰ１４，Ｐ１６についても同様）を検出する。このとき、イベント特定部４０９は、状態関連情報４１１を参照してプレーイベントを特定する。より具体的には、イベント特定部４０９は、パターンＰ１３に対応するプレーの発生前の状態Ｓ１２が１ｓｔサーブの待機状態であったことに基づいて、１ｓｔサーブのプレーイベントＥ１３を特定する。

さらに、状態管理部４１５は、特定されたプレーイベントＥ１３に基づいて状態関連情報４１１を更新する。ここでは、１ｓｔサーブの待機状態（Ｓ１２）でショットイベント（Ｅ１３）が発生しているため、１ｓｔサーブの待機状態Ｗ１からラリー状態Ｒへの遷移（Ｔ_Ｗ１Ｒ）が発生し、待機状態Ｓ１２はラリー状態Ｓ１３に変更される。

その後、状態Ｓ１３（ラリー）において、例えば他センサデータ取得部４１７が、サーブミスを検出する。この情報を提供された状態管理部４１５は、ラリー状態Ｒから２ｎｄサーブの待機状態Ｗ２への遷移（Ｔ_ＲＷ２）を発生させ、ラリー状態Ｓ１３を２ｎｄサーブの待機状態Ｓ１４に変更する。

次に、状態Ｓ１４（２ｎｄサーブの待機）において、パターン検出部４０５がオーバーハンドショットのパターンＰ１４を検出する。このときも、パターンＰ１３の場合と同様に、イベント特定部４０９は状態関連情報４１１を参照してプレーイベントを特定する。より具体的には、イベント特定部４０９は、パターンＰ１４に対応するプレーの発生前の状態Ｓ１４が２ｎｄサーブの待機状態であったことに基づいて、２ｎｄサーブのプレーイベントＥ１４を特定する。

さらに、状態管理部４１５は、特定されたプレーイベントＥ１４に基づいて状態関連情報４１１を更新する。ここでは、２ｎｄサーブの待機状態（Ｓ１４）でショットイベント（Ｅ１４）が発生しているため、２ｎｄサーブの待機状態Ｗ２からラリー状態Ｒへの遷移（Ｔ_Ｗ２Ｒ）が発生し、待機状態Ｓ１４はラリー状態Ｓ１５に変更される。

その後、状態Ｓ１５（ラリー）において、パターン検出部４０５がフォアハンドストロークのパターンＰ１５を検出し、イベント特定部４０９がフォアハンドストロークのプレーイベントＥ１５を特定する。このときのイベント特定部４０９および状態管理部４１５の処理は、パターンＰ１１の場合と同様であるため説明は省略する。結果として、ラリー状態Ｒでの自己遷移（Ｔ_ＲＲ）が発生し、パターンＰ１５の検出時には状態Ｓ１５は変更されない。

次に、状態Ｓ１５（ラリー）において、パターン検出部４０５がオーバーハンドショットのパターンＰ１６を検出する。このときも、パターンＰ１３，１４の場合と同様に、イベント特定部４０９は状態関連情報４１１を参照してプレーイベントを特定する。より具体的には、イベント特定部４０９は、パターンＰ１６に対応するプレーの発生前の状態Ｓ１５がラリー状態であったことに基づいて、スマッシュのプレーイベントＥ１６を特定する。

さらに、状態管理部４１５は、特定されたプレーイベントＥ１６に基づいて状態関連情報４１１を更新する。ここでは、ラリー状態（Ｓ１５）でショットイベント（Ｅ１６）が発生しているため、ラリー状態Ｒでの自己遷移（Ｔ_ＲＲ）が発生し、結果として状態Ｓ１５は変更されない。

その後、状態Ｓ１５（ラリー）において、パターン検出部４０５がモーションデータのパターンを検出せず、イベント特定部４０９もプレーイベントを特定しない状態が所定の時間継続した場合に、状態管理部４１５は、例えばタイマーなどを用いてこれを検出し、ラリー状態Ｒから１ｓｔサーブの待機状態Ｗ１への遷移（Ｔ_Ｒｗ１）を発生させ、ラリー状態Ｓ１５を１ｓｔサーブの待機状態Ｓ１６に変更する。

（１−４．変形例）
図９は、本開示の第１の実施形態の変形例を示す図である。図９には、上記で図５を参照して説明した例と同様にして定義される、テニスのプレーに関する状態の別の例が示されている。図示された例では、ＳＴＰ（ストローク練習）、ＳＥＰ（サーブ練習）、ＶＰ（ボレー練習）、およびＳＭＰ（スマッシュ練習）の４つの状態が定義されている。図５に示された例と同様に、それぞれの状態の間での遷移、およびそれぞれの状態の自己遷移を、適切な条件に関連付けることによって、スポーツのプレーの進行に対応して状態を変化させることができる。

なお、上記で図５などを参照して説明した例では、遷移と条件とを対応付けるルールベースの手法によって状態の遷移が定義されたが、他の例では、例えば、観測データを基に、状態遷移モデルを自動的に学習する手法が採用されてもよい。状態遷移モデルは、例えば、ＨＭＭ（Hidden Markov Model）のような確率モデルとして定義できる。

以上、本開示の第１の実施形態について説明した。本実施形態では、状態関連情報４１１によって、ユーザによるスポーツのプレーのコンテキストが保持されている。状態関連情報４１１は、イベント特定部４０９および／または他センサデータ取得部４１７が提供する情報によって更新されている。従って、イベント特定部４０９は、パターン検出部４０５によって検出されたモーションデータのパターンに基づいてプレーイベントを特定するにあたり、状態関連情報４１１を参照することによって、プレーのコンテキストに即した適切なプレーイベントを特定することができる。

（２．第２の実施形態）
続いて、本開示の第２の実施形態について説明する。本実施形態は、解析処理のための機能構成の一部について上記の第１の実施形態と相違するが、それ以外の構成については第１の実施形態と同様であるため、重複した説明は省略する。

図１０は、本開示の第２の実施形態における解析処理のための機能構成を示すブロック図である。図１０を参照すると、機能構成５００は、入力インターフェース４０１と、モーションデータ取得部４０３と、パターン検出部４０５と、イベント特定部５０９と、出力インターフェース４１３とを含む。機能構成５００のうち、入力インターフェース４０１および出力インターフェース４１３を除いた処理部、すなわちモーションデータ取得部４０３、パターン検出部４０５、およびイベント特定部５０９は、センサ装置１００の処理部１２０、スマートフォン２００の処理部２２０、および／またはサーバ３００の処理部３２０によって実現される。センサ装置１００の処理部１２０、スマートフォン２００の処理部２２０、および／またはサーバ３００の処理部３２０によって実現される。以下では、第１の実施形態とは異なる構成要素であるイベント特定部５０９、およびイベント特定部５０９が参照するイベント履歴５１１について、さらに説明する。

イベント特定部５０９は、パターン検出部４０５によって検出されたモーションデータのパターンに基づいて、ユーザがプレーに対応するプレーイベントを特定する。本実施形態において、イベント特定部５０９は、上記の第１の実施形態でイベント特定部４０９が参照した状態関連情報４１１の代わりに、イベント履歴５１１を参照する。本実施形態では、イベント履歴５１１は、解析処理を実行する装置の記憶部に格納されている。あるいは、イベント履歴５１１は、解析処理を実行する装置とは異なる装置の記憶部に格納されており、イベント特定部５０９はネットワークを介してイベント履歴５１１を参照してもよい。イベント特定部５０９は、イベント履歴５１１の参照が必要とされない場合も含め、プレーイベントを特定した場合、当該特定されたプレーイベントの情報をイベント履歴５１１に追加する。

イベント履歴５１１は、イベント特定部５０９によって特定されたイベントの履歴を示す情報であり、イベント特定部５０９がプレーイベントを特定するために参照される。つまり、本実施形態において、イベント特定部５０９は、過去に自ら特定したイベントの履歴に基づいて、新たに検出されたモーションデータのパターンに対応するプレーイベントを特定する。イベント履歴５１１には、例えば、第１の実施形態で図４を参照して説明したプレーイベントを示す情報と、各プレーイベントが発生した時刻を示すタイムスタンプとが格納される。

図１１は、本実施形態における、イベント履歴を参照したプレーイベント特定の処理の例を示すフローチャートである。なお、以下で説明する例では、第１の実施形態で図４に示した例と同様にモーションデータのパターンとプレーイベントとの関係が定義されているものとする。従って、イベント特定部５０９がプレーイベントの特定にあたってイベント履歴５１１を参照するのは、パターン検出部４０５によってパターン「スイング−８」（オーバーハンドショット）が検出された場合である。

図１１を参照すると、パターン検出部４０５によってパターン「スイング−８」（オーバーハンドショット）が検出された場合、イベント特定部５０９はイベント履歴５１１を参照し、直前に特定されたイベントがＮＳ（ＮＯＴ ＳＷＩＮＧ）であるか否かを判定する（Ｓ１０１）。ここで、直前に特定されたイベントがＮＳではない、つまりショットイベントである場合（ＮＯ）、イベント特定部５０９は、さらに、直前のイベント（ショットイベント）が発生してから１秒未満であるか否かを判定する（Ｓ１０３）。なお、ここで、１秒というのはラリーにおけるショットの間隔に対応する時間閾値の一例であり、他の例では異なる時間閾値が採用されてもよい。

上記のＳ１０３の判定において、直前のイベントが発生してから１秒未満であると判定された場合（ＹＥＳ）、イベント特定部５０９は、プレーイベント「スマッシュ」を特定する（Ｓ１０５）。この場合、イベント特定部５０９は、「直前のイベントがＮＳではなく」（Ｓ１０１の判定）、かつ「直前のイベントから１秒未満である」（Ｓ１０３の判定）という条件によって、第１の実施形態でいうラリー状態Ｒと同様のプレーのコンテキストを識別しているといえる。

一方、上記のＳ１０１の判定において、直前に特定されたイベントがＮＳである場合（ＹＥＳ）、イベント特定部５０９は、ＮＳ以外の直前のイベントを、イベント履歴に関する判定の対象にする（Ｓ１０７）。ＮＳのイベントが複数回連続して特定されている場合、イベント特定部５０９はそのさらに前に特定されたＮＳ以外のイベント、つまりショットイベント判定の対象にする。

上記のＳ１０３の判定において直前のイベントが発生してから１秒未満ではなかった場合（ＮＯ）、および上記のＳ１０７においてＮＳ以外の直前のイベントが判定の対象になった場合、イベント特定部５０９は、さらに、直前のイベントが１ｓｔサーブのプレーイベントであるか否かを判定する（Ｓ１０９）。ここで、直前のイベント（Ｓ１０１およびＳ１０７の結果、ショットイベントに限定されている）が１ｓｔサーブではなかった場合（ＮＯ）、イベント特定部５０９は、プレーイベント「１ｓｔサーブ」を特定する（Ｓ１１１）。この場合、イベント特定部５０９は、「直前のイベントがＮＳであり」（Ｓ１０１の判定）、かつ「ＮＳ以外の直前のイベントが１ｓｔサーブではない」（Ｓ１０９の判定）という条件、または、「直前のイベントがショットイベントであり」（Ｓ１０１の判定）、「直前のショットイベントから１秒以上経過しており」（Ｓ１０３の判定）、かつ「直前のショットイベントが１ｓｔサーブではない」（Ｓ１０９の判定）という条件によって、第１の実施形態でいう１ｓｔサーブの待機状態Ｗ１と同様のプレーのコンテキストを識別しているといえる。

一方、上記のＳ１０９の判定において、直前のイベントが１ｓｔサーブであった場合（ＹＥＳ）、イベント特定部５０９は、プレーイベント「２ｎｄサーブ」を特定する（Ｓ１１３）。この場合、イベント特定部５０９は、「直前のイベントがＮＳであり」（Ｓ１０１の判定）、かつ「ＮＳ以外の直前のイベントが１ｓｔサーブである」（Ｓ１０９の判定）という条件、または、「直前のイベントがショットイベントであり」（Ｓ１０１の判定）、「直前のショットイベントから１秒以上経過しており」（Ｓ１０３の判定）、かつ「直前のショットイベントが１ｓｔサーブである」（Ｓ１０９の判定）という条件によって、第１の実施形態でいう２ｎｄサーブの待機状態Ｗ２と同様のプレーのコンテキストを識別しているといえる。

なお、厳密には、直前のショットイベントが１ｓｔサーブであっても、サービスエースまたはサービスウィナーの場合には、その次に発生するイベントは１ｓｔサーブになりうる。従って、Ｓ１０９の判定は、より正確には「直前のイベントが１ｓｔサーブのプレーイベントであり、かつサーブミスが検出されたか否か」の判定であってもよい。サーブミスは、例えば、第１の実施形態で説明した他センサデータ取得部４１７によって取得される情報や、ユーザがマニュアル入力した情報などに基づいて検出することができる。

以上、本開示の第２の実施形態について説明した。本実施形態では、イベント履歴５１１に格納された情報に基づいて、ユーザによるスポーツのプレーのコンテキストが識別される。つまり、本実施形態では、プレーのコンテキストを直接的に表す情報を保持する代わりに、コンテキストを識別するためのソースになる情報であるイベント履歴５１１を保持しておき、コンテキストに基づく判定が必要なモーションデータのパターンが検出された場合にイベント履歴５１１に基づいてプレーのコンテキストが識別される。本実施形態では、第１の実施形態のように、状態管理部４１５が状態関連情報４１１を更新する処理が必要とされないため、処理負荷が軽減されうる。

（３．ハードウェア構成）
次に、図１２および図１３を参照して、本開示の実施形態に係るセンサ装置および情報処理装置（上述した例ではセンサ装置、スマートフォンまたはサーバ）を実現するためのハードウェア構成の例について説明する。

（センサ装置）
図１２は、本開示の実施形態に係るセンサ装置のハードウェア構成の例を示す図である。図１２を参照すると、センサ装置１００は、センサ１０１と、ＣＰＵ（Central Processing Unit）１０３と、ＲＯＭ（Read Only Memory）１０５と、ＲＡＭ（Random Access Memory）１０７と、ユーザインターフェース１０９と、外部記憶装置１１１と、通信装置１１３と、出力装置１１５とを含みうる。これらの要素は、例えばバスによって相互に接続される。

センサ１０１は、例えば加速度センサ、角速度センサ、振動センサ、地磁気センサ、温度センサ、圧力センサ（押下スイッチを含む）、またはＧＰＳ（Global Positioning System）受信機などを含む。センサ１０１は、カメラ（イメージセンサ）やマイクロフォン（音センサ）を含んでもよい。

ＣＰＵ１０３、ＲＯＭ１０５、およびＲＡＭ１０７は、例えば外部記憶装置１１１に記録されたプログラム命令を読み込んで実行することによって、様々な機能をソフトウェア的に実現する。本開示の実施形態では、ＣＰＵ１０３、ＲＯＭ１０５、およびＲＡＭ１０７によって、例えば、センサ装置１００全体の制御などの機能が実現されうる。

ユーザインターフェース１０９は、センサ装置１００へのユーザ操作を受け付ける、例えばボタンやタッチパネルなどの入力装置である。ユーザの操作は、例えば、センサ装置からのセンサ情報の送信の開始や終了を指示するものでありうる。

外部記憶装置１１１は、センサ装置１００に関する各種の情報を記憶する。外部記憶装置１１１には、例えば、ＣＰＵ１０３、ＲＯＭ１０５、およびＲＡＭ１０７にソフトウェア的に機能を実現させるためのプログラム命令が格納されてもよく、またセンサ１０１によって取得されたデータが一時的にキャッシュされてもよい。センサ装置１００が打具などに装着されることを考慮すると、外部記憶装置１１１としては、例えば半導体メモリなどの衝撃に強いものを使用することが望ましい。
なお、上述した、スマートフォン２００がスポーツをプレーしているユーザの近傍に配置されない場合における、センサ装置１００において検出されたデータを蓄積する内部の記憶領域（メモリまたは外部記憶装置）に対応する構成は、ＲＯＭ１０５、ＲＡＭ１０７、および／または外部記憶装置１１１である。

通信装置１１３は、有線または無線の各種通信方式によって後述する情報処理装置６００と通信する。また、通信装置１１３は、機器間通信によって直接的に情報処理装置６００と通信してもよいし、インターネットなどのネットワークを介して情報処理装置６００と通信してもよい。

出力装置１１５は、情報を光、音声または画像として出力することが可能な装置で構成される。出力装置１１５は、例えばセンサ装置１００における時刻やプレーイベントの検出を通知する情報を出力してもよいし、情報処理装置６００から受信された解析結果、またはセンサ装置１００において算出された解析結果に基づいて、ユーザに対する視覚的または聴覚的な通知を出力してもよい。出力装置１１５は、例えば、例えばＬＥＤなどのランプ、ＬＣＤなどのディスプレイ、スピーカ、またはバイブレータなどを含む。

（情報処理装置）
図１３は、本開示の実施形態に係る情報処理装置のハードウェア構成の例を示す図である。情報処理装置６００は、本開示の実施形態に係る情報処理装置、例えば上記で説明したスマートフォン２００またはサーバ３００を実現しうる。なお、上述のように、情報処理装置は、センサ装置１００によって実現されてもよい。

情報処理装置６００は、ＣＰＵ６０１と、ＲＯＭ６０３と、ＲＡＭ６０５と、ユーザインターフェース６０９と、外部記憶装置６１１と、通信装置６１３と、出力装置６１５とを含みうる。これらの要素は、例えばバスによって相互に接続される。

ＣＰＵ６０１、ＲＯＭ６０３、およびＲＡＭ６０５は、例えば外部記憶装置６１１に記録されたプログラム命令を読み込んで実行することによって、様々な機能をソフトウェア的に実現する。本開示の実施形態では、ＣＰＵ６０１、ＲＯＭ６０３、およびＲＡＭ６０５によって、例えば、情報処理装置６００全体の制御や、上記の機能構成における処理部の機能などが実現されうる。

ユーザインターフェース６０９は、情報処理装置６００へのユーザ操作を受け付ける、例えばボタンやタッチパネルなどの入力装置である。

外部記憶装置６１１は、情報処理装置６００に関する各種の情報を記憶する。外部記憶装置６１１には、例えば、ＣＰＵ６０１、ＲＯＭ６０３、およびＲＡＭ６０５にソフトウェア的に機能を実現させるためのプログラム命令が格納されてもよく、また通信装置６１３が受信したセンサ情報が一時的にキャッシュされてもよい。また、外部記憶装置６１１には、解析結果のログが蓄積されてもよい。

出力装置６１５は、情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置６１５は、例えば、ＬＣＤ（Liquid Crystal Display）などの表示装置、またはスピーカやヘッドホンなどの音声出力装置などでありうる。出力装置６１５は、情報処理装置６００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音声または音響などの音声として出力したりする。

以上、センサ装置１００および情報処理装置６００のハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。かかる構成は、実施する時々の技術レベルに応じて適宜変更されうる。

（４．補足）
本開示の実施形態は、例えば、上記で説明したような情報処理装置（スマートフォンなどの情報処理端末、サーバ、またはセンサ装置）、システム、情報処理装置またはシステムで実行される情報処理方法、情報処理装置を機能させるためのプログラム、およびプログラムが記録された一時的でない有形の媒体を含みうる。

より具体的には、例えば、本開示の実施形態は、対象のアクションに起因して発生するセンシングデータを取得するデータ取得部と、前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定するイベント特定部とを備える情報処理装置を含む。

例えば、上記の第１および第２の実施形態では、対象のアクションとしてユーザによるスポーツのプレーが例示された。しかし、他の実施形態では、対象はユーザに限られず（人ではなく動物や物であってもよい）、またアクションもスポーツのプレーだけではなくあらゆるアクションを含みうる。例えば、車を運転しているユーザが頭を下げた場合、それがお辞儀であるのか居眠りであるのかを、アクションのコンテキスト（例えば運転の状態）に基づいて識別することは有用である。また、例えば、ユーザがお辞儀をした場合に、それが挨拶のお辞儀であるのか謝罪のお辞儀であるかをアクションのコンテキスト（例えば会話のトーンなど）に基づいて識別することは、ユーザの行動ステータスを共有するサービスなどでは有用である。また、アクションがスポーツのプレーである場合も、スポーツの種類はテニスには限られず、例えばバレーボール（ジャンプサーブとスパイク（アタック）をコンテキストに基づいて識別する）や卓球（フォアハンドやバックハンドのスイングやドライブと、それぞれのショットをサーブとして打った場合とをコンテキストに基づいて識別する）などであってもよい。また、本技術を適用可能なスポーツは、上記のような対戦型の球技には限られず、プレーのコンテキストが定義可能なあらゆる種類のスポーツを含みうる。

また、上記の第１および第２の実施形態では、センシングデータとしてモーションデータが例示された。しかし、他の実施形態では、センシングデータはモーションデータに限られず、対象のアクションの画像を取得する撮像装置や、対象である人や動物の脈拍などを測定する生体情報センサなどであってもよい。また、センシングデータは、温度センサ、湿度センサ、照度センサ、位置センサ（ＧＰＳ受信機を含む）など、対象の環境情報を取得するためのセンサによって提供されてもよい。

また、上記の第１および第２の実施形態では、アクション（プレー）の発生前のコンテキストに基づいてイベントが特定された。しかし、他の実施形態では、アクションの発生後のコンテキストにさらに基づいてイベントが特定されてもよい。例えば、アクション（プレー）の進行中にリアルタイムでイベントを特定する場合にはアクション（プレー）の発生前のコンテキストに基づいてイベントが特定されるが、アクション（プレー）の発生後に事後的にイベントを特定する場合には、アクション（プレー）の発生後のコンテキストにさらに基づいてアクションに対応するイベントを特定することも可能である。

また、上記の第１および第２の実施形態では、センシングデータ（モーションデータ）のパターンだけではプレーイベントを特定することが困難な場合にコンテキストが参照された。しかし、他の実施形態では、コンテキストに基づく判定がパターンに基づく判定に優越してもよい。例えば、第１および第２の実施形態と同様のテニスの例において、状態関連情報４１１、またはイベント履歴５１１によって、サーブの待機状態に相当するコンテキストが示される場合には、モーションデータのパターンに関わらず、ショットが発生した場合にはサーブのプレーイベントが特定されてもよい。例えば、テニスのサーブにはオーバーヘッドサーブとアンダーサーブとがあり、アンダーサーブの場合はオーバーヘッドサーブ（スマッシュに類似）とは異なるモーションデータのパターンが発生する。上記のようにコンテキストに基づく判定を利用すれば、いずれの場合も正しくサーブのプレーイベントを検出することができる。

また、プレーヤによっては、上記の２パターンにあてはまらない変則的なフォームでサーブを打つ場合もありうる。例えば、変則的なサーブのパターンがフォアハンドストロークのパターンに類似していたり、あるいは他のどのショットのパターンにも類似していなかったりしたとしても、コンテキストに基づく判定を利用すれば、正しくサーブのプレーイベントを検出することができる。また、他の例として、相手のサーブを返すショットを、「リターン」のプレーイベントとして、他のショットとは区別してもよい。この場合、「リターン」プレーイベントは、モーションデータのパターンが示すショットの種類（フォアハンドストローク、バックハンドストロークなど）に関わらず、コンテキスト（相手のサーブの直後のショット）に基づいて特定されうる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）対象のアクションに起因して発生するセンシングデータを取得するデータ取得部と、
前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定するイベント特定部と
を備える情報処理装置。
（２）前記イベント特定部は、前記アクションに対応するイベントを、前記パターンに対応付けられる複数のイベントの中から前記コンテキストに基づいて選択する、前記（１）に記載の情報処理装置。
（３）前記アクションは、スポーツのプレーを含み、
前記イベントは、少なくとも前記スポーツのルールに従って規定されるプレーイベントを含む、前記（１）または（２）に記載の情報処理装置。
（４）前記センシングデータは、モーションデータを含む、前記（１）〜（３）のいずれか１項に記載の情報処理装置。
（５）前記イベント特定部は、前記アクションの発生前の前記コンテキストに基づいて前記アクションに対応するイベントを特定する、前記（１）〜（４）のいずれか１項に記載の情報処理装置。
（６）前記イベント特定部は、前記アクションの発生後の前記コンテキストにさらに基づいて前記アクションに対応するイベントを特定する、前記（５）に記載の情報処理装置。
（７）前記コンテキストは、少なくとも前記センシングデータに基づいて定義される、前記（１）〜（６）のいずれか１項に記載の情報処理装置。
（８）前記イベント特定部は、前記アクションの発生前のイベント履歴に基づいて前記アクションに対応するイベントを特定する、前記（７）に記載の情報処理装置。
（９）前記コンテキストは、前記センシングデータとは異なるデータに基づいて定義される、前記（１）〜（８）のいずれか１項に記載の情報処理装置。
（１０）前記センシングデータは、モーションデータを含み、
前記コンテキストは、前記モーションデータとは異なる種類のセンシングデータに基づいて定義される、前記（９）に記載の情報処理装置。
（１１）対象のアクションに起因して発生するセンシングデータを取得するデータ取得機能と、
前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定するイベント特定機能と
を情報処理装置のプロセッサに実現させるためのプログラムが記録された記録媒体。
（１２）対象のアクションをセンシングすることと、
前記センシングによって取得されたセンシングデータを送信することと、
前記センシングデータを受信する情報処理装置のプロセッサが、前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定する処理を実行することと
を含む情報処理方法。

１０ システム
１００ センサ装置
１１０ センサ
１２０ 処理部
２００ スマートフォン
２１０ 受信部
２２０ 処理部
３００ サーバ
３１０ 受信部
３２０ 処理部
４０３ モーションデータ取得部
４０５ パターン検出部
４０７ モーションパターン
４０９，５０９ イベント特定部
４１１ 状態関連情報
４１５ 状態管理部
４１７ 他センサデータ取得部
５１１ イベント履歴

Claims (12)

1. 対象のアクションに起因して発生するセンシングデータを取得するデータ取得部と、
   前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定するイベント特定部と
   を備える情報処理装置。
2. 前記イベント特定部は、前記アクションに対応するイベントを、前記パターンに対応付けられる複数のイベントの中から前記コンテキストに基づいて選択する、請求項１に記載の情報処理装置。
3. 前記アクションは、スポーツのプレーを含み、
   前記イベントは、少なくとも前記スポーツのルールに従って規定されるプレーイベントを含む、請求項１に記載の情報処理装置。
4. 前記センシングデータは、モーションデータを含む、請求項１に記載の情報処理装置。
5. 前記イベント特定部は、前記アクションの発生前の前記コンテキストに基づいて前記アクションに対応するイベントを特定する、請求項１に記載の情報処理装置。
6. 前記イベント特定部は、前記アクションの発生後の前記コンテキストにさらに基づいて前記アクションに対応するイベントを特定する、請求項５に記載の情報処理装置。
7. 前記コンテキストは、少なくとも前記センシングデータに基づいて定義される、請求項１に記載の情報処理装置。
8. 前記イベント特定部は、前記アクションの発生前のイベント履歴に基づいて前記アクションに対応するイベントを特定する、請求項７に記載の情報処理装置。
9. 前記コンテキストは、前記センシングデータとは異なるデータに基づいて定義される、請求項１に記載の情報処理装置。
10. 前記センシングデータは、モーションデータを含み、
    前記コンテキストは、前記モーションデータとは異なる種類のセンシングデータに基づいて定義される、請求項９に記載の情報処理装置。
11. 対象のアクションに起因して発生するセンシングデータを取得するデータ取得機能と、
    前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定するイベント特定機能と
    を情報処理装置のプロセッサに実現させるためのプログラムが記録された記録媒体。
12. 対象のアクションをセンシングすることと、
    前記センシングによって取得されたセンシングデータを送信することと、
    前記センシングデータを受信する情報処理装置のプロセッサが、前記センシングデータに現れるパターン、および前記アクションのコンテキストに基づいて前記アクションに対応するイベントを特定する処理を実行することと
    を含む情報処理方法。
    

Images