JP2015106845A - 携帯端末の動きを認識するためのシステム、装置および方法 - Google Patents

Abstract

【課題】携帯端末の動きを認識するためのシステム、装置および方法を提供する。
【解決手段】携帯端末の動きを認識するためのシステムは、前記携帯端末の動きを認識するためのセンサデータを取得する取得手段と、前記センサデータに基づいて、前記携帯端末の動きに応じて付与された複数のコードからなる第１のコード列を生成する生成手段と、前記第１のコード列と格納されている第２のコード列とを比較する比較手段とを含む。
【選択図】図４

Description

本発明は、携帯端末の動きを認識するためのシステム、装置および方法に関する。より詳細には、携帯端末の動きに基づきコード列を生成して、そのコード列を用いて、携帯端末の動きが他の携帯端末の動きと類似しているか否かを判定するシステム、装置および方法に関する。

従来、スマートフォン同士でメールアドレス等のデータを交換するためのアプリケーションソフトとして「Ｂｕｍｐ」が知られている。「Ｂｕｍｐ」では、ＧＰＳ（Global Positioning System）によるスマートフォンの位置情報をもとに、データ交換を行なう２つのスマートフォンを特定している。

しかし、一定のエリア内で複数のスマートフォンが同時にデータ交換をしようとした場合、誤認識が発生することが多々ある。すなわち、本来データ交換しようとしているスマートフォンではなく、そのそばに存在する全く別のスマートフォンがデータ交換相手の候補として誤認識されてしまうことがある。

ところで、携帯端末を持つユーザのジェスチャを認識する方法として、特許文献１のような方法がある。特許文献１では、携帯端末内のジャイロスコープや加速度センサから提供されたデータに基づき、ユーザのジェスチャを認識している。具体的には、ジャイロスコープや加速度センサから提供されたデータを変換した値を、データベースに記憶されている値と比較して、データベース内で最も近いものを選び出す。すなわち、ユーザが行なったジェスチャが、事前に登録しておいたジェスチャのうちのどれと類似しているかを判定するための方法である。

特表２０１３−５１０３８１号公報

上記のようなデータ交換相手の候補の誤認識問題を解消するための方法の１つとして、例えばデータ交換を行いたい２つの携帯端末を重ねて持ってジェスチャを行い、ジェスチャが類似していると判定される携帯端末間でデータ交換を行う方法が考えられる。しかし、特許文献１のようなユーザが行ったジェスチャを既に登録されたジェスチャと比較する方法によっては、携帯端末同士を重ねて持ってジェスチャを行った場合の比較はできなかった。特許文献１では、初めて行なわれる２つの携帯端末の動きが類似しているか否かを判定することができないからである。

本発明は、このような問題に鑑みてなされたもので、その目的とするところは、携帯端末の動きに基づきコード列を生成して、そのコード列を用いて、携帯端末の動きが他の携帯端末の動き等と類似しているか否かを判定するためのシステム、装置および方法を提供することにある。具体的には、携帯端末の動きに応じたセンサデータを複数のコードに分類して、これらのコードからなるコード列を生成する。このコード列と他の携帯端末の動きに基づくコード列とを比較して、２つの携帯端末の動きが類似しているか否かを判定する。あるいは、このコード列と携帯端末に動きが加えられる前から予め登録されているコード列とを比較して、携帯端末の動きが登録された動きと類似しているか否かを判定する。

本発明に係る携帯端末の動きを認識するためのシステムは、このような目的を達成するために、携帯端末の動きを認識するためのセンサデータを取得する取得手段と、センサデータに基づいて、携帯端末の動きに対応した複数のコードからなる第１のコード列を生成する生成手段と、第１のコード列と格納されている第２のコード列とを比較する比較手段とを備えたことを特徴とする。

以上説明したように、本発明によれば、携帯端末の動きに応じたセンサデータを複数のコードに分類して、これらのコードからなるコード列を生成することができる。このコード列の生成方法に加え、２つのコード列間の類似度を求めるアルゴリズムを用いることで、２つの携帯端末の動きが類似しているか否かを判定することが可能となる。

本発明を実施するためのシステム構成図である。 サーバの詳細図である。 携帯端末の詳細図である。 携帯端末の動きをもとにコード列を生成するフローチャートである。 ノイズ対策の例である。 オン閾値とオフ閾値が異なる場合のコード列生成のフローチャートである。 別のノイズ対策の例である。 コード列の比較例である。

図１は、本発明を実施するためのシステム構成図である。

このシステムには、サーバ１０１、携帯端末１０２および携帯端末１０３が含まれる。サーバ１０１は、携帯端末１０２および携帯端末１０３とインターネットを介してデータの送受信が可能である。携帯端末１０２および携帯端末１０３には、スマートフォンやタブレット、携帯電話等の機器が含まれる。また、携帯端末１０２および携帯端末１０３は、加速度センサやジャイロスコープ等の携帯端末の動きを検出するセンサを備える。尚、以下に示す通り、本発明の実施の形態によっては、そのシステムの構成要素として必ずしも携帯端末１０２と携帯端末１０３との両方を備える必要はないし、或いは３つ以上の複数の携帯端末が含まれていても良い。

図２は、サーバ１０１の詳細図である。

サーバ１０１には、データ受信部２０１、データ送信部２０２、第１記憶部２０３、第２記憶部２０４、演算処理部２０５が含まれる。データ受信部２０１は、携帯端末１０２および携帯端末１０３からデータを受信できる。また、データ送信部２０２は、携帯端末１０２および携帯端末１０３にデータを送信できる。第１記憶部２０３は、携帯端末１０２の動きに基づき生成されたコード列を格納できる。また、第２記憶部２０４は、携帯端末１０３の動きに基づき生成されたコード列を格納できる。あるいは、第２記憶部２０４は、携帯端末に動きが加えられる前に予め任意のコード列を格納しておくこともできる。なお、第１記憶部２０３および第２記憶部２０４は、コード列を生成するためのコードを一時的に格納しておくこともできる。演算処理部２０５は、２つのコード列を比較して、コード列に対応する２つの動きが類似しているか否かを判定することができる。さらに、演算処理部２０５は、コード列の生成をすることもできる。

図３は、携帯端末１０２および携帯端末１０３の詳細図である。

携帯端末１０２および携帯端末１０３には、データ受信部３０１、データ送信部３０２、加速度センサやジャイロスコープ等のセンサ３０３、演算処理部３０４、記憶部３０５が含まれる。データ受信部３０１は、サーバ１０１からデータを受信できる。また、データ送信部３０２は、サーバ１０１にデータを送信できる。センサ３０３には、加速度センサやジャイロスコープ等が含まれる。演算処理部３０４は、コード列の生成をすることができる。記憶部３０５は、コード列を生成するためのコードを一時的に格納しておくことができる。

［コード列の生成］
本発明におけるコード列は、携帯端末に生じた何らかの「動き」を、加速度センサやジャイロスコープ等のセンサ３０３から少なくとも１点以上の時点で取得された各出力値をもとに、１つ以上の長さを持ったコードの列として表現するものである。この際、コード列を構成する各単一のコードは、センサ３０３から取得された単一の出力値自体であっても良いが、本発明における２つのコード列間の類似の判定を好適に行う場合には、センサ３０３から取得された単一または複数の出力値に応じて、新たなコードを作成し、コード列を生成することが好ましい。

図４は、コード列の生成方法の一例を示すフローチャートである。コード列の生成処理は、サーバ内の演算処理部２０５または携帯端末内の演算処理部３０４のいずれにおいてでも行なうことが可能である。また、携帯端末内の加速度センサやジャイロスコープ等のセンサ３０３は、携帯端末の動きを検出して、この動きに基づく値を逐次出力している。

ステップ４０１で、演算処理部２０５または３０４は、コード列生成の開始を指示するコマンドを受け取ると、加速度センサやジャイロスコープ等のセンサ３０３からの出力値を取得し始める。例えば、携帯端末の利用者がアプリケーションソフトウェアの開始ボタンを押下することに応じて、開始コマンドが演算処理部２０５または３０４に与えられるようにすることができる。あるいは、携帯端末に特定の動きが加えられたことに応じて、開始コマンドが演算処理部２０５または３０４に与えられるようにすることもでき、演算処理部２０５または３０４が開始コマンドを受け取るための条件は特に限定されない。既述したように、コード列の生成処理は、サーバ内の演算処理部２０５または携帯端末内の演算処理部３０４のいずれにおいてでも行なうことが可能である。コード列がサーバ内の演算処理部２０５で生成される場合、加速度センサやジャイロスコープ等のセンサ３０３からの出力値が携帯端末のデータ送信部３０２からサーバのデータ受信部２０１に送信されて、サーバ内の演算処理部２０５によって処理される。

以降、ｘ軸・ｙ軸・ｚ軸の３方向の加速度を測定できる３軸加速度センサのみを用いた場合でコード列生成処理の一例を示す。この３軸加速度センサから出力される加速度ベクトルを、順に（ｘ_１,y_１,z_１）, （ｘ₂,y₂,z₂）・・・とする。

ステップ４０２で、フラグがオンかオフかを判定し、オフならばステップ４０３に、オンならばステップ４０６に進む。

ステップ４０３で、演算処理部２０５または３０４は、直近のステップ４０１で取得された加速度ベクトルの成分の大きさを求める（すなわち、ステップ４０１で出力値を取得するごとにステップ４０２以降のステップが行われる）。次に、演算処理部２０５または３０４は、この加速度ベクトルの大きさが閾値を超えるか否かを判定する。加速度ベクトルの大きさが閾値を超える場合は、ステップ４０４でフラグをオンにしてステップ４０５に進み、そうでない場合（加速度ベクトルの大きさが閾値以下の場合）はステップ４０１に進む。

ステップ４０５で、演算処理部２０５または３０４は、直近のステップ４０１で取得された加速度ベクトルの成分“ｘ_ｋ，ｙ_ｋ，ｚ_ｋ”の絶対値“｜ｘ_ｋ｜，｜ｙ_ｋ｜，｜ｚ_ｋ｜（｜ａ｜はａの絶対値）”のうち最も大きな値を求める。さらに、その最も大きな値を有する成分（すなわち、ｘ_ｋ、ｙ_ｋ、ｚ_ｋのいずれか１つ）の符号（プラスまたはマイナス）を求める。次に、演算処理部２０５または３０４は、これらの求められた「最も大きな値であった成分」と「その符号」に基づき、出力値のコード化を行なう。例えば、最も大きな値であった成分（以下、この段落では成分という）が「ｘ_ｋ」でその符号が「プラス」の場合のコードを「→」とする。また、成分が「ｘ_ｋ」・符号が「マイナス」の場合は「←」、成分が「ｙ_ｋ」・符号が「プラス」の場合は「↑」、成分が「ｙ_ｋ」・符号が「マイナス」の場合は「↓」、成分が「ｚ_ｋ」・符号が「プラス」の場合は「上」、成分が「ｚ_ｋ」・符号が「マイナス」の場合は「下」にコード化されるとする。この場合、３軸加速度センサから取得した値が、６種類のコードへとコード化される。なお、このコード化は例示であり、６種類のコードに限らず、２０種類のコードなど多種類のコードへのコード化を行なうこともできる。演算処理部２０５または３０４は、コード化されたコードをサーバまたは携帯端末の記憶部に記憶しておく。

ステップ４０６で、演算処理部２０５または３０４は、直近のステップ４０２で取得された加速度ベクトルの成分の大きさを求める。次に、演算処理部２０５または３０４は、この加速度ベクトルの大きさが閾値を超えるか否かを判定する。加速度ベクトルの大きさが閾値を超える場合は、ステップ４０８に進み、そうでない場合（加速度ベクトルの大きさが閾値以下の場合）はステップ４０７でフラグをオフにしてステップ４０１に進む。

ステップ４０８では、直近のステップ４０２で取得された加速度ベクトルの成分をステップ４０５と同様の手順でコード化すると仮定したとき、そのコードが最後にコード化されたコード（つまり、コード列において一つ手前に配置されるコード）と一致するかどうかを判定する。一致すると判定される場合はステップ４０１に進み、そうでない場合（一致しないと判定される場合）はステップ４０５に進む。

このように、演算処理部２０５または３０４は、ステップ４０１から４０８の処理を行なう。演算処理部２０５または３０４は、コード列生成の終了を指示するコマンドを受け取ると、加速度センサやジャイロスコープ等のセンサ３０３からの出力値の取得を終える。例えば、携帯端末の利用者がアプリケーションソフトウェアの終了ボタンを押下することに応じて、終了コマンドが演算処理部２０５または３０４に与えられるようにすることができる。あるいは、携帯端末に特定の動きが加えられたことに応じて、終了コマンドが演算処理部２０５または３０４に与えられるようにすることもできる。あるいは、携帯端末に動きが加えられない状態（例えば、加速度センサやジャイロスコープ等のセンサ３０３からの出力値の大きさが規定された閾値未満の状態）が一定時間続くと、終了コマンドが演算処理部２０５または３０４に与えられるようにすることもでき、演算処理部２０５または３０４が終了コマンドを受け取るための条件は特に限定されない。演算処理部２０５または３０４は、取得した出力値のコード化が全て終了すると、サーバまたは携帯端末の記憶部に記憶しておいたコードからコード列を生成する。すなわち、コード化されたコードを時系列で並べて、コード列を生成する。

上記の方法で生成されたコード列は、サーバの第１記憶部２０３または第２記憶部２０４に格納される。既述したように、コード列の生成処理は、サーバ内の演算処理部２０５または携帯端末内の演算処理部３０４のいずれにおいてでも行なうことが可能である。コード列が携帯端末内の演算処理部３０４で生成された場合、生成後、コード列が携帯端末のデータ送信部３０２からサーバのデータ受信部２０１に送信されて、サーバの第１記憶部２０３または第２記憶部２０４に格納される。

既述したように、加速度ベクトルから各コードへの分類は、加速度ベクトルの大きさが閾値を超えているか、および加速度ベクトルの向きに影響を受ける。したがって、携帯端末に加えられた動きの強弱に関わらず（すなわち、強い力で動きを加えられた携帯端末であっても、弱い力で動きを加えられた携帯端末であっても）、同様の軌道で携帯端末を動かしたのであれば、概ね類似したコード列を生成可能である。

本明細書に記載された方法は一例であり、携帯端末の動きに応じたコードを付与する方法や携帯端末の動きに応じてコード列を生成する方法は、上記のほか、様々な形態で実現することが可能である。

［コード列生成の追加処理］
次に、コード列生成の際に、任意選択できる追加処理を説明する。まず、ノイズ対策について説明する。

図５は、加速度ベクトルの大きさが、閾値周辺で変化する場合の対処例を示す。なお、便宜上、Ｘ軸とＹ軸のみで説明するが、Ｘ軸、Ｙ軸、Ｚ軸の３軸であっても同様である。左側はノイズ対策がない場合、右側はノイズ対策がある場合である。いずれの図においても、Ｘ軸、Ｙ軸は、それぞれ加速度ベクトルのＸ方向、Ｙ方向を示す。また、正方形内のうち、２本の対角線と右辺に囲まれた領域は、コード「→」が生成される領域であり、２本の対角線と左辺に囲まれた領域はコード「←」、２本の対角線と上辺に囲まれた領域はコード「↑」、２本の対角線と下辺に囲まれた領域はコード「↓」が生成される領域である。

まず、ノイズ対策がない場合について説明する。図５の「ノイズ対策がない場合」の円の内側は、加速度ベクトルの大きさが閾値より小さい領域、円の外側は、加速度ベクトルの大きさが閾値より大きい領域である。ここで、図５に示す「ノイズ対策がない場合」の様に、携帯端末に加えられる動きに基づく加速度の変化が微小にも関わらず、加速度ベクトルの大きさがその閾値の内側と外側を複数回行き来するように変化したとする。この場合、加速度ベクトルの大きさが閾値周辺で変化しているので、わずかな加速度ベクトルの変化であってもフラグの「オン」と「オフ」が切り替わってしまう。すなわち、「フラグがオンになる」、「コード↓を生成する」、「フラグがオフになる」、「フラグがオンになる」、「コード↓を生成する」・・・を繰り返し、その結果、「↓↓↓・・・」と多数のコードが生成される。このように、わずかな加速度ベクトルの変化によって多数のコードが生成されてしまうと、適正な判定に支障をきたす。そこで、ノイズの影響によって、本来同様であるはずの２つの動きが大きく異なるコード列に変換されてしまうのを防ぐために、下記のノイズ対策を行なう。

ノイズ対策がある場合について説明する。上記のような問題点を解消するために、フラグを「オフ」に設定するための閾値１と、フラグを「オン」に設定するための閾値２と２つの閾値を設ける。すなわち、加速度ベクトルの大きさが閾値２を上回るとフラグが「オン」に設定されるが、加速度ベクトルの大きさが閾値１を下回らないとフラグは「オフ」に設定されない（閾値２を下回ったとしても閾値１を上回っている場合は「オン」のままである）。図５の「ノイズ対策がある場合」の小さな円の内側は、加速度ベクトルの大きさが閾値１より小さい領域である。また、小さな円の外側かつ大きな円の内側である部分は、加速度ベクトルの大きさが閾値１より大きく閾値２より小さい領域である。また、大きな円の外側は、加速度ベクトルの大きさが閾値２より大きい領域である。

ここで、図５の「ノイズ対策がある場合」に示す例の様に、携帯端末に加えられる動きに基づく加速度の変化が微小にも関わらず、加速度ベクトルの大きさがその閾値２の内側と外側を複数回行き来するように変化したとする。この場合、加速度ベクトルの大きさが閾値２の周辺で変化しているが、いったん加速度ベクトルの大きさが閾値２を上回りフラグが「オン」になると、加速度ベクトルの大きさが閾値１を下回らない限りフラグは「オフ」にならない。したがって、ノイズ対策がない場合のように、わずかな加速度ベクトルの変化で多数のコードが生成されることはない。このように、フラグが「オン」になる閾値と、フラグが「オフ」になる閾値とを別々に設定することによって、適正な判定に支障をきたすコード化を防ぐことができる。

図６は、フラグを「オン」に設定するための閾値とフラグを「オフ」に設定するための閾値が別々の値である場合のコード列を生成する方法を示すフローチャートである。

図７は、加速度ベクトルの成分が、異なるコードが生成される２つの領域の境界線付近を変化する場合の対処例を示す。なお、便宜上、Ｘ軸とＹ軸のみで説明するが、Ｘ軸、Ｙ軸、Ｚ軸の３軸であっても同様である。図５と同様に、左側はノイズ対策がない場合、右側はノイズ対策がある場合である。いずれの図においても、Ｘ軸、Ｙ軸は、それぞれ加速度ベクトルのＸ方向、Ｙ方向を示す。また、円の内側は、加速度ベクトルの大きさが閾値より小さい領域、円の外側は、加速度ベクトルの大きさが閾値より大きい領域である。

まず、ノイズ対策がない場合について説明する。図７の「ノイズ対策がない場合」の正方形内のうち、２本の対角線と右辺と円（閾値を示す）に囲まれた領域は、コード「→」が生成される領域であり、２本の対角線と左辺と円（閾値を示す）に囲まれた領域はコード「←」、２本の対角線と上辺と円（閾値を示す）に囲まれた領域はコード「↑」、２本の対角線と下辺と円（閾値を示す）に囲まれた領域はコード「↓」が生成される領域である。ここで、図７の「ノイズ対策がない場合」に示す例の様に、携帯端末に加えられる動きに基づく加速度の変化が微小にも関わらず、加速度ベクトルの向きが右下に伸びる境界線を複数回行き来するように変化したとする。この場合、加速度ベクトルの成分が、コード「→」が生成される領域とコード「↓」が生成される領域との境界線付近で変化しているので、わずかな加速度ベクトルの変化であってもコード「→」と「↓」とが交互に繰り返し生成される。その結果、「↓→↓→↓→」とコード化される。このように、わずかな加速度ベクトルの変化を厳密に反映してコード化すると、適正な判定に支障をきたす。そこで、ノイズの影響によって、本来同様であるはずの２つの動きが大きく異なるコード列に変換されてしまうのを防ぐために、下記のノイズ対策を行なう。

ノイズ対策がある場合について説明する。上記のような問題点を解消するために、一度コード「→」が生成されると、コード「→」が生成される領域とコード「↓」が生成される領域との境界線付近（右下に伸びる対角線と太線２との間）、およびコード「→」が生成される領域とコード「↑」が生成される領域との境界線付近（右上に伸びる対角線と太線１との間）に、コードの切り替えを行なわない新たな領域を設ける。つまり、一度コード「→」が生成されると、図７の太線１から太線２までの斜線部分では、太線１から太線２までの斜線部分から外れない限り、新たなコード化は行われない。また、一度コード「↓」が生成されると、コード「↓」が生成される領域とコード「→」が生成される領域との境界線付近（右下に伸びる対角線と太線３との間）、およびコード「↓」が生成される領域とコード「←」が生成される領域との境界線付近（左下に伸びる対角線と太線４との間）に、コードの切り替えを行わない新たな領域を設ける。つまり、一度コード「↓」が生成されると、図７の太線３から太線４までの斜線部分から外れない限り、新たなコード化は行われない。

ここで、図７の「ノイズ対策がある場合」に示す例の様に、携帯端末に加えられる動きに基づく加速度の変化が微小にも関わらず、加速度ベクトルの向きが右下に伸びる境界線を複数回行き来するように変化したとする。この場合、加速度ベクトルの向きが境界線付近で変化しているが、いったん加速度ベクトルの最大成分に基づき「↓」にコード化されると、加速度ベクトルの最大成分が太線３を越えない限り（すなわち、太線３から太線４までの斜線部分から外れない限り）、「→」にコード化されない。逆に、いったん加速度ベクトルの最大成分に基づき「→」にコード化されると、加速度ベクトルの最大成分が太線２を越えない限り（すなわち、太線１から太線２までの斜線部分から外れない限り）、「↓」にコード化されない。したがって、ノイズ対策がない場合のように、わずかな加速度ベクトルの変化で多数のコードが生成されることはない。このように、いったん隣接する領域でコード化されたものについては、最大成分に変化があっても新たなコードは生成されない領域を設定することによって、適正な判定に支障をきたすコード化を防ぐことができる。

別の追加処理として、時刻情報の付与について説明する。以下のように、コード列には時刻情報を付与することができる。

演算処理部２０５または３０４は、コード列に、加速度センサやジャイロスコープ等のセンサ３０３から出力値を取得した日時（例えば、取得開始時または取得終了時など）の情報を付与することができる。あるいは、演算処理部２０５または３０４は、コード列に、コード列を生成した日時の情報を付与することができる。時刻情報の付与処理は、サーバ内の演算処理部２０５または携帯端末内の演算処理部３０４のいずれにおいてでも行なうことが可能である。

別の追加処理として、位置情報の付与について説明する。以下のように、コード列には位置情報を付与することができる。

演算処理部２０５または３０４は、コード列に、加速度センサやジャイロスコープ等のセンサ３０３から出力値を取得した際の携帯端末１０２または１０３の位置情報を付与することができる。あるいは、演算処理部２０５または３０４は、コード列に、コード列を生成した際の携帯端末１０２または１０３の位置情報を付与することができる。これらの位置情報は、携帯端末１０２または１０３に搭載されたＧＰＳなどの位置情報取得機能を利用して取得される。位置情報の付与処理は、サーバ内の演算処理部２０５または携帯端末内の演算処理部３０４のいずれにおいてでも行なうことが可能である。

別の追加処理として、コード列の反転機能について説明する。例えば、２つの携帯端末を重ねて持って動きを加える場合に２つの携帯端末の上下または左右が異なると、２つの携帯端末のコード列は上下逆または左右逆になってしまう。このような場合であっても、両者の動きは類似していると判定できるように、コード列を反転させることができる。

例えば、携帯端末１０２のコード列１が「↑→↓←」であり、携帯端末１０３のコード列２が「↑←↓→」であるように、左右逆の場合を考える。この場合、演算処理部２０５または３０４は、コード列の反転を指示するコマンドを受け取ると、コード列１またはコード列２のいずれかのコードの左右を逆にして、両者の動きが類似していると判定できるようにコード列を反転させることができる。

［コード列の比較］
次に、２つのコード列を比較して、各々のコード列で表わされた携帯端末の動きが類似しているか否かの判定を行なう方法の一例について説明する。

この判定処理は、サーバ内の演算処理部２０５で行なうことができる。サーバ内の演算処理部２０５は、サーバの第１記憶部２０３に格納されたコード列と第２記憶部２０４に格納されたコード列とを比較する。第１記憶部２０３に格納されたコード列は、図４の方法で生成された携帯端末の動きに基づくコード列である。一方、第２記憶部２０４に格納されたコード列は、図４の方法で生成された別の携帯端末の動きに基づくコード列とすることもできるし、任意のコード列とすることもできる。すなわち、第１記憶部に格納されたコード列に対応する携帯端末とは別の携帯端末の動きに基づくコード列が第２記憶部に格納されて、携帯端末の動きが別の携帯端末の動きと類似しているか否かを判定することができる。あるいは、任意のコード列が第２記憶部に格納されて、携帯端末の動きが、携帯端末に動きが加えられる前から予め登録されている動きと類似しているか否かを判定することができる。

サーバ内の演算処理部２０５は、２つのコード列の類似度を点数で表わして、この点数に基づいて、携帯端末の動きが他の携帯端末の動きと類似しているか否かを判定、あるいは、携帯端末の動きが、携帯端末に動きが加えられる前から予め登録されている動きと類似しているか否かを判定する。具体的には、コード列に含まれる各々のコードが同一か否かに基づいて、点数化が行なわれる。例えば、コード列１に含まれるあるコードとコード列２に含まれるあるコードが「一致」している場合はプラス２点、これらのコードの一方が「置換」されている場合（すなわち、２つのコードが一致しない場合）はマイナス３点、これらのコードの一方が「欠落」している場合（すなわち、どちらかのコードが「削除」されている（言い換えると、どちらかのコードが「挿入」されている）場合）はマイナス２点と、加点または減点を行なう。加点および減点を行なった後に合計点を算出することによって、２つのコード列の類似度が点数で表わされる。これは点数の付け方の一例であり、任意に点数を決めることができる。図８のように比較するコードの組み合わせ方には複数のパターンが想定されるが、「置換」の減点を「欠落」の減点の２倍以上に設定した場合、実質「置換」が含まれるパターンは生じず、最も合計点が高くなるのは「一致」と「欠落」のみが含まれるパターンとなってしまうことに注意する。

この合計点が閾値を超える場合、両者（すなわち、携帯端末の動きと他の携帯端末の動き、または、携帯端末の動きと携帯端末に動きが加えられる前から予め登録されている動き、等）は類似していると判定される。また、この合計点が閾値を超えない場合、両者は類似していないと判定される。

図８は、２つのコード列の比較の一例である。例えば、比較する２つのコード列がコード列１「上↓←→上→」とコード列２「上→←↓→→」とであったとする。ただし２つのコード列の長さは一致している必要はない。また、コード列内のコードが「一致」している場合は「○」、一方が「欠落」している場合は「△」、一方が「置換」されている場合は「×」とする。さらに、それぞれの点数を「○」の場合は２点加点、「△」の場合は２点減点、「×」の場合は３点減点とする。ただし、これらの「一致」、「欠落」、「置換」などの類似判断判定基準、またそれらに対応する加点および減点の点数は、例であり、任意の判定基準および点数を設定することができる。

コード列の比較には複数のパターンが想定されるが、あらゆるパターンから最も合計点が高くなるパターンを採用する。図８では３つのパターンとそれぞれのパターンを採用した場合の合計点を示している。この２つのコード列の比較の例では、考える得る全てのパターンの中で、パターン１が最も点数が高くなる。比較のパターンは非常に数多く存在するが、図８では３つのパターンを紹介する。

既述したように、複数の比較パターンが想定される場合、最も合計点が高くなるパターンが採用されるため、図８の例では、パターン１が採用される。パターン１の合計点が、閾値を超える場合、両者は類似していると判定される。また、この合計点が閾値を超えない場合、両者は類似していないと判定される。

本明細書に記載された方法は一例であり、携帯端末の動きに応じたコード列と他の携帯端末の動きに応じたコード列とを比較する方法、携帯端末の動きに応じたコード列と任意のコード列とを比較する方法は、上記のほか、様々な形態で実現することが可能である。

［用途例］
コード列の比較結果を利用したサービスの実施例を説明する。サーバは、判定した「類似」または「非類似」の結果を、携帯端末に送信することができる。または、サーバは、「類似」に対応したデータを、携帯端末に送信することもできる。

まず、２つの携帯端末の動きを比較する場合について説明する。例えば、利用者は、スマートフォンなどの携帯端末１と携帯端末２とを重ねて持ち、これらの携帯端末に任意の動きを加える。この加えられた動きにより、携帯端末１のコード列と携帯端末２のコード列がそれぞれ既述の方法で生成される。２つのコード列が類似していると判定された場合、メールアドレスや電話番号などのデータを２つの携帯端末間で交換することができる。したがって、赤外線通信等に対応していない携帯端末間でもデータ交換が可能になる。

具体的には、携帯端末間でデータ交換を行なうソフトウェアアプリケーションは、ソフトウェアアプリケーション「Ｂｕｍｐ」のようにＧＰＳの位置情報のみをもとに認識するのではなく、位置情報を用いて２つの携帯端末が近い位置にあるということと、２つのコード列が類似しているという判定結果を受け取ると、データ交換を開始するように設定する。この方法を用いると、位置情報のみを用いる場合よりも誤認識の可能性が低くなる。また、サーバが、類似していると判定する場合には、互いのメールアドレスや電話場番号などのデータを、それぞれの携帯端末に送信するように設定することもできる。

また別の実施例として、利用者は、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）対応の携帯端末と、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）対応の任意の機器とを重ねて、任意の動きを加える。この加えられた動きにより、携帯端末のコード列と任意の機器のコード列がそれぞれ既述の方法で生成される。２つのコード列が類似していると判定された場合に、ペアリング（接続のための事前設定）を行なうように設定できる。

また別の実施例として、利用者は、携帯端末に、イベント会場などに設けられた任意の端末と同様の動きを加える。この加えられた動きにより、携帯端末のコード列と任意の端末のコード列が生成される。２つのコード列が類似していると判定された場合、特定のサービス（例えば、ＬＩＮＥの来場者限定スタンプなど）が提供されるように、携帯端末にデータを送信できる。この場合、指定された期限までにコード列が生成されれば、サービスを受けられるようにすることもできる。すなわち、コード列に付与された時刻情報に基づき、サービスの提供の有無を判断する。

次に、携帯端末の動きと携帯端末に動きが加えられる前から予め登録されている動きとを比較する場合について説明する。例えば、利用者が、ポスターなどに描かれた線をなぞるように携帯端末を動かすことによって、その線の形状に応じたサービス（ＵＲＬや特定のデータ）が提供されるように設定できる。

また別の実施例として、パスワードの代わりとして、特定の動きを事前に登録しておき、認証に用いることも可能である。すなわち、この実施例では携帯端末の動きによって認証が行なわれ、携帯端末の動きが携帯端末に動きが加えられる前から予め登録しておいた動きと類似すると判定される場合に、アクセス等が認められる。

本発明によれば、携帯端末に加えられた動きを、他の携帯端末に加えられた動きやポスターに描かれた線など明確な比較対象（有形の対象物）と比較することが可能である。

以上に示す実施例の通り、本発明は二つの端末間に加えられた動きの類似・非類似の判定に始まり、多様な用途に適応できるものである。特に、本発明によるシステムおよび判定方法は、例えば当該端末以外の別の端末や、ポスターに書かれた軌道の絵など、互いに明確な比較対象がある中で行うジェスチャについて好適に適用されるものである。

１０１ サーバ
１０２ 携帯端末
１０３ 携帯端末
２０１ データ受信部
２０２ データ送信部
２０３ 第１記憶部
２０４ 第２記憶部
２０５ 演算処理部
３０１ データ受信部
３０２ データ送信部
３０３ センサ
３０４ 演算処理部
３０５ 記憶部

Claims (12)

1. 携帯端末の動きを認識および比較するためのシステムであって、
   前記携帯端末の動きを認識するためのセンサデータを取得する取得手段と、
   前記センサデータに基づいて、前記携帯端末の動きに応じて付与された複数のコードからなる第１のコード列を生成する生成手段と、
   前記第１のコード列と格納されている第２のコード列とを比較する比較手段と
   を備えたことを特徴とするシステム。
2. 前記システムは、サーバを含み、
   前記携帯端末が前記取得手段および前記生成手段を備え、
   前記サーバが前記比較手段を備えることを特徴とする請求項１に記載のシステム。
3. 前記システムは、サーバを含み、
   前記携帯端末が前記取得手段を備え、
   前記サーバが前記生成手段および前記比較手段を備えることを特徴とする請求項１に記載のシステム。
4. 前記第２のコード列は、前記携帯端末とは異なる携帯端末の動きに基づくことを特徴とする請求項１から３に記載のシステム。
5. 前記第２のコード列は、前記携帯端末の動きが生じる前から格納されているコード列であることを特徴とする請求項１から３に記載のシステム。
6. 前記第１のコード列および前記第２のコード列に時刻情報を付与する時刻情報付与手段をさらに備えることを特徴とする請求項１から５に記載のシステム。
7. 前記第１のコード列および前記第２のコード列に位置情報を付与する位置情報付与手段をさらに備えることを特徴とする請求項１から６に記載のシステム。
8. 携帯端末の動きを認識および比較するためのサーバであって、
   前記携帯端末の動きに基づき生成された複数のコードからなる第１のコード列を格納する第１の記憶部と、
   第２のコード列を格納する第２の記憶部と、
   前記第１のコード列と前記第２のコード列とを比較する演算処理部と、
   前記比較の結果を前記携帯端末に送信する送信部と
   を備えたことを特徴とするサーバ。
9. 前記携帯端末の動きを認識するためのセンサデータに基づき各々のコードを生成する生成部をさらに備えることを特徴とする請求項８に記載のサーバ。
10. 携帯端末の動きを認識するための携帯端末であって、
    前記携帯端末の動きを認識するためのセンサデータを取得する取得部と、
    前記センサデータに基づいて、前記携帯端末の動きに応じて付与された複数のコードからなるコード列を生成する生成部と
    を備えたことを特徴とする携帯端末。
11. 携帯端末の動きを認識するためのコード列を生成する方法であって、
    前記携帯端末の動きに関連付けられたデータを取得するステップと、
    前記データを複数のコードに分類するステップと、
    前記分類されたコードを配列してコード列を生成するステップと
    を含むことを特徴とする方法。
12. 携帯端末の動きを比較するための方法であって、
    前記携帯端末の動きに基づく第１のコード列に含まれるコードと、第２のコード列に含まれるコードとを比較するステップと、
    前記比較の結果に基づく点数を集計するステップと、
    前記集計された点数に基づき、前記携帯端末の動きと、前記第２のコード列に対応する動きとが類似しているか否かを判定するステップと
    を含むことを特徴とする方法。

Images